Архітектура проти посилення галюцинацій у графах агентів

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

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

План керування, а не запит

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

1. Типізований шинний механізм інструментів

Кожен інструмент має версійовану схему JSON для входних та вихідних даних, яка зберігається у реєстрі, до якого модель не має права змінювати. Модель може запропонувати виклик, але детерміністичний верифікатор повинен його прийняти або відхилити *до* того, як щось станеться в результаті. Жодного примусового типування, жодного „достатньо гарного“ мапування між значенням енумерації та тим, що створила модель. Якщо виклик є недійсним, він повертається до планувальника у вигляді структурованої помилки — ніколи у вигляді розмовного докору.

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

Для будь-якого інструменту з незворотними наслідками — надсилання чого-небудь, запису файлу, розгортання чи оновлення системи зберігання даних — механізм керування повинен вимагати подвійного контролю: ClaimSet, який вже пройшов перевірку, а також схвалення людини чи пряме дозволення згідно з правилами. За такою схемою агент-оператор ніколи не має прямого доступу до цих інструментів.

2. Журнал посилань лише для додавання

Кожен результат пошуку, кожен вихід інструменту та кожен факт, наданий людиною, записуються у сховище лише для додавання, індексовані за значенням run_id та хешем вмісту. Агентам заборонено просто „запам’ятовувати“ джерело в власному записнику — замість цього вони повинні використовувати ідентифікатори журналу посилань.

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

Тут також важлива функція хешування. Модель може посилатися на doc:matter-4421#p3, але все одно неправильно цитувати те, що насправді написано на сторінці 3. Облікова книга має зберігати сам текст — або принаймні посилання на незмінний об’єкт-сховище — щоб верифікатор перевіряв саме ці байти, а не те, що модель про них пам’ятає.

3. Брана схеми (не для LLM)

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

• масив claims[], кожен елемент якого містить type, text, ledger_ids[] та значення confidence, яке пізніше калібрується, а не просто визначається моделлю як „високе“
• масив open_questions[], який планувальник повинен або вирішити, або явно передати на розгляд вищого рівня
• масив action_intents[], який посилається на конкретний інструмент, а не на розпливчастий опис на кшталт „нам, мабуть, варто...“

Цей елемент має бути звичайним кодом — Pydantic, JSON Schema, політика CEL чи Rego, обирайте що завгодно. Це не може бути модель штучного інтелекту. Якщо ви покладете сюди модель мовлення, це просто означатиме повторне використання механізму critic-agent на нижчому рівні.

4. Перевірювач тверджень із іншим набором інформації

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

Потім проведіть перевірку на випливальність: чи підтверджує отриманий фрагмент твердження, чи суперечить йому, чи зовсім нічого про нього не каже? Це можна реалізувати за допомогою невеликої моделі NLI, обмеженого декодера, який може копіювати лише з цього фрагмента, або людини-рецензента. Ви не можете доручити цю роботу тій самій великій моделі чату, яка працює за тим самим системним запитом, та попросити її визначити, чи „виглядає твердження правильним“.

Коли заявку відхиляють, ніхто тихо не змінює формулювання, щоб вона пройшла під час наступної спроби. Вона повертається у вигляді Unsupported{proposition, missing_evidence}, і завданням того, хто займається плануванням, є знайти більше доказів, а не просто перефразувати проблему.

Цей крок також виявляє більш тонку проблему: заміна нечіткого, неперевірюваного твердження на таке, що здається обґрунтованим. Твердження про те, що рахунок-фактура сильно завищений, саме по собі не є перевірюваною заявкою. Лише вказавши конкретну суму — назвавши позицію, контрактний ліміт, який вона перевищує, суму понад цей ліміт та записи в бухгалтерському обліку, які підтверджують усе це — можна перетворити це на щось, що верифікатор може фактично підтвердити чи відхилити. Схема, яка приймає першу, більш нечітку форму, у кінцевому підсумку буде перевіряти тон, а не факти.

5. Оцінюйте за допомогою конкретних даних, а не вражень

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

