RAG em produção: o que realmente quebra quando clientes de verdade começam a perguntar

Dá para construir uma demo funcional de Retrieval-Augmented Generation em uma tarde. Você gera embeddings de alguns documentos, joga tudo num banco vetorial, recupera os cinco trechos mais próximos por similaridade de cosseno e cola no prompt. Ele responde perguntas. Numa gravação de tela, parece mágica.

Aí você coloca isso na frente de clientes reais e a distância aparece.

Alguém pergunta no terceiro idioma que você atende. Alguém pergunta sobre uma política que existe em duas versões contraditórias no seu próprio site. Alguém pergunta algo que o seu conteúdo genuinamente não cobre, e o sistema responde mesmo assim: fluente, confiante e errado. Vinte pessoas perguntam ao mesmo tempo enquanto um novo rastreamento está rodando. Um PDF digitalizado em vez de digitado vira ruído de recuperação que envenena silenciosamente todas as respostas vizinhas.

Nada disso aparece numa demo, porque uma demo usa documentos limpos, um idioma, um usuário e perguntas cujas respostas quem construiu já conhece. Tudo que é caro em RAG mora na distância entre essas duas situações.

Este guia é sobre essa distância. Ele assume que você já sabe o que é RAG — se não sabe, comece pela nossa explicação sobre o que é um chatbot RAG e como ele funciona e depois volte. O que vem a seguir é a camada de cima: a engenharia que decide se um sistema de recuperação sobrevive ao contato com usuários reais.

Toda vez que as janelas de contexto crescem, alguém declara o RAG obsoleto. Não aconteceu, e as razões são estruturais, não temporárias.

O contexto utilizável é menor que o contexto anunciado. Um modelo que aceita 200 mil tokens não raciocina igualmente bem sobre os 200 mil. O efeito é bem documentado: o artigo "Lost in the Middle", de Liu et al. (2023), mostrou a precisão caindo para informações enterradas no meio de entradas longas, e cada geração seguinte de modelos de contexto longo veio com alguma versão da mesma ressalva. A qualidade se degrada antes do limite duro. E a base de conhecimento real de uma empresa média não tem 200 páginas; tem dezenas de milhares.

Fine-tuning muda comportamento, não conhecimento. Este é o equívoco mais caro da área. Fine-tuning é excelente para ensinar formato, tom ou padrão de raciocínio. É um jeito fraco e não confiável de ensinar fatos, e degrada mal quando os fatos mudam — o que acontece toda semana em preços, políticas e estoque.

O custo escala na direção errada. Enfiar o corpus inteiro em cada requisição significa pagar pelo corpus inteiro a cada pergunta. Recuperar significa pagar pelos poucos milhares de tokens relevantes. Em qualquer volume real de mensagens, essa diferença é a margem inteira.

Auditabilidade é requisito, não recurso. Em finanças, saúde e direito, uma resposta sem fonte rastreável não serve. A recuperação produz esse rastro de graça, porque o sistema já sabe de qual documento veio cada trecho.

Então a pergunta interessante não é mais se vale recuperar. É por que tantos sistemas de recuperação são ruins nisso.

A causa mais comum de respostas ruins não é o modelo, nem os embeddings, nem o banco vetorial. É o corpus.

Já vimos uma base de conhecimento em que aproximadamente metade dos documentos eram quase duplicatas da outra metade: a mesma política republicada com pequenas diferenças de formatação num site de marketing, numa central de ajuda e num PDF arquivado. A recuperação devolvia obedientemente cinco trechos que eram cinco cópias do mesmo parágrafo; o modelo via uma fatia estreita de evidência em vez de cinco perspectivas, e o orçamento de top-k ia embora em redundância. Corrigir isso foi trabalho manual e sem glamour de pipeline de dados. Ainda assim melhorou a qualidade das respostas mais do que qualquer ajuste de recuperação daquele mês.

Os reincidentes:

