Как тестировать нейросеть: выборка вместо ощущений

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

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

Причина техническая и не зависит от вашей аккуратности.

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

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

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

Как собрать выборку

Пять правил, каждое из которых кто-то нарушал и терял на этом время.

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

Включите трудные случаи. Не только типичные, а именно те, на которых уже были жалобы. Выборка из одних лёгких запросов показывает 98% и ничего не значит.

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

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

Храните её в репозитории. Выборка — такой же артефакт проекта, как код и промпт.

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

Что считать метрикой

Зависит от типа задачи, и подмена одного другим — частая ошибка.

Есть единственно верный ответ (классификация, извлечение полей, да/нет): доля совпадений. Простая, честная, считается программно — как это устроено на классификации.

Ответ проверяется по правилам (формат, обязательные поля, запрещённые слова): доля ответов, прошедших все проверки. Тоже программно.

Ответ оценивается качественно (текст, перевод, объяснение): число правок до готового состояния. Эта метрика лучше оценок «хорошо/плохо», потому что переводится в рабочее время.

Есть побочные требования (длина, стоимость, задержка): считайте их отдельной колонкой. Модель, дающая на два процента лучше при вдвое большей цене, — не улучшение.

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

Можно ли поручить оценку модели

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

Работает это частично и с оговорками.

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

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

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

И отдельно: не берите в судьи ту же модель, которую тестируете. Свои ответы она оценивает мягче.

Что тестировать при каждом изменении

Четыре типа изменений, после которых прогон обязателен.

Правка промпта. Даже маленькая. Особенно если добавили правило под конкретную жалобу: такие правки часто чинят один случай и ломают три.

Смена модели. Промпт, отлаженный под одну позицию, на другой работает иначе. Каталог обновляется часто: на 3 сентября 2026 года в нём 46 позиций в двенадцати семействах — как сравнивать.

Изменение параметров генерации. Один параметр за раз — что они меняют.

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

Плюс регулярный прогон без изменений — раз в месяц. Модели на стороне провайдеров обновляются, и результат может измениться сам по себе.

Как устроен рабочий цикл

Порядок, который занимает вечер на настройку и потом экономит недели.

1. Прогон без изменений дважды. Получаете уровень шума. Всё, что меньше него, — не результат.
2. Фиксируете базовое значение. Текущая доля правильных ответов с текущим промптом и моделью.
3. Меняете одно. Промпт, параметр или модель — но не два сразу, иначе причина неизвестна.
4. Прогоняете ту же выборку. Сравниваете с базовым.
5. Смотрите не только на среднее. Где именно изменилось: улучшилось на лёгких и ухудшилось на трудных — это ухудшение, хотя среднее могло вырасти.
6. Записываете результат рядом с изменением. Через месяц вопрос «почему у нас такой промпт» должен иметь ответ.

Шестой пункт превращает набор случайных правок в историю решений — и это то, чего почти ни у кого нет.

Где выборку взять, если её нет

Практический вопрос для тех, кто начинает с нуля.

Из логов. Если вы записываете запросы, там уже лежат реальные примеры — что стоит логировать.

Из обращений в поддержку. Жалобы на неверные ответы — готовый список трудных случаев.

Из ручной работы. Если задачу сейчас делают люди, их результаты и есть эталон.

Из архива. Переводы, описания, разборы, сделанные раньше, — это пары «вход — правильный выход».

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

Прогонять выборку дешевле всего на нулевых позициях каталога: их восемь из сорока шести на 3 сентября 2026 года — что там доступно.

Чем это отличается от тестов в коде

Сравнение полезное, потому что привычки из обычной разработки сюда переносятся не полностью.

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

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

Выборка стареет. Код меняется — тесты меняются вместе с ним осознанно. Выборка же перестаёт отражать реальность незаметно: приходят новые типы запросов, а в наборе их нет. Пополнять её стоит из свежих логов раз в квартал.

Прогон стоит денег. Обычные тесты бесплатны, прогон выборки — нет. Отсюда практика: полный прогон на значимых изменениях, сокращённый набор из полусотни примеров — на мелких правках.

Что переносится без изменений: прогон обязателен перед выкаткой, результат хранится рядом с изменением, а падение метрики — повод остановиться, а не объяснить.

Чего мы не утверждаем

Не рекомендуем конкретные инструменты. Их много, и на выборке в двести примеров хватает обычного скрипта.

Не сравниваем модели. Своих замеров мы не делали; в этом и смысл: мерить надо на своих данных.

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

Что держать в голове

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

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

Как мы проверяем факты и что храним из запросов — на странице о проекте и в llms.txt. Прогнать свою выборку на нескольких моделях по одному ключу: keydealer.ru/login.