nvlabs/toolorchestra

ToolOrchestra: Elevating Intelligence via Efficient Model and Tool Orchestration [ код , веса ] Исследователи из NVIDIA и Университета Гонконга (HKU) поднимают проблему агентного оркестрирования. Современные мультимодальные агенты (например, в Humanity's Last Exam) строятся по принципу монолита: одна огромная LLM (как GPT-4o или Claude) пытается решить задачу самостоятельно, периодически дергая базовые тулы вроде поиска или интерпретатора кода. Авторы говорят: это не эффективно и дорого. Намного лучше работает другой подход — небольшая (8B) модель-оркестратор, которая управляет целым парком инструментов. В этот набор инструментов входят не только калькуляторы и поиск, но и другие специализированные и общие LLM (от Qwen-Coder до GPT-5). То есть, маленькая LLM решает, когда задачу можно решить дешевым локальным поиском, а когда нужно позвать GPT-5 или специализированную математическую модель. Метод Авторы обучают модель Orchestrator-8B (на базе Qwen3-8B) с помощью метода ToolOrchestra в парадигме Perception-Reasoning-Action. При этом, если просто взять готовую LLM и попросить её выбрать нужную модель-инструмент (через промпт), она ведет себя предвзято: ➡️ Self-enhancement bias: Qwen будет вызывать другие модели Qwen. ➡️ Other-enhancement bias: GPT-5 будет в 98% случаев вызывать GPT-5-mini или себя же, игнорируя стоимость и наличие других, не менее подходящих моделей. Чтобы научить 8B-модель быть хорошим менеджером, её обучают с помощью GRPO. Reward строится не просто на правильности ответа, а как взвешенная сумма трех компонентов: ➡️ Outcome: решена ли задача в итоге (судит GPT-5). ➡️ Эффективность: штрафы за стоимость вызванных моделей (по реальным API-ценам) и за задержку (latency). ➡️ Пользовательские предпочтения: вектор предпочтений, описывающий, насколько пользователю критична цена, приватность (локальный поиск vs web) или скорость. Для обучения авторы собрали синтетический датасет ToolScale. Пайплайн его создания включает симуляцию баз данных,