Использование экспертных знаний о задачах в RL позволяет достичь передовых результатов в Text-to-SQL

Многие отрасли полагаются на реляционные базы данных, запросы к которым выполняются с помощью SQL. Большая часть SQL-кода пишется машинами, но люди, вероятно, ежемесячно пишут миллиарды пользовательских SQL-запросов (основываясь на наших внутренних оценках и общедоступных данных, таких как отчеты Snowflake), продиктованных бизнес-задачами. Они справляются с этим довольно хорошо — люди набирают 92,96% в BIRD, реалистичном бенчмарке для перевода вопросов на естественном языке в SQL.

Однако производительность ИИ в задачах text-to-SQL отстает. Результаты LLM в таблице лидеров BIRD выросли с чуть менее 70% в 2024 году до 82% сегодня. Передовые модели, такие как GPT-5.6 Sol Ultra и Claude Fable 5, могут набирать результаты в районе 85%, хотя и с затратами, которые непомерно высоки для высоконагруженных приложений. Это происходит не из-за нехватки обучающих данных: SQL широко представлен в интернет-контенте, используемом при предварительном обучении LLM. Задача для ИИ заключается в навигации по неоднозначным вопросам и сложным контекстуальным схемам, которые характерны для реальных примеров.

Распространенным подходом для улучшения производительности ИИ в задачах, которые хорошо понимают люди, является создание агентных каркасов (agentic scaffolding). Системы, такие как OpenHands, AI co-scientist и MetaGPT, разбивают задачу на этапы, каждый из которых имеет свой промпт или вызов модели. Каркасы Text-to-SQL следуют той же схеме. Этап связывания схем (schema-linking) сужает тысячи столбцов до набора кандидатов. Реальные корпоративные системы данных (включая базы данных, хранилища данных и озера данных) содержат до миллионов столбцов. Ответы на бизнес-вопросы часто требуют понимания того, какие столбцы использовать. Академические бенчмарки проще. Этап генерации делает выборку запросов. Этап самокоррекции исправляет ошибки выполнения. Этап выбора голосует среди выживших вариантов. Каждый компонент является отдельным вызовом, а оркестрация обычно настраивается под конкретный бенчмарк.

Каркас — это попытка преодолеть ограничения рассуждений модели, заставляя ее придерживаться последовательности шагов, которая отражает то, как человек подошел бы к задаче. И все же лучшие модели с каркасами все еще отстают от людей в SQL на 11 пунктов. Профессионалы приобретают свои навыки с помощью повторяющегося опыта, а не путем получения списка инструкций — то же самое должно быть верно и для LLM. Опыт работы с задачей должен использоваться для обучения модели лучшему рассуждению о запросах и базах данных, вместо простого обновления промптов, которые она получает от каркаса.

В этом блоге мы описываем дообучение модели, которая достигает точности человеческого уровня в задачах text-to-SQL без использования каркасов, применяя обучение с подкреплением с проверяемыми вознаграждениями (RLVR) на Tinker.

Извлечение правильного ответа с помощью SQL — это проверяемая задача, которую можно обучить простым способом. Однако разрыв в производительности SQL-моделей предполагал, что стандартный рецепт можно улучшить. Наш подход имеет два решающих улучшения: проверенный экспертами обучающий набор, очищенный от ошибок разметки, которые могли бы отравить RLVR, и метод формирования вознаграждения, нацеленный на два распространенных режима сбоев RLVR в этой области.

Обученная модель, ReViSQL-K2.6, превышает человеческий показатель в 92,96% при выборе из 16 образцов (SC-16) (SC относится к выбору на основе самосогласованности, где мы группируем одновременно сгенерированные SQL-запросы по результатам их выполнения и случайным образом выбираем запрос из большинства. Ни один из компонентов не является частью традиционного агентного каркаса: генерация образцов просто извлекает несколько выходных данных из одного и того же промпта модели без отдельно заданных промежуточных шагов, в то время как голосование большинством не требует дополнительных вызовов модели) при стоимости $0,56 за задачу. Она точнее, чем Fable 5 и GPT-5.6 Sol Ultra, при 12–15% от их стоимости и намного точнее любой модели с каркасом в таблице лидеров.

