Il segnale: un contratto operativo da 1,1 GB

Obsessive-1.7B non dialoga. Il modello, derivato da LFM3-1.7B e grande circa 1,1 GB, esegue un compito solo: riceve 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 della ricerca non contengono la risposta, risponde con «Not found in the search results.» Non è pensato per sostenere una conversazione, ma per stare sotto un modello più grande come subagente che produce elementi verificabili. Questa divisione del lavoro non è solo un dettaglio tecnico: sposta la valutazione di un LLM locale dalla capacità di conversare alla capacità di mantenere un contratto operativo stretto.
Il peso ridotto e la distribuzione tramite GGUF, con llama-server e contesto da 16.384 token, collocano Obsessive-1.7B nel perimetro self-hosted. Su un laptop con RTX 4060 il tempo mediano per domanda scende da 5,1 a 2,0 secondi rispetto al modello base. Questo rende il subagente un componente realistico per pipeline on-premise, non una curiosità da laboratorio.
Il segnale per chi valuta infrastrutture locali è chiaro: la specializzazione spinta può produrre, con pochi gigabyte e una scheda consumer, un comportamento più prevedibile di un modello generalista più grande. La domanda non è più se un modello piccolo sia intelligente, ma quale ruolo gli si affida e quali garanzie offre all'orchestratore.

Copertura contro prevedibilità: i numeri di un bivio

I test su benchmark a risultati fissi (131 domande SimpleQA, 29 con risposta rimossa) mostrano il bivio. Il modello base trova la risposta quando presente nel 50% dei casi; Obsessive nel 94%. Quando la risposta è assente, il base non dichiara mai «not found», mentre Obsessive lo fa nel 100% dei casi. Le risposte inventate scendono dal 10% del base allo 0%. Sul piano operativo, una risposta assente e una sbagliata hanno costi diversi: l'assenza può essere gestita con un retry, l'invenzione richiede verifica a valle o produce danni.
Sulla ricerca live su Wikipedia, con 120 domande e 40 richieste multi-fatto su backend mai visto in addestramento, la copertura cambia segno. Il modello base restituisce una risposta nel 38% dei casi, Obsessive nel 100%. Sulle risposte corrette, però, vince il base: 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, ma nel 62% dei casi esaurisce i turni e non restituisce nulla. Obsessive cerca una sola volta e dichiara solo ciò che può citare.
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. Sui valori fattuali inventati, il confronto live è quattro su quattro per il base e tre su cinquantadue per Obsessive.

Il fine-tuning su laptop cambia la geografia dell’addestramento

Il metodo di addestramento merita attenzione. Per ottenere Obsessive-1.7B sono state usate LoRA rank 16, circa 9.000 conversazioni di tool-calling e una RTX 4060 laptop. Non serve un cluster: il fine-tuning avviene su hardware consumer. Questo abbassa la soglia per creare subagenti specializzati e riporta l'addestramento dentro l'organizzazione.
I dati provengono da Wikipedia e pagine FineWeb. Ogni risposta e citazione è stata controllata perché compaia testualmente; circa un quarto dei dati insegna il «not found». Non si tratta solo di mostrare esempi positivi: il dataset addestra anche il rifiuto quando le fonti non bastano. È un lavoro di ingegneria dei dati, non una magia del modello.
Per chi valuta deployment on-premise, questa combinazione cambia i vincoli. Il controllo dei dati di addestramento non richiede infrastrutture cloud; la distribuzione con GGUF rientra in strumenti già adottati. Il costo del fine-tuning è legato a una scheda consumer e a un dataset curato, non a una bolletta API ricorrente. Il TCO si sposta dalla spesa per inference cloud alla manutenzione di componenti locali e alla qualità dei dati.

Subagenti verificabili: un’unità contabile per le pipeline

In un'architettura a più modelli, il modello orchestratore delega compiti fattuali a subagenti. Il valore di Obsessive-1.7B non è nel sapere di più, ma nel restituire sempre un oggetto verificabile: risposta, citazione testuale e URL. Questa forma stabile permette all'orchestratore di applicare regole, log e controlli senza adattarsi a formati imprevedibili.
Il confronto con il base è istruttivo. Un modello che a volte non risponde, a volte inventa, obbliga a gestire l'incertezza a monte. Un subagente che risponde sempre, anche con «not found», trasforma il fallimento in un evento codificato. La prevedibilità operativa diventa una metrica di primo ordine, accanto alla qualità delle risposte.
La verifica a valle è il punto di forza dell'approccio. La citazione è già estratta e il link è pronto: un sistema di controllo può confrontare il testo citato con la fonte senza dover rigenerare o chiedere al modello. Per settori regolati o per archivi interni, questa caratteristica riduce il rischio di introdurre contenuti non verificati nelle procedure automatiche.
C'è un costo: la copertura grezza cala. Obsessive dice «not found» in circa una domanda su dieci in cui la risposta era presente e talvolta cita il fatto sbagliato. Ma un errore con citazione è più economico da individuare di una risposta fluida senza fonte. La scelta tra un modello più coprente e uno più verificabile non è tecnica in senso stretto: è una decisione di rischio.

Sovranità e costi: il ritorno del modello specializzato

L'idea di un LLM locale da 1,1 GB specializzato 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.
La dimensione della sovranità diventa concreta. Un'organizzazione può addestrare un subagente sui propri documenti, con le proprie regole di citazione, senza inviare query a un fornitore cloud. Il modello e i dati di contesto rimangono nel perimetro aziendale. Per chi opera in settori regolati, questo riduce i rischi legali e di compliance.
Sul piano del TCO, un componente locale elimina i costi per token delle API esterne e riduce la latenza di rete. Il costo fisso è l'hardware per l'inference e per eventuali cicli di fine-tuning. Con una RTX 4060 laptop il tempo mediano è già compatibile con molti flussi automatici; non serve una GPU datacenter. La moltiplicazione di subagenti specializzati può frammentare la manutenzione, ma ogni componente è piccolo e sostituibile.

Cosa guardare da qui: multi-fatto, multi-turno e soglie di fiducia

I limiti dichiarati di Obsessive-1.7B sono coerenti con il vincolo scelto: una sola domanda per conversazione, il multi-turno lo confonde, solo inglese, e tende a riportare affermazioni come fatti. Non è un sostituto di un assistente generale, né un motore di ricerca. È un componente con un contratto ristretto.
Il prossimo passaggio è capire se il modello può gestire domande multi-fatto senza perdere la prevedibilità. Le 40 richieste multi-fatto del test live suggeriscono che il problema è già sul tavolo. Un subagente che risponde a una sola domanda per volta obbliga l'orchestratore a spezzare il lavoro e a riaggregare i risultati, con costi di coordinamento. La sfida è mantenere la verifica della citazione quando il compito diventa composito.
Anche il multi-turno andrà osservato. Oggi il modello si confonde se la conversazione prosegue. Per pipeline che interrogano documenti in modo iterativo, questo è un limite forte. Potrebbero emergere varianti specializzate per sessioni brevi o per reiterazione di query, magari con contratti diversi.
Infine, serve una riflessione sulle soglie di fiducia. Il modello offre un comportamento deterministico con temperatura 0, ma la qualità della citazione non è uniforme. Monitorare il tasso di «not found» falsi e la precisione delle citazioni diventerà importante quanto misurare l'accuratezza. Per chi usa AI-Radar, il framework analitico su /llm-onpremise serve proprio a soppesare questi trade-off senza trasformare un esperimento in una raccomandazione universale.