От настройки промптов до циклов обратной связи: DSPy, GEPA и Claude Code

В течение многих лет стандартным решением проблем с низким качеством результатов работы слабых LLM было простое: скорректировать запрос и попробовать снова. Однако в системах с агентами проблема часто заключается не в самом запросе.

Представьте себе ошибку в производственной среде, которая появляется только после изменения конфигурации. Передайте её двум разным ИИ-системам. Первая выдаёт трассировку ошибки вместе с тщательно сформулированным указанием и исправление. Вторая может открыть репозиторий, прочитать правила проекта, воспроизвести сбой, изменить код, запустить тесты, выяснить, что пошло не так, и начать всё заново.

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

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

Это та же концепция, которая лежит в основе исследований Stanford в области DSPy, MIPRO, STORM и GEPA, а также практической работы Anthropic над Claude Code и Model Context Protocol. Речь не идет об одной архитектуре; общая идея заключается в том, что инженерия искусственного интеллекта переходит от оттачивания отдельных запросов к созданию систем, которые действуют, измеряют результаты и улучшают программу, связанную с моделью.

Запрос теперь — это просто параметр

У приложений одноразового использования очень мало возможностей для настройки:

Task → Prompt → Model → Result

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

Система, созданная для производственного использования, выглядит примерно так:

 Task
  ↓
Program / Planner
  ↓
Context + Retrieval
  ↓
Tools + Environment
  ↓
Execution Trace
  ↓
Evaluator
  ↓
Retry, Repair, or Optimize
  ↓
Result

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

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

DSPy: делаем программу более явной

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

Небольшая программа на DSPy выглядит так:

import dspy

class Diagnose(dspy.Signature):
    """Identify the most likely root cause from an issue and repository evidence."""
    issue: str = dspy.InputField()
    evidence: str = dspy.InputField()
    diagnosis: str = dspy.OutputField()

program = dspy.ChainOfThought(Diagnose)

optimizer = dspy.GEPA(
    metric=score_diagnosis,
    auto="medium",
)

optimized = optimizer.compile(
    program,
    trainset=historical_incidents,
)

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

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

Без значимой метрики автоматическая оптимизация просто делает систему лучше в неверном направлении.

MIPRO: настройка множества этапов — это задача поиска

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

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

В кратком изложении:

Bootstrap useful demonstrations
          ↓
Propose task-grounded instructions
          ↓
Search instruction + demo combinations
          ↓
Evaluate the whole program

С использованием Llama-3-8B оптимизатор превзошел базовые варианты в пяти из семи многоэтапных программ, причем в лучшем случае было достигнуто улучшение точности на 13% по указанной метрике.

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

STORM: структура важнее оптимизации

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

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

По сравнению с базовым подходом, основанным на плане, в статье отмечается абсолютное улучшение организации на 25 процентных пунктов и увеличение объёма информации на 10 пунктов. В документации STORM также чётко указаны ограничения: генерируемые статьи ещё не готовы к публикации и часто требуют значительной правки.

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

GEPA: учитесь на том, что действительно произошло

Одна оценка может указать на то, что выступление было посредственным. Обычно она не позволяет понять почему. Настоящее исполнение оставляет гораздо более подробные следы:

input
  ↓
retrieval choice
  ↓
reasoning
  ↓
tool call
  ↓
tool result
  ↓
constraint failure
  ↓
final output

GEPA, сокращение от Genetic-Pareto и опубликованный в июле 2025 года, использует этот сигнал. Он собирает данные о траекториях выполнения задач, анализирует их на естественном языке, предлагает правки запросов, оценивает кандидатские решения и сохраняет границу Парето, чтобы не отбрасывать взаимодополняющие стратегии.

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

Claude Code: цикл в реальной среде

DSPy решает проблему с точки зрения оптимизации программы. Claude Code подходит к ней с точки зрения времени выполнения. Согласно описанию от Anthropic, это агент, находящийся в вашем репозитории: он берет на себя инструкции проекта, изменяет файлы, выполняет команды оболочки и наборы тестов, а также постоянно корректирует свои действия на основе полученных результатов. В их подробных материалах рассматриваются такие аспекты, как разделение работы между подагентами, выполнение задач между этапами и подключение внутренних корпоративных сервисов через MCP.

