Desenvolvimento Orientado por Avaliação: A Camada Operacional Que Falta nos Agentes de IA

O cientista de dados que treinava modelos morreu. Koren Gast, da monday.com, publicou o obituário na semana passada. Depois de construir dois produtos agênticos, Monday Magic e Monday Vibe, ela concluiu que model.fit() não é mais o trabalho. O trabalho agora é construir infraestrutura de avaliação.

Ela está certa. Mas a implicação vai além do que ela enquadra.

Gast descreve um novo papel: metodologista de frameworks de avaliação, taxonomias de erro e engenharia de contexto. A equipe dela descobriu que 40% das falhas no agente text-to-app eram erros de geração de parâmetros de ferramentas. Não alucinações. Não falhas de raciocínio. O agente selecionava a ferramenta correta e passava os parâmetros errados. Uma mudança de prompt melhorou a acurácia de seleção de ferramentas em 12%, mas causou uma regressão de 4% na aderência ao schema.

Esse tradeoff é a história. Não dá para otimizar uma dimensão do comportamento de um agente sem degradar outra. E não dá para detectar essas regressões sem infraestrutura de avaliação que meça múltiplas dimensões simultaneamente.

O problema da consistência

Dois dias depois do post de Gast, a ServiceNow publicou o EVA: o primeiro framework de avaliação ponta a ponta para agentes de voz. Oito autores. Vinte sistemas avaliados. Cinquenta cenários de companhia aérea (remarcação, cancelamento, vouchers, lista de espera). Quinze ferramentas no toolkit de avaliação. Três tentativas por cenário.

O framework mede seis dimensões: Conclusão de Tarefa (scoring determinístico), Fidelidade (LLM-as-Judge), Fidelidade de Fala (LALM-as-Judge), Concisão, Progressão da Conversa e Troca de Turnos. Duas métricas-síntese: EVA-A para acurácia, EVA-X para experiência.

Três achados merecem atenção.

Primeiro, agentes que completam tarefas bem entregam experiências piores. O EVA encontrou um tradeoff mensurável entre scores de acurácia e experiência. Um agente que persegue obsessivamente a conclusão da tarefa se torna verborrágico, repetitivo e desagradável. Espelha a observação de Gast sobre o tradeoff 12%/4%. Melhoria numa dimensão causa regressão em outra.

Segundo, a distância entre “consegue fazer” e “faz de fato” é enorme. O EVA usa pass@k (sucesso em pelo menos uma de k tentativas) e pass^k (sucesso em todas as k tentativas). O delta entre pass@3 e pass^3 foi substancial em todos os sistemas testados. Agentes que conseguem completar uma tarefa frequentemente falham em completá-la de forma consistente. Capacidade e confiabilidade são métricas diferentes que exigem infraestrutura de avaliação diferente.

Terceiro, transcrição de entidades nomeadas é o modo de falha dominante em agentes de voz. Um único caractere mal transcrito numa referência de reserva se propaga pela interação inteira. O erro não está no raciocínio. Está na fidelidade da entrada. Nenhuma quantidade de engenharia de prompt corrige um erro de transcrição.

Avaliação como infraestrutura operacional

Como exploramos em O Loop de Governança Escondido no Seu Monitoramento de Agentes, o loop de melhoria em produção de Chase é um framework de governança disfarçado. Filas de anotação são revisão de compliance. Rubrics de avaliação são políticas de controle. Estratégias de amostragem são supervisão baseada em risco.

Gast e o time do EVA estendem essa tese. Avaliação não é uma fase de testes que acontece antes do deploy. É uma disciplina operacional contínua que roda junto com a produção.

Gast descreve a transição explicitamente: cientistas de dados migraram de Python e Jupyter notebooks para codebases em TypeScript e integração com CI/CD. Pipelines de avaliação vivem na mesma infraestrutura que os agentes que avaliam. Golden datasets, avaliadores calibrados (medidos por Cohen’s Kappa para concordância entre anotadores) e guardrails automatizados não são ferramentas de pesquisa. São infraestrutura de produção.

Hamel Husain, citado por Gast, resume: “Times que têm sucesso mal falam sobre ferramentas. Eles são obcecados por medição e iteração.” E mais direto: “Evals são simplesmente data science aplicada a IA.”

A armadilha multidimensional

Aqui é onde a maioria das organizações falha. Constroem avaliação unidimensional: taxa de conclusão de tarefa, ou score de satisfação do usuário, ou latência. Otimizam contra essa métrica única e se perguntam por que a qualidade em produção degrada.

A taxa de 40% de falhas em parâmetros de ferramentas da monday.com era invisível até que construíram taxonomias de erro que classificavam falhas por tipo. Uma métrica única de “acurácia do agente” teria mascarado o padrão inteiramente. Você precisa saber que o agente selecionou a ferramenta certa mas passou parâmetros errados, porque a correção para erros de seleção de ferramenta e erros de geração de parâmetros são intervenções completamente diferentes.

O framework de seis dimensões do EVA torna isso explícito por design. Não dá para avaliar um agente de voz apenas pela conclusão de tarefas, porque um agente que completa todas as tarefas mas leva quinze turnos para isso é inutilizável. Não dá para avaliar apenas pela concisão, porque um agente conciso que falha metade das tarefas é inútil. As dimensões interagem. A avaliação precisa capturar as interações.

Não é complexidade opcional. É a avaliação mínima viável para sistemas de agentes em produção. Como exploramos em Seu Agente Já Sabe o Que Está Errado, o sistema de monitoramento da Factory processa 1.946 sessões diariamente e auto-resolve 73% dos problemas. Essa taxa de resolução depende de classificação granular de falhas. Um sistema que só sabe “sessão falhou” não consegue se auto-curar.

