Чтобы надежно оценивать ИИ-промпты, запускайте каждую редакцию на одной версии случаев, с одинаковой конфигурацией, критериями и порогом выпуска. Повторяйте изменчивые ответы, сохраняйте все исходные результаты, отделяйте детерминированные сбои от человеческого суждения и показывайте неопределенность. Один удачный ответ — демонстрация, а не сравнительная оценка (benchmark).

Практическое руководство по ИИ объясняет общие границы данных и проверки. Здесь предполагается, что задача уже ограничена и требуется сравнить промпт A с B, не меняя вопрос по ходу эксперимента.

Ключевые выводы

Сначала определите решение, затем пишите случаи и смотрите ответы.

Зафиксируйте репрезентативную редакцию набора и по возможности отдельную отложенную выборку (holdout).

Оценивайте критические сбои отдельно от предпочтений и среднего качества.

Выровняйте модель, инструменты, параметры, источники поиска и условия запуска.

Скройте метки версий и перемешайте порядок для человеческой оценки.

Повторяйте запуски и показывайте распределение, а не лучший ответ или одно среднее.

Выпускайте претендента, только если он проходит явные проверки на регрессию и безопасность.

Как оценивать ИИ-промпты повторяемо?

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

Раздел Measure в AI RMF Playbook от NIST рекомендует документировать методы измерения, тестовые наборы, метрики, процессы, материалы и сведения об инструментах: такая основа повышает повторяемость и согласованность.［1］ Храните эту запись рядом с результатом.

Поле	Что фиксировать
Experiment ID	Стабильный ID и дата запуска
Решение	Какой выбор должен поддержать результат?
Редакции промптов	Неизменяемый текст или ссылки A и B
Редакция случаев	Точные случаи, метки, исключения и правило отложенной выборки
Редакция входа	Вложения, снимок поиска и предобработка
Ожидаемые свойства	Что полезный ответ должен содержать или сохранять?
Критические сбои	Какие исходы блокируют выпуск при любом балле?
Рубрика	Критерии, якоря шкалы, веса и правила при равенстве
Оценщики	Детерминированные проверки и роли людей
Конфигурация	Класс модели, инструменты, параметры, системные правила и права
Повторы	Число запусков каждой пары и рандомизация порядка
Доказательства	Исходные ответы, проверки, оценки и разногласия
Правило решения	Порог регрессии, неопределенность, утверждающий и итог

Это уже, чем составление сильного промпта: правка формулировок даёт кандидатов, а сравнительная оценка — доказательства для выбора между ними.

Шаг 1. Сформулируйте вопрос и правило выпуска

Запишите решение одним предложением: «Может ли редакция B заменить A для извлечения пяти утвержденных полей из англоязычных обращений?» Укажите популяцию, пользователей, контракт результата и исключенные применения. Расплывчатая цель вроде «какой промпт умнее?» не даёт обоснованного набора случаев.

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

Заранее задайте правило выпуска:

Выпустить B, только если:
1. в фиксированном критическом наборе нет критических сбоев;
2. все детерминированные контракты не хуже A;
3. медианная человеческая оценка не ниже согласованного предела;
4. ни одна заданная подгруппа или категория случаев не пересекла порог отказа;
5. изучены разногласия и разброс между запусками;
6. владелец задачи утвердил пакет доказательств.

Пороги должны следовать из риска и операционных нужд, а не из числа, при котором B выигрывает. Документируйте рассмотренные, но отклонённые меры и причины: NIST советует сохранять обоснование выбора метрик и сведения о неизмеряемых рисках.［1］

Шаг 2. Создайте и версионируйте набор тестовых случаев для промптов

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

Поле случая	Значение
Case ID	Стабильная метка, например `missing-owner-01`
Категория	Норма, граница, ошибка, атака или отказ
Вход	Зафиксированный очищенный или синтетический материал
Ожидаемые свойства	Обязательные факты, поля и поведение
Запрещенное поведение	Выдумка, утечка, неразрешенное действие или выход из формата
Серьезность	Критическая, значительная или малая
Метод оценки	Точное правило, программная проверка или человеческая рубрика
Обоснование	Почему случай представляет целевое применение?
Источник и право	Откуда взят паттерн и разрешено ли его оценивать?

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

