Punti Chiave
- Efficienza dei Token: Il consumo scende da 884.000 a soli 1.160 token per query, con un incremento dell'accuratezza del 50% sui task complessi.
- Tecnologia: Framework SkillWeaver basato su Skill-Aware Decomposition (SAD), costruito su modello Qwen2.5 a 7 miliardi di parametri.
- Limite Operativo: Il planner non gestisce gli errori runtime; un fallimento API a metà catena blocca l'intero processo esecutivo.
Il problema del rumore informativo
Quando un modello linguistico deve orchestrare migliaia di strumenti esterni, il metodo bruto non paga. Riversare l'intera libreria di funzioni disponibili dentro un singolo prompt genera un carico insostenibile: nei test di laboratorio si sono toccati picchi di 884.000 token solo per permettere all'agente di "vedere" le opzioni a disposizione. È un collo di bottiglia che SkillWeaver promette di eliminare radicalmente, cambiando l'approccio da statico a dinamico.
La logica della decomposizione
Il cuore del sistema è la Skill-Aware Decomposition. Invece di caricare tutto, l'algoritmo spezza la richiesta dell'utente in un grafo di esecuzione a nodi. Per ogni singolo sotto-obiettivo, recupera solo gli strumenti realmente pertinenti, ignorando il rumore di fondo. Il risultato del test, condotto su un benchmark proprietario di 300 richieste multi-step attingendo a 2.209 strumenti reali dell'ecosistema MCP, parla chiaro: consumo ridotto a 1.160 token e un balzo di accuratezza del 50%. Emerge un dato tecnico rilevante: i modelli di grandi dimensioni, se lasciati senza una guida strutturale come SAD, tendono a frammentare i compiti in passaggi microscopici e superflui, peggiorando la resa finale invece di migliorarla.
Codice chiuso, template aperti
Sviluppato nei laboratori di Shanghai, il progetto non ha ancora rilasciato il codice sorgente completo. Tuttavia, i template dei prompt utilizzati sono già di dominio pubblico e risultano riproducibili tramite librerie standard come LangChain o tramite script Python personalizzati. Resta però un vuoto strutturale non trascurabile: la gestione degli errori a runtime è assente dal planner. Se una chiamata API fallisce durante l'esecuzione di un passaggio intermedio, l'intera catena logica si interrompe senza un protocollo di recupero automatico.