O que Desenvolvimento Orientado por Avaliação realmente exige

A equipe de Gast chegou a uma stack operacional específica. Vale examinar porque representa como uma prática madura de avaliação se parece.

Taxonomias de erro. Não logs de erro. Taxonomias. Classificação estruturada de modos de falha que possibilita detecção de padrões. A taxonomia da monday.com revelou o problema dos 40% em parâmetros de ferramentas. Sem ela, essas falhas eram ruído numa taxa de erro agregada.

Métricas multidimensionais. O EVA mede seis dimensões. A monday.com rastreia acurácia de seleção de ferramentas, aderência ao schema e completude de campos de forma independente. O mínimo são três métricas ortogonais para qualquer agente em produção. Conclusão de tarefa, qualidade do output e eficiência operacional.

Detecção de regressão entre dimensões. O padrão melhoria de 12% / regressão de 4% é a norma, não a exceção. Toda mudança num sistema de agentes desloca múltiplas métricas. Você precisa de detecção automatizada de regressões entre dimensões, ou vai colocar em produção melhorias que são negativas no saldo final.

Avaliadores calibrados. Avaliação por LLM-as-judge funciona, como cobrimos na análise do loop de governança, alcançando aproximadamente 85% de alinhamento com julgamento humano. Mas o juiz precisa de calibração. Cohen’s Kappa mede se seus avaliadores (humanos ou automatizados) concordam entre si. Sem calibração, sua infraestrutura de avaliação produz scores confiantes mas não confiáveis.

Golden datasets. Conjuntos curados de entradas com saídas corretas conhecidas. Não dados sintéticos. Casos reais de produção, anotados por especialistas de domínio, versionados junto com o código do agente. Quando uma mudança de prompt melhora seleção de ferramentas em 12%, você precisa de um golden dataset para detectar a regressão de 4% em aderência ao schema antes que chegue à produção.

A mudança organizacional

Aqui está a parte desconfortável. Desenvolvimento Orientado por Avaliação não é uma prática técnica. É uma prática organizacional.

Gast descreve cientistas de dados migrando para codebases TypeScript. Não é preferência de linguagem. É uma fronteira organizacional se dissolvendo. Quando a avaliação vive em Jupyter notebooks mantidos por um time de pesquisa, é um checkpoint. Quando a avaliação vive em pipelines de CI/CD mantidos pela organização de engenharia, é infraestrutura.

A mesma transição se aplica às métricas. A taxa de 3% de falhas da monday.com em omissão de campos obrigatórios em saídas estruturadas é uma métrica de qualidade do produto, não de qualidade do modelo. Pertence ao dashboard do time de produto, não ao log de pesquisa do time de ML.

O framework EVA da ServiceNow torna isso ainda mais explícito. Avaliar agentes de voz requer expertise em linguística (Fidelidade de Fala), UX (Progressão da Conversa, Troca de Turnos), domínio (Conclusão de Tarefa, Fidelidade) e sistemas (medição de consistência via pass@k vs pass^k). Nenhum time isolado possui todas essas disciplinas.

Desenvolvimento Orientado por Avaliação exige propriedade cross-funcional da infraestrutura de avaliação. Engenharia constrói os pipelines. Produto define as métricas. Especialistas de domínio curam os golden datasets. Operações monitora as regressões. É a mesma estrutura cross-funcional que identificamos no loop de governança de Chase, aplicada especificamente à avaliação.

O custo de não construir isso

Organizações que pulam infraestrutura de avaliação não economizam dinheiro. Adiam o custo para incidentes em produção.

A taxa de 40% de erro em parâmetros da monday.com existia antes de terem a taxonomia para enxergá-la. Esses erros estavam chegando aos usuários. A infraestrutura de avaliação não criou o problema. Revelou o problema que já estava custando caro.

A lacuna de consistência do EVA (pass@3 vs pass^3) significa que agentes com qualidade de demo — que funcionam quando você testa — falham de forma imprevisível em produção. Sem medição de consistência, você coloca em produção agentes que passam nos testes e falham no deploy. O cliente descobre o problema de confiabilidade. Você descobre na fila de suporte.

A regressão de 4% em aderência ao schema da mudança de prompt da monday.com teria ido para produção sem avaliação multidimensional detectando. Quatro por cento parece pouco. Ao longo de milhões de interações, são milhares de outputs quebrados por dia.

Onde isso converge

Monitoramento diz o que aconteceu. Governança diz o que deveria acontecer. Avaliação diz se o que aconteceu corresponde ao que deveria ter acontecido.

Essas três disciplinas estão convergindo numa camada operacional única. O loop de melhoria em produção de Chase é o esqueleto de governança. O monitoramento auto-curativo da Factory é a camada de automação. A metodologia de avaliação de Gast e o framework EVA da ServiceNow são a disciplina de medição.

As organizações que constroem as três como infraestrutura integrada vão operar agentes que melhoram ao longo do tempo. As que tratam avaliação como fase de testes pré-deploy vão operar agentes que degradam ao longo do tempo — porque condições de produção mudam e avaliação que não roda continuamente não consegue detectar a mudança.

As ferramentas existem. Os frameworks existem. A questão é se avaliação recebe o mesmo investimento organizacional que os agentes que ela mede.

Fontes

Gast, K. “The Death of Model Fit: What Data Scientists Actually Do in the Age of AI Agents” monday.com Engineering. Março 2026.
ServiceNow AI. “EVA: A Framework for Evaluating Voice Agents” HuggingFace. Março 2026.

Victorino Group constrói infraestrutura de avaliação para operações de agentes de IA empresariais: contato@victorino.com.br | www.victorino.com.br