
Ещё пару лет назад промпт-инжиниринг выглядел как подбор удачного заклинания: "а давай добавим think step by step, "а давай попросим быть аккуратнее" и о приправим xml-тегами".
Сегодня это типовая задача оптимизации в условиях чёрного ящика.
Уже 2026 год и современные LLM одновременно:
чувствительны к формулировкам;
дороги по токенам;
нестабильны между версиями;
плохо прощают ручную настройку на глазок.
Промпт -> это не текст, а параметр модели, и оптимизировать его нужно алгоритмически, а не интуитивно.
Ниже — краткий обзор основных подходов. Как они формализуются, где про них почитать и почему на них стоит обратить внимание.

1. Как вообще формализуется оптимизация промптов
Все подходы сводятся к поиску аргумента, максимизирующего функцию в дискретном пространстве:
Где f — это не только точность (accuracy), но и стоимость, формат (JSON compliance) и латентность.
Главные инженерные барьеры:
Отсутствие градиентов: Мы не можем сделать
loss.backward(), так как API — это чёрный ящик.Смерть лог-вероятностей (Logprobs): Большинство современных API (OpenAI, Anthropic) либо скрывают лог-пробы, либо делают их бесполезными для сложных рассуждений. Это убило методы типа AutoPrompt.
Комбинаторный взрыв: Пространство вариантов текста бесконечно.
Решения делятся на три класса: эволюционные, программные и генеративно-эвристические, .
2. Эволюционные методы

MetaPrompt и TextGrad
Подход, основанный на "текстовых градиентах. https://github.com/zou-group/textgrad
Раз мы не имеем доступа к весам, мы используем критику LLM как градиент.
Forward Pass (ответ) -> Loss (оценка судьи) -> Backward Pass (текстовая критика) -> Update (правка промпта).MetaPrompt: Реализует цикл
Generate -> Critique -> Refine. Отлично подходит для исправления проблем с JSON-схемами или стилем.
HRPO — Hierarchical Reflective Prompt Optimizer
Оптимизация серого ящика с анализом корневых причин. Вместо исправления каждой ошибки отдельно, HRPO кластеризует ошибки (например, «модель путает даты в 30% случаев») и вносит системные правки в промпт. Это снижает дрейф промпта.. https://arxiv.org/abs/2305.17126
Как работает:
Батчевый прогон;
Сбор неудач;
Кластеризация ошибок;
Точечные мутации.
Исправляется класс ошибок и файндинги, а не отдельный кейс.

GEPA: Эволюция с Парето-фронтиром
Генетические алгоритмы, адаптированные для текста.
-
Как работает:
Рефлексивная мутация: Вместо случайной замены слов, LLM анализирует почему предыдущий промпт ошибся (анализ трейсов) и предлагает осмысленное исправление;
Парето-оптимизация: GEPA ищет не один «лучший» промпт, а набор (фронтир). Например: один промпт дает 95% точности, но длинный и дорогой; второй — 93%, но дешевый и быстрый. Оба сохраняются в популяции.
Результат: Превосходит RL-методы, требуя в 35 раз меньше вызовов API.
Ссылки на почитать: Paper (GEPA) | Opik Docs
2. Программные