• PDFs digitalizados e dano de OCR. Um texto que parece bom ao olho humano pode estar estruturalmente destroçado: ordem de colunas embaralhada, tabelas achatadas em sopa de palavras. Embeddings de texto destroçado são recuperados de forma imprevisível.
• Boilerplate e banners de consentimento. Rastreie um site de forma ingênua e cada página carregará o mesmo aviso de cookies, o mesmo menu e o mesmo rodapé. Agora todos os trechos compartilham um prefixo grande e idêntico, e a similaridade semântica entre páginas sem relação sobe. É por isso que o nosso rastreador remove consentimento e moldura antes de indexar qualquer coisa.
• Paredes de login e páginas rasas. Uma página de login tem texto, então um pipeline ingênuo a ingere. Ela não contribui com nada e dilui tudo.
• Contradições que ninguém notou. Duas páginas informam prazos de devolução diferentes. A recuperação acha as duas. O modelo escolhe uma. Escolha qual escolher, alguém vai receber a informação errada.

A regra prática: o portão de qualidade fica antes da indexação, em exatamente um lugar do código, aplicado por todo caminho capaz de adicionar conteúdo. Quando as regras de ingestão vivem em três lugares, elas divergem, e a diferença de qualidade entre o seu onboarding e o seu rastreamento periódico vira um mistério que ninguém consegue reproduzir. Para a versão prática, veja nosso guia de como montar uma base de conhecimento limpa.

Uma única busca vetorial densa é o rascunho da recuperação. Em produção, recuperação é um pipeline de quatro ou cinco etapas, e cada uma corrige um modo de falha que as outras não alcançam.

Expansão de consulta. Consultas reais são curtas, com erros de digitação e cheias de jargão interno. Expandir a consulta com sinônimos e siglas por extenso antes de gerar o embedding melhora o recall de forma mensurável — especialmente nas perguntas de duas ou três palavras que dominam o tráfego real de chat.

Busca híbrida: densa mais esparsa. Embeddings densos capturam significado, mas erram tokens exatos: SKUs, códigos de erro, números de modelo, sobrenomes. A busca por palavra-chave (no nosso caso, BM25 sobre um tsvector do Postgres) acerta justamente esses e erra as paráfrases. Rodar as duas e fundir os resultados com Reciprocal Rank Fusion é o padrão de produção, não uma otimização.

Um detalhe que pesa mais do que deveria: busca por palavra-chave é dependente de idioma. O Postgres reduz "preços" a "preç" só se você disser que o texto está em português. Turco, alemão, espanhol, francês, italiano e português precisam cada um da sua configuração, e idiomas sem stemmer embutido — japonês, coreano, chinês — precisam de um fallback deliberado, não acidental. Um sistema RAG multilíngue que aplica stemming de inglês em toda consulta perde recall silenciosamente em todos os outros idiomas. Se você atende mais de um mercado, leia junto com esta seção o nosso guia de chatbot multilíngue.

Reranking. A fusão entrega vinte ou trinta candidatos plausíveis. Um reranker cross-encoder pontua cada um contra a consulta real e rotineiramente promove o trecho genuinamente correto da posição 15 para o top 3. Se o seu sistema "vive citando uma página quase certa", a etapa de reranking ausente é o primeiro lugar para olhar.

Cache, com cuidado. Perguntas idênticas não deveriam reexecutar o pipeline inteiro. Mas guarde em cache a recuperação, com chave de consulta e top-k — não a resposta gerada — ou você servirá uma resposta desatualizada depois que o documento de origem já tiver sido atualizado.

Todo sistema RAG sério pontua a recuperação antes de gerar e usa essa pontuação para instruir o modelo sobre o quanto confiar no contexto: responder direto, responder com ressalva, ou recusar e transferir. É a defesa contra alucinação mais importante que existe.

É também o ajuste com maior probabilidade de estar errado, porque os valores padrão em geral são inventados, não medidos.

