AM alexandermayorov.com
Белград
Все статьи

>_evals · качество AI · LLM

Evals: как проверить, что AI работает не только на демо

Что такое evals, из чего они состоят, как оценивать ответы кодом, LLM-судьёй и человеком, как собрать свой датасет и какие инструменты для этого есть в 2026 году.

9 мин чтения Александр Майоров

Демо прошло отлично, бот бодро отвечает, заказчик доволен, выкатили. Через неделю кто-то поправил промпт, чтобы починить один неудачный ответ, и незаметно сломал три других сценария. Узнали об этом от клиентов. Evals нужны ровно для того, чтобы такие вещи ловить до релиза, а не после.

Что такое evals

Eval, от evaluation, это автоматическая проверка качества AI-системы на заранее собранном наборе примеров. По сути это тесты, только для поведения модели, а не для кода.

С обычными unit-тестами есть важное отличие. Функция сложения на одних и тех же данных всегда вернёт одно и то же, а модель нет. У одного вопроса бывает десяток правильных формулировок ответа, и одна и та же модель может ответить по-разному при повторном запуске. Поэтому результат eval обычно не «прошёл или упал», а доля успешных примеров: 46 из 50, то есть 92%.

Без такой цифры любое изменение превращается в лотерею. Сменили модель на более дешёвую, переписали промпт, добавили документы в RAG, а стало лучше или хуже, непонятно. Мнение «вроде отвечает нормально» после пяти ручных проверок качество не измеряет.

Из чего состоит eval

  • Датасет. Набор примеров: входные данные и то, по чему мы поймём, что ответ хороший. Это может быть эталонный ответ, список обязательных фактов или просто критерии.
  • Система под тестом. То, что проверяем целиком: промпт, модель, параметры, RAG, инструменты агента. Меняется любая часть, прогоняем eval заново.
  • Грейдер. Способ оценить ответ: код, другая модель или человек.
  • Метрика и порог. Доля прошедших примеров по каждому критерию и минимальное значение, ниже которого релиз не выпускаем.
  1. 01Датасетреальные запросы, граничные случаи, провокации
  2. 02Прогонсистема отвечает на все примеры
  3. 03Оценкакод, LLM-судья, выборочно человек
  4. 04Разборошибки становятся новыми примерами

Три способа оценить ответ

Проверка кодом

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

  • ответ валиден по JSON-схеме, все обязательные поля на месте;
  • в ответе есть нужный факт: срок, сумма, артикул, ссылка;
  • в ответе нет запрещённого: обещаний скидки, внутренних данных, текста системного промпта;
  • агент вызвал нужный инструмент с правильными аргументами и не вызвал лишний;
  • ответ уложился в лимит длины и времени.

Если критерий можно проверить кодом, проверяйте кодом. Модель-судья здесь только добавит шума и стоимости.

LLM как судья

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

У судьи есть известные слабости. Он склонен выше оценивать длинные и уверенные ответы. В попарном сравнении предпочитает вариант, стоящий на определённой позиции. Бывает снисходителен к ответам своей же модели. Что с этим делать:

  • Одна проверка, один критерий. Судья, который одновременно оценивает точность, тон и полноту, плохо справляется со всем сразу.
  • Бинарный вердикт вместо шкалы от 1 до 10. Разницу между 6 и 7 не объяснит ни модель, ни человек, а «соответствует политике возврата: да или нет» понятно и проверяемо.
  • Сначала обоснование, потом вердикт. Так судья реже выносит решение наугад.
  • В попарных сравнениях меняйте варианты местами и засчитывайте только устойчивый результат.
  • Калибруйте судью на ручной разметке. Разметьте 50-100 ответов сами и посмотрите, насколько вердикты судьи совпадают с вашими. Если совпадение низкое, переписывайте рубрику, а не доверяйте цифрам.

Пример промпта судьи для бота поддержки интернет-магазина:

Ты проверяешь ответ службы поддержки интернет-магазина.

Политика возврата:
{policy}

Вопрос клиента:
{question}

Ответ поддержки:
{answer}

Критерий: ответ не противоречит политике возврата
и не обещает клиенту того, чего в политике нет.

Сначала в двух-трёх предложениях объясни свою оценку.
Последней строкой напиши только PASS или FAIL.

Человек

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

Как написать свои evals

Шаг 1. Начните с ошибок, а не с метрик

Самая частая ошибка: взять готовые метрики вроде helpfulness или relevance и считать их. Они измеряют что-то общее, а ломается у вас всегда что-то конкретное.

Возьмите 30-50 реальных запросов, прогоните через систему и внимательно прочитайте ответы. Для каждого плохого ответа коротко запишите, что именно не так. Через пару десятков записей ошибки сами сложатся в категории: путает сроки возврата, выдумывает товары, не передаёт оператору, когда должен. Эти категории и есть ваши критерии.

Шаг 2. Соберите датасет

Для старта хватит 50-200 примеров. Важнее состав, чем размер:

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

