La biblioteca di Karpathy e il bias che nessuno controlla
Andrej Karpathy, uno dei pionieri più influenti nel campo dell'intelligenza artificiale moderna, ha recentemente pubblicato una proposta che sta circolando con forza tra i team di ingegneria e i leader di prodotto: un'architettura alternativa ai sistemi RAG (Retrieval-Augmented Generation) che lui chiama 'LLM Knowledge Base'. L'idea centrale è quella di sostituire i database vettoriali e i processi di recupero dinamico con una biblioteca di file markdown che un modello di linguaggio mantiene, aggiorna e organizza autonomamente nel tempo.
È una proposta tecnicamente pulita. Riduce la latenza, elimina la complessità degli indici vettoriali e genera un repository di conoscenza che diventa più coerente con l'uso. Per qualsiasi team che ha combattuto con pipeline RAG instabili, questo suona come un sollievo immediato.
Ma c'è una domanda che i team di ingegneria raramente pongono prima di implementare una nuova architettura, e che i direttori non pongono mai dopo: chi ha definito il corpus iniziale e quali criteri di rilevanza sono stati utilizzati.
Un'architettura elegante che nasconde una decisione politica
Una biblioteca di markdown gestita dall'IA non è neutrale per definizione. Ogni sistema di conoscenza inizia con un atto editoriale: qualcuno decide quali documenti entrano per primi, quali fonti sono autorizzate, quali argomenti meritano un proprio file e quali possono essere assorbiti all'interno di un altro. Questa decisione iniziale non è tecnica. È profondamente politica nel senso organizzativo del termine: riflette la gerarchia dei valori, i punti ciechi e le priorità di chi l'ha presa.
Ciò che fa la proposta di Karpathy è sofisticare e automatizzare il livello di aggiornamento, ma non risolve il problema di origine. Il modello imparerà a mantenere coerente ciò che era già distorto dall'inizio. Un file markdown che descrive "come funziona il cliente tipico" scritto da un team omogeneo di ingegneri a San Francisco codifica una visione particolare di chi è quel cliente, che lingua parla, quale dispositivo utilizza, quale livello di alfabetizzazione digitale ha e in quale fuso orario opera. Il modello lo aggiornerà diligentemente. Ciò che non farà è metterlo in discussione.
Questo non è un attacco a Karpathy né all'architettura in sé. È un diagnostico del divario che esiste tra l'eccellenza tecnica e la robustezza organizzativa. I team che implementano questa soluzione senza controllare il corpus fondativo stanno costruendo una memoria istituzionale che amplificherà le proprie limitazioni percezionali su larga scala, con la velocità che solo l'automazione consente.
L'ironia operativa è che quanto più efficiente è il sistema nel mantenere la biblioteca, tanto più velocemente consoliderà quei bias come verità di riferimento.
Il costo reale di una memoria aziendale omogenea
Esistono sufficienti prove per affermare che i team di gestione con bassa diversità di origine e prospettiva prendono decisioni con punti ciechi sistematici, non occasionali. McKinsey, nei suoi studi sulla diversità nei team di leadership, ha documentato correlazioni tra omogeneità e minore capacità di previsione nei mercati emergenti. Ma più rilevante per questa analisi è il meccanismo, non la statistica.
Quando un team omogeneo costruisce una base di conoscenza istituzionale — sia in markdown, in una wiki aziendale o nell'onboarding di nuovi dipendenti — ciò che produce è una codificazione del proprio modello mentale condiviso. Questo è esattamente l'opposto di ciò di cui un'organizzazione ha bisogno per rilevare le disruzioni. Le disruzioni provengono dai margini: dagli utenti che il prodotto non ha considerato, dai mercati che sembravano secondari, dalle esigenze che il team non ha mai avuto perché non le ha mai vissute.
Una biblioteca di conoscenza gestita dall'IA che parte da quel corpus omogeneo non solo non risolve il problema: lo istituzionalizza con uno strato di automazione che conferisce un'apparenza di obiettività. I documenti sono ben scritti, la struttura è coerente, il modello li aggiorna con consistenza. Tutto sembra rigore. Ma la domanda su quali mercati, quali utenti e quali casi d'uso siano stati esclusi dall'indice fin dal primo giorno rimane senza risposta.
Il rischio finanziario concreto è che l'organizzazione costruisca decisioni di prodotto, di espansione e di assistenza clienti su una base di conoscenza che esclude sistematicamente i segmenti con maggiore potenziale di crescita: precisamente quelli che l'azienda ancora non comprende bene.
Ciò che la proposta apre per chi sa leggerla
Sarebbe un errore ridurre questa analisi a un avvertimento. L'architettura descritta da Karpathy ha un potenziale organizzativo che va oltre l'ottimizzazione tecnica, a patto che i leader intervengano nel livello che gli ingegneri tendono a considerare risolto.
Una biblioteca di markdown mantenuta dall'IA è, in sostanza, una memoria istituzionale viva. Se il corpus fondativo viene costruito con deliberata diversità di prospettive — team di mercati emergenti, utenti di contesti a bassa larghezza di banda, operatori in lingue diverse dall'inglese, voci della periferia organizzativa e non solo del centro — allora il sistema ha la capacità di mantenere quella ricchezza aggiornata e coerente nel tempo. Questo è qualcosa che nessuna wiki aziendale tradizionale riesce a conseguire perché dipende dall'impegno volontario di coloro che hanno meno incentivi a documentare.
L'argomento commerciale è diretto: una base di conoscenza che rappresenta la complessità reale dei mercati in cui opera l'azienda prende decisioni migliori a un costo operativo inferiore rispetto a una che rappresenta solo la prospettiva del team fondatore. Non perché sia più giusta, ma perché ha una maggiore quantità di informazioni rilevanti integrate nella sua struttura.
L'intervento che il C-Level deve esigere prima di approvare qualsiasi implementazione di questa architettura è semplice e non richiede competenze tecniche: un inventario di chi ha contribuito ai documenti fondativi, quali geografie sono rappresentate, quali lingue sono presenti nel corpus di riferimento e quali tipi di utenti sono stati presi in considerazione nei casi d'uso documentati. Se quella lista è breve e omogenea, la decisione di investimento dovrebbe essere condizionata all'ampliamento prima di automatizzare.
Il tavolo di design come variabile di rischio
L'industria tende a valutare le architetture di IA in base a benchmark tecnici: latenza, accuratezza del recupero, coerenza semantica, costo per chiamata. Sono metriche legittime e necessarie. Ma esiste una variabile che non appare in nessun benchmark e che determina l'utilità reale del sistema a lungo termine: la composizione del team che ha preso le decisioni di design.
Un sistema RAG con alta precisione di recupero costruito su un corpus distorto recupera informazioni distorte con alta efficienza. Una biblioteca di markdown impeccabilmente organizzata che documenta solo l'esperienza di un sottogruppo di utenti fornisce risposte coerenti per quel sottogruppo e fallisce silenziosamente per il resto. Il fallimento silenzioso è il più pericoloso perché non genera avvisi: il sistema risponde, il team presume che funzioni, e l'organizzazione continua a prendere decisioni basate su informazioni incomplete senza saperlo.
La proposta di Karpathy merita attenzione tecnica e merita di essere implementata. Ma merita anche che i leader che la approvano comprendano che stanno prendendo una decisione sull'architettura della conoscenza istituzionale, non solo sull'infrastruttura software. Questa distinzione cambia chi deve essere presente quando viene definito il corpus iniziale e cambia i criteri con cui si valuta il successo del sistema sei mesi dopo il suo lancio.
I direttori che approvano questo investimento senza controllare la diversità delle prospettive al tavolo di design stanno pagando per una memoria istituzionale che ricorderà, con grande efficienza, esattamente ciò che il loro team più omogeneo già sapeva.
