Промпт-инжиниринг в продакшене: как тестировать изменения?
Автоматический перевод
Эта статья была автоматически переведена с оригинальной английской версии.
Определите, какие ответы считать успешными, соберите репрезентативные случаи и сравните одно изменение промпта с фиксированным базовым вариантом. Улучшайте инструкцию, примеры или предоставленный контекст в зависимости от наблюдаемой ошибки. Оставьте отдельный тестовый набор, чтобы проверить, работает ли изменение за пределами примеров, на которых его разрабатывали.
Промпт в продакшене должен обрабатывать неполные, неоднозначные и некорректные входные данные наряду с обычными запросами.
Превратите ошибки в тестовые случаи
Допустим, модель извлекает поля из счетов. Включите обычные счета, пропущенные значения, незнакомые форматы, противоречивые даты и документы, которые не являются счетами. Определите, как система должна обрабатывать каждый случай, до изменения промпта.
| Ошибка | Изменение для сравнения | Проверка |
|---|---|---|
| Отсутствует обязательное поле | Уточнить поле и добавить подходящий пример | Поле присутствует, когда источник его подтверждает |
| Значение выдумано | Задать поведение при отсутствии значения и предоставить подтверждения | Неподтверждённое поле остаётся пустым |
| Ответ не удаётся разобрать | Использовать поддерживаемую схему ответа | Парсер принимает весь ответ |
| Верное значение из неверного источника | Сохранить сведения о том, из какого источника взяты данные | Значение относится к запрошенному документу |
Вывод, ограниченный схемой, может устранить синтаксические ошибки. Документация vLLM по structured outputs описывает поддерживаемые ограничения вывода. Валидный объект JSON всё ещё может содержать неверную дату или неподтверждённое утверждение, поэтому проверяйте значения отдельно.
Сохраните возможность интерпретировать сравнение
При тестировании изменения промпта сохраняйте неизменными версию модели, настройки декодирования, исходные данные, определения инструментов и ограничения вывода. Записывайте качество, категории ошибок, количество токенов и латентность. Повторяйте недетерминированные случаи достаточно раз, чтобы увидеть, сохраняется ли улучшение.
Примеры few-shot должны охватывать реальное разнообразие, включая неполные или неоднозначные входные данные. Добавляйте их для решения проблемы, выявленной при измерениях, а не исходя из предположения, что больше примеров всегда лучше. Позиция в контексте тоже может иметь значение: авторы Lost in the Middle обнаружили, что использование подтверждающей информации зависит от её позиции в протестированных моделях и задачах.
Используйте явные этапы, когда они помогают изолировать ошибку, но учитывайте дополнительные вызовы и интерфейсы в сравнении. Обеспечивайте права доступа и другие обязательные правила приложения в коде; одно системное сообщение не может их гарантировать.
Раздел о промптах в продакшене в руководстве по инженерии LLM объясняет основные методы и их ограничения.