Il sintomo: una biografia dentro un task di refactoring

L'episodio parte da un ambiente di inference locale: una RTX 5070 Ti, il progetto Strata e un modello Qwen3.8-27B portato in quantization IQ3_XXS. L'utente sta affrontando un refactoring. Deve scrivere uno script probe_eol.js per distinguere i file con fine riga CRLF da quelli LF, scegliere i caratteri corretti nelle specifiche JSON e procedere file per file. Durante la pianificazione registrata nei log di ragionamento, la sequenza operativa si interrompe. Dopo una frase su Zoo che controlla i fine riga, il modello vira su una biografia di Lee Kuan Yew: Cambridge, Middle Temple, il figlio Lee Hsien Loong. Non c'è alcun collegamento con il compito.

Il punto non è l'errore fattuale. Una biografia di Lee Kuan Yew può essere corretta. Il problema è il cambio di registro dentro il flusso di ragionamento. In un task di refactoring, il modello dovrebbe mantenere una separazione tra il contesto operativo e le conoscenze latenti. Qui quella separazione collassa. Il modello non contesta un fatto: inserisce un'intera enciclopedia personale in un punto in cui serviva una decisione tecnica. Per chi esegue LLM locali, questo comportamento è più insidioso di una semplice allucinazione, perché non si manifesta nell'output finale, ma nei pensieri intermedi.

La prima implicazione riguarda l'attenzione umana. Nei flussi di lavoro self-hosted, gli operatori guardano spesso il risultato finale: il codice ripulito, lo script generato, la risposta prodotta. I log di ragionamento vengono consultati solo in caso di errore evidente. Se la deriva semantica avviene nei passaggi intermedi e poi il modello riprende il filo, l'anomalia può restare invisibile. Eppure quel passaggio estraneo ha già compromesso la coerenza della catena di ragionamento. La supervisione basata sul solo output non basta quando il guasto è nella traiettoria.

Il contesto è quello di un task reale, non di un benchmark. Il refactoring, la verifica dei fine riga e le specifiche JSON richiedono precisione procedurale. Il modello stava operando come strumento di sviluppo. L'inserimento di una voce enciclopedica mostra che il confine tra conoscenza generale e compito attivo non è garantito. È un segnale per chi pensa che l'esecuzione locale risolva in automatico i problemi di controllo: il controllo dipende anche dalla qualità dei passaggi interni, non solo dalla sovranità dei dati.

La tracciabilità del reasoning come variabile infrastrutturale

I log di ragionamento non sono più una scatola nera invisibile. In molti stack self-hosted vengono usati per diagnosticare errori, verificare passaggi intermedi e, in prospettiva, alimentare pipeline agentiche. Se un modello quantizzato produce interpolazioni di contesto così nette, la tracciabilità del processo decisionale diventa fragile. Non si tratta di un log illeggibile per rumore; si tratta di un log che racconta una storia diversa da quella eseguita. Chi usa quei log per ricostruire una decisione si trova davanti a un salto non spiegato, una biografia politica in mezzo a un controllo di fine riga.

La differenza tra un errore di sintesi e la perdita di separazione dei contesti merita attenzione. Un errore di sintesi produce un output finale sbagliato, ma il percorso resta ricostruibile. Qui il percorso stesso include un segmento estraneo. Il modello non sbaglia a rispondere: smette temporaneamente di rispondere al task. Questo rende fragile ogni forma di audit. In contesti dove la sovranità dei dati impone di documentare le scelte automatizzate, un log con deriva semantica non offre una base affidabile per la revisione.

La seconda conseguenza è operativa. I team che gestiscono modelli on-premise usano i log di ragionamento per il debugging. Quando un comportamento anomalo viene segnalato, il primo passo è guardare i pensieri intermedi. Se quei pensieri possono contenere blocchi non correlati, il debugging diventa più costoso: bisogna distinguere le deviazioni innocue da quelle che hanno prodotto un errore a valle. Non si può dare per scontato che il modello segua un piano lineare. La manutenzione del sistema include la manutenzione della coerenza del ragionamento.