Код, данные и рецепты обучения находятся по адресу github.com/uiuc-kang-lab/ReViSQL. Мы подробно описываем наши методы в нашем техническом отчете.

Курирование высококачественных обучающих данных

RLVR эффективен для улучшения рассуждений в конкретной предметной области, но он чувствителен к данным с неверными метками. В RLVR скалярное вознаграждение является полным сигналом обучения для шага обучения. Неправильно размеченные экземпляры меняют сигнал на противоположный, значительно ухудшая обучение. Наше исследование показало, что алгоритмические настройки не могут компенсировать эту потерю — очистка данных имеет решающее значение для эффективной работы RLVR.

Мы обнаружили, что существующие данные text-to-SQL чрезвычайно зашумлены. (Зашумленность публичных SQL-датасетов была отмечена многими другими, такими как Pourreza and Rafiei (2023) и Wretblad et al. (2024)). Наш анализ показал, что многие широко известные бенчмарки содержат большое количество шума. Мы отобрали 2,5 тыс. экземпляров из BIRD Train, обучающего датасета для text-to-SQL. Наш аудит обнаружил ошибки в каждом компоненте датасета: вопросах, предоставленных внешних знаниях и более чем в половине «золотых SQL-запросов», с которыми сравнивается ответ модели.

Таблица 1: Уровни ошибок аннотирования по 2,5 тыс. экземпляров, отобранных из BIRD Train. Категории перекрываются, поэтому итоговая сумма не является суммой значений.

Мы очистили обучающий набор в ходе многоэтапного процесса. Сначала LLM (o3 от OpenAI) и эксперт-человек просмотрели каждый экземпляр и пометили ошибки. Экспертная проверка показала, что аудитор LLM был точен в выявлении ошибок аннотирования (точность 90,6%), но обнаружил лишь 24,5% ошибок, отмеченных людьми. Ошибки и предложенные исправления с этого первого этапа были отправлены другому эксперту для проверки. Там, где проверяющий не соглашался с первоначальным аудитором, образец отправлялся обратно для дополнительных циклов разрешения конфликтов.

Мы выпустили очищенный обучающий набор для сообщества как BIRD-Platinum.

Мы подозревали, что оценочный датасет BIRD Mini-Dev также содержит ошибки аннотирования. Первый проход очистки BIRD Mini-Dev был выполнен Arcwise и исправил ошибки в 32,3% экземпляров. Мы провели второй проход, который подтвердил подавляющее большинство пометок Arcwise и нашел еще много других, доведя общий уровень обнаруженных ошибок в BIRD Mini-Dev до 52,8%. Оценочный набор с исправленными ошибками золотых запросов был выпущен как Arcwise-Plat-SQL.

BIRD-Platinum поднимает RLVR выше предыдущих лучших моделей

Мы дообучили Kimi-K2.6 с помощью RLVR на BIRD-Platinum, чтобы получить ReViSQL-K2.6. Обучение только на проверенных данных подняло ReViSQL-K2.6 значительно выше как передовых LLM-генералистов, так и ведущих дообученных моделей text-to-SQL с открытыми весами на Arcwise-Plat-SQL, с показателем точности 88,55%. Это показывает, что ошибки аннотирования в стандартных обучающих данных были ограничивающим фактором для RLVR в задачах text-to-SQL.

Чтобы продемонстрировать, что этот подход обобщается на другие модели и оценочные наборы, которых мы не касались, мы дообучили Qwen3-235B-A22B с помощью RLVR на BIRD-Platinum и оригинальном BIRD Train. Мы протестировали модель на двух новых бенчмарках text-to-SQL, которые широко считаются более сложными, чем BIRD:

• Spider2-SQLite: вариант бенчмарка Spider2, который содержит сложные запросы, в среднем в 5,2 раза превышающие по количеству токенов Arcwise-Plat-SQL.
• : вариант Spider2, который использует диалект Snowflake SQL.

