Правильный ответ ещё не gold
Что необходимо подтвердить до превращения результата в инженерный эталон.

Правильный ответ ещё не gold
Что необходимо подтвердить до превращения результата в эталон
Сценарий знакомый.
Команда запускает новую версию промпта. Модель отвечает точно, красиво и по существу. Разработчик облегчённо выдыхает, сохраняет пару «запрос — ответ» в контрольную папку и подписывает её гордым словом gold.
Через несколько недель этот эталон начинает браковать правильные ответы, одобрять неправильные и путать модель-судью.
Виновата, разумеется, новая модель.
Потом промпт.
Потом температура.
И только после небольшого внутреннего расследования выясняется, что золотым с самого начала был только цвет папки.
Хороший ответ ещё не является gold-кейсом.
Gold — это не награда модели за примерное поведение. Это измерительный инструмент. А прежде чем измерять им другие версии системы, необходимо убедиться, что сама линейка не растягивается, не меняет длину по пятницам и не была нарисована фломастером на салфетке.
Gold-кейс — это не ответ
Самая распространённая ошибка — считать эталоном только финальный текст.
Но один ответ без условий его получения почти ничего не доказывает.
Полноценный gold-кейс включает:
- исходный запрос;
- весь необходимый контекст;
- использованные источники;
- версию задания или правил;
- подтверждённый ожидаемый результат;
- обязательные свойства ответа;
- допустимые варианты;
- запрещённые ошибки;
- способ оценки;
- сведения о том, кто и как провёл проверку;
- дату и область применимости.
То есть gold — это не фотография победителя.
Это протокол соревнования вместе с дистанцией, правилами, секундомером и актом о том, что Кот не передвинул финишную черту после забега.
Правильный результат мог появиться случайно
Модель способна прийти к верному ответу по ненадёжным основаниям.
Она могла:
- угадать;
- воспользоваться случайной подсказкой в формулировке;
- опереться на постороннее знание вместо предоставленного материала;
- неверно истолковать два факта, но получить правильный итог;
- воспроизвести знакомый шаблон, который случайно подошёл к этому случаю.
Поэтому недостаточно проверить только последнюю строку.
При этом требовать у модели полный внутренний Chain-of-Thought и объявлять его доказательством тоже не следует. Текстовое «рассуждение» может быть неполным, недостоверным или построенным уже после получения ответа. А некоторые модели вообще не раскрывают внутренний процесс в такой форме.
Проверять нужно не мысли модели, а наблюдаемое поведение системы:
- какие данные были доступны;
- на какие фрагменты источника опирается результат;
- сохраняется ли он при нейтральных изменениях входа;
- меняется ли ответ, когда меняется действительно значимый факт;
- выполняются ли все правила задачи;
- воспроизводится ли результат в чистом запуске.
Если замена имени Анна на Мария внезапно меняет классификацию объекта, возможно, система изучила не правило, а примету.
Такой ответ может быть правильным.
Но золотым ему пока рано.
Gold начинается с однозначного задания
Эталон невозможно построить для задачи, условия которой допускают несколько несовместимых толкований.
Предположим, система должна определить, присутствует ли объект на изображении. Но в описании кейса не указано:
- считается ли частично закрытый объект присутствующим;
- достаточно ли отражения в зеркале;
- нужно ли учитывать изображение объекта на плакате;
- что делать при недостаточном качестве;
- разрешён ли ответ «неопределимо».
Два эксперта могут дать разные ответы и оба будут действовать разумно.
Если после этого один вариант объявить gold, тест начнёт измерять не качество модели, а степень её телепатической совместимости с автором эталона.
До утверждения кейса нужно проверить:
- хватает ли входных данных для решения;
- определены ли термины;
- учтены ли существенные исключения;
- существует ли единственный правильный класс ответа;
- описано ли поведение при недостатке информации.
Иногда результатом проверки становится не утверждение gold, а исправление самого задания.
Это не провал.
Гораздо дешевле обнаружить двусмысленность до того, как ею начнут экзаменовать весь модельный состав.
Источник должен быть частью эталона
Если задача связана с документом, изображением, видео или набором данных, gold должен хранить не только ответ, но и основание для него.
Например:
Объект присутствует в кадре с 00:12 по 00:17.
Для проверки необходимы:
- конкретный файл или его неизменяемая версия;
- временной диапазон;
- описание наблюдаемого признака;
- правило, по которому этот признак относится к нужному классу.
Без этого следующий проверяющий увидит только готовое утверждение и будет вынужден либо поверить предшественнику, либо повторить всю экспертизу с нуля.
Так интерпретация постепенно начинает притворяться первичным наблюдением.
В хорошем gold-кейсе другой эксперт может открыть тот же источник, применить то же правило и понять, почему был утверждён именно этот результат.
Он не обязан соглашаться автоматически.
Но он должен иметь возможность проверить решение.
Все требования равноправны
Ответ может быть фактологически правильным и всё равно не пройти задачу.
Если система должна вернуть JSON, а модель написала великолепное эссе, перед нами великолепное нарушение контракта.
Если разрешено не более 250 символов, ответ на 400 символов не становится gold только потому, что автору было что сказать.
Если запрещено добавлять отсутствующие в материале сведения, одна красивая догадка делает результат непригодным, даже когда всё остальное верно.
При проверке нужно учитывать:
- предметную правильность;
- полноту;
- отсутствие домыслов;
- формат;
- длину;
- обязательные поля;
- запрещённые элементы;
- порядок данных;
- стиль, если он действительно является частью задачи;
- корректное поведение при неопределённости.
Gold фиксирует не «хороший ответ вообще».
Он фиксирует выполнение конкретного контракта.
Дословное совпадение требуется не всегда
Для некоторых задач эталон можно проверить строго.
Например:
- класс объекта;
- числовое значение;
- набор тегов;
- JSON со строго определёнными полями;
- наличие или отсутствие конкретного признака.
Здесь детерминированная проверка обычно надёжнее впечатлений модели-судьи.
Но в открытых задачах существует несколько равноценных формулировок.
Фразы:
Учётная запись активирована.
и
Активация учётной записи завершена.
могут быть одинаково правильными.
Если gold разрешает только первую строку, тест измеряет сходство формулировок, а не качество ответа.
Поэтому для генеративной задачи вместо единственной священной фразы нужен рубрикатор:
- какие факты обязательны;
- какие детали допустимы;
- какие выводы запрещены;
- какой формат необходим;
- какие стилистические различия несущественны;
- что считается критической ошибкой.
Эталонный ответ можно сохранить как пример.
Но пример не должен незаметно становиться единственно допустимой литературной формой существования истины.
Модель-судья тоже сдаёт экзамен
LLM-as-a-Judge позволяет быстро проверять большое количество ответов по заданным критериям. Это полезный инструмент, особенно для задач, где простого сравнения строк недостаточно.
Но модель-судья остаётся моделью.
Она может:
- предпочитать длинные ответы;
- завышать оценку уверенно написанному тексту;
- пропускать фактическую ошибку;
- следовать стилю эталона вместо критериев;
- нестабильно оценивать один и тот же случай;
- соглашаться с формулировкой, похожей на её собственную.
Поэтому судья должен получать не просто пару текстов, а чёткий рубрикатор.
Его решения полезно периодически сравнивать с экспертной разметкой. Для критических критериев лучше сохранять детерминированные проверки или участие человека.
Назначить вторую модель судьёй можно быстро.
Сделать её Верховным судом без права апелляции — уже архитектурное решение, причём довольно смелое.
Эталон имеет дату и среду обитания
Некоторые ответы остаются правильными годами.
Другие портятся быстрее молока на батарее.
К нестабильным относятся сведения, зависящие от:
- текущей даты;
- версии библиотеки;
- модели или API;
- законодательства;
- юрисдикции;
- внешнего сервиса;
- меняющейся базы данных;
- состояния конкретной системы.
Вопрос:
Кто сейчас является руководителем компании?
не может иметь бессрочного gold-ответа.
Для такого кейса нужно либо приложить фиксированный источник и сформулировать вопрос относительно него, либо указать дату проверки и срок актуальности.
То же относится к программному коду. Правильный пример для одной версии библиотеки может не работать в следующей.
Поэтому паспорт gold-кейса должен содержать:
- дату утверждения;
- версии зависимостей;
- целевую модель, если это существенно;
- редакцию правил;
- источник данных;
- условия, при которых кейс необходимо пересмотреть.
Gold — не вечная истина.
Это утверждённый эталон в определённых границах.
Эталон не должен тащить за собой мусор
Gold-кейс часто рождается из реального рабочего инцидента. Вместе с полезными данными туда могут попасть:
- персональные сведения;
- пароли и токены;
- внутренние адреса;
- абсолютные пути;
- клиентские документы;
- случайные комментарии разработчика;
- особенности ответа конкретной модели;
- фрагменты защищённых источников.
Перед включением в постоянный набор кейс необходимо очистить.
Но очистка не должна менять проверяемую проблему.
Если удалить из примера половину контекста и заменить все сущности одинаковыми буквами, можно случайно уничтожить именно тот признак, из-за которого система ошибалась.
Поэтому обезличивание — тоже преобразование, которое необходимо проверить.
После очистки кейс повторно проходит экспертную оценку.
Даже если из него удалили всего лишь безобидный пароль от московского VPS.
Особенно если из него удалили пароль от московского VPS.
Один эксперт — ещё не золотой фонд
Автор ответа знает, что хотел получить, поэтому легко видит в результате именно это.
Независимая проверка нужна не из-за недоверия к автору. Она помогает обнаружить неявные предположения, которые тот считает очевидными.
Хорошая схема допуска может выглядеть так:
- один эксперт создаёт или размечает кейс;
- другой проверяет источник и применённые правила;
- расхождения фиксируются;
- неоднозначности устраняются;
- утверждается критерий оценки;
- кейс получает статус gold.
Если эксперты не согласны, это важный результат.
Возможно, требуется уточнить правила. Возможно, входные данные недостаточны. Возможно, задача допускает несколько ответов.
В таком состоянии кейс не следует насильно позолачивать.
Его можно сохранить как candidate, disputed или отдельный пример неоднозначности.
Золотая краска не устраняет трещину.
Она только делает её дороже.
Проверка на устойчивость
Перед утверждением полезно провести контролируемые вариации.
Нейтральные изменения
Меняются детали, которые не должны влиять на решение:
- имена;
- порядок независимых фрагментов;
- несущественное форматирование;
- нейтральный фон;
- служебные идентификаторы.
Ответ должен оставаться прежним.
Значимые изменения
Меняется один признак, который обязан изменить результат.
Если после удаления ключевого факта система продолжает отвечать так же, возможно, она вообще не использовала этот факт.
Чистый запуск
Кейс повторяется без истории предыдущего разговора.
Это отделяет свойства промпта от подсказок, случайно сохранившихся в контексте.
Сравнение моделей или версий
Если gold предназначен для общего экзамена, нужно убедиться, что критерии не зашиты под речевые привычки одного конкретного участника.
Цель проверки — не добиться одинаковых фраз.
Цель — убедиться, что эталон измеряет заявленное свойство системы.
Протокол допуска в gold
До утверждения кейса лаборатория должна ответить на следующие вопросы.
Наблюдаемость
Можно ли проверить правильный результат непосредственно по сохранённому источнику?
Однозначность
Достаточно ли данных и правил для принятия решения?
Полнота контракта
Зафиксированы ли все обязательные требования и запреты?
Воспроизводимость
Получит ли независимый эксперт тот же результат при тех же условиях?
Устойчивость
Сохраняется ли решение при нейтральных изменениях и меняется ли при значимых?
Оцениваемость
Можно ли отличить успешный ответ от провала с помощью понятных критериев?
Актуальность
Указаны ли дата, версии и границы применимости?
Чистота
Удалены ли секреты, персональные данные и случайные артефакты без разрушения смысла кейса?
Происхождение
Известно ли, кто, когда и на каком основании утвердил эталон?
Если хотя бы один критический пункт остаётся неизвестным, перед нами хороший кандидат.
Но ещё не gold.
Gold тоже может ошибаться
Утверждённый эталон не становится непогрешимым.
Позже может обнаружиться:
- ошибка разметки;
- конфликт правил;
- повреждённый источник;
- скрытая неоднозначность;
- устаревшая зависимость;
- систематический перекос набора;
- критерий, подходящий одной модели, но несправедливый к другим.
Поэтому gold-кейс должен иметь историю изменений и возможность отзыва.
Нельзя тихо переписать ответ, оставив прежнее имя. Иначе результаты старых и новых прогонов станут несопоставимыми.
Исправленный эталон получает новую редакцию, а прежняя сохраняется с объяснением причины замены.
Золотой фонд нуждается в ревизии не меньше, чем промпты, которые он проверяет.
Иногда реабилитация требуется самому экзамену.
Правильный ответ и инженерный эталон
Правильный ответ сообщает, что система успешно справилась с одним запросом.
Gold-кейс позволяет проверить, справится ли она с этим классом задач снова — и понять, почему результат был принят или отклонён.
Разница между ними состоит не в красоте формулировки и не в уверенности эксперта.
Она находится в доказательной базе.
Хороший ответ можно одобрить.
Gold-кейс должен выдержать независимую проверку.
Поэтому в лаборатории действует простое правило:
Если результат понравился Коту — это успех.
Если к нему приложены источник, контракт, критерии, версии, допустимые варианты и протокол проверки — возможно, это gold.
Но окончательное решение всё равно принимается только после того, как кто-нибудь убедится, что линейка не резиновая.