Experiência com RAG em produção obtida ao processar mais de 5 milhões de documentos

• Ao longo de 8 meses conduzindo um projeto de RAG (geração aumentada por recuperação), foi possível distinguir o que realmente funcionou do que foi perda de tempo
• No início, foi usado Langchain e Llamaindex para concluir rapidamente um protótipo, mas no feedback de usuários reais surgiram limitações de desempenho
• Os fatores que mais contribuíram para melhorar o desempenho da busca em documentos foram geração de consultas, reranking, estratégia de chunking, uso de metadados e roteamento de consultas
• Na prática, foi construída uma pipeline customizada, escolhendo de forma flexível banco de dados vetorial, embeddings, reranking, LLM etc.
• Toda a experiência e know-how foram reunidos e publicados no projeto open source (agentset-ai/agentset)

---

Visão geral de 8 meses de experiência construindo RAG em produção

• É compartilhada a experiência de construir e operar sistemas RAG em grandes conjuntos de dados, como um total de 9 milhões de páginas (Usul AI) e 4 milhões de páginas (uma empresa anônima de IA jurídica)
• No começo, seguindo tutoriais do YouTube, o autor migrou de Langchain para Llamaindex e concluiu um protótipo em poucos dias, mas na implantação real surgiram problemas de baixo desempenho perceptíveis apenas para os usuários
• Ao longo de vários meses, partes dos componentes do sistema foram ajustadas até alcançar o desempenho ideal

Elementos que realmente contribuíram para melhorar o desempenho (em ordem de ROI)

1. Geração de consultas (Query Generation)

   • Como a última consulta do usuário não consegue conter todo o contexto, um LLM revisa a conversa e gera várias consultas semânticas e consultas por palavras-chave
   • Essas consultas são processadas em paralelo e enviadas ao reranker, obtendo o efeito de ampliar o escopo da busca e compensar vieses da busca híbrida

2. Reranking

   • O impacto no desempenho de um reranking que pode ser implementado com cerca de 5 linhas de código é maior do que se imagina
   • Em entradas com muitos chunks (por exemplo, 50), o processo de reordenar e selecionar apenas parte dos chunks superiores (por exemplo, 15) tem o maior ROI
   • Só o reranking já pode compensar de forma significativa deficiências de uma pipeline mal projetada

3. Estratégia de chunking (Chunking Strategy)

   • Foi a parte que consumiu a maior parte do tempo durante todo o processo de desenvolvimento
   • É preciso entender com precisão a estrutura e os padrões dos dados, fazer o chunking em unidades lógicas e revisar manualmente para evitar que caracteres ou frases sejam cortados no meio
   • Cada chunk precisa manter significado independente

4. Uso de metadados na entrada do LLM

   • Em vez de enviar ao LLM apenas o texto do chunk, adicionar metadados (title, author etc.) melhora bastante o contexto e a qualidade da resposta

5. Roteamento de consultas (Query Routing)

   • Para tipos de consulta que o RAG não consegue responder (por exemplo, resumo de artigo, pedido de informações sobre autor etc.), foi introduzido um roteador leve, que direciona a consulta para um fluxo de processamento com API + LLM

Stack real utilizado (Our stack)

• Banco de dados vetorial: Azure → Pinecone → Turbopuffer (barato e com suporte nativo a busca por palavras-chave)
• Extração de documentos: abordagem customizada
• Ferramenta de chunking: Unstructured.io por padrão; em pipelines corporativas, solução customizada (Chonkie também tem boa reputação)
• Modelo de embedding: uso de text-embedding-large-3 (outros modelos não foram testados)
• Reranker: None → Cohere 3.5 → Zerank (não é popular, mas na prática é excelente)
• LLM: GPT 4.1 → GPT 5 → GPT 4.1 (principalmente usando créditos da Azure)

Open source e conclusão

• Todo o aprendizado e a experiência prática resultaram no projeto open source agentset-ai/agentset
• Publicado sob licença MIT, podendo ser usado livremente e com possibilidade de contato para dúvidas

[GN⁺]

Opinião do Hacker News

