Promptfoo: как проверять ИИ-приложение на своих задачах, а не по демо

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

Что вы получаете на выходе

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

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

Первый набор без искусственных примеров

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

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

В гайде о бюджете API описаны ограничения стоимости. Для Promptfoo это особенно важно: матрица быстро множит число запросов. Двадцать заданий на три модели и два варианта промпта уже дают как минимум 120 обращений без учёта повторов. Запускайте сначала малый набор и проверяйте тарифы подключённых сервисов. То, что сам инструмент открытый, не означает бесплатность модельных вызовов.

Какие проверки можно доверить автоматике

Хорошие машинные проверки просты и проверяемы: ответ не пустой; JSON соответствует схеме; присутствует требуемое поле; нет запрещённого вывода персональных данных; цитируемый идентификатор существует в переданном наборе. Они ловят регрессии после изменения кода. Более тонкие требования — «полезно ли объяснение?» или «не искажён ли смысл закона?» — требуют человека и конкретного контекста. Судья-модель может ошибиться вместе с проверяемой моделью, особенно если оба ориентируются на гладкую формулировку.

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

Где обзорный инструмент не заменяет испытания

Матрица тестов показывает поведение на выбранной выборке. Она не проверяет права доступа в вашем приложении, корректность авторизации API или случайную утечку секретов в логах. Даже red teaming не даёт гарантии защиты от всех атак. Кроме того, данные тестов и ответы могут проходить через внешние модельные сервисы в зависимости от конфигурации. Перед передачей внутренних документов нужно проверить маршрут данных и согласовать его с политикой компании.

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

Кому подходит

Promptfoo уместен, когда ИИ-функция уже повторяет одну задачу много раз и от её ошибок зависит работа людей. Его можно использовать как лабораторный стенд для промптов, моделей и защитных проверок. Он не нужен ради красивой цифры «качество 97%» без понятных заданий. Начните с десятка живых случаев, двух вариантов, ограниченного бюджета и ручного просмотра расхождений. Такой эксперимент даст больше, чем сотни случайных атак без связи с продуктом.

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

Promptfoo сам предоставляет модель? Нет. Он запускает тесты через настроенного провайдера, приложение или локальную модель; стоимость внешних API оплачивается отдельно.

Можно ли считать процент прохождения объективным качеством? Только для вашего конкретного набора и критериев. Не переносите число на все будущие вопросы.

Заменит ли red teaming аудит безопасности? Нет. Он помогает искать часть проблем, но доступы, инфраструктуру и бизнес-логику проверяют отдельно.

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