Eis um erro que vale aprender — foi nosso. Nosso limiar de "alta confiança" estava em 0,82 de similaridade de cosseno, um número que soa adequadamente rigoroso. Depois checamos contra tráfego real e descobrimos que menos de 2% das respostas reais cruzavam esse valor. Correspondências semânticas densas raramente passam de cerca de 0,80, mesmo quando o trecho recuperado é óbvia e exatamente o certo. Ou seja, o modelo ouvia "este contexto é apenas parcial" em quase toda pergunta e se resguardava: respostas corretas embrulhadas em incerteza desnecessária. A recuperação estava boa. Errada estava a régua.

A correção não foi afrouxar tudo. Puxamos uma amostra de conversas reais na faixa ambígua e lemos: entre 0,64 e 0,68, as respostas eram específicas e corretas, citando limites de plano e regras exatos. Mas lacunas genuínas — perguntas sobre uma integração que não oferecemos — pontuavam na mesma faixa e se resguardavam corretamente. Então baixamos a barra alta para um nível que correspondências reais conseguem alcançar, mantivemos a faixa intermediária ambígua como "parcial" e deixamos a proteção de baixo, o "não invente", exatamente onde estava.

As lições transferíveis: calibre limiares contra a sua própria distribuição, não contra a intuição; leia as conversas reais na faixa que você está ajustando, porque pontuações agregadas escondem a diferença entre uma boa resposta e um erro bem pontuado; e transforme cada limiar em variável de ambiente, para que uma calibragem ruim seja um rollback de um minuto e não um deploy.

Chunking parece uma decisão de formatação. Na verdade é uma decisão de recuperação, e uma parcela surpreendente das reclamações do tipo "o bot não acha uma coisa que está claramente na nossa documentação" nasce aí.

Cortar em tamanho fixo a cada 500 tokens vai partir uma tabela ao meio, separar um título do parágrafo que ele introduz e dividir um procedimento numerado em dois trechos de modo que nenhum sirva sozinho. Divisão consciente da estrutura — respeitar primeiro títulos e limites de parágrafo, depois mesclar até o tamanho-alvo e quebrar segmentos longos em fronteiras de frase — custa um dia de implementação e se paga imediatamente. Nosso pipeline mira cerca de 800 tokens por trecho com 200 de sobreposição, um ponto de partida razoável para conteúdo corporativo majoritariamente textual.

O problema mais sutil é que um trecho, uma vez isolado, perde o contexto que o tornava significativo. "A entrega padrão leva de 3 a 5 dias úteis" é um alvo de recuperação inútil se o trecho não diz de quem é a entrega, qual região ou qual linha de produto. Recuperado sozinho, o modelo pode aplicá-lo a uma pergunta completamente diferente.

A correção é enriquecer cada trecho com a própria procedência antes de gerar o embedding — título do documento, título da seção, fonte — para que o texto embutido carregue o contexto que um leitor humano teria pela página ao redor. A Anthropic popularizou uma versão disso como "contextual retrieval" e relatou uma queda substancial nas falhas de recuperação. E não é preciso uma passada de LLM para valer a pena: um prefixo determinístico montado a partir dos próprios metadados do documento captura boa parte do benefício a custo marginal zero — é o que rodamos em produção.

Um aviso vindo da experiência: se você mudar a estratégia de chunking ou de contextualização, comprou uma migração. Todo trecho existente foi embutido pelo esquema antigo. Planeje uma reindexação direcionada, documento a documento — nunca um reembedding em massa e às cegas de um corpus em produção.

Times discutem qualidade de recuperação. O que de fato derruba sistemas é confiabilidade.

Ingestão é um processo longo, de várias etapas e parcialmente externo: buscar, extrair, dividir, gerar embeddings (uma chamada paga de API que pode bater em limite de taxa), gravar, marcar como concluído. Tudo que roda por minutos atravessando uma fronteira de rede vai ser interrompido, e essas interrupções não são raras.

