Агенти самовдосконалення: зцілення, навчання та контрольовані зміни
Агенти, які самовдосконалюються, без ризиків: автоматичне відновлення під час роботи, навчання під час кількох запусків, а також зміни, які впроваджуються лише після оцінки та тестування, у LangGraph.
Джерела: Self-improving Agentic AI Applications — Feedback loop integration
Агент у стилі ReAct добре планує, використовує інструменти, отримує інформацію та виконує багатоетапні завдання. Проблеми починаються тоді, коли він починає працювати в реальних умовах, і хтось запитує, що станеться, якщо він припуститься помилки. Чи може він це помітити? Чи може він відновитися без перезапуску всього робочого процесу? Чи може він пам’ятати, що спрацювало, вчитися на корекціях користувачів та з часом покращувати свою поведінку?
Люди об’єднують ці запитання під позначкою „цикл зворотного зв’язку агента“, але ця позначка вводить в оману. Наведена нижче архітектура поєднує LangGraph з MongoDB, Gemini у Vertex AI та Arize Phoenix та охоплює відновлення під час роботи, навчання на досвіді, постійну оцінку та контрольоване вдосконалення.
Чому наївний цикл є небезпечним
Приваблива версія циклу зворотного зв’язку є короткою:
Agent produces answer
↓
LLM reflects on answer
↓
Agent learns
Це привабливо тому, що це просто, але водночас це й ризиковано. Коли ШІ оцінює власний вихід та негайно змінює свою подальшу поведінку, помилка може перетворитися на урок, урок — на спогад, а цей спогад може вплинути на тисячі подальших рішень.
Більш безпечний дизайн ґрунтується на іншому принципі: агент виправляє поточну реалізацію, платформа навчається на основі багатьох реалізацій, а шар керування вирішує, що стане остаточною поведінкою.
Конкретний приклад: агент пропонує коди для нарахування чи відрахування заробітної плати. Під час однієї роботи він обирає неправильний код, оскільки ніколи не отримував інформації про політику нарахування заробітної плати, специфічну для певного стану. Наївний шлях навчання виглядає так:
Agent made mistake
↓
Agent reflects
↓
"Always retrieve state policy"
↓
Write lesson to memory
↓
Future agents use lesson
Кілька речей можуть піти не так. Діагноз може бути неправильним. Правило може стосуватися лише одного типу транзакцій заробітної плати. Пізніша зміна політики може зробити цей урок застарілим. Зловмисний вхід користувача може спрямувати результати аналізу в неправильне русло. Крім того, урок може допомогти в деяких випадках, але нашкодити в інших.
Тому кращий підхід до проектування розглядає урок як гіпотезу, а не як істину.
Production failure
↓
Capture evidence
↓
Evaluate the run
↓
Identify recurring failure
↓
Generate lesson candidate
↓
Gather supporting and contradicting evidence
↓
Validate
↓
Canary test
↓
Activate
Ця зміна є тонкою. Агент не постійно переписує себе. Платформа, яка його оточує, постійно оцінює та розвиває агента.
Три рівні з різною повноваженням
Корисно уявити собі три взаємопов’язані рівні.
+------------------------------------------------+
| RUNTIME PLANE |
| |
| plan -> act -> validate -> repair -> respond |
+-----------------------+------------------------+
|
v
+------------------------------------------------+
| LEARNING PLANE |
| |
| evaluate -> diagnose -> cluster -> learn |
+-----------------------+------------------------+
|
v
+------------------------------------------------+
| CONTROL PLANE |
| |
| test -> approve -> canary -> rollout -> rollback|
+------------------------------------------------+
Кожен рівень працює у власному темпі та має різний ступінь автономії. Рівень виконання функціонує протягом мілісекунд чи секунд, і його єдиною задачею є надійне виконання поточного запиту. Рівень навчання аналізує багато спроб, які відбуваються протягом хвилин, годин чи днів, та визначає, що свідчать зібрані дані. Рівень керування вирішує, чи є запропоноване покращення достатньо безпечним для впровадження у фінальну версію продукту. У платформі адаптивних агентів мало які архітектурні рішення мають таке велике значення, як розділення цих трьох рівнів.
1. Самовідновлення під час виконання
Почнемо з негайної проблеми: виклик інструменту зазнає невдачі. Проста реалізація просто повторює спробу.
Tool failed
↓
Retry
↓
Retry
↓
Retry
Проте повторна спроба не є способом самовідновлення. Для відновлення необхідно знати, що зазнало невдачі, та обрати відповідну стратегію відновлення. Більш ефективний робочий процес LangGraph наближається саме до цього:
User Request
|
v
Clarification Gate
|
v
Retrieve Context
|
v
Plan
|
v
Proposed Action
|
v
Action Guard
|
v
Execute Tool
|
v
Sanitize Tool Result
|
v
Validate Tool Result
|
v
Reason
|
v
Validate Answer
|
+------ uncertain ------> Critic
| |
| v
| Policy Router
| / | | \
| PASS REPAIR HUMAN FAIL
| |
+---------------------------+
|
v
Response
Кілька ідей у цьому графіку заслуговують уваги.
Перевіряйте перед дією
Уявіть агента, який може виконувати дії з побічними ефектами: оновлювати дані співробітників, створювати відрахування з заробітної плати, подавати транзакції, змінювати рахунки чи надсилати сповіщення. Перевірка результату після факту вже занадто пізно. Архітектура потребує захисника дій перед будь-якою значущою зміною. Цей захисник оцінює дозволи, бізнес-правила, наявні докази, чи можна скасувати дію, рівень ризику та чи потрібна затвердження особи. Лише тоді інструмент може запуститися.
Це змінює підхід до перевірки. Питання більше не звучить як «Чи була дія правильною?», а стає набагато безпечнішим: «Чи маємо ми достатньо доказів та повноважень, щоб це дозволити?»
Вихідні дані інструменту також є ненадійними
Ще один ризик залишається непоміченим. Агенти читають контент з веб-сайтів, документів, API, пошукових систем, баз даних та інших агентів, і цей матеріал потрапляє до контексту LLM. Тому результати інструментів є ще одним шляхом для введення спонсорського коду, тож між виконанням інструменту та процесом міркувань має бути вбудований детерміністичний фільтр для очищення результатів інструментів.
External Tool
|
v
Tool Result
|
v
Sanitizer
|
v
Validator
|
v
LLM
Типові обов’язки санітайзера включають контроль типу та довжини вихідних даних, відхилення некоректних структур, ескейпування тексту, який може виглядати як інструкції, та виявлення ймовірних спроб вставки коду. Одне обмеження є суворим: жоден LLM не може використовуватися для перевірки тексту, який може бути адверсарським.
Тримайте валідатор окремо від критика
Поширеним підходом є запит у LLM щоразу під час запиту: «Чи є ця відповідь правильною?». Це збільшує затримку та витрати, а також надає моделі занадто багато повноважень. Спочатку має відбуватися детерміністична валідація, наприклад:
Schema correct?
Required fields present?
Allowed value?
Business invariant satisfied?
Evidence exists?
Policy satisfied?
Known contradiction detected?
Якщо програмне забезпечення може довести, що відповідь є неправильною, немає причин запитувати інший модель. Лише справжня семантична неоднозначність потрапляє до критика, і навіть тоді критик не керує процесом роботи. Його роль — діагностика, у такому ключі:
{
"correctness": 0.61,
"groundedness": 0.92,
"uncertainty": 0.73,
"defects": [
"missing_authoritative_evidence"
]
}
Потім маршрутизатор з детерміністичною політикою обирає один із чотирьох результатів:
PASS
REPAIR
HUMAN REVIEW
SAFE FAIL
Розділення є чітким: ШІ надає докази та оцінки, тоді як політика програмного забезпечення має повноваження.
Виправлення має змінити стратегію
Повторна спроба має сенс лише тоді, коли щось змінилося. Розглянемо агента, який це робить:
Search policy
↓
Generate recommendation
↓
Fail validation
Якщо ремонт повторює наведену нижче послідовність із тим самим запитом, тими самими доказами та тим самим підходом до обґрунтування, це не відновлення. Це просто повторення.
Search policy
↓
Generate recommendation
Надійний агент відстежує кілька полів.
failure signature
strategy fingerprint
attempt ID
repair strategy
remaining budget
quality delta
Тоді діє просте правило.
same failure
+
same strategy
+
same evidence
=
do not retry
Кожного разу, коли та сама проблема зустрічається з тією самою стратегією вдруге, агент повинен змінити стратегію, передати завдання людині або безпечно зазнати невдачі. Простий retry_count не враховує цього, тому для автономного відновлення в продакшені потрібні бюджети на ремонт. Вони можуть обмежувати кількість викликів LLM, інструментів, тривалість виконання, витрати та спроби семантичного відновлення. Метою не є наполеглива спроба довести справу до кінця — метою є використання обмеженої кількості ресурсів на стратегії відновлення, які дійсно відрізняються.
Перевірка ефективності ремонту
Різні спроби все одно можуть не дати результату. Припустимо, оцінювач ставить оцінку початковому результату:
quality score = 0.54
Після першого ремонту:
quality score = 0.55
Після другого:
quality score = 0.56
На папері це покращення, а на практиці — застій. Ремонтний дельта-шлюз це усуває.
delta = score_after_repair - score_before_repair
Коли кожен з окремих ремонтів приносить мінімальну користь, потік ресурсів припиняється.
small delta
+
small delta
=
human review or safe failure
Це захищає від однієї з найпоширеніших проблем агентів — дорогого циклу міркувань, який виглядає активним, але насправді майже нічого не досягає.
Людський огляд є варіантом обробки
Людський огляд не повинен вважатися невдачею. Для деяких завдань це просто правильне кінцеве рішення. Крім того, „людський огляд“ охоплює кілька різних результатів.
Human
|
+-----------+-----------+
| | |
Approve Edit Reject
| | |
Continue Validate Safe Fail
Request Repair
|
v
Repair
Кожен результат розвивається по-різному, тому кожен з них має бути чітко відображений у графіку. Модель переривання та відновлення роботи LangGraph добре підходить для цього, оскільки робочий процес можна зупинити на певному етапі, призупинити, а потім продовжити після того, як рецензент відповість.
2. Навчання на основі досвіду з різних виконань
Механізм виправлення під час виконання відповідає на питання, як врятувати цей запит. Механізм навчання на основі досвіду допомагає зрозуміти, що цей запит може навчити нас щодо майбутніх запитів. Його зазвичай використовують у фоновому режимі. Як тільки агент відповість:
run_completed
|
v
Evaluation worker
|
v
Gather feedback
|
v
Reflection
|
v
Candidate lesson
Нікому не доводиться чекати, поки один ШІ роздумує над тим, що міг би дізнатися інший ШІ. Затримка залишається низькою, а офлайн-оцінка може бути значно багатшою.
Відгуки — це не істина
Сигнали надходять з різних напрямків. Користувач ставить оцінку «низько». Експерт у галузі виправляє відповідь. API відхиляє транзакцію. Аудит відповідності виявляє помилку через два тижні. Це не є однаковим. Розгляньмо першу пару випадків, коли це не так:
thumbs up != correct
thumbs down != incorrectuser correction != authoritative rule
Тож відгуки слід зберігати як первинні докази та ранжувати за надійністю приблизно так:
Authoritative business outcome
>
Expert human label
>
Deterministic rule
>
Calibrated evaluator
>
User feedback
>
Agent self-confidence
Це запобігає тому, щоб емоції плуталися з об’єктивною правдою.
Деякі з найкращих відгуків надходять пізно
Агенти часто починають робочі процеси, успіх яких не можна одразу побачити.
Agent recommends payroll code
|
v
Payroll system accepts
|
v
Two weeks later
|
v
Audit rejects transaction
Корисний сигнал надходить значно після завершення виконання LangGraph, що означає, що кожне важливе рішення потребує причинно-наслідкового зв’язку. Необхідно передати run_id у наступні системи, щоб пізніші результати можна було прив’язати до рішення, яке їх спричинило. Інакше система навчання дізнається, що щось пішло не так, але не зможе визначити яке рішення агента заслуговує на похвалу чи звинувачення. Це класична проблема призначення заслуг.
Пам’ять потребує керування
Як тільки агенти навчаються під час кількох виконань, пам’ять стає водночас потужною та небезпечною. Варто розділяти три категорії пам’яті.
- Профільна пам’ять зберігає уподобання користувача чи суб’єкта, наприклад, бажання отримувати стислі пояснення.
- Епізодична пам’ять фіксує те, що сталося, наприклад, те, що виконання 182 провалилося через відсутність отримання політики стану.
Процедурна пам’ять найбільше впливає на поведінку, тому вимагає найсуворішого контролю. Одна невдала спроба ніколи не повинна створювати правило для продакшн-середовища. Шлях має виглядати приблизно так:
Observation
↓
Candidate lesson
↓
Supporting evidence
+
Counterexamples
↓
Validation
↓
Active lesson
Урок краще моделювати як гіпотезу плюс докази плюс обсяг плюс довіра плюс життєвий цикл, а не як текст, який вставляється до векторної пам’яті.
Набута пам’ять не може перевершити авторитетні знання
Агенти отримують два типи інформації. Авторитетні знання — це політики, регуляції, конфігурації, даних для посилань та договірних бізнес-правил. Набуті знання — це уподобання, досвід, попередні стратегії, спостереження та уроки. Вони повинні залишатися логічно окремими, з розумною ієрархією:
Authoritative policy
>
Tenant configuration
>
Approved procedural lesson
>
Episodic example
>
User preference
>
Unverified claim
>
LLM reflection
Інакше урок, який добре запам’ятався, може тихо переважити над фактичною політикою.
Уроки стають застарілими
Те, що було корисним шість місяців тому, тепер може бути неправильним. Політики, продукти, API, поведінка користувачів та моделі постійно змінюються. Активні уроки потребують управління протягом усього їхнього життєвого циклу.
candidate
↓
validated
↓
active
↓
pending revalidation
↓
deprecated
↓
retired
Додайте до кожного уроку часову позначку підтвердження, а за потреби — політику терміну дії чи повторного підтвердження. Зміна політики може спричинити переоцінку всіх уроків, створених на основі цієї політики, тож пам’ять перетворюється на упорядковані знання, а не просто на набір ембеддингів, який постійно зростає.
3. Офлайн-режим навчання
Наступний рівень об’єднує дані з багатьох запусків у реальних умовах.
Runs
+
User Feedback
+
Human Reviews
+
Downstream Outcomes
+
Evaluation Scores
|
v
Failure Classification
|
v
Failure Clustering
Скажімо, тиждень пробіжок показує такий розподіл:
missing state policy 178
wrong tool selected 63
bad tool argument 52
unsupported inference 41
output schema failure 11
Тепер платформа може бачити, які проблеми є системними. Це щось інше, ніж просити окремого невдалиого агента проаналізувати одну конкретну невдачу. Механізм навчання виявляє закономірності.
Не кожна невдача — це проблема зі запитом
Інженерія запитів не завжди є рішенням. Якщо агент постійно забуває отримати авторитетну політику перед тим, як щось порекомендувати, додавання рядка до системного запиту з проханням пам’ятати про це може допомогти. Сильнішим рішенням може бути структурне правило:
Graph rule:
Policy retrieval must occur before this decision.
Інші постійні проблеми можуть вимагати змін у цих сферах:
retrieval
tool schema
validator rule
routing
memory policy
clarification logic
action guard
model configuration
Зрілий двигун вдосконалень пропонує кілька можливих варіантів виправлень та не переписує запит автоматично.
Оцінка знаходиться в центрі
Якщо система може створювати вдосконалення, але не може визначити, чи вони кращі, то немає циклу навчання — лише цикл мутацій. Оцінка є основою цієї архітектури.
Correctness
Groundedness
Retrieval relevance
Completeness
Tool selection
Tool arguments
Trajectory efficiency
Repair effectiveness
Safety
Latency
Cost
Business outcome
Оцінка має враховувати кінцеву відповідь та також шлях, який було пройдено для її отримання. Два агенти можуть надати однакову відповідь. Агент А робить це так:
Agent A
search -> answer
поки Агент Б робить це:
Agent B
search
-> wrong tool
-> retry
-> timeout
-> second search
-> repair
-> answer
Якщо орієнтуватися лише на кінцеву відповідь, вони є еквівалентними. Однак оцінка траєкторії показує, що це явно не так.
Одного судді у вигляді ШІ недостатньо
Те, що Gemini пише відповідь, а інший Gemini оцінює її за запитом, є корисним, але несе ризик кореляційних помилок, адже оцінювач може мати ті самі сліпі плями, що й генератор. Більш надійний рівень оцінки поєднує кілька джерел.
Deterministic checks
+
Business outcomes
+
Human labels
+
Multiple evaluator rubrics
+
LLM judges
Оцінювачів LLM також слід час від часу порівнювати з прикладами, позначеними людьми. Це дозволяє з’ясувати, наскільки можна довіряти оцінювачеві, перш ніж його оцінки вплинуть на те, які уроки будуть просуватися.
Спостережуваність є частиною процесу навчання
Традиційний моніторинг перевіряє, чи працює сервіс. Спостережуваність агента також має враховувати, чому агент прийняв певне рішення. Хороша система для продакшну записує весь перебіг виконання LangGraph.
Agent Run
|
+-- Retrieve Context
|
+-- Planner
|
+-- Tool Call
|
+-- Tool Result Validator
|
+-- Repair
|
+-- Critic
|
+-- Final Answer
Кожен запуск також має мати стабільну ідентичність, яка об’єднує кілька записів.
LangGraph execution
MongoDB events
Vertex AI calls
Evaluation results
Human feedback
Downstream outcomes
Ця кореляція є сировиною для циклу. Спостережуваність більше не є лише засобом для виправлення помилок, а стає частиною системи навчання.
Чому допомагають події з можливістю лише додавання
Хочеться помістити всю траєкторію виконання в один документ MongoDB, але це спрацьовує спочатку, а при масштабуванні стає проблематичним. Краще зберігати дані компактно.
run_id
agent
release
outcome
latency
tool count
repair count
cost
Потім записуйте виконання як події з додаванням лише даних.
run.started
retrieval.completed
tool.called
validation.failed
repair.started
human_review.requested
run.completed
Це зберігає причинно-наслідковий порядок, уникає надмірного зростання документів, спрощує розподілене відстеження та робить аналіз несправностей більш точним.
Для відтворюваності потрібно більше, ніж просто версія запиту
Поведінка агента залежить від більшого, ніж лише його системного запиту.
model
generation settings
graph version
tool definitions
validator rules
critic rubric
retrieval configuration
memory rules
security rules
Кожна серія виробництва повинна використовувати незмінну версію агента. Концептуально:
agent_release_43
|
+-- graph v12
+-- prompt v43
+-- Gemini configuration
+-- tools v17
+-- validator v11
+-- retrieval config v9
+-- memory policy v5
+-- evaluation suite v8
Невдалу спробу можна потім повторити пізніше. Без цього відлов помилок перетворюється на запитання про ту версію, яка дала результат, після чого настає тиша.
Площина керування: покращення відкривають доступ до продакшну
Зрештою система навчання виявляє постійну помилку та розробляє варіант її усунення. Найгіршим рішенням є негайне впровадження цього варіанту. Краще спочатку пройти всі необхідні перевірки:
Candidate Improvement
|
v
Historical Replay
|
v
Regression Evaluation
|
v
Shadow Production
|
v
Canary
|
v
Progressive Rollout
|
v
Production
На кожному етапі порівнюйте кандидата з поточною версією. Це може покращити точність та погіршити затримку, зменшити галюцинації та підвищити необхідність людського втручання, або допомогти одному типу завдань, пошкодивши інший. Тому для просування потрібні кілька захисних механізмів.
Уроки також потребують «канарок»
У довгостроковій пам’яті є цікавий наслідок: коли активується новий процедурний урок та вводиться в контекст майбутніх агентів, їхня поведінка змінюється, тож введення уроку фактично є зміною запиту. Активацію слід розглядати як експеримент, а не негайно застосовувати до кожного підходящого виконання.
Historical replay
↓
5% canary
↓
Measure outcome
↓
25%
↓
Measure
↓
100%
Якщо урок погіршує продуктивність, поверніться до попередньої версії. Тоді пам’ять перестає бути таємничим адаптивним механізмом та стає вимірюваною частиною програмного забезпечення.
Кінцева архітектура
У сукупності платформа адаптивних агентів виглядає приблизно так:
USER
|
v
+------------------------------------------------------+
| RUNTIME |
| |
| clarify -> retrieve -> plan -> action guard |
| | |
| v |
| tool |
| | |
| sanitize |
| | |
| validate |
| | |
| reason |
| | |
| answer validate |
| | |
| critic if needed |
| | |
| policy router |
| / | \ |
| repair human pass |
+--------------------------+---------------------------+
|
agent events
|
v
+------------------------------------------------------+
| LEARNING |
| |
| traces + feedback + outcomes |
| | |
| v |
| evaluate |
| | |
| classify failures |
| | |
| cluster |
| / \ |
| lessons improvement candidates |
+--------+----------------------+----------------------+
| |
v v
+------------------------------------------------------+
| CONTROL |
| |
| validate -> replay -> shadow -> canary -> rollout |
| | |
| monitor |
| | |
| rollback |
+------------------------------------------------------+
Межі відповідальності навмисно чіткі. Агент під час виконання виправляє помилки. Система навчання генерує гіпотези. Контрольний рівень вирішує, що вважатиметься надійною поведінкою.
Переосмислення концепції „самовдосконалення“
Чуючи термін „агент, який самовдосконалюється“, багато хто уявляє ШІ, який переписує власні інструкції або оновлюється після кожної розмови. Для продакшн-систем це неправильна модель мислення. Кращою є модель циклу:
Observe
↓
Measure
↓
Diagnose
↓
Propose
↓
Test
↓
Promote
↓
Monitor
Інтелект тут не обмежується лише LLM. Різні компоненти системи його використовують:
- Граф LangGraph визначає порядок виконання.
- Валідатори звичайного коду забезпечують дотримання вже відомих правил.
- LLM вирішує всі ситуації, які є неоднозначними.
- MongoDB зберігає стан та накопичений досвід.
- Механізм відстеження збирає докази.
- Оцінювачі визначають якість.
- Люди приймають рішення, коли ризик високий, а відповідь неясна.
- План керування контролює будь-які зміни в поведінці.
Саме таке розподілення перетворює агента на адаптивну систему агентів.
Розумний порядок створення
Нікому не потрібно створювати всю систему одразу. Ефективна послідовність роботи починається з надійної реалізації та запису даних під час кожного запуску. До цього додаються механізми контролю дій, перевірка результатів та відповідей, обмежені способи виправлення проблем та людський огляд. Далі йде оцінка якості: аналіз записів, оцінка та класифікація збоїв, а також наявність набору даних для виявлення регресії. Досвід навчання вступає в силу лише тоді, коли якість можна оцінювати з впевненістю, що дозволяє використовувати кандидатів на вдосконалення, обмежену пам’ять, агрегацію доказів, контроль за застарілістю даних та затриману зворотну відповідь. Контрольоване вдосконалення є останнім етапом, який включає групування збоїв, генерацію кандидатів на вдосконалення, оцінку повторних запусків, імітацію трафіку та поступове впровадження змін.
Порядок має значення:
Reliability
↓
Observability
↓
Evaluation
↓
Learning
↓
Controlled adaptation
Переход до „самонавчання“ ще до проведення оцінки зазвичай призводить до системи, яка змінюється швидше, ніж інженери можуть це відстежувати.
Мета
Ніхто не повинен прагнути до агента, який сам себе редагує. Кращою метою є платформа, здатна демонструвати, коли агент має змінитися. Однієї пам’яті про попередні розмови недостатньо, щоб цикл заслуговував на довіру. Йому потрібна дисциплінована послідовність між цими етапами:
production behavior
↓
evidence
↓
evaluation
↓
learning
↓
experimentation
↓
controlled production change
Саме на цій ланцюговій структурі ґрунтується система адаптивних агентів, які керуються даними, і саме така архітектура необхідна для агентних ШІ, якщо вони мають перейти від демонстраційних прикладів до надійного продакшн-програмного забезпечення.