Проблема «разрыва верности» (Fidelity Collapse)
В продакшен-системах, использующих LLM для работы с инструментами, часто возникает критическая проблема: при каждом новом запросе (turn) модель заново обрабатывает историю данных, что приводит к постепенной порче (corruption) изначально верных вычислений. Исследование Tung Thanh Hoang на примере агента для бронирования авиабилетов выявило, что причина деградации — не в длине диалога, а в размере передаваемых таблиц.
Сравнение двух архитектур
Авторы протестировали две системы на идентичных «замороженных» данных (frozen payloads) и промптах, различающихся только способом доставки данных в контекст модели:
- SYNTHESIS (Стандартная): Полные наборы записей загружаются в контекст планировщика. Модель отвечает на уточняющие вопросы, опираясь на этот контекст (in-head).
- BYPASS (Развернутая система): Данные хранятся в состоянии сессии. Уточняющие запросы транслируются в аргументы для детерминированного фильтра, а строки передаются через типизированный побочный канал (typed side channel).
Ключевые метрики и бенчмарки
Тестирование проводилось на 24 диалогах (всего 339 оцененных поворотов). Результаты показали катастрофический разрыв в точности:
| Архитектура | Доля верных ответов | Зависимость от размера таблицы | Стоимость верного ответа (>100 строк) |
|---|---|---|---|
| BYPASS (Deployed) | 92.3% | Не зависит (size-flat) | $0.012 (базовая) |
| SYNTHESIS (Context-heavy) | 45.7% | Коллапс при >74 строках | ~$2.40 (в 200 раз дороже) |
При размере таблицы более 74 строк точность SYNTHESIS падает до 8% и ниже. При этом стоимость получения одного верного ответа в этом режиме возрастает примерно в 200 раз по сравнению с BYPASS.
Влияние модели на порог коллапса
Авторы провели тест на «лестнице префиксов» (prefix ladder) с контролем контента, чтобы определить, насколько разные модели справляются с большими таблицами в режиме SYNTHESIS. Порог, после которого точность падает, напрямую зависит от мощности модели:
| Модель | Порог коллапса (строк) |
|---|---|
| GPT-4o-mini | < 10 строк |
| Gemini 2.5 Pro | > 198 строк |
В то же время архитектура BYPASS оставалась стабильной (size-flat) для всех четырех протестированных моделей, независимо от их размера.
Вывод для разработчиков
Практики часто выбирают архитектуру с типизированным побочным каналом (side-channel delivery) только для упрощения рендеринга данных. Данное исследование доказывает, что это решение является прежде всего решением для сохранения корректности (correctness). Передача больших объемов структурированных данных в контекст LLM на каждом шаге диалога экономически неэффективна и технически рискованна.
Источник: arXiv cs.CL ↗