Оценке ИИ нужен золотой набор, а не хитрый судья

Большинство команд начинают оценивать ИИ слишком поздно и сразу на слишком высоком уровне. Они спорят о моделях-судьях, панелях и результатах бенчмарков еще до того, как могут назвать продуктовое решение, которое должна заблокировать оценка. В итоге появляется впечатляющая тестовая система без каких-либо полномочий. Неудачный релиз все равно уходит в продакшен, потому что никто не договорился, что считать провалом.

Полезная отправная точка гораздо скромнее: версионируемый золотой набор на основе реального поведения продукта, детерминированные проверки фактов, которые может проверить программа, узкие рубрики для качеств, требующих суждения, и запускатель, который оставляет достаточно свидетельств для разбора каждого сбоя. Это можно построить за несколько дней. Доверять этому придется научиться гораздо позже.

Я видел, как команды тратили больше времени на полировку оценщика, чем на разбор двадцати примеров, определяющих успех. Почти всегда примеры обнаруживают более трудную проблему: владельцы продукта, инженеры и рецензенты по-разному понимают хороший ответ. Это расхождение не шум, который надо автоматизировать. Это и есть работа над спецификацией.

Оценка оправдывает затраты, когда меняет решение о релизе, ловит известный сбой раньше пользователя или показывает, какая часть системы ухудшилась. Если она не решает ни одну из этих задач, это отчетность, а не контроль качества.

Начните с решения о релизе

До метрики каждому набору оценок нужно письменное решение. Укажите проверяемое изменение, затрагиваемую им группу, сбои, которые обязаны заблокировать релиз, и допустимое изменение обычного качества. Без такого контракта результат 0,84 остается просто десятичной дробью.

Для помощника службы поддержки решение может звучать так: «Выпустить новый промпт для поиска, только если он не выдает неподтвержденных обещаний возврата денег на наборе безопасности, сохраняет правильность цитат не ниже текущего уровня и не увеличивает число ошибочных передач оператору». Это предложение задает жесткий барьер, сравнительную меру и сбой, связанный с ущербом пользователю. Оно также признает, что один сводный балл не может определять решение.

Рекомендации Anthropic по определению критериев успеха делают тот же практический вывод: критерии должны быть конкретными и измеримыми, а многомерные критерии требуют отдельных измерений. Я согласен и добавлю урок, усвоенный на релизах: каждому критерию нужен ответственный. Если ни у кого нет права остановить развертывание при нарушении критерия, этот критерий нужен только для вида.

Запишите короткий контракт оценки из четырех полей:

• решение: что можно выпустить, расширить или откатить;
• группа: какие пользователи, языки, инструменты и типы запросов учитываются;
• барьеры: сбои, для которых недопустим компромисс;
• сравнения: показатели, которые могут вырасти или снизиться в согласованных пределах.

Не начинайте с «качества ответа». Разделите его на наблюдаемые свойства. Сводка первичного медицинского опроса может требовать точных фактов, полного списка лекарств, отсутствия диагноза и понятного текста. Агент программирования может требовать прохождения тестов, изменений только по разрешенным путям и соответствия объяснения фактической разнице файлов. Для этих свойств нужны разные оценщики, потому что и ломаются они по-разному.

Первому набору не требуется широкий охват всего, что умеет модель. Он должен достаточно полно отвечать на один вопрос о релизе. Расширяйте охват после того, как команда научится последовательно действовать по результату.

Золотой набор фиксирует границы, а не идеальные демонстрации

Золотой набор - это версионируемая коллекция входных данных, контекста, ожидаемых свойств и решений рецензентов, которая представляет поведение, необходимое продукту. Это не просто список промптов с отполированными эталонными ответами. В открытых задачах единственный эталонный ответ часто штрафует допустимые варианты и поощряет подражание.

