Assistente AI locale | Memoria a grafo e voce

Che cosa serve perché un assistente basato su modelli linguistici sia davvero utile giorno dopo giorno, senza mandare nulla fuori dal computer su cui gira? Questo progetto di ricerca nasce per rispondere con un sistema funzionante, non con una presentazione.

È il laboratorio in cui provo le soluzioni che poi porto nei progetti per aziende e studi.

La maggior parte degli assistenti dimentica tutto a fine conversazione, oppure ricorda in un modo che nessuno può controllare. Qui la memoria è un grafo di conoscenza: persone, fatti e relazioni scritti in forma esplicita, con regole che ne verificano la coerenza.

Un’informazione nuova non entra subito tra le cose date per certe. Passa da una zona di quarantena, e diventa memoria stabile solo dopo una verifica. È lo stesso principio delle ontologie su cui avevo scritto la tesi nel 2013: allora era teoria, oggi è ciò che impedisce a un modello di ricordare con sicurezza una cosa sbagliata.

L’assistente si attiva con una parola chiave, trascrive il parlato, ragiona e risponde a voce. Detta così è una catena semplice. In pratica ogni anello aggiunge ritardo, e una conversazione con due secondi di silenzio tra una battuta e l’altra non è una conversazione.

Gran parte del lavoro è stato progettare i dettagli che fanno sembrare naturale lo scambio: poter interrompere, chiedere di ripetere, ricevere un cenno di assenso mentre il sistema sta ancora lavorando, non sentirsi leggere ad alta voce simboli e punteggiatura.

Tutto gira su hardware proprio, senza servizi esterni. Significa fare i conti con la memoria della scheda grafica, scegliere quale modello caricare per quale compito e prevedere una modalità ridotta per quando le risorse servono ad altro.

Significa anche accettare che un modello piccolo sbaglia in modo diverso da uno grande. Può dire «fatto» senza aver fatto nulla. La lezione più utile del progetto è che questi errori non si correggono chiedendo gentilmente al modello di stare attento: i controlli vanno scritti nel codice, fuori dal modello.

Ogni volta che esce un modello nuovo la domanda è la stessa: conviene cambiare? Per rispondere ho costruito un kit di prove ripetibili, basato su compiti reali, che confronta i modelli e segnala a parte le regressioni, cioè le cose che prima funzionavano e ora non più.

È il pezzo meno appariscente e forse il più prezioso: senza misure, la scelta di un modello è una questione di simpatia.

L’architettura e le decisioni sono mie; il codice nasce lavorando insieme ad assistenti AI di programmazione, con agenti diversi che scrivono, rileggono e verificano. È un modo di sviluppare che uso apertamente, e che richiede di saper spiegare il perché di ogni scelta: perché un grafo e non un semplice archivio di testi, perché la quarantena, perché certe guardie stanno nel codice.

Vuoi qualcosa di simile sui dati della tua azienda? Parliamone.