Ескалація вузлів, а не завдань: шестирівнева драбина для контролю витрат у робочому процесі ШІ

Багато команд, які створюють пайплайни на основі ШІ, починають з одного архітектурного запитання щодо кожної нової функції: чи слід це виконувати як фіксована структура DAG чи як автономний агент? Це звучить як логічний етап перевірки проекту, але відповідь на це запитання на рівні всієї задачі тихо визначає витрати на найбільш невизначений етап для всіх інших етапів. У цій статті пояснюється, як це відбувається, а потім пропонується шестиступенева ієрархія ескалації, у якій кожен етап починається з найдешевшого можливого рівня та піднімається лише у разі порушення чіткого контракту. До кінця ви зможете розкласти на складові власні завдання „агента“, зрозуміти, наскільки вони є детермінованими, та встановити жорсткі обмеження для ресурсів, які може витратити решта.

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

Вихідна точка: класифікувати кожне завдання заздалегідь

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

Завдання з відкритим форматом передавалися агенту

Завдання, які вважалися справді відкритими за своєю структурою, були реалізовані як єдиний агент ReAct у LangGraph. Прикладом слугувало пошук роботи на основі резюме. Користувач завантажує своє резюме, і система мусить знайти вакансії, на які варто подати заявку, та підготувати індивідуальне резюме для кожної з них. Це включає резюме, написані кількома мовами, підбір кандидатів до вакансій за параметрами, які неможливо визначити лише за ключовими словами (час доїзду з дому, склад команди, щоденні обов’язки на роботі, діапазон заробітної плати), а також створення індивідуалізованого документа. Ніхто не може заздалегідь сказати, скільки кроків це потребує, тому це виглядало як класичний приклад для агента.

Завдання з передбачуваним ходом виконання були передані статичній DAG

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

Розділення обов’язків здавалося логічним, і проект було реалізовано. Проблема полягала у тому, що витрати так і не знизилися.

Чому податок на агентів ніколи не зникає

Механізм, який лежить в основі плоскої кривої витрат, є звичайним, і саме тому його легко проігнорувати.

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

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

Повторне читання наукових праць разом із місяцями записів з роботи системи призвело до майже простого у своїй логіці висновку:

Невизначеність належить до окремих вузлів, а не до всіх завдань разом.

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

Якщо розглянути процес пошуку роботи, закономірність стає очевидною:

• Для вилучення структурованих полів з PDF-резюме зовсім не потрібні моделі для міркувань.
• Визначення мови, якою написане резюме, також є механічним процесом.
• Знаходження адреси проживання та розрахунок часу дороги — це один виклик інструменту.
• Отримання інформації про вакансії означає звернення до API роботи.
• Оцінка того, наскільки певна посада підходить певному кандидату, вимагає одного запиту до моделі, фіксованого запиту та жодних інструментів.

Лише щось на кшталт „дізнатися, що саме ця команда нещодавно розсилала“ не має передбачуваної кількості кроків.

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

Шкала ескалації

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

• L0: лише виклики інструментів, без LLM. Якщо запит можна повністю задовольнити за допомогою детермінованих операцій, жодні моделі не запускаються. У продукті це є існуючим швидким шляхом, який залишається окремою системою. Витрати складають лише вартість викликів інструментів.
• L1: статична схема DAG з механічними вузлами. Справжня схема з гілками та розгалуженнями, але кожен вузол — це звичайний код. Також не відбувається жодних викликів моделей.
• L2: статична DAG із вузлами LLM для одноразового використання. Форма графа залишається незмінною, але деякі вузли тепер запускають модель один раз у межах вузько визначеного контексту. Насправді вузол бачить лише свої прямі вхідні дані: жодної історії розмови, жодного глобального стану та, що найважливіше, жодних схем інструментів. На цьому рівні модель поводиться як чиста функція, а не як агент. Витрати становлять O(n) викликів, причому значення n відоме ще до початку виконання.
• L3: цикли уточнення з обмеженнями. Вузол L2 може спробувати виконати завдання згідно з контрактом до фіксованої кількості N спроб. Саме контракт, а не модель, визначає, чи є результат прийнятним. Витрати становлять O(n·N), причому це значення також відоме ще до початку виконання.
• L4: непрозорий вузол стає підагентом. Вузол, який не можна визначити заздалегідь, отримує справжню циклічну структуру ReAct, але його інструменти обмежені цим вузлом, і у нього є жорсткий ліміт кроків. Ніхто не може передбачити, скільки він витратить, і саме ця непередбачуваність є причиною, чому у нього має бути чіткий верхній ліміт.
• L5: повне перепланування. Сам план був неправильним, тому граф перебудовується. Це найдорожчий варіант дій та має траплятися рідко.