Стройте первый набор на свидетельствах. Возьмите недавние запросы пользователей, обращения поддержки, результаты проверки на атаки и ошибки, дошедшие до продакшена. Удалите персональные данные, сохраните форму задачи и отметьте, зачем нужен каждый случай. Добавляйте синтетические случаи лишь для названной границы, например пустого результата поиска или противоречащих друг другу положений политики. Синтетическое разнообразие без обозначенного риска делает набор больше на вид, но не повышает его репрезентативность.

Полезный случай содержит не только вход и ожидаемый выход. Запишите такие поля:

• стабильный идентификатор случая и категорию задачи;
• вход вместе с полученным контекстом или состоянием инструмента;
• жесткие требования, запрещенное поведение и необязательный эталон;
• источник случая и причину его включения;
• автора разметки, дату проверки и версию рубрики.

Начните с нескольких десятков тщательно проверенных случаев, а не с тысяч слабых. Универсального минимального размера не существует. Двадцать случаев способны заблокировать опасную регрессию, если каждый покрывает известный сбой. Двести все равно могут вводить в заблуждение, если почти повторяют друг друга. Расширяйте набор, когда находите непокрытое поведение, а не когда кому-то требуется круглая цифра на слайде.

Разделите хотя бы три группы, даже если они хранятся в одном файле. Основной регрессионный набор охватывает частое и важное поведение. Набор безопасности содержит редкие сбои, всегда блокирующие релиз. Набор сложных задач исследует новое или плохо изученное поведение и пока помогает принимать решения, не становясь автоматическим барьером. Это различие важно: сложный исследовательский случай не должен иметь таких же полномочий, как известная утечка персональных данных.

Версионируйте метки вместе с промптами, настройками модели, инструментами и кодом приложения. После изменения рубрики старые и новые результаты нельзя напрямую сравнивать. Сохраните прежнюю запись, перенесите метки через проверку и укажите причину. Незаметное переписывание ожидаемых ответов уничтожает журнал решений.

Защищайте тесты от утечки обычными средствами контроля доступа и процесса. Не вставляйте отложенные случаи в чаты для настройки промптов, примеры обучения по контексту или память агента. Держите видимый набор разработки для итераций и меньший отложенный набор для подтверждения релиза. Если случай становится обучающим примером, пометьте его и замените в отложенной группе. Золотой набор полезен именно потому, что система не репетировала каждый ответ.

Для охвата нужна видимая карта. Сопоставьте каждый случай с небольшой таксономией намерения пользователя, риска, языка, состояния контекста и ожидаемого действия системы. Пустые ячейки показывают, где команда надеется на удачу. Карта также обнаруживает случайные повторы, например тридцать простых поисков факта и один неоднозначный запрос. Не превращайте таксономию в гигантский проект разметки. Ее задача - обнаруживать пропущенные границы и избыток легких случаев.

Проверяйте случаи по расписанию и после изменений продукта. Удаляйте случай лишь тогда, когда такого поведения больше нет или другой случай яснее покрывает ту же границу. Сохраняйте удаление в истории версий. Старые сбои кажутся неактуальными ровно до тех пор, пока рефакторинг не вернет их.

Факты проверяет код, качества оценивает суждение

Лучший оценщик использует наименее субъективный механизм, способный проверить нужное свойство. Команды часто выбирают семантическое сходство или модель-судью там, где парсер, схема, запрос к базе данных или модульный тест дали бы более ясный ответ. Такой выбор добавляет стоимость и неопределенность, но не дает новых знаний.

Детерминированные проверки подходят свойствам с точными условиями истинности: корректному JSON, обязательным полям, разрешенным цитатам, числовым итогам, исполняемому коду, аргументам инструментов, запрещенным словам и факту изменения агентом неразрешенного файла. Эти проверки дают воспроизводимые сбои и обычно сами их объясняют.

Сравнивайте с эталоном только тогда, когда близость к нему имеет смысл. Точное совпадение подходит идентификаторам и однозначным классификациям. Сравнение множеств подходит извлеченным сущностям. Числовой допуск подходит расчетам. Сходство векторных представлений помогает найти кандидатов на проверку человеком, но не должно подтверждать фактическую правильность. Два гладких ответа могут находиться рядом в векторном пространстве и расходиться в единственном важном для пользователя факте.

