Recentemente, pedi à IA que me ajudasse a aprimorar um post de blog.
Ela escreveu rapidamente. A estrutura estava completa e as ideias eram claras. Quando eu disse que queria que soasse mais profissional, ela acrescentou discussões técnicas. Quando pedi embasamento acadêmico, ela encontrou artigos recentes.
O artigo ficou mais sério, mas comecei a hesitar: será que ele realmente precisava ser escrito assim?
Não havia nada obviamente errado com o conteúdo. Mas o que eu queria escrever era um texto com a minha própria voz, que permitisse aos leitores ver como eu pensava sobre um problema. Depois de várias rodadas de revisão, ele estava gradualmente se tornando uma revisão de pesquisa que eu mesmo precisaria de tempo para digerir.
Minhas expectativas também foram mudando ao longo do caminho. No início, eu não tinha definido completamente o que “profissional” ou “aprofundado” deveria significar para este artigo em particular.
Essa experiência me fez repensar o que faz um bom agente.
Se eu verificasse os requisitos um a um, nossa colaboração teria realizado bastante coisa: o artigo foi escrito, a pesquisa foi feita e as referências estavam no lugar. Cada pedido individual tinha um entregável correspondente.
Mas, ao juntá-los, eu ainda precisava perguntar: é este o artigo que quero publicar?
É fácil verificar o que um agente fez. Explicar se essas ações aproximaram o usuário do seu objetivo dá mais trabalho.
Neste caso, “adicionar embasamento acadêmico” foi um pedido explícito. Seu propósito era tornar o argumento mais crível. Se adicionar pesquisa fizesse o artigo perder sua voz original, precisaríamos reconsiderar como usar esse material.
Um novo pedido do usuário nem sempre é algo para simplesmente acrescentar por cima. Pode ser uma correção de direção, ou até um motivo para remover trabalho que já foi concluído.
Para um agente que permanece envolvido em uma tarefa, compreender essas mudanças afeta a qualidade de toda a colaboração. Ele precisa revisar sua compreensão da tarefa à medida que o feedback chega, em vez de continuamente acrescentar mais ao resultado.
Isso também torna o “concluído” mais complicado. O artigo pode ter um final, e a tarefa pode ser marcada como completa, enquanto o usuário ainda não tem algo que possa usar.
Então, antes de projetar uma avaliação, quero esclarecer outra coisa: que julgamento estamos tentando fazer a partir dos resultados?
Verificar a precisão factual significa validar citações e evidências de apoio. Avaliar a capacidade de revisão significa observar se o agente entende o feedback e preserva o conteúdo que ainda funciona. Julgar se ele consegue assumir uma tarefa do início ao fim também significa olhar quanto trabalho ele deixa para o usuário.
Essas perguntas estão relacionadas, mas “a qualidade geral é boa” faz pouco para responder a todas elas.
Somente quando temos clareza sobre o que estamos avaliando é que podemos saber quais evidências coletar e quanto uma pontuação pode nos dizer.
Uma avaliação também precisa ser justa com as condições daquele momento.
Neste processo de escrita, alguns objetivos só ficaram claros por meio da discussão. As primeiras respostas devem ser julgadas em relação às necessidades que já haviam sido expressas, e não a preferências que surgiram depois.
Se os requisitos já estavam claros e o resultado ainda era inadequado, precisamos identificar o problema com mais precisão. O agente entendeu mal? Esqueceu uma restrição anterior? Ou atender a um novo pedido desfez algo que já estava funcionando?
Tudo isso pode ser descrito como “escrita ruim”, mas cada caso exige melhorias muito diferentes. Fornecer mais informações sobre a tarefa, ajustar o contexto ou mudar a abordagem de execução podem ajudar. Primeiro, porém, precisamos saber onde as coisas deram errado.
Outros requisitos não devem mudar conforme a preferência pessoal. Se as citações são reais, se os fatos são precisos e se as conclusões têm sustentação precisa ser verificado de forma independente. O usuário gostar de um resultado não basta para estabelecer que esses requisitos foram atendidos.
Acho que essa distinção importa. Ela permite que a avaliação leve em conta necessidades específicas enquanto mantém padrões necessários de julgamento.
Mesmo quando o objetivo está claro e o agente acerta desta vez, ainda há mais a observar.
Ele consegue fazer a mesma tarefa bem uma segunda vez? Se o usuário formular o pedido de outra maneira, ele interpretará mal a intenção? Quando faltam informações, ele consegue reconhecer a incerteza em vez de preencher as lacunas com prosa fluente?
Um estudo sobre a confiabilidade de agentes examinou consistência, robustez, previsibilidade e segurança separadamente. Nos modelos e benchmarks que testou, ganhos de capacidade trouxeram apenas melhorias limitadas em confiabilidade. É um lembrete de que, depois de aprender o que um agente consegue realizar, ainda precisamos entender as condições sob as quais podemos confiar nele. Pesquisa relacionada
Então, quem define o que é um bom agente?
Acredito que o propósito real do usuário deve ser o ponto de partida. As equipes de produto precisam deixar claro quais necessidades pretendem atender e quanta responsabilidade assumirão. A engenharia precisa entender a implementação e os limites das capacidades do sistema. A avaliação coloca essas expectativas em situações concretas e testa se os resultados as confirmam.
Alguém precisa ser responsável pelos trade-offs finais, e é preciso haver evidências sobre as quais discuti-los.
Pegue o pedido para tornar algo “mais profissional”. Uma pessoa pensa em terminologia e referências. Outra pensa em raciocínio mais rigoroso. Uma terceira espera que o autor identifique o cerne do problema. Quando aplicamos o pedido a um artigo real, fica mais fácil ver que não estamos todos falando da mesma coisa.
Prefiro construir consenso por meio de casos como esses. Quais fatos precisam estar corretos? Quais partes afetam se o resultado é utilizável? Onde há espaço para escolhas diferentes? Tudo isso pode ser discutido. Quanto mais específicos forem nossos padrões, melhores serão nossas chances de explicar divergências depois.
Esses padrões também devem estar abertos a revisão. Novas situações podem expor problemas que não havíamos considerado, e os usuários podem começar a pedir coisas diferentes. O que importa é registrar por que fizemos um ajuste, para que a equipe possa distinguir uma melhoria no produto de uma mudança na forma como ele é julgado.
O valor da avaliação também precisa aparecer nas escolhas que fazemos depois.
Se uma avaliação nos deixa mais claros sobre o que priorizar, capazes de explicar por que uma melhoria vale o investimento e cientes de quais testes adicionais precisamos quando as evidências são insuficientes, então as pontuações têm valor prático.
Olhando para trás, a IA ajudou a tornar o artigo mais completo. Foram as rodadas posteriores de discussão que nos ajudaram a definir o que manter e o que podíamos remover.
É também isso que espero que a avaliação ajude uma equipe a fazer: quando um resultado já parece bom, ainda ter uma forma de julgar se ele está pronto para ser colocado nas mãos de um usuário, e por que podemos confiar nesse julgamento.