Infine c'è una dimensione di fiducia. L'adozione di LLM locali cresce proprio perché le organizzazioni vogliono controllare i propri dati e i propri modelli. Ma il controllo tecnico non coincide con il controllo cognitivo. Avere il modello sulla propria macchina non garantisce che il modello resti sul compito. La tracciabilità diventa una variabile infrastrutturale: va progettata, misurata e manutenuta. Non è un accessorio per gli audit, ma una condizione per usare i log come fonte di verità operativa.

Compressione spinta e VRAM: il prezzo dei token al secondo

Il passaggio alla quantization IQ3_XXS nasce da una necessità pratica: far girare un modello da 27 miliardi di parametri su una scheda consumer. La RTX 5070 Ti ha limiti di VRAM. Compressioni spinte riducono l'ingombro e consentono l'inference locale. L'utente segnala un incremento tra 2 e 3 volte nelle prestazioni rispetto alle varianti IQ4XS usate in precedenza. Il guadagno di velocità è reale ed esplicito. Ma il caso mostra che il costo può emergere in fase di reasoning, proprio dove la supervisione umana tende a essere più bassa.

Non ci sono elementi per affermare che la quantization IQ3_XXS abbia causato direttamente la digressione. Il nesso causale non è dimostrato. Tuttavia, il trade-off è comune negli ambienti on-premise: per ottenere più token al secondo con hardware limitato si accettano compressioni aggressive. Queste compressioni non degradano solo la precisione numerica; possono alterare il modo in cui il modello gestisce i confini tra contesti. Il guadagno misurato in token al secondo non cattura la stabilità del ragionamento.

La VRAM resta il vincolo principale per chi valuta modelli locali. Un modello più grande offre potenzialmente maggiore capacità, ma richiede compressione per entrare nella scheda. Un modello più piccolo può girare con precisione maggiore, ma con meno parametri. Non c'è una scelta universale. Il caso di Lee Kuan Yew aggiunge un fattore al calcolo: la qualità dei passaggi intermedi. La velocità di generazione è una metrica visibile e facile da misurare. La coerenza del ragionamento è meno visibile e più difficile da monitorare, ma può determinare l'utilità reale del sistema.

Per chi calcola il TCO di un deployment on-premise, l'episodio sposta l'attenzione. Il costo non è solo l'hardware o l'energia. Include il tempo perso per diagnosticare anomalie di ragionamento, la validazione delle pipeline che consumano i log e il rischio di decisioni sbagliate a valle. Un modello più veloce può costare di più se produce più deviazioni. Il TCO non si misura solo in euro per token, ma in costo di supervisione e correzione. La compressione spinta può ridurre il costo di calcolo e aumentare quello di gestione.

Pipeline agentiche e stato interno: quando la deriva diventa comando

Nei framework agentici, i log di ragionamento non restano passivi. Diventano contesto per il passo successivo. Un agente può rileggere i propri pensieri, pianificare azioni, invocare strumenti e correggersi. Se in quei pensieri compare una biografia di Lee Kuan Yew durante un refactoring, il passo successivo può partire da un contesto contaminato. Non serve che la biografia venga ripetuta nell'output finale: basta che abbia spostato l'attenzione o alterato lo stato interno. La deriva semantica diventa un possibile comando implicito per la pipeline.

Questo cambia la natura del rischio. In un modello usato come chatbot, una digressione è visibile e si può ignorare. In una pipeline agentica, la digressione può influenzare la scelta di un tool, la lettura di un file o la decisione di fermarsi. Il log non è un semplice sottoprodotto; è memoria di lavoro. Se la memoria di lavoro perde coerenza, l'agente perde il filo. Il problema non è solo l'allucinazione: è l'instabilità della catena di ragionamento che guida le azioni.

Per chi costruisce sistemi self-hosted, la separazione tra task operativo e knowledge base latente diventa un requisito di progettazione. Non si può dare per scontato che il modello mantenga il contesto. Serve verificare i log, filtrare i passaggi anomali o isolare il reasoning dal contesto di esecuzione. Alcuni framework consentono di separare la generazione del piano dall'esecuzione, ma se il piano contiene frammenti estranei, la separazione non basta. La qualità del ragionamento influenza la qualità dell'azione.

La sovranità dei dati non protegge da questi guasti. Un sistema locale può essere pienamente sovrano eppure incoerente. La località garantisce il controllo dei dati, non la fedeltà al task. Chi valuta deployment on-premise deve aggiungere un criterio: la stabilità del ragionamento sotto compressione. Non si tratta di rinunciare alla velocità, ma di sapere che i token generati più rapidamente devono anche restare allineati con il compito. Altrimenti la pipeline accelera verso una direzione sbagliata.

