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