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

Команди рідко переходять відразу до автоматизованої оцінки та оптимізації агентів. Зазвичай процес відбувається поступово: спочатку використовуються розумні запити та кілька одноразових експериментів, потім — повторювані вимірювання, далі — цілеспрямована налаштування, і нарешті з’являється достатньо впевненості, щоб контрольовано випускати зміни.

Зазвичай все починається з агента, який має чіткий системний запит, кілька інструментів та демонстрацію, що справляє враження. Це гарна початкова точка, але вона дає мало результатів. Коли все більше людей починає покладатися на агента, постають практичні запитання: які робочі процеси залишаються стабільними, а які зазнають проблем при великих обсягах роботи? Що відбувається з поведінкою агента після оновлення базової моделі? Чи добре агент справляється з тими завданнями, які найважливіші для операцій, контролю ризиків чи клієнтів?

Інженерія запитів — це корисна базова навичка, проте справжня зрілість досягається шляхом впровадження агента у дисциплінований цикл вдосконалення. Агент, якого можна систематично оцінювати, можна також систематично вдосконалювати, а той, кого можна систематично вдосконалювати, піддається керуванню з набагато більшою впевненістю. Тож нагорода полягає не лише у кращих запитах — це контрольований цикл навчання для систем мовних моделей: визначити, що означає «хорошо», виміряти поведінку за цими критеріями, застосувати цілеспрямовану оптимізацію та зберігати достатньо записів, щоб довіряти результатам.

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

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

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

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

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

• точність проти затримки

якість за рахунок витрат

покриття проти переобучення

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

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

локально покращений крок проти надійності всієї системи

Тому ці бібліотеки краще розглядати як позиції в просторі проектування для вдосконалення агентів, а не як конкуруючі трюки з формулювання запитів.

Чому тиск зростає

На початкових етапах проектів корпоративних агентів зазвичай керуються інтуїцією експертів. Кваліфікований фахівець переписує запити, коригує описи інструментів, додає приклади та перевіряє результати, поки вихідний продукт не стане прийнятним. Для одного-двох сценаріїв використання цього достатньо.

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

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

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

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