Di cosa parlavamo l'ultima volta?

Fino al 19 maggio, l'assistente tratteneva tutto, tranne la conversazione in corso. Uno schermo che si spegne, una rete che salta, una deviazione in un'altra app, e gli ultimi minuti sparivano: «sì» non voleva più dire niente, e «di cosa parlavamo l'ultima volta?» riceveva «non trovo nessuna conversazione recente». I ricordi erano intatti. Quella giornata ha riparato la memoria breve: una sola conversazione per persona che sopravvive alle interruzioni, gli scambi passati letti così com'erano e datati, e un contesto che non si svuota più quando una delle sue fonti tossisce.

Due memorie, e una sola che reggeva

Quando si parla di memoria a proposito di questa app, si pensa alla memoria neuronale: le schede, i collegamenti tra loro, ciò che viene trattenuto per mesi. È la memoria lunga, e il 19 maggio funzionava bene. Una settimana prima, la ricerca aveva persino imparato a seguire i collegamenti tra i ricordi invece di fidarsi della sola somiglianza delle parole.

Ma esiste una seconda memoria, di cui nessuno parla perché tra esseri umani è data per scontata. È quella degli ultimi dieci minuti. Quando dici «sì» a qualcuno, lui sa a quale domanda. Quando dici «anche lui», sa di chi si tratta. Quella memoria non è riposta in una scheda: vive nel filo della conversazione, dal lato del server, sotto forma degli ultimi scambi che il modello rilegge a ogni turno.

E quella memoria breve si perdeva. Non dopo un'ora: dopo pochi secondi, appena il collegamento tra il telefono e il server si interrompeva, per qualunque ragione. Il risultato era strano da vivere. L'assistente ricordava il nome del dentista e la data di rinnovo di un passaporto, ma non la frase che aveva appena pronunciato. Dava l'impressione di una persona dalla memoria enciclopedica e dall'attenzione difettosa, e quell'impressione era peggiore che se la memoria lunga fosse stata vuota, perché contraddiceva ciò che si era appena sentito.

Primo pomeriggio: un direttore d'orchestra per connessione

Il telefono e il server si parlano attraverso un collegamento permanente, aperto all'avvio dell'app. Dal lato del server, un direttore d'orchestra riceve ciò che dice l'utente, fa girare il modello, esegue i suoi strumenti e rimanda la risposta. È lui a tenere la cronologia della conversazione.

Il difetto stava in una riga: quel direttore veniva costruito per ogni collegamento. Un collegamento, un direttore, una cronologia tutta sua. Finché il collegamento vive, tutto bene. Ma un collegamento muore molto più spesso di quanto si immagini. Lo schermo si spegne in tasca: il sistema taglia il collegamento per risparmiare batteria. Si esce di casa: il wifi molla, la rete mobile prende il posto, e il collegamento viene rifatto. Si risponde a un messaggio in un'altra app e si torna: collegamento rifatto. Ogni volta, l'app si riconnette da sola, in silenzio, senza mostrare nulla. E ogni volta, il server fabbricava un nuovo direttore, con una cronologia vuota, come se fosse appena entrato uno sconosciuto.

Il modello riceveva allora la memoria lunga, e nient'altro. Un «sì» lanciato dopo uno schermo spento diventava «sì a cosa?». Una richiesta formulata in due tempi, la prima metà prima dell'interruzione e la seconda dopo, non aveva più una prima metà. E quella stessa mattina, l'assistente aveva appena imparato che gli si poteva dire chi parla quando il telefono viene prestato a qualcun altro, senza che il proprietario cambi; quella dichiarazione viveva nella stessa cronologia, e svaniva con lei, col rischio di archiviare sotto il nome sbagliato ciò che la persona di passaggio aveva appena detto.

