Как устроен экзамен для ИИ
Корпоративные базы, большие схемы и проблема золотого эталона
Представьте: вы аналитик университета. Перед вами хранилище — тысячи таблиц, годы истории, миллионы строк. Вы пишете в чат: «среднее число записавшихся на математические кафедры за пять лет». Нейросеть уверенно выдаёт SQL. Запускаете — пустая таблица. Или, хуже, красивые цифры, которые ни с чем не сходятся.
Что пошло не так? И как вообще понять, насколько хорошо машина говорит с базой?
Нельзя просто «попробовать»
У нейросети нет интуиции. Она не знает, права ли, — пока её не проверят. А проверить вручную почти невозможно: корпоративное хранилище — это легко две тысячи таблиц и десятки тысяч колонок. Тысяча вопросов «на глаз» — месяцы работы.
Отсюда бенчмарки — стандартизованные экзамены для моделей. Коллекция вопросов на естественном языке, к каждому — эталонный SQL. Модель отвечает; ответ сверяют с эталоном. Звучит просто. На практике — минное поле.
Первые экзамены: слишком лёгкие
Первое поколение — конец 2010-х. WikiSQL (2017): вопросы к таблицам Википедии, «кто забил больше всех в матче X». Spider (2018) — сложнее: несколько таблиц, вложенные запросы, GROUP BY. Модели взяли 80–90% — и продолжили расти.
Казалось — победа. Но в 2022-м выяснилось: модель с 91% на Spider на реальной корпоративной базе права меньше чем в 10% случаев. Она выучила экзамен, а не научилась работать с данными.
Причина системная: тренировочные данные бенчмарка просочились в модель при обучении — и она просто запомнила ответы. Студент, зазубривший прошлогодние билеты, не понимая предмета.
Новое поколение: ближе к реальности
Ответ исследователей — бенчмарки сложнее, реалистичнее, труднее «зазубрить».
Spider 2.0 (2025) принёс промышленные диалекты: BigQuery, Snowflake, SQLite. Вопросы требуют рассуждения в несколько шагов, представлений, оконных функций. 256 выверенных вопросов — GPT-4 берёт около 10%.
BEAVER пошёл дальше. Расшифровка — «Benchmark for Evaluating Automated Very-large-schema Entity Retrieval», поиск сущностей в очень больших схемах. Реальное хранилище крупного университета: десятки лет истории, 5787 вопросов. Вопросы писали настоящие аналитики — те, кто каждый день работает именно с этими данными.
DABstep (2025, arXiv) проверяет не отдельный запрос, а весь процесс: агент должен найти данные, свести несколько источников, принять промежуточные решения. Это уже ближе к тому, как ИИ используют вживую.
Как ставят оценку: execution oracle
Самый строгий способ проверить ответ — запустить его.
На этом стоит главная метрика — execution accuracy. Берут эталонный запрос эксперта, запускают на реальной базе. Запускают запрос модели. Совпали результирующие таблицы — зачёт.
Изящно: неважно, как запрос написан. Важно, что он возвращает. Модель может пойти через другие таблицы, другие JOIN'ы — и всё равно получить зачёт, если результат верен.
Цена — живая база. Исследователи поднимают снапшот, замороженную копию данных на момент времени, и прогоняют по ней все запросы. Это и есть execution oracle: эталон задан самим фактом выполнения.
Альтернатива — аннотация: люди вручную размечают, какие таблицы и колонки нужны под вопрос, и модель меряют точностью этой разметки. Дешевле — но слабее: можно угадать таблицы и всё равно написать неверный запрос.
Пять подзадач: анатомия провала
BEAVER сделал тонкий ход: не одна метрика, а пять подзадач. Чтобы видеть, где именно ломается модель.
1. Поиск таблиц (table retrieval). Из всей схемы выбрать нужные. Просто? А как найти SUBJECT_OFFERED_SUMMARY по словам «предложенные предметы»? Лучшие системы векторного поиска берут ~93% на recall@15 — нужная таблица в топ-15 кандидатов. Без переранжирования — 81%.
2. Сопоставление колонок (column mapping). «Средний бюджет кафедры» — это DEPT_BUDGET_CODE в SIS_DEPARTMENT? Или нет? Модель должна связать понятие из вопроса с колонкой в базе.
3. Ключи соединения (join keys). Чем связаны таблицы? SIS_DEPARTMENT и SIS_SUBJECT_CODE — по SCHOOL_CODE. Соединит не тем полем — вернёт мусор.
4. Доменные знания (domain knowledge). Вопрос: «кафедры Курса 18». Что за «Курс 18»? В данных этого слова нет. Надо знать: в MIT Курс 18 — это математика, в базе — DEPARTMENT_NAME = 'Mathematics'. Таких локальных знаний — тысячи. 57 из 100 проверочных вопросов BEAVER требуют именно их.
5. Декомпозиция запроса (query decomposition). Сложный вопрос — на шаги: найти кафедры, посчитать среднее, отсортировать. Верная последовательность подзапросов — отдельный навык, и меряют его отдельно.
Парадокс золотого эталона
Здесь — фундаментальная трещина: откуда берётся эталон?
В BEAVER эталонные запросы написали аналитики университета — те, кто годами живёт в этих данных. Запросы гоняли на реальной базе, они давали верный результат. Лучший возможный эталон.
Но прошёл год. Кафедры переименовали, таблицы добавили, схему изменили. Эталонный запрос теперь врёт — или падает с ошибкой. Золотой стандарт протух.
Это oracle staleness — устаревание эталона. Хранилища живые: схемы меняются, данные мигрируют, таблицы переименовываются. Бенчмарк, снятый сегодня, через полгода меряет уже не то.
Ответ — регулярно обновлять бенчмарки и считать метрики, что учитывают «свежесть» эталона.
Один бенчмарк — не ответ
Полной картины не даёт ни один.
Spider 2.0 — точность SQL под конкретные диалекты. BEAVER — поиск в огромных схемах и сложные запросы с оконными функциями и CTE. DABstep — агентное поведение, цепочка решений. CrackSQL (SIGMOD 2025) — про другое: умеет ли модель перевести SQL из диалекта в диалект, из MySQL в Oracle. Это нужно при смене базы, когда сотни тысяч запросов надо перенести без ручного переписывания.
Хорошая система с данными должна тянуть всё это — или хотя бы честно говорить, чего не тянет.
Что дальше
Экзамены для ИИ всё сложнее — и это хорошо. Прошли времена, когда 90% на тесте из трёх таблиц значили «задача решена».
Четыре направления.
Многошаговость. Не «напиши запрос», а целый сценарий: найти данные, заметить аномалию, выдвинуть гипотезу, проверить.
Честные условия. Модель не должна «видеть» бенчмарк при обучении. Технически тяжело — весь интернет пронизан Spider и WikiSQL, — но «невидимые» тесты учатся делать.
Диалектное разнообразие. SQL под MySQL не пойдёт на Oracle или PostgreSQL. Настоящий инструмент понимает все диалекты — или переводит между ними.
Доменные знания. Никакая сеть не родится со знанием, что «Курс 18» — это математика именно в MIT. Это знание надо откуда-то брать: из документации, из истории запросов, из разговоров с аналитиками. Встроить организационную память в систему данных — пожалуй, самое сложное и самое важное здесь. Первый шаг к ней — увидеть, как данные связаны на самом деле: анализ зависимостей данных прямо из кода, а не из вики, которую никто не обновлял.
Пока ИИ сдаёт экзамены, придуманные людьми, — люди придумывают экзамены сложнее. Гонка продолжается.