Бенчмарк BIRD: Розрив між реальними базами даних у Text-to-SQL для LLM

Бенчмарк 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», написана Цзіньяном Лі та великою командою з DAMO Academy, HKU, UIUC та інших установ, представляє BIRD: 12 751 пару «питання–SQL» для 95 реальних баз даних загальним обсягом 33,4 ГБ у 37 професійних доменах. Саме в масштабі полягає суть. Spider і WikiSQL, два бенчмарки, що домінували в дослідженнях text-to-SQL до цього, використовують невеликі чисті бази даних, що містять максимум кілька сотень рядків. BIRD використовує бази даних, взяті з реальних установ — фінансові звіти, токсикологічні звіти, державні набори даних — де значення «брудні», семантика колонок потребує знання предметної області, а ефективність запитів справді має значення. Стаття також вводить дві метрики: точність виконання (Execution Accuracy, EX), яка перевіряє, чи відповідає результат SQL еталонній відповіді, і валідний показник ефективності (Valid Efficiency Score, VES), який штрафує правильні, але повільні запити.

Ключові ідеї

• GPT-4 досягає лише 54,89% точності виконання на тестовому наборі, коли надаються підготовлені докази зовнішніх знань. Без цих доказів показник падає до 34,88% — розрив у 20 відсоткових пунктів, який показує, наскільки модель покладається на надані підказки, а не на власні знання про світ.
• Результативність людини на наборі для розробки (dev set) становить 92,96%, що залишає розрив у 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-запити в наборі даних є відверто помилковими. Коли їх виправляють, рейтинги моделей змінюються: GPT-3.5 у режимі zero-shot випереджає DIN-SQL та MAC-SQL, які були розроблені, щоб перемогти GPT-3.5 на невиправленому бенчмарку. Це тривожний сигнал. Бенчмарк, рейтинги якого змінюються після очищення, вчить нас особливостям анотування так само само, як і можливостям моделей. Зокрема, рівень шуму у 49% у фінансовому домені робить специфічні для домену висновки ненадійними.

Також існує тонка проблема з VES. Винагорода за ефективність запитів є розумною практичною метою, але для того, щоб бенчмарк міг навчати та оцінювати ефективність, потрібна істина (ground truth) щодо того, що означає «ефективний» для конкретного рушія бази даних та розподілу даних. VES працює тут, тому що BIRD контролює середовище виконання. Ця умова не виконувалася б для агента Beancount, що запускає beanquery для особистого леджера користувача на різнорідному обладнанні.

Чому це важливо для фінансового ШІ

Мова запитів Beancount, BQL (доступна через CLI bean-query та бібліотеку beanquery), синтаксично близька до SQL: вона підтримує SELECT, WHERE, GROUP BY, агрегаційні функції та з'єднання (joins) у вбудованих таблицях проводок (postings) та балансів. Інтерфейс природною мовою, який перекладає запитання користувачів у BQL, є найбільш природним способом входу для нетехнічних користувачів, і висновки BIRD безпосередньо окреслюють цей виклик.

Проблема зовнішніх знань у BIRD чітко переноситься на Beancount. Користувач може запитати: «Скільки я витратив на медичні витрати минулого року?», і агент повинен знати, що медичні витрати цього користувача знаходяться під Expenses:Health:* або Expenses:Medical, залежно від того, як він організував свої рахунки. Це відображення є персональним і не міститься в жодному навчальному корпусі. Висновок BIRD про те, що GPT-4 втрачає 20 пунктів без доказів, свідчить про те, що будь-який агент для генерації BQL потребує кроку пошуку (retrieval), який вивчає власну таксономію рахунків користувача — фактично, базу знань для кожного користувача.

Проблема «брудних» даних також переноситься безпосередньо. Імпортовані банківські транзакції часто мають непослідовні назви продавців, артефакти OCR та змішані кодування. BIRD кількісно оцінює, чого це коштує з точки зору правильності SQL, і це число достатньо велике, щоб зробити попередню обробку першочерговим завданням, а не другорядною думкою.

Чого BIRD не охоплює: специфічні для леджера конструкції, такі як твердження про баланс (balance assertions), директиви доповнення (pad directives) або мультивалютні проводки, не мають еквівалентів у стандартному 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.