Karpathy deelt de ‘LLM Knowledge Base’-architectuur die RAG omzeilt met een evoluerende markdown-bibliotheek die wordt onderhouden door AI

AI-vibe-codeerders hebben nog een reden om dankbaar te zijn Andrej Karpathyde munten van het concept.

De voormalig directeur van AI bij Tesla en mede-oprichter van OpenAI, die nu onlangs zijn eigen onafhankelijke AI-project leidt gepubliceerd op X waarin een “LLM Knowledge Bases” wordt beschreven aanpak die hij gebruikt om verschillende onderwerpen van onderzoeksbelang te behandelen.

Door een aanhoudend, bijgehouden LLM-bestand van zijn projecten op te bouwen, pakt Karpathy de kernfrustrering van de ‘staatloze’ AI-ontwikkeling aan: het gevreesde resetten van de contextgrenzen.

Zoals iedereen met een vibratiecode kan beamen, voelt het bereiken van een bestedingslimiet of het beëindigen van een sessie vaak als een lobotomie voor uw project. Je wordt gedwongen waardevolle tokens (en tijd) te besteden aan het reconstrueren van de context voor de AI, in de hoop dat deze de architecturale nuances die je zojuist hebt vastgesteld, zal “onthouden”.

Karpathy stelt iets eenvoudigers, losser en rommeliger en eleganters voor dan de typische bedrijfsoplossing met een vectordatabase en RAG-pijplijn.

In plaats daarvan schetst hij een systeem waarbij de LLM zelf optreedt als een fulltime ‘onderzoeksbibliothecaris’, waarbij hij actief Markdown-bestanden (.md) compileert, lintt en koppelt, het meest LLM-vriendelijke en compacte gegevensformaat.

Door een aanzienlijk deel van zijn ‘tokenflow’ te richten op de manipulatie van gestructureerde kennis in plaats van op standaardcode, heeft Karpathy een blauwdruk gecreëerd voor de volgende fase van het ‘tweede brein’ – een brein dat zelfherstellend, controleerbaar en volledig door mensen leesbaar is.

Naast RAG

De afgelopen drie jaar was het dominante paradigma voor het verlenen van toegang aan LLM’s tot bedrijfseigen gegevens Retrieval-augmented generatie (RAG).

In een standaard RAG-opstelling worden documenten in willekeurige “brokken” geknipt, omgezet in wiskundige vectoren (inbedding) en opgeslagen in een gespecialiseerde database.

Wanneer een gebruiker een vraag stelt, voert het systeem een ​​‘zoekopdracht naar gelijkenis’ uit om de meest relevante stukjes te vinden en voegt deze toe aan de aanpak van LLM.Karpathy, die hij ‘ LLM-kennisbankenverwerpt de complexiteit van vectordatabases voor middelgrote datasets.

In plaats daarvan vertrouwt het op het toenemende vermogen van LLM om over gestructureerde tekst te redeneren.

De systeemarchitectuur zoals gevisualiseerd door de X-gebruiker @himanshu onderdeel van de bredere reacties op Karpathy’s post, verloopt in drie verschillende fasen:

1. Gegevens laden: Grondstoffen (onderzoekspapers, GitHub-repository’s, datasets en webartikelen) worden gedumpt in een raw/ map. Karpathy-gebruiker Obsidiaan webclipper om webinhoud naar Markdown te converteren (.md)-bestanden, waardoor vloeiende afbeeldingen lokaal worden opgeslagen, zodat LLM ernaar kan verwijzen via visiefuncties.

2. De compilatiestap: Dit is de kerninnovatie. In plaats van de bestanden eenvoudigweg te indexeren, “compileert” LLM ze. Het leest ruwe gegevens en schrijft een gestructureerde wiki. Dit omvat het genereren van samenvattingen, het identificeren van sleutelconcepten, het schrijven van artikelen in encyclopediestijl en – cruciaal – het creëren ervan backlinks tussen verwante ideeën.

3. Actief onderhoud (pluis): Het systeem is niet statisch. Karpathy beschrijft het uitvoeren van “sanity checks” of “linting” -passen waarbij LLM de wiki scant op inconsistenties, ontbrekende gegevens of nieuwe verbindingen. Als lid van de gemeenschap Charlie Wargnier merkte op: “Het fungeert als een levende AI-kennisbasis die zichzelf daadwerkelijk geneest.”

Door Markdown-bestanden te behandelen als de “bron van de waarheid”, vermijdt Karpathy het “black box”-probleem van vectorinbedding. Elke claim van AI is terug te voeren op een specifieke claim .md bestand dat een mens kan lezen, bewerken of verwijderen.

