Avaliação antes da orquestração: construa a prova, depois a complexidade

Um framework de avaliação de IA deve vir antes da orquestração, não depois. A versão mínima útil é simples: defina a tarefa, monte um eval set, avalie as saídas com uma rubrica, inspecione traces de múltiplas etapas quando necessário e bloqueie o release quando a qualidade cai.

Essa é a diferença entre um sistema que parece competente numa demo e um que sobrevive às mudanças da produção. Se você orquestra antes de avaliar, cada novo router, ferramenta, retry ou handoff torna o modo de falha mais difícil de enxergar e mais difícil de corrigir.

Orquestração parece progresso porque torna o sistema mais competente na aparência. Na prática, ela costuma acumular incerteza:

• uma etapa de roteamento muda a distribuição de prompts
• uma chamada de ferramenta corrige um modo de falha e introduz outro
• uma política de retry aumenta latência e custo em silêncio
• um caminho de fallback esconde uma regressão que os usuários ainda sentem

É por isso que a sequência melhor é prova primeiro, complexidade depois. A própria orientação de evals da OpenAI segue esse loop: defina a tarefa, rode exemplos representativos, inspecione as falhas e itere antes de expandir o sistema (guia de evals da OpenAI).

Você não precisa de uma plataforma grande para começar. Precisa de um loop repetível que responda cinco perguntas:

1. Qual é a tarefa?
2. Como é o "bom"?
3. Como detectamos a falha?
4. O que bloqueia o release?
5. O que acompanhamos depois do lançamento?

Comece com um conjunto pequeno de exemplos que reflita a distribuição real do trabalho, e não só os caminhos felizes.

Inclua:

• casos comuns
• casos de borda
• casos negativos
• entradas adversariais ou bagunçadas
• exemplos que já causaram regressões no passado

Em muitos times, 25 a 50 exemplos bem escolhidos bastam para expor os maiores problemas antes de um rollout mais amplo.

Uma rubrica deve ser específica o suficiente para que dois revisores cheguem a conclusões parecidas. "Parece bom" não é rubrica.

Dimensões típicas de avaliação incluem:

• correção
• completude
• grounding
• conformidade com políticas
• acionabilidade
• tom ou formatação, quando importam para a tarefa

Se a saída deveria extrair campos, defina o que conta como ausente, errado ou parcialmente correto. Se a saída deveria recomendar uma ação, defina o que torna a ação segura o suficiente para ser aceita.

Avaliar só a saída final deixa de ser suficiente quando o workflow tem várias etapas. Uma resposta final pode parecer errada escondendo onde o erro começou.

É aí que trace grading importa. Em vez de perguntar só "a resposta ficou boa?", você inspeciona também:

• seleção de ferramentas
• argumentos das ferramentas
• qualidade do retrieval
• comportamento de fallback
• recuperação de erros
• comportamento de parada

A escrita recente da LangChain sobre avaliação de agentes e inspeção de traces aponta na mesma direção: sistemas de múltiplas etapas precisam de visibilidade do comportamento intermediário, não só do texto final (blog da LangChain).

Mantenha a taxonomia pequena o bastante para ser usada na prática:

• interpretação errada da tarefa
• falha de retrieval
• uso errado de ferramentas
• violação de política
• falha de latência ou timeout
• ação insegura ou de baixa confiança

Se você não consegue rotular as falhas recorrentes de forma consistente, também não consegue melhorá-las de forma consistente.

Evals offline comparam versões de forma controlada. Evals online dizem se a realidade concorda depois que o workflow está no ar.

Evals offline devem acontecer antes do lançamento. A observação online deve continuar depois do lançamento, via logs, traces, revisão dos operadores e monitoramento de impacto em usuários.

Um gate de release só é útil se alguém for dono dele.

Defina:

• quem aprova uma mudança
• quais métricas ou notas podem bloquear o release
• quando um override temporário é permitido
• qual trabalho de follow-up é obrigatório depois de um override

É aqui que a avaliação vira modelo operacional, e não exercício de notebook. O NIST AI Risk Management Framework ajuda porque enquadra medição e governança como parte da disciplina de deploy, e não como um pensamento tardio (NIST AI RMF).

Rode primeiro este checklist:

• A definição da tarefa é específica o bastante para ser avaliada?
• O eval set inclui casos de falha conhecidos?
• Os revisores concordam com a rubrica?
• Você consegue explicar as principais categorias de falha?
• Você conhece a linha de base de latência e custo?
• Ações de alto risco estão protegidas por política ou revisão humana?
• A nova etapa resolve um problema medido, ou só faz o sistema parecer mais esperto?

Se várias dessas ainda estão vagas, mais uma camada de orquestração provavelmente vai esconder o problema em vez de resolvê-lo.

Mantenha o scorecard operacional enxuto:

• sucesso da tarefa
• duas principais categorias de falha
• contagem de saídas inseguras
• latência p95
• custo por execução bem-sucedida
• taxa de override humano

Esse scorecard basta para sustentar discussões de mudança, revisões de release e follow-up pós-incidente. Ele também emenda diretamente com a camada de controle de produção discutida em agentes de IA em produção.

E se a escolha for entre retrieval, ferramentas e padrões procedurais, a lente certa é a de quando RAG é a resposta errada. Se o workflow já caminha para autonomia, o próximo passo é a camada de controle do agente — não mais orquestração por orquestração.