Nossa falha mais instrutiva foi silenciosa. Uma usuária iniciou um rastreamento do site e depois saiu da página. A função serverless que atendia a requisição foi morta no meio do voo — depois de os trechos e embeddings terem sido gravados, mas antes de o documento ser marcado como processado. Nenhuma exceção. Nenhum erro no monitoramento. Apenas um documento totalmente indexado exibido permanentemente como "indexando", e uma usuária que rastreou o mesmo site quatro vezes em dezenove horas tentando fazer um selo mudar, e depois foi embora.

Essa classe de bug nos ensinou três invariantes que vale copiar:

• Ordene as escritas para que a verdade visível ao usuário venha primeiro. Vire a flag de processado imediatamente após o conteúdo ser gravado de forma durável; estatísticas, invalidação de cache e demais contabilidades vêm depois, cada uma com tempo limitado e em melhor esforço. Nunca deixe um passo opcional entre o trabalho real e a flag que o registra.
• Torne cada handler de job idempotente e depois reenfileire com generosidade. Se um worker morre no meio, a próxima varredura precisa poder reexecutar o job inteiro com segurança. Handlers de "apagar e inserir" tornam as retentativas gratuitas.
• Adicione uma varredura auto-reparadora. Um job periódico que procura documentos travados em estado inacabado e os reenfileira transforma uma falha permanente e visível em um atraso de alguns minutos. É o item de confiabilidade de maior retorno em um pipeline RAG, e quase ninguém o constrói antes de se queimar.

Sob carga concorrente, some também a infraestrutura chata: uma fila de verdade em vez de promessas do tipo dispare-e-esqueça, limites de pool de conexões que considerem que chamadas de embedding seguram conexões abertas, e isolamento por cliente para que o rastreamento de 900 páginas de um deles não deixe o chat ao vivo de todos os outros passando fome.

Não dá para avaliar qualidade de RAG no olho. Todo time acredita que consegue, e todo time erra, porque o modo de falha de um RAG ruim é uma resposta fluente, plausível e bem formatada que por acaso é falsa. Ela se lê exatamente como uma boa.

O setup mínimo viável de avaliação é menor do que as pessoas temem:

Um conjunto dourado. De trinta a cem perguntas reais com respostas corretas conhecidas, tiradas do seu histórico de atendimento em vez de inventadas. Reexecute depois de cada mudança em recuperação, chunking, prompts ou versão de modelo. É um teste de regressão e deve falhar de forma barulhenta.

Separe a pontuação de recuperação da pontuação de resposta. Quando a qualidade cai, você precisa saber se o trecho certo não foi recuperado ou se foi recuperado e ignorado. As correções são completamente diferentes, e uma única nota ponta a ponta não distingue as duas.

Monitore a distribuição de confiança ao longo do tempo. Uma mudança no histograma das pontuações de recuperação é um alerta precoce — normalmente alguém adicionou um lote grande de conteúdo ruim, ou o tráfego migrou para temas que o seu corpus não cobre.

Trate o "não sei" como sua telemetria mais valiosa. Toda resposta de baixa confiança e todo escalonamento é uma lacuna de conteúdo já rotulada. Os times cujos assistentes melhoram visivelmente ao longo dos meses são, quase sem exceção, os que leem essa lista toda semana e escrevem a página que falta. Nosso guia de analytics de chatbot cobre as métricas que valem acompanhamento.

E meça desvio de tickets com honestidade. Uma conversa não está resolvida porque o cliente parou de digitar; está resolvida porque ele não te mandou um e-mail uma hora depois. Se a sua plataforma não consegue ligar esses dois eventos, você está otimizando um número que te elogia.

Dois sistemas RAG com arquitetura idêntica podem ter um sucesso e um fracasso no mesmo setor. A diferença normalmente não está no pipeline.

