Автоматическая оптимизация промптов: генерация и оценка вариантов

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

Автор: Ai Flowi · Опубликовано 2026-10-10

Это план эксперимента без оптимизированного промпта, качество которого подтверждено измерениями. Соответствующие компоненты AI Flowi Workflow описаны в каталоге; Ai Flowi не проверяла их в производственной среде.

Определите цель поиска до генерации промптов

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

Используйте синтетическую задачу классификации текста: отнесите запрос к refund, delivery или unclear. Refund означает явную просьбу вернуть деньги. Delivery означает явную просьбу сообщить о ходе доставки без требования возврата денег. Отсутствие обоих намерений или их сочетание означает unclear. Требуйте ровно одну метку в нижнем регистре без пояснения.

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

Разделяйте примеры для разработки и отложенной проверки

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

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

Создайте небольшую таблицу вариантов и сохраните исходный промпт

пример конфигурации, а не зафиксированный тест

С помощью Structured Output подготовьте не более двух изменённых вариантов. В input_value передайте фиксированные определения меток, неизменённый исходный промпт и пакет для разработки. В system_prompt запросите два варианта, сохраняющих задачу, с указанием каждой изменённой инструкции. Настройте schema_name=prompt_candidates, model с подключением к провайдеру и output_schema с предлагаемыми полями prompt_id, prompt_text и changed_instruction.

Объяснение Structured Output описывает требования к генерации и проверки схемы.

В этом поиске отклоняйте строку варианта, если changed_instruction описывает не то изменение, которое внесено в prompt_text. Храните B0 отдельно, чтобы генератор не мог перезаписать образец для сравнения. Строки ниже составлены как иллюстрация результата генерации вариантов; они не получены от модели.

Интерфейс форматирования описан в справке по Parser.

Добавляйте одни и те же фиксированные определения меток к инструкции каждого варианта. Для копии на проверку передайте таблицу вариантов в input_data, выберите mode="Parser" и задайте pattern так, чтобы prompt_id, prompt_text и changed_instruction оставались вместе. Убедитесь, что C1 и C2 остаются отдельными записями; объединение их инструкций создало бы третий, непроверенный вариант. Сравните копию с таблицей перед использованием любой из инструкций.

Запустите каждый проверенный вариант на одинаковых строках набора для разработки

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

1. Подготовьте таблицу для разработки с example_id и text. Храните expected_output в журнале проверки, вне входного столбца модели.
2. В Batch Run передайте эту таблицу в df, задайте column_name=text и output_column_name=observed_label. В system_message укажите один проверенный вариант вместе с фиксированными определениями; подключите настроенный LanguageModel к model.
3. Запускайте B0, C1 и C2 отдельно, меняя только инструкцию варианта. Batch Run предоставляет один system_message для всего пакета, а не экспортируемое поле выбора промпта для каждой строки.
4. Сохраняйте каждую Table из batch_results с идентификатором варианта. Подтверждайте соответствие строк, не предполагая сохранение порядка или метаданных. Соберите журнал сравнения с candidate_id, example_id, output и независимо заданным expected_output.

Интерфейс обработки строк описан в записи Batch Run в каталоге.

Для D04 вход модели должен содержать только текст запроса; включение ожидаемой метки unclear раскрывает ответ в ходе эксперимента. Настройка column_name=text исключает целевые ответы и примечания проверяющего из этого входа. Сохраняйте одну и ту же модель провайдера и доступные настройки; записывайте temperature, max_tokens и другие применимые параметры настроенного Language Model. Экспорт не определяет, какие настройки наследует Batch Run, поэтому сначала проверьте фактическое поведение.

По теме: Температура LLM и top-p: пример выбора токенов.

Рассматривайте ответы оценщика вместе с проверками точного совпадения

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

Объяснение оценки галлюцинаций LLM описывает интерфейс LangWatch Evaluator и ограничения интерпретации.

Сопоставляйте по одной строке журнала сравнения: по example_id=D04 найдите фиксированный текст запроса для input, передайте сохранённый output этого варианта без изменений и задайте expected_output=unclear из тестового примера. Храните candidate_id и example_id рядом с ответом оценщика в журнале; это учётные идентификаторы, а не дополнительные входы оценщика. Для B0, C1 и C2 используйте один и тот же проверенный evaluator_name. При ошибке оценки отмечайте строку как нерешённую, а не исключайте её из сравнения.

Гипотетическое исправление C1 на D04 нужно сравнивать с его результатами на D01-D03, а не учитывать отдельно. Если оно вызывает новую ошибку delivery на D02, запишите ухудшение рядом с исправлением обработки сочетания намерений; отклоните вариант, если D02 заранее объявлен критическим. Если оценщик одобряет ответ с пояснением после unclear, такой ответ всё равно не соответствует строгим требованиям к выводу. Согласие оценщика не отменяет нарушение формата и не разрешает менять фиксированные метки.

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

Зафиксируйте бюджет эксперимента, правило остановки и критерий отката

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

Выбирайте только вариант с меньшим числом ошибок меток на наборе для разработки, чем у B0, и без новых нарушений формата; при равенстве сохраняйте B0. Отклоняйте вариант, который создаёт ошибку в заранее объявленном критическом случае. Один раз проверьте выбранный вариант на двух отложенных строках вместе с одним запуском фиксированного исходного промпта. Это итоговое сравнение требует ещё четыре ответа по строкам. Если вариант ошибается хотя бы на одном примере отложенного набора или показывает худший результат, чем B0, сохраните исходный промпт, не возобновляя поиск на этих ответах.

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

Эти меры описывают ограниченный эксперимент, а не встроенный оптимизатор, автоматическое развёртывание или самообучающуюся модель. Для выбора демонстрационных примеров используйте промпты с несколькими примерами. Считайте фактически выполненные узлы и проверяйте записи использования; бюджет ответов по строкам не является измеренным расходом Flowi Tokens.

Когда поиск промптов не подходит?

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

Тарифы: Go от USD8 в месяц при годовой оплате (USD10 помесячно), Plus от USD16 (USD20 помесячно), Pro 100 от USD80 (USD100 помесячно), Pro 200 от USD160 (USD200 помесячно) и Pro 500 от USD400 (USD500 помесячно), от 5,000 до 250,000 Flowi Tokens в месяц с возможностью пополнения; 1 токен за каждый запуск узла; использование сторонних API и моделей не включено.