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 te bedanken Andrej Karpathyde bedenker van de term.

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

Door een aanhoudend, door LLM bijgehouden dossier van zijn projecten op te bouwen, lost Karpathy de kernfrustratie van de ‘staatloze’ AI-ontwikkeling op: de gevreesde reset van de contextlimiet.

Zoals iedereen die vibratiecode heeft kan beamen, voelt het bereiken van een gebruikslimiet 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, “onthoudt”.

Karpathy stelt iets eenvoudigers, losser en rommeliger elegants voor dan de typische bedrijfsoplossing van 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 onderling koppelt, het meest LLM-vriendelijke en compacte gegevensformaat.

Door een aanzienlijk deel van zijn ‘token-doorvoer’ te besteden aan het manipuleren van gestructureerde kennis in plaats van standaardcode, heeft Karpathy een blauwdruk voor de volgende fase van het ‘Tweede Brein’ naar voren gebracht – een die zelfherstellend, controleerbaar en volledig voor mensen leesbaar is.

Verder dan RAG

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

In een standaard RAG-opstelling worden documenten in willekeurige ‘brokken’ gehakt, 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 delen te vinden en voert deze in de aanpak van LLM.Karpathy in, die hij ‘ LLM-kennisbankenverwerpt de complexiteit van vectordatabases voor middelgrote datasets.

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

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

1. Gegevensopname: Grondstoffen (onderzoekspapers, GitHub-repository’s, datasets en webartikelen) worden gedumpt in een raw/ map. Karpathy maakt gebruik van de Obsidiaan webclipper om webinhoud om te zetten in Markdown (.md)-bestanden, waardoor zelfs afbeeldingen lokaal worden opgeslagen, zodat de LLM ernaar kan verwijzen via vision-mogelijkheden.

2. De compilatiestap: Dit is de kerninnovatie. In plaats van de bestanden alleen maar te indexeren, “compileert” de LLM ze. Het leest de onbewerkte 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 van backlinks tussen verwante ideeën.

3. Actief onderhoud (pluizen): Het systeem is niet statisch. Karpathy beschrijft het uitvoeren van “gezondheidscontroles” of “linting”-passen waarbij de LLM de wiki scant op inconsistenties, ontbrekende gegevens of nieuwe verbindingen. Als gemeenschapslid Charly 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 de AI is terug te voeren op een specifieke claim .md bestand dat een mens kan lezen, bewerken of verwijderen.

Gevolgen voor de onderneming

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

Als ondernemer Vamshi Reddy (@tammireddy) merkte dit op als reactie op de aankondiging: “Elk bedrijf heeft een raw/ directory. Niemand heeft die ooit samengesteld. Dat is het product.”

Karpathy was het daarmee eens en suggereerde dat deze methodologie een categorie van “ongelooflijke nieuwe producten” vertegenwoordigt.

De meeste bedrijven ‘verdrinken’ momenteel in ongestructureerde gegevens: Slack-logs, interne wiki’s en pdf-rapporten waar niemand de tijd voor heeft om deze 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 nieuwsbriefauteur Ole Lehmann zette het op X: “Ik denk dat degene die dit voor normale mensen verpakt, op iets enorms zit. Eén 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 een persoonlijke onderzoekswiki naar bedrijfsactiviteiten is waar het wreed wordt. Duizenden werknemers, miljoenen records, stamkennis die zichzelf tegenspreekt binnen teams. Er is inderdaad ruimte voor een nieuw product en we bouwen het in de onderneming.”

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

Een recente architectonische inzinking door @jumperzoprichter van het AI-agentcreatieplatform Tweede maatillustreert deze evolutie 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 één hallucinatie het collectieve geheugen kan verergeren en ‘infecteren’ – wordt hier aangepakt door een speciale ‘Quality Gate’.

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

Dit systeem creëert een “samengestelde lus”: agenten dumpen onbewerkte uitvoer, de compiler organiseert ze, Hermes valideert de waarheid en geverifieerde briefings worden aan het begin van elke sessie teruggekoppeld 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 de 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 podcaster Lex Fridman (@lexfridman) bevestigde dat hij een vergelijkbare opstelling gebruikt, waarbij hij een laag dynamische visualisatie toevoegt:

“Ik laat het vaak dynamische html genereren (met js) 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 ​​aangepaste onderzoeksomgeving voor een specifieke taak te bouwen, die vervolgens verdwijnt zodra het rapport is 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 gepatenteerde maar 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 specifieke 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 de 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 uit te voeren.

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… Gewoon markdown, FTS5 en grep… Elke bugfix… wordt geïndexeerd. De 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 suggereerde dat gebruikers hun persoonlijke ‘kluis’ schoon zouden moeten houden en de agenten in een ‘rommelige kluis’ zouden moeten laten spelen, waarbij ze pas de nuttige artefacten zouden overbrengen zodra de agentgerichte workflow ze heeft gedestilleerd.

Welke oplossing is geschikt voor uw ondernemingsgerichte 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 van deze gegevens: het genereren en verfijnen van synthetische gegevens.

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

In plaats van dat de 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 om de persoonlijke kennisbasis van de onderzoeker in zijn eigen gewicht 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 de LLM te behandelen als een actieve agent die zijn eigen geheugen onderhoudt, heeft hij de beperkingen van ‘one-shot’ AI-interacties omzeild.

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

Voor de onderneming betekent dit de overgang van een ‘ruw/datameer’ naar een ‘gecompileerd kennismiddel’. Zoals Karpathy zelf samenvatte: “Je schrijft of bewerkt de wiki zelden handmatig; het is het domein van de LLM.” We betreden het tijdperk van het autonome archief.