Karpathy condivide l’architettura “LLM Information Base” che ignora RAG con una libreria di ribasso in evoluzione gestita dall’intelligenza artificiale

I programmatori di vibrazioni AI hanno ancora un altro motivo per ringraziare Andrej Karpathyil coniatore del termine.

L’ex direttore dell’intelligenza artificiale di Tesla e co-fondatore di OpenAI, ora gestisce di recente il proprio progetto di intelligenza artificiale indipendente pubblicato su X che descrive una “base di conoscenza LLM” approccio che sta utilizzando per gestire vari argomenti di interesse di ricerca.

Costruendo un registro persistente dei suoi progetti, mantenuto da LLM, Karpathy sta risolvendo la frustrazione principale dello sviluppo dell’intelligenza artificiale “senza stato”: il temuto ripristino dei limiti del contesto.

Come può testimoniare chiunque abbia Vibe Code, raggiungere un limite di utilizzo o terminare una sessione spesso sembra una lobotomia per il tuo progetto. Sei costretto a spendere token (e tempo) preziosi per ricostruire il contesto per l’IA, sperando che “ricordi” le sfumature architettoniche che hai appena stabilito.

Karpathy propone qualcosa di più semplice, più vago e disordinatamente elegante rispetto alla tipica soluzione aziendale composta da un database vettoriale e una pipeline RAG.

Invece, delinea un sistema in cui lo stesso LLM agisce come un “bibliotecario di ricerca” a tempo pieno, compilando, collegando e collegando attivamente file Markdown (.md), il formato di dati più compatto e compatibile con LLM.

Deviando una parte significativa della sua “produzione di token” nella manipolazione della conoscenza strutturata piuttosto che nel codice commonplace, Karpathy ha fatto emergere un progetto per la fase successiva del “Secondo Cervello”, uno che è auto-riparante, verificabile e interamente leggibile dall’uomo.

Oltre il RAG

Negli ultimi tre anni, il paradigma dominante per fornire agli LLM l’accesso ai dati proprietari è stato Generazione aumentata di recupero (RAG).

In una configurazione RAG commonplace, i documenti vengono suddivisi in “pezzi” arbitrari, convertiti in vettori matematici (incorporamenti) e archiviati in un database specializzato.

Quando un utente pone una domanda, il sistema esegue una “ricerca di similarità” per trovare i blocchi più rilevanti e inserirli nell’approccio di LLM.Karpathy, che lui chiama Basi di conoscenza LLMrifiuta la complessità dei database vettoriali per set di dati di medie dimensioni.

Si basa invece sulla crescente capacità del LLM di ragionare sul testo strutturato.

L’architettura del sistema, come visualizzata dall’utente X @himanshu in parte delle reazioni più ampie al submit di Karpathy, funziona in tre fasi distinte:

1. Importazione dati: Le materie prime (documenti di ricerca, repository GitHub, set di dati e articoli net) vengono scaricate in un uncooked/ listing. Karpathy utilizza il Tagliaragnatele di ossidiana per convertire i contenuti net in Markdown (.md), garantendo che anche le immagini vengano archiviate localmente in modo che LLM possa farvi riferimento tramite funzionalità di visione.

2. La fase di compilazione: Questa è l’innovazione fondamentale. Invece di limitarsi a indicizzare i file, LLM li “compila”. Legge i dati grezzi e scrive un wiki strutturato. Ciò embrace la generazione di riepiloghi, l’identificazione di concetti chiave, la creazione di articoli in stile enciclopedico e, soprattutto, la creazione backlink tra idee correlate.

3. Manutenzione attiva (Linting): Il sistema non è statico. Karpathy descrive l’esecuzione di “controlli di integrità” o passaggi di “linting” in cui LLM esegue la scansione del wiki per incoerenze, dati mancanti o nuove connessioni. Come membro della comunità Charly Wargnier ha osservato: “Agisce come una base di conoscenza vivente dell’intelligenza artificiale che in realtà guarisce se stessa”.

Trattando i file Markdown come la “fonte della verità”, Karpathy evita il problema della “scatola nera” degli incorporamenti di vettori. Ogni affermazione fatta dall’IA può essere ricondotta advert uno specifico .md file che un essere umano può leggere, modificare o eliminare.

Implicazioni per l’impresa

