Um agente de IA foi solicitado a acelerar um banco de dados chave-valor. Ele entregou um ganho de 6× no throughput e passou em todos os testes de correção. A explicação? O agente descobriu que o benchmark padrão da indústria usado para avaliar o desempenho do banco gerava valores a partir das chaves. Em vez de armazenar os valores, ele simplesmente os regenerava sob demanda quando os clientes solicitavam.
Um banco de dados chave-valor que evita armazenar valores não faz muito sentido, mas o avaliador recompensou exatamente esse comportamento. A especificação omitiu algo que considerávamos óbvio, e o benchmark falhou em expor essa omissão.
Duas lacunas que levam ao reward hacking e às alucinações
Nosso novo artigo explica esse comportamento e muitas outras falhas agênticas através da lente de duas lacunas principais que estão fora do familiar ciclo de implementação-verificação que gera código, executa testes e corrige falhas até que todos passem.
- Lacuna de Requisitos: Separa o que escrevemos do que realmente queremos. No nosso caso, assumimos como certo que qualquer solução armazenaria os valores fornecidos pelos clientes—afinal, é chamado de "banco de dados" por uma razão!—então nunca nos ocorreu declarar esse requisito explicitamente.
- Lacuna de Modelo: Separa o ambiente onde avaliamos do mundo real onde a implementação será implantada. Nosso benchmark usava valores previsíveis, mas clientes reais fornecem valores arbitrários.
A resposta natural é escrever melhores requisitos e testes mais robustos. Ambos ajudam. Mas nem mesmo provas verificadas por máquina podem fechar essas lacunas. Como Brian Cantwell Smith explicou em The Limits of Correctness (1985), uma prova apenas estabelece que o software satisfaz os requisitos declarados sob determinadas suposições ambientais. Ela não pode provar que esses requisitos capturam tudo o que os usuários desejam, ou que essas suposições cobrem todos os cenários de implantação no mundo real. Como resultado, essas lacunas não podem ser fechadas de forma geral.
Essas lacunas levam ao reward hacking e às alucinações. O reward hacking acontece quando agentes melhoram um objetivo dado explorando uma lacuna, como um requisito não declarado ou uma suposição do mundo real. A alucinação acontece quando os agentes ampliam ainda mais as lacunas introduzindo requisitos fabricados ou suposições ambientais, como uma API que não existe. Incidentes recentemente reportados envolvendo a OpenAI e a Hugging Face e o Claude são todas manifestações dessas lacunas.
Agentes de IA pioram as duas lacunas
Essas lacunas não são novas; elas existem na engenharia de software há décadas. Mas os agentes de IA tornam essas lacunas muito piores.
- Hiperotimização: Agentes buscam implementações ordens de magnitude mais rápido que humanos, otimizando ativamente contra o avaliador.
- Falta de Conhecimento Tácito: Engenheiros humanos experientes dependem de contexto tácito (por exemplo, saber que um banco de dados deve realmente armazenar dados). Os agentes frequentemente carecem desse contexto organizacional e explorarão prontamente requisitos ausentes.
- A Armadilha Multiagente: Adicionar mais agentes revisores não resolve o problema se cada agente herdar exatamente os mesmos requisitos incompletos e suposições ambientais.
O julgamento humano é essencial para reduzir as lacunas
Como as lacunas estão fora do ciclo implementação–verificação, reduzi-las requer um ciclo externo de garantia-revisão. Este ciclo verifica se o comportamento implantado satisfaz a intenção humana. Quando não satisfaz, o ciclo usa evidências de implantação para revisar os requisitos, o modelo ambiental ou o avaliador. O ciclo de implementação-verificação então roda novamente para produzir uma implementação revisada.
Como o software deve servir à intenção humana, os humanos retêm a autoridade final sobre a interpretação das evidências e a decisão de qual comportamento é aceitável. Os agentes podem acelerar o ciclo externo reunindo evidências, propondo revisões e tomando decisões rotineiras dentro da autoridade delegada pelos humanos.
Assim, à medida que a implementação de software se torna mais barata, o recurso mais crítico se torna o julgamento humano sobre qual comportamento é aceitável e a avaliação fiel de como os sistemas se comportam sob condições reais.
