Оценка и оптимизация агентов: сравнение DSPy, TextGrad, Reflexion и OPRO

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

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

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

Пять подходов разделяют эту идею: DSPy с его оптимизаторами MIPRO и COPRO, TextGrad, Reflexion и OPRO. Их механизмы, уровень зрелости и практическая применимость отличаются, но каждый из них отвечает на один вопрос: как агент может перейти от ручной настройки промптов к повторяемым улучшениям, основанным на метриках?

Оценка находится в центре каждого цикла

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

• Что-то, что можно изменить: программа агента, подсказка, рабочий процесс или правило принятия решений.
• Набор задач или критерии оценки, определяющие, что должен делать агент.
• Критерий оценки — будь то метрика, шкала, награда или правило успеха — который позволяет отличить лучшие результаты от худших.
• Оптимизатор, явный или неявный, который предлагает изменения на основе ранее полученных оценок.

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

• точность против задержки

качество при заданных затратах

защита от переобучения

автономность по сравнению с контролем

широкая универсальность против настройки под конкретные задачи

локальное улучшение по сравнению с надежностью всей системы

Поэтому эти библиотеки лучше рассматривать как элементы пространства проектирования для совершенствования агентов, а не как конкурирующие приемы формирования промптов.

Почему растет давление

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

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

Тогда требуется что-то вроде дисциплины MLOps, адаптированной к системам, построенным на языковых моделях. Обычные тестирования программного обеспечения необходимы, но недостаточны, а классическая оценка ML помогает, но не покрывает всё. Агенты добавляют собственные элементы, влияющие на их работу: промпты, вызовы инструментов, механизмы поиска информации, структуру планирования, память, возможности повторных попыток и чувствительность к конкретной модели. Автоматизированная оценка и оптимизация предоставляют практические инструменты для контроля за этой изменчивостью.

Четыре основные техники

DSPy с MIPRO и COPRO: оптимизация программы

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

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

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

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

TextGrad: критика как градиент

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

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

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

Рефлексия: извлечение уроков из неудачных попыток

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

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

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

OPRO: модель в качестве оптимизатора

OPRO, сокращение от Optimization by PROmpting, превращает языковую модель в оптимизатор. Она предлагает более подходящие варианты промптов, используя историю предыдущих результатов, таким образом одна модель ищет в пространстве инструкций подходящие варианты для другой модели или программы.

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

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

Два способа сортировки вариантов

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

По местоположению:

• Оптимизация в оффлайн-режиме включает DSPy с использованием MIPRO и COPRO, TextGrad и OPRO.
• Для адаптации во время выполнения или для каждой эпизодической обработки предназначен Reflexion.
• Также возможно гибридное использование, поскольку сигналы от запусков Reflexion могут собираться в оффлайн-режиме и подаваться в циклы в стиле DSPy-, TextGrad- или OPRO.

По целям:

• Обработкой текста запросов и инструкций занимаются MIPRO, COPRO, TextGrad и OPRO.
• Примеры с небольшим количеством примеров настраиваются с помощью MIPRO и COPRO.
• Структура программы и компоненты пайплайна относятся к более широкой экосистеме DSPy.
• Траектории выполнения и восстановление при ошибках — это сфера деятельности Reflexion.

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

Продолжайте измерять и совершенствовать их как отдельные слои

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

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

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

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

Узкий список кандидатов

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

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

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

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

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

Что можно построить на его основе

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

1. SDK для оценки. Единый способ определения задач агентов, наборов данных и метрик. Он стандартизирует схему тестовых случаев, ожидаемые результаты или критерии оценки, формат логирования, сбор информации о затратах и задержках, версионирование наборов данных и базовые показатели для выявления регрессии. Цель: команда может описать своего агента, набор для оценки и критерии успеха без необходимости писать собственные инструменты.

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

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

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

Интеграция с корпоративной плоскостью управления. Фреймворк подключается к точкам контроля CI/CD, инструментам наблюдаемости, каталогам моделей, механизмам хранения секретов и управления средами, мерам контроля за данными и рабочим процессам утверждения для сценариев с высоким риском. Благодаря такой интеграции библиотека техник отделяется от корпоративных возможностей.

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

Поэтапное внедрение

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

Этап второй: офлайн-оптимизация с использованием DSPy. Сделать DSPy в сочетании с MIPRO и COPRO основным инструментом для стабильных классов задач, включая компиляцию запросов, выбор примеров, настройку инструкций и возможность повторяемого сравнения экспериментов.

Этап третий: отражение во время выполнения с ограничениями. Внедрить политики в стиле Reflexion для агентов, чьи сбои часто можно устранить путем повторной попытки с анализом причин, селективными повторными попытками, структурированной памятью для отражения действий и диагностикой на уровне траектории выполнения.

Четвертый этап: продвинутые режимы — ограниченно. Включайте функции TextGrad и поиск в стиле OPRO только там, где существует явная необходимость и процесс оценки достаточно развит, чтобы ими управлять. Как правило, это должно оставаться возможностью команды платформы до тех пор, пока она не станет доступной для всех разработчиков.

Где возникают проблемы

• Чрезмерная адаптация к метрикам. Узкие или устаревшие критерии оценки заставляют оптимизатор учиться на этих критериях, а не на реальной задаче.
• Хрупкие критерии оценки. Если оценка основывается на слабых или несогласованных моделях-оценщиках, оптимизация будет следовать за особенностями этих оценщиков.
• Локальные успехи, глобальные потери. Настройка одной подзадачи может незаметно увеличить затраты или замедлить другие этапы, а также изменить поведение остальных частей рабочего процесса.
• Шумные процессы рефлексии. Рефлексия без ограничений по правилам приводит к увеличению количества токенов и задержкам при минимальной реальной пользе.

Фрагментация организации. Когда каждая команда выбирает собственные библиотеки оптимизации и правила оценки, компания теряет возможность сравнения и контроль.

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

Форма решения

То, что объединяет DSPy, MIPRO, COPRO, TextGrad, Reflexion и OPRO, — это не способность каждого из них улучшать промпты. Каждый из них стремится превратить совершенствование агентов в систему обратной связи. Стратегический подход заключается не в том, чтобы предоставить каждому разработчику доступ ко всем идеям, а в создании контролируемой внутренней структуры, в которой оценка стандартизирована, оптимизация осуществляется избирательно, отражение действий во время выполнения соответствует установленным правилам, а варианты промптов управляются как производственные ресурсы.

Для более точных рекомендаций наилучшим подходом является использование DSPy в сочетании с MIPRO и COPRO для выполнения оффлайн-оптимизации, применение Reflexion в качестве общего шаблона выполнения для ограниченной самокоррекции, предназначение TextGrad для специализированных команд, а также рассмотрение OPRO в основном как внутренней техники поиска, а не как зависимости для разработчиков. Победителями среди корпоративных агентов станут те, у кого качественный цикл обратной связи, причем быстрая сообразительность имеет гораздо меньшее значение.