DSPy — программирование вместо текста
Это смена парадигмы. Ты больше не пишешь промпты. Ты описываешь:
сигнатуры;
модули;
ограничения;
связи между шагами.
DSPy сам компилирует это в оптимальные инструкции. https://arxiv.org/abs/2310.03714, https://github.com/stanfordnlp/dspy. Кстати неплохо разбрано тут https://habr.com/ru/articles/882864/.
Вместо "“Answer the question carefully”
Retrieve → Reason → Answerconstraint: output_schema
Используются MIPRO и MIPROv2 (https://dspy.ai/api/optimizers/MIPROv2/):
байесовская оптимизация;
совместная оптимизация всей цепочки;
учёт стоимости токенов.
По сути это компилятор для LLM-программ. Вместе с Opik выходит 9.5 из 10.
Нюанс
Кстати, без граунд тру датасета и метрик с ивалами DSPy превращается в извращенный способ писать промпты. Помните это. Иначе не лучше GigaChat.
APE — Automatic Prompt Engineer
Старая, но попрежнему используемая штука. LLM сама генерирует инструкции, сама же их прогоняет и сама выбирает лучшие. https://arxiv.org/abs/2211.01910
Максимизация лог-правдоподобия правильных ответов:
max_p E_{(x,y)} logP(y | x, p)
Как работает:
Генерируется N кандидатов инструкций;
Они прогоняются по датасету;
Считается метрика;
Лучшие идут в следующий раунд
Обычный search + evaluation loop, только вместо параметров текст. Где APE хорош:
классификация,
извлечение информации,
задачи с чёткой автоматической метрикой.
Где ломается:
высокая дисперсия,
быстрый оверфит,
плохой перенос между доменами.
3. Генеративно-эвристические

OPRO — Optimization by PROmpting
Здесь начинается инженерная магия. Мы не оптимизируем промпт напрямую. Мы даём модели историю прошлых попыток:
[prompt₁ → score₁, prompt₂ → score₂, prompt₃ → score₃]
и просим предложить следующий, который будет лучше. https://arxiv.org/abs/2309.03409
Фактически in-context learning используется как оптимизатор.
Почему это работает:
LLM хорошо улавливают тренды;
умеют экстраполировать улучшения;
не требуют доступа к логпробам.
Топвая инструкция в свое время
“Take a deep breath and work on this problem step by step”
была найдена именно через OPRO и стабильно обгоняла классический CoT.
Минусы будут:
нестабильность;
высокая стоимость;
нужен жёсткий контроль за репрезентативность.
Где применять
reasoning-задачи;
математика и логика;
когда нет доступа к модели.
4. Самообучающиеся промпты (простенькое)
STaR, ReST
Просто оставлю ссылки, привожу для кругозора, они не работают почти. STaR: https://arxiv.org/abs/2203.14465. ReST: https://arxiv.org/abs/2304.06263
5. Сравнительный обзор
Метод |
Датасет |
Метрика |
Стоимость |
Стабильность |
Продакшен |
Когда применять |
|---|---|---|---|---|---|---|
APE |
Да |
Да |
Средняя |
Низкая |
Ограниченная |
Простые задачи |
OPRO |
Да |
Да |
Высокая |
Низкая |
Низкая |
Reasoning |
DSPy |
Да |
Да |
Средняя |
Высокая |
Высокая |
RAG, агенты |
MetaPrompt |
Нет |
Нет |
Низкая |
Средняя |
Средняя |
Быстрый буст |
HRPO |
Да |
Желательно |
Средняя |
Очень высокая |
Высокая |
Продакшен |
GEPA |
Да |
Да |
Очень высокая |
Средняя |
Низкая |
Offline |
STaR / ReST |
Да |
Да |
Высокая |
Высокая |
Средняя |
Свои модели |
6. Рецепт как выстрелить себе в ногу

Оптимизация без валидации: Самая частая ошибка. Промпт-оптимизаторы (особенно OPRO и APE) находят "хаки" — формулировки, которые работают на тестовом датасете, но ломаются на реальных данных. Всегда имейте отложенную выборку и граунд тру датасет;
Дрейф моделей: Промпт, идеально вылизанный под
gpt-4-o, может деградировать наgpt-5.1. Оптимизированные промпты хрупкие. Делайте аля CI/CD для промптов. При смене версии модели запускайте перекомпиляцию/хот реалоад проекта и проверяйте;Гниение контекста : В длинных контекстах (например, Gemini 2.5 Pro) оптимизированные инструкции могут теряться. Использовать техники типа цепочек и оптимизировать звенья цепи отдельно помогает лишь частично на данный момент.
7. Почему открыть Google AI Studio и попросить улучшить промпт не работает
Да потому что это не оптимизация, а перефразирование.
В таком режиме LLM:
не видит метрики;
не знает, что считать успехом;
не видит распределения ошибок;
не платит за токены!!!!
Она оптимизирует правдоподобие текста, а не качество решения.
Без цикла Generate → Evaluate → Compare → Select улучшения не существует.
Именно поэтому такие промпты:
хуже обобщаются;
ломаются при смене модели;
дороже в продакшене;
нравятся авторам телеграм каналов про ИИ.
8. Главная мысль

Переход совершён. Если вы пишете промпты руками в 2026 году — вы занимаетесь кустарным производством в эпоху конвейеров. Используйте готовые фреймворки (DSPy, TextGrad), настраивайте пайплайны оценки и перестаньте гадать на кофейной гуще.
Если делаете ИИ-шку, ну поставьте вы себе prompt-base любой и observability. Есть куча связок вроде Agenta + LLM Studio + Langfuse\Opik.
rsashka
Вы всегда будете гадать на кофейной гуще, если не можете обеспечить повторяемость.
Renewal_Studio Автор
А так ли уж она необходима?
rsashka
Если вас устраивает пляски с бубном без возможности воспроизвести полученный ранее результат (например, заказчик оплачивает время), то можно и без нее.
Renewal_Studio Автор
Во многих случаях вполне достаточно некоторого набора энтропии, средства для этого уже есть
flancer
Повторяемость чего? На каком уровне? С какими допусками?
Я уверен, что и сказки, и былины изустно передавали без повторяемости и с повторяемостью одновременно. Форма подачи менялась быстрее, передаваемый смысл - медленнее.
Повторяемость - не самоцель. Вы свою публикацию "Главная проблема использования ИИ (Иллюзии Интеллекта) при разработке ПО" могли написать другими словами. Более того, вы её точно напИшите другими словами, если попробуете изложить те же мысли ещё раз.
Если говорить за повторяемость результата, то для передачи одних и тех же идей разным людям вообще, иногда, нужно использовать разные формы (слова) - например, объяснить "как пройти в библиотеку" русскому, англичанину и французу.
Абсолютная повторяемость переоценена.
Terranz
Бро, мы тут генерируем код, если он меняется при одинаковом промте, о чем мы вообще рассуждаем?
flancer
О назначении этого кода, бро. О задачах, которые он должен выполнять.
Нам не нужен одинаковый код, нам нужен одинаковый результат работы этого кода.
Вам же всё равно, как называются переменные в коде? Особенно, если вам его ни дебажить не надо, ни даже читать. Более того, вам всё равно какие алгоритмы используются внутри, если результат работы кода вас устраивает. Вам нужна повторяемость не на уровне кода, а на уровне результата.
Если промпт даёт повторяемость на уровне результата - то вот и вот.
А если нам результат работы кода нужен вообще один раз? Параметризированный промпт, который создаёт одноразовые программы. Возможно даже на разных ЯП.
k4ir05
А как проверить что результат работы не изменился при изменении кода?
flancer
Запустить тесты? Я угадал?
k4ir05
Верно. Но кто их будет писать? И что-то мне подсказывает, что писать их придётся, в таком случае, не меньше, чем пришлось бы написать кода. Ведь придётся проверять все сценарии.
flancer
А если вы сами пишите код, то вы его сразу пишите правильно и без ошибок? Или тоже пишете сценарии его проверки? Своего собственного кода?
Ну так вот, в случае кодогенерации через промпты вам нужно сделать только половину работы - написать тесты. Причём не на все сценарии, а лишь на важные конкретно для этого результата. Впрочем, 100% code coverage уже давно не в моде, насколько мне известно. IMHO, profit.
Renewal_Studio Автор
Да, писать хорошие тесты сложно. Но в эпоху дипкода мы можем использовать синтетику. Мощные модели помогают генерировать тысячи граничных сценариев для проверки более слабых или быстрых моделей. Это не подгонка, а создание обучающего и валидационного контура, который гарантирует, что система не развалится при первом же обновлении API провайдером. Ну а если развалится, быстро можно затектить. Хотя пока что учитывая что эвалы не шибко развиты это отчасти вилами по воде
flancer
Если совместить опыт Magento, GitHub/JIRA-тикеты и кодогенерацию, то, в пределе, LLM-агенты могут в автомате (!) обновлять кодовую базу на проде по тикетам конечных пользователей.
Меня тут сейчас начнут пинать ногами за такие слова. Но это просто от недостатка воображения. Это действительно можно. Уже сейчас. Без всякого AGI :)
rsashka
Да чего уж мелочиться. Путь огни сами и тикеты создают. Тогда им и пользователи вообще будут не нужны :-)
flancer
Я уверен, что где-то примерно так ПО уже сейчас и разрабатывают. Одни агенты пишут код, а другие его тестируют и пишут тикеты, которые первые разбирают и фиксят.
Это уже реальность. Где-то краем глаза видел про такой подход. Не запомнил, где именно. Я пока что считаю, что участие человека в контуре принятия решений (оценки результата) обязательным. Хотя бы при постановке задачи. Но лучше - при оценке результата (обучение, самое, что ни на есть) и ещё лучше - не в одно лицо, а массово ("судом присяжных"), а ещё лучше - если "все эти люди" заинтересованы в результатах правильной работы кода, который они оценивают.
Да, в такой "карусели" программисты действительно становятся не очень сильно нужными.
Renewal_Studio Автор
Могу сказать что в яндекс внутреннем поиске так делают, так делают у меня в студии друга, майкрософте, дойче телекоме, в страйпе, это где проверенная информация
k4ir05
Конечно можно, вопрос только в качестве результата. Чем больше работы вы спихиваете на неразумный генератор текста, тем качество.
Renewal_Studio Автор
А почему генератор должен быть разумным?)
k4ir05
Потому, что на него перекладывается работа, требующая разума.
Renewal_Studio Автор
Программисты иногда тоже интересное выдают
k4ir05
Смысл автоматизации ведь в избавлении от недостатков и повышении качества. А так получается замена шила на мыло.
Renewal_Studio Автор
Ну не скажите. Многие вещи можно проверять куда быстрее. Опять таки переносить много рутины, вроде вынести в микросервис на фастапи кусок функционала, а потом когда убедиться что бизнес-логика ок и данные не теряются переписать на более эффективный стек, вроде гошки милое дело
k4ir05
А, так вам просто не нравится писать на питоне, понимаю )
Renewal_Studio Автор
Но опять таки, как мы ушли в сторону ИИ кодинга. если статья больше про способы машинного улучшения промптов для всяких тулов, например для gen агентов картинов или text2sql
Renewal_Studio Автор
Я больше скажу. Берешь claude code + mcp + linear (нафиг vibe kanban и тп тулы) и это уже работает
Renewal_Studio Автор
А чего пинать, часть ребят уже на это переходят, могу сказать что в яндексе начали активно пересаживаться на гибридную работу люди + агенты