Оценки для не-инженеров: как понять, становится ли ваш ИИ-процесс лучше или хуже

Вот паттерн, который мы видим постоянно. Команда собрала ИИ-процесс — для черновиков контента, классификации обращений в поддержку, генерации писем продаж, неважно. На первой неделе работает. Команда в восторге. Раскатывают.

Через три месяца — что-то не так. Качество вывода ощущается хуже. Клиенты жалуются. Менеджеры перестают пользоваться. Никто не знает, когда это изменилось и почему.

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

Решение — оценки: систематическое измерение качества выводов ИИ. Оценки обычно считают инженерной темой, но они нужны любой команде, у которой есть ИИ-процессы. И базовый уровень доступен без кода.

Эта статья — о том, что такое оценки, зачем они нужны и как их настроить под любой ИИ-процесс, не будучи инженером.

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

Что такое оценки (и чем они не являются)

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

Компоненты:

• Датасет. Набор входов (того, что обрабатывает ваш ИИ).
• Ожидаемое поведение. Что вы хотите, чтобы ИИ сделал с этими входами.
• Метод оценки. Как вы измеряете, что ИИ сделал это правильно.
• Прогон/отчёт. Прогнать датасет, оценить каждый вывод, свести результат.

Смысл — иметь повторяемый способ спросить: «ИИ делает то, что я хочу, в нужном мне качестве?» — и замечать, когда ответ меняется.

Оценки — это не:

• Разовое тестирование при первой сборке.
• Точечные проверки, когда что-то ощущается не так.
• Обратная связь пользователей (она полезна, но реактивна, медленна и пристрастна).
• Ощущения («вывод выглядит правильным»).

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

Почему «инструменты для инженеров» не подходят большинству команд

Если погуглить «LLM evals», вы попадёте на статьи про Promptfoo, LangSmith, Braintrust, Helicone. Они хороши. Они также рассчитаны на инженеров, которые выпускают LLM-продукты в масштабе.

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

Хорошая новость: с таблицей и LLM это вполне делается. Не на уровне LangSmith, но достаточно, чтобы ловить большинство проблем с качеством.

Четыре паттерна оценки

Существует четыре распространённых паттерна. Каждый подходит под свой тип процесса.

Паттерн 1: точное совпадение

Использовать, когда есть единственный правильный ответ.

Пример процесса: классификация обращений в поддержку по 8 категориям.

Датасет: 50 тикетов с правильной категорией. Оценка: ответ ИИ либо совпадает с правильной категорией (1 балл), либо нет (0). Выход: процент правильных.

Хорошо работает для классификации, извлечения, простых структурированных выводов.

Паттерн 2: сравнение с эталоном

Использовать, когда есть известный эталонный ответ для сравнения.

Пример процесса: черновики описаний товара.

Датасет: 30 товаров с «эталонными» описаниями, которые вы написали сами. Оценка: насколько близко описание ИИ к эталону — по точности, тону, полноте?

Это можно оценивать вручную (человек читает оба и ставит 1–5) или через LLM-судью (следующий паттерн). Сравнение с эталоном — золотой стандарт для контент-процессов.

Паттерн 3: LLM-судья

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

Пример процесса: генерация персонализированных писем продаж.

Датасет: 30 профилей потенциальных клиентов. Оценка: LLM работает судьёй — получив вход и выход, оценивает по специфичности, профессиональности, длине, попаданию в голос.

LLM-судья полезен, но требует аккуратного дизайна промпта. Типичный паттерн:

Вы оцениваете письмо продаж на качество. Оцените его по этим измерениям:

1. Specificity (1-5): Ссылается ли оно на конкретные факты о потенциальном клиенте, а не на общую лесть?
2. Professionalism (1-5): Звучит ли оно как сообщение от равного, а не как спам?
3. Length appropriateness (1-5): Достаточно ли оно лаконично (40–80 слов)?
4. Voice match (1-5): Соответствует ли оно нашему голосу (прямой, без buzzwords)?

По каждому измерению укажите оценку и одно предложение с обоснованием.

Вывод в JSON: {"specificity": {"score": N, "reason": "..."}, ...}

Профиль потенциального клиента: [входные данные]
Письмо для оценки: [результат]

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

1. Создайте репрезентативный набор с человеческой разметкой. Используйте реальные случаи из очереди проверки, охватите важные классы и пограничные ситуации, отделите калибровку от итоговой оценки и зафиксируйте квалификацию разметчиков по каждому критерию.
2. Прогоните судью на том же наборе и разберите каждое расхождение. Показывайте матрицу ошибок или согласие по отдельным оценкам, а не только одно среднее. Причина может быть в рубрике, человеческой метке или судье — это нужно исследовать, а не угадывать.
3. Учитывайте направление и последствия ошибки. Судья, пропускающий опасный результат, может быть неприемлем даже при высоком общем согласии. Определяйте критерии выпуска по цене ложного допуска и ложного отказа.
4. Повторяйте калибровку после каждого существенного изменения модели или версии судьи, промпта, рубрики, языка, распределения входных данных либо политики. Размер выборки определяйте по распространённости классов и требуемой уверенности: универсального числа примеров нет.

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

