IA em produção: RAG, eval e prompt injection

Existe um padrão previsível em projetos de IA: a demo funciona em duas semanas, e o produto não sai em seis meses.

Não é falta de capacidade técnica. É que a demo e o produto exigem coisas diferentes, e as três coisas que o produto exige são justamente as menos glamourosas.

Primeira: recuperação que funciona#

Quando um RAG responde errado, o instinto do time é trocar de modelo. Na esmagadora maioria dos casos, o problema não é o modelo: é a recuperação.

Se o trecho certo não entrou no contexto, nenhum modelo salva.

As causas, em ordem de frequência:

Chunking ruim. Você quebrou por número fixo de caracteres e cortou a tabela no meio, ou separou a pergunta da resposta. Quebre por estrutura (seção, parágrafo) com alguma sobreposição. E guarde o título da seção junto com o pedaço, porque o contexto do título é frequentemente o que torna o trecho compreensível.

Busca só semântica. Embedding é ruim com código de produto, número de nota fiscal, nome próprio e negação: "com juros" e "sem juros" ficam próximos porque os textos são quase idênticos.

Busca híbrida (vetorial mais BM25) é a mudança de maior impacto que existe em RAG. Quase sempre ganha de qualquer uma sozinha, e é barata de implementar.

Falta de reordenação. Recupere vinte candidatos e passe por um reranker, um modelo menor treinado especificamente para ordenar relevância. Melhora muito e custa pouco.

Falta de metadado. Sem filtro por data, produto ou permissão, você recupera o documento revogado de 2019. E, pior, você pode recuperar um documento que aquele usuário não tinha direito de ver, o que é um vazamento com cara de funcionalidade.

O diagnóstico que economiza semanas#

Quando a resposta vier errada, olhe primeiro o que foi recuperado.

Se o trecho certo não estava lá → é recuperação.

Se estava e o modelo ignorou → é prompt ou modelo.

Duas situações completamente diferentes, com soluções completamente diferentes. Sem separar as duas, você fica meses ajustando prompt para um problema de busca.

Segunda: avaliação#

Esta é a disciplina que separa produto de demo, e é a que quase ninguém faz.

A pergunta é simples: você consegue responder, com número, se a mudança que acabou de fazer melhorou ou piorou?

Se a resposta for "testei três perguntas na mão e pareceu melhor", você está ajustando no escuro.

Avaliar IA é diferente de testar software. Não existe passa/falha determinístico: existe uma distribuição de qualidade medida numa amostra.

Como começar, e é mais simples do que parece:

Você precisa de um conjunto de casos. Vinte já muda a sua vida. Cem é confortável.

De onde tirar: dos logs reais, se você tem tráfego; dos casos que deram errado, que são os mais valiosos; e das perguntas que o suporte recebe. Não invente casos sintéticos bonitos: eles não se parecem com o que os usuários fazem.

Os tipos de verificação, do mais barato ao mais caro:

Determinístico. A resposta contém o número certo? O JSON é válido? O id existe na base? Sempre que der para verificar com código, verifique com código: é grátis, rápido e não erra.

Comparação com referência. Quando existe resposta esperada. Para texto livre, use similaridade semântica em vez de igualdade literal.

Juiz por modelo. Quando o critério é subjetivo.

Humano. Caro, e insubstituível numa amostra pequena para calibrar os outros.

E o processo: toda mudança de prompt, de modelo ou de recuperação roda contra o conjunto, e você compara antes e depois. É o equivalente do CI para IA.

Usando LLM como juiz, sem se enganar#

Funciona, com cuidados que mudam o resultado.

Critério específico e escala pequena. "A resposta está fundamentada apenas no contexto fornecido? Sim ou não" funciona muito melhor que "dê uma nota de 0 a 10". Notas contínuas ficam todas em sete ou oito.

Peça a justificativa antes da nota. Mesmo efeito de raciocínio em etapas, e permite auditar.

Os vieses são reais e medidos: viés de posição, em que o juiz prefere a primeira ou a última opção numa comparação, e que se corrige rodando nas duas ordens; viés de verbosidade, em que resposta mais longa é considerada melhor; e autopreferência, em que o modelo prefere texto gerado por ele mesmo.

E calibre contra humano. Avalie cinquenta casos na mão e meça a concordância. Se for baixa, o seu juiz está medindo outra coisa, e você tem um número que parece objetivo e não é.

