Un modello da 1,1 GB non dialoga: esegue un compito solo. Obsessive-1.7B, derivato da LFM3-1.7B, prende una domanda fattuale, chiama web_search una volta e restituisce una risposta corta, una citazione parola per parola e l'URL della fonte. Se i risultati non contengono la risposta, dice "Not found in the search results." Non è pensato per chattare: il suo posto è sotto un modello più grande, come subagente che produce elementi verificabili.

Il modello base LFM ha sorpreso il suo autore per la capacità di gestire tool call ed estrarre informazioni. L'esempio riportato è Barbara Liskov: risposta, citazione letterale e link alla voce di Wikipedia.

La scelta tra copertura e prevedibilità

Nei test su un benchmark a risultati fissi (131 domande SimpleQA, in 29 delle quali la risposta era stata rimossa dai risultati) il modello base trova la risposta quando c'è nel 50% dei casi, Obsessive nel 94%. Quando la risposta non c'è, il base non dice mai "not found": zero su cento; Obsessive cento su cento. Le risposte inventate scendono dal 10% del base allo 0%. Il tempo mediano per domanda su un laptop con RTX 4060 passa da 5,1 a 2,0 secondi.

Sulla ricerca live su Wikipedia (120 domande più 40 richieste multi-fatto, su un backend di ricerca mai visto in addestramento) il modello base restituisce una risposta nel 38% dei casi, Obsessive nel 100%. Sulle risposte corrette il base vince: 37 su 120 contro 24 su 120. Il motivo è dichiarato: il base continua a cercare e scrive risposte lunghe, quindi la risposta emerge più spesso; però nel 62% dei casi esaurisce i turni e non restituisce nulla. Obsessive cerca una volta e dichiara solo ciò che può citare. Nei valori fattuali inventati, il confronto live è 4 su 4 per il base e 3 su 52 per Obsessive.

Qui emerge un punto strutturale. In un sistema automatico, un componente che non risponde nel 62% dei casi è un buco nero: l'orchestratore non sa se riprovare, passare ad altro o fermarsi. Un subagente che restituisce sempre una risposta, con citazione e URL, offre un contratto operativo più stretto. Certo, paga in copertura grezza: dice "not found" per circa una risposta su dieci che in realtà è nei risultati e a volte cita un fatto vicino, come il vincitore dell'anno sbagliato. Ma l'architettura permette una verifica a valle: la citazione è lì, pronta per il controllo.

Il metodo di addestramento è altrettanto interessante. LoRA rank 16, circa 9.000 conversazioni tool-calling, una RTX 4060 laptop. I risultati di ricerca provengono da Wikipedia e pagine FineWeb, con ogni risposta e citazione controllata perché compaia testualmente; circa un quarto dei dati insegna il "not found". Il modello si serve con llama-server, file GGUF, contesto da 16.384 token e temperatura 0: una configurazione self-hosted, non cloud. I problemi noti sono coerenti con il vincolo: una sola domanda per conversazione, il multi-turn lo confonde, solo inglese, e tende a riportare affermazioni come fatti ("X dice di aver risolto Y" può diventare "Sì").

Un modello locale da 1,1 GB che agisce come subagente sposta gli incentivi per chi valuta pipeline on-premise. Non serve un data center per avere componenti specializzati: il fine-tuning può avvenire su un laptop, i dati restano in casa e la distribuzione passa da strumenti GGUF già noti. Il confronto non è più fra modello grande e generico oppure piccolo e inutile: è fra copertura statistica e prevedibilità operativa. Per chi valuta deployment on-premise, AI-RADAR offre framework analitici su /llm-onpremise per soppesare questi trade-off.