Контракти, обсяг та бюджети

Сама таксономія була б лише кращою лексикою. Три механізми забезпечують функціональність цієї системи:

• Контракти запускають процес підвищення рівня. Кожен вузол визначає формат прийнятного результату, і лише невдалий перевірка цього формату є підставою для переходу на вищий рівень.
• Обсяг дії зберігає L4 доступним за ціною. Схеми інструментів підагента знаходяться всередині контексту цього одного вузла та не з’являються ніде інде під час виконання, тому податок за схеми сплачується локально.
• Бюджети встановлюють верхню межу. Кожен рівень вище L2 має максимальну кількість спроб або кроків; після цього вузол або здається, або переходить на вищий рівень.

Практичний спосіб мислення про це: контракт відповідає на питання „Чи цього достатньо?“, обсяг дії — на питання „Що може бачити та викликати цей вузол?“, а бюджет — на питання „Скільки він може витратити на спроби?“. Якщо бракує хоча б одного з цих елементів, відповідний рівень стає непередбачуваним. Щоб дізнатися більше про контроль циклів на рівнях L3 та L4 у коді, дивіться обмежені агентські цикли в TypeScript.

Процес створення субтитрів: крок за кроком

Більшість виконань ніколи не доходять до рівня L1. У цьому процесі вилучається аудіо, виконується розпізнавання мовлення, відбувається сегментація за часовими мітками та створюється файл SRT, причому жодних викликів моделей не відбувається. Потім результат перевіряється згідно з встановленими правилами: сегменти не повинні перекриватися, жоден рядок не може перевищувати обмеження за кількістю символів, а швидкість читання має залишатися нижче певного порогу. Типове відео з чітким аудіо проходить перевірку, і для обробки потрібно не більше, ніж ffmpeg та один процес розпізнавання.

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

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

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

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

Пошук роботи крок за кроком

Це приклад, який змінив підхід команди, адже він очевидно нагадував роботу агента.

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

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

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

L4 — це єдиний вузол: дослідження команди конкретної компанії та її останніх напрямків розвитку. За своєю природою він є відкритим, але обмежений за конструкцією.

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

Основний результат полягає у тому, що завдання, яке раніше класифікувалося як робота агента, насправді складається приблизно на 80% з роботи типу L1 та L2. Це не питання налаштування запиту; це змінює всю структуру витрат у процесі роботи.

Що пропонує продукт типу «файл-до-файлу»

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

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

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

Коли Ladder не є доцільним

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

Спочатку — найпростіша частина

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

Він був випущений як SDK для Python з відкритим кодом Python SDK, опублікований на PyPI під ліцензією Apache-2.0 та може використовуватися як сервер MCP усередині Claude Code. Встановлення здійснюється за допомогою одного командного запиту з використанням uv або pip.

uv add convilyn          # or: pip install convilyn

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

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

Текущий стан двигуна робочих процесів

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

Попередні розробки та пов’язана робота

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

Почніть з простого та додавайте складність лише тоді, коли це необхідно

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

Підвищуйте рівень лише того компонента, який зазнав невдачі

• Стаття ADaPT, назва якої означає розкладання та планування за потребою (Findings of NAACL 2024), починається з загального плану та далі рекурсивно розбиває підзавдання лише після того, як його виконання зазнає невдачі, залишаючи успішні частини недоторканими. Це найближчий до публікації опис механізму активації L4, хоча він не сформульований з урахуванням витрат.