Архитектура не представляет собой «чат с умнее программистом». Она ближе к следующему описанию:

Repository + Project Rules + Task
              ↓
            Model
       ↙      ↓      ↘
     Read    Edit   Execute
       ↘      ↓      ↙
      Tests / Runtime Evidence
              ↓
         Next Decision

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

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

MCP соединяет инструменты; он не осуществляет оркестрацию

Часто MCP относят к агентам, использованию инструментов и оркестрации, как будто это одно и то же. Но это не так. Архитектура MCP — это спецификация клиент-серверной модели: приложение ИИ подключается к серверам, узнаёт, какие инструменты, ресурсы и команды они предоставляют, затем вызывает их одинаковым образом. Хост координирует клиенты и отвечает за разрешения, управление контекстом, политику безопасности и способ подключения больших языков моделей.

Таким образом, MCP охватывает лишь один слой более крупной стек-архитектуры:

Model                  capability envelope
Program / graph         task decomposition
Context / state         what the model can see
Tools / MCP             what the system can access or do
Runtime / harness       where actions execute
Evaluator               what counts as success
Optimizer               how the program improves
Observability           why a run succeeded or failed

Нет единой платформы, которая контролировала бы всё это, и именно поэтому системный подход оказывается эффективным.

Оптимизируйте цикл устранения ошибок, а не сам запрос

Вернёмся к ошибке с самого начала. Вместо одной инструкции вида «найдите проблему и исправьте её» опишите пошаговую процедуру:

  Issue + Repository
        ↓
    Diagnosis
        ↓
      Patch
        ↓
Tests + Lint + Runtime Checks
        ↓
    Diff Review
        ↓
  Accept or Revise

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

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

Со временем прошлые случаи превращаются в набор для оценки. MIPRO может искать инструкции и примеры в модулях диагностики и ремонта. GEPA может использовать неудачные варианты решения и отзывы оценщиков для предложения более качественного текста программы. Однако оптимизация осуществляется после завершения процесса выпуска:

Production traces
      ↓
Curated evaluation set
      ↓
Offline optimizer
      ↓
Candidate program
      ↓
Held-out validation
      ↓
Controlled promotion

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

Что это означает для инженеров ИИ

Подсказки не стали нерелевантными. У вас просто появилось больше полезных возможностей для вмешательства. Когда рабочий процесс работает недостаточно хорошо, не начинайте сразу с формулировок подсказок. Сначала выясните, в каком слое возникла проблема:

• Сможет ли базовая модель вообще справиться с задачей?
• Предоставила ли система поиска нужный контекст?
• Была ли задача разделена на логические части?
• Вернули ли инструменты надёжные доказательства?
• Было ли выполнение изолированным и доступным для наблюдения?
• Оценивает ли оценщик те показатели, которые действительно важны?
• Улучшает ли оптимизатор качество на реальных данных или просто адаптируется к данным тестирования?

Анализ всей системы также выявляет компромиссы, которые часто игнорируются в хайпе. Обертывание слабой модели в граф не превращает её в передовую модель. Плохая метрика способствует оптимизации нежелательного поведения. Чем больше инструментов, тем больше возможностей для сбоев и тем больше уязвимостей. Каждая операция оптимизации потребляет токены и время обработки. Самое худшее — агент, который сам себя изменяет, не имея истории версий и неприкосновенных тестовых случаев, может стать более нестабильным, хотя на бумаге кажется более автономным.

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

Вот настоящая связь между исследованиями в Стэнфорде и инструментарием Anthropic. Благодаря DSPy программа больше не скрывается внутри строк-промптов. MIPRO позволяет искать инструкции и примеры на разных этапах. STORM напоминает о том, что форма рабочего процесса имеет первостепенное значение. GEPA анализирует полные трассы выполнения для поиска улучшений. Claude Code помещает модель в рамки рабочей инженерной среды, а стандарт MCP унифицирует один из границ с внешними возможностями. Разные проекты на разных уровнях, все они указывают в одном направлении.

В следующий раз, когда система ИИ сработает некорректно, вопрос «Какой промпт стоит попробовать дальше?» не должен быть единственным. Спросите, какая часть системы вышла из строя, и какие доказательства помогут вам её исправить.