• вірність: яка частина сформульованих тверджень насправді підтверджується даними облікової книги
• покриття: яка частина очікуваних тверджень насправді була сформульована графіком, адже мовчання також може вважатися невдачею
• точність утримання від відповіді: чи було відмовлення системи у відповіді дійсно обґрунтованим
• чистота від побічних ефектів: жоден незворотний виклик інструменту не виконується без належного дозволу

Якщо падіння рівня вірності на два пункти не може завадити розгортанню, у вас немає системи керування — у вас є лише панель керування, яка створює враження надійності.

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

6. HITL на незворотному краю

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

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

Опис контракту, а не його реалізація

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

{
  "run_id": "run_7f3c",
  "from_agent": "analyst",
  "claims": [
    {
      "id": "c_19",
      "type": "Assertion",
      "text": "Line item 14 exceeds the engagement-letter hourly cap.",
      "propositions": [
        {
          "id": "p_19a",
          "pred": "exceeds_cap",
          "args": {"line_id": "14", "cap_source": "engagement_letter"},
          "ledger_ids": ["led_aa12", "led_bb90"],
          "entailment": null
        }
      ]
    }
  ],
  "open_questions": [],
  "action_intents": [
    {
      "tool": "flag_invoice_line",
      "args": {"invoice_id": "INV-4421", "line_id": "14"},
      "requires_grant": true,
      "depends_on": ["c_19"]
    }
  ]
}

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

Також зверніть увагу, що значення entailment встановлено як null. Агент, який створив твердження, не має права самостійно заповнювати це поле — лише перевіряючий може це зробити. Дозволяти агенту оцінювати власні твердження — це все одно, що дозволяти компанії проводити власну аудиторську перевірку та називати її незалежним контролем.

Чому пропозиція „просто додати посилання“ все одно не спрацьовує

Найпоширенішим фальшивим засобом захисту є результат, який лише виглядає як посилання. Модель додає [1] або [2], іноді навіть вказуючи на справжній отриманий фрагмент. Потім ви відкриваєте цей фрагмент і бачите, що він насправді не підтримує це твердження.

Саме по собі посилання нічого не доводить. Справжній доказ виглядає так: цей конкретний уривок тексту, ця точна сукупність байтів, що відповідає певному твердженню, має позначку про наслідок та керується чіткою політикою щодо того, що відбувається, коли ця позначка є neutral. Без цього повного ланцюга „посилання“ — це просто форматувальний вибір, прикиданий під доказ.

Другим фальшивим засобом захисту є встановлення параметра температури на 0. Це не робить результат більш правдивим — воно лише робить неправильну відповідь послідовною. Стабільна галюцинація завжди пройде тестування шляхом зрізу даних. Вона не витримає належним чином підтримуваного обліку.

Скільки це коштує, чесно кажучи

Запуск демонстраційної системи на такому інструменті, як LangGraph, займає кілька днів. Однак створення справжньої системи керування — реєстру інструментів, журналу цитувань, механізмів перевірки схем, верифікатора на основі NLI, оцінок з використанням «золотих» прикладів, людського перегляду кожного шляху для запису даних та журналів подій, достатньо детальних для розуміння юристом — саме це відрізняє функціональний прототип від системи, якій можна довіряти при прийнятті реальних бізнес-рішень.

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

Перше запитання, яке варто поставити, — це не те, на якій платформі будувати, а те, де саме у цьому спектрі знаходиться ваш власний робочий процес.

Якщо це саме та проблема, з якою ви стикаєтесь

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

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

Пов’язана література

• Проектування стійких графів AI-агентів: повторні спроби, альтернативи та GraphRAG — Дізнайтеся, як створювати робочі процеси AI-агентів, стійкі до збоїв, за допомогою чітких механізмів обробки помилок, логіки повторних спроб, LangGraph, а також коли GraphRAG є кращим за звичайний RAG чи цикли агентів.
• Що розкриває створення агента за 10 хвилин про справжню архітектуру — Розглядається, чому інструменти швидкого створення агентів, такі як TrueForge, можуть приховувати архітектурні рішення, з якими вам доводиться стикатися за допомогою ручних фреймворків, як-от Deep Agents.