Від корекції запитів до циклів зворотного зв’язку: DSPy, GEPA та Claude Code

Протягом багатьох років стандартним рішенням проблеми слабких результатів ШІ було просте: скоригувати запит та спробувати знову. У системах з агентами запит часто не є тим елементом, який потребує корекції.

Уявіть собі баг у продакшні, який з’являється лише після зміни конфігурації. Передайте його двом різним системам штучного інтелекту. Перша отримує трек стеку та ретельно сформульовану інструкцію та повертає патч. Друга може відкрити репозиторій, прочитати правила проекту, відтворити проблему, змінити код, запустити тести, з’ясувати, що зламалося, та почати все знову.

У обох випадках важлива роль моделі. Те, що є у другій системі, а немає у першій, — це виконуваний цикл зворотного зв’язку.

Як тільки такий цикл існує, формулювання запиту стає лише одним із багатьох параметрів. Ви також можете налаштовувати спосіб розділення завдання, те, що буде отримано, які інструменти доступні, приклади, процедуру перевірки, правила повторної спроби, умови виконання в ізольованому середовищі та механізм оцінки, який визначає, чи є результат справді правильним.

Це та сама ідея, яка простягається від досліджень 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 було припинити розглядати підхід LM як набір ручно налаштованих рядків запитів. У оригінальній статті застосування LM моделюються як обчислювальні графи декларативних модулів, а також додається компілятор, який оптимізує ці модулі з урахуванням певної метрики. У поточній документації це сформульовано простіше: необхідно визначити структуровані сигнатури та модулі, надати приклади та функцію оцінки, а потім скомпілювати програму замість того, щоб ручно налаштовувати кожен запит.

Невелика програма 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 — це специфікація клієнт-сервер: додаток на основі ШІ під’єднується до серверів, дізнається, які інструменти, ресурси та команди вони надають, а потім використовує їх у єдиному форматі. Хост координує клієнтів та несе відповідальність за дозволи, керування контекстом, політику безпеки та спосіб підключення LLM.

Отже, 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 уніфікує один із кордонів з зовнішніми можливостями. Різні проекти на різних рівнях, усі вони спрямовані в одному напрямку.

Наступного разу, коли система ШІ зазнає невдачі, питання „Який запит я маю спробувати далі?“ не повинно бути єдиним. Слід запитати, яка частина системи зламалась, та які докази допоможуть її виправити.