Índice
- 1. Recapitulando: os limites do RAG ingênuo
- 2. O pipeline de RAG moderno em resumo
- 3. ① Chunking (o mais importante)
- 4. ② Escolhendo um modelo de embedding
- 5. ③ Escolhendo um vector DB (comparação)
- 6. ④ Busca híbrida (BM25 + vetor)
- 7. ⑤ Reranking (retrieve-then-rerank)
- 8. Frameworks (LlamaIndex/LangChain)
- 9. RAG vs contexto longo
- 10. Cuidados na produção
- Resumo
- FAQ
Você entende o que é RAG. Mas, na hora de construir um de fato, muita gente esbarra em um muro: "até funciona, mas a resposta-chave sai errada." A causa é quase sempre a mesma — ainda é o "RAG ingênuo": picar o documento de qualquer jeito e fazer uma busca vetorial simples.
O RAG prático em 2026 claramente já superou isso. As chaves são um pipeline de múltiplas etapas: "chunking inteligente → o embedding certo → busca híbrida (palavra-chave + vetor) → reranking." Como o complemento de implementação ao artigo 030, este texto cobre o como-fazer concreto de cada etapa, a escolha de um vector DB (Chroma/pgvector/Qdrant/Pinecone/Weaviate/Milvus), frameworks e até "ainda precisamos de RAG na era de 1M de tokens?" — o essencial de uma implementação mais avançada.
As 5 etapas do RAG moderno
— do RAG ingênuo ao RAG que funciona em produção
Os dois maiores ganhos de precisão: busca híbrida (BM25 + vetor) e reranking.
Só de adicionar esses dois você corrige muito o problema do RAG ingênuo de "a resposta sai errada".
* Nomes de ferramentas, métodos e números de benchmark se baseiam em fontes oficiais e em vários veículos de tecnologia (em 2026). Esse espaço evolui rápido e as melhores opções mudam. Os números de benchmark são reportados pelas fontes e variam conforme dados e condições. Avalie com seus próprios dados (abaixo) antes de escolher.
1. Recapitulando: os limites do RAG ingênuo
O RAG mínimo é "dividir o documento → vetorizar com embeddings → armazenar em um vector DB → vetorizar a pergunta e buscar os chunks mais próximos → passá-los ao LLM para responder." Esse é o básico do RAG. Mas esse "RAG ingênuo" tem fraquezas típicas.
- Chunks malfeitos: cortam no meio de uma frase, quebrando o sentido.
- Apenas busca vetorial: fraca em termos exatos como nomes de produtos ou números de modelo (pega/perde coisas que são semanticamente próximas, mas lexicalmente diferentes).
- Passar os top N como estão: os itens realmente mais relevantes acabam soterrados.
O RAG prático em 2026 esmaga esses três com "divisão inteligente", "busca híbrida" e "reranking". Vamos por ordem.
2. O pipeline de RAG moderno em resumo
O fluxo de dados de um RAG de produção tem duas trilhas: preparação (indexação) e momento da consulta (busca e geração).
Duas fases
Preparação (offline): fazer o chunking do documento com inteligência → vetorizar com embeddings → armazenar em um vector DB (construir um índice de palavras-chave ao mesmo tempo).
Momento da consulta (online): buscar os top 50-100 com busca híbrida (BM25 + vetor) → reduzir a alguns poucos com reranking → passar ao LLM para gerar a resposta.
A diferença em relação ao RAG ingênuo é se "④ busca híbrida" e "⑤ reranking" estão presentes. Essas duas etapas elevam a precisão da busca a um nível prático.
3. ① Chunking (o mais importante)
É justo dizer que o chunking decide metade da qualidade do RAG. Aqui estão as principais estratégias.
| Estratégia | O que faz | Boa para |
|---|---|---|
| recursive 512 tokens | Um padrão pragmático. Reportada como a #1 de 7 estratégias em um benchmark de fev/2026 | Na dúvida, esta |
| semantic | Divide onde o sentido muda, de modo que cada chunk seja tematicamente coerente | Documentos técnicos densos |
| structural | Respeita títulos, blocos de código, seções HTML | Documentação e código |
| parent-child (hierárquico) | Busca com precisão em chunks pequenos; retorna o chunk-pai circundante na hora de responder | Equilibrar precisão e contexto |
Se a perda de contexto nas fronteiras for o problema, Contextual Retrieval (anexar o contexto do documento inteiro a cada chunk) ou Late Chunking ajudam. A Anthropic reporta que Contextual Retrieval + reranking reduziram as falhas de retrieval no top-20 em até 67% (um número reportado). A ordem realista: começar com "recursive 512" e adicionar semantic / parent-child / Contextual Retrieval se a precisão ficar aquém.
4. ② Escolhendo um modelo de embedding
O modelo de embedding converte os chunks em vetores — a base da precisão de busca.
- Padrão seguro: OpenAI text-embedding-3-large. Um bom equilíbrio entre qualidade de retrieval e facilidade de integração.
- Outras opções: embeddings da Cohere, Voyage, Gemini e diversos modelos OSS.
- Importante: muitos embeddings OSS são mais do que suficientes para produção quando combinados com busca híbrida + reranking. Não fique obcecado apenas com o embedding.
O ponto é tratar "o embedding como uma parte de todo o pipeline de busca". Em vez de trocar por um embedding caro, adicionar busca híbrida e reranking costuma ser mais custo-efetivo.
5. ③ Escolhendo um vector DB (comparação)
O vector DB armazena e busca vetores. Aqui estão os líderes de 2026 por característica.
| DB | Característica / ponto forte | Para quem |
|---|---|---|
| Chroma | AI-native, local-first, API Python simples | Indivíduos/PoCs que prototipam RAG mais rápido |
| pgvector | Uma extensão do Postgres. Sem um segundo DB, consistência transacional | Times que já usam Postgres |
| Qdrant | Baixa latência (p50 ~4ms; reportado vs Milvus ~6ms / Pinecone ~8ms) | Foco em velocidade, produção |
| Pinecone | Totalmente gerenciado. Zero infra, começa só com uma API key | Quer a operação resolvida, cloud-first |
| Weaviate | Campeão de busca híbrida (BM25 + vetor + metadados em uma consulta) | Usuários intensivos de busca híbrida |
| Milvus | Nível enterprise, lida com bilhões de vetores | Escala muito grande |
Eixos de escolha: "escala, gerenciado vs self-hosted, stack existente, orçamento". Na dúvida — Chroma para prototipagem, pgvector se você tem Postgres, Qdrant/Pinecone para produção equilibrada, Weaviate para uso intenso de híbrida. Para a maioria das cargas de RAG, Pinecone / Weaviate / Qdrant são considerados escolhas fortes.
6. ④ Busca híbrida (BM25 + vetor)
O que corrige a maior fraqueza do RAG ingênuo — ser fraco em termos exatos — é a busca híbrida. Ela funde o BM25 (busca por palavra-chave/lexical) com a busca vetorial densa.
Fundir lexical + semântico
Fundir os dois com Reciprocal Rank Fusion (RRF) é reportado como capaz de
superar consistentemente qualquer abordagem isolada (NDCG mais alto).
Na prática, o mais fácil é usar um DB que retorna resultados híbridos em uma única consulta, como o Weaviate. Deixe o ajuste de score complicado por conta do RRF (fusão baseada em ranking) e não vai quebrar. O resultado: uma busca forte tanto em termos exatos quanto em paráfrases.
7. ⑤ Reranking (retrieve-then-rerank)
O padrão de 2026 é "duas etapas: primeiro buscar amplamente → depois reduzir (rerank)".
- Etapa 1 (retrieve): buscar rapidamente os top 50-100 com um bi-encoder (embeddings).
- Etapa 2 (rerank): com um cross-encoder, pontuar (pergunta, chunk) em conjunto e reduzir aos poucos realmente mais relevantes.
Rerankers populares são Cohere Rerank 3.5, Voyage rerank-2.5, BGE reranker-v2, Jina Reranker v2. O reranking adiciona cerca de 50-200ms de latência e custo, mas, como os chunks passados ao LLM passam a ser poucos e selecionados, ele frequentemente reduz o consumo de tokens do LLM e baixa o custo total. Tanto em precisão quanto em custo, o reranking está se tornando uma etapa para a qual "não há razão para não adicioná-la".
8. Frameworks (LlamaIndex/LangChain)
Usar um framework é mais rápido do que escrever tudo do zero. Aqui está a divisão de tarefas de 2026.
- LlamaIndex: focado em retrieval. Forte em indexação de documentos, qualidade de busca e iteração rápida de RAG.
- LangChain / LangGraph: o lado da orquestração (controle). Workflows complexos e coordenação de agentes.
- Padrão combinado: na prática, muitos usam o LlamaIndex como camada de retrieval e o LangGraph como camada de controle.
Note que, ultimamente, com a padronização de ferramentas via MCP e a ascensão dos Agent SDKs, há uma tendência de agentes construírem pipelines em tempo real sem frameworks de LLM pesados. Ainda assim, se você está lapidando a qualidade de busca, a família LlamaIndex continua forte. Para a construção de agentes em geral, veja como construir um agente de IA.
9. RAG vs contexto longo
"Com uma janela de contexto de 1M de tokens, não posso simplesmente enfiar tudo e pular o RAG?" — uma pergunta comum. A resposta é "não, o RAG não é substituído".
A armadilha do "enfiar tudo"
- Ineficiente em tokens: enviar um contexto enorme e redundante toda vez é caro.
- Lost in the middle: a informação no meio de um texto longo tende a ser ignorada.
- Distração: quanto mais informação irrelevante, menor a qualidade da resposta.
A diretriz: use contexto longo para corpora pequenos e iteração rápida, adicione prompt caching cedo para contexto repetido e estável, e adicione RAG no momento em que "frescor, escala, proveniência" se tornam requisitos. "Basta enfiar na janela de contexto" é o novo "basta adicionar um vector DB" — não é uma cura para tudo. Combine isso com um entendimento da janela de contexto.
10. Cuidados na produção
- Construa uma avaliação primeiro: "meio que melhorou" não dá para melhorar. Quantifique a precisão de retrieval com um conjunto de perguntas representativas × fontes esperadas e compare a cada mudança.
- Monitoramento: acompanhe continuamente a taxa de acerto do retrieval, a relevância pós-rerank e o grounding das respostas.
- Design de custo: a cobrança vem dos embeddings, do reranking e do LLM. Cortar tokens do LLM via reranking é a economia de custo padrão. Veja economia de tokens.
- Frescor e proveniência: projete para refletir as atualizações de dados (reindexação) e sempre anexar a fonte (qual documento) às respostas — chave para combater a alucinação.
- Dados confidenciais: tenha cuidado ao vetorizar documentos internos e colocá-los externamente. Veja as diretrizes corporativas de uso de IA.
Resumo
O RAG prático evoluiu do ingênuo "picar e buscar por vetor" para um pipeline de múltiplas etapas: "chunking inteligente → embedding → vector DB → busca híbrida → reranking". Os dois maiores ganhos de precisão são a busca híbrida (fundir BM25 + vetor com RRF) e o reranking (retrieve-then-rerank) — só de adicionar esses dois você corrige muito o "a resposta sai errada".
Para vector DBs: Chroma para prototipagem, pgvector se você tem Postgres, Qdrant/Pinecone para produção, Weaviate para uso intenso de híbrida. Para frameworks: LlamaIndex para retrieval, LangChain/LangGraph para controle. E mesmo com 1M de tokens, o RAG não é substituído — se você precisa de frescor, escala e proveniência, é RAG. Um último item indispensável: "construa o conjunto de avaliação primeiro". Você não pode melhorar o que não consegue medir. Mantenha isso e seu RAG vai evoluir de forma confiável de "meio que funciona" para "funciona em produção".
Leitura relacionada: o que é RAG (básico), o que é uma janela de contexto, como construir um agente de IA, Claude Agent SDK e o que é MCP.
FAQ
Q. A precisão do meu RAG está baixa. O que devo corrigir primeiro?
A. Adicionar as duas coisas — "busca híbrida" e "reranking" — é o mais eficaz. A busca vetorial pura sozinha é fraca em termos exatos como números de modelo e nomes próprios, e os chunks mais relevantes acabam soterrados. Fundir com o BM25 (via RRF) + um rerank com cross-encoder eleva a qualidade de busca a um nível prático. Se ainda assim não for suficiente, reveja seu chunking.
Q. Qual vector DB devo escolher?
A. Chroma para prototipagem, pgvector se você já tem Postgres são os começos fáceis. Para produção equilibrada, Qdrant (baixa latência) ou Pinecone (totalmente gerenciado); para busca híbrida intensa, Weaviate; para escala muito grande, Milvus. Escolha pela escala, preferência de operação, stack existente e orçamento.
Q. Qual tamanho de chunk é bom?
A. Cerca de 512 tokens com divisão recursive é um padrão pragmático (reportado perto do topo nos benchmarks de 2026). Para documentos técnicos, semantic (dividir por sentido); para documentação/código, structural (respeitar títulos/código); para precisão mais contexto, parent-child. Comece em 512 e ajuste enquanto avalia.
Q. Com uma janela de 1M de tokens, o RAG não é desnecessário?
A. Ele não se torna desnecessário. Enfiar tudo no contexto derruba a qualidade via ineficiência de tokens, "lost in the middle" e distração. Use contexto longo para corpora pequenos e protótipos, e RAG quando frescor, escala e proveniência forem requisitos — essa é a divisão realista.
Q. LangChain ou LlamaIndex — qual devo usar?
A. LlamaIndex se você está lapidando a qualidade de busca; LangChain/LangGraph para controle complexo e coordenação de agentes. Na prática, muitos os combinam — "LlamaIndex como camada de retrieval, LangGraph como camada de controle". Ultimamente também há uma tendência de montar de forma leve com Agent SDKs, então escolha pelos seus requisitos.
