RAG É um Problema de Arquitetura, Não de Prompt

Muitos tutoriais de "RAG em 10 minutos" seguem o mesmo formato: carregar uns documentos, dividir em chunks, gerar embeddings, jogar num vector store e escrever um template de prompt. Funciona bem o suficiente como demonstração. Tende a desmoronar no momento em que usuários reais fazem perguntas reais.

O modelo é a parte fácil

No momento em que o contexto recuperado chega ao LLM, a maioria das decisões que determinam a qualidade já foi tomada:

• Estratégia de chunking. Chunks de tamanho fixo são fáceis de implementar e frequentemente errados — separam uma tabela do seu cabeçalho, ou cortam um procedimento na metade, bem antes do passo que importa.
• Escolha do embedding e adequação ao domínio. Um modelo de embedding genérico vai ter desempenho silenciosamente pior em terminologia específica de domínio (contratos jurídicos, prontuários médicos, código interno) comparado a um ajustado ou escolhido para aquele domínio.
• Estratégia de recuperação. Busca por similaridade vetorial pura perde casos de correspondência exata — códigos de produto, mensagens de erro, nomes específicos — que uma busca por palavra-chave ou híbrida pegaria instantaneamente.
• Re-ranking. Os top-k resultados de uma busca vetorial são uma lista de candidatos "provavelmente relevantes", não uma lista de candidatos "de fato relevantes". Pular o re-ranking significa alimentar o modelo com ruído junto do sinal e esperar que ele resolva isso por conta própria.

Nada disso é um problema de prompt. Você pode escrever o prompt mais cuidadosamente projetado do mundo e ele não vai compensar a recuperação dos três parágrafos errados.

Trate como um pipeline de dados, porque é um

Os times que conseguem bons resultados com RAG tendem a tratá-lo como tratariam qualquer outro pipeline de dados: com monitoramento, com conjuntos de avaliação, e com a premissa de que qualquer etapa pode degradar silenciosamente. Na prática, isso significa:

1. Construir um conjunto pequeno e rotulado manualmente de perguntas realistas e os trechos-fonte esperados, antes de escrever um único prompt.
2. Medir a qualidade da recuperação (precisão/recall contra esse conjunto) separadamente da qualidade da geração. Um sistema pode recuperar perfeitamente e ainda gerar uma resposta ruim, ou recuperar mal e ainda ter sorte — você quer saber qual falha está vendo.
3. Reavaliar o pipeline sempre que os documentos subjacentes, o modelo de embedding ou a lógica de chunking mudarem — a mesma disciplina que você aplicaria a uma migração de schema.

A conclusão

Se seu sistema de RAG não está performando bem, o primeiro lugar a olhar não é o system prompt. São as quatro etapas que acontecem antes do modelo ser chamado. Conserte a recuperação, e um prompt mediano vai frequentemente produzir uma boa resposta. Conserte só o prompt, e uma camada de recuperação quebrada ainda vai entregar a informação errada ao modelo — só que formulada de um jeito mais educado.