Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Исследователи AWS Agentic AI предложили ESPO — метод автоматической оптимизации инструкций, описанный в препринте, который не проходил рецензирования. По замерам авторов, итоговые инструкции получились на 47% короче, чем у GEPA. Работа важна командам, которые управляют поведением LLM через системные инструкции и уже сталкиваются с накоплением частных правил.
Что сделали
ESPO заменяет последовательное исправление отдельных неудачных ответов на три раздельных этапа: диагностику, подготовку кандидатов и отбор. Авторы рассматривают разрастание инструкции как следствие процесса, в котором оптимизатор видит лишь часть ошибок, изменяет текст одним способом и выбирает результат по нестабильной оценке на небольшой проверочной выборке.
На этапе диагностики система запускает текущую инструкцию на обучающих примерах, собирает все ошибки и с помощью отдельной LLM группирует их по структурным причинам. В оптимизацию передаются не отдельные неудачные ответы, а описания повторяющихся проблем: например, неверное понимание формата результата или правило, которое срабатывает слишком широко.
Затем ESPO применяет четыре стратегии подготовки кандидатов. Диагностическое исправление меняет инструкцию с учётом найденных причин ошибок. Консолидация объединяет повторяющиеся требования, не увеличивая длину текста. Абляция удаляет или смягчает правила, создающие ложные срабатывания. Добавление фактов переносит в инструкцию предметные сведения, обнаруженные при анализе примеров. После этого система может объединять удачные части разных вариантов и дорабатывать их по оставшимся ошибкам.
Финальный вариант выбирается через бутстрэп-отбор: проверочная выборка многократно пересобирается случайным выбором примеров с возвращением, а кандидаты оцениваются на каждой такой версии. Побеждает инструкция, которая чаще остальных занимает первое место; при равенстве предпочтение получает более короткая. Такой подход должен снизить вероятность выбора варианта, случайно показавшего лучший результат на одной небольшой выборке.
Что показали
В основном эксперименте средний результат ESPO составил 74,67% против 70,91% у GEPA. ESPO сравнялась с GEPA или превзошла её на каждом использованном наборе данных. Авторы также измерили меньшую задержку при выполнении запросов, что согласуется с сокращением текста инструкции, однако конкретный выигрыш зависит от задачи.
Перенос между моделями оказался неоднородным, но средний результат ESPO был лучшим на всех проверенных авторами моделях. Самая заметная разница возникла на Qwen3 в GSM8K: 91,4% у ESPO против 35,4% у GEPA. Авторы связывают её с тем, что диагностика обнаружила несоответствие требуемого формата ответа, которое последовательное добавление правил исправило лишь частично.
Разбор компонентов поддерживает выбранную архитектуру процесса, но не показывает, что простое увеличение числа кандидатов полезно само по себе. Разнообразие без устойчивого отбора ухудшило результат. Теоретическая граница в работе объясняет предполагаемую роль каждого этапа, однако сами авторы называют её пояснительной конструкцией, а не строгой гарантией качества для конкретного набора данных.
Ограничения
Эксперименты охватывают семь открытых наборов данных для классификации, математики, логического вывода, проверки фактов и генерации ответов с учётом приватности. Для каждой задачи использовали 70 обучающих, 30 проверочных и 500 тестовых примеров. Такой масштаб показывает поведение метода в контролируемом испытании, но не его устойчивость на непрерывном потоке производственных данных.
Основное сравнение начинается с намеренно слабых инструкций, выбранных по низкому результату. Поэтому работа лучше отвечает на вопрос о восстановлении плохой исходной настройки, чем о доработке уже зрелой системы. Сводный показатель также объединяет разные метрики задач, включая точность, точное совпадение и семантическую F1-меру, из-за чего его нельзя трактовать как единую продуктовую метрику.
Для анализа ошибок и генерации кандидатов применялась одна модель — Claude Sonnet 4.5. Авторы не проверяли смешивание разных моделей на этом этапе, а предполагаемая независимость стратегий в теоретическом объяснении соблюдается не полностью. За рамками экспериментов остались работа с инструментами, программный код, длинный контекст и многоходовые диалоги. Основные таблицы опираются на отдельные запуски с дополнительной оценкой разброса, поэтому небольшие различия между методами сами авторы предлагают считать сопоставимыми.
Что это значит
Работа не требует менять выбранную LLM или прикладную архитектуру, но предлагает пересмотреть сам цикл оптимизации. Если система сейчас исправляет каждый новый сбой добавлением очередного запрета или исключения, полезнее сначала собрать ошибки в устойчивые категории, затем подготовить варианты с разными типами изменений и только после этого выбирать победителя на нескольких пересборках проверочных данных.
Для производственной команды ESPO пока стоит рассматривать как схему собственного эксперимента, а не как готовое доказательство превосходства. Проверка должна проводиться на реальном распределении запросов и учитывать одновременно качество, длину инструкции, задержку и стоимость оптимизации. Авторы оценивают полный запуск ESPO примерно на уровне GEPA по вычислительным затратам, поэтому сокращение инструкции не означает автоматического удешевления всего процесса.
Планы меняются прежде всего у команд, уже инвестирующих в автоматическую оптимизацию инструкций: им имеет смысл добавить отдельную диагностику и устойчивый отбор до дальнейшего наращивания правил. Для продуктов с инструментами, длинными диалогами или кодом выводов работы недостаточно — сначала потребуется воспроизвести метод на собственных сценариях.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