Обучение на более тщательно отобранном наборе данных BIRD-Platinum повышает точность модели на 16% в Arcwise-Plat-SQL, на 12% в Spider2-SQLite и на 14% в Spider2-Snow по сравнению с BIRD Train. Это указывает на то, что наши проверенные данные создают более переносимый обучающий сигнал для различных бенчмарков и диалектов SQL.

Точный сигнал вознаграждения для RLVR в задачах text-to-SQL

Обучение на чистых данных приблизило дообученную модель к уровню человеческих показателей, однако разрыв более чем в 4% сохранился. Мы проанализировали случаи, когда модель не смогла выявить закономерности, что привело нас к изучению функции вознаграждения, используемой при обучении.

Стандартный метод RLVR для text-to-SQL присваивает вознаграждение 1, если сгенерированный запрос возвращает тот же результат, что и эталонный запрос к базе данных бенчмарка. Это повторяет систему оценки, используемую при тестировании, но не полностью отражает общее поведение, которому мы хотим обучить модель. Мы сосредоточились на двух способах, которыми вознаграждение на основе результата может отклоняться от желаемого поведения, и внесли изменения в функцию вознаграждения для их устранения.

Отклонение 1: совпадение результатов выполнения не означает семантическую эквивалентность

Стандартное вознаграждение на основе результата проверяет вывод сгенерированного запроса на одном экземпляре базы данных, но это не гарантирует, что результат будет верным для другого экземпляра. Неверный ключ соединения или пропущенный предикат могут остаться незамеченными, если конкретный экземпляр базы данных не выявляет ошибку. Только семантически эквивалентные запросы гарантированно дают одинаковый результат на любом экземпляре базы данных.

Мы проверяем семантическую эквивалентность SQL-запросов с помощью VeriEQL, решателя, который использует ограниченную верификацию и требует незначительных затрат ресурсов процессора по сравнению с общими затратами на обучение (менее 0,1%). В пилотном запуске обучения мы обнаружили, что 32,8% положительных вознаграждений на основе результатов были выданы запросам, которые не были полностью эквивалентны правильным. Это означает, что почти в одном случае из трех вознаграждение подкрепляло неверный запрос.

Вопрос: Сколько денег в среднем тратит Лукас Уайлдбор на заказы книг?

Эталонный SQL-запрос

SELECT AVG(order_total) FROM ( SELECT o.order_id, SUM(i.price) AS order_total FROM orders o JOIN items i ON o.order_id = i.order_id WHERE o.customer = 'Lucas...' GROUP BY o.order_id );

Неверный запрос, положительное вознаграждение

SELECT AVG(i.price) FROM orders o JOIN items i ON o.order_id = i.order_id WHERE o.customer = 'Lucas...'

Усредняет цены отдельных позиций, а не общие суммы заказов. Эти два значения совпадают только потому, что каждый заказ содержит одну позицию.

Мы обновили сигнал вознаграждения, снизив его вес в случаях, когда запрос был принят по результатам выполнения, но не был эквивалентен согласно VeriEQL. Благодаря дополнительному источнику верификации вознаграждение направляет обучение к правильному запросу, который обобщается на различные экземпляры баз данных.

Отклонение 2: вознаграждение за результат не учитывает предоставленные знания

Задачи в стиле BIRD предоставляют внешние знания вместе с вопросом в промпте. Вознаграждение на основе результата зависит только от конечного результата, что означает, что оно не может отличить модель, которая прочитала предоставленную информацию, от той, которая угадала правильно на основе своих априорных знаний. Например, поскольку «sodium = 0» и «sodium < 5» дают один и тот же набор результатов, вознаграждение на основе результата не может отличить модель, которая правильно использует внешние знания для выбора «sodium = 0», от той, которая запомнила или галлюцинирует «sodium < 5». При отсутствии градиента, подталкивающего модели к использованию внешних знаний, они склонны полагаться на априорные данные. В пилотном анализе на валидационном наборе 24,2% ошибок были связаны с тем, что модель игнорировала предоставленную необходимую информацию.

