[PT-BR] IA para Produção: meu agente não estava falhando, minha arquitetura estava

Quando comecei a desenvolver a Build Your Training (BYT), eu já tinha estudado bastante sobre IA, agentes e todo o ecossistema em volta.

Mesmo assim, cometi o erro que mais vejo acontecer.

O agente não entregava o que eu esperava. Pior: a mesma entrada gerava respostas diferentes.

A primeira conclusão foi a mais óbvia. "O problema é o modelo."

Troquei de modelo. Testei outro. Depois outro.

O resultado? Praticamente o mesmo.

Este artigo é a versão longa da série IA para Produção que venho publicando no LinkedIn. A ideia aqui é mostrar, com mais detalhe, a arquitetura que hoje roda em produção na BYT, com usuários reais, e os erros que cometi até chegar nela.

Menos hype. Mais engenharia.

O problema não era o modelo

Em uma aplicação Java tradicional, a mesma entrada deveria produzir o mesmo resultado. Se não produz, é bug.

Com LLMs, não necessariamente. A saída é probabilística. Você pode (e deve) reduzir a variação, mas não vai eliminá-la só trocando de modelo.

Foi aí que mudei a pergunta. Em vez de "qual modelo é melhor?", passei a perguntar:

• O contexto que o agente recebe é suficiente?
• As responsabilidades estão bem divididas?
• Existe validação da saída?
• Existe avaliação da qualidade?
• O que acontece quando tudo isso falha?

Cada uma dessas perguntas virou uma peça da arquitetura.

A arquitetura

Simplificando bastante, o fluxo de geração de um treino na BYT é este:

 Dados do aluno
       |
       v
 [Agente Gerador] <-----------------+
       |                            |
       v                            | feedback
 [Guardrails de formato]            |
       |                            |
       v                            |
 [Agente Juiz] -- REPROVADO --------+  (até 3 tentativas)
       |
       +-- APROVADO ----------------> entrega ao aluno
       +-- APROVADO COM RESSALVAS --> entrega ao aluno
       |
       +-- 3ª reprovação ----------> humano (eu, via WhatsApp)

Quatro ideias sustentam esse desenho.

1. Separar quem cria de quem avalia

Um agente cria o treino. Outro avalia.

Esse padrão tem nome: LLM as a Judge. Um modelo avaliando a saída de outro.

Parece estranho no começo. Mas faz sentido quando você pensa em IA como um sistema distribuído de responsabilidades. Você não pede para o mesmo serviço que escreve um dado validar esse dado. Por que pediria isso a um único prompt?

O juiz tem três vereditos possíveis:

• Aprovado: o treino respeita as regras.
• Aprovado com ressalvas: o treino é válido, mas existe um ponto de atenção real (por exemplo, uma lesão informada pelo aluno).
• Reprovado: há erro relevante ou possível alucinação. O feedback volta para o gerador.

2. Guardrails antes do juiz

Nem tudo precisa de um LLM para ser validado.

Se o próximo componente espera uma estrutura específica, isso é verificável de forma determinística. Formato errado não chega no juiz. Volta direto.

É a mesma lógica de validar o payload antes de chamar a regra de negócio. Barato, rápido e previsível.

Não basta pedir para a IA fazer algo corretamente. Precisamos construir mecanismos para verificar se ela realmente fez.

3. Retry com limite

Quando o juiz reprova, o gerador recebe o feedback e produz uma nova versão. Nova versão, nova avaliação.

Mas retry infinito não é estratégia. É custo e latência sem garantia de resultado.

Na BYT, o limite é 3 tentativas.

4. Human in the loop como dead letter queue

Se o treino for reprovado pela terceira vez, o sistema para de insistir e eu recebo uma mensagem no WhatsApp.

Quem trabalha com mensageria conhece esse padrão. Retry com limite. Depois, dead letter queue.

Na BYT, a dead letter queue sou eu.

Human in the loop não é admitir que a IA falhou. É decidir, com clareza, onde a automação deve parar.

O que deu errado no caminho

A primeira versão do juiz tinha um problema que eu demorei para enxergar.

Quase todo treino saía "aprovado com ressalvas". Aluno com lesão? Com ressalvas. Aluno sem lesão nenhuma? Com ressalvas também.

O juiz não estava errado. Só não estava dizendo nada.

Um juiz que ressalva tudo é igual a um alerta que dispara o tempo todo. Depois de uma semana, ninguém mais olha.

Foram alguns ciclos de ajuste. E não fiz isso sozinho: fiz junto com o profissional de educação física da BYT. Ele analisava os vereditos e apontava onde a ressalva fazia sentido e onde não fazia. Eu ajustava os critérios e rodava de novo.

O objetivo era assertividade: ressalva quando existe um motivo real, aprovação limpa quando o treino está dentro das regras.

Duas lições:

• Avaliar a saída não basta. Você precisa avaliar o avaliador.
• A IA não sabe sozinha o que é um bom resultado no seu domínio. Quem sabe é o especialista. O papel da engenharia é transformar esse conhecimento em critério.

Observabilidade

Nada disso funcionaria sem visibilidade.

Hoje, o fluxo inteiro da BYT é acompanhado no Langfuse: cada geração, cada veredito, cada retry. É de lá que vêm as respostas para perguntas como "o juiz está ressalvando demais?" ou "quantos treinos precisam de segunda tentativa?".

Esse tema merece um artigo próprio. Fica para o próximo.

Conclusão

O modelo nunca foi o principal problema. A arquitetura era.

Modelos importam. Mas contexto, validação, avaliação e arquitetura costumam importar muito mais. É isso que transforma uma demo em um produto.

Antes de trocar de modelo, pergunte:

• O contexto está adequado?
• As responsabilidades estão bem divididas?
• Existem guardrails?
• Existe avaliação da saída e de quem avalia?
• Existe um caminho claro para quando tudo falhar?

Se a resposta para alguma delas for "não", você ainda não está avaliando o modelo. Está avaliando a implementação.

Este artigo faz parte da série **IA para Produção. Os posts curtos estão no meu LinkedIn.

E você: como está validando os seus agentes em produção?