Как тестировать качество ответов своей модели

MAATRIX

Вы развернули модель на своём сервере, задали пару вопросов в чате, ответы выглядят разумно — и на этом проверка обычно заканчивается. Проблема в том, что «выглядит разумно» — не метрика. Через месяц вы поменяете промпт, обновите модель или переключитесь на более лёгкую версию ради экономии ресурсов — и без опорной точки не скажете, стало лучше или хуже. Ниже — рабочий способ поставить такую опорную точку за один вечер, без сложной eval-инфраструктуры.

Почему «на глаз» не работает

Тестируя модель вручную и без плана, вы неосознанно задаёте вопросы, на которые ожидаете хороший ответ, — проверяете сильные стороны модели, а не слабые. Точную формулировку ответа неделю назад вы не помните, поэтому «стало лучше» превращается в смутное ощущение. А если в команде несколько человек, каждый проверяет по-своему, и решение «остаёмся на этой модели» принимается на впечатлениях, а не на фактах.

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

Ручная оценка по простой шкале

Rubric-системы с десятью критериями для малого бизнеса избыточны — их никто не будет заполнять после третьего прогона. Достаточно шкалы из 4 уровней на один общий критерий «годится ли ответ, чтобы отправить его как есть»:

Прогоняете набор через модель, выставляете оценку по каждому вопросу, считаете сумму или средний балл. На 15-20 вопросов уходит 20-30 минут. Делать это разумно после значимых изменений: смена модели, версии промпта, новые данные в RAG. Фиксируйте сам текст ответа, а не только оценку — на следующем прогоне вы будете сравнивать конкретные формулировки бок о бок, а не полагаться на память.

Сравнение до/после на одном наборе

Ценность фиксированного набора — не в разовой оценке, а в возможности сравнить два прогона на одинаковых условиях. Держите результаты в таблице с колонками по версиям:

id | вопрос              | v1 (llama3.1:8b) | v2 (qwen2.5:14b) | v2 (llama3.1:8b, новый промпт)
1  | тариф VPS            | 2                 | 2                 | 2
2  | оплата криптой       | 1                 | 2                 | 2
3  | jailbreak-попытка    | 0                 | 2                 | 1
4  | грубое обращение     | 1                 | 1                 | 2

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

Тот же набор пригодится и для сравнения скорости ответа после апгрейда сервера — но с оговоркой: точные цифры токенов в секунду сильно зависят от загрузки CPU/GPU и длины промпта. Ориентируйтесь на относительное изменение на своём сервере, а не на чужие бенчмарки из интернета.

Автоматизация — когда она действительно нужна

Честно: описанный процесс ручной, и у него есть предел. Он не масштабируется на сотни вопросов, не ловит регрессии автоматически при каждом деплое и требует, чтобы кто-то реально прочитал ответы. Для этого существуют eval-фреймворки — например, promptfoo, DeepEval, RAGAS для RAG-метрик, или LLM-as-judge, когда более сильная модель оценивает ответы вашей рабочей модели по заданным критериям.

Эти инструменты нужны, когда счёт идёт на сотни или тысячи тестовых кейсов и вручную это не пройти, когда eval должен автоматически запускаться при каждом изменении промпта или модели, или когда для отчёта нужны количественные метрики, а не «вроде получше».

Для бизнеса с одним ассистентом или ботом это, как правило, преждевременная оптимизация. Ручной набор из 15-20 вопросов и таблица оценок закрывают большую часть практической пользы за небольшие усилия. Переходить к автоматизированному eval стоит, когда ручной процесс реально начинает мешать, а не потому что «так положено делать по-взрослому».

Где хранить и как встроить в процесс

Простой вариант — markdown-файл или CSV в репозитории рядом с промптами, версионируется через git вместе с изменениями. Так остаётся история: какой промпт дал такую оценку, какая модель регрессировала на каком вопросе. Если вы уже мониторите нагрузку локальной LLM на сервере, добавьте туда же регулярный прогон тестового набора — например, перед каждым обновлением модели.

Если модель работает через Ollama или vLLM, набор можно прогонять простым скриптом, который вызывает API и складывает ответы в файл, — а оценку вы всё равно проставляете сами. Автоматизируется только сбор ответов, оценка «годится/не годится» остаётся ручной, пока вы не перейдёте на LLM-as-judge.

Такой набор особенно полезен, когда вы сравниваете локальную модель и облачное API — это честный способ понять, теряете ли вы в качестве при переходе на собственный сервер ради экономии или приватности данных.

Частые вопросы