Агент с фильтром и боковым каналом дал 92,3% полностью верных ходов против 45,7% у пересказа

Когда агент получает от инструмента готовую таблицу и на каждом ходу диалога переписывает её в ответ, модель портит данные, которые инструмент посчитал правильно. Авторы новой работы измерили это в боевом агенте для поиска авиабилетов за мили. Они сравнили две архитектуры на одних и тех же замороженных данных.

В схеме SYNTHESIS полный список строк попадает в контекст модели, и она каждый раз заново выдаёт таблицу сама. В схеме BYPASS, которая работает в продакшене, записи хранятся в состоянии сессии, а строки уходят в интерфейс мимо модели. Главная метрика — доля ходов, где все поля всех строк верны: 92,3% у BYPASS и 45,7% у SYNTHESIS.

Парный разрыв между ними составил 46,6 процентного пункта. Ошибки определяет размер таблицы в контексте, а не число ходов.

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

Система называется AwardWise. Это мультиагентный помощник на Google Agent Development Kit (ADK). Планировщик маршрутизирует запросы, а субагенты обращаются к поиску наградных мест (Seats.aero) и к денежным тарифам (SerpAPI). Обе архитектуры работали на Gemini 2.5 Flash при температуре 0,1 и top_p 0,5. Данные брались из одних и тех же замороженных ответов вендоров. Отличалась только доставка.

В SYNTHESIS, классическом для ADK образце, уточнения вроде «только вылеты после 21:00» модель обрабатывает «в уме» и снова печатает таблицу. В BYPASS она лишь переводит просьбу пользователя в аргументы для детерминированного фильтра. Фильтр работает над сохранённым набором записей, а строки идут клиенту типизированными событиями рядом с потоком токенов модели, а не через него. Ошибка перевода просьбы в аргументы даёт один неверный, но реальный срез данных. Пересказ же ставит под удар каждое поле каждой строки на каждом ходу.

Оценивали 24 диалога, по 339 оценённых ходов на каждое условие. Диалоги составлены по сессиям опытного практика award-travel. Эталон считал продакшен-вычислитель фильтров, а проверка шла построчно и пополевно, с обнулением хода при неверном результате. Корпус содержит 408 снимков выдачи по 36 маршрутам, самая крупная выдача — 510 строк. Те же 46,6 п.п. на трёх семействах моделей превращаются в разрыв от 46,6 до 55,8 п.п.

Обрыв точности по размеру таблицы

Чтобы отделить размер от числа ходов, авторы поставили несколько экспериментов. Двадцать диалогов на четырёх маршрутах менялись по размеру выдачи. Лестница из шести маршрутов давала модели первые K строк одной и той же выдачи, так что содержимое оставалось постоянным. Латинский квадрат разделял размер и позицию строки. На каждом дизайне SYNTHESIS рушится с ростом таблицы, а BYPASS остаётся ровным. Контрольная таблица, побайтно совпадающая с проблемной, сохраняет уровень даже там, где схема с пересказом набрала ноль.

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

Цена обрыва и ограничения

Стоимость хода в BYPASS не зависит от размера таблицы и составляет около $0,012. У SYNTHESIS при таблицах свыше 100 строк почти нет верных ответов, и каждый верный обходится примерно в 200 раз дороже этой плоской цены. Замена Flash на Gemini 2.5 Pro поднимает точность пересказа с 46% до 72%, но за ход выходит примерно в пять раз дороже. По оценке авторов, покупать точность у более крупной модели — дорогая замена отказу от пересказа.

Предрегистрированная гипотеза о сверхлинейном накоплении ошибок по ходам диалога не подтвердилась. Нулевая модель насыщается, когда вероятность сбоя за ход и так велика. Зато трассировка значений показала, что сбои не независимы: испорченная выдача становится входом следующего хода. BYPASS каждый раз пересчитывает ответ из сохранённого состояния, и такому распространению ошибки там нечему возникнуть.

Ограничения тоже названы прямо. Разрыв отражает совместный эффект трёх отличий архитектур, и вклад каждого по отдельности авторы не разделяли. Для этого нужны раздельные условия, их оставили на будущую работу. Основные условия работали на Gemini 2.5 Flash, унаследованной по истории продукта, а не выбранной специально. По ходу работы измерения вскрыли восемь дефектов установки, три из них в собственном эталоне, плюс две поправки семантики эталона и три продакшен-бага. Всё исправили, и все основные числа получены уже после правок.

Вывод для разработчиков: типизированный боковой канал появился в LangGraph, AG-UI, Vercel Data Parts и Google A2UI ради предсказуемого рендеринга. Эта работа показывает, что он заодно решает вопрос корректности. Если в контексте лежат десятки и сотни строк, пользователь должен увидеть их без искажений. Поэтому записи стоит хранить в состоянии и фильтровать детерминированным кодом, а не просить модель переписывать их заново.