В Text-to-SQL экономить контекст нужно до выполнения запроса

У агента, который пишет SQL, есть неприятная особенность: он сам определяет, какие наблюдения получит дальше. Если запрос слишком широкий, агент сначала тратит контекст и ресурсы базы, а полезное свидетельство может так и не попасть в рабочее окно. Сжать результат после этого — не значит вернуть пропущенные строки или отменить уже выполненную работу.

Именно на этом строится BAP-SQL. Авторы предлагают контролировать не только ответ модели, но и формирование наблюдения: оценивать риск запроса, при необходимости переписывать SQL и передавать жёсткие ограничения независимому runtime shield.

Это важный сдвиг в архитектуре. Бюджетирование происходит до того, как данные попадут агенту, а не после получения огромного результата. Для Text-to-SQL это означает, что планирование запроса становится частью политики агента, а не вспомогательной оптимизацией промпта.

На основном сценарии, производном от BIRD, BAP-SQL получил прирост в 3,4–3,6 процентного пункта относительно сопоставимого SFT и использовал на 4,5–5,0% меньше токенов. Результат проверяли на моделях общего назначения 4B, специализированной FINER-SQL 4B и 7B.

Но это не история про универсальное улучшение. Эффект слабее, когда растут возможности модели и доступный бюджет, а на самом свободном режиме преимущество меняет знак. Кроме того, BAP-SQL не уменьшает объём работы, который выполняет база данных: экономия относится прежде всего к наблюдениям и токенам агента.

Практический вывод простой: если агент работает с инструментами, лимитировать нужно не только финальный контекст. Нужно заранее ограничивать и форму запроса, и объём данных, которые вообще разрешено доставить модели. Иначе «оптимизация» после вызова инструмента будет лишь уборкой последствий.

Источник: cs.AI updates on arXiv.org