Чем опасны «рекорды» в Text-to-SQL
Каждый месяц появляются новые заявления о том, что очередная LLM почти сравнялась с человеком на SQL-бенчмарках. Но если присмотреться, за этими цифрами скрываются очень разные условия: у кого-то используется простая подсказка без доступа к базе, кто-то разрешает модели выполнять запросы итерациями, а кто-то встроил рассуждения прямо в веса модели. Сравнивать такие результаты напрямую — всё равно что ставить рядом автомобиль с механиком и беспилотник, который сам чинит себя во время движения.
Авторы свежего препринта на arXiv (2608.15389) обратили внимание именно на эту проблему. Они предлагают больше не измерять «прогресс» абстрактной высотой в таблице лидеров, а сначала честно фиксировать, сколько автономии имела система при генерации SQL. Без такой оговорки любое сравнение между работами оказывается неустойчивым: изменение бенчмарка, базовой модели или даже чуть другого протокола инференса может изменить выводы.
Ось автономии: от подсказок к самодостаточным агентам
Вместо того чтобы просто собрать все цифры в одну таблицу, исследователи переопределяют саму область Text-to-SQL как «агрегацию лидерборда». Они собирают метрики, которые авторы систем сообщают самостоятельно, и раскладывают их вдоль оси автономности инференса. Получается пять уровней:
- Constrained generation — модель лишь выбирает ответ из жёстко ограниченного пространства допустимых запросов, часто с внешней проверкой синтаксиса.
- In-context generation — SQL строится за один проход по контексту с примерами и описанием схемы.
- Iterative generation — система может делать несколько попыток, уточняя запрос по результатам выполнения или по ответу СУБД.
- Agentic generation — модель работает как агент: сама исследует схему базы, запускает запросы, реагирует на ошибки и планирует следующие шаги.
- Reasoning-internalized generation — «рассуждение» заранее встроено в модель, поэтому на инференсе она выдаёт запрос напрямую, без внешних оркестраций и промежуточных шагов.
Подобная шкала не говорит, что один уровень «лучше» другого. Она лишь фиксирует условия честного сравнения: систему с внутренним reasoning нельзя противопоставлять голому single-shot выводy на равных, так же как агентный контур с правом выполнять запросы не стоит сравнивать с моделью, которой такого права не давали.
Важно, что для каждой ячейки такого лидерборда сохраняется прослеживаемое происхождение метрики. Это значит, что читатель всегда может понять, какая именно конфигурация дала результат, а не пытаться угадать по обрывкам экспериментального раздела.
Что показал эксперимент на Spider и за его пределами
Чтобы привязать агрегацию метрик к реальности, авторы провели прицельное исследование на бенчмарке Spider. Они сравнили открытые 8B-модели — с CoT-супервизией и без неё — против few-shot бейзлайнов на базе DeepSeek V3 и GLM-4. Интересно, что использовались именно few-shot протоколы, а не полноценные дообученные версии, поэтому сопоставление получилось достаточно чистым.
Из эксперимента выделяют четыре паттерна, важных для практиков.
Во-первых, улучшения, полученные на Spider, переносятся на BIRD и Spider 2.0 неравномерно. Модель может показывать красивый прирост на одном наборе запросов и почти не двигаться на другом. Это ещё раз подтверждает: слепая погоня за единым скором на одном популярном бенчмарке создаёт иллюзию общего прогресса.
Во-вторых, автономность добавляет устойчивость, но за нетривиальную цену. Агентные контуры действительно лучше справляются с многошаговыми и неоднозначными задачами, однако затраты на токены и время выполнения заметно растут. Если для интерактивного аналитика такая цена оправдана, то для пакетной обработки она может съесть весь выигрыш от более редких ошибок.
В-третьих, режим reasoning internalized занимает неожиданно среднее положение. Он оказывается между «тупым» декодированием ответа без рассуждений и внешне оркеструемыми агентами. Для ряда задач такой режим даёт почти агентское качество, но без необходимости строить сложный контур с инструментами. Хотя универсального «бесплатного обеда» не получается: встроенные рассуждения тоже имеют свои ограничения.
В-четвёртых, выигрыши от CoT-супервизии концентрируются на запросах уровней Hard и Extra-Hard. На простых вопросах разница почти незаметна либо даже негативна — зачем модели рассуждать вслух, когда ответ виден сразу? Зато на сложных многоступенчатых заданиях способность проговорить шаги вслух даёт заметное преимущество. Это важный сигнал для тех, кто строит SQL-ассистентов: фокусировать дополнительные вычислительные мощности надо на запросах с высокой сложностью, а не тратить их на типовые простые случаи.
Как пользоваться этой шкалой на практике
Самое полезное следствие работы — даже не сама таксономия, а публичный Python-харнесс, который авторы выпустили вместе с препринтом. Харнесс воспроизводит ось автономности и позволяет добавлять в лидерборд новые методы без переписывания всего окружения. Если вы разрабатываете ещё один Text-to-SQL подхода, достаточно указать, на каком уровне автономии он работает, — и сообщество сможет сравнить вас с предыдущими системами на равных.
Понятно, что агрегации, основанные на самостоятельно сообщённых метриках, всё равно стоит доверять с осторожностью. Не у всех есть бюджет повторять чужие эксперименты, но единая аннотация — это уже большой шаг вперёд. Пока же при чтении очередного «state-of-the-art» держите в голове простой вопрос: а что именно могла делать модель во время генерации запроса? Если ответ на это вопрос отсутствует, то и цифра из статьи — лишь красивое число без твёрдой опоры.