Паттерн 4: проверка свойств

Использовать, когда вы можете выразить «хорошо» как набор конкретных тестируемых свойств.

Пример процесса: генерация заголовков товаров для интернет-магазина.

Датасет: 50 товаров. Свойства для проверки на каждом выводе:

• Длина 30–70 символов.
• Включает название бренда.
• Включает хотя бы один ключевой атрибут товара.
• Не использует запрещённые маркетинговые слова («amazing», «best», «revolutionary»).

Каждое свойство — тест «да/нет». Оценка = % прошедших свойств по всем выводам.

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

Как настроить свою первую оценку

Практическая настройка, дружелюбная к не-инженеру.

Шаг 1: выбрать процесс

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

Пример: «ИИ, который классифицирует входящие обращения в поддержку по теме».

Шаг 2: собрать датасет

Соберите 20–50 репрезентативных примеров. Включите:

• Простые случаи (явно категория A).
• Сложные (могут быть A или B).
• Граничные (ни одна категория не подходит чисто).
• Частые вариации (разные формулировки одного намерения).

Фиксируйте в таблице или Google Sheet:

Этот датасет и есть ваш набор оценки. Он не должен меняться часто — его смысл в том, чтобы быть стабильной точкой отсчёта.

Шаг 3: определить оценку

Что для каждого примера считается правильным ответом? Будьте конкретны.

Для классификации: точное совпадение категории. Для контента: оценка 1–5 по каждому из 2–4 названных измерений. Для извлечения: каждое поле правильно/неправильно.

Запишите рубрику. Держитесь её.

Шаг 4: прогнать процесс на датасете

Запустите ваш ИИ-процесс на каждом примере. Сохраните вывод в новой колонке.

Для классификации это можно делать в таблице через функцию вроде GPT-интеграции Google Sheets или вручную, копированием.

Для более сложных процессов — закидывайте входы в Promptfoo или просто раз в неделю запускайте пакетный прогон.

Шаг 5: оценить

Для точного совпадения: колонка «match» с 1, если ожидаемый вывод совпал с фактическим, иначе 0. Суммируйте — это ваша точность.

Для LLM-судьи: прогон судейского промпта по каждому выводу. Сохраняйте оценки.

Для проверки свойств: каждое свойство — отдельный тест. Агрегируйте.

Минимально полезная таблица оценки

Для первой оценки отслеживайте меньше измерений, но сделайте каждое пригодным для действия.

Таблица оценки должна называть владельца и правило выпуска. «Ниже 90% корректности означает ревью владельцем продукта» сильнее, чем «отслеживаем корректность».

Шаг 6: свести

Сводная таблица вроде:

Со временем это даёт траекторию качества. Просадки запускают разбирательство.

Шаг 7: расписание

Гоняйте оценку по регулярному расписанию. Для большинства процессов хватит раза в неделю. После любого изменения в промптах или модели — прогоняйте до выкатки.

Привычка на 30 минут в неделю. Поставьте повторяющийся блок в календарь. Не пропускайте.

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

Добавьте контроль перед выпуском

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

1. Базовая линия. У текущего производственного процесса есть записанная оценка.
2. Кандидат. Новый промпт, модель, инструмент или шаг процесса прогоняется на том же наборе оценки.
3. Сравнение. Кандидат должен сохранить оценки безопасности и регрессии и не снижать основной показатель качества сверх согласованного допуска.
4. Решение. Выпустить, отложить, доработать или откатить. Зафиксировать причину.
5. Проверка после выпуска. Повторно прогнать на небольшой выборке реальных кейсов после запуска.

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

Что делать, когда оценки падают

Смысл оценок — ловить деградацию. Когда она случилась — разбираетесь.

Простой разбор:

Шаг 1: найти проваленные кейсы. Что конкретно пошло не так?

Шаг 2: искать паттерн. Провалы кластеризованы (похожие входы)? Или разбросаны (разные типы)?

Шаг 3: диагноз.

• Паттерн → скорее всего, конкретная слабость (промпт, нехватка знаний).
• Разброс → скорее всего, общая просадка качества (смена модели, дрейф).

Шаг 4: гипотеза о причине.

• Не менялась ли базовая модель? Проверьте журнал изменений провайдера.
• Не менялся ли промпт? Откатите и проверьте.
• Не сместилось ли распределение входов? Посмотрите свежие реальные данные.
• Не устарел ли датасет? Освежите примеры.

Шаг 5: проверить исправление. Внесите одно изменение. Перепрогоните оценку. Восстановилось ли?

Такой системный подход бьёт панику и догадки.

Как развивать датасет со временем

