SkillWeaver и SAD: как Alibaba решила проблему маршрутизации навыков в ИИ-агентах, сократив расход токенов на 99%
Ваш ИИ-агент обзавёлся сотнями инструментов — от парсеров до генераторов отчётов, но на каждом шагу тупит, пытаясь вспомнить, какой из них применить. Знакомая боль? Инженеры Alibaba придумали SkillWeaver — фреймворк, который строит граф выполнения задачи и подбирает нужные скиллы для каждого узла. А ещё они внедрили Skill-Aware Decomposition (SAD) — хитрую технику с циклом обратной связи, которая заставляет агента итеративно перебирать кандидатов и отсеивать лишнее. Такой композиционный подход с петлёй обратной связи выгодно отличает SkillWeaver от других систем, которые просто тыкают пальцем в небо и выбирают инструмент с одного раза.
SkillWeaver напрямую связан с реальными кейсами, где агенты автономно оркеструют целые экосистемы инструментов вроде Model Context Protocol (MCP). Например, чтобы скачать датасет, преобразовать данные и сгенерировать визуальный отчёт — типичная многошаговая бизнес-операция. В экспериментах исследователей подход «найди и смаршрутизируй» резко повысил точность, а расход токенов сократился более чем на 99% по сравнению с тупым скармливанием агенту всей библиотеки инструментов. Главный вывод для разработчиков: гранулярность декомпозиции задачи — вот ключевое узкое место для точного поиска нужного инструмента.
Проблема маршрутизации навыков
Скиллы — один из ключевых паттернов в современных архитектурах LLM-агентов. Скилл — это модульная, переиспользуемая спецификация инструмента с документированием на естественном языке. Когда корпоративные агенты подключаются к огромным библиотекам инструментов, точно направить пользовательский запрос к нужному скиллу становится адской задачей. Запихать всю библиотеку в промпт LLM — путь в никуда: контекст мгновенно переполняется, а расход токенов улетает в сотни тысяч.
Современные фреймворки обычно пытаются решить это через поиск по API, сопоставление документации или иерархические структуры. Но они рассматривают маршрутизацию как выбор одного скилла на шаг. Однако для корпоративной среды этого мало — реальные запросы по своей природе композиционны. Стандартное «Скачай датасет, преобразуй и сделай отчёт» одним инструментом не выполнить. Нужно разбить промпт на части и выстроить последовательность: API-клиент, обработчик данных, инструмент визуализации — в связный многошаговый план.
Как работают SkillWeaver и SAD
Чтобы справиться с этим, исследователи сформулировали задачу как «композиционную маршрутизацию скиллов». По сложному пользовательскому запросу и огромной библиотеке инструментов агент должен одновременно понять, как разбить запрос на атомарные подзадачи, как сопоставить каждую подзадачу с лучшим доступным скиллом и как собрать эти скиллы в исполняемый план.
SkillWeaver оркестрирует процесс в три этапа: Decompose, Retrieve, Compose. На первом этапе LLM-декопмозер разбивает сложный запрос на последовательность подзадач, каждая из которых требует одного скилла. Когда подзадачи чётко определены, система использует эмбеддинговую модель, чтобы сравнить каждую подзадачу с библиотекой скиллов и вытащить шорт-лист лучших кандидатов для каждого шага. На финальном этапе планировщик оценивает кандидатов на совместимость: проверяет, чтобы выход одной задачи естественно втекал во вход следующей. Затем строится финальный план в виде направленного ациклического графа (DAG), который отображает зависимости — так независимые шаги можно выполнять параллельно.
Пример: пользователь просит агента «Скачай датасет, преобразуй его и создай визуальные отчёты». На этапе декомпозиции LLM разбивает это на три подзадачи: скачать датасет, преобразовать данные, создать отчёты. На этапе поиска система находит кандидатов: для первой задачи — «api-client» или «http-fetch», для второй — «csv-parser» или «etl-pipeline» и так далее. Наконец, композиция выбирает самую совместимую комбинацию, скажем, «api-client», «csv-parser» и «chart-gen», и связывает их в готовый к выполнению workflow.
Главная проблема: LLM часто генерируют слишком общие описания шагов, не совпадающие с техническим словарём реальных скиллов. Чтобы это исправить, SkillWeaver вводит Iterative Skill-Aware Decomposition (SAD) — ту самую петлю обратной связи. SAD работает так: LLM набрасывает черновой план, проводит предварительный поиск, находит слабо подходящие скиллы, а затем передаёт эти скиллы обратно LLM как подсказки. Теперь модель может переписать декомпозицию так, чтобы гранулярность и словарь идеально совпали с существующими инструментами. Выглядишь немного грустной для девушки, SAD? На самом деле — очень боевой фреймворк.
SkillWeaver в действии
Чтобы оценить производительность в реалистичных корпоративных сценариях, исследователи создали свой бенчмарк — CompSkillBench. В нём 300 многошаговых запросов разного уровня сложности. Для имитации реального окружения использовалась библиотека из 2209 реальных скиллов из публичной экосистемы MCP, покрывающая 24 функциональные категории: облачная инфраструктура, финансы, базы данных и так далее. В качестве движка декомпозиции взяли легковесную 7-миллиардную модель Qwen2.5-7B-Instruct, а для семантического поиска — MiniLM с FAISS-индексом.
SkillWeaver сравнивали с тремя подходами: методом «в лоб» (LLM-Direct), где в промпт большой модели запихивали все имена инструментов; ванильной декомпозицией без 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 токенов до примерно 1160 токенов на запрос — снижение на 99,9%. Для разработчиков это означает радикальное уменьшение затрат на API и рост скорости ответа.
Традиционный ReAct-цикл полностью провалился — 0% точности декомпозиции. Его цикл естественным образом схлопывает многошаговые планы в изолированные действия, вместо того чтобы явно выстраивать связную последовательность инструментов. Такая вот садовая грусть для старых подходов.
Что учесть разработчикам
Исследователи пока не выложили исходный код SkillWeaver, но их работа построена на готовых инструментах, которые легко воспроизвести. Skill-Aware Decomposition (SAD) — ключевая инновация — по сути, умный промптинг с циклом поиска. Авторы поделились шаблонами промптов в своей статье, так что разработчики могут реализовать это самостоятельно, используя стандартные библиотеки оркестрации вроде LangChain, LlamaIndex или даже сырой Python-скрипт.
Что касается поиска, то ядро фреймворка собрано на all-MiniLM-L6-v2 — открытой эмбеддинговой модели. Замена на чуть более сильный кодировщик BGE-base-en-v1.5 сразу повысила точность без дообучения. Готовая биэнкодерная модель хорошо справляется с тем, чтобы затащить нужный инструмент в топ-10 кандидатов почти в 70% случаев, но стабильно