Produtos de IA confiáveis exigem evals, guardrails e orquestração

O problema: uma árvore de oportunidades sem hierarquia

Uma cliente beta do Vistaly, ao revisar sua opportunity solution tree gerada por IA, comentou que gostaria de poder clicar e "limpar" uma ramificação cheia de oportunidades planas, sem subgrupos. Teresa Torres, que desde fevereiro ajuda o Vistaly a construir snapshots de entrevistas e árvores de oportunidades geradas por IA, decidiu não criar um botão de correção, e sim atacar a causa raiz: por que o agente não adicionava estrutura àquela ramificação?

Responder à pergunta tomou três semanas, quatro evals novos e 16 variantes de experimentos. O argumento central do texto é que síntese de alta qualidade exige esse nível de detalhe - e que você pode pedir ao Claude ou ChatGPT para gerar uma árvore a partir de transcrições, mas torná-la realmente acionável exige refinar cada categoria de erro.

Medindo o erro com evals

Torres partiu de duas abordagens de medição. A primeira, chamada tree-shape, é um eval de asserção de código: conta o número total de oportunidades, filhos por nó, profundidade e distribuição, permitindo comparar contra regras práticas (três a sete key moments por árvore, largura que se estabiliza, profundidade que cresce com novas entrevistas).

A segunda, o eval de missed-groupings, usa LLM-as-a-Judge: um segundo call de LLM avalia se cada nó pai está perdendo um subagrupamento. Para confiar no juiz, Torres criou um conjunto de calibração rotulado manualmente e mediu duas métricas: recall (acerto quando há erro) e especificidade (acerto quando não há erro). O recall chegou a 100%, mas a especificidade ficou em 43,75% - o juiz apontava erros inexistentes. Após sete iterações (instruções simplificadas, mais exemplos, modelo mais capaz), a especificidade só alcançou 60%.

Erros upstream contamina o juiz

Analisando os falso positivos, ela percebeu que o juiz se confundia com erros upstream: key moments mal formulados (compostos, com motivo de um único cliente, verbosos) e oportunidades que apenas repetiam o pai sem acrescentar nada. Hamel, do curso de evals dela, insistiu que erros upstream devem ser tratados primeiro - mas Torres hesitava, porque os clientes não reclamavam desses erros, e temia que eles nunca chegassem a zero.

Ela criou então dois novos evals LLM-as-a-Judge para medir essas duas categorias, com rotulação manual auxiliada por Claude para explicitar regras intuitivas. Sua estratégia: rodar os nós pelos dois novos evals e só mandar ao juiz de missed-groupings os nós limpos dos erros upstream.

Juizes calibrados falham em produção

Ao rodar a primeira variante de prompt (regras de agrupamento derivadas de cerca de 40 exemplos rotulados), os dois novos juízes reportaram mais de 90% de taxa de erro em todos os nós - eram juízes calibrados que não sobreviveram a dados reais de produção. Torres recalibrou os conjuntos e prompts até alcançar 100%/93% e 90%/100% (recall/especificidade).

As variantes seguintes revelaram um dilema persistente: ensinar o agente a criar subgrupos gerava pais mal formulados; ensinar a formular pais bem o tornava relutante em criar novos. A troca para Sonnet 5 no lugar do Sonnet 4.6 não resolveu: ele criava quase nenhum nó novo (um pai de nível médio onde o 4.6 criava seis ou onze), então o baixo erro vinha de não fazer o trabalho, não de fazê-lo melhor.

Das variantes 8 a 13, acumularam-se ganhos (parent-restaters caíram cerca de 70%, CKMs mal formulados 54%), mas os missed groupings seguiam altos. Uma pausa para otimização de custos trouxe um insight: os pais mal formulados vinham quase todos de árvores novas, e um prompt antigo de geração era o culpado - mas corrigi-lo piorou os missed groupings.

Orquestração e guardrails: o loop que funcionou

Esgotada a via de prompts, Torres mudou de orquestração. O agente já trabalhava em etapas (key moments, agrupamento, estrutura de ramificações) e usava uma ferramenta de auditoria determinística para checar o próprio trabalho e corrigir erros. Ela reaproveitou essa infraestrutura: o auditor passou a usar tree-shape - código determinístico, sem custo extra de LLM - como guardrail para detectar pais com filhos demais, e os prompts foram otimizados para pais bem formulados. O agente então corrigia os agrupamentos faltantes, agora com pais bem escritos.

Ambos os erros caíram pela primeira vez, mas surgiu o problema inverso: pais com um só filho, corrigido em duas iterações. A variante 16, considerada vencedora, mostrou redução de 78% em parent-restaters, 29% em CKMs mal formulados e aumento de 65% em pais de nível médio.

Lições

Torres destaca três aprendizados: conjuntos de calibração podem falhar contra dados de produção; a recomendação de tratar erros upstream primeiro estava certa, mas corrigi-los exacerbava o erro-alvo, e o que importava era medir todas as categorias simultaneamente; e produtos de IA confiáveis exigem a combinação de engenharia de prompt, engenharia de contexto, orquestração e guardrails, sobretudo quando as categorias de erro estão entrelaçadas. A cliente que reclamou verá novos subgrupos na próxima revisão - estrutura real, não pais que apenas repetem os filhos.