Gevolgen voor het bedrijf

Hoewel de opzet van Karpathy momenteel wordt omschreven als een ‘hacky verzameling scripts’, zijn de gevolgen voor het bedrijf onmiddellijk.

Als ondernemer Vamshi Reddy (@tammireddy) merkte in reactie op op het bericht: “Elk bedrijf heeft een onbewerkte directory. Niemand heeft deze ooit samengesteld. Het is het product.”

Karpathy was het daarmee eens en suggereerde dat deze methode een categorie “ongelooflijk nieuw product” vertegenwoordigt.

De meeste bedrijven ‘verdrinken’ momenteel in ongestructureerde gegevens – slappe logs, interne wiki’s en pdf-rapporten waar niemand tijd voor heeft om ze te synthetiseren.

Een bedrijfslaag in “Karpathy-stijl” zou niet alleen deze documenten doorzoeken; het zou actief een “Bedrijfsbijbel” schrijven die in realtime wordt bijgewerkt.

Als AI-docent en nieuwsbriefschrijver Ole Lehmann zette het op X: “Ik denk dat degene die dit voor normale mensen verpakt, op iets enorms zit. Een app die synchroniseert met de tools die je al gebruikt, je bladwijzers, je later lezen-app, je podcast-app, je opgeslagen discussies.”

Eugen Alpeza, mede-oprichter en CEO van AI enterprise agent builder en orkestratie-startup Edra, merkte in een X-post op dat: “De sprong van persoonlijke onderzoekswiki naar bedrijfsactiviteiten is waar het wreed wordt. Duizenden werknemers, miljoenen records, tribale kennis die zichzelf tegenspreekt binnen teams. Er is zelfs ruimte voor een nieuw product, en we bouwen het in eigen huis.”

Terwijl de gemeenschap het ‘Karpathy-patroon’ verkent, verschuift de focus al van persoonlijk onderzoek naar orkestratie door meerdere agenten.

Een recente architectonische afdeling van @jumperzoprichter van het AI-agentcreatieplatform Tweede stuurmanillustreert deze ontwikkeling via een “Swarm Knowledge Base” die de wiki-workflow schaalt naar een systeem met 10 agenten dat wordt beheerd via OpenClaw.

De kernuitdaging van een zwerm met meerdere agenten – waarbij een hallucinatie het collectieve geheugen kan versterken en ‘infecteren’ – wordt hier opgelost door een speciale ‘Quality Gate’.

Met behulp van het Hermes-model (opgeleid door Nous Research voor gestructureerde evaluatie) als onafhankelijke supervisor, wordt elke conceptversie van een artikel beoordeeld en gevalideerd voordat deze wordt gepromoveerd naar de “live” wiki.

Dit systeem creëert een “samengestelde lus”: agenten dumpen ruwe uitvoer, de compiler organiseert ze, Hermes valideert de waarheid en geverifieerde briefings worden aan het begin van elke sessie teruggestuurd naar agenten. Dit zorgt ervoor dat de zwerm nooit “stil wakker wordt”, maar in plaats daarvan elke taak begint met een gefilterde, zeer integriteitsbriefing van alles wat het collectief heeft geleerd

Schaalbaarheid en prestaties

Een veelgehoorde kritiek op niet-vectorbenaderingen is schaalbaarheid. Karpathy merkt echter op dat op een schaal van ~100 artikelen en ~400.000 woorden het vermogen van LLM om door samenvattingen en indexbestanden te navigeren ruim voldoende is.

Voor een afdelingswiki of een persoonlijk onderzoeksproject introduceert de “fancy RAG”-infrastructuur vaak meer latentie en “ophaalruis” dan het oplost.

Technische podcasts Lex Fridman (@lexfridman) bevestigde dat hij een vergelijkbare opstelling gebruikt en een laag dynamische visualisatie toevoegt:

“Ik krijg het vaak voor elkaar om dynamische html (met js) te genereren waarmee ik gegevens kan sorteren/filteren en interactief aan visualisaties kan sleutelen. Een ander nuttig ding is dat ik het systeem een ​​tijdelijke gerichte mini-kennisbank laat genereren… die ik vervolgens in een LLM laad voor interactie in spraakmodus tijdens een lange hardloopsessie van 11 tot 15 kilometer.”

Dit ‘efemere wiki’-concept suggereert een toekomst waarin gebruikers niet alleen maar ‘chatten’ met een AI; ze brengen een team van agenten voort om een ​​op maat gemaakte onderzoeksomgeving voor een specifieke taak te bouwen, die vervolgens wordt opgeheven wanneer het rapport wordt geschreven.

