Come funziona realmente una memoria IA persistente

I pesi di un modello sono congelati. Parlargli non gli insegna nulla, e chiudere la scheda non glielo fa dimenticare — non c'è mai stato un posto in cui quel ricordo potesse andare. Ciò che lei vive come un assistente che si ricorda di lei è una disposizione molto più prosaica: del testo è stato salvato da qualche parte, e prima che il modello rispondesse un programma è andato a trovare i pezzi pertinenti e li ha incollati davanti a lui.

È tutto qui il trucco. Ma la qualità di una memoria IA è quasi interamente la qualità della fase di recupero, ed è lì che i prodotti di questa categoria differiscono enormemente pur descrivendosi in modo identico.

La finestra di contesto non è una memoria

I due termini vengono confusi di continuo, allora: la finestra di contesto è la scrivania di lavoro del modello. Tutto ciò che può prendere in considerazione adesso, in questo turno. È ampia nei modelli attuali, ed è cancellata integralmente tra una conversazione e l'altra.

La memoria è un archivio che sopravvive alla conversazione. Il legame tra i due è che la memoria *alimenta* la finestra — selettivamente.

E deve essere selettiva, perché l'alternativa ingenua fallisce sia sul costo sia sull'accuratezza. Se avesse un anno di appunti e li riversasse tutti a ogni turno, pagherebbe quei token a ogni singolo messaggio, e il modello farebbe peggio, non meglio: un dettaglio pertinente sepolto in cento pagine di dettagli irrilevanti si diluisce. Il recupero esiste perché meno, scelto bene, batte di più.

Archiviare: la parte che sembra banale e non lo è

Due decisioni si prendono al momento della scrittura, ed entrambe la perseguitano dopo.

Che cosa conservare. Salvare trascrizioni intere costa poco ed è quasi inutile: finisce per cercare in un pagliaio che ha costruito lei stesso. Salvare fatti distillati è molto più recuperabile, ma richiede un giudizio su che cosa contava, e qualsiasi estrazione automatica a volte scarterà proprio la cosa a cui teneva. La maggior parte dei prodotti si colloca da qualche parte su questo asse, e la loro posizione predice come ci si sentirà dopo sei mesi meglio di qualsiasi elenco di funzionalità.

Come ritagliarlo. Il testo entra sotto forma di frammenti, e il frammento è l'unità che verrà recuperata. Troppo grande, e un risultato si trascina dietro tre argomenti scollegati. Troppo piccolo, e la frase torna priva del contesto che la rendeva significativa. Non c'è una risposta giusta, solo una risposta tarata.

Trovare: gli embedding e il loro angolo cieco

Un secondo modello — un modello di embedding, non quello con cui chatta — trasforma ogni frammento in un vettore di qualche centinaio fino a qualche migliaio di numeri. I testi di significato simile atterrano vicini tra loro. La sua domanda subisce lo stesso trattamento, e la ricerca diventa geometria: restituire i frammenti più vicini.

Fatto in modo esaustivo è lento, quindi i sistemi reali usano un indice approssimato — HNSW è quello comune, un grafo navigabile che arriva a una buona risposta senza visitare ogni punto. Scambia un po' di richiamo per ordini di grandezza di velocità, e in pgvector è un indice di una riga.

Ecco l'angolo cieco che nessuno cita nella presentazione. La ricerca semantica è *soltanto* semantica. Chieda un numero di fattura esatto, un cognome, una versione di libreria, un nome di variabile — i casi in cui conosce la stringa precisa — e la similarità vettoriale le porgerà volentieri cinque cose che *parlano* di quell'argomento e non quella che contiene la stringa.

Ecco perché un indice per parole chiave, BM25 o la ricerca full-text di un database, non è il vecchio approccio che i vettori avrebbero sostituito. È la metà per cui i vettori sono scarsi.

Ricerca ibrida e reranking

Una pipeline di recupero seria esegue entrambe le ricerche e le fonde. La fusione standard è la reciprocal rank fusion: ogni risultato è valutato in base al suo *rango* in ciascuna lista anziché a un punteggio grezzo, il che aggira il fatto che una distanza coseno e un punteggio BM25 non sono misurati nella stessa unità e non possono essere sommati.

Poi arriva la fase che produce gran parte della qualità visibile, e che molti prodotti saltano perché costa calcolo. La fusione le dà forse trenta candidati. Un reranker cross-encoder legge la domanda e ciascun candidato *insieme*, e valuta quanto bene quello risponda a questa. È molto più accurato che confrontare due vettori costruiti indipendentemente, e molto troppo lento per essere eseguito su tutto l'archivio — ed è esattamente per questo che interviene per ultimo, su una lista breve.

Un avvertimento se lavora in più di una lingua. Entrambe le fasi dipendono dai modelli, e parecchi modelli di embedding e di reranking sono pensati prima di tutto per l'inglese. Una pipeline che ottiene buoni punteggi in inglese può degradarsi silenziosamente in francese o in tedesco, e lei lo vivrà come «ha dimenticato», non come «il reranker è stato addestrato sulla distribuzione sbagliata». Se non lavora in inglese, verifichi che i modelli siano realmente multilingue — multilingual-e5 è una di queste famiglie.

Quando abbiamo fatto passare la nostra pipeline dalla semplice ricerca vettoriale alla fusione ibrida più un cross-encoder multilingue, il mean reciprocal rank sul nostro insieme di valutazione è migliorato del 139%. Prenda quel dato per ciò che è: la nostra misura, sui nostri dati, con il nostro ritaglio. Dice che il passo vale la pena; non è un numero che può aspettarsi di riprodurre su un altro corpus.

I quattro modi in cui questo fallisce

1. Non è mai stato archiviato. Il fallimento più frequente, e di gran lunga. Nulla nella catena di recupero può trovare un fatto che non è mai stato scritto, e l'estrazione automatica si lascia sfuggire delle cose.
2. Nessuna soglia. Se il sistema restituisce sempre i suoi cinque migliori risultati, allora quando non esiste nulla di pertinente ne restituisce cinque irrilevanti — e il modello, accomodante, li intreccia. Un pavimento di similarità che non restituisce nulla è una funzionalità, e la sua assenza è il motivo per cui certi assistenti ricordano male con sicurezza.
3. Contraddizioni scadute. Ha cambiato città; il fatto vecchio e quello nuovo sono entrambi nell'archivio, entrambi recuperabili. Senza ponderazione per recenza né sostituzione esplicita, il modello può scegliere l'uno o l'altro.
4. Il problema dell'ago. Gli identificatori esatti, in un sistema puramente vettoriale. Vedi sopra.

Che cosa chiedere a un prodotto di memoria

Cinque domande, e ognuna ha una risposta fattuale che un fornitore le dà o schiva:

• Ricerca per parole chiave oltre al vettoriale, o solo vettoriale?
• C'è una fase di reranking, e con quale modello?
• C'è una soglia di pertinenza sotto la quale non restituisce nulla?
• I modelli di embedding e di reranking sono multilingue, e valutati nella mia lingua?
• Posso vedere, modificare e cancellare un singolo ricordo — o l'archivio è opaco per me?

L'ultima non riguarda la qualità del recupero, ma è quella che le importerà per prima, la prima volta che qualcosa di sbagliato verrà ricordato sul suo conto.

Pryzm esegue una fusione ibrida con un reranker cross-encoder multilingue e una soglia di pertinenza, su PostgreSQL con indici HNSW, e ogni ricordo è visibile e cancellabile individualmente. Come si collocano le alternative è nel nostro confronto.