Chi guadagna e chi perde nella scelta on-premise

Il caso divide gli utenti in base alle priorità. Chi usa LLM locali per generare codice o eseguire refactoring può guadagnare dalla velocità della quantization IQ3_XXS. Il miglioramento tra 2 e 3 volte rispetto a IQ4XS è un dato concreto che riduce i tempi di attesa. Per task singoli e supervisionati, una digressione occasionale può essere tollerabile: si guarda l'output, si corregge, si riparte. Il costo della deriva è basso se l'umano resta nel ciclo.

Per chi usa i log di ragionamento come fonte per audit o per pipeline agentiche, il framework cambia. La tracciabilità è un requisito, non un optional. Una biografia inattesa dentro un task di refactoring è un segnale di fragilità. Chi opera in settori regolamentati, dove ogni passaggio deve essere documentato, non può permettersi log che raccontano una storia diversa da quella eseguita. La scelta della quantization diventa una decisione di governance, non solo di performance.

Anche i fornitori di hardware e software leggono il segnale in modo diverso. Le GPU consumer come la RTX 5070 Ti rendono possibile l'inference locale di modelli grandi, ma spingono verso compressioni aggressive. Chi produce framework per on-premise può differenziarsi offrendo strumenti per monitorare la coerenza del ragionamento. Chi produce modelli può valutare quanto le varianti quantizzate mantengano la separazione dei contesti. Il mercato non è solo una gara di token al secondo: è anche una gara di affidabilità dei passaggi intermedi.

Alla fine, il trade-off è tra modelli più grandi quantizzati in modo aggressivo e modelli più piccoli a precisione maggiore. Nessuna delle due vie è migliore in assoluto. La prima offre più capacità a parità di hardware; la seconda offre una struttura più stabile. La decisione dipende dal tipo di carico, dal livello di supervisione e dalla criticità degli errori. L'episodio non fornisce una risposta, ma mostra che la velocità di generazione non può essere l'unico criterio di scelta.

Segnali da monitorare nei prossimi mesi

La battuta finale dell'utente su una futura specializzazione in psicopatologia degli LLM ha un fondo serio. I guasti dei modelli quantizzati non saranno solo bug di performance, ma comportamenti da classificare e correggere. Nei prossimi mesi, il segnale più importante da osservare è la nascita di strumenti per l'ispezione dei log di ragionamento. Non basta visualizzare i token: serve rilevare le deviazioni semantiche, le rotture di contesto e le interpolazioni non richieste.

Un secondo segnale riguarda la valutazione dei modelli quantizzati. Le metriche tradizionali misurano la qualità dell'output finale, non la coerenza del percorso. Serviranno benchmark che iniettino conoscenze irrilevanti e verifichino se il modello le tiene fuori dal contesto operativo. Questi test potrebbero diventare parte delle schede tecniche dei modelli, accanto alla velocità di generazione e al consumo di VRAM. Per chi valuta deployment on-premise, la stabilità del reasoning diventerà una metrica di primo livello.

Un terzo segnale è il consolidamento delle pipeline agentiche. Se i log di ragionamento diventano input per azioni, la loro qualità diventa critica. Framework e librerie dovranno gestire la possibilità di derive semantiche: filtrare i passaggi anomali, isolare i contesti, attivare controlli umani quando la coerenza scende sotto una soglia. L'automazione aumenterà la pressione sulla tracciabilità. Chi costruisce sistemi locali dovrà decidere quanto fidarsi dei pensieri intermedi e quanto verificarli.

Infine, la discussione sulla quantization si sposterà dal solo risparmio di memoria alla qualità del comportamento. I miglioramenti in token al secondo sono facili da mostrare e da vendere. La stabilità del ragionamento è più difficile da misurare, ma è quella che determina se un sistema resta governabile. AI-RADAR continuerà a osservare questi segnali nei propri framework su LLM on-premise: la scelta tra modelli più grandi quantizzati in modo aggressivo e modelli più piccoli a precisione maggiore non si riduce alla velocità di generazione. Il caso di Lee Kuan Yew è un promemoria: i token interni devono restare allineati con il compito.