Испытание для ИИ: почему узкий выбор инструментов эффективнее для локальных моделей
Исследование на основе практических замеров ставит под сомнение распространенную догму о том, что мощным языковым моделям требуется доступ ко всему каталогу инструментов одновременно. Автор статьи демонстрирует, что для систем, работающих с ограниченным контекстом и «слабыми» моделями, фильтрация кандидатур перед запросом повышает точность выполнения задач.
# Узкий выбор против полного каталога: новый подход к инструментальным агентам
В мире искусственного интеллекта активно развивается направление инструментальных агентов — систем, способных не только генерировать текст, но и взаимодействовать с внешним миром: управлять базами данных, отправлять письма, анализировать документы и работать с веб-страницами. В таких системах критически важным этапом становится выбор нужного инструмента из доступного списка. Традиционная парадигма диктует показ модели всего каталога инструментов, позволяя ей самостоятельно определить, какой из них применить. Однако последние эксперименты показывают, что этот подход может быть не только неэффективным, но и вредным для определенных архитектур.
Проблема перегрузки контекста
Основная сложность заключается в управлении ресурсами. Современные оркестраторы ИИ, такие как те, над которыми работают многие энтузиасты и разработчики, могут включать в свой арсенал более девяноста инструментов. Они охватывают работу с таблицами, управляют задачами, позволяют просматривать презентации и анализировать новости. Когда перед языковой моделью открывается список из сотен опций, увеличивается нагрузка на контекстное окно, а также возрастает вероятность ошибки.
Для моделей, размещенных в облаке с огромными вычислительными мощностями, это, казалось бы, не проблема. Однако для локальных решений, работающих на потребительском оборудовании, ситуация иная. Автор исследования опирается на минимально рабочую конфигурацию, которая включает видеокарту NVIDIA RTX 3090 с 24 ГБ памяти и модель Qwen3.6 весом в 27 миллиардов параметров. Такая связка является достаточной для решения сложных корпоративных задач, но у нее есть фундаментальное ограничение: она не способна удерживать в контексте описания всех сотен инструментов без потери качества.
В традиционных системах, таких как Hermes, OpenClaw или Ouroboros, модель получает полный перечень доступных функций и решает, какую из них вызвать. Иногда для экономии контекста реализуют упрощенный режим: модель видит только краткие описания и названия, а затем самостоятельно запрашивает детали нужного инструмента. Это решение ориентировано на так называемые фронтир-модели (фронтир-модели), которые, по прогнозам экспертов, достигнут уровня Claude или GPT-5 и смогут уверенно работать с обширным набором опций. Однако автор придерживается другой цели: обеспечения стабильной работы в закрытом контуре на локальном оборудовании.
Гипотеза роутинга и её проверка
Вместо того чтобы нагружать модель полным списком, автор предлагает архитектуру с предварительным роутингом. В этой схеме перед основным вызовом модели работает специальный модуль, который анализирует текст запроса пользователя. По результатам анализа выбирается конкретная тематическая секция, например, «работа с почтой» или «анализ датасетов». Затем модель получает не все описания инструментов, а сжатый набор, включающий только те варианты, которые относятся к выбранной теме. В эксперименте это уменьшило количество кандидатов с почти девяноста до двадцати.
Для проверки гипотезы был создан тестовый корпус из 49 пользовательских запросов. Эксперимент проводился в два прогона с единственным отличием: в одном случае модель получала полный список инструментов, а в другом — отфильтрованный узкий набор. Результаты оказались показательно контрастными. При использовании узкого набора модель совершила 43 верных выбора из 44, то есть точность составила почти 98%. При работе с полным списком количество верных ответов снизилось до 39.
Важно понимать, что в тестах использовалась не «слабая» модель в общепринятом смысле, а та, которая не имеет избыточного контекстного окна для переработки такого количества данных. Потерянные четыре выборки связаны с характерной ошибкой локальных моделей: путаницей между инструментами с похожими названиями. Например, запрос на объединение датасетов мог ошибочно привести к выбору общего раздела управления датасетами. Узкий набор помогает избежать подобных ошибок не столько за счет уменьшения общей длины текста, сколько за счет снижения количества «соседей» с семантически близкими названиями.
Результаты на облачных моделях
Интересно, что результаты эксперимента не ограничиваются локальными решениями. В сентябре автор провел дополнительные замеры на двух мощных облачных моделях: GigaChat-2-Max и gpt-oss 120B. Несмотря на их значительные возможности, и они показали лучшую производительность в режиме узкого набора инструментов. Гипотеза о том, что для сильных моделей всегда необходим широкий спектр опций, не подтвердилась на выборке из 91 инструмента.
Однако в этом исследовании выявлен важный нюанс. Часть ошибок на узком наборе была связана не с ошибочным выбором инструмента, а с тем, что модель не смогла определить категорию запроса. Если роутер не нашел подходящий раздел, система могла сымпровизировать, выдав текстовый ответ вместо реального действия. Классический пример: при запросе «определите устройства в сети» модель, не найдя инструментов для сканирования, могла описать план действий текстом, не выполнив команду. Это подчеркивает, что оценка качества работы модели должна учитывать не только выбор инструмента, но и корректность обработки запросов, не попадающих в заранее заданные категории.
Выводы для разработчиков
Итог исследования однозначен: для систем, работающих в условиях ограниченных ресурсов или с моделями среднего веса, режим предварительной фильтрации инструментов (роутинга) является предпочтительным. Он измеряемо улучшает точность выбора и сокращает задержки отработки запросов. Автор рекомендует привязывать режим роутинга непосредственно к модели, создавая отдельные профили конфигурации для разных движков, а не использовать единые настройки для всей системы.
Кроме того, исследователи должны учитывать качество описаний инструментов. Четкие и различимые подписи функций могут компенсировать отсутствие полного контекста. Также важно правильно формировать критерии успеха тестирования: уточняющие вопросы пользователя нельзя списывать на ошибку модели, если это разумный этап диалога. В конечном счете, архитектура инструмента должна подстраиваться под возможности конкретной модели, а не наоборот.