# Как проверять качество ответов модели, а не верить на слово

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

Published: 2026-02-10 · Source: https://subxcat.com/ru/articles/llm-evals · Author: SUBXCAT

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

Evals — это и есть тесты для функций с моделью. Звучит громко, а начинается с таблицы на тридцать строк.

## Собери маленький набор

Не нужно тысяч примеров. Для начала хватит двадцати–пятидесяти на функцию, если они правильно подобраны:

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

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

Для каждого примера запиши вход и то, каким должен быть хороший ответ. Не обязательно эталонный текст — чаще достаточно критериев.

```
вход: "верните деньги за заказ 4812, пришёл не тот размер"
ожидание: категория = возврат; номер заказа = 4812; тон вежливый; без обещания сроков
```

## Как оценивать

Есть три способа, и их удобно сочетать.

**Проверки кодом.** Всё, что можно проверить программно, проверяй программно: ответ — валидный JSON, нужное поле заполнено, длина в пределах, нет запрещённых слов, номер заказа совпадает с тем, что во входе. Это быстро, бесплатно и без споров.

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

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

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

## Прогон перед каждой правкой

Главное правило: любое изменение промпта, модели, параметров или того, что подкладывается в контекст, проходит через набор до выкатки. Сравниваешь не «стало ли хорошо», а «что изменилось относительно прошлого прогона»: какие примеры начали проходить, какие перестали.

Если перестал проходить хоть один пример из «известных провалов» — это повод остановиться, даже если в среднем стало лучше.

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

## Про случайность

Модель на один и тот же вход может отвечать по-разному. Поэтому:

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

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

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

## Итог

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

SUBXCAT может собрать проверочный набор для твоих функций с ИИ и встроить прогон в процесс выкатки.