Вопрос: Среди рецептов от The California Tree Fruit Agreement рассчитайте процент рецептов без натрия.

Внешние знания: «без натрия» означает «sodium = 0».

Эталонный SQL-запрос

SELECT CAST(SUM( CASE WHEN sodium = 0 THEN 1 ELSE 0 END ) AS REAL) * 100 / COUNT(*) FROM recipes r WHERE r.source = 'California...'

Игнорирует внешние знания

SELECT CAST(SUM( CASE WHEN sodium < 5 THEN 1 ELSE 0 END ) AS REAL) * 100 / COUNT(*) FROM recipes r WHERE r.source = 'California...'

Мы решаем эту проблему с помощью вознаграждений за процесс, основанных на правилах. Модель должна выдать блок требований, который переводит каждую запись внешних знаний в явное ограничение запроса, и блок верификации, который проверяет сгенерированный запрос на соответствие этим ограничениям, с наложением штрафов за несоблюдение. Наше вознаграждение за процесс побуждает модель обосновывать свои рассуждения и генерацию предоставленными знаниями, а не слепо полагаться на свои предварительно обученные априорные знания. Вознаграждения основаны на правилах, а не на оценке моделью, что делает процесс оценки дешевым и свободным от влияния априорных знаний модели-судьи.

Рецепт обучения

Мы предоставляем наш рецепт обучения для ReViSQL-K2.6. Этот рецепт также можно воспроизвести, используя наш код, построенный на API Tinker.

Таблица 2: Конфигурация обучения.

Результаты

Мы представляем ReViSQL-K2.6, модель, дообученную на Tinker с использованием проверенных данных и обеих модификаций вознаграждения. При жадном декодировании (один образец, температура = 0) наша модель достигает точности 91,37% на Arcwise-Plat-SQL при стоимости $0,035 за задачу. Это улучшение на 8,4 пункта по сравнению с OpenSearch, самым сильным существующим конвейером с открытым исходным кодом, при стоимости на 37% ниже. Преимущество в стоимости является прямым следствием удаления вспомогательных структур вокруг модели.

Если ReViSQL-K2.6 выбирает ответ среди 16 кандидатов, сгенерированных с температурой = 1, точность возрастает до 92,97% при стоимости $0,56 за задачу. Насколько нам известно, это первый случай, когда система ИИ для text-to-SQL превзошла человеческий бенчмарк.

Заключение

Когда ИИ демонстрирует низкую производительность в узкоспециализированной задаче, обычная реакция — добавить вспомогательные структуры вокруг выполнения задачи. Этот подход несколько улучшил производительность моделей text-to-SQL, но в конечном итоге он упирается в потолок, установленный возможностями базовой модели. Это не означает, что вспомогательные структуры бесполезны. Скорее, это говорит о том, что знания о задаче, содержащиеся в этих структурах, должны быть частью обучающего сигнала — того самого обучения, которое повысило бы общую мощность модели.

Общая черта нашей предыдущей работы по обучению ИИ для принятия финансовых решений заключается в том, что специализированные модели могут превосходить передовые решения в широком спектре задач, требующих экспертного вкуса и суждения, часто за долю стоимости. Это требует, чтобы экспертное суждение было частью процесса обучения: при выявлении ошибок ИИ, разметке обучающих данных и приведении обучения в соответствие с предполагаемым поведением.

В случае с text-to-SQL мы увидели значительные улучшения как от тщательной очистки данных, так и от формирования функции вознаграждения, чтобы обучить модель правильному навыку. Это потребовало больше усилий на начальном этапе, но полученная модель достигает лучшей производительности при меньших затратах, чем люди и модели со вспомогательными структурами. Внедрение экспертных знаний в специализированное обучение — это то, что в конечном итоге обеспечивает масштабируемость.

Цитирование

Пожалуйста, цитируйте эту работу как:

BibTeX: