BIRD Бенчмарк: Разликата в реалните бази данни при LLM Text-to-SQL

Бенчмаркът BIRD (NeurIPS 2023 Spotlight) е статията, която все се каня да прочета, когато някой започне да твърди, че GPT-4 може да „прави заявки към база данни на чист английски“. Той поставя един остър въпрос: могат ли LLM действително да служат като интерфейс за бази данни върху реални бази данни, а не върху академични играчки-схеми? Отговорът е отрезвяващ по начини, които се припокриват почти директно с това, пред което би се изправил един слой за заявки на естествен език за дневници на Beancount.

Статията

„Can LLM Already Serve as A Database Interface? A BIg Bench for Large-Scale Database Grounded Text-to-SQLs“ от Jinyang Li и голям екип от DAMO Academy, HKU, UIUC и други представя BIRD: 12 751 двойки въпрос–SQL върху 95 реални бази данни с общ размер 33,4 GB в 37 професионални области. Този мащаб е важен. Spider и WikiSQL, двата бенчмарка, които доминираха изследванията на text-to-SQL преди това, използват малки чисти бази данни с най-много няколкостотин реда. BIRD използва бази данни, взети от реални институции — финансови записи, токсикологични доклади, държавни масиви от данни — където стойностите са „мръсни“, семантиката на колоните изисква познаване на домейна, а ефективността на заявките всъщност има значение. Статията представя и две метрики: точност на изпълнение (Execution Accuracy - EX), която проверява дали резултатът от SQL съвпада с истинския отговор, и валиден резултат за ефективност (Valid Efficiency Score - VES), който наказва правилни, но бавни заявки.

Основни идеи

• GPT-4 постига само 54,89% точност на изпълнение на тестовия набор, когато се предоставят подбрани доказателства от външни знания. Без тези доказателства тя пада до 34,88% — разлика от 20 процентни пункта, която разкрива доколко моделът разчита на предоставените насоки, а не на собствените си познания за света.
• Представянето на хората е 92,96% в набора за разработка (dev set), оставяйки разлика от 38 пункта, дори след като на GPT-4 е даден контекстът на домейна на отговорите.
• Външните знания се предоставят като „изречение с доказателство“ за всеки въпрос (напр. „account.type = 'OWNER' означава, че титулярът на сметката е основният собственик“). Модели, които не могат да извлекат или изведат този контекст сами, на практика са спънати от самото начало.
• Финансовият домейн, който е най-подходящ за Beancount, има най-висок процент на шум в анотациите: последващ одит установи, че приблизително 49% от данните във финансовия домейн съдържат някаква грешка — правописни грешки, двусмислени въпроси или неправилни златни SQL заявки.
• Класацията се промени значително от публикуването насам. Към 2026 г. водещата система (AskData + GPT-4o) достига 81,95% на тестовия набор, докато човешкото представяне все още е около 92,96%, но разликата е затворена главно чрез сложни многоетапни конвейери, а не чрез сурови възможности на модела.

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

Основният принос остава: бенчмарковете в стил Spider наистина подцениха трудността на text-to-SQL чрез използване на санирани схеми. Настояването на BIRD за реални стойности в базите данни и външни знания разкрива видове откази, които никога не се появяват при чисти данни, а разликата от 20 процентни пункта при добавяне на доказателства е възпроизводимо и важно откритие.

Но бенчмаркът има проектен недостатък, който собствената му последваща работа признава. Доказателствата за външни знания са написани на ръка за всяка заявка от анотатори с експертиза в домейна. Това не е реалистичен сценарий за внедряване. Един истински NL-to-SQL агент не получава предварително написана насока за всеки въпрос; той трябва сам да извлече или да изведе съответния контекст на домейна. Статията SEED (2025) показва, че автоматично генерираните доказателства могат да съвпаднат или да надминат ръчно написаните доказателства в някои настройки, което отслабва имплицитното предположение на BIRD, че тясното място в знанията е трудната част.

Одитът за шум е още по-вреден. Двайсет и две златни SQL заявки в набора от данни са откровено грешни. Когато те бъдат коригирани, класирането на моделите се променя: zero-shot GPT-3.5 превъзхожда DIN-SQL и MAC-SQL, които са проектирани да побеждават GPT-3.5 в некоригирания бенчмарк. Това е червен флаг. Бенчмарк, чието класиране се обръща при почистване, ни учи на артефакти от анотация толкова, колкото и на възможности на модела. 49-процентният процент шум във финансовия домейн в частност прави изводите, специфични за домейна, ненадеждни.

Съществува и по-незабележим проблем с VES. Възнаграждаването на ефективността на заявките е разумна цел от реалния свят, но за да може един бенчмарк да обучава и оценява ефективността, са необходими обективни данни за това какво означава „ефективно“ за конкретен двигател на база данни и разпределение на данните. VES работи тук, защото BIRD контролира средата на изпълнение. Това условие не би важало за агент на Beancount, изпълняващ beanquery срещу личния дневник на потребителя на хетерогенен хардуер.

Защо това е важно за финансовия изкуствен интелект

Езикът за заявки на Beancount, BQL (достъпен чрез CLI bean-query и библиотеката beanquery), е синтактично близък до SQL: поддържа SELECT, WHERE, GROUP BY, агрегиращи функции и съединения в вградените таблици с записи и баланси. Интерфейс на естествен език, който превежда потребителските въпроси в BQL, е най-естественият начин за навлизане на нетехнически потребители, а откритията на BIRD директно очертават предизвикателството.

Проблемът с външните знания в BIRD се пренася чисто към Beancount. Потребител може да попита „колко похарчих за медицински разходи миналата година?“ и агентът трябва да знае, че медицинските разходи на потребителя се намират под Expenses:Health:* или Expenses:Medical, в зависимост от това как са организирани сметките им. Това картографиране е лично, не присъства в нито един корпус за обучение. Откритието на BIRD, че GPT-4 губи 20 точки без доказателства, предполага, че всеки агент за генериране на BQL се нуждае от стъпка за извличане, която научава собствената таксономия на сметките на потребителя — по същество база знания за всеки потребител.

Проблемът с „мръсните“ данни също се пренася директно. Импортираните банкови транзакции често имат непоследователни имена на търговци, OCR артефакти и смесени кодирания. BIRD количествено определя какво струва това по отношение на коректността на SQL и числото е достатъчно голямо, за да превърне предварителната обработка в първостепенна грижа, а не в нещо оставено за накрая.

Какво не покрива BIRD: специфичните за счетоводната книга конструкции като balance assertions, pad директиви или записи в няколко валути нямат еквивалент в стандартния SQL, така че всеки BQL агент ще се изправи пред слой сложност, който BIRD не измерва. Бенчмаркът е полезна долна граница, а не таван.

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

• Spider 2.0: Evaluating Language Models on Real-World Enterprise Text-to-SQL Workflows (arXiv:2502.04306, ICLR 2025 Oral) — разширява BIRD към корпоративни среди с облачни бази данни и работни процеси с множество файлове; естествената следваща стъпка за разбиране на пропуските при реално внедряване.
• SEED: Enhancing Text-to-SQL Performance and Practical Usability Through Automatic Evidence Generation (arXiv:2506.07423) — директно адресира предположението на BIRD за ръчно написани доказателства с автоматизиран конвейер.
• DIN-SQL: Decomposed In-Context Learning of Text-to-SQL with Self-Correction (arXiv:2304.11015, NeurIPS 2023) — една от най-добрите базови линии на BIRD; показва как разлагането на сложна SQL заявка на подпроблеми подобрява точността – техника, директно приложима към многоетапни BQL заявки върху дневници на Beancount.