Přibližně 100 článků. Zhruba 400 tisíc slov. Nula embeddingů a nula vektorových databází. Tolik má Andrej Karpathy ve své osobní znalostní bázi, o které od 3. dubna 2026 píše na síti X jako o funkční alternativě ke všemu, co průmysl poslední tři roky staví kolem RAG pipeline.
Karpathy – spoluzakladatel OpenAI, bývalý ředitel AI v Tesle a aktuálně nezávislý výzkumník – svůj systém nenazývá revolucí. Říká mu “LLM Knowledge Bases”. Během několika hodin ale komunita jeho popis převedla do architektonických diagramů, prvních implementací a široké debaty o tom, jestli se celý segment vektorových databází neorientoval špatným směrem. Následující analýza rozebírá, co Karpathy popsal, jak to technicky funguje, kde přístup obstojí a kde naráží na limity.
Druhý mozek, který se sám píše
Koncept “second brain”, druhého mozku v podobě osobní digitální knihovny, sleduje produktivní svět už minimálně deset let. Tiago Forte si na něm postavil kariéru, Notion z něj udělal produktovou kategorii a Obsidian získal jádro uživatelů přesně kolem této myšlenky. Karpathyho posun je v tom, kdo tuto knihovnu píše.
Dosud ji psal člověk. Teď ji píše LLM.
Karpathy byl vědecký ředitel pro AI v Tesle, odkud odešel v roce 2022, pak se krátce vrátil do OpenAI a od loňského roku pracuje nezávisle. V komunitě ho znají i laici, protože razil termín “vibe coding” – způsob práce, kdy vývojář víc diriguje AI, než ťuká do klávesnice. Jeho starší tutoriál k backpropagation patří dodnes mezi nejčtenější na světě. To, co publikuje, není akademická studie ani produktové oznámení. Je to záznam toho, jak konkrétně řeší konkrétní problémy ve vlastní praxi. Právě proto jeho popis působí přesvědčivěji než produktová prezentace.
Lobotomie relace
Problém, který celý Karpathyho systém řeší, zná každý, kdo s AI pracuje soustavně. Relace skončí. Limit tokenů se naplní. Server se přes noc restartuje. A při dalším spuštění model netuší, co se v relaci budovalo včera, předevčírem ani minulý týden.
Carl Franzen, který Karpathyho příspěvek zpracoval pro VentureBeat, to pojmenoval přiléhavě: každý reset je “lobotomie projektu”. Ztrácejí se architektonická rozhodnutí, pojmenování proměnných, omezení i jednou vyřešené kompromisy. Vysvětlení se musí budovat znovu. Výsledkem jsou vyšší náklady na tokeny, čas i pozornost.
Průmysl na tento problém odpovídá hlavně dvěma způsoby. Buď rozšiřuje kontextové okno (současné modely zvládnou 200 tisíc až milion tokenů, ale cena a latence rostou), nebo staví RAG pipeline nad vektorovou databází. Karpathy přichází se třetí cestou, která se od obou zásadně liší.
Kde RAG skřípe
Retrieval-Augmented Generation je od roku 2023 dominantní způsob, jak dát LLM přístup k proprietárním datům. Princip je přímočarý. Dokumenty se rozsekají na úseky, typicky o velikosti 256 až 1024 tokenů. Každý úsek se přepočítá na embedding, vektor reálných čísel, který má reprezentovat význam textu. Vektory putují do specializované databáze. Při dotazu se na vektor převede i samotná otázka a systém v embeddingovém prostoru najde nejbližší sousedy. Jejich obsah pak dostane LLM jako kontext k promptu.
Na papíře elegantní řešení. V praxi to drhne ve třech bodech.
Problém první je chunking. Rozdělení textu je arbitrární operace a klíčová informace může skončit rozpůlená mezi dvěma úseky tak, že ani jeden sám o sobě nedává smysl. Druhý problém se jmenuje embedding drift – dva sémanticky opačné texty se mohou v prostoru ukázat jako podobné, protože embeddingový model zachytil formu, ne význam. Model pak odpoví přesvědčivě, ale na základě fragmentu, který mu problém popisuje špatně.
Třetí bod je pro podniky nejpalčivější. Audit. Když model odpoví chybně, nejde dohledat proč. Byl to vybraný chunk? Práh podobnosti? Prompt engineering? Samotný model? Odpověď vyžaduje přístup do celé pipeline a know-how, které většina firemních týmů typicky nemá.
Karpathy tuto námitku relativizuje. Pro osobní škálu i pro týmové znalostní báze o desítkách až stovkách dokumentů podle něj RAG řeší problém, který ve skutečnosti není o podobnosti.
Je o struktuře.
Tři fáze: sběr, kompilace, kontrola
Architekturu popsal Karpathy textem, ale uživatel X @himanshu ji během několika hodin převedl do diagramu, který komunita rychle adoptovala. Tři fáze, tři různé role LLM.
Sběr (ingest). Surová data – výzkumné studie, repozitáře z GitHubu, webové články, vlastní poznámky – míří do adresáře raw/. Karpathy pro webový obsah používá Obsidian Web Clipper; nástroj, který přímo z prohlížeče převádí stránky do Markdownu a obrázky ukládá lokálně, aby na ně LLM mohl později odkazovat přes své vizuální schopnosti.
Kompilace. Právě zde leží jádro architektury. LLM soubory v raw/ nenapojuje na index, jak by to udělal vyhledávač. Čte je a píše z nich wiki. Generuje shrnutí. Identifikuje klíčové pojmy. Skládá encyklopedické záznamy. A vytváří zpětné odkazy mezi souvisejícími myšlenkami – bod, na kterém celý systém stojí. Model se z role čtenáře posouvá do role autora.
Kontrola (linting). Wiki se v čase rozpadá. Přibývají články, staré zastarávají, protichůdné závěry se hromadí. Karpathy proto spouští pravidelné “health check” průchody, při kterých LLM prochází celou bázi, hledá nesrovnalosti a mezery a doplňuje chybějící propojení. Charly Wargnier to v komunitě popsal stručně: “Funguje to jako živá znalostní báze, která se skutečně sama léčí.”
Výsledkem této architektury je systém, ve kterém má každé tvrzení modelu jasnou stopu k jednomu konkrétnímu .md souboru. Souboru, který lze otevřít v libovolném textovém editoru, přečíst, opravit – nebo smazat.
Knihovna, ne sklad
Komunita přišla s přímým srovnáním, kolem kterého se debata soustředila nejvíc:
| Vlastnost | RAG / vektorová databáze | Markdown wiki (Karpathy) |
|---|---|---|
| Datový formát | Neprůhledné vektory | Čitelný Markdown |
| Logika | Sémantická podobnost | Explicitní propojení přes zpětné odkazy |
| Auditovatelnost | Nízká, “černá skříňka” | Vysoká, přímá dohledatelnost |
| Obnova | Statická, vyžaduje reindexaci | Aktivní, wiki se sama ošetřuje |
| Ideální rozsah | Miliony dokumentů | 100 až 10 000 vysoce signálních dokumentů |
Karpathy to ilustruje obrazem, který se ve vláknu hojně cituje. Vektorová databáze je masivní neuspořádaný sklad, ve kterém pracuje velmi rychlý řidič vysokozdvižného vozíku. Najde potřebný balík během sekundy, ale nevysvětlí, proč leží právě tam a jak souvisí s vedlejší řadou. Markdown wiki je naproti tomu kurátorská knihovna, kde hlavní knihovník průběžně dopisuje další knihy, aby vyložil ty staré.
Na první pohled to připomíná návrat do roku 2005, kdy si technická komunita stavěla vlastní wiki v Tiddlywiki nebo DokuWiki. Při bližším čtení je ale patrný zásadní rozdíl. Tím knihovníkem není člověk, ale LLM, který se ke své práci vrací v pravidelných cyklech a bez lidské intervence.
Čísla, která Karpathy uvádí, jsou přitom střízlivá. Pro škálu kolem 100 článků a 400 000 slov je schopnost LLM procházet shrnutí a index plně dostačující. Nad tuto hranici sofistikovaná RAG infrastruktura podle něj přidává víc latence a vyhledávacího šumu, než kolik problémů skutečně řeší. U milionu dokumentů to platit nebude, tam RAG zůstává jediným rozumným řešením. Pro zhruba 90 procent případů ve výzkumu nebo ve středně velké firmě tak vyvstává otázka, zda je embeddingový server vůbec potřeba.
Od raw/ adresáře k firemní bibli
Karpathy sám popisuje svůj aktuální setup jako “narychlo slátanou sbírku skriptů”. To je startovní bod pro jednotlivce. Pro podnik je situace o dva řády složitější.
Podnikatel Vamshi Reddy (@tammireddy) tuto příležitost pojmenoval větou, kterou pak Karpathy veřejně potvrdil: “Every business has a raw/ directory. Nobody’s ever compiled it. That’s the product.” Volně přeloženo: každá firma má adresář se surovými daty – Slack logy, interní wiki, PDF reporty, e-mailová vlákna – a nikdo ho nikdy nezkompiloval do znalostního aktiva. A právě v tom leží nenaplněná produktová kategorie.
Ole Lehmann, AI edukátor a autor newsletteru, formuloval konzumní perspektivu ještě přímočařeji: “Ten, kdo tohle zabalí pro běžné uživatele, sedí na něčem obřím. Jedna aplikace, která se synchronizuje s nástroji, co už používáte. S záložkami, read-later appkou, podcast appkou, uloženými vlákny.”
Eugen Alpeza, spoluzakladatel a CEO startupu Edra zaměřeného na enterprise AI agenty, přinesl realističtější pohled: “Skok z osobní výzkumné wiki do podnikových operací je místo, kde to začíná být brutální. Tisíce zaměstnanců, miliony záznamů, kmenové znalosti, které si navzájem protiřečí napříč týmy. Prostor pro nový produkt tam je a my ho stavíme.”
Mezi prvními, kdo tuto kategorii začali formalizovat, je @jumperz, zakladatel platformy Secondmate. Jeho architektura “Swarm Knowledge Base” škáluje Karpathyho wiki workflow na systém deseti agentů, kteří běží pod orchestrátorem OpenClaw. Hlavní riziko multi-agentního roje je přitom jasné: jediná halucinace se může kaskádou šířit do kolektivní paměti a tiše ji zkontaminovat. @jumperz to řeší vyhrazenou kontrolní branou. Model Hermes od Nous Research, natrénovaný pro strukturovaná hodnocení, slouží jako nezávislý supervizor. Každý návrh článku prochází jeho kontrolou a bodovým hodnocením dřív, než se dostane do živé wiki.
Vzniká tak “Compound Loop”. Agenti produkují surové výstupy, kompilátor je třídí, Hermes je verifikuje a ověřené instrukce se pak vracejí agentům na začátku každé další relace. Výsledkem je roj, který nevstupuje do dalšího běhu s prázdným kontextem. Startuje s filtrovaným shrnutím toho, co kolektiv doposud zjistil.
Ne všichni chtějí vektory
Karpathyho přístup zarezonoval i mimo obvyklou AI komunitu. Jason Paul Michaels (@SpaceWelder314), svářeč, který si nad Claudem staví interní znalostní systém pro svou dílnu, to shrnul pragmaticky: “No vector database. No embeddings. Just markdown, FTS5, and grep. Každá oprava chyby se zaindexuje. Znalosti se kupí.” Pro něj, pro Lex Fridmana i pro komunitu kolem Obsidianu to potvrzuje trend, který průmysl poslední dva roky spíš přehlížel. Jednodušší nástroje často stačí a pracují spolehlivěji než navrstvené pipeliny.
Steph Ango (@Kepano), spolutvůrce Obsidianu, přidal do debaty pojem “contamination mitigation”, tedy omezování kontaminace. Doporučuje držet osobní archiv čistý a nechat agenty pracovat v odděleném “messy vaultu”, tedy v bázi s nižší důvěryhodností. Teprve ověřené artefakty se pak přesouvají do hlavní sbírky. Pro firmy je to návod, jak oddělit vrstvy důvěryhodnosti dat, aniž by se při experimentování prolomila kvalita provozní báze.
Lex Fridman přidal vrstvu, která ukazuje další směr využití. Nechává si LLM generovat dynamické HTML s JavaScriptem pro interaktivní filtrování a třídění dat z wiki. Navíc používá koncept “ephemeral wiki”, dočasné znalostní báze vytvořené pro jediný úkol, která se po splnění rozpustí. Spouští si ji při dlouhých bězích sedm až deset mil v hlasovém režimu přes sluchátka. Nezvyklý scénář použití. Z hlediska rozhraní a práce s dočasným kontextem ale pozoruhodný.
Při prvním čtení může architektura působit jako další vrstva komplexity vedle RAG. Při bližším pohledu ale směřuje opačným směrem: k menší komplexitě, ne k větší.
File-over-app
Volba Markdownu je programová. Karpathy si vědomě vybírá otevřený standard bez vázanosti na dodavatele. Jestli Obsidian, aplikace, kterou pro organizaci souborů používá, jednoho dne zmizí z trhu, jeho .md soubory zůstanou čitelné v čemkoliv od VS Code po Vim nebo iOS Poznámky. Data zůstávají uživateli. AI zde funguje jako sofistikovaný editor, který nad soubory pracuje, aniž by si je přivlastnil.
Tato “file-over-app” filozofie je přímou výzvou SaaS modelům typu Notion nebo Google Docs, kde data de facto leží v cizím prostředí a migrace z nich znamená export s kompromisy. V Karpathyho modelu je vztah opačný. AI slouží souborům, ne naopak.
V kontextu posledních pěti let jde zároveň o zřetelný odklon od produktové rétoriky, která uživatele tlačila do uzavřených ekosystémů.
Kam to směřuje
Karpathy na konci svého vlákna naznačil, kam tato infrastruktura míří. Jak wiki roste a data se přes pravidelný linting očišťují, stává se z ní strukturovaná trénovací sada. Místo čtení v kontextovém okně se otevírá fine-tuning. Doladění menšího, efektivnějšího modelu přímo na vlastní wiki. Výsledkem je model, který konkrétní znalostní bázi nezná přes retrieval, ale nese ji přímo ve svých vahách. Výzkumný projekt tak může získat podobu soukromé inteligence.
Sám Karpathy to pro VentureBeat shrnul do jedné věty, která vystihuje podstatu modelu: “Wiki prakticky nikdy nepíšete ani neupravujete manuálně. To je doména LLM.”
Pro jednotlivce to znamená konec zapomenutých záložek. Pro firmu přechod od “raw/ data lake”, tedy neutříděné digitální haldy, ke “compiled knowledge asset”, zkompilovanému znalostnímu aktivu, které žije a aktualizuje se samo.
Tato architektura pravděpodobně nepřekoná RAG ve všech kategoriích. U milionu dokumentů si vektorové databáze svoji roli podrží. U středně velké firmy, výzkumného týmu nebo jednotlivce, který si chce postavit vlastní druhý mozek, ale Karpathyho model nabízí to, co RAG ze své definice nedá: auditovatelnost, čitelnost a možnost data bez větších překážek přesunout jinam.
Franzen svůj text pro VentureBeat uzavírá obratem o éře autonomního archivu. V kontextu celé debaty nepůsobí přehnaně. Pokud se znalostní báze stane průběžně kompilovanou, kontrolovanou a přenositelnou vrstvou nad firemními či osobními daty, nejde už jen o alternativu k RAG. Jde o jiný způsob, jak si pro AI připravit vlastní paměť.
Zdroje
- Carl Franzen, VentureBeat, 3. 4. 2026: “Karpathy shares ‘LLM Knowledge Base’ architecture that bypasses RAG with an evolving markdown library maintained by AI” – https://venturebeat.com/data/karpathy-shares-llm-knowledge-base-architecture-that-bypasses-rag-with-an
- Andrej Karpathy na X, 3. 4. 2026 – původní popis LLM Knowledge Bases
- @himanshu na X – architektonický diagram tří fází
- Vamshi Reddy (@tammireddy) na X – “Every business has a raw/ directory. Nobody’s ever compiled it.”
- Ole Lehmann na X – výhled na konzumní produktovou kategorii
- Eugen Alpeza (Edra) na X – enterprise perspektiva
- @jumperz (Secondmate) na X – Swarm Knowledge Base a Hermes quality gate
- Jason Paul Michaels (@SpaceWelder314) na X – “No vector database. No embeddings. Just markdown, FTS5, and grep.”
- Steph Ango (@Kepano, Obsidian) na X – koncept “contamination mitigation”
- Lex Fridman (@lexfridman) na X – dynamické HTML a ephemeral wiki
- Charly Wargnier na X – “living knowledge base that actually heals itself”
