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

Бенчмарк BIRD (NeurIPS 2023 Spotlight) — это работа, к которой я возвращаюсь всякий раз, когда кто-то утверждает, что GPT-4 может «запрашивать базу данных на простом английском». В ней ставится острый вопрос: могут ли LLM на самом деле служить интерфейсом для реальных баз данных, а не для академических «игрушечных» схем? Ответ отрезвляет, и он напрямую соотносится с тем, с чем столкнется слой запросов на естественном языке для журналов Beancount.

О статье

«Может ли LLM уже служить интерфейсом базы данных? Большой бенчмарк для преобразования текста в SQL на основе крупномасштабных баз данных» (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% на тестовом наборе, когда ей предоставляются специально отобранные внешние знания (evidence). Без этих данных точность падает до 34,88% — разрыв в 20 процентных пунктов, который показывает, насколько модель полагается на предоставленные подсказки, а не на собственные знания о мире.
• Результативность человека на наборе для разработки составляет 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. Поощрение эффективности запросов — разумная цель для реального мира, но чтобы бенчмарк мог обучать и оценивать эффективность, нужны достоверные данные о том, что значит «эффективный» для конкретного движка базы данных и распределения данных. 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 нужен этап поиска (retrieval), который изучает собственную таксономию счетов пользователя — по сути, базу знаний для каждого пользователя.

Проблема «грязных» данных также переносится напрямую. Импортированные банковские транзакции часто имеют непоследовательные названия торговых точек, артефакты 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.