La correzione ha preso la forma di uno spostamento. C'è ormai un solo direttore d'orchestra per tutto il server, ed è lui a conservare tutte le conversazioni in corso, una per persona. Tutto ciò che dipendeva dal collegamento, lo schermo a cui inviare una scheda da mostrare, il modo di programmare un promemoria per quel preciso telefono, gli viene consegnato al momento di ogni turno invece di essere sigillato nella sua costruzione. Così, quando un collegamento viene rifatto, ritrova la conversazione che aveva lasciato: stessa cronologia, stesso parlante dichiarato, stesso filo. La regola è semplice da enunciare: una riconnessione entro la mezz'ora successiva all'ultimo scambio riprende la stessa conversazione; oltre, se ne apre una nuova.

Quello spostamento ne imponeva un secondo. Fino ad allora, la chiusura del collegamento serviva da segnale di fine: era in quel momento che la conversazione veniva riassunta e archiviata nella memoria lunga. Se la conversazione deve sopravvivere alla chiusura, quel segnale non vale più nulla. Il server passa quindi in rassegna, ogni cinque minuti, le conversazioni il cui proprietario tace da più di mezz'ora, le archivia e le toglie dalla sua memoria viva. Nulla si accumula, e una conversazione abbandonata a metà finisce comunque nel database, invece di perdersi al riavvio successivo.

Tardo pomeriggio: «non trovo nessuna conversazione recente»

Il filo non si spezzava più. Restava una domanda, posta quello stesso giorno a voce, che riceveva una risposta sbagliata: «di cosa parlavamo l'ultima volta?».

Il materiale però esisteva. Quando una conversazione viene archiviata, ne viene scritto un riassunto nella memoria lunga, come un ricordo tra gli altri. Il problema stava in quel «tra gli altri». Prima di ogni turno, il server assembla per il modello una panoramica di ciò che la memoria sa: i ricordi di lavoro, ciò che è stato menzionato negli ultimi giorni, un campione del resto. I riassunti delle conversazioni passate vi scivolavano dentro, nella lista dei fatti, senza etichetta. Il modello vedeva «weekend in Sicilia, Claire, date da confermare» tra il codice del cancello e il compleanno di Paul, e non aveva modo di sapere che quella riga raccontava la conversazione di dodici minuti prima e non un progetto annotato un giorno qualunque. Alla domanda «di cosa parlavamo», cercava una conversazione, non ne riconosceva nessuna, e rispondeva di non trovarne di recenti. La risposta era sotto i suoi occhi, travestita da fatto.

La prima correzione ha dato a quei riassunti una sezione tutta loro, in testa alla panoramica, con ciò che li distingue da un fatto: una data relativa, «12 min fa», e la lunghezza dello scambio, «4 turni». E un'istruzione, nella stessa sezione: quando l'utente chiede di cosa parlavamo, se si ricorda, o dice di aver dimenticato cosa si diceva, appoggiarsi prima a quei riassunti, prima di qualsiasi ricerca nelle schede. Gli stessi riassunti sono stati tolti dalle altre liste, per non comparire due volte sotto due etichette.

Tre minuti dopo: leggere la conversazione stessa

La sezione ha retto tre minuti prima di essere rifatta, perché poggiava su un compromesso che non aveva ragione di esistere.

Il riassunto scritto all'archiviazione è stato pensato per la ricerca per somiglianza di significato: corto, denso, calcolato per essere ritrovato più tardi a partire da un indizio. È un indice, non un verbale. Ma le conversazioni stesse vengono conservate, turno per turno, in una tabella del database. Per rispondere a «di cosa parlavamo», l'indice è una deviazione: la materia è lì accanto, intera.

La panoramica legge quindi ormai quella tabella direttamente. Presenta le ultime conversazioni, dalla più recente alla più vecchia, ciascuna col suo riassunto, la sua età e il suo numero di turni. E per la più recente, spacchetta gli ultimi scambi così come sono avvenuti, «Tu: mi fai una lista per il weekend?», «Io: ecco, ho annotato tutto», con gli estratti lunghi accorciati. Il modello non deve più indovinare di cosa parlava la sessione precedente: ce l'ha davanti, parola per parola, e può rispondere col suo contenuto invece che con una parafrasi.