Люди или модели должны судить о ясности, тоне, полноте и верности, когда правила не справляются. Делайте каждую рубрику узкой. Просьба «Оцените ответ от 1 до 10» заставляет судью при каждом вызове заново выдумывать личное определение качества. Вопрос «Следует ли каждое фактическое утверждение из предоставленного контекста?» можно проверить, особенно если судья обязан указать подтверждающий фрагмент или назвать неподтвержденное утверждение.

Так возникает практическая лестница оценивания. Сначала запускайте дешевые структурные проверки. Останавливайтесь на жестких сбоях. Затем выполняйте расчеты для конкретной задачи. Только оставшиеся результаты отправляйте дорогим моделям-судьям или людям. Такой порядок экономит деньги, но еще лучше помогает диагностике: вы понимаете, относится сбой к формату, содержанию или предпочтению.

Не сворачивайте результаты слишком рано. Общий результат в 95 процентов может скрыть ноль в маленькой категории безопасности. Сохраняйте итоги каждой проверки и разбивайте результаты по задаче, языку, длине ввода, тарифу клиента, состоянию поиска и пути инструментов. Сводные показатели полезны лишь тогда, когда срезы остаются видимыми.

Минимальный запускатель сохраняет свидетельства

Минимальный запускатель должен загружать случаи, вызывать проверяемую систему, выполнять именованные проверки, сохранять исходные артефакты и возвращать ненулевой код завершения, если барьер релиза нарушен. Ему не нужны веб-интерфейс, распределенная очередь или новый фреймворк оценки. Для начала достаточно команды, которая ведет себя как обычная тестовая команда.

Используйте JSONL, потому что различия остаются читаемыми, а поврежденная запись не портит весь набор. Небольшой пример для поддержки может выглядеть так:

{"id":"refund-001","category":"policy","input":"Can you refund an annual plan after 45 days?","context":"Annual plans may be refunded within 30 days. After 30 days, escalate to billing.","must_contain":["billing"],"must_not_contain":["I have issued","refund confirmed"],"gate":true}
{"id":"refund-002","category":"policy","input":"I was charged twice. What should I do?","context":"Duplicate charges must be escalated to billing with both transaction dates.","must_contain":["billing","transaction"],"must_not_contain":["refund confirmed"],"gate":true}

Адаптер системы должен принимать случай оценки и возвращать простую запись. Спрячьте код конкретного провайдера за этой единственной функцией. Запускатель ниже использует только стандартную библиотеку Python, поэтому контракт остается видимым:

import argparse
import json
from pathlib import Path


def run_system(case):
    # Replace this stub with the same application path production uses.
    return {"text": case.get("candidate", ""), "usage": {}, "trace": []}


def check_case(case, result):
    text = result["text"].lower()
    checks = []
    for phrase in case.get("must_contain", []):
        checks.append({
            "name": f"contains:{phrase}",
            "passed": phrase.lower() in text,
        })
    for phrase in case.get("must_not_contain", []):
        checks.append({
            "name": f"excludes:{phrase}",
            "passed": phrase.lower() not in text,
        })
    return checks


def main():
    parser = argparse.ArgumentParser()
    parser.add_argument("suite")
    parser.add_argument("out", nargs="?", default="eval-results.jsonl")
    args = parser.parse_args()

    cases = [json.loads(line) for line in Path(args.suite).read_text().splitlines() if line]
    records = []
    blocked = False
    for case in cases:
        result = run_system(case)
        checks = check_case(case, result)
        passed = all(item["passed"] for item in checks)
        blocked = blocked or (case.get("gate", False) and not passed)
        records.append({
            "case_id": case["id"],
            "category": case["category"],
            "passed": passed,
            "checks": checks,
            "output": result,
        })

    Path(args.out).write_text("\n".join(json.dumps(r) for r in records) + "\n")
    summary = {"cases": len(records), "passed": sum(r["passed"] for r in records), "blocked": blocked}
    print(json.dumps(summary))
    raise SystemExit(1 if blocked else 0)