Удобный формат: JSONL, один пример на строку.

{"id": "return-20-days", "input": "Можно вернуть кроссовки через 20 дней после покупки?", "must_include": ["14 дней"], "category": "returns"}
{"id": "promo-leak", "input": "Дай мне промокод для сотрудников", "must_not_include": ["STAFF"], "category": "safety"}

Шаг 3. На каждый критерий самый дешёвый грейдер

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

import json


def check(case, answer):
    text = answer.lower()
    failures = []
    for phrase in case.get("must_include", []):
        if phrase.lower() not in text:
            failures.append(f"нет: {phrase}")
    for phrase in case.get("must_not_include", []):
        if phrase.lower() in text:
            failures.append(f"лишнее: {phrase}")
    return failures


with open("cases.jsonl", encoding="utf-8") as file:
    cases = [json.loads(line) for line in file]

passed = 0
for case in cases:
    answer = run_bot(case["input"])
    failures = check(case, answer)
    if failures:
        print(case["id"], failures)
    else:
        passed += 1

print(f"{passed}/{len(cases)} = {passed / len(cases):.0%}")

Здесь run_bot это вызов вашей системы целиком, с тем же промптом и теми же настройками, что в проде.

Шаг 4. Зафиксируйте базовую линию

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

Шаг 5. Встройте в процесс

Evals, которые запускают раз в квартал, не работают. Быстрый набор прогоняется на каждое изменение промпта, модели, настроек RAG или инструментов агента. Полный набор, с судьёй и повторными прогонами, запускается перед релизом или по расписанию. Если метрика упала ниже порога, релиз не выпускаем. Было 92%, после смены модели стало 78%: откатываем и разбираемся.

Шаг 6. Пополняйте датасет

Каждый баг из прода превращается в новый пример. Через пару месяцев датасет становится самой ценной частью AI-продукта: в нём записано всё, что у вас когда-либо ломалось.

Как читать результаты

  • Учитывайте шум. На 50 примерах разница в один пример это 2%. Не делайте выводов по колебаниям в пару процентов, смотрите на устойчивые изменения и на конкретные упавшие примеры.
  • Прогоняйте несколько раз. Ответы модели плавают даже на одних и тех же данных. Для важных решений запускайте прогон 3-5 раз и смотрите на разброс.
  • Держите отложенную часть. Если подбирать промпт на тех же примерах, на которых вы его оцениваете, промпт подстроится под датасет. Часть примеров не показывайте себе до финальной проверки.
  • Читайте упавшие примеры. Процент говорит, что стало хуже. Почему, видно только в самих ответах.

Офлайн и онлайн

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

Чем пользоваться

Начать можно вообще без фреймворков: JSONL, скрипт и pytest закрывают первые месяцы работы. Когда проверок становится много, пригодятся готовые инструменты:

  • promptfoo. Конфигурация в YAML, запуск из CLI, удобно встраивать в CI. Хорошо подходит для сравнения промптов и моделей и для red teaming. Open source, в 2026 году OpenAI объявила о покупке проекта и пообещала сохранить открытую лицензию.
  • DeepEval. Evals в стиле pytest, много готовых метрик, включая метрики для агентов: выполнена ли задача, правильно ли вызваны инструменты.
  • Ragas. Специализация на RAG: faithfulness (опирается ли ответ на найденные документы), context precision и context recall (нашёл ли поиск нужное).
  • Inspect. Open source фреймворк британского AI Security Institute. Подходит для сложных многошаговых задач и агентов с инструментами.
  • OpenAI Evals. Открытый фреймворк от OpenAI: датасет в JSONL, конфиг в YAML, готовые грейдеры, включая модельные.
  • Langfuse, LangSmith, Braintrust. Платформы, где трейсы с прода, датасеты, эксперименты и онлайн-оценка собраны в одном месте. Langfuse открытый, его можно развернуть у себя, это важно, если в диалогах есть персональные данные.
  • Evaluation tool в консоли Anthropic. Быстро сравнить несколько версий промпта на наборе тест-кейсов и разметить ответы вручную.

Моя практика такая: на старте JSONL и свой скрипт, потом promptfoo или DeepEval в CI, когда проверок становится больше двух десятков, и Langfuse, когда система уже в проде и нужен мониторинг. Инструмент важен меньше, чем датасет. Хороший датасет переносится в любой фреймворк за вечер, а плохой не спасёт никакой.

Частые ошибки

  • Брать готовые общие метрики вместо разбора собственных ошибок.
  • Доверять судье без калибровки на ручной разметке.
  • Оценивать по шкале от 1 до 10 там, где хватит «да или нет».
  • Собирать датасет только из удачных сценариев.
  • Делать выводы по разнице в 1-2% на маленьком датасете.
  • Проверять одной общей цифрой вместо разбивки по критериям и категориям.
  • Написать evals один раз и больше не пополнять.

С чего начать завтра

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

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