C'è una lezione di metodo in quei tre minuti. Quando il dato esiste in forma grezza, è meglio mostrarlo che mostrare ciò che se n'è derivato. Il riassunto conserva il suo ruolo, quello di essere ritrovato per somiglianza tra qualche settimana; per la domanda di oggi, la trascrizione è la risposta giusta.

Prima serata: una fonte che cade non svuota più tutto

L'ultimo difetto della giornata si vedeva solo ogni tanto, ed è questo che lo rendeva difficile da acchiappare.

La panoramica di memoria consegnata al modello è assemblata a partire da più fonti: le conversazioni recenti, i ricordi di lavoro, ciò che è stato menzionato negli ultimi giorni, il campione del resto e le regole personali. Vengono interrogate in parallelo, per non sommare i loro tempi di attesa. Ma lo erano con una regola del tutto o niente: se una sola delle richieste falliva, un ritardo dal lato del database, un rifiuto passeggero, l'insieme veniva abbandonato e il modello riceveva una panoramica vuota. Rispondeva allora, in perfetta buona fede, di non ricordare. Non aveva letteralmente nulla.

La regola è diventata «tutto ciò che risponde viene tenuto». Ogni fonte viene attesa separatamente; quella che fallisce viene annotata nei log e sostituita da una lista vuota, le altre passano. Un contesto privato di una fonte vale più di un contesto assente, e di gran lunga: il modello che ha le conversazioni recenti ma non il campione del resto risponde quasi come al solito; quello che non ha nulla risponde come uno sconosciuto.

Due misure hanno accompagnato questo cambiamento. La prima riguarda il modello stesso: capitava che il servizio remoto restituisse una risposta vuota alla prima chiamata di un turno, un sovraccarico travestito da successo. L'utente sentiva allora la frase di riserva, quella che annuncia un problema tecnico, prevista una settimana prima per i guasti veri. Quella prima chiamata viene ora ritentata una volta, dopo una breve pausa, prima di rinunciare. Una volta sola, e solo la prima: nel mezzo di una catena di strumenti, ripetere una chiamata significherebbe eseguire due volte ciò che è già stato fatto, creare due schede, programmare due promemoria.

La seconda misura è una traccia. A ogni turno, il server scrive nei suoi log ciò che ha davvero consegnato al modello: quante conversazioni recenti, quanti ricordi di ogni livello, quante regole, e la dimensione dell'insieme. Prima, quando qualcuno segnalava «ha dimenticato», non c'era modo di sapere se il modello avesse letto male una memoria piena o letto bene una memoria vuota. Sono due difetti senza rapporto che producono lo stesso sintomo, e non si corregge ciò che non si riesce a distinguere.

Cosa ha insegnato la giornata

Tre difetti che non avevano nulla in comune hanno prodotto, per settimane, una sola e stessa lamentela: «non si ricorda quello che abbiamo appena detto». Una cronologia legata a un collegamento fragile. Verbali di conversazione travestiti da fatti. Una memoria che si svuotava del tutto per una fonte in ritardo. Nessuno di questi difetti toccava i ricordi in sé; tutti toccavano il modo di consegnarli al modello al momento giusto.

È questo che rende la memoria breve così particolare. Un buco nella memoria lunga passa spesso inosservato: non si nota ciò che non si chiede. Un buco nella memoria breve si vede in un secondo, perché contraddice ciò che si è appena vissuto. Una persona che dimentica un appuntamento di tre mesi fa è distratta; una persona che dimentica la frase precedente non stava ascoltando. L'assistente dava la seconda impressione quando aveva il primo difetto, e nemmeno del tutto.

Dal 19 maggio, una conversazione ripresa dopo uno schermo spento, un tragitto o una deviazione in un'altra app è la stessa conversazione. «Di cosa parlavamo l'ultima volta?» riceve la risposta, con le parole dell'ultima volta. E quando manca qualcosa, si può sapere perché. La memoria lunga fa sì che si possa tornare tra mesi; la memoria breve, che si possa tornare tra un minuto. Servivano entrambe perché parlare con l'app somigliasse a parlare con qualcuno.