Почему одного удачного ответа недостаточно

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

Promptfoo — открытый инструмент для таких проверок. Его документация описывает тестовые наборы с переменными и утверждениями, сравнение нескольких провайдеров, просмотр результатов и подключение локальных моделей через Ollama или совместимый с OpenAI интерфейс vLLM. На официальном скриншоте видна матрица: строки — запросы, столбцы — варианты модели или промпта, в ячейках — ответы и результат проверки. Это пример интерфейса продукта, а не результат нашего теста и не доказательство качества конкретной модели.

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

Что именно проверять

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

Набор из 40–80 случаев для первого пилота часто полезнее тысячи синтетических вопросов без разметки. Соберите его из обезличенных реальных обращений и ошибок прошлых проверок. Покройте четыре группы:

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

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

NIST AI Risk Management Framework рекомендует измерять качество в контексте конкретного применения и документировать различия между испытаниями и рабочей средой. Поэтому не подменяйте рабочие обращения общим публичным бенчмарком: он не знает ваших справочников, доступа к документам и стоимости неправильного решения.

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

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

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

Документация Promptfoo позволяет задать проверки вроде точного совпадения, регулярного выражения, структурного формата и оценки моделью. Отдельные тесты можно хранить в локальных CSV, JSON, JSONL или YAML. Результаты можно вывести в JSON и HTML для разбора ошибок. Для малого пилота достаточно одного версионируемого файла случаев и отчёта; сложную платформу управления экспериментами покупать не требуется.

Метрика «прошёл тест» должна иметь знаменатель. Если критических случаев десять, один неверный ответ — уже 10% провала этой группы, даже если общий процент по лёгким вопросам красивый. Разделяйте долю правильных ответов, безопасных отказов, неверных уверенных ответов, время ответа и цену одного принятого результата. Сравнение вариантов должно учитывать и дополнительное время человека на исправления.

Где остаются данные и почему это надо проверить

Локальный запуск утилиты не означает, что всё испытание замкнуто внутри компании. Запросы уходят к тому провайдеру модели, который вы указали в конфигурации. Если для оценки ответа применяется модель-судья, у неё тоже есть отдельный провайдер; документация Promptfoo описывает внешние настройки по умолчанию и способ явно выбрать оценщик. Подключите нужный локальный endpoint для каждого пути — генерации, оценки и векторных проверок — либо на первом этапе ограничьтесь детерминированными правилами и ручной оценкой.

У Promptfoo также есть служебная телеметрия использования, которую можно отключить документированной настройкой. По описанию проекта, она не включает тексты промптов и ответов, но вопрос передачи метаданных всё равно должен решаться политикой компании. Не включайте публикацию или общий доступ к отчётам с рабочими данными. Отчёты и экспорт могут содержать запросы, переменные, ответы модели и конфигурацию; храните их как внутренние документы, задайте срок хранения и удаляйте персональные данные ещё до теста.

Для локальной модели нужны не только веса и GPU. Нужен стабильный endpoint, версия модели, ограничение параллельности и замеры задержки под реальной нагрузкой. Проверка на ноутбуке одним запросом не показывает, как система поведёт себя при очереди из рабочих обращений. Если часть проверок требует сетевого доступа или модели-судьи, добавьте её вычисления и передачу данных в архитектуру и бюджет.

Во сколько обходится проверка

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

Пример расчёта только для планирования: 60 проверочных случаев, два варианта модели и два варианта промпта дают 240 генераций на полный прогон. Если предметный специалист тратит по две минуты на ручную проверку каждого уникального ответа, это до восьми часов до учёта подготовки и разбора спорных случаев. Автоматические правила сокращают просмотр очевидных ошибок, но не отменяют проверку критических ответов. Это модельное допущение, не измерение Promptfoo и не универсальная норма трудозатрат.

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

Практический следующий шаг

Назначьте владельца процесса и соберите 40–80 обезличенных случаев из работы за последние недели. Разметьте правильный результат и критические запреты; зафиксируйте версии документов. Сравните два варианта на одном наборе, затем отдельно просмотрите все провалы и случайную выборку «успехов». После исправлений повторите прогон на отложенной части случаев, которая не использовалась для настройки инструкции.

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

Изображение: официальный скриншот Promptfoo, © Promptfoo 2025; исходный файл и условия MIT License приведены в источниках. Для квадратной обложки использован кроп без дорисовки.