Если объём позволяет, держите отдельно набор для разработки (итераций промпта) и отложенную выборку для решения о выпуске. Если авторы постоянно видят отложенную выборку и подстраивают текст под неё, она перестаёт быть независимым доказательством. Фиксируйте доступ и заменяйте раскрытые случаи через управляемое изменение, а не молча.

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

Шаг 3. Разделите программные проверки и человеческое суждение

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

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

Критерий	0	1	2
Верность доказательствам	Факт выдуман или перевернут	В основном верно, но есть неподтвержденный вывод	Каждое существенное утверждение связано с входом
Неопределенность	Важное неизвестное скрыто	Неопределенность упомянута без локализации	Неизвестное сохранено, названо недостающее доказательство
Практичность	Предложено опасное действие	Следующий шаг слишком общий	Шаг разрешен, имеет владельца и условие остановки

Критические сбои держите вне среднего: несколько баллов за стиль не должны перекрывать выдуманное согласование или утечку. Если ответ повреждён или у оценщика нет предметного контекста, записывайте «не оценивается»; не превращайте отсутствие доказательств в ноль или угаданный балл без заранее заданного правила.

Шаг 4. Зафиксируйте среду и запустите A и B

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

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

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

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

Не отбрасывайте отказ, тайм-аут или повреждённый ответ как «ненастоящий запуск»: классифицируйте его по заранее зарегистрированному правилу.

Шаг 5. Повторите изменчивые ответы и оцените неопределенность

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

Руководство Google SRE по надежности объясняет пользу повторных тестов для различения устойчивого поведения и шума, а также необходимость учитывать неопределенность.［3］ Храните распределение по категориям, а не только общее среднее.

Полезные сводки:

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

Избегайте ложной точности. Десять синтетических случаев не доказывают универсального качества в 97,3%. Опишите ровно то, что подтверждает выборка: редакция B показала такие результаты на редакции 4 набора случаев при записанной конфигурации.

Шаг 6. Проведите слепую оценку и разрешите разногласия

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

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

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

Шаг 7. Примите и задокументируйте решение

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

Профиль NIST для генеративного ИИ рассматривает оценку как часть постоянного управления рисками и человеческого контроля, включая конфабуляцию, приватность, безопасность и целостность информации.［4］ Одного среднего балла недостаточно.

Используйте один из четырёх исходов:

Выпуск: B проходит все обязательные проверки, и владелец принимает доказательства.
Доработка: B перспективен, но имеет исправимую регрессию или неясную инструкцию.
Сохранить A: B не даёт достаточной пользы или пересекает порог.
Нет вывода: недостаточность доказательств — выборка, рубрика, запись конфигурации или согласие рецензентов не позволяют принять решение.

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

Итоги

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

Часто задаваемые вопросы (FAQ)

Сколько случаев нужно для оценки промптов?

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

Сколько раз запускать каждый вариант?

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

Нужно ли сравнивать ответы дословно?

Только если точный текст является контрактом. Обычно сравнивают обязательные свойства, запрещенное поведение и рубрику, допуская корректные варианты формулировки.

Может ли ИИ выставлять оценки?

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

Что такое критический сбой при оценке промптов?

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

Как защитить набор от загрязнения?

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

Что делать при разногласии рецензентов?

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

Более высокий средний балл означает выпуск B?

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

Когда обновлять набор для оценки?

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

Источники

NIST — AI RMF Playbook, Measure — https://airc.nist.gov/airmf-resources/playbook/measure/
NIST — GenAI Evaluation Program — https://ai-challenges.nist.gov/genai
Google SRE — Testing for Reliability — https://sre.google/sre-book/testing-reliability/
NIST — Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile — https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence

Sources checked 4 сентября 2026 г.

Как оценивать ИИ-промпты на повторяемом наборе тестов