Золотой стандарт: как проверяют, что ИИ ответил правильно

Аннотаторы, оракулы выполнения и проблема правильного правильного ответа

Нейросеть получила вопрос на естественном языке и вернула SQL. Как понять — ответ правильный?

Кажется, очевидно: запустить запрос, посмотреть результат. Но что значит «результат правильный»? Правильный по сравнению с чем? Кто решает, что должно быть в ответе? И что делать, если два опытных аналитика дают разные «правильные» ответы на один вопрос?

Это и есть проблема золотого стандарта — фундамент любого бенчмарка для систем работы с данными.

Откуда берётся эталон

«Золотой» здесь не метафора. В машинном обучении gold label — эталонный ответ, с которым сверяют всё остальное. Его качество задаёт качество всей оценки: плохой эталон — бессмысленные цифры, каким бы хорошим ни был алгоритм.

Для NL→SQL эталон — это SQL-запрос, написанный экспертом. Но и здесь есть нюансы. Получить его можно двумя путями: аннотация и оракул выполнения. Это не технические детали — это две философии проверки.

Путь первый: аннотация

Аннотация — это когда люди вручную размечают «правильный ответ». Для поиска таблиц аннотатор смотрит на вопрос — «средняя численность студентов по математическим факультетам» — и отмечает: нужны SIS_STUDENT, SIS_DEPARTMENT, SIS_ENROLLMENT. Это правильный набор. Остальное — лишнее.

Метрику считают просто: сколько нужных таблиц алгоритм нашёл (recall), сколько найденных верны (precision), их гармоническое среднее (F1). В эксперименте с детерминированным парсером через sqlglot средний F1 — 0.77 при recall 0.96: почти все нужные таблицы находились, но иногда захватывались лишние.

Слабое место — разногласие аннотаторов (inter-annotator agreement, IAA). Разные эксперты понимают один вопрос по-разному. Один уверен, что нужна SIS_ENROLLMENT, другой — что хватит агрегата SIS_SUBJECT_STATS. Оба правы — с разных углов.

IAA меряют каппой Коэна: 1.0 — полное согласие, 0 — случайное. Для сложных вопросов к большим схемам типичная каппа — 0.7–0.8. То есть примерно каждый пятый вопрос эксперты оценивают по-разному. Золотой стандарт оказывается не таким уж золотым.

Путь второй: оракул выполнения

Альтернатива — не спрашивать людей, а запустить запрос на реальной базе и сравнить результаты.

Логика: если запрос модели и эталонный дают одинаковые данные — значит, ответ верен. Неважно, как написан SQL. Важно, что он возвращает. Это execution accuracy. В BEAVER эталоны написали аналитики MIT и гоняют их на снапшоте реального хранилища. Сравнение жёсткое: результат превращают в набор строк (порядок строк и имена колонок игнорируются, дубликаты убираются) и сверяют напрямую.

Преимущество очевидно: подход не зависит от того, как запрос написан. Другие JOIN'ы, другие подзапросы, другие алиасы — зачёт, если результат совпал.

Цена — живая база: загрузить данные, поднять MySQL, прогнать оба запроса, сравнить. Сложнее, чем посмотреть разметку. (Сами подзадачи — поиск таблиц, колонок, ключей, доменные знания, декомпозиция — разобраны в «Как устроен экзамен для ИИ». Здесь нас занимает другое: что вообще считать правильным.)

Где ломается оракул

Оракул выглядит объективным — но у него свои трещины.

Несколько правильных запросов. «Сколько студентов записалось на математику в 2023-м?» — это уникальные студенты или записи о зачислении? Оба запроса верны, оба дают разные числа. Эталон фиксирует одну трактовку; всё, что не совпало, — «ошибка».

Устаревание эталона — oracle staleness. Бенчмарк снимают в конкретный момент. А хранилище живёт: таблицы переименовывают, схемы эволюционируют, данные мигрируют. Запрос, верный в 2024-м, в 2026-м вернёт пустоту — не потому что стал неправильным, а потому что изменилась база. Золотой стандарт протух.

Это меряют: gold staleness rate — доля эталонов, потерявших актуальность. Для долгоживущих корпоративных хранилищ — 20–30% за два-три года. Треть истины осыпается каждые несколько лет.

Развилка: жить без эталона — или обновлять его

Устаревание ставит перед выбором, у которого нет уютного ответа.

Путь первый — признать, что абсолютного эталона нет. Правильный ответ — не камень, а консенсус: договорённость людей, работавших в конкретное время с конкретными данными. Тогда и метрики должны мерить не «совпал ли с эталоном», а «насколько ответ обоснован и воспроизводим». Мягче — но честнее.

Путь второй — построить процесс актуализации. Раз хранилище меняется, эталон должен меняться вместе с ним: переустанавливаться при изменении схемы, тянуться за переименованиями, помнить, каким был вчера. Не разовый снимок истины — живой, обновляемый слой.

Второй путь — это, по сути, карта зависимостей, которая живёт вместе с кодом: когда видно, что от чего зависит и что изменилось, эталон не протухает молча — его старение становится видимым и поправимым.

Зависимости схемы: новый уровень детализации

Традиционные метрики отвечают на «нашёл ли алгоритм нужные таблицы». Но в реальных хранилищах правильный ответ — не просто список таблиц.

Microsoft в работе SLiCE (2025) предложил более детальный формат: каждый элемент схемы — четырёхэлементный кортеж: корпус, таблица, поле, действие (Corpus / Table / Field / Action). Не «нужна FINANCE.JOURNAL_LINES», а «нужно поле AMOUNT из JOURNAL_LINES корпуса FINANCE для действия aggregate».

Это меняет масштаб оценки. Раньше система могла «найти» таблицу — и взять из неё не то поле и не так. С SLiCE такая ошибка видна: таблица совпала, поле — нет. Формат уже используют как рамку для оценки точности зависимостей: насколько точно система понимает не «какие таблицы», а «какие поля и как именно».

Кто проверяет проверяющих

Парадокс, о котором редко говорят вслух: сами метрики содержат допущения.

Execution accuracy верит, что эталонный SQL написан правильно. Но его написал человек — а люди ошибаются. В реальных бенчмарках 3–7% эталонов содержат ошибки: опечатки, неверный JOIN, кривое условие WHERE. Тест с таким эталоном меряет не систему — он меряет, насколько точно система повторяет человеческую ошибку.

Аннотация верит, что разметчики были последовательны и квалифицированы. Но кто проверяет разметчиков? Это second-order evaluation — оценка оценщиков. В лучших бенчмарках — перекрёстная проверка: несколько аннотаторов независимо размечают одно и то же, расхождения судит арбитр.

За пределами NL2SQL

Проблема золотого стандарта — не специфика баз данных. Она везде, где ИИ проверяют на точность.

Медицина: что значит «правильный» диагноз, если патологоанатомы расходятся в 15% случаев? Право: кто задаёт «правильную» трактовку прецедента? Перевод: какой из пяти переводов фразы — эталонный?

Везде одно и то же: эталон — это не истина, а консенсус. Консенсус людей, работавших в конкретное время, с конкретными данными, с конкретным пониманием задачи.

Тестировать ИИ — значит сперва договориться, что считать правильным. И это, как выясняется, одна из самых сложных частей всей работы.

Хороший бенчмарк — не тот, что даёт точные цифры. Хороший — тот, где понятно, что именно эти цифры мерят.