У міру масштабування корпоративних систем ШІ для обробки складних робочих процесів, практики стикаються з проблемою маршрутизації підзавдань до правильних інструментів та навичок. Агенти можуть мати сотні інструментів та навичок і плутатися, який з них використовувати для кожного кроку робочого процесу.
Для вирішення цієї проблеми дослідники Alibaba розробили SkillWeaver – фреймворк, який створює граф виконання для заданого завдання та обирає правильні навички для кожного з вузлів. Вони також представили Skill-Aware Decomposition (SAD) – новаторську техніку, яка використовує цикл зворотного зв’язку, щоб дозволити агенту ітеративно отримувати та перевіряти відповідні кандидати інструментів. Такий композиційний підхід та механізм зворотного зв’язку відрізняють SkillWeaver від інших фреймворків маршрутизації інструментів, які обирають інструменти за один крок.
SkillWeaver пов’язаний з реальними ШІ-додатками, де агенти автономно оркеструють мультиінструментальні екосистеми, такі як Model Context Protocol (MCP), для виконання багатоетапних бізнес-операцій, наприклад, завантаження наборів даних, трансформація інформації та створення візуальних звітів.
На практиці експерименти дослідників з SkillWeaver показують, що впровадження цього підходу “отримання та маршрутизації” значно підвищує точність, одночасно зменшуючи споживання токенів більш ніж на 99% порівняно з наданням агентам доступу до всієї бібліотеки інструментів.
Для практиків, які розробляють ШІ-агентів, головний висновок полягає в тому, що деталізація розбиття завдань є найбільшим вузьким місцем для точного вибору інструментів.
Проблема маршрутизації навичок
Навички є ключовим шаблоном у сучасних архітектурах агентів LLM. Навичка – це модульна, багаторазова специфікація інструменту, яка використовує структуровану документацію природною мовою.
Оскільки корпоративні агенти інтегруються з величезними екосистемами інструментів, точна маршрутизація запитів користувачів до правильних навичок стає складним завданням. Надання всього бібліотеки LLM для пошуку правильного інструменту є надзвичайно неефективним, швидко вичерпує ліміти контексту та споживає сотні тисяч токенів.
Більшість сучасних фреймворків використання інструментів намагаються вирішити це за допомогою отримання API, відповідності документації або ієрархічних структур, які розглядають маршрутизацію виключно як проблему вибору одного інструменту або проблеми на кожному кроці.
Однак, ця парадигма одного інструменту є недостатньою для корпоративного середовища, оскільки реальні запити за своєю суттю є композиційними. Стандартний бізнес-запит, такий як “Завантаж набір даних, трансформуй його та створи візуальні звіти”, не може бути виконаний одним інструментом. Це вимагає розбиття запиту та послідовного використання клієнта API, обробника даних та інструменту візуалізації для створення узгодженого, багатоетапного плану виконання.
Як працюють SkillWeaver та SAD
Щоб вирішити цю проблему, дослідники формулюють проблему обробки складних завдань, які вимагають кількох навичок, як “композиційна маршрутизація навичок”. Отримавши складний запит користувача та величезну бібліотеку інструментів, агент повинен одночасно визначити, як розбити запит на послідовність елементарних підзавдань, як зіставити кожне підзавдання з одним найкращим доступним навичком, і як скомпонувати ці навички в виконуваний план.
SkillWeaver оркеструє цей процес через три окремі етапи: Декомпозиція, Отримання та Компонування. На першому етапі LLM діє як декомпозитор завдань, розбиваючи складний запит користувача на послідовність підзавдань, кожне з яких потребує одного навику. Після чіткого визначення підзавдань система використовує модель вбудовування (embedding model) для порівняння кожного підзавдання з бібліотекою навичок, щоб отримати короткий список найкращих інструментів-кандидатів для кожного кроку.
На останньому етапі планувальник оцінює отримані кандидати на основі того, наскільки добре вони працюють разом. Він перевіряє сумісність навичок, щоб забезпечити природний потік виходів одного інструменту до входів наступного. Потім він створює остаточний план виконання у вигляді спрямованого ациклічного графа (DAG), який відображає залежності, дозволяючи незалежним завданням потенційно виконуватися паралельно.
Наприклад, розглянемо запит користувача до ШІ-агента: “Завантаж набір даних, трансформуй його та створи візуальні звіти”. На етапі декомпозиції LLM-декомпозитор розбиває це на три окремі підзавдання: завантаження набору даних, трансформація даних та створення звітів.
На етапі отримання система шукає в бібліотеці та знаходить такі кандидати, як “api-client” або “http-fetch” для першого завдання, “csv-parser” або “etl-pipeline” для другого, і так далі. Нарешті, етап компонування оцінює ці варіанти, обирає конкретну комбінацію “api-client”, “csv-parser” та “chart-gen”, які є найбільш сумісними, та об’єднує їх у остаточний, готовий до виконання робочий процес.
Ключовою проблемою цього конвеєра є те, що LLM часто генерують загальні описи кроків, які не відповідають специфічній технічній термінології доступних у бібліотеці навичок. Для вирішення цієї проблеми SkillWeaver впроваджує Ітеративну Декомпозицію з Урахуванням Навичок (Skill-Aware Decomposition – SAD), новий цикл зворотного зв’язку. SAD працює шляхом того, що LLM створює початковий план, проводить попередній пошук для знаходження приблизно відповідних навичок, а потім передає ці отримані навички назад до LLM як підказки. Це дозволяє LLM переписати свою декомпозицію так, щоб деталізація та термінологія ідеально відповідали існуючим інструментам.
SkillWeaver у дії
Для оцінки ефективності SkillWeaver у реалістичних корпоративних сценаріях дослідники створили власний тест CompSkillBench. Він складається з 300 багатоетапних запитів різного рівня складності. Щоб відобразити реальні середовища, вони використали бібліотеку з 2 209 реальних навичок, отриманих із загальнодоступної екосистеми MCP, що охоплює 24 функціональні категорії, такі як хмарна інфраструктура, фінанси та бази даних.
Для основного механізму дослідники переважно використовували легку модель з 7 мільярдами параметрів (Qwen2.5-7B-Instruct) для декомпозиції завдань, у поєднанні зі стандартним пошуковим механізмом семантичного пошуку (MiniLM з індексом FAISS) для знаходження інструментів. SkillWeaver оцінювався проти трьох основних конфігурацій: метод “LLM-Direct” з повним перебором, де вони вставляли всі назви інструментів у промпт великої моделі; стандартна LLM-декомпозиція без SAD; та агентський цикл у стилі ReAct.
Експерименти свідчать, що декомпозиція завдань є головним вузьким місцем. Стандартна поведінка LLM виявляється недостатньою при роботі з великими бібліотеками інструментів, але цикл зворотного зв’язку SAD значно покращує ситуацію. У стандартній конфігурації 7B модель досягала точності декомпозиції (тобто, прогнозування правильної кількості кроків) лише в 51.0% випадків. Після активації циклу зворотного зв’язку SAD точність зросла до 67.7% (з більшою моделлю Qwen-Max точність досягла 92%). Для “складних” завдань, що вимагають чотирьох-п’яти окремих навичок, SAD підвищив точність на 50%.
Одне з цікавих спостережень полягає в тому, що більші моделі можуть фактично працювати гірше без належного керування. При тестуванні у стандартному режимі, більша модель з 14 мільярдами параметрів показувала точність нижчу, ніж 7B модель, оскільки вона мала тенденцію надмірно розбивати завдання на мікроскопічні, непотрібні кроки. Після впровадження SAD, підказки щодо отриманих інструментів повернули модель до реальності та підвищили її точність. Це свідчить про те, що узгодження агента з термінологією конкретних інструментів часто є більш ефективним, ніж використання більшої та дорожчої LLM.
Ще один важливий висновок – економія токенів. Базовий метод LLM-Direct, який використовував дуже велику модель Qwen-Max, показав, що передача всіх інструментів у промпт великої моделі не працює. Незважаючи на майже ідеальні можливості розбиття завдань, масивна модель отримувала правильну категорію інструменту лише в 21.1% випадків, коли її заповнювали варіантами інструментів. Цільовий підхід SkillWeaver “отримання та маршрутизація” значно перевершив цей показник за точністю, одночасно скоротивши споживання контексту з приблизно 884 000 токенів до приблизно 1 160 токенів на запит, що становить 99.9% скорочення. Для практиків це безпосередньо означає різке зниження витрат на API та прискорення часу відповіді.
Нарешті, традиційний базовий метод ReAct повністю зазнав невдачі, показавши 0% точності декомпозиції. Його цикл природно розбиває багатоетапні плани на ізольовані дії, а не явно моделює послідовну, багатоінструментальну послідовність.
Розгляд для розробників
Хоча дослідники ще не опублікували вихідний код SkillWeaver, їхня робота була побудована на готових інструментах, які легко відтворити.
Skill-Aware Decomposition (SAD), яка є ключовою інновацією у фреймворку, – це розумний цикл інженерії промптів та отримання даних. Автори поділилися шаблонами промптів у своїй статті, і розробники можуть легко реалізувати його самостійно, використовуючи стандартні бібліотеки оркестрації, такі як LangChain, LlamaIndex, або навіть прості скрипти Python.
Щодо компонента отримання, автори побудували основний фреймворк, використовуючи all-MiniLM-L6-v2 – модель вбудовування з відкритим кодом. Вони виявили, що заміна на трохи потужніший стандартний кодер (BGE-base-en-v1.5) негайно підвищила точність без будь-якого доналаштування. Хоча стандартний бі-енкодер добре отримує релевантний інструмент у топ-10 кандидатів майже в 70% випадків, він погано ранжує ідеальний інструмент на першому місці, досягаючи цього лише приблизно в 37% випадків. Щоб подолати цей розрив, командам, ймовірно, доведеться впровадити вторинний крос-енкодер або LLM-основний реранжувальник для перевпорядкування цих топ-10 кандидатів.
Однією з початкових вимог до підготовки є векторизація бібліотеки інструментів та створення індексу FAISS заздалегідь. На практиці це незначна перешкода. Вбудовування та індексування всіх 2 209 навичок у бенчмарку зайняло всього 15 секунд. Після створення, отримання інструментів з індексу додає менше 15 мілісекунд затримки на запит. Для корпоративних середовищ синхронізація індексу інструментів є тривіальним фоновим завданням.
Потоковим обмеженням SkillWeaver є відсутність відновлення після помилок. Хоча SkillWeaver успішно моделює сумісний DAG для виконання, пілотне дослідження авторів виявило труднощі з багатоетапними ланцюжками інструментів. Наприклад, якщо виклик API зазнає невдачі на другому кроці, весь ланцюжок розривається. Основний внесок статті обмежується фазою маршрутизації та планування. Для справжнього виробничого розгортання практикам необхідно побудувати власні механізми відновлення після помилок, резервування та повторних спроб поверх етапу компонування для обробки реальних тайм-аутів API або неправильних вихідних даних.
Як захиститися (Порада CryptoDom): Завжди перевіряйте джерела інформації, особливо якщо це стосується нових технологій. Розробникам варто застосовувати підходи, як SAD, для покращення безпеки та ефективності власних ШІ-систем, використовуючи зворотний зв’язок для оптимізації взаємодії з інструментами.
Інформація підготовлена на основі матеріалів: venturebeat.com