• A parte sobre geração de consultas sintéticas parece realmente muito importante; na prática, muitos usuários inserem consultas de forma bastante imprecisa, então no início o LLM gerava consultas sintéticas, mas como a variação dos resultados ficava grande dependendo da consulta gerada a cada vez, passou-se a fazer uma única chamada ao LLM para criar três versões diferentes da consulta, explorá-las em paralelo e depois combinar uma lista robusta de resultados com reciprocal rank fusion; na busca, usa-se hybrid dense + sparse BM25, porque dense sozinho é fraco com termos técnicos; adicionando ainda um reranker, a maioria dos problemas de busca acaba resolvida
  • Achei interessante usar uma abordagem híbrida (BM25 + dense search) para compensar a fraqueza dos modelos dense com termos técnicos; modelos v3 como o SPLADE, que equilibram bem busca semântica e lexical, também parecem ter bom desempenho, e sempre fico curioso se eles poderiam ser substituídos por uma solução mais simples
  • Reforça-se que esse tipo de geração/otimização detalhada de consultas é, no fim, algo com que provedores de soluções RAG como Amazon, Microsoft e OpenAI deveriam se preocupar
  • Embora esses métodos sejam de fato as melhores práticas atuais, ainda fica uma sensação de que falta algo nas estratégias adicionais que poderiam elevar mais um nível o desempenho, como ramificação seletiva do modelo de embedding e combinações variadas de re-rankers
  • Como dica final, sugere-se mostrar ao usuário, junto com o resultado, como o LLM interpretou a intenção de busca dele, para que ele mesmo possa verificar se o entendimento do modelo está correto
• Há confusão em relação à opção self-hosted; olhando a documentação relacionada, parece que são necessárias pelo menos seis contas de serviços de terceiros, e isso é bem diferente do que normalmente se entende por verdadeiro self-hosted
  • Explica-se que o próprio código pode, sim, ser hospedado diretamente por conta própria; parece não haver um critério oficial claro para o termo “self-hosted”; por exemplo, mesmo que um serviço self-hosted tenha backup off-site, ele continua sendo self-hosted e apenas um serviço bem projetado
  • Esse tipo de marketing de self-hosted pode até ser natural, mas como o modelo de negócios original da empresa está na venda da versão hospedada, ela não é obrigada a oferecer um produto self-hosted totalmente independente
  • Compartilha-se a experiência de trabalhar em ambientes de rede restritos; por ter passado os últimos 20 anos em redes internas completamente isoladas, a pessoa acha que pode ter perdido muitas ondas tecnológicas recentes, quase não usa YouTube exceto para conserto de carros e tende a ser um pouco resistente a tendências tecnológicas que exigem conexão online constante
  • A pessoa está usando a versão open source com bastante satisfação; se não quiser dependências de hospedagem, a opinião prática é que basta implementar tudo diretamente em Rust
• Recomenda-se muito testar rerankers grandes baseados em LLM (como o Qwen3-reranker), pois eles entregam o desempenho que se queria há muito tempo dos cross-encoders; o problema é que o custo computacional é considerável; além disso, metadados e informações de tabela são conhecimentos básicos óbvios para humanos, mas como não se repetem nos chunks de texto, injetá-los na entrada do LLM faz o sistema parecer muito mais “inteligente”; também é preciso ter cuidado com consultas complexas que o RAG simples não lida bem, como resumir os 20 documentos mais recentes; por isso, foi adotada uma UI mais focada em busca e com menos UX de chat, mostrando ao usuário exatamente as informações que o modelo realmente vê
  • Concorda-se totalmente que é muito difícil fazer o usuário entender corretamente como funciona a estrutura de processamento de contexto de um LLM; há poucos casos públicos que fogem da UX de chat, e existe ceticismo sobre se as grandes empresas desistiram disso realmente por “falta de resultados”; na prática, como apps de consumo em larga escala precisam controlar o custo de contexto e inferência, parece que UIs com contexto explícito acabaram deixadas de lado; em contraste, sistemas RAG internos têm menos pressão de custo, então a experiência mostra que o foco fica muito mais na qualidade dos resultados e na economia de tempo dos funcionários
  • Otimização técnica é importante, mas gostaria de saber mais sobre casos reais de quanto a eficiência do trabalho dos clientes de fato melhorou; sem isso, parece apenas mais uma moda tecnológica
