Оценка превращает бенчмарк из «прикидки на глаз по JSON» в объективное число. Результат каждой модели оценивается по золотому эталону — ожидаемому выводу — давая полноту, корректность и общую оценку качества, по которой можно сортировать.
Для оценки нужно то, с чем сравнивать. Каждый сценарий содержит эталонный вывод: правильный ответ для его единственной фиксированной сущности. Создайте его, сгенерировав с помощью мощных моделей (веб-поиск + документ-источник истины), вставив заведомо верный результат, а затем отредактировав его вручную, — и отметьте как проверенный, когда будете ему доверять. Проверенный эталон необходим для бенчмаркинга сценария, поэтому всегда есть с чем сравнивать. Если позже вы отредактируете эталон — или измените конфигурацию оценки сценария, — существующие оценки будут помечены как устаревшие до переоценки.
Эталон также обновляет себя сам. Проверенный эталон — всё ещё выправленный вручную черновик, а модели, которые вы прогоняете в бенчмарке, — его рецензенты: везде, где судья находит ответ кандидата лучше эталонного (или признаёт эталон неверным), везде, где собственные образцы сценария доказывают ошибку эталона, и везде, где модель заполняет значение, оставленное в эталоне пустым, а судья это подтверждает, результат фиксирует находку. В конце каждого прогона оценки находки всех оценённых моделей сводятся воедино — сначала то, что доказывают образцы, затем ответ, который дало большинство моделей, — и записываются в эталон. Правка, уже сделанная прогоном, заменяется только более веским подтверждением (образцы, вердикт о неверном значении или большее число согласных моделей — с учётом всех прогонов), но никогда — мнением ещё одной модели, поэтому поочерёдный бенчмарк моделей не может сместить эталон в сторону той, что оценена последней. Такие автоматические правки никогда не помечают оценки устаревшими (это делают только ваши собственные сохранения), и каждая из них логируется вместе с тем, что она заменила, и тем, какие модели её вызвали.
Просматривайте их как рецензирование правок: раздел Эталон сценария рядом с его результатами показывает сам эталон, где каждая автоматическая правка подсвечена на своём месте — зачёркнутое прежнее значение, новое значение, сколько моделей за ним стоит и почему. Всё считается принятым, пока вы не отклоните правку; отклонение восстанавливает прежнее значение и исключает этот путь из будущих прогонов. Фильтруйте по атрибуту или подтверждению (правки от одной модели стоит посмотреть в первую очередь), выбирайте показанное и отклоняйте массово.
Основная проблема: два правильных ответа могут быть записаны по-разному. Модель, называющая актёра «R. Downey Jr.» вместо «Robert Downey Jr.», не ошибается. Поэтому каждое поле сравнивается по многоуровневой лестнице — сначала самое дешёвое и достоверное, с эскалацией только при необходимости:
Идентичные значения совпадают. Как и значения, различающиеся только регистром, окружающими пробелами или числовой точностью ("Acme" = "ACME", 4.0 = 4). Бесплатно и полностью детерминированно.
Для текста кандидат и эталон векторизуются и сравниваются по косинусному сходству. Выше порога они считаются одинаковыми — поэтому допустимое альтернативное написание, например «R. Downey Jr.» и «Robert Downey Jr.», является совпадением, а не ошибкой. Исключение — даты: они сравниваются как календарные значения, а не по сходству, поэтому близкая, но неверная дата («1972-03-14» и «1972-03-24») — это чёткое несовпадение, а не обманчиво высокое косинусное значение. Логические значения также сравниваются строго — точное совпадение или ничего.
Значения, которые нельзя оценить по схожести, — все поля со свободным текстом, такие как сводки и описания, любое неидентичное число, а также явно отличающееся значение, которое подтверждают ваши документы или большинство других моделей, — передаются модели-судье. Судья работает вслепую: он видит два значения как A и B, место поля в схеме (родительские поля и их описания, тип, к какому элементу списка оно относится) и ваши исходные документы, если они есть в сценарии, и говорит, какое значение лучше подходит полю, верны ли оба или одно из них ошибочно. Кандидат, признанный равноценным эталону или лучше него, — как и значение, для которого ошибочным признан сам эталон, — получает полный балл; более слабый ответ получает частичный балл, ошибочный — мало баллов или ноль. Число получает частичный балл, если поле это допускает (молекулярная масса 273.37 против 273.35, период полураспада 12 против 15), и не засчитывается там, где важна точность (год выхода 2020 против 2023). Значение, оставленное в эталоне пустым, оценивается отдельно: подтверждённое как верное, оно засчитывается как значение, которое должно было быть в эталоне и которое нашла модель, — оценка растёт, а не просто не снижается, — и эталон принимает это значение.
Настройка строгости управляет порогом эмбеддингов: чем выше, тем более похожими должны быть два по-разному записанных значения, чтобы считаться одинаковыми. Строгость, необязательная модель-судья и модель эмбеддингов задаются в сценарии — а не выбираются каждый раз при оценке — поэтому каждая модель оценивается одинаково, и результаты остаются сопоставимыми.
Списки — актёрский состав фильма, побочные эффекты препарата — это то, где модели различаются сильнее всего: небольшая модель может найти 4 актёров там, где сильная находит 15. Порядок не важен, и находка большего числа верных элементов должна побеждать. Поэтому массивы оцениваются как множество, а не позиция за позицией:
Разверните строку результата, чтобы увидеть, какие именно элементы были сопоставлены, пропущены или являются галлюцинациями.
Одно число скрывает слишком многое, поэтому каждый результат содержит промежуточные оценки:
Разворачиваемая строка показывает разбивку по каждому полю: кандидат против эталона, какая ступень лестницы приняла решение и, где это уместно, степень сходства.
Качество — лишь треть картины. Когда бенчмарк питает выбор модели — как источник оценок, — позиция модели складывается из сочетания качества, скорости и стоимости, и эта пропорция за вами: задайте её для каждого типа сценария в Настройки → Организация → Значения по умолчанию; каждая группа в сумме даёт 100, по умолчанию доли равны. Задайте стоимости большой вес — и дешёвая, приличная модель обойдёт отличную дорогую: для одних задач это верный ответ, для других — нет, поэтому платформа не решает это за вас. Скорость и стоимость считываются относительно других результатов сценария по логарифмической шкале: самая быстрая или самая дешёвая модель получает 100, а та, что в десять раз медленнее или дороже, — 0; но плотное поле никогда не растягивается на весь диапазон: две модели по $10 и $12 получат 100 и 92, а не 100 и 0.
Когда сценарий запускает модель более одного раза (повторы), каждый запуск оценивается отдельно, и в строке показывается среднее качество плюс разброс консистентности (от наименьшего до наибольшего среди запусков) — так что модель, которая в среднем верна, но нестабильна, легко заметить. Отображаемый вывод — это запуск с медианным качеством.
Бенчмарки не ограничиваются обогащением: сценарий может также тестировать генерацию образцов (каждая модель придумывает пример JSON по одному и тому же текстовому запросу) или генерацию схемы (каждая модель преобразует фиксированный образец в схему). У каждого варианта свои правила оценки:
В любом случае привычные столбцы сохраняют своё значение — наведите курсор на заголовок столбца, чтобы увидеть определение для конкретного типа, и разверните строку для полной детализации.
Оценивание — это отдельный проход по уже сохранённым результатам: он никогда не выполняет обогащение заново, поэтому не оплачивает повторно тестируемые модели. Но он строит эмбеддинги текста для сравнения значений (и запускает судью, если он задан в сценарии), что списывает кредиты по факту использования. Это происходит автоматически при каждом запуске — каждая модель оценивается сразу после завершения её запусков — и снова при каждой переоценке. Если в вашей организации не настроена модель эмбеддингов (и сценарий не задаёт переопределение), оценивание всё равно выполнится, но откатится только к точному совпадению (тогда альтернативные написания считаются несовпадениями) и сообщит об этом. С неработающим судьёй иначе: если вызов судьи завершается ошибкой, оценивание останавливается с явной ошибкой, и у затронутой модели не остаётся частичных оценок — результат либо оценён полностью, либо не оценён вовсе, и его можно переоценить позже. Ответы судьи кэшируются в пределах сценария по содержанию: один и тот же вопрос, поднятый другой моделью, повтором или проходом, никогда не оплачивается дважды, а переоценка после самообновления эталона заново задаёт вопросы только по изменённым полям. В работе судьи нет ничего скрытого: каждое оценивание модели оставляет запись оценивания в Истории — по строке на каждый вызов судьи с его промптом, ответом, токенами и стоимостью, включая неудавшиеся вызовы, а также число вопросов, на которые бесплатно ответил кэш, — а в таблице результатов рядом со ссылкой на неё показаны стоимость судьи, число вызовов и время оценивания для каждой модели. Выбирая оценщика, учтите, что LLM-оценщики могут отдавать предпочтение собственному семейству моделей — выбирайте оценщика от провайдера, который вы не тестируете в бенчмарке.
В разделе Управление моделями → Бенчмарки задайте и проверьте эталон в редакторе сценариев (там же выберите модель-судью, модель эмбеддингов и строгость). После этого каждый запуск автоматически оценивает свои успешные результаты — сортируемый столбец Качество заполняется без дополнительных действий. Используйте Переоценить результаты (кнопку в заголовке или меню ···), чтобы переоценить после правки эталона или настроек оценивания. Значок обновлений эталона рядом со статусом эталона открывает журнал изменений, внесённых проходами оценивания, с откатом для каждой записи.