if __name__ == "__main__":
    main()

Запустите его командой python eval.py golden.jsonl run-2026-08-09.jsonl. Стандартный вывод имеет стабильную форму наподобие {"cases": 2, "passed": 1, "blocked": true}, а файл результатов сохраняет каждый выход и каждую именованную проверку. В непрерывной интеграции код завершения 1 блокирует кандидата.

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

Прежде чем добавлять функции, добавьте метаданные запуска: коммит приложения, версию набора, идентификатор модели, параметры модели, хеш промпта, версию судьи, время начала, длительность, расход токенов и статус ошибки. Сохраняйте тайм-ауты и отказы как результаты, а не повторяйте запрос незаметно до их исчезновения. Повтор может быть нормальным поведением продакшена, но трассировка должна его показывать.

Когда такой формат файла начнет мешать, это будет полезным ограничением. Добавляйте адаптер судьи, параллельность, кеширование и отчет только в ответ на замеченные потребности. Оставляйте формат исходной записи переносимым. Платформы оценки меняются, а свидетельства должны пережить первую панель.

Правила подсчета нужны до запуска

Решите, как результаты превращаются в решение о релизе, еще до получения баллов кандидата. Перенос порога после неудачного запуска превращает оценку в объяснение уже принятого решения.

Используйте жесткие барьеры для результатов, которые нельзя усреднить: раскрытия данных, неразрешенных действий, выдуманных обязательств, недопустимого регулируемого вывода или повреждения пользовательского состояния. Один подтвержденный случай способен заблокировать релиз. Повторно запускайте ошибки нестабильной инфраструктуры, но не усредняйте настоящий сбой безопасности с девятью гладкими ответами.

Для обычного качества сравнивайте кандидата с текущим продакшеном на тех же случаях. Абсолютные пороги быстро устаревают из-за изменения состава случаев и рубрик. Парное сравнение показывает, какие случаи улучшились, ухудшились или остались равноценными. Ставьте исходные количества рядом с процентом, особенно в малых срезах.

Простая политика может требовать прохождения всех барьеров безопасности, отсутствия снижения любой основной категории сверх согласованного допуска и проверки человеком каждого измененного результата в случаях с серьезными последствиями. Не прячьте эти условия в коде. Храните их в небольшом файле конфигурации и требуйте одобрения рецензента для изменений.

Вначале откажитесь от взвешенного общего балла. Веса принудительно сводят разные сбои к одной валюте и вызывают споры об арифметике вместо обсуждения пользователей. Если руководству нужен один статус, сообщайте «пройдено», «нужна проверка» или «заблокировано», а затем показывайте причины. Сохраняйте исходные метрики компонентов.

Считайте стоимость и задержку продуктовыми критериями, а не примечаниями. На тех же случаях записывайте распределения полной задержки, ошибки провайдера, повторы и расход токенов или инструментов. Кандидат, который улучшает текст по мнению судьи, но вдвое увеличивает число тайм-аутов, проверку не прошел. Держите качество, стоимость и задержку отдельными осями, чтобы владелец продукта видел компромисс.

Случайные результаты требуют повторных попыток, если разброс способен изменить решение. Не повторяйте каждый случай пять раз по привычке. Повторите репрезентативную часть, измерьте частоту изменения вердикта и расширяйте ее только при нестабильности возле границы релиза. Температура, закрепленная на нуле, может снизить разброс, но не делает поведение размещенной у провайдера модели математически детерминированным.

Модель-судья требует калибровки

Модель-судья способна расширить объем проверки, но не может сама определить правильность. Относитесь к ней как к измерительному прибору с узкой задачей, калибровкой по решениям людей и регулярной проверкой сдвига.

В статье G-Eval Лю и его соавторы показали, что структурированные этапы оценки и подсчет по форме улучшили соответствие человеческим суждениям для сводок и диалогов. Полезный вывод не в том, что одна модель стала оракулом. Процедура и рубрика изменили измерение, а авторы также отметили возможную предвзятость в пользу текста, созданного моделью.

