Итеративная разработка и отладка запросов

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

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

До написания промпта создайте эталонный набор проверок: коллекцию из 20–100 репрезентативных примеров входных данных в паре с ожидаемым выводом или критериями успешного прохождения. Этот набор станет эталоном для оценки любых изменений промпта.

Хорошие наборы проверок включают типичные входные данные, нестандартные случаи (пустые строки, очень длинные входные данные, неоднозначные случаи), враждебные входные данные, предназначенные для нарушения работы промпта, и входные данные от разных сегментов вашей аудитории. Чем разнообразнее набор проверок, тем увереннее вы можете быть, что изменение промпта действительно улучшает его работу, а не подгоняет её под несколько примеров, которые вы держали в уме.

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

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

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

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

OpenAI Playground (platform.openai.com/playground) — самый быстрый инструмент для доработки промптов без написания кода. Он позволяет переключаться между моделями, настраивать параметры с помощью ползунков, сохранять версии промптов и сравнивать вывод рядом.

Используйте Playground на этапе исследования при разработке промпта: пробуйте разные формулировки, интерактивно проверяйте нестандартные случаи и развивайте понимание того, что работает. Когда вы остановитесь на перспективном промпте, перенесите его в код и используйте инструмент оценки, чтобы систематически проверить его на всём наборе данных до выпуска.

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

Более продвинутые подходы включают хранение промптов в специализированной базе данных для управления промптами (LangSmith, PromptLayer или простой таблице Supabase), добавление меток к версиям и проведение A/B-проверок разных версий промпта в рабочей среде. Это особенно важно, когда над одними и теми же промптами работают несколько участников команды или когда нужно откатить изменение промпта, ухудшившее качество в рабочей среде.

Если у Вас есть две конкурирующие версии запроса, протестируйте обе на полном наборе тестов и сравните оценки. Даже повышение точности на 5% в рабочей системе, обрабатывающей тысячи запросов в день, стоит затраченных на оценивание усилий. Никогда не выбирайте запрос на основе одного-двух проверенных вручную примеров — всегда сравнивайте варианты на полном наборе тестов.

Для субъективных показателей качества, где нет единственного правильного ответа (например, для оценки тона, полезности или креативности), можно использовать оценивание LLM как судьёй: попросите мощную модель, например GPT-4o, оценить, какой из двух ответов лучше соответствует Вашим критериям качества. Это позволяет масштабировать оценивание за пределы возможностей человеческой проверки.

По умолчанию результаты LLM не являются детерминированными. Установка значения temperature=0 делает результаты почти детерминированными (наиболее вероятный токен на каждом шаге), что особенно важно для отладки: Вы можете дважды выполнить один и тот же запрос и получить одинаковый результат. При отладке всегда устанавливайте температуру равной 0, чтобы определить, вызвало ли изменение запроса изменение результата или это было всего лишь случайное отклонение.

После исправления запроса снова включите некоторую степень случайности в рабочей среде, если Вашему сценарию использования полезно разнообразие (творческое письмо, мозговой штурм). Однако для задач структурированного извлечения и классификации, где нужны стабильные и воспроизводимые результаты, оставляйте температуру равной 0.

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

• Указывайте источники: «Отвечайте только на основе предоставленного контекста. Если ответа нет в контексте, скажите: „Я не знаю“».
• Оценивайте степень уверенности: «Оцените свою уверенность по шкале от 1 до 5. Если оценка ниже 3, не отвечайте».
• Добавляйте этап проверки: «Перед ответом убедитесь, что каждый планируемый к использованию факт присутствует в предоставленном документе».

Ни один метод не устраняет галлюцинации полностью, но сочетание поиска (RAG) со строгими ограничениями запроса значительно сокращает их количество в приложениях, интенсивно использующих знания.

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

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

Жизненный цикл разработки запроса состоит из трёх этапов:

• Исследование: свободно экспериментируйте в Playground. Сосредоточьтесь на понимании того, что работает с концептуальной точки зрения, а не на получении идеального результата.
• Оценивание: создайте набор тестов и средство для проведения оценивания. Запускайте варианты запросов на полном наборе тестов и измеряйте долю успешных результатов. Повторяйте процесс, пока не достигнете заданного порога качества.
• Рабочая среда: добавьте финальный запрос в систему контроля версий, настройте мониторинг показателей качества в рабочей среде и оповещения об ухудшении качества. Планируйте будущие итерации при изменении версий модели.

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

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