A linguagem do domínio dá trabalho de verdade. Abreviações da saúde, nomes de instrumentos financeiros, formatos de citação jurídica e convenções de SKU quebram a recuperação genérica de maneiras bem específicas. Um cliente de finanças pergunta sobre "o de três anos" e quer dizer um produto específico; um embedding genérico pensa em tempo. Isso se resolve com dicionários de sinônimos, filtros de metadados e conteúdo escrito também para a máquina — não com um modelo maior.

Disciplina de escopo vence capacidade. O jeito mais rápido de destruir a confiança em um assistente é deixá-lo responder fora do que ele realmente sabe. Uma fronteira explícita — este agente responde sobre nossos produtos, políticas e documentação e transfere todo o resto — reduz respostas constrangedoras mais do que qualquer melhoria de recuperação. É também a correção que implantamos depois de ver assistentes reais derivando para terreno genérico e inútil.

Adoção é requisito de lançamento. Um assistente sobre o qual ninguém avisou o time de atendimento acaba sabotado pelo time de atendimento. Alguém precisa ser dono das lacunas de conteúdo, ler os escalonamentos e decidir o que o assistente pode prometer.

Confiança corporativa tem checklist. Acesso por papéis para que a recuperação respeite quem está perguntando, trilhas de auditoria mostrando qual fonte produziu qual resposta, residência de dados clara, controles de retenção e uma declaração inequívoca de que conversas de clientes não são usadas para treinar modelos públicos. Não são recursos que se acrescentam depois de uma revisão de segurança; são a razão de a revisão passar ou não. Nosso guia de segurança e privacidade de chatbots percorre o que verificar em um fornecedor.

Se você vai construir internamente, o escopo honesto não é "um banco vetorial e um prompt". É um portão de qualidade de conteúdo, um pipeline de recuperação multietapa, limiares de confiança calibrados, uma fila de jobs com handlers idempotentes e varredura auto-reparadora, um arcabouço de avaliação e um ciclo de analytics — mais a operação contínua de tudo isso. Vale a pena quando qualidade de recuperação é o seu produto. É um mau uso do ano de um time pequeno quando recuperação é apenas o meio de responder perguntas de clientes.

Se você vai comprar, o checklist deste artigo vira a sua due diligence. Pergunte ao fornecedor: vocês usam recuperação híbrida ou só densa? Existe etapa de reranking? Como o limiar do "não sei" é definido e eu posso mudá-lo? O que acontece com um documento se a ingestão for interrompida no meio? Consigo ver qual fonte produziu determinada resposta? O que acontece com a busca por palavra-chave no meu idioma? Quais perguntas o assistente não conseguiu responder na semana passada? Um fornecedor que não sabe responder isso construiu uma demo.

Esta é a camada que a Chatloom existe para assumir. O pipeline descrito ao longo deste artigo — chunking consciente da estrutura com enriquecimento contextual, expansão de consulta, recuperação híbrida densa mais esparsa com stemming por idioma, fusão RRF, reranking cross-encoder, confiança calibrada com um "não sei" de verdade, jobs de ingestão idempotentes com varredura auto-reparadora e um painel que mostra exatamente quais perguntas ficaram sem resposta — é o que roda por trás de cada agente da plataforma, em dez idiomas, sem um time de ML do seu lado da mesa.

Teste hoje com o seu próprio conteúdo. Crie uma conta gratuita, cole a URL do seu site e veja o ciclo inteiro rodar — rastreamento, portão de qualidade, chunking, embeddings, recuperação híbrida — em mais ou menos o tempo que você levou para ler este artigo. Faça as cinco perguntas que os seus clientes realmente fazem. Se as respostas se apoiarem no seu conteúdo e ele admitir o que não sabe, você já fez a sua avaliação. O plano gratuito não pede cartão.

Prefere os detalhes primeiro? Veja como funciona o nosso motor RAG ou leia o artigo prático complementar sobre treinar um assistente com os seus próprios dados.