Агент теряет данные из-за размера таблицы, а не числа реплик: 92% верных ходов против 46%

Типичный агент устроен просто: инструмент возвращает таблицу, модель получает её в контекст и пересказывает пользователю, а на уточнения вроде «покажи только вылеты после 21:00» отвечает «в уме». Выглядит безобидно, но именно здесь данные и портятся. Поиск посчитал всё правильно, JSON валиден, схема сходится, а в итоговой таблице у пользователя уже другая цена, неверная дата или потерянный рейс. Авторы свежей работы на arXiv измерили это на реальном продакшн-агенте. Под «точностью» в заголовке понимается доля ходов диалога, где все поля всех строк совпали с эталоном. Главный результат: падение точности определяется размером таблицы, а не тем, сколько реплик прошло. Если вы строите агентов, это прямо влияет на архитектуру и на счёт за токены.

Что сравнивали

Исследователи взяли AwardWise, мультиагентного помощника по поиску авиабилетов за мили на Google Agent Development Kit. Две версии системы отличаются только способом доставки данных. Модель (Gemini 2.5 Flash), температура 0,1, top_p 0,5 и родственные инструкции одинаковы.

Первая версия, SYNTHESIS, повторяет стандартный шаблон фреймворков. Полный список рейсов попадает в контекст планировщика, тот сам формирует таблицу и сам отвечает на уточнения.

Вторая, BYPASS, работает в боевой системе. Записи лежат в состоянии сессии и никогда не проходят через генерацию модели. Модель лишь переводит просьбу пользователя в аргументы фильтра, фильтр выполняет обычный детерминированный код, а строки уходят в интерфейс отдельным типизированным каналом.

Проверяли на 24 диалогах, по 339 оцениваемых ходов на каждый вариант. Ответы поставщиков заранее заморозили: 408 снимков по 36 маршрутам, самая большая выдача содержит 510 строк. Критерий строгий: ход считается верным, только если поля совпали с эталоном.

Что получилось

Полностью верными оказались 92,3% ходов у BYPASS и 45,7% у SYNTHESIS, разрыв составил +46,6 процентного пункта. На трёх семействах моделей разрыв держался в диапазоне от +46,6 до +55,8 пункта.

Дальше выяснилось, от чего зависит провал. Размер таблицы меняли по датам снимков, по префиксам одной и той же выдачи и по схеме «латинского квадрата», которая отделяет размер от позиции в диалоге. Везде SYNTHESIS обваливается по мере роста таблицы, а BYPASS остаётся ровным. Порог обвала зависит от силы модели: у GPT-4o-mini он ниже 10 строк, у Gemini 2.5 Pro выше. Но обход держит уровень на всех четырёх проверенных моделях: 140 из 144 запусков. Авторы формулируют так: сильная модель покупает порог, архитектура покупает иммунитет.

Замена Flash на Gemini 2.5 Pro на тех же диалогах поднимает точность пересказа с 46% до 72%, но ход обходится примерно в 5 раз дороже. Это дорогой способ арендовать точность вместо того, чтобы не терять её.

Деньги, ошибки и ограничения

У BYPASS цена и задержка хода не зависят от размера таблицы: около $0,012. У пересказа расходы растут вместе с контекстом. На выдачах больше 100 строк почти ни один ответ не верен, и каждый корректный ответ обходится примерно в 200 раз дороже, чем у обходного пути.

Гипотезу о том, что ошибки ускоряются с каждым ходом, заранее зарегистрированный тест не подтвердил. По словам авторов, причина в методе: при таком высоком проценте провалов сравнивать не с чем. Зато видно, что ошибки передаются дальше. Испорченная таблица становится входом для следующего хода. У BYPASS каждый ход пересчитывается из сохранённого состояния, поэтому такой цепочки нет, а нулевой результат 0/25 означает лишь, что контрпримеров не нашлось.

Ограничения тоже важны. Это одна система в одной предметной области, основные замеры сделаны на Gemini 2.5 Flash, а сценарии диалогов написаны по сессиям одного опытного практика award-путешествий. Выигрыш не разложен по факторам: хранение состояния, детерминированный фильтр и боковой канал оценены вместе.

Практический вывод: боковые каналы вроде LangGraph или AG-UI обычно внедряли ради предсказуемого интерфейса. Работа показывает, что они ещё и защищают данные. Если инструмент возвращает десятки строк, держите их в состоянии сессии, фильтрацию отдайте коду, а модели оставьте только перевод просьбы в аргументы.