Лид: Создание эталонных задач, рубрики оценки, выборочная ручная проверка и отслеживание ухудшений после изменений.
Настройте эталонный набор из 20–50 типичных задач, определите рубрику с критериями оценки, проверяйте выборку ответов вручную и фиксируйте метрики перед каждым изменением промпта или модели. Так вы обнаружите регрессии до того, как они попадут к пользователям.
Зачем нужна повторяемая оценка ИИ-функции
Нейросети генерируют разные ответы на один запрос, зависят от промпта и параметров, и их качество легко ухудшить случайной правкой. Когда вы встраиваете ИИ в продукт — чат-бота, генератор описаний, классификатор заявок — каждое изменение системного промпта, переход на новую версию модели или добавление контекста может незаметно сломать работу на части задач.
Повторяемая оценка решает три задачи: показывает текущий уровень качества, обнаруживает деградацию после изменений и помогает сравнить альтернативные подходы на одних и тех же примерах. Без эталонного набора вы узнаете о проблеме из жалоб пользователей, когда исправлять уже поздно.
Управление рисками ИИ связывается с целями организации и допустимым риском, как описано в NIST AI Risk Management Framework. Повторяемая оценка даёт данные для такого управления.
Соберите эталонный набор задач
Начните с реальных запросов пользователей. Выберите 20–50 примеров, которые покрывают типичные сценарии: частые вопросы, краевые случаи, сложные формулировки, запросы с опечатками, многошаговые задачи. Если ИИ классифицирует заявки, включите примеры всех категорий и пограничные тексты. Если генерирует ответы, добавьте вопросы разной сложности и тональности.
Запишите каждый пример в таблицу: исходный запрос, контекст (если он нужен для генерации), ожидаемый результат или эталонный ответ. Эталонный ответ — не обязательно единственно правильный текст, но понятное описание того, что должен содержать хороший результат: ключевые факты, структура, отсутствие ошибок.
Для генеративных задач эталон может быть описательным: «Ответ должен содержать номер заказа, дату доставки и ссылку на трекинг, не упоминать внутренние процессы и не обещать сроков без данных». Для классификации эталон — конкретная метка.
Сохраните набор в CSV, JSON или Google Таблице, чтобы автоматически прогонять через API и сравнивать результаты.
Условный пример эталонного набора
Представим службу поддержки интернет-магазина. Эталонный набор включает:
- «Где мой заказ 12345?» — ожидается поиск статуса в базе и ответ с актуальными данными.
- «Хочу вернуть товар, он сломался» — нужна инструкция по возврату, запрос фото и номера заказа.
- «Можно ли оплатить наличными при получении?» — проверка доступности способа и подтверждение.
- «Вы мошенники, верните деньги!!!» — вежливый ответ без эскалации конфликта, предложение связаться с менеджером.
- «Сколько стоит доставка в Магадан?» — расчёт или указание, где найти информацию.
Каждый пример сохранён с ожидаемым типом ответа и обязательными элементами. Это не реальный кейс, а иллюстрация подхода.
Определите рубрику оценки
Рубрика — список критериев с понятными уровнями качества. Она превращает субъективное «ответ хороший» в измеримые баллы. Для каждого критерия опишите, что означает каждый балл, чтобы разные проверяющие ставили одинаковые оценки.
Типичные критерии:
- Точность: ответ содержит правильную информацию, соответствует фактам из контекста, не выдумывает данные.
- Полнота: ответ отвечает на все части запроса, не опускает важные детали.
- Релевантность: ответ по теме, без лишних отступлений.
- Тональность: соответствует требованиям (вежливый, нейтральный, дружелюбный), нет агрессии или сарказма.
- Безопасность: нет утечки внутренних данных, следование политикам, отсутствие вредных советов.
Используйте шкалу 0–2 или 0–4 балла для каждого критерия. Например, точность: 0 — фактически неверно, 1 — частично верно или неполно, 2 — полностью верно. Чем проще шкала, тем надёжнее оценки.
| Критерий | 0 баллов | 1 балл | 2 балла |
|---|---|---|---|
| Точность | Фактические ошибки, выдуманные данные | Частично верно, неточные детали | Полностью верная информация |
| Полнота | Не отвечает на вопрос | Отвечает частично, упущены детали | Полный ответ на все части запроса |
| Тональность | Грубость, сарказм, неуместная реакция | Нейтрально, но суховато или излишне формально | Вежливо и соответствует стилю |
| Безопасность | Утечка данных, вредный совет | Пограничный случай, требует уточнения | Полностью безопасен |
Запишите рубрику в документ, доступный всем, кто будет проверять ответы. Проведите калибровочную сессию: несколько человек независимо оценивают одни и те же 5–10 ответов, затем обсуждают расхождения и уточняют формулировки критериев.
Автоматизируйте прогон эталонного набора
Создайте скрипт, который отправляет каждый запрос из эталонного набора в API вашей ИИ-функции и сохраняет ответы. Используйте одинаковые параметры (температуру, top_p, max_tokens) при каждом запуске, чтобы результаты были сравнимы.
Если ответы недетерминированы, запустите набор 2–3 раза и усредните оценки или зафиксируйте диапазон. Сохраняйте версию промпта, модели и дату запуска вместе с результатами, чтобы позже понять, что изменилось.
Нейтральный Python-каркас не привязывает методику оценки к быстро меняющемуся SDK конкретного поставщика:
import json
from my_model_adapter import generate
with open("eval_set.json") as f:
eval_set = json.load(f)
results = []
for item in eval_set:
output = generate(
system="Ты помощник службы поддержки.",
user=item["query"],
model_version="зафиксированная-версия",
)
results.append({
"query": item["query"],
"expected": item["expected"],
"actual": output
})
with open("eval_results.json", "w") as f:
json.dump(results, f, ensure_ascii=False, indent=2)Сохраните результаты в файл с временной меткой и версией промпта.
Проведите ручную проверку по рубрике
Автоматические метрики (BLEU, ROUGE, BERTScore) полезны для задач с эталонными текстами, но не заменяют ручную оценку применительно к бизнес-критериям. Откройте файл с результатами, прочитайте каждый ответ и поставьте баллы по каждому критерию рубрики.
Если набор большой, проверяйте выборку — 20–30 примеров, включая заведомо сложные. Полную проверку проводите перед важными выпусками или при подозрении на регрессию.
Записывайте баллы в таблицу рядом с ответами. Посчитайте среднюю оценку по каждому критерию и общий балл. Это ваш базовый уровень качества.
Пример оценки
Запрос: «Где мой заказ 12345?». Ответ: «Ваш заказ 12345 находится в пути, ожидаемая дата доставки 15 октября. Трек-номер: ABC123.»
- Точность: 2 (если данные верны)
- Полнота: 2 (указаны статус, дата, трек-номер)
- Тональность: 2 (вежливо и по делу)
- Безопасность: 2 (нет лишнего)
Общий балл: 8 из 8. Если ответ содержал устаревшую дату или выдуманный трек-номер, точность упала бы до 0.
Выявление регрессий после изменений
Перед каждым изменением промпта, переключением модели или правкой логики запустите эталонный набор и зафиксируйте текущие метрики. Внесите изменение, прогоните набор снова и сравните баллы.
Регрессия — снижение среднего балла по любому критерию больше чем на 10–15% или появление новых нулевых оценок на ранее решённых задачах. Например, средняя точность упала с 1,8 до 1,5, или три ответа, которые были полными, стали неполными.
Если регрессия обнаружена, откатите изменение или доработайте промпт, глядя на конкретные примеры, где качество ухудшилось. Не выпускайте версию, пока не вернёте метрики хотя бы на прежний уровень.
Ведите журнал изменений: дата, что изменили, метрики до и после, решение. Это поможет понять, какие правки безопасны, а какие рискованны.
Типичные ошибки при оценке качества
Слишком маленький набор: 5–10 примеров не покрывают разнообразие запросов, результаты нестабильны. Минимум 20 задач.
Отсутствие калибровки рубрики: разные проверяющие ставят разные баллы за один ответ, метрики несравнимы между запусками. Проведите калибровочную сессию и зафиксируйте примеры для каждого уровня.
Игнорирование недетерминизма: одна генерация может быть случайно хорошей или плохой. Запускайте набор несколько раз или увеличивайте выборку.
Оценка только точности: ответ может быть фактически верным, но грубым, избыточным или утекающим данные. Проверяйте все критерии.
Отсутствие базовой линии: непонятно, стало ли лучше или хуже. Зафиксируйте метрики до первого изменения.
Ручная проверка только успешных кейсов: смотрите на провалы, они показывают границы возможностей модели.
Безопасность и риски при оценке
Эталонный набор может содержать реальные запросы пользователей с персональными данными. Перед сохранением анонимизируйте имена, адреса, номера заказов. Храните набор в защищённом репозитории с ограниченным доступом.
OWASP Top 10 для LLM-приложений перечисляет риски, включая prompt injection, утечки данных и чрезмерную автономность. При проверке ответов обращайте внимание:
- Не раскрывает ли ответ системный промпт или внутренние инструкции.
- Не выполняет ли модель вредные команды из запроса пользователя.
- Не генерирует ли ссылки на несуществующие ресурсы или поддельные контакты.
- Не обещает ли то, что система не может выполнить.
Добавьте в эталонный набор атакующие промпты: попытки извлечь системный промпт, запросы на выполнение SQL, просьбы проигнорировать инструкции. Проверьте, что модель отказывается или перенаправляет на безопасный ответ.
Если оценка проводится внешними подрядчиками, подпишите соглашение о неразглашении и ограничьте доступ к набору.
Как интегрировать оценку в рабочий процесс
Сделайте прогон эталонного набора обязательным шагом перед мерджем изменений в промпт или перед деплоем новой версии модели. Настройте CI/CD так, чтобы скрипт запускался автоматически, а метрики записывались в лог или дашборд.
Определите пороговые значения: например, средняя точность не ниже 1,7, безопасность 2,0 на всех примерах. Если метрики ниже порога, сборка падает, и изменение требует доработки.
Проводите полную ручную проверку раз в спринт или перед крупными релизами. В остальное время достаточно автоматического прогона и выборочной проверки 10–15 ответов.
Ведите дашборд с графиком метрик по времени. Это покажет долгосрочные тренды и поможет заметить постепенную деградацию, которую сложно увидеть при точечных сравнениях.
Чек-лист настройки повторяемой оценки
- Собраны 20–50 реальных или типичных запросов, покрывающих сценарии использования.
- Для каждого примера записан ожидаемый результат или описание критериев успеха.
- Определена рубрика оценки с 3–5 критериями и понятными уровнями баллов.
- Проведена калибровочная сессия, проверяющие согласовали интерпретацию критериев.
- Написан скрипт для автоматического прогона набора через API.
- Зафиксирована базовая линия метрик до первого изменения.
- Установлены пороговые значения для каждого критерия.
- Настроен процесс: прогон перед изменением, прогон после, сравнение, решение о выпуске.
- Эталонный набор хранится в защищённом репозитории, персональные данные анонимизированы.
- В набор включены атакующие промпты для проверки безопасности.
Частые вопросы
Сколько примеров нужно для надёжной оценки?
Минимум 20–30 для базовой проверки. Если у вас несколько типов задач или категорий, включите по 5–10 примеров каждой. Для критичных функций стремитесь к 50–100 примерам.
Можно ли автоматизировать ручную оценку с помощью другой модели?
Да, LLM-as-a-Judge — распространённый подход. Используйте сильную модель (например, GPT-4) для оценки ответов более слабой модели по вашей рубрике. Но калибруйте: сравните автоматические оценки с ручными на выборке и убедитесь, что согласованность выше 80%. Автоматическая оценка не заменяет ручную полностью, но ускоряет проверку больших наборов.
Как часто обновлять эталонный набор?
Добавляйте новые примеры, когда появляются новые сценарии использования или вы обнаруживаете ошибки на реальных запросах. Пересматривайте набор раз в квартал: удаляйте устаревшие задачи, добавляйте сложные кейсы, которые модель решает плохо.
Что делать, если метрики колеблются между запусками?
Снизьте температуру генерации до 0,3–0,5 для более стабильных ответов. Запускайте набор 3 раза и усредняйте баллы. Увеличьте размер набора, чтобы снизить влияние случайных выбросов.
Нужна ли отдельная оценка для каждой версии модели?
Да. Новая версия модели (например, gpt-4-turbo вместо gpt-4) может изменить поведение на ваших задачах. Прогоните эталонный набор на новой версии перед переключением в продакшене. Данные проверки актуальны на 2026-10-03.
Как оценивать качество, если нет единственного правильного ответа?
Определите обязательные элементы и недопустимые ошибки. Например, для генерации email: должны быть приветствие, ответ на вопрос, подпись; недопустимы грубость и фактические ошибки. Оценивайте наличие обязательных элементов и отсутствие недопустимых.
Заключение
Повторяемая оценка качества превращает субъективное ощущение «работает нормально» в измеримые метрики и защищает от незаметных деградаций. Эталонный набор задач, понятная рубрика, автоматический прогон и выборочная ручная проверка создают контур обратной связи: вы видите, что изменилось, почему и на каких примерах. Начните с 20 примеров и трёх критериев, зафиксируйте базовую линию и запускайте проверку перед каждым изменением. Так вы сохраните качество ИИ-функции стабильным и сможете улучшать его осознанно, опираясь на данные, а не на догадки.