L’ANALISI
Strands Decider 2B: come usare un modello locale per routing e controlli degli agenti
Analisi pratica di Strands Decider 2B: architettura, checkpoint locale, uso negli agenti, benchmark dichiarati, limiti e checklist di valutazione.
In breve: Strands Decider 2B è un componente locale per decisioni chiuse dentro un agente: legge uno stato, assegna probabilità a opzioni definite e può bloccare, instradare o chiedere conferma prima di un’azione. Non sostituisce il modello generativo e richiede soglie validate sul proprio traffico.
Che cosa è stato rilasciato
Il pacchetto comprende checkpoint v19 su Hugging Face, codice Apache 2.0, CLI e server HTTP, ricetta di training, inventario dei dati, manifest e valutazioni. Il modello deriva da Qwen3.5-2B-Base con LoRA rank 16 e una piccola testa dedicata alle opzioni.
Come prende una decisione
Le richieste definiscono uno stato e domande di tipo choice, noul o score. La testa confronta le rappresentazioni delle opzioni in un singolo passaggio e restituisce una distribuzione, senza decodifica autoregressiva né testo libero.
Dove entra in un agente
Gli usi più concreti sono routing, selezione degli strumenti, controllo degli argomenti prima di una tool call, triage e policy classification. L’esempio ufficiale lo usa prima di una chiamata meteo per verificare se la città sia stata realmente fornita e, in caso contrario, rimandare l’agente a una domanda di chiarimento.
Prestazioni dichiarate e misura
Il repository riporta 167 risposte corrette su 231 nel set pubblico JevBench, mediana di 115 ms su RTX 3090 e 153 ms sui compiti brevi su M3 Pro. Sono misure del progetto, con rumore fra retraining e forte divario fra tier facili e difficili: non equivalgono a una garanzia sul proprio dominio.
Confine locale e integrazione
Il modello può girare su CPU, CUDA o Apple silicon e il server locale ascolta per impostazione documentata su 127.0.0.1 senza autenticazione. L’esempio Strands usa ancora un LLM Bedrock per l’agente principale: locale è il decider, non necessariamente l’intera pipeline.
Condizioni e limitazioni
Non è un modello di ragionamento o generazione. I risultati dichiarati provengono dal progetto: la model card segnala debolezze su documenti lunghi, domande fuori distribuzione e trasferimento della calibrazione. Soglie e affidabilità vanno misurate sui propri casi.
Checklist per una prova controllata
- Installare in un ambiente isolato e fissare checkpoint e dipendenze.
- Definire poche decisioni chiuse con opzioni non ambigue.
- Preparare casi etichettati, inclusi errori, ambiguità e fuori distribuzione.
- Misurare accuratezza, calibrazione, latenza e tasso di escalation.
- Impostare una soglia che mandi i casi incerti a regole, LLM o revisione umana.
- Provare concorrenza e stabilità del server sul dispositivo scelto.
- Registrare versione, input e decisione senza trattenere dati sensibili inutili.