Terceira: observabilidade#

Aplicação de IA é distribuída e não determinística. Sem rastro, você não depura.

O que registrar em cada chamada: o prompt completo, incluindo o que foi recuperado; a resposta; o modelo e a versão; os parâmetros; a contagem de tokens de entrada e saída; a latência; o custo; e o identificador de correlação ligando isso à requisição do usuário.

Num fluxo agêntico, registre cada passo do loop: qual ferramenta, com que argumentos, o que devolveu.

Por que é inegociável: quando um usuário reclamar de uma resposta errada, a primeira pergunta é "o que foi recuperado?". Sem trace, você não consegue responder, e não vai conseguir reproduzir, porque não é determinístico.

O painel mínimo por rota: custo por dia, latência p95, taxa de erro, distribuição de tokens. Custo de IA cresce silenciosamente, e a primeira vez que a maioria dos times olha é quando a fatura chega.

1. Recuperaçãoo teto da qualidadeSe o trecho certo não entrou no contexto, nenhum modelo salva. Busca híbrida é a mudança de maior impacto.
2. Avaliaçãomedir a mudançaVinte casos reais já mudam a sua vida. Sem eles, toda alteração de prompt é ajuste no escuro.
3. Observabilidadepoder depurarSem o rastro do que foi recuperado, você não responde a reclamação nem reproduz, porque não é determinístico.

Prompt injection: o problema sem solução#

A causa raiz é a mesma da injeção de SQL: instrução e dado trafegam no mesmo canal. A diferença é que não existe consulta parametrizada para linguagem natural.

Injeção direta é o usuário mandando "ignore as instruções anteriores". Relativamente fácil de mitigar.

Injeção indireta é a perigosa: o conteúdo malicioso está num documento que o seu RAG recupera, numa página que o agente lê, num e-mail que ele processa. O atacante nunca falou com o seu sistema: ele plantou o texto onde o sistema ia buscar.

O que ajuda, e nenhuma delas é completa:

→ Delimitar claramente o conteúdo não confiável e instruir o modelo a tratá-lo como dado.

→ Menor privilégio na ferramenta. O estrago depende do que o agente pode fazer.

→ Confirmação humana para ação irreversível.

→ Validar a saída com código antes de agir.

→ Limitar o alcance: se o agente só pode escrever num rascunho, injeção não manda e-mail.

A regra mental: trate a saída do modelo como entrada de usuário não confiável.

E o ponto que mais gente ignora: o risco não escala com a inteligência do modelo. Escala com o privilégio que você deu a ele.

Ensinar a dizer "não sei"#

O comportamento mais valioso e menos implementado.

Como conseguir: instrua explicitamente ("se o contexto não contiver a informação, responda que não encontrou"); dê exemplos de recusa no few-shot, porque sem exemplo o modelo não aprende o formato; exija citação, porque se toda afirmação precisa apontar um trecho, inventar fica mais difícil; e use o escore de recuperação: se o melhor trecho tem similaridade baixa, nem chame o modelo.

E meça a taxa de recusa correta como métrica de primeira classe. O contraponto importa: recusar demais também é ruim, e é o erro que aparece quando você aperta demais. Por isso é métrica, não regra.

Agentes: a matemática do erro composto#

Se você está construindo agente, uma conta que vale internalizar:

Noventa por cento de acerto por passo, em dez passos, dá trinta e cinco por cento de acerto no fim.

Agente longo é frágil por matemática, não por implementação ruim. As mitigações: menos passos, verificação determinística entre eles, limite de iterações, e checkpoint humano nos pontos caros.

E sobre multi-agente, uma honestidade: na maior parte dos casos, um agente bem instrumentado com boas ferramentas ganha de uma orquestra. Multi-agente compensa quando as subtarefas são genuinamente independentes, ou quando você quer perspectivas diferentes de propósito, como um crítico revisando um autor.

O que fazer nesta semana#

Um exercício concreto e pequeno:

Monte vinte perguntas reais do seu domínio, com a resposta certa e o documento certo anotados. Rode o seu sistema e meça quantas vezes o documento certo apareceu entre os recuperados.

Esse número é o teto da sua qualidade. Nenhum ajuste de prompt passa dele.

E você vai descobrir, na maioria dos casos, que o problema nunca foi o modelo.