Все началось с вопроса одного из наших инвесторов: *“Как различные модели справляются с BIRD при использовании MotherDuck MCP?”* Поэтому я провел эксперимент. Три передовые LLM модели (`Claude Opus 4.5`, `GPT-5.2` и `Gemini 3 Flash`), каждая из которых подключена к базе данных через сервер `MotherDuck MCP`, были запущены на наборе данных `BIRD Mini-Dev`.<\/p>\n
\nПояснение:<\/b><\/p>\n\n- MCP (Model Context Protocol):** Стандарт, позволяющий ИИ-моделям безопасно и стандартизировано подключаться к внешним источникам данных и инструментам.<\/li>\n
- BIRD (BIg Bench for Large-scale Database Grounded Text-to-SQL):** Популярный и сложный бенчмарк (набор тестов) для оценки того, насколько хорошо нейросети умеют переводить естественный язык в SQL-запросы.<\/li>\n
- Mini-Dev:** Это официальная выборка из 500 вопросов для разработки из бенчмарка BIRD. Она охватывает 11 баз данных в сферах финансов, спорта, образования и здравоохранения.<\/li>\n<\/ul>\n<\/blockquote>\n
Модели данных здесь простые. В среднем 7 таблиц на базу данных. Ни в одной нет больше 13 таблиц. Объединения (joins) в основном «один-ко-многим», максимальная глубина — два или три перехода, ноль отношений «многие-ко-многим». Это тот тип схемы, который можно понять за пять минут, прочитав `DDL`.<\/p>\n
\nПояснение:<\/b> `DDL` (Data Definition Language) — это часть SQL, используемая для описания структуры базы данных (создание таблиц, колонок, связей).<\/p>\n<\/blockquote>\n
Результат? 95% точности.<\/b> Никакого семантического слоя. Никакой истории запросов. Никакого специального контекста. Только схема базы данных.<\/p>\n
Но это число требует «звездочки» (примечания), и, честно говоря, эта звездочка — самая интересная часть.<\/p>\n
Что на самом деле означают 95%<\/h3>\n
Вот что я измерял на самом деле.<\/p>\n
Бенчмарк BIRD оценивает точность, используя Execution Accuracy (EX)<\/b>: запускается предсказанный SQL и «золотой» (эталонный) SQL, сравниваются наборы результатов, и ставится бинарная оценка «сдал\/не сдал». При этих строгих правилах текущий уровень развития технологий (SOTA) составляет около 76. Мои модели набрали 64 на тренировочной выборке и 58 на тестовой.<\/p>\n
Звучит плохо. Но у строгой оценки BIRD есть хорошо задокументированная проблема. В статье 2025 года, представляющей метрику `FLEX`, было обнаружено, что точность выполнения (execution accuracy) BIRD совпадает с оценками экспертов-людей только в 62% случаев. Почти 4 из 10 суждений ошибочны, в основном это ложноотрицательные результаты, когда бенчмарк отвергает ответы, которые люди бы приняли.<\/p>\n
Эти 62 бросились мне в глаза, потому что они почти точно совпадают с моей смешанной точностью при строгой оценке в 60.5 (64 обучение \/ 58 тест). То же наблюдение, но с другой стороны. Метрика `FLEX` пришла к этому с помощью проверяющих людей. Я пришел к этому, ослабив условия тестирования.<\/p>\n
Подумайте, что это значит для таблицы лидеров. Если бенчмарк согласен с людьми только в 62 случаев, то чтобы набрать выше 62 по строгим правилам, вы должны начать воспроизводить ошибки бенчмарка. Вы перестаете учиться писать правильный SQL. Вы начинаете учиться соответствовать специфической, иногда ошибочной интерпретации каждого вопроса в BIRD. Системы с рейтингом 76 закрепили эти ошибки суждения в своем обучении. Они получают более высокие баллы, становясь *хуже* в выполнении реальной задачи.<\/p>\n
Поэтому я построил более реалистичную оценку. Я разделил 500 вопросов на тренировочный набор (151 вопрос) и тестовый набор (349 вопросов).<\/p>\n
Я использовал тренировочный набор (train)<\/b> для калибровки оценки: вручную пересматривал ошибки, создавал исправленные «платиновые» ответы там, где «золотой» SQL BIRD был ошибочным, и настраивал правила частичного совпадения. Тестовый набор (test)<\/b> был контрольным.<\/p>\n
Вот как выглядит точность, если смягчать критерии оценки уровень за уровнем:<\/p>\n
\n\n| Уровень оценки (Scoring Tier)<\/td>\n | Train<\/td>\n | Test<\/td>\n | Что добавляется<\/td>\n<\/tr>\n |
\n| Только совпадение с Gold<\/b> (≈ офиц. BIRD)<\/td>\n | 64.0<\/td>\n | 58.2<\/td>\n | Строгое равенство наборов результатов<\/td>\n<\/tr>\n |
\n| + Платиновые ответы<\/b><\/td>\n | 73.1<\/td>\n | 58.5<\/td>\n | Исправляет известные ошибки в «золотом» SQL BIRD (см. примечание ниже)<\/td>\n<\/tr>\n |
\n| + Допуск форматирования<\/b><\/td>\n | 78.8<\/td>\n | 65.5<\/td>\n | Различия в `DISTINCT`, лишние колонки, округление<\/td>\n<\/tr>\n |
\n| + Судья LLM<\/b><\/td>\n | 94.9<\/td>\n | 94.4<\/td>\n | “Принял бы человек этот ответ?”<\/td>\n<\/tr>\n<\/table>\n\nПримечание:<\/b> «Платиновые» исправления существуют только для тренировочного набора, так как я вручную проверил эти 151 вопрос. Вот почему уровень «Платина» почти не меняется на тесте +0.3 pp против +9.1 pp на тренировке). Но посмотрите на уровень с судьей: 94.9 на тренировке и 94.4 на тесте. Разница всего в половину процентного пункта. Оценка держится на контрольной выборке даже без моих исправлений вручную.<\/p>\n<\/blockquote>\nРезультаты тренировочной выборки (151 вопрос, все 3 модели):<\/h4>\n\n\n| Модель<\/td>\n | STRICT (≈ BIRD EX)<\/td>\n | REALISTIC<\/td>\n | Общая стоимость<\/td>\n | Вызовы инструментов (P5 \/ Median \/ P95)<\/td>\n<\/tr>\n | \n| `Gemini 3 Flash`<\/td>\n | 68.2<\/td>\n | 94.0<\/td>\n | 1.80<\/td>\n | 3 \/ 6 \/ 9<\/td>\n<\/tr>\n | \n| `Claude Opus 4.5`<\/td>\n | 64.9<\/td>\n | 95.4<\/td>\n | 26.37<\/td>\n | 4 \/ 6 \/ 9<\/td>\n<\/tr>\n | \n| `GPT-5.2`<\/td>\n | 58.9<\/td>\n | 95.4<\/td>\n | 6.87<\/td>\n | 4 \/ 7 \/ 12<\/td>\n<\/tr>\n<\/table>\nРезультаты тестовой выборки (349 вопросов, 2 модели):<\/h4>\n\n\n| Модель<\/td>\n | STRICT (≈ BIRD EX)<\/td>\n | REALISTIC<\/td>\n | Общая стоимость<\/td>\n | Вызовы инструментов (P5 \/ Median \/ P95)<\/td>\n<\/tr>\n | \n| `Gemini 3 Flash`<\/td>\n | 60.7<\/td>\n | 94.6<\/td>\n | 3.96<\/td>\n | 4 \/ 6 \/ 9<\/td>\n<\/tr>\n | \n| `GPT-5.2`<\/td>\n | 55.6<\/td>\n | 94.3<\/td>\n | 15.32<\/td>\n | 4 \/ 7 \/ 11<\/td>\n<\/tr>\n<\/table>\n\n*Примечание: `Claude Opus` не запускался на тестовом наборе. После того как все три модели сошлись на ~95% на тренировке, тратить еще 60+, чтобы доказать то же самое на 349 вопросах, показалось нецелесообразным.*<\/p>\n<\/blockquote>\n Медианная модель делает 6-7 вызовов инструментов MCP на вопрос при лимите в 10 итераций. Типичный вопрос выглядит так: изучить схему, просмотреть некоторые колонки, набросать запрос, проверить результаты, уточнить, готово. Некоторые модели, такие как `GPT-5.2`, делают несколько вызовов инструментов за итерацию, поэтому его показатель P95, равный 12, превышает лимит итераций.<\/p>\n Все три модели достигают 94-95% при реалистичной оценке<\/b>, независимо от того, где они начинают при строгой оценке. На тренировочной выборке разрыв между «лучшим» и «худшим» сокращается с 12.6 процентных пунктов до 1.4. На тесте — с 5.1 до 0.3. Берите любую передовую модель.<\/p>\nБенчмарк иногда ошибается<\/h3>\n BIRD — хороший бенчмарк. Но в нем есть баги. Только в тренировочном наборе (151 вопрос) я нашел 49 случаев, где «золотой» SQL явно неверен. Я не проверял вручную тестовый набор, поэтому реальное число для всех 500 вопросов, вероятно, выше.<\/p>\n Вот пример, который мне запомнился. Вопрос просит список школ, чей совокупный балл превышает 1500. «Золотой» SQL проверяет `count` (количество) студентов, набравших более 1500 баллов. Совершенно другой запрос, совершенно другой ответ. Вы читаете вопрос, читаете «правильный» ответ и думаете: подождите, но спрашивали-то не об этом.<\/p>\n Я создал исправленные «платиновые» ответы для этих случаев. В среднем около 14 из 151 вопроса тренировочной выборки для каждой модели совпали с платиновым ответом вместо золотого, добавив 9.1 процентных пунктов.<\/p>\n Людей не волнует форматирование<\/h3>\nНа тренировочной выборке еще +5.7 pp получается за счет принятия результатов, которые верны по существу, но не проходят проверку на строгое равенство:<\/p>\n \n- Лишние колонки (30 случаев):<\/b> Модель вернула запрошенные данные плюс дополнительный контекст. Человек сказал бы «спасибо, это полезно». Бенчмарк говорит «провал».<\/li>\n
- Несовпадения `DISTINCT` (41 случай):<\/b> Модель использовала `SELECT DISTINCT`, когда в золотом ответе этого не было, или наоборот. Уникальные значения совпадают идеально. Человек бы даже не заметил.<\/li>\n
- Различия в округлении (3 случая):<\/b> Золотой ответ 24.67, ответ модели 24.6667. То же число, разная точность.<\/li>\n<\/ul>\n
Ни один из этих ответов не является неверным. Это различия в форматировании, которые важны только для функции сравнения строк.<\/p>\n Человек (LLM)-в-петле (The LLM-in-the-Loop)<\/h3>\nОставшийся разрыв (16 pp на тренировке, 29 pp на тесте) закрывается судьей LLM<\/b>. Я использовал `Gemini 3 Flash` для проверки каждого «проваленного» ответа с вопросом: *действительно ли этот SQL отвечает на вопрос?*<\/p>\n На тестовой выборке судья выполняет больше тяжелой работы, потому что там нет «платиновых» исправлений для предварительного отлова багов бенчмарка. Что именно он спасал?<\/p>\n \n\n| Причина<\/td>\n | Кол-во<\/td>\n | Что произошло<\/td>\n<\/tr>\n | \n| Больше отфильтровано<\/b> (Missing rows)<\/td>\n | 57<\/td>\n | Модель отфильтровала строже, чем золотой стандарт, но это обоснованно.<\/td>\n<\/tr>\n | \n| Лишние строки<\/b> (Extra rows)<\/td>\n | 33<\/td>\n | Модель интерпретировала вопрос более широко.<\/td>\n<\/tr>\n | \n| Близкие значения<\/b> (Values close)<\/td>\n | 19<\/td>\n | Числовые результаты в пределах допуска.<\/td>\n<\/tr>\n | \n| Пустой результат<\/b><\/td>\n | 14<\/td>\n | Модель ничего не вернула, но логика была верной (данных нет).<\/td>\n<\/tr>\n | \n| Пропущенные колонки<\/b><\/td>\n | 11<\/td>\n | Возвращено меньше колонок, но ответ на вопрос дан.<\/td>\n<\/tr>\n<\/table>\n Это оценочные суждения. Должен ли запрос «перечислите все школы в районе» включать чартерные школы? Разумные люди могут не согласиться. Строгий бенчмарк выбирает одну интерпретацию и наказывает за все остальные. Судья просто спрашивает, можно ли обосновать интерпретацию модели.<\/p>\n Если вы создаете ИИ-аналитику, это важно. Никто не выпускает продукт text-to-SQL, где пользователь видит сырые результаты без этапа проверки. Всегда есть человек или LLM, проверяющий выходные данные. Эти 94-95% отражают то, как эти продукты работают на самом деле. 58-64% отражают то, как работают бенчмарки.<\/p>\n А как насчет контекста?<\/h3>\nВы могли бы ожидать, что дополнительный контекст поможет. Комментарии к колонкам, описания, подсказки о значении данных. Это интуиция, лежащая в основе семантических слоев и механизмов контекста.<\/p>\n Я протестировал это. Те же 500 вопросов, все модели, с комментариями к колонкам каждой таблицы и без них.<\/p>\n \n\n| Схема<\/td>\n | Train<\/td>\n | Test<\/td>\n<\/tr>\n | \n| Без комментариев<\/b><\/td>\n | 94.9<\/td>\n | 94.4<\/td>\n<\/tr>\n | \n| С комментариями<\/b><\/td>\n | 96.0<\/td>\n | 94.6<\/td>\n<\/tr>\n | \n| Дельта<\/b><\/td>\n | 1.1 pp<\/td>\n | 0.2 pp<\/td>\n<\/tr>\n<\/table>\n Один процентный пункт на тренировке, почти ничего на тесте. В большинстве вопросов правильность не изменилась.<\/p>\n Если разбить по базам данных, становится интересно. Чем сложнее схема, тем больше помогают комментарии (усредненно по train и test):<\/p>\n \n\n| База данных<\/td>\n | Базовая точность<\/td>\n | Эффект комментариев<\/td>\n<\/tr>\n | \n| `debit_card_specializing`<\/td>\n | 85.5 (самая сложная)<\/td>\n | 8.7 pp<\/td>\n<\/tr>\n | \n| `european_football_2`<\/td>\n | 93.2<\/td>\n | 3.4 pp<\/td>\n<\/tr>\n | \n| `california_schools`<\/td>\n | 95.7 (самая легкая)<\/td>\n | 2.9 pp<\/td>\n<\/tr>\n<\/table>\n Комментарии помогают, когда схема действительно запутанная. Таблица `debit_card_specializing` (попробуйте угадать, как выглядит эта схема) получила самый большой прирост. Но схемы с интуитивными названиями и очевидными связями? Там комментарии сделали только хуже. У моделей уже сформировалась правильная ментальная модель, а комментарии внесли шум.<\/p>\n Каждый разработчик знает это о комментариях в коде. Полезны при реальной неоднозначности. Вредны, когда констатируют очевидное. `\/\/ увеличить i на 1` еще никому не помогло.<\/p>\n Почему простые модели данных работают<\/h3>\nБазы данных BIRD — это не корпоративные хранилища данных. Они простые:<\/p>\n \n- 7 таблиц в среднем.<\/li>\n
- 9 внешних ключей в среднем, в основном «один-ко-многим».<\/li>\n
- Ноль связей «многие-ко-многим».<\/li>\n
- Глубина join макс. 2-3 перехода, нет глубоких иерархий.<\/li>\n<\/ul>\n
LLM читают эти схемы так же, как опытный аналитик читает DDL. Они видят таблицу `schools` с колонками `school_name`, `district` и `enrollment`, и они знают, что делать. Внешний ключ от `schools` к `scores`? Они знают, как их соединить (join). Никому не нужен семантический слой, чтобы объяснить, что “enrollment” означает «количество студентов».<\/p>\n Хорошее моделирование данных — это и есть семантический слой.<\/b> Когда ваши таблицы названы хорошо, а объединения прямолинейны, у LLM есть всё необходимое.<\/p>\nВо что я бы инвестировал в первую очередь<\/h3>\n Каждая среда уникальна, но вот как бы я расставил приоритеты, основываясь на том, что увидел:<\/p>\n \n- Начните с модели данных.<\/b> Чистые таблицы, понятные названия, простые объединения. Если опытный аналитик может посмотреть на вашу схему и понять ее за несколько минут, то и LLM сможет.<\/li>\n
- Затем добавьте целевой контекст.<\/b> Комментарии к колонкам и метаданные, но только там, где действительно существует путаница. Документируйте таблицы типа `debit_card_specializing`, а не `schools`.<\/li>\n
- История запросов идет следом.<\/b> Она становится важнее по мере усложнения предметной области, особенно для обнаружения недокументированных бизнес-правил (вроде “abnormal GOT > 60”). Базы данных BIRD имеют простые правила. Но я работаю над (проектом) `DABstep`, у которого простая модель данных, но очень сложные правила предметной области. Тот вид знаний, который живет в головах людей, а не в названиях колонок. Там история запросов и подобранный контекст будут значить гораздо больше. Но даже тогда чистая модель данных стоит на первом месте.<\/li>\n<\/ol>\n
Наконец, не беспокойтесь о формальном семантическом слое. Если ваша модель данных чиста, а контекст целенаправлен, это почти ничего не добавляет для сценариев использования ИИ. На самом деле, кажется, что это даже мешает, так как ИИ отлично пишет SQL, но менее хорош в работе с другими инструментами.<\/p>\n Начните сейчас<\/h3>\nПланка для «данных, готовых к ИИ», ниже, чем вам говорит индустрия.<\/p>\n Вам не нужен “движок контекста”, семантический слой, годы истории запросов или специализированная платформа метаданных. Вам нужна чистая модель данных и LLM<\/b>. Найдите домен, который готов к этому, и начните там.<\/p>\n Разрыв между «точностью бенчмарка» и «примет ли это человек?» составил 31 pp на тренировочной выборке и 36 pp на тестовой. Это огромный разрыв, и он закрывается в тот момент, когда вы включаете человека или LLM в цикл проверки. Именно так и работает любой продукт ИИ-аналитики.<\/p>\n Если ваша модель данных чиста, начните сегодня. Направьте LLM на вашу схему и задавайте вопросы. Если ваша модель данных не чиста, теперь вы знаете, с чего начать.<\/p>\n ***<\/p>\n Итоги статьи<\/h4>\n\n- Проблема:<\/b> Принято считать, что для работы ИИ с базами данных (Text-to-SQL) нужны сложные семантические слои, история запросов и контекст.<\/li>\n
- Эксперимент:<\/b> Автор протестировал работу современных LLM (Claude, Gemini, GPT) на известном наборе данных BIRD.<\/li>\n
- Открытие 1:<\/b> Формальные бенчмарки занижают качество работы ИИ. Они требуют строгого совпадения SQL-запросов, хотя люди принимают ответы с правильными данными, но другим форматированием (лишние колонки, другой порядок сортировки). Истинная (“реалистичная”) точность моделей достигает 95%<\/b>, тогда как бенчмарк показывает около 60%.<\/li>\n
- Открытие 2:<\/b> “Готовность данных к ИИ” сводится к понятной структуре базы данных. Чистые таблицы, внятные названия колонок и простые связи работают лучше, чем нагромождение комментариев.<\/li>\n
- Открытие 3:<\/b> Дополнительные комментарии (контекст) нужны только для реально запутанных схем. В простых случаях они даже мешают, создавая шум.<\/li>\n
- Вывод:<\/b> Не тратьте ресурсы на сложные семантические надстройки. Инвестируйте в чистоту модели данных<\/b> (понятные имена таблиц и полей). Хорошая модель данных — это и есть лучший семантический слой для ИИ.<\/li>\n<\/ol>\n",
"date_published": "2026-03-14T00:19:28+03:00",
"date_modified": "2026-03-14T00:19:21+03:00",
"tags": [
"AI",
"big data",
"Data",
"MCP"
],
"_date_published_rfc2822": "Sat, 14 Mar 2026 00:19:28 +0300",
"_rss_guid_is_permalink": "false",
"_rss_guid": "321",
"_rss_enclosures": [],
"_e2_data": {
"is_favourite": false,
"links_required": [],
"og_images": []
}
}
],
"_e2_version": 4171,
"_e2_ua_string": "Aegea 11.4 (v4171e)"
}
| | | | | |