Несколько месяцев назад я писал о том, почему нам может не понадобиться семантический слой<\/a>. Аргумент заключался в том, что ИИ может обнаруживать бизнес-логику из истории запросов, вместо того чтобы заставлять людей заранее определять каждую метрику. Я верил в это. Но у меня не было данных, чтобы это доказать.<\/p>\n Теперь они у меня есть.<\/p>\n Все началось с вопроса одного из наших инвесторов: *“Как различные модели справляются с BIRD при использовании MotherDuck MCP?”* Поэтому я провел эксперимент. Три передовые LLM модели (`Claude Opus 4.5`, `GPT-5.2` и `Gemini 3 Flash`), каждая из которых подключена к базе данных через сервер `MotherDuck MCP`, были запущены на наборе данных `BIRD Mini-Dev`.<\/p>\n Пояснение:<\/b><\/p>\n Модели данных здесь простые. В среднем 7 таблиц на базу данных. Ни в одной нет больше 13 таблиц. Объединения (joins) в основном «один-ко-многим», максимальная глубина — два или три перехода, ноль отношений «многие-ко-многим». Это тот тип схемы, который можно понять за пять минут, прочитав `DDL`.<\/p>\n Пояснение:<\/b> `DDL` (Data Definition Language) — это часть SQL, используемая для описания структуры базы данных (создание таблиц, колонок, связей).<\/p>\n<\/blockquote>\n Результат? 95% точности.<\/b> Никакого семантического слоя. Никакой истории запросов. Никакого специального контекста. Только схема базы данных.<\/p>\n Но это число требует «звездочки» (примечания), и, честно говоря, эта звездочка — самая интересная часть.<\/p>\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
\n
Что на самом деле означают 95%<\/h3>\n
![\"\"](\"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2026-02-13-v-01.58.40.png\")
\n<\/div>\n![\"\"](\"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2026-02-13-v-01.59.13.png\")
\n<\/div>\n