Licenties en de ‘file-over-app’-filosofie

Technisch gezien is de methodologie van Karpathy gebouwd op een open standaard (Markdown), maar bekeken door een eigen, maar toch uitbreidbare lens (app voor het maken van aantekeningen en het organiseren van bestanden). Obsidiaan).

• Prijsverlaging (.md): Door voor Markdown te kiezen, zorgt Karpathy ervoor dat zijn kennisbank niet gebonden is aan een bepaalde leverancier. Het is toekomstbestendig; als Obsidian verdwijnt, blijven de bestanden leesbaar voor elke teksteditor.

• Obsidiaan: Hoewel Obsidian een propriëtaire applicatie is, sluiten de ‘local-first’-filosofie en de EULA (die gratis persoonlijk gebruik toestaat en een licentie vereist voor commercieel gebruik) aan bij het verlangen van de ontwikkelaar naar datasoevereiniteit.

• De “Vibe-gecodeerde” tools: De zoekmachines en CLI-tools die Karpathy noemt, zijn aangepaste scripts (waarschijnlijk gebaseerd op Python) die de kloof overbruggen tussen LLM en het lokale bestandssysteem.

Deze ‘file-over-app’-filosofie vormt een directe uitdaging voor SaaS-zware modellen zoals Notion of Google Docs. In het Karpathy-model is de gebruiker eigenaar van de gegevens en is de AI slechts een zeer geavanceerde editor die de bestanden “bezoekt” om werk te doen.

Bibliothecaris versus zoekmachine

De AI-gemeenschap heeft gereageerd met een mix van technische validatie en ‘vibe-coding’-enthousiasme. Het debat concentreert zich op de vraag of de industrie Vector DB’s te veel heeft geïndexeerd voor problemen die fundamenteel te maken hebben met structuur, en niet alleen met gelijkenis.

Jason Paul Michaels (@SpaceWelder314), een lasser die Claude gebruikte, herhaalde het gevoel dat eenvoudiger gereedschap vaak robuuster is:

“Geen vectordatabase. Geen insluitingen… Alleen markdown, FTS5 en grep… Elke bugfix… wordt geïndexeerd. Kennis wordt samengesteld.”

De belangrijkste lof kwam echter van Steph Ango (@Kepano), mede-maker van Obsidian, die een concept benadrukte met de naam ‘Contamination Mitigation’.

Hij stelde voor dat gebruikers hun persoonlijke “kluis” schoon zouden moeten houden en de agenten in een “rommelige kluis” zouden moeten laten spelen, waarbij de nuttige artefacten pas zouden worden overgebracht nadat de agentgerichte workflow ze heeft gedestilleerd.

Welke oplossing is geschikt voor uw zakelijke codeerprojecten?

De “Vector DB”-aanpak is als een enorm, ongeorganiseerd magazijn met een zeer snelle vorkheftruckchauffeur. Je kunt van alles vinden, maar je weet niet waarom het daar ligt of hoe het zich verhoudt tot de pallet ernaast. Karpathy’s “Markdown Wiki” is als een samengestelde bibliotheek met een hoofdbibliothecaris die voortdurend nieuwe boeken schrijft om de oude uit te leggen.

De volgende fase

Karpathy’s laatste verkenning wijst in de richting van de uiteindelijke bestemming voor deze gegevens: het genereren en verfijnen van synthetische gegevens.

Naarmate de wiki groeit en de gegevens ‘schoonder’ worden door voortdurende LLM-linting, wordt het de perfecte trainingsset.

In plaats van dat LLM de wiki alleen maar in zijn “contextvenster” leest, kan de gebruiker uiteindelijk een kleiner, efficiënter model op de wiki zelf verfijnen. Dit zou de LLM in staat stellen de persoonlijke kennisbasis van de onderzoeker op zijn eigen schaal te ‘kennen’, waardoor een persoonlijk onderzoeksproject in wezen wordt omgezet in een op maat gemaakte, particuliere intelligentie.

Kortom: Karpathy heeft niet alleen een script gedeeld; hij heeft een filosofie gedeeld. Door LLM te behandelen als een actieve agent die zijn eigen geheugen in stand houdt, heeft hij de beperkingen van ‘one-shot’ AI-interacties omzeild.

Voor de individuele onderzoeker betekent dit het einde van ‘de vergeten boekenlegger’.

Voor het bedrijf betekent dit de transitie van een ‘raw/data lake’ naar een ‘gecompileerd kennismiddel’. Zoals Karpathy zelf samenvatte: “Je schrijft of bewerkt de wiki zelden handmatig; dat is het domein van de LLM.” We betreden het tijdperk van het autonome archief.