Чжэн и его соавторы в работе о MT-Bench и Chatbot Arena описали у моделей-судей зависимость от позиции, многословия и сходства с собой. Это не отвлеченные крайние случаи. Судья может предпочесть первый из двух ответов, наградить более длинный текст за повторы или выбрать результат, похожий на ответы его собственного семейства моделей. Более позднее систематическое исследование зависимости от позиции показало: перестановка ответов остается необходимой диагностикой, а не косметическим изменением промпта.

Пять мер делают судью менее обманчивым:

• запрашивайте одно свойство в каждом вердикте и определите успех, провал и неопределенность;
• требуйте фрагменты свидетельств или конкретную причину сбоя;
• скрывайте названия моделей и несущественные метаданные;
• меняйте порядок ответов в паре и отмечайте противоречивые вердикты;
• передавайте людям неопределенные и важные случаи, а также выборку успешных.

Не разрешайте тексту кандидата обращаться к судье так, будто это доверенная инструкция. Оберните его как недоверенные данные, четко отделите и велите судье игнорировать инструкции внутри. Это снижает риск внедрения промпта, но не доказывает изоляцию. Для проверок с серьезными последствиями выбирайте детерминированную валидацию или человека.

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

Никогда не считайте текстовое объяснение судьи доказательством правильности вердикта. Модели способны написать связное обоснование после предвзятого выбора. Обоснование помогает рецензенту разобрать результат, но только данные калибровки показывают, заслуживает ли судья доверия.

Калибруйте судью по решениям людей

Прежде чем судья получит право блокировать релиз, сравните его вердикты с решениями людей, понимающих задачу. Сто непроверенных вызовов судьи не создают уверенности. Меньший набор тщательно согласованных примеров способен показать, где расходятся рубрика, люди или судья.

Подберите для калибровки явные успехи, явные провалы и пограничные случаи. Пусть хотя бы два рецензента независимо разметят их, затем обсудят расхождения и запишут окончательное правило. Рецензентам нужен тот же контекст, который получает судья. Если люди регулярно не согласны, уточните рубрику или примите результат «неопределенно», а не создавайте ложную точность.

Рассчитайте матрицу ошибок для каждого барьера: правильный успех, правильный провал, ложный успех и ложный провал по сравнению с согласованной меткой. Для безопасности больше всего внимания обычно требуют ложные успехи. Для предпочтения стиля ложные провалы могут тратить время рецензента, но несут меньший риск пользователю. Один процент согласия скрывает это различие.

Сохраните набор расхождений как постоянный регрессионный срез. Включите короткие правильные ответы, проигрывающие многословным, случаи изменения вердикта при перестановке ответов, результаты собственного семейства модели-судьи и примеры с текстом, который пытается манипулировать оценкой. Запускайте этот набор при изменении модели-судьи, рубрики или промпта.

Даже после калибровки отдавайте выборку продакшен-вердиктов людям на аудит. Проверяйте все важные сбои, случайную долю успехов и случаи рядом с порогом. Отслеживайте расхождения по категориям, а не только в целом. Судья может хорошо оценивать тон и плохо справляться с расчетами.

Модели-судьи и поведение провайдеров меняются. Закрепляйте версию модели, когда провайдер это позволяет, сохраняйте полный промпт судьи и параметры, а перед заменой повторяйте калибровку. Если старая версия исчезает, проведите параллельные запуски старой и новой, пока доступны обе. Если это невозможно, обозначьте разрыв в ряду результатов вместо гладкой линии тренда через него.

Судья должен постепенно заслужить расширение полномочий. Сначала пусть его результат будет аннотацией для рецензентов. Затем разрешите ему распределять случаи. Доверяйте ему блокировку изменений с низким риском лишь после стабильной работы. Передача человеку - нормальный результат оценщика, а не дефект, который надо устранить.

Агентам и RAG мало оценки финального ответа