• Compartilha-se um texto de resumo escrito há um ano e meio sobre processamento de RAG com milhões de páginas (especialmente material técnico): https://jakobs.dev/learnings-ingesting-millions-pages-rag-azure/
  • Também foi construído no ano anterior um sistema RAG para busca técnica, e a impressão é que, olhando agora, muitas partes continuam praticamente iguais
• Do ponto de vista de quem quer construir ou adotar esse tipo de sistema RAG, há curiosidade sobre se uma arquitetura prática seria fazer upload de documentos por API para uma pasta do Google Workspace e então usar a Google AI search API para pesquisar esses documentos, separando-os por pastas diferentes para cada usuário; ou talvez implementar algo semelhante na Azure
• Há curiosidade sobre como fazer versionamento de embeddings; pergunta-se como lidar com atualização de dados, exposição de versões específicas ou filtragem por data, e até se considera adicionar a versão do contexto antes do chunk
  • Basta armazenar no vector store o texto original e os metadados junto com as informações de versão; por exemplo, no turbopuffer a filtragem por atributos é conveniente, e é apresentado este link da documentação
  • A própria pergunta parece bastante útil e importante
• Parece estranho o motivo de a ordem de uso das versões de LLM ter sido GPT 4.1 → GPT 5 → voltar para GPT 4.1, assim como a inconsistência com as versões de outros componentes da stack (por exemplo, text-embedding-large-3)
  • Resposta do OP: assim que o GPT-5 foi lançado, ele foi testado, mas com entradas de muito contexto (até 100 mil tokens) teve desempenho inferior ao GPT-4.1, então houve retorno ao 4.1; especificamente: a) seguia mal instruções e não obedecia bem ao system prompt, b) as respostas ficavam prolixas demais e prejudicavam bastante a UX, c) a janela de contexto limitada a 125 mil tokens causava erro com entradas muito grandes; esses problemas ficaram especialmente evidentes em “RAG”, quando muitos chunks eram enviados, embora em tarefas mais gerais o GPT-5 possa ser melhor
• Embora não seja um defensor da AWS, enfatiza-se que o S3 Vectors é atualmente state-of-the-art nessa área; junto com o Bedrock Knowledge Base, Discovery/Rebalance também fica simples, o que faria dessa a solução mais simples do mercado; acredita-se que, quando houver lançamento oficial, isso vai superar a maioria dos concorrentes
  • Corrige-se em tom de brincadeira que a palavra certa não é “schlep”, mas “shill”
  • Pergunta-se por que o S3 Vectors seria SOTA (estado da arte); afinal, não seria no fim apenas um vector store?
• RAG baseado em embeddings não é necessariamente o melhor método na prática; funciona bem para uma tarefa única ou uma demo, mas no mundo real muitas vezes esbarra em limitações
  • A experiência de outra pessoa é que nem sempre é assim; o produto Query Assistant do Honeycomb, em que trabalhou, também se baseava em consultas de dados desde 2023, e por ter sido projetado com um objetivo simples, parece até um direcionamento ideal para produtos com LLM; combinar isso com processamento non-LLM parece positivo
  • RAG continua sendo reinterpretado de várias maneiras e tem muitos usos; foi integrado como uma ferramenta em busca agentic, ao mesmo tempo em que se mistura busca em fontes em tempo real e a abordagem tradicional por chunks; com as grandes janelas de contexto que devem chegar em breve, deve ficar viável inserir um documento inteiro em uma única requisição
  • Pergunta-se que alternativa seria recomendada exatamente; se a referência é à abordagem de geração de consultas
  • No caso do ChatGPT também, o RAG é eficaz para obter informações atualizadas; essa utilidade prática é justamente o motivo de todos os principais fornecedores oferecerem isso hoje
  • Pede-se esclarecimento sobre qual seria exatamente o termo de comparação
• Foi dito que muito tempo e esforço foram gastos na estratégia de seleção de chunks, então há interesse em ouvir mais detalhes sobre quais estratégias concretas foram usadas