прочитал китайскую статью об адаптации text-to-sql через reasoning, поэтому небольшой обзор.
Few-shot prompting справляется с простыми схемами, но требует гигантских подсказок (тысячи токенов) и всё равно ломается на нескольких джоинах или вложенных запросах.
Seq2Seq fine-tuning (RAT-SQL) хорошо обрабатывает знакомые паттерны, но не даёт прозрачности, почему именно сгенерирован тот или иной SQL, и плохо работает с новыми или сложными запросами.
поэтому идея проста - вместо чистого sequence-to-sequence STaR-SQL рассматривает задачу как reasoning-процесс, состоящий из четырёх этапов, которые вместе дают state-of-the-art на сложных многошаговых запросах:
chain-of-thought
предлагают вместо прямого вопрос -> SQL предлагают разбивать на шаги
step 1: определить релевантные таблицы и дать им алиасы
step 2: отфильтровать столбец x в таблице a по условию y
step 3: выполнить join таблицы a и b по ключу z
…
sql: select a.col1, b.col2
from a as a
join b as b on a.id = b.a_id
where …
эти промежуточные шаги становятся примерами для обучения: видя «черновую работу», модель учится отслеживать несколько логических шагов, не терять условия и генерировать более точный sql. без cot execution accuracy падает более чем на 15 pp.
метрики оценки
EM (Exact Match) — покадровое сравнение предсказанного и золотого SQL по структуре и токенам
EX (Execution Accuracy) — процент вопросов, для которых при выполнении предсказанного SQL на БД результат полностью совпадает с результатом выполнения эталонного SQL. В отличие от EM, EX оценивает семантическую корректность по данным и учитывает разные, но эквивалентные по смыслу формулировки запросов.
seed rationales
базовый корпус берётся из text-to-sql датасета Spider: около 7000 вопросов с разметкой схемы и «золотым» SQL (train split). (Q, S, Y) — вопрос, схема, эталонный SQL.
вручную аннотируют небольшую выборку (~40 примеров Spider) пошаговыми CoT-обоснованиями: разбиваем NL-вопрос на логику («сначала выбрать таблицу X», «затем джоин с Y по Z», «применить фильтр W»).
rationale-driven generation
для каждого из 7000 примеров в few-shot режиме генерируют k=8 (!) пар (rationale + SQL);
Prompt: «По этой NL-формулировке и схеме БД сгенерируй многошаговое rationale, а потом финальный SQL».
выполняют каждый SQL на соответствующей тестовой базе: те, что дают правильный результат, метят как correct, остальные как incorrect;
k-way Sampling: для каждого примера получаем k пар (rationale + SQL).
из 7000×8 = 56 000 кандидатов обычно попадает в первый forward пул порядка 20–30 % correct запросов, остальные это negative.
difficulty-aware self-finetuning
все это хорошо, но есть проблема: модель слишком быстро учится на «простых» примерах, и данные для дообучения получаются перекошенными. Поэтому после первого раунда считаем для каждого примера ошибочность. Для «тяжёлых» случаев в prompt добавляем золотой SQL как backward-hint, чтобы модель генерировала rationale, объясняющее уже известную правильную структуру..
здесь используется стандартный токенный cross-entropy, но с весом, зависящим от сложности
verifier-supervised selection.
Даже после дообучения генератор может допускать тонкие логические ошибки. Обучаем лёгкий классификатор (на тех же примерах Spider) помеченным как correct/incorrect.
На инференсе генерируем 16 кандидатов (rationale + SQL), прогоняем каждый через верификатор и выбираем самый «достоверный».
осле одного раунда возвращаются к исходному checkpoint, повторяют генерацию → фильтрацию → дообучение, пока gain по EX/EM не схлынет (обычно 2–3 итерации).
В отличие от majority-voting (self-consistency), напрямую использует execution outcomes при обучении.