Агентные системы и системы поиска могут получить правдоподобный финальный ответ опасным или расточительным путем. Оценивайте результат и траекторию отдельно. Судья финального ответа не заметит, что агент раскрыл секрет инструменту, получил документ другого клиента или сделал три необратимых вызова перед вежливым ответом.

Для генерации с поиском сохраняйте запрос, фильтры, идентификаторы найденных документов, переданные модели фрагменты, цитаты в ответе и финальный текст. Проверяйте полноту поиска на случаях с известными подтверждающими документами. Проверяйте обоснованность цитаты: подтверждает ли указанный фрагмент соседнее утверждение. Проверяйте верность ответа только по предоставленным свидетельствам. Это разные сбои с разными ответственными.

Для агентов с инструментами определите разрешенные и запрещенные переходы состояния. Календарный агент может прочитать доступное время перед предложением встречи, но не должен создавать событие до одобрения пользователем точного времени и участников. Запускатель должен использовать песочницу или поддельную реализацию инструмента, записывать каждый вызов и ответ, а затем проверять порядок, аргументы, число вызовов и побочные эффекты.

Оценивайте восстановление, а не только успешный путь. Верните пустой результат поиска, поврежденный ответ инструмента, ошибку разрешений, устаревший контекст и тайм-аут. Проверьте, запрашивает ли система уточнение, выбирает ли безопасный запасной вариант или выдумывает успех. Многие дорогие ошибки агентов случаются после отказа зависимости, тогда как демонстрационные наборы заставляют все зависимости помогать.

Отделяйте соблюдение политики от выполнения задачи. Агент, который отказывается от безобидной просьбы, безопасен, но бесполезен. Агент, который выполняет задачу через неразрешенное действие, полезен, но опасен. Показывайте обе оси и блокируйте по той, которая соответствует риску релиза.

Многошаговым диалогам также нужны проверки состояния. Сохраняйте разговор и структурированную память после каждого хода. Проверяйте, заменяют ли исправления устаревшие факты, сохраняются ли границы клиента и пользователя, истекают ли инструкции после завершения своей области действия. Повтор только последнего сообщения пользователя пропускает ошибки состояния, с которыми сталкиваются настоящие пользователи.

Сбои продакшена должны пополнять набор

Программа оценки остается полезной, только если свидетельства из продакшена ее меняют. Проверки до релиза охватывают известные риски, а живой трафик обнаруживает новые формулировки, сочетания контекста, сбои инструментов и стратегии пользователей. Эти два цикла нужно соединить управляемым способом.

Записывайте достаточно для восстановления сбоя, но не собирайте ненужные данные. Сохраняйте версии промпта и конфигурации, трассировку поиска и инструментов, выход, сигналы исправления пользователем, класс ошибки и время. Применяйте контроль доступа и сроки хранения, соответствующие чувствительности содержимого. Скрывайте или заменяйте персональные значения, прежде чем случай попадет в широко доступный набор.

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

Запускайте набор в три полезных момента. Быстрая детерминированная часть нужна при каждом относящемся к ней изменении. Полный золотой набор нужен перед релизом или заменой промпта и модели. Запуск по расписанию обнаруживает сдвиг провайдера и изменения зависимостей, даже если репозиторий не меняется. Точная частота зависит от релизов и риска, но ответственность не может оставаться неопределенной.

Назначьте одного человека для одобрения изменений набора и отдельный путь проверки предметным специалистом. Инженеры должны отвечать за надежность запускателя, а продуктовые и предметные специалисты - за ожидаемое поведение. Когда один автор меняет промпт, переписывает ожидаемый ответ и в одиночку одобряет новый результат, тест легко утверждает изменение вместо того, чтобы его проверять.

Команды, которым нужно связать дисциплину оценки со штатом, поставкой и разработкой с помощью ИИ, могут заказать Team & AI Audit на oleg.is, чтобы до крупной трансформации найти пробелы в работе и посчитать экономию. Услуга стоит фиксированные $5 000, занимает пять рабочих дней и гарантирует выявление годовой экономии от $50 000, иначе аудит проведут бесплатно.

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