Da demonstração à produção: um guia prático para sistemas RAG

A geração aumentada por recuperação (RAG) é a forma mais rápida de tornar um modelo de linguagem útil sobre os seus próprios dados: recupera documentos relevantes, coloca-os no prompt e deixa o modelo responder com contexto fundamentado. A demonstração é genuinamente fácil. O sistema de produção é onde vive a engenharia.

Eis no que nos focamos quando levamos um protótipo de RAG a algo que pode colocar à frente de clientes.

A qualidade da recuperação é tudo

Se forem recuperados os pedaços errados, nenhuma engenharia de prompt salva a resposta. A maioria dos ganhos acontece antes de o modelo sequer ser chamado:

• Segmentação (chunking): divida em fronteiras semânticas, não em contagens arbitrárias de tokens. Preserve títulos e estrutura.
• Pesquisa híbrida: combine similaridade vetorial densa com pesquisa por palavra-chave (BM25); cada uma apanha o que a outra falha.
• Re-ranking: recupere de forma ampla e depois use um cross-encoder para reordenar os melhores candidatos antes de chegarem ao prompt.

Meça a recuperação por si só, com um conjunto rotulado de perguntas e as passagens que as devem responder. Se o recall da recuperação for baixo, corrija isso primeiro.

Fundamente cada resposta e prove-a

O RAG em produção precisa de mostrar o seu trabalho. Devolvemos citações com cada resposta e, quando o risco é elevado, acrescentamos um passo de verificação que confronta a afirmação gerada com a passagem recuperada. Se o modelo não conseguir sustentar uma afirmação a partir do contexto, deve dizê-lo; uma resposta errada mas confiante é pior do que “não sei”.

Trate-o como um sistema, não como um prompt

As partes que tornam o RAG fiável são pouco glamorosas:

• Arnês de avaliação: um conjunto automatizado de perguntas com comportamento esperado, corrido a cada alteração.
• Observabilidade: registe a pergunta, os pedaços recuperados e a resposta final para conseguir depurar falhas reais.
• Guardrails: validação de entrada, filtragem de saída e limites de taxa.
• Caching e controlo de custos: embeddings e completions somam-se rapidamente à escala.

Onde as equipas encalham

O modo de falha mais comum não é o modelo; é enviar a demonstração e assumir que vai aguentar. O drift instala-se à medida que os documentos mudam, as perguntas se tornam mais adversariais e os casos extremos se acumulam. As equipas que têm sucesso tratam a qualidade da recuperação como uma métrica que monitorizam, não como uma caixa que assinalam uma vez.

Construa o arnês de avaliação antes de construir a funcionalidade, e cada melhoria a partir daí torna-se mensurável em vez de anedótica.