Nesta página
Uma resposta sobre a devolução de um pedido parece pronta para envio: gramaticalmente correta, cordial e curta. Neste caso ilustrativo, uma avaliação automática dá nota máxima. O assistente também diz ao cliente que o reembolso foi emitido, embora ninguém tenha consultado o sistema de pagamentos.
O problema não é a frase. É uma definição fraca de bom.
Em uma demonstração de avaliação, uma equipe cria notas para um agente que escreve documentação de software. O momento interessante ocorre quando quem conhece o trabalho descreve o significado de qualidade e uma ferramenta transforma essa descrição em critérios. Mais tarde, uma nota baixa provoca a dúvida certa: talvez o agente precise de correção, ou talvez a avaliação precise.
A rubrica é uma teoria sobre a tarefa. Teste a teoria.
Comece pelo erro que invalida tudo
As equipes costumam começar por dimensões fáceis de pontuar: clareza, tom, estrutura, completude. Elas são úteis, mas raramente bastam.
Para a resposta ilustrativa sobre o reembolso, “nunca afirmar que o reembolso foi concluído sem um comprovante de pagamento” está acima da qualidade da redação. Para uma sincronização de dados, “não mapear o e-mail de cobrança para o e-mail da pessoa titular da conta” importa mais do que uma boa explicação do mapeamento.
Peça a quem domina a tarefa três tipos de caso: um claramente bom, um claramente errado e um sobre o qual pessoas informadas possam discordar. Guarde os registros de origem e o motivo de cada julgamento. Se um caso depende de uma regra que pode mudar, versione a regra junto com o rótulo.
A primeira rodada pode ser pequena. Não pode ser vaga.
- Responsável pela tarefa
casos bons, ruins e disputados
- Verificações exatas identidade · permissão · destino
código verifica fatos
- Rubrica semântica
julgar só o que exige interpretação
- Revisão de divergências
corrigir rótulos e critérios
| Verificação | Melhor responsável | Por quê |
|---|---|---|
| Existe a permissão necessária | Código e registros oficiais | O fato é exato e tem consequências |
| ID no destino corresponde à identidade de origem | Código e registro de teste | Um modelo não deve adivinhar identificadores |
| A resposta atende à pergunta do cliente | Rubrica revista por humanos, possivelmente com modelo julgador | O significado exige interpretação |
| O tom se ajusta à situação | Rubrica revista por humanos, possivelmente com modelo julgador | Há mais de uma forma aceitável |
Nosso guia sobre IA em fluxos de trabalho existentes ajuda a separar decisões que exigem interpretação de verificações operacionais. Aqui a fronteira é específica: o código copia valores originais e confere restrições depois de uma escolha semântica. A confiança do modelo não concede permissão.
A nota herda os pontos cegos da rubrica
A objeção é justa: “Uma pessoa não consegue revisar cada execução do agente. Precisamos de um avaliador escalável.” Sim. A pergunta é o que ele está ampliando.
Se a rubrica recompensa uma resposta polida e nunca verifica se o pedido foi mesmo reembolsado, a automação amplia a omissão. Um número com duas casas decimais parece preciso, mas pode medir a coisa errada.
A documentação do Google Cloud sobre avaliação de julgadores descreve uma verificação prática: prepare casos com notas humanas, execute a métrica baseada em modelo e compare as notas. O ponto não é que a opinião de uma pessoa seja infalível. É que o modelo precisa de um padrão externo antes que sua nota tenha peso.
Examine divergências, não apenas a concordância média. Se o julgador aprova uma resposta rejeitada pela liderança do atendimento, pergunte qual critério está faltando. Se duas pessoas especialistas discordam, mantenha os dois rótulos e encontre a regra interpretada de maneiras diferentes. Não apague a disputa por meio de uma média.
A seleção dos casos importa tanto quanto a redação do critério. Uma coleção de sucessos rotineiros pode fazer o julgador parecer confiável enquanto os casos difíceis ficam de fora. Inclua registros incompletos, instruções conflitantes e casos em que a resposta correta é parar e perguntar. Reserve também casos que não foram usados para ajustar a rubrica, para que uma mudança que melhore os exemplos conhecidos precise se provar em outros. Quando a regra de negócio mudar, atualize rótulos e resultados esperados; um conjunto de testes congelado pode recompensar a política de ontem.
Mantenha o resultado ligado à avaliação
Uma rubrica para um agente de sincronização deve acompanhar o resultado do cliente. O contato certo mudou? O consentimento foi respeitado? Um registro que falhou pode ser reprocessado sem repetir uma ação importante?
O guia do conector Brevo explica por que uma chamada de API bem-sucedida pode coexistir com um atributo ausente. Uma avaliação que confere apenas se o agente chamou o endpoint perde o resultado. Uma que confere apenas o destino pode ignorar um caminho proibido que, por acaso, terminou com o valor certo. Ambos importam quando o caminho traz risco.
Comece por uma tarefa restrita e alguns modos de falha. Rotule os casos com quem responde pela tarefa. Coloque verificações exatas em código e use um modelo julgador apenas quando linguagem ou julgamento realmente exigirem. Repita os casos depois de mudar prompt, modelo ou ferramenta. Registre o que as falhas posteriores revelam sobre a rubrica.
O custo é o tempo das pessoas especialistas no início. O ganho é que cada nota posterior tem um significado que alguém consegue defender.
Um painel pode mostrar uma nota. Só a rubrica diz o que foi contado.
Perguntas frequentes
Quem deve definir os critérios de avaliação de um agente de IA?
As pessoas que conhecem a tarefa e suas consequências devem definir os resultados aceitáveis e os erros que os invalidam. A engenharia pode transformar esses julgamentos em verificações repetíveis e avaliar se um modelo julgador concorda com as notas humanas.
Uma nota alta do julgador prova que o agente funciona?
Não. A nota mede a concordância com a rubrica nos casos testados. Uma rubrica fraca, casos não representativos ou um julgador mal calibrado podem dar nota alta a um resultado prejudicial.
O que deve ser verificado por código, em vez de por um modelo julgador?
Permissões exatas, identificadores de registros, chamadas obrigatórias de ferramentas e o estado no destino devem ser verificados por código sempre que possível. O modelo julgador serve para qualidades semânticas que regras exatas não resolvem.