Documenti e conoscenza

Il problema, detto con precisione

Il problema non è «abbiamo troppi documenti». Quello è un lamento, non un problema, e nessuno strumento lo risolve. Il problema vero è più stretto e più fastidioso: la risposta esiste già, qualcuno l'ha scritta, e non si trova.

La scena tipica dura venti minuti. Una persona cerca una procedura, non la trova, chiede a un collega. Il collega risponde a memoria. La risposta è quella di due anni fa, perché nel frattempo il documento aggiornato è finito in una cartella con un nome diverso. Nessuno se ne accorge.

Il costo non è il tempo di ricerca: quello si misura, sembra piccolo e nessuno lo autorizza a diventare un progetto. Il costo vero è altrove.

• Risposte diverse alla stessa domanda, a seconda di chi la riceve. Verso un cliente, questo è un problema di credibilità prima che di efficienza.
• Lavoro rifatto perché non si sapeva che qualcuno l'aveva già fatto.
• Conoscenza che esce dalla porta insieme alla persona che sapeva dove guardare — e che non era documentata da nessuna parte, perché sapere dove guardare non è un documento.

Vale la pena notare che sono tutti costi che non compaiono in nessun bilancio. È il motivo per cui questo problema resta aperto per anni in organizzazioni che funzionano benissimo su tutto il resto.

Perché la ricerca per parole non basta

La ricerca tradizionale trova i documenti che contengono le parole che hai scritto. Funziona benissimo quando conosci già il vocabolario del documento, e fallisce esattamente quando ne avresti bisogno: quando non lo conosci.

Chi cerca scrive «posso rimborsare il taxi». Il documento si intitola «Policy trasferte e note spese» e dentro parla di «spostamenti urbani». Nessuna parola in comune, nessun risultato.

La ricerca semantica risolve proprio questo, ed è la stessa cosa vista nella tappa 07 del percorso: ogni pezzo di testo diventa una posizione in uno spazio, e i testi che parlano di cose simili finiscono vicini. Cercare per significato è, alla lettera, cercare i punti vicini.

Il che introduce subito il limite da tenere in mente per tutto il resto di questa pagina, e che è la ragione dei quattro errori più avanti: la vicinanza misura la somiglianza d'uso, non la correttezza.

Come funziona davvero

Il meccanismo si chiama recupero e generazione, spesso RAG. Detto senza sigle, sono due momenti distinti: uno che si fa una volta sola, e uno che si ripete a ogni domanda.

Due cose meritano attenzione in questo schema, perché sono quelle che distinguono un sistema progettato da uno assemblato.

Il modello non «legge l'archivio». Vede cinque o dieci pezzi di testo, selezionati da un altro pezzo di software. Se la selezione è sbagliata, la risposta sarà sbagliata anche con il modello migliore del mondo — e sarà sbagliata con sicurezza, perché il modello non ha modo di sapere che gli manca qualcosa.

Il modello non attinge a ciò che ricorda. O meglio: non dovrebbe. Questa è una scelta progettuale precisa, e la ragione tecnica è quella della tappa 09 — ciò che un modello sa e ciò che gli sembra plausibile stanno nello stesso posto e hanno la stessa forma. La memoria interna non è consultabile né correggibile; un archivio documentale sì.

I quattro modi in cui sbaglia

Sbaglia in modi specifici e prevedibili. Conoscerli in anticipo è la differenza fra un collaudo serio e una brutta sorpresa in produzione.

Il primo e il terzo hanno la stessa radice, ed è quella della tappa 07: la vicinanza registra come un testo è scritto, non se è vero o se è in vigore. Una clausola abrogata e la sua sostituta sono quasi identiche agli occhi di un indice semantico, perché parlano della stessa cosa con le stesse parole. È esattamente ciò che rende quel tipo di errore difficile da notare: la risposta sbagliata è plausibile, pertinente e ben scritta.

Il quarto è il più insidioso perché non ha sintomi. Un sistema che non trova niente e lo dice è un sistema che funziona; uno che non trova niente e inventa una procedura verosimile è indistinguibile, dall'esterno, da uno che ha trovato la risposta giusta.

