Agente perde dados por causa do tamanho da tabela, não do número de mensagens: 92% de turnos corretos contra 46%

Um agente típico é simples: a ferramenta devolve uma tabela, o modelo a recebe no contexto e a repassa ao usuário. Quando vêm perguntas como «mostre só os voos depois das 21:00», ele responde «de cabeça». Parece inofensivo, mas é justamente aí que os dados se corrompem.

A busca calculou tudo certo, o JSON é válido, o esquema bate, e mesmo assim a tabela final do usuário traz um preço diferente, uma data errada ou um voo que sumiu. Os autores de um trabalho recente no arXiv mediram esse efeito em um agente real, em produção. Por «precisão» no título, entende-se a fração de turnos da conversa em que todos os campos de todas as linhas coincidiram com o gabarito.

O principal resultado: a queda de precisão é determinada pelo tamanho da tabela, e não pela quantidade de mensagens já trocadas. Para quem constrói agentes, isso afeta diretamente a arquitetura e a conta de tokens.

O que foi comparado

Os pesquisadores usaram o AwardWise, um assistente multiagente de busca de passagens aéreas por milhas, construído sobre o Google Agent Development Kit. As duas versões do sistema diferem apenas na forma de entregar os dados. O modelo (Gemini 2.5 Flash), a temperatura 0,1, o top_p 0,5 e as instruções correlatas são os mesmos.

A primeira versão, SYNTHESIS, segue o padrão típico dos frameworks. A lista completa de voos entra no contexto do planejador, que monta a tabela sozinho e também responde sozinho às perguntas de refinamento.

A segunda, BYPASS, é a que roda no sistema em produção. Os registros ficam no estado da sessão e nunca passam pela geração do modelo. O modelo apenas traduz o pedido do usuário em argumentos de filtro. O filtro é executado por um código determinístico comum, e as linhas chegam à interface por um canal tipado separado.

O teste usou 24 conversas, com 339 turnos avaliados para cada variante. As respostas dos provedores foram congeladas de antemão: 408 snapshots em 36 rotas, e o maior resultado tem 510 linhas. O critério é rigoroso: um turno só é considerado correto se os campos coincidirem com o gabarito.

O que aconteceu

Foram totalmente corretos 92,3% dos turnos no BYPASS e 45,7% no SYNTHESIS, uma diferença de +46,6 pontos percentuais. Em três famílias de modelos, a diferença ficou entre +46,6 e +55,8 pontos.

Em seguida, os autores investigaram de que depende a falha. Eles variaram o tamanho da tabela pelas datas dos snapshots, por prefixos de um mesmo resultado e por um esquema de «quadrado latino», que separa o tamanho da posição na conversa. Em todos os casos, o SYNTHESIS desaba à medida que a tabela cresce, enquanto o BYPASS se mantém estável. O limiar do colapso depende da força do modelo: no GPT-4o-mini, fica abaixo de 10 linhas; no Gemini 2.5 Pro, é mais alto. Já o desvio mantém o nível nos quatro modelos testados: em 140 de 144 execuções. Os autores resumem assim: um modelo forte compra um limiar, a arquitetura compra imunidade.

Trocar o Flash pelo Gemini 2.5 Pro nas mesmas conversas eleva a precisão da reescrita de 46% para 72%, mas cada turno fica cerca de 5 vezes mais caro. É uma forma cara de alugar precisão em vez de simplesmente não perdê-la.

Custos, erros e limitações

No BYPASS, o custo e a latência do turno não dependem do tamanho da tabela: cerca de $0,012. Na reescrita, os gastos crescem junto com o contexto. Em resultados com mais de 100 linhas, quase nenhuma resposta está correta, e cada resposta correta sai cerca de 200 vezes mais cara do que no caminho com desvio.

A hipótese de que os erros se aceleram a cada turno não foi confirmada pelo teste registrado previamente. Segundo os autores, a causa está no método: com uma taxa de falha tão alta, não há com o que comparar. Por outro lado, é visível que os erros se propagam. Uma tabela corrompida vira entrada do turno seguinte. No BYPASS, cada turno é recalculado a partir do estado salvo, então essa cadeia não existe, e o resultado nulo de 0/25 significa apenas que não foram encontrados contraexemplos.

As limitações também importam. É um único sistema em um único domínio, as principais medições foram feitas com o Gemini 2.5 Flash, e os roteiros das conversas foram escritos a partir de sessões de um único praticante experiente em viagens com milhas (award travel). O ganho não foi decomposto por fator: o armazenamento de estado, o filtro determinístico e o canal lateral foram avaliados em conjunto.

Conclusão prática: canais laterais como LangGraph ou AG-UI costumavam ser adotados em nome de uma interface previsível. O trabalho mostra que eles também protegem os dados. Se a ferramenta devolve dezenas de linhas, mantenha-as no estado da sessão, deixe a filtragem para o código e reserve ao modelo apenas a tradução do pedido em argumentos.