O problema
Um time decide "vamos fazer RAG" antes de responder duas perguntas mais básicas: como é o conteúdo de verdade, e como as pessoas vão perguntar sobre ele. O resultado mais comum é escolher um tamanho de chunk fixo (500 tokens, por exemplo), jogar tudo — contratos jurídicos longos, tabelas de preço, threads de Slack, documentação técnica — no mesmo pipeline de embedding, e só descobrir depois que a recuperação traz pedaços de contrato cortados no meio de uma cláusula, ou uma tabela sem o cabeçalho da coluna.
RAG não é uma técnica única. É uma composição de decisões — como fatiar, como indexar, como buscar, quando não usar — e cada uma dessas decisões depende da forma real dos dados e do padrão real de consulta, não de um valor padrão que funcionou em outro projeto.
Chunking segue a estrutura do conteúdo, não um tamanho fixo
Um documento com seções bem marcadas (títulos, subtítulos) deve ser fatiado nos limites semânticos dessas seções — um chunk é "a política de reembolso", não "os primeiros 500 tokens do arquivo, não importa onde isso caia". Conteúdo tabular quebra esse modelo: uma tabela fatiada por tamanho de token perde a relação entre linha e cabeçalho, e a resposta recuperada vira números sem contexto.
Regra prática: antes de decidir o tamanho do chunk, decida a unidade de sentido do conteúdo. Prosa contínua sem estrutura clara (transcrição de reunião, por exemplo) tolera um corte por tamanho com sobreposição. Conteúdo com estrutura explícita (documentação, contratos, tabelas) deve ser fatiado respeitando essa estrutura, mesmo que os chunks resultantes tenham tamanhos bem diferentes entre si.
A estratégia de recuperação segue o padrão de consulta
Uma busca semântica pura (embedding contra embedding) é boa para perguntas amplas ("como funciona nossa política de reembolso") e ruim para buscas exatas ("qual é o número do pedido 4521"). Um sistema que só tem busca vetorial vai "quase acertar" uma busca exata — trazer pedidos parecidos, não o pedido certo.
Três padrões de consulta pedem estratégias diferentes:
- Busca exata (um ID, um número, um nome específico): busca lexical ou um índice estruturado resolve melhor que embedding.
- Pergunta ampla, semântica (um conceito, uma explicação): busca vetorial é o caminho certo.
- Pergunta que exige múltiplos saltos (comparar duas cláusulas de contratos diferentes, por exemplo): recuperação única não basta — o sistema precisa buscar, avaliar o que faltou, buscar de novo.
Um sistema de produção madura combina busca lexical e vetorial (busca híbrida) e usa metadados estruturados (data, tipo de documento, autor) como filtro antes da busca semântica, não depois.
Quando RAG não é a resposta certa
O distrator mais comum em cenário de arquitetura é propor RAG para um problema que não precisa dele:
- O corpus é pequeno e cabe inteiro no contexto (um guia de estilo, um arquivo de configuração): injetar o conteúdo direto no prompt é mais simples e mais confiável do que indexar e recuperar um pedaço dele.
- A base de conhecimento é pequena e enumerável (uma tabela de códigos de erro com 40 entradas): uma consulta estruturada a uma tabela vence busca semântica em precisão e em custo.
- O requisito de atualização é mais rápido do que qualquer reindexação viável (preço em tempo real, status de um pedido): o caminho certo é uma chamada de ferramenta que busca o dado ao vivo, não um índice que sempre vai estar um passo atrasado.
RAG resolve um problema específico — conhecimento grande demais para caber no contexto, mas estável o suficiente para valer a pena indexar. Fora dessa faixa, é complexidade sem retorno.
Coloque em prática
O laboratório desta lição implementa três funções de decisão: qual estratégia de chunking usar dado o formato do conteúdo, qual estratégia de recuperação usar dado o padrão de consulta, e se RAG é sequer a resposta certa dado o tamanho do corpus, a exigência de atualização e se o conteúdo cabe no contexto.