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

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

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

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

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

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

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

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

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

Компоненты:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

You are evaluating a sales email for quality. Score it on these dimensions:

1. Specificity (1-5): Does it reference specific facts about the prospect, not generic flattery?
2. Professionalism (1-5): Does it sound like a peer rather than spam?
3. Length appropriateness (1-5): Is it concise (40-80 words)?
4. Voice match (1-5): Does it match our voice (direct, no buzzwords)?

For each dimension, give the score and a one-sentence reason.

Output JSON: {"specificity": {"score": N, "reason": "..."}, ...}

Prospect profile: [input]
Email to evaluate: [output]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

| ID | Вход | Ожидаемый вывод | |----|-------|-----------------| | 1 | "My password isn't working" | "account-access" | | 2 | "I want to cancel my subscription" | "billing" | | 3 | "Your latest update broke my workflow" | "bug" | | ... | ... | ... |

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

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

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

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

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

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

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

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

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

| ID | Вход | Ожидаемо | Фактически | |----|-------|----------|--------| | 1 | ... | "account-access" | "account-access" | | 2 | ... | "billing" | "billing" | | 3 | ... | "bug" | "feature-request" | | ... | ... | ... | ... |

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

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

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

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

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

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

| Измерение | Вопрос | Порог прохождения | Действие, если ниже порога | | --- | --- | --- | --- | | Корректность | Процесс дал правильный ответ или классификацию? | 90% | Разобрать провалы перед выпуском | | Безопасность | Избежал ли он запрещённого контента, неподтверждённых утверждений или рискованных действий? | 100% | Заблокировать выпуск | | Формат | Вернул ли он ожидаемую структуру? | 95% | Исправить промпт/схему перед выпуском | | Полезность | Принял бы пользователь такой вывод как разумный? | среднее 4/5 | Пересмотреть примеры или инструкции | | Регрессия | Остались ли исправленными известные прошлые провалы? | 100% | Заблокировать выпуск |

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

Шаг 6: свести

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

| Дата оценки | Оценка | Заметки | |-----------|-------|-------| | 2026-05-01 | 47/50 (94%) | Базовая линия. 3 ошибки: тикеты 8, 23, 41. | | 2026-05-08 | 46/50 (92%) | Стабильно. 4 ошибки. | | 2026-05-15 | 44/50 (88%) | Просадка. Новые ошибки в тикетах 12, 35. |

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ошибка 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 месяцев у команд с оценками будут ИИ-процессы, которые реально стали лучше. У команд без оценок — те же процессы, что и полгода назад, только хуже.