Контракти, обмежені правила відновлення та ескалації

• Теоретична схема планувальника для виконання агентів LLM у вигляді структурованих графів, опублікована в arXiv у квітні 2026 року, використовує статичну DAG із контрактами вихідних даних для кожного вузла та трьохетапний протокол відновлення — повторна спроба, локальне виправлення та повне перепланування, із чіткими правилами ескалації. Автори стверджують, що вузли, які базуються на моделях, мають перевірятися за контрактами, оскільки типові перевірки недостатні, а повторна спроба нейдемпотентних кроків вимагає обмежених ресурсів. У цій схемі навмисно не передбачено рекурсивне розширення підграфів, де існує концепція L4.

Planування з розділенням завдань (TDP), про яке йдеться у тій самій статті, розділяє роботу на граф підзавдань, кожне з яких має власний вузький контекст, та обмежує будь-яке перепланування лише поточним активним підзавданням. Воно повідомляє про зниження кількості токенів до 82%, що є найближчим опублікованим показником, який підтримує аргумент щодо обмеження функціоналу на рівні L2.

Обсяг інструментів як основний фактор витрат

• Skillflow визначає DAG у форматі YAML, яким керується двигун, а не модель. Його вхід/вихід контролюється можливостями: кожен крок отримує лише той контекст, про який просить, а будь-який інструмент, який не входить до його контракту, просто не з’являється у його схемі. Його висновок про те, що невеликий контекст, специфічний для певної ролі, дозволяє використовувати дешеві моделі, узгоджується з аргументом L2.

Етапні сходинки, які вже використовуються у продакшені

• PraisonAI включає у свій SDK агентів функцію ескалації, яка визначає чотири послідовні етапи: пряма відповідь без використання інструментів чи планування, використання евристичних інструментів без додаткового виклику моделі, один обмежений виклик моделі та, нарешті, повністю автономний цикл із використанням інструментів, підагентів та перевірки. Це приблизно етапи від L0 до L4, стиснуті у чотири кроки.
• Маршрутизатор ескалації NVIDIA NeMo Switchyard застосовує таку саму структуру для вибору моделі замість архітектури: спочатку використовується слабша модель, а при виявленні постійних проблем — переходить на сильнішу.

Та сама структура в інших місцях

• Agentic Design Patterns (systemdesign.one, квітень 2026 р.) використовує термін „драбина ескалації“ для позначення вибору між робочим процесом та агентом та рекомендує використовувати найпростішу можливу конфігурацію, яка дозволяє виконати завдання.
• Посібник Vercel з фреймворками оцінки AI-агентів для продакшену (липень 2026 р.) застосовує принцип „найдешевше спочатку“ під час оцінки: спочатку виконується найдешевший перевірювач, здатний виявити певну проблему, а ескалація відбувається лише тоді, коли цей перевірювач структурно не може виявити проблему.

Основні висновки

• Вирішення питання „DAG чи агент“ для кожного завдання дозволяє зробити кожен крок ефективним для найбільш невизначеного кроку.

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

Починайте роботу кожного вузла на найдешевшому рівні та піднімайтеся лише у разі невдачі чи явного порушення контракту.

Обмежуйте схеми інструментів лише тим вузлом, який їх потребує, та встановлюйте жорсткий бюджет для кожного рівня вище L2.

Очікуйте, що більшість „агентських“ завдань будуть у значній мірі детермінованими після розкладання; у випадку пошуку роботи близько 80% належало до рівнів L1 та L2.

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

• Проектування багатоагентних систем на основі протоколу A2A: вузли, пам’ять та управління — це довідкова архітектура багатоагентних систем, побудованих на протоколі A2A, яка охоплює модулі агентів, типи пам’яті, оркестрацію, ризики безпеки та чек-лист для проектування.
• LangGraph на практиці: стани, вузли, ребра та п’ять шаблонів агентних процесів — Дізнайтеся, як визначати стани LangGraph за допомогою анотацій та редукторів, з’єднувати вузли ребрами та реалізовувати всі п’ять основних шаблонів агентних робочих процесів у JavaScript.