Come si progetta

Sei decisioni, nell'ordine in cui vanno prese. Nessuna riguarda la scelta del modello, che è la meno importante e la più facile da cambiare in seguito.

• Il perimetro. Quali documenti entrano, e soprattutto quali no. Un perimetro stretto e curato batte sistematicamente un perimetro largo e disordinato: è la conseguenza pratica della tappa 08, dove l'attenzione è una torta da spartire e ogni pagina irrilevante ne toglie a quelle che contano.
• I permessi. È la decisione che viene dimenticata più spesso ed è l'unica che può produrre un incidente vero. Il sistema deve poter rispondere solo con documenti che chi sta chiedendo avrebbe comunque il diritto di leggere. Questo va risolto nel recupero, non chiedendo al modello di comportarsi bene: un modello a cui è stato mostrato un documento riservato lo ha già visto.
• La preparazione. Eliminare i duplicati, dichiarare le versioni, marcare i documenti superati e togliere dall'indice quelli non più validi. Sembra lavoro noioso e preliminare: è invece il fattore che determina la qualità del risultato più di qualunque altra scelta tecnica.
• Il taglio. Spezzare per unità di senso — un articolo, una procedura, una sezione — e non ogni mille caratteri. Dove regola ed eccezione stanno lontane, farle viaggiare insieme.
• Le citazioni obbligatorie. Ogni affermazione deve portare il documento da cui viene, in modo che chi legge possa aprirlo. Non è una funzione accessoria: è ciò che rende la risposta verificabile invece che credibile, ed è la differenza fra uno strumento professionale e un oracolo.
• Il comportamento in assenza di risposta. Va deciso e collaudato esplicitamente: quando i pezzi recuperati non sono pertinenti, il sistema deve dirlo. È l'unica difesa contro il quarto errore.

Come si collauda

Qui vale integralmente il metodo della tappa 10: si giudica sulla partita, non sul muro. In concreto significa una cosa sola — le domande di collaudo si scrivono prima, e si raccolgono dalle persone che quel lavoro lo fanno, non da chi costruisce il sistema.

Trenta o cinquanta domande reali bastano. Vanno divise in tre gruppi, e i tre gruppi non si guardano insieme.

Il terzo gruppo è quello che di solito manca, e la ragione per cui manca è comprensibile: nessuno pensa a collaudare ciò che il sistema non deve fare. Ma un sistema che inventa quando non sa è peggiore di nessun sistema, perché sposta l'errore da «non lo trovo» a «me l'ha detto lo strumento».

Vanno aggiunte due prove che non sono domande e che scoprono i due errori più silenziosi. La prima: mettere nell'archivio un documento superato e la sua versione aggiornata, e verificare quale delle due viene citata. La seconda: fare la stessa domanda con due utenze con permessi diversi, e verificare che le risposte differiscano di conseguenza.

Quando non conviene

La parte che manca in quasi tutte le presentazioni. Ci sono situazioni in cui questo strumento è la risposta sbagliata, e riconoscerle in anticipo vale più di qualunque ottimizzazione.

• Quando i documenti sono pochi. Sotto una certa soglia, una cartella ordinata con nomi sensati risolve lo stesso problema, si mantiene da sola e non sbaglia mai.
• Quando la risposta richiede un calcolo. «Quante ore abbiamo consuntivato sul progetto X» non è una domanda documentale: è una interrogazione su dati strutturati. Un modello linguistico ci proverà comunque, e produrrà un numero verosimile — che è il modo peggiore possibile di sbagliare.
• Quando i documenti cambiano di continuo. Se l'archivio si aggiorna più in fretta di quanto si riesca a re-indicizzarlo e a rifare il collaudo, il sistema sarà stabilmente in ritardo sulla realtà, e nessuno saprà dire di quanto.
• Quando sbagliare costa molto e nessuno verificherà. Se la risposta finisce direttamente davanti a un cliente o dentro un atto senza che una persona competente la controlli, il problema non è il sistema: è il processo intorno.