Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Text-to-SQL-агента научили не забывать уточнения, которые он сам счёл нужными до генерации запроса. В нерецензированном препринте Cornell University и AWS все числа получили сами авторы: новый протокол снизил долю тихих ошибок на BIRD-Lite с 10,5% до 8,2%. Для продуктовой команды вывод практический: план вопросов надо хранить как состояние системы, а не как текст в истории диалога.
Почему правильный SQL ещё не означает правильного понимания
Интерактивный Text-to-SQL-агент может изучить схему и данные, спросить пользователя о пропущенных условиях, а затем собрать запрос. Переход от генерации за один ход к диалогу более чем утроил точность выполнения SQL на BIRD-Lite, но не устранил догадки.
Запрос «расставить товары по рейтингу» не задаёт показатель и направление сортировки. Агент может выбрать популярность и порядок по убыванию, случайно получить ожидаемый результат и пройти обычную проверку. Однако такой успех не опирается на явно подтверждённое намерение пользователя.
Работа разделяет точность выполнения и обоснованность ответа. Обоснованный успех означает, что SQL вернул правильный результат, а агент уточнил все размеченные неоднозначности. Тихой ошибкой авторы называют неверный результат, при котором хотя бы одна неоднозначность осталась неразрешённой.
Принудительное увеличение числа вопросов повышало точность, но быстро создавало лишний диалог: поздние вопросы чаще касались второстепенных деталей или того, на что пользователь не мог ответить. Текстовый план тоже не решил проблему. На BIRD-Lite агент намечал в среднем 4,1 вопроса, а задавал 3,3: после нескольких ответов модель начинала считать задачу понятной и переходила к SQL.
PlanPool повысил полноту выявления неоднозначностей с 80,8% у планирования через подсказку до 87,5%. Эта метрика показывает, какую долю заранее размеченных проблем агент затронул своими вопросами.
Как PlanPool удерживает незакрытые вопросы
PlanPool выносит план из контекста модели в отдельное изменяемое состояние. Сначала агент изучает источник данных и составляет упорядоченный набор вопросов. Дальше этот набор сохраняет управляющий слой, поэтому очередной ответ модели не может незаметно стереть ранее найденную проблему.
Во время диалога агент выполняет три операции: задаёт ожидающий вопрос, удаляет его с явным обоснованием или добавляет новую неоднозначность. Удаление нужно, если ответ на другой вопрос уже дал нужные сведения либо сделал пункт лишним. Поэтому PlanPool работает не как жёсткая анкета, а как обновляемая очередь обязательств.
Главное правило срабатывает перед отправкой результата: пока в наборе остаётся хотя бы один пункт, агент не может передать финальный SQL. Система требует не задать все первоначальные вопросы, а явно разобрать каждый из них. Модель сохраняет свободу менять план, но теряет возможность молча его бросить.
Механизм не меняет саму LLM, инструменты работы с базой или способ генерации SQL. Он добавляет состояние процесса и проверку перед завершающим действием. Это позволяет внедрить тот же принцип на уровне оркестратора, не переобучая модель.
Проверку провели на наборах, собранных из BIRD-Interact-Lite, BIRD-Interact-Full и Spider. Claude-Opus-4.8 работала и системным агентом, и симулятором пользователя; модель, инструменты и среду сохраняли одинаковыми для всех вариантов. Поэтому эксперимент сравнивает способы управлять уточнениями, но не показывает поведение реальных пользователей или других моделей.
Когда внешний план стоит добавить в продукт
Работа меняет планы команд, если цена неверного предположения выше цены дополнительного вопроса. Это относится к аналитическим помощникам, внутренним системам отчётности и интерфейсам к данным, где одинаково исполнимые SQL-запросы могут выражать разные бизнес-правила.
Одной инструкции «сначала составь план» для такого сценария недостаточно. Надёжная схема должна хранить ожидающие вопросы вне переписки, разрешать их явное добавление и удаление и блокировать финальное действие до опустошения набора. Проверку выполнения SQL при этом убирать нельзя: PlanPool дополняет её контролем намерения, а не заменяет.
За контроль приходится платить более длинным контекстом. На BIRD-Lite PlanPool стоил примерно на десятую часть дороже планирования только через подсказку, хотя кэширование контекста сгладило разницу. Эти расходы относятся к использованной модели и экспериментальной среде, поэтому для продукта важнее сначала измерить длину реальных диалогов и цену тихой ошибки.
Метрики тоже стоит разделить. Точность выполнения отвечает, сработал ли SQL на тестовых данных. Полнота неоднозначностей показывает, какие допущения агент обсудил, а обоснованный успех требует одновременно правильного результата и закрытых вопросов. Без такого разделения случайно угаданный запрос выглядит таким же надёжным, как запрос, собранный по подтверждённым требованиям.
Основной результат шире Text-to-SQL: найденное моделью обязательство не становится надёжным только потому, что присутствует в истории диалога. Если агент не должен забывать условие перед необратимым действием, это условие лучше превратить во внешнее состояние и проверять программно.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
