Un agente pierde datos por el tamaño de la tabla, no por el número de turnos: 92% de turnos correctos frente a 46%

Un agente típico funciona de forma sencilla: la herramienta devuelve una tabla, el modelo la recibe en su contexto y se la resume al usuario, y ante aclaraciones como «muéstrame solo los vuelos que salen después de las 21:00» responde «de memoria». Parece inocuo, pero es justo aquí donde los datos se corrompen. La búsqueda calculó todo bien, el JSON es válido, el esquema cuadra, y aun así en la tabla final el usuario ve otro precio, una fecha errónea o un vuelo perdido.

Los autores de un trabajo reciente en arXiv lo midieron en un agente real en producción. Por «precisión» en el título se entiende la proporción de turnos del diálogo en los que todos los campos de todas las filas coincidieron con la referencia. El resultado principal: la caída de la precisión depende del tamaño de la tabla, no de cuántos turnos han pasado.

Si construyes agentes, esto afecta directamente a la arquitectura y a la factura de tokens.

Qué se comparó

Los investigadores tomaron AwardWise, un asistente multiagente para buscar vuelos con millas, construido sobre Google Agent Development Kit. Las dos versiones del sistema se diferencian solo en cómo entregan los datos. El modelo (Gemini 2.5 Flash), la temperatura 0,1, top_p 0,5 y las instrucciones afines son idénticos.

La primera versión, SYNTHESIS, sigue la plantilla estándar de los frameworks. La lista completa de vuelos entra en el contexto del planificador, que forma la tabla por sí mismo y responde por sí mismo a las aclaraciones.

La segunda, BYPASS, es la que funciona en el sistema real. Los registros se guardan en el estado de la sesión y nunca pasan por la generación del modelo. El modelo solo traduce la petición del usuario a argumentos de un filtro, el filtro lo ejecuta código determinista convencional y las filas llegan a la interfaz por un canal tipado independiente.

La prueba usó 24 diálogos, con 339 turnos evaluables por cada variante. Las respuestas de los proveedores se congelaron de antemano: 408 instantáneas de 36 rutas, y la salida más grande contiene 510 filas. El criterio es estricto: un turno se considera correcto solo si los campos coinciden con la referencia.

Qué resultó

Fueron totalmente correctos el 92,3% de los turnos de BYPASS y el 45,7% de los de SYNTHESIS, una brecha de +46,6 puntos porcentuales. En tres familias de modelos, la brecha se mantuvo en un rango de +46,6 a +55,8 puntos.

Después se averiguó de qué depende el fallo. El tamaño de la tabla se varió por fechas de las instantáneas, por prefijos de una misma salida y mediante un diseño de «cuadrado latino» que separa el tamaño de la posición en el diálogo. En todos los casos SYNTHESIS se desploma a medida que crece la tabla, mientras que BYPASS se mantiene estable. El umbral del desplome depende de la potencia del modelo: en GPT-4o-mini está por debajo de 10 filas y en Gemini 2.5 Pro, por encima. Pero el bypass mantiene su nivel en los cuatro modelos probados: 140 de 144 ejecuciones. Los autores lo resumen así: un modelo potente compra umbral, la arquitectura compra inmunidad.

Cambiar Flash por Gemini 2.5 Pro en los mismos diálogos eleva la precisión de la reescritura de 46% a 72%, pero cada turno sale aproximadamente 5 veces más caro. Es una forma costosa de alquilar precisión en lugar de no perderla.

Dinero, errores y limitaciones

En BYPASS, el precio y la latencia del turno no dependen del tamaño de la tabla: unos $0,012. En la reescritura, los costes crecen junto con el contexto. En salidas de más de 100 filas casi ninguna respuesta es correcta, y cada respuesta correcta cuesta aproximadamente 200 veces más que con la vía de bypass.

La hipótesis de que los errores se aceleran con cada turno no quedó confirmada por la prueba registrada de antemano. Según los autores, la causa está en el método: con un porcentaje de fallos tan alto no hay con qué comparar. Lo que sí se ve es que los errores se arrastran. La tabla corrompida se convierte en la entrada del turno siguiente. En BYPASS cada turno se recalcula a partir del estado guardado, así que no existe esa cadena, y el resultado nulo de 0/25 solo significa que no se encontraron contraejemplos.

Las limitaciones también importan. Se trata de un solo sistema en un solo ámbito, las mediciones principales se hicieron con Gemini 2.5 Flash y los guiones de los diálogos se escribieron a partir de sesiones de un único profesional experimentado en viajes con award. La ganancia no está desglosada por factores: el almacenamiento del estado, el filtro determinista y el canal lateral se evaluaron en conjunto.

Conclusión práctica: los canales laterales como LangGraph o AG-UI solían adoptarse para lograr una interfaz predecible. Este trabajo muestra que, además, protegen los datos. Si una herramienta devuelve decenas de filas, guárdalas en el estado de la sesión, deja el filtrado al código y limita al modelo a traducir la petición a argumentos.