DIN-SQL: Декомпозирано контекстно обучение за текст-към-SQL

Миналата седмица разгледах BIRD — бенчмаркът, който разкри колко сериозно се препъват големите езикови модели (LLM), когато задачите за преобразуване на текст в SQL преминат от подредени тестови бази данни към реални схеми с разхвърляни имена, специфични знания в областта и ограничения за ефективност. DIN-SQL е статията, която трябваше да прочета първо: тя дефинира какво всъщност може да постигне внимателно декомпозиран конвейер за подтикване (prompting pipeline) на LLM върху Spider и BIRD. Тя беше представена на NeurIPS 2023 от Мохамадраза Пореза и Давуд Рафиеи точно когато GPT-4 стана широко достъпен. Четенето ѝ сега — след като BIRD разкри тавана на възможностите — прави силните и слабите ѝ страни много по-лесни за забелязване.

Статията

DIN-SQL (arXiv:2304.11015) адресира рязката разлика в производителността. В началото на 2023 г. най-добрите фино настроени модели — RESDSQL-3B+NatSQL — достигнаха 79,9% точност на изпълнение на тестовия набор на Spider, докато GPT-4 с наивно prompt-ване само с няколко примера (few-shot) постигна едва 67,4% в набора за разработка. Хипотезата на Пореза и Рафиеи е, че тази празнина е основно проблем на интерфейса: LLM са достатъчно способни, но генерирането на SQL в един пас изисква от тях да решат едновременно свързването на схеми, класификацията на сложността и синтеза на заявката. Ако тези задачи се декомпозират в последователни подзадачи и всяко решение се подава напред като контекст, ситуацията се променя.

Техният конвейер има четири етапа: (1) модул за свързване на схеми (schema-linking), който използва подтикване тип „верига от мисли“ (chain-of-thought), за да съпостави въпроса на естествен език със специфични колони и стойности в схемата; (2) модул за класификация и декомпозиция, който разпределя заявката в категории: лесна (единична таблица, без съединяване), сложна не-вложена (съединявания, но без подзаявки) или сложна вложена (съединявания, подзаявки, операции с множества) и, за вложените заявки, декомпозира проблема в подзаявки; (3) модул за генериране на SQL, който съобразява стратегията на подтикване с класа на сложност — опростен few-shot за лесни, NatSQL междинно представяне за не-вложени и многоетапна „верига от мисли“ за вложени; и (4) модул за самокорекция, който изисква от модела да прегледа собствения си изход за дребни грешки като липсващ DISTINCT или неправилно поставен DESC.

Ключови идеи

• GPT-4 + DIN-SQL достига 85,3% точност на изпълнение в независимия тестов набор на Spider, скок от +5,4 пункта спрямо тогавашния SOTA фино настроен модел RESDSQL-3B+NatSQL (79,9%), без никакви специфични за задачата данни за обучение.
• В Spider dev набора, конвейерът за декомпозиция придвижва GPT-4 от 67,4% (базов few-shot) до 74,2% — чист прираст от +6,8 пункта. CodeX Davinci се премества от 61,5% на 69,9%.
• Аблационният анализ потвърждава, че всеки етап допринася: премахването само на свързването на схеми сваля CodeX от 69,9% на 65,9%; премахването на класификацията го сваля още до 63,1%.
• Печалбите са концентрирани в лесни и средни заявки. При „изключително трудни“ заявки дори пълният конвейер DIN-SQL + GPT-4 достига само 43,4% в Spider dev — декомпозицията не решава сложността, тя просто намалява предотвратимите грешки при изпълними заявки.
• Самокорекцията е чувствителна към модела: GPT-4 реагира на „нежни“ подкани, които питат за потенциални подобрения; CodeX реагира по-добре на „генерични“ подкани, които приемат, че SQL е грешен. Това предполага, че модулът извършва стилистично изчистване, а не реална семантична проверка.
• В BIRD dev, DIN-SQL + GPT-4 постига 50,72% срещу 46,35% за базовия GPT-4 — подобрение от +4,4 пункта, значително по-малко от печалбите при Spider, към което ще се върна по-късно.

Какво се потвърждава — и какво не

Основният резултат е реален. Декомпозирането на текст-към-SQL в изрични подзадачи подобрява производителността и аблационните изследвания са достатъчно ясни, за да се повярва в приноса на отделните модули. Свързването на схеми е най-важно за трудните заявки, което е логично: моделът не може да генерира правилни JOIN-ове, ако първо не е идентифицирал правилно към кои таблици и колони се отнася въпросът.

Но няколко неща ме карат да се замисля. Разликата между 74,2% (dev) и 85,3% (test) е подозрителна. Наборите за разработка (dev) обикновено са по-трудни или поне толкова трудни, колкото тестовите, защото моделите са индиректно настроени спрямо тях; скок от +11 пункта при преминаване от dev към test е необичаен. Авторите не обясняват това и ме кара да се запитам дали тестовият набор има различно разпределение на трудността на заявките или има нещо в начина, по който се оценява независимият тест (чрез официалния сървър на Spider), което се различава от тяхната оценка на dev набора. Не бих цитирал 85,3% без тази уговорка.

Разликата при BIRD (50,72% dev) е забележимо по-малка от печалбите при Spider. Базите данни на BIRD имат разхвърляни реални схеми със съкратени имена на колони, терминология, специфична за домейна, и двусмислени стойности. Модулът за свързване на схеми на DIN-SQL е проектиран с оглед на сравнително чистите схеми на Spider; когато схемите станат по-неясни, точността на свързване пада и останалата част от конвейера се деградира заедно с нея. Това е точно това, което измери статията за BIRD, и DIN-SQL не го решава.

Разходите и числата за латентност са проблем за всяка производствена система: грубо $0,50 и 60 секунди на въпрос с GPT-4. Това е приемливо за анализатор на данни, изпълняващ десет заявки на ден, но напълно неизползваемо за интерактивна работа. Статията представя това като известно ограничение, но не предлага път за намаляването му. DAIL-SQL (arXiv:2308.15363), който се появи няколко месеца по-късно, ще покаже, че по-добрият избор на примери, вместо изрична декомпозиция, може да достигне 86,6% на Spider — надминавайки DIN-SQL при значително по-ниска цена.

Модулът за самокорекция е най-слабата част. Авторите признават, че той улавя „дребни“ грешки. Това, което не може да направи, е да открие семантични грешки — случаи, в които генерираният SQL е синтактично валиден и дори се изпълнява, но отговаря на грешен въпрос. Това е по-трудният режим на отказ за реалните потребители.

Защо това е важно за финансовия ИИ

Beanquery (BQL) е SQL-подобен език за заявки върху данни от Beancount леджър. Той има своя собствена структура на таблиците — transactions, postings, balance, prices — с йерархии на сметки, тагове и полета за метаданни, които не приличат на нищо в генеричните схеми на бази данни. Интерфейс на естествен език към BQL е реално и полезно нещо (вече има експериментален beanquery-mcp сървър, изпълняващ точно това чрез MCP) и стратегията за декомпозиция на DIN-SQL е правилната отправна точка.

Свързването на схеми над BQL е аналогичният проблем на свързването на схеми над релационни таблици, но с две допълнителни особености: имената на сметките са йерархични пътища като Assets:BG:Checking:Bank, а съответната схема зависи от това какъв вид заявка задава потребителят (отчет за приходите и разходите, баланс, паричен поток). Модулът за класификация на DIN-SQL предполага директна адаптация: първо класифицирайте намерението на заявката (баланс срещу поток срещу проверка на цени), след което насочете към различни шаблони за подкани.

Констатацията на бенчмарка BIRD, че реалната неподреденост вреди на LLM текст-към-SQL, е пряко релевантна. Beancount леджърът също е „разхвърлян“ — дефинирани от потребителя имена на сметки, непоследователни символи на активи, персонализирани ключове за метаданни. Подобрението от 4,4 пункта в BIRD срещу 6,8 пункта в Spider ми подсказва, че структурираният режим с чисти схеми надценява доколко декомпозицията ще помогне при реални BQL заявки. Очаквайте по-малки печалби на практика.

Ограничението в разходите е реално, но по-малко обвързващо тук. Потребител на лични финанси, изпълняващ 10–20 заявки на ден, може да толерира $5–10 на ден разходи за API, ако интерфейсът е наистина полезен. Латентността (60 секунди) е по-голям проблем за интерактивна употреба; пакетирането на аналитични заявки може да заобиколи това.

Какво да прочетете след това

• DAIL-SQL: Text-to-SQL Empowered by Large Language Models: A Benchmark Evaluation (arXiv:2308.15363) — систематично изследване на стратегии за инженеринг на подкани; постига 86,6% на Spider чрез фокусиране върху подбора на примери вместо върху архитектурна декомпозиция, полезен контрапункт на DIN-SQL.
• RESDSQL: Decoupling Schema Linking and Skeleton Parsing for Text-to-SQL (arXiv:2302.05965, AAAI 2023) — фино настроеният базов модел, който DIN-SQL победи; разбирането на това какво прави добре фино настроеният подход изяснява къде prompt-ването все още не достига.
• MAC-SQL: A Multi-Agent Collaborative Framework for Text-to-SQL (arXiv:2312.11242) — разширява идеята за многоетапна декомпозиция в изричен мулти-агентен конвейер със Selector, Decomposer и Refiner; достига 59,59% на BIRD с GPT-4 и е най-агентно-центрираният подход в тази сфера.