O que separa um RAG de demo de um RAG em produção

A demo de RAG funciona por um motivo simples: quem pergunta é quem construiu. A pergunta sai com as mesmas palavras do documento, uma por vez, sem contexto anterior. Em produção, quem pergunta é alguém que não leu o documento — e usa outra palavra para a mesma coisa.

O que quebra primeiro

Três coisas, quase sempre nesta ordem:

• Sinônimo e sigla. O documento diz "insuficiência cardíaca", a pessoa digita "IC". A busca vetorial acerta parte disso, mas erra feio com siglas internas da empresa, código de produto e nome de sistema — justamente o vocabulário que importa.
• Pergunta de acompanhamento. "E no caso de menores?" não tem sentido sozinha. Se você joga essa frase no buscador sem reescrever a consulta com o contexto da conversa, recupera lixo.
• A resposta plausível. O modelo recebe trechos irrelevantes e responde mesmo assim, com a mesma confiança de sempre. Sem verificação, ninguém percebe até um usuário reclamar.

Nenhum desses problemas se resolve trocando de modelo. Todos são de engenharia ao redor dele.

Busca híbrida não é opcional

Busca vetorial entende semântica e erra literal. Busca por palavra-chave (BM25) entende literal e erra semântica. As duas juntas, com os resultados combinados por reciprocal rank fusion, cobrem o buraco uma da outra.

O custo disso é baixo — é um índice a mais no mesmo Postgres, com pgvector de um lado e índice textual do outro. O ganho aparece exatamente nas consultas que mais irritam o usuário: as que têm um código, uma sigla ou um nome próprio no meio.

Depois da fusão vem a reordenação. Recuperar vinte trechos e mandar todos para o modelo é caro e piora a resposta: o contexto fica cheio de quase-relevante. Reordenar e cortar nos poucos melhores custa menos e responde melhor.

Verificar antes de exibir

A pergunta que separa protótipo de produção é: o que acontece quando a busca não achou nada bom? Em um sistema de tutorial, o modelo inventa. Em um sistema sério, existe um passo entre recuperar e responder que checa se os trechos sustentam a resposta — e, se não sustentam, reescreve a consulta e tenta de novo, ou admite que não sabe.

"Não encontrei isso na base" é uma resposta aceitável. Uma resposta inventada com fonte falsa não é, e é ela que destrói a confiança no sistema inteiro — inclusive nas respostas certas que vieram antes.

Três números, sempre

Sistema de LLM sem medição é chute com sotaque técnico. O mínimo que precisa estar num painel desde o primeiro dia:

1. Custo por requisição, quebrado por etapa. Sem isso você descobre o preço no fim do mês, e sempre pela fatura.
2. Latência por etapa — busca, reordenação, geração. A soma esconde qual das três está estragando a experiência.
3. Taxa de acerto contra um conjunto de perguntas reais, rodado a cada mudança. Não precisa ser sofisticado: cinquenta perguntas com resposta conhecida já pegam a maior parte das regressões.

O terceiro é o que quase ninguém faz, e é o que transforma "achei que melhorou" em "melhorou 12%".

Quando RAG não é a resposta

Se a informação está estruturada num banco, a pergunta certa não é como fazer RAG sobre ela — é gerar SQL e devolver o número com a consulta à vista. Se são cinco documentos que cabem inteiros no contexto, não monte pipeline de busca: mande os cinco. Se o dado está desatualizado na origem, nenhuma arquitetura de recuperação vai consertar; o problema é a origem.

RAG resolve um caso específico — muita informação em texto, mudando com frequência, consultada por pergunta em linguagem natural. Fora dele, costuma ser complexidade que alguém vai manter por anos sem precisar.