Стартовый датасет — это точка отсчёта. Развивайте его так:

Добавляйте реальные провалы. Когда живой клиентский/пользовательский кейс дал плохой вывод — добавьте его в набор оценки. Теперь это регрессионный тест: повторись провал — поймаете.

Чистите устаревшее. По мере эволюции процесса часть тест-кейсов теряет смысл. Убирайте.

Расширяйте покрытие. Если в наборе 20 кейсов «account-access» и 1 «billing» — он перекошен. Пересбалансируйте.

Добавляйте граничные кейсы по мере их обнаружения. Новые паттерны жалоб, новые фичи продукта, новые категории.

Хороший набор оценки живой — он отражает текущую реальность, а не историческую.

Типовые ошибки

Несколько паттернов, из-за которых программы оценки проваливаются.

Ошибка 1: ждать идеальной оценки до старта. За датасет на 50 примеров со сложной системой оценки страшно даже браться. 10 примеров с простой оценкой — реально сделать сегодня. Стартуйте с малого. Итерируйте.

Ошибка 2: оценивать только благополучные сценарии. Сплошь лёгкие примеры реальных провалов не ловят. Включайте сложные, граничные и ранее провалившиеся кейсы.

Ошибка 3: дрейф набора оценки. Если обновлять набор оценки каждый раз, когда меняется процесс, оценка теряет смысл. Набор оценки должен меняться редко; процесс может чаще. Смысл — мерить процесс, а не сам набор.

Ошибка 4: слепо доверять LLM-судье. У LLM-судей есть предвзятости. Они переоценивают поверхностные признаки (длину, формат). Регулярно калибруйте судью по людским оценкам. Если вы не согласны с судьёй — промпт судьи нуждается в доработке.

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

Ошибка 6: мерить только одно измерение. «Оценка показывает 95% точности!» — но, возможно, качество ответа просело, или скорость, или выросла частота галлюцинаций. Отслеживайте несколько измерений там, где они важны.

Инструменты в помощь (но необязательные)

Если хотите вырасти из таблиц, доступные варианты:

Promptfoo. Инструмент с открытым исходным кодом, конфигурируется через YAML, гоняется локально или в CI. Отличный для тестов промптов и их сравнения.

Braintrust. Хостинговая платформа для оценок с приятным UI. Дороже, но мощно.

LangSmith. Завязан на LangChain; полезен, если вы в этой экосистеме.

Helicone. Логирование и аналитика для LLM-вызовов, с возможностями оценки.

OpenAI Evals. Фреймворк с открытым исходным кодом, более ориентированный на разработчиков.

Большинству не-инженерных команд хватит таблицы + ChatGPT/Claude. Promptfoo — самый простой «настоящий инструмент», если хочется вырасти.

4-недельная программа оценки

Для команды, стартующей с нуля, реалистичный план:

Неделя 1: выбор и определение.

• Выберите один процесс.
• Соберите датасет из 20 примеров.
• Определите оценку (точное совпадение, LLM-судья или свойства).

Неделя 2: первая базовая линия.

• Прогоните оценку. Запишите базовую оценку.
• Идентифицируйте очевидные провалы.
• Пока ничего не меняйте — наблюдайте.

Неделя 3: итерация.

• Внесите одно изменение, которое, по-вашему, улучшит качество.
• Перепрогоните оценку.
• Оценка выросла? Упала? Та же? Разберитесь, почему.

Неделя 4: расписание.

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

За 4 недели у вас рабочая оценка. Дальше расширяйте: добавляйте процессы в программу, углубляйте датасет, уточняйте оценку.

Культурный сдвиг

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

Сдвиг включает:

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

Инвестиции в калибровку. Первый месяц новой оценки — это время на настройку датасета, оценки и промптов. Это инвестиция.

Привычка «до/после». Любое нетривиальное изменение в ИИ-процессе проходит через оценку до выкатки. Это становится рефлексом.

Держать планку по качеству. Когда оценка падает — чините или откатывайте. Не выкатывайте с просевшим качеством только потому, что дедлайн.

Этот культурный сдвиг — самая сложная часть. Когда он состоялся, инструментальная часть простая.

Один процесс, двадцать примеров, полчаса в неделю

Оценки — это разница между ИИ-процессами, которым можно доверять во времени, и ИИ-процессами, которые незаметно сползают в посредственность.

Не нужны ни инженеры, ни ML-экспертиза, ни навороченные инструменты. Нужны: процесс, который стоит мерить, маленький датасет, метод оценки и полчаса в неделю.

Выберите один процесс на этой неделе. Соберите оценку на 20 примеров. Прогоните. Посмотрите на результат. Прогоните ещё раз на следующей неделе. Заметьте, какую дисциплину это выстраивает.

Через 6 месяцев у команд с оценками будут ИИ-процессы, которые реально стали лучше. У команд без оценок — те же процессы, что и полгода назад, только хуже.