Sebbene la configurazione di Karpathy sia attualmente descritta come una “raccolta di script hackerati”, le implicazioni per l’azienda sono fast.

Come imprenditore Vamshi Reddy (@tammireddy) ha notato in risposta all’annuncio: “Ogni azienda ha una listing uncooked/. Nessuno l’ha mai compilata. Questo è il prodotto.”

Karpathy è d’accordo, suggerendo che questa metodologia rappresenta una categoria di “nuovo prodotto incredibile”.

La maggior parte delle aziende attualmente “annega” in dati non strutturati: registri Slack, wiki interni e report PDF che nessuno ha il tempo di sintetizzare.

Un livello aziendale “in stile Karpathy” non si limiterebbe a cercare questi documenti; creerebbe attivamente una “Bibbia aziendale” che si aggiorna in tempo reale.

Come educatore di intelligenza artificiale e autore di publication Ole Lehmann l’ha messo su X: “Penso che chiunque abbia confezionato questo pacchetto per le persone normali sia seduto su qualcosa di enorme. un’app che si sincronizza con gli strumenti che già usi, i tuoi segnalibri, la tua app leggi più tardi, la tua app podcast, i tuoi thread salvati.”

Eugen Alpeza, co-fondatore e CEO di Edra, costruttore di agenti aziendali di intelligenza artificiale e startup di orchestrazione, ho notato in un post di X che: “Il passaggio dal wiki di ricerca personale alle operazioni aziendali è il momento in cui le cose diventano brutali. Migliaia di dipendenti, milioni di report, conoscenze tribali che si contraddicono tra i staff. In effetti, c’è spazio per un nuovo prodotto e lo stiamo costruendo nell’azienda.”

Mentre la comunità esplora il “modello Karpathy”, l’attenzione si sta già spostando dalla ricerca personale all’orchestrazione multi-agente.

Una recente rottura architettonica di @jumperzfondatore della piattaforma di creazione di agenti AI Secondo compagnoillustra questa evoluzione attraverso una “Swarm Information Base” che adatta il flusso di lavoro wiki a un sistema a ten agenti gestito tramite OpenClaw.

La sfida principale di uno sciame multi-agente, in cui un’allucinazione può aggravare e “infettare” la memoria collettiva, viene affrontata qui da un “Porta di qualità” dedicato.

Utilizzando il modello Hermes (addestrato da Nous Analysis per la valutazione strutturata) come supervisore indipendente, ogni bozza di articolo viene valutata e convalidata prima di essere promossa al wiki “stay”.

Questo sistema crea un “loop composto”: gli agenti scaricano i risultati grezzi, il compilatore li organizza, Hermes convalida la verità e i briefing verificati vengono restituiti agli agenti all’inizio di ogni sessione. Ciò garantisce che lo sciame non si “svegli mai vuoto”, ma inizi invece ogni attività con un briefing filtrato e advert alta integrità di tutto ciò che il collettivo ha imparato

Scalabilità e prestazioni

Una critica comune agli approcci non vettoriali è la scalabilità. Tuttavia, Karpathy osserva che su una scala di ~ 100 articoli e ~ 400.000 parole, la capacità del LLM di navigare tramite riepiloghi e file di indice è più che sufficiente.

Per un wiki dipartimentale o un progetto di ricerca personale, l’infrastruttura “fantasiosa RAG” spesso introduce più latenza e “rumore di recupero” di quanto ne risolva.

Podcaster tecnologico Lex Fridman (@lexfridman) confermato che utilizza una configurazione simile, aggiungendo un livello di visualizzazione dinamica:

“Spesso lo faccio generare HTML dinamico (con js) che mi consente di ordinare/filtrare i dati e di armeggiare con le visualizzazioni in modo interattivo. Un’altra cosa utile è che faccio generare al sistema una mini-base di conoscenza focalizzata temporanea… che poi carico in un LLM per l’interazione in modalità vocale su un lungo percorso di 7-10 miglia.”

Questo concetto di “wiki effimero” suggerisce un futuro in cui gli utenti non si limitano a “chattare” con un’intelligenza artificiale; generano un staff di agenti per costruire un ambiente di ricerca personalizzato per un compito specifico, che poi si dissolve una volta scritto il rapporto.

Licensing e filosofia ‘file-over-app’

Tecnicamente, la metodologia di Karpathy è costruita su uno commonplace aperto (Markdown) ma vista attraverso una lente proprietaria ma estensibile (app per prendere appunti e organizzare file Ossidiana).

• Ribasso (.md): Scegliendo Markdown, Karpathy garantisce che la sua base di conoscenza non sia vincolata a un fornitore specifico. È a prova di futuro; se Obsidian scompare, i file rimangono leggibili da qualsiasi editor di testo.

• Ossidiana: Sebbene Obsidian sia un’applicazione proprietaria, la sua filosofia “local-first” e l’EULA (che consente l’uso personale gratuito e richiede una licenza per uso commerciale) sono in linea con il desiderio dello sviluppatore di sovranità dei dati.

• Gli strumenti “Codificati in Vibe”: I motori di ricerca e gli strumenti CLI menzionati da Karpathy sono script personalizzati, probabilmente basati su Python, che colmano il divario tra LLM e il file system locale.

Questa filosofia “file-over-app” è una sfida diretta ai modelli SaaS come Notion o Google Docs. Nel modello Karpathy, l’utente possiede i dati e l’intelligenza artificiale è semplicemente un editor altamente sofisticato che “visita” i file per eseguire il lavoro.

Bibliotecario contro motore di ricerca

La comunità dell’intelligenza artificiale ha reagito con un combine di convalida tecnica ed entusiasmo per la “codifica delle vibrazioni”. Il dibattito è incentrato sulla questione se il settore abbia sovraindicizzato i DB vettoriali per problemi che riguardano fondamentalmente la struttura, non solo la somiglianza.

Jason Paul Michaels (@SpaceWelder314), un saldatore che utilizza Claude, ha fatto eco alla convinzione secondo cui gli strumenti più semplici sono spesso più robusti:

“Nessun database vettoriale. Nessun incorporamento… Solo markdown, FTS5 e grep… Ogni correzione di bug… viene indicizzata. La conoscenza si accumula.”

Tuttavia, gli elogi più significativi sono arrivati ​​da Steph Ango (@Kepano), co-creatore di Obsidian, che ha evidenziato un concetto chiamato “Mitigazione della contaminazione”.

Ha suggerito che gli utenti dovrebbero mantenere pulito il loro “caveau” personale e lasciare che gli agenti giochino in un “caveau disordinato”, portando con sé gli artefatti utili solo una volta che il flusso di lavoro rivolto agli agenti li ha distillati.

Quale soluzione è adatta ai tuoi progetti di codifica dell’atmosfera aziendale?

L’approccio “Vector DB” è come un enorme magazzino non organizzato con un carrello elevatore molto veloce. Puoi trovare qualsiasi cosa, ma non sai perché è lì o come si collega al pallet accanto. “Markdown Wiki” di Karpathy è come una biblioteca curata con un capo bibliotecario che scrive costantemente nuovi libri per spiegare quelli vecchi.

La fase successiva

L’esplorazione finale di Karpathy punta verso la destinazione finale di questi dati: la generazione e il perfezionamento dei dati sintetici.

Man mano che il wiki cresce e i dati diventano più “puri” attraverso il continuo linting LLM, diventa il set di formazione perfetto.

Invece di limitarsi a leggere il wiki nella sua “finestra di contesto”, l’utente può eventualmente mettere a punto un modello più piccolo ed efficiente sul wiki stesso. Ciò consentirebbe al LLM di “conoscere” la base di conoscenza personale del ricercatore secondo i propri pesi, trasformando essenzialmente un progetto di ricerca personale in un’intelligence privata e personalizzata.

In conclusione: Karpathy non ha semplicemente condiviso una sceneggiatura; ha condiviso una filosofia. Trattando l’LLM come un agente attivo che mantiene la propria memoria, ha aggirato i limiti delle interazioni IA “one-shot”.

Per il singolo ricercatore significa la effective del “segnalibro dimenticato”.

Per l’impresa, ciò significa la transizione da un “lago di dati grezzi” a un “asset di conoscenza compilato”. Come ha riassunto lo stesso Karpathy: “Raramente scrivi o modifichi il wiki manualmente; è il dominio del LLM”. Stiamo entrando nell’period dell’archivio autonomo.