Karpathyho LLM Wiki – průběžně budovaná znalostní báze

LLM Wiki je Karpathyho popis patternu pro budování průběžně udržované knowledge base nad lokálními soubory. Častý omyl je chápat to jako odkladiště bookmarků, vendor dokumentace nebo složku, kterou stačí jednorázově nahrát do LLM a tím vznikne znalostní databáze. Ve skutečnosti raw zdroje zůstávají jen vstupem, zatímco LLM z nich postupně vytváří a udržuje wiki jako persistentní, zkompilovanou mezivrstvu mezi dokumenty a dotazy. Na princip v češtině upozornil i článek na Marigold.cz.

Nejdůležitější je neplést si LLM Wiki s generickým „second brain“ úložištěm na všechno. Smyslem není jen nahromadit co nejvíc souborů, ale průběžně z nich stavět provázanou znalostní vrstvu pro konkrétní doménu nebo projekt.

• raw/ není hotová knowledge base, ale jen zdroj pravdy
• samotné přidání celé složky souborů ještě neznamená, že se znalost „zkompilovala„
• wiki/ nemá být mechanická kopie článků, bookmarků nebo dokumentace, ale syntéza, entity, porovnání, souvislosti a rozpory
• existující wiki nebo dokumentace může být jen dalším zdrojem v raw/, ne privilegovanou vrstvou architektury
• v praxi dává největší smysl držet jednu wiki pro jeden jasně vymezený okruh témat; jinak místo kumulace znalosti roste šum

Jinými slovy: dokumentace k nástroji nebo odkaz na zajímavý článek se může stát vstupem, ale hodnotu získá až ve chvíli, kdy ho LLM zapracuje do existujících stránek a propojí s ostatními znalostmi v dané doméně.

Základní myšlenka je jednoduchá: běžný RAG nebo upload dokumentů do chatu většinou při každém dotazu znovu hledá relevantní pasáže a skládá odpověď od nuly. Karpathy navrhuje jiný model. LLM má místo jednorázového retrievalu průběžně vytvářet a aktualizovat wiki z markdown souborů, kde už jsou dopředu zapsané souhrny, entity, vztahy, rozpory i odkazy mezi tématy.

Výsledkem není jen odpověď na konkrétní dotaz, ale průběžně rostoucí znalostní vrstva. Nový zdroj neznamená pouze nový embedding nebo další soubor v indexu, ale i úpravu již existujících stránek, doplnění souvislostí a případné označení konfliktů s tím, co wiki tvrdila dřív.

Když Karpathy píše, že znalost je zkompilovaná předem, nemyslí tím indexaci souborů pro pozdější retrieval. Myslí tím, že po ingestu už jsou relevantní wiki stránky přepsané a připravené k použití, takže se syntéza nemusí skládat znovu při každém dalším dotazu.

Podle gistu stojí celý přístup na třech vrstvách:

raw/     = zdrojové materiály, do kterých se nezasahuje
wiki/    = LLM-generované markdown stránky
schema/  = pravidla a workflow pro agenta, typicky v CLAUDE.md nebo AGENTS.md

• Raw sources – články, PDF, poznámky, obrázky, přepisy nebo datasety. Jsou immutable a fungují jako zdroj pravdy.
• Wiki – zpracovaná znalostní vrstva. Obsahuje shrnutí, přehledové stránky, entity, témata, porovnání a další průběžně udržované soubory.
• Schema – instrukce pro agenta, jak má wiki strukturovat, co dělat při ingestu, jak zapisovat zdroje, jak udržovat index a jak zacházet s rozpory.

Právě schema je důležité. Rozhoduje o tom, zda agent funguje jako disciplinovaný správce znalostí, nebo jen jako další chatbot, který do souborů občas něco připíše.

Karpathy popisuje tři základní provozní režimy:

• Ingest – přidání nového zdroje a jeho zapracování do wiki
• Query – dotazování nad již zkompilovanou wiki
• Lint – průběžná kontrola kvality a konzistence wiki

Při ingestu LLM neudělá jen shrnutí nového zdroje. Má také:

• aktualizovat související stránky
• doplnit cross-linky
• upravit přehled nebo index
• zapsat změnu do logu
• označit konflikty s dřívějšími tvrzeními

Jeden nový zdroj tak může změnit více stránek najednou. To je hlavní rozdíl oproti klasickému retrievalu nad plochým archivem souborů.

Karpathy v gistu zároveň píše, že osobně preferuje ingest po jednom zdroji a zůstává u něj v loopu. To dobře ukazuje, že pointa není bezhlavý hromadný import všeho, ale průběžné kurátorství: člověk vybírá zdroje a směr, LLM dělá syntézu a údržbu.

Dotazy se už nevedou primárně proti raw dokumentům, ale proti wiki. LLM si z ní vytáhne relevantní stránky, propojí je a připraví odpověď. Důležitá myšlenka z gistu je, že hodnotné odpovědi je vhodné ukládat zpět do báze jako nové přehledy, porovnání nebo syntetické stránky. Dotazování tak knowledge base dále rozšiřuje.

Praktický důsledek je jednoduchý: pokud při dotazu vznikne dobrá syntéza, srovnání nebo nová užitečná stránka, je škoda ji nechat jen v historii chatu. Dává smysl mít workflow, kde agent takové uložení po odpovědi rovnou navrhne.

Karpathy výslovně doporučuje pravidelný health check. LLM má hledat například:

• rozpory mezi stránkami
• zastaralá tvrzení
• osiřelé stránky bez odkazů
• důležité pojmy bez vlastní stránky
• chybějící cross-reference
• témata, kde dává smysl dohledat další zdroje

Tahle údržba je prakticky stejně důležitá jako samotný ingest.

Největší posun není v tom, že by LLM Wiki zakazovala retrieval. Podstatné je, že wiki funguje jako persistentní a kumulativní artefakt. Znalost se neskládá od nuly při každém dotazu, ale jednou se průběžně kompiluje a pak se jen udržuje aktuální.

To má několik důsledků:

• souvislosti mezi tématy už jsou zapsané předem
• důležité rozpory mohou být označené průběžně
• syntéza roste s každým zdrojem i s každým smysluplným dotazem
• člověk se víc soustředí na kurátorství zdrojů a méně na ruční údržbu poznámek

V tomto smyslu je LLM Wiki spíš pattern pro knowledge compilation než jen další varianta RAG.

Pattern dává smysl hlavně tam, kde se znalost hromadí delší dobu a je potřeba ji průběžně propojovat:

• osobní knowledge base
• technické rešerše a studium tématu
• přehledy k článkům, paperům nebo podcastům
• týmová interní wiki nad meeting notes, Slackem nebo dokumentací
• průběžné case studies a srovnání nástrojů

Naopak to není hotová produktová specifikace. Gist výslovně zůstává záměrně abstraktní a předpokládá, že konkrétní podobu – strukturu adresářů, typy stránek, naming a workflow – si uživatel navrhne podle vlastního use-case.

Tenhle přístup má i limity:

• při větší bázi přestane stačit ručně udržovaný index
• pokud agent zapisuje nepřesnosti zpět do wiki, chyby se mohou kumulovat
• bez verzování a lintingu se báze časem zhorší
• je potřeba jasně oddělit raw zdroje, interní pracovní vrstvu a případně publikované výstupy
• pokud se do jedné wiki míchají nesouvisející domény, rychle se zhorší struktura i kvalita syntézy

Právě proto dává smysl wiki verzovat v gitu a průběžně kontrolovat diffy. U větší knowledge base se hodí i samostatná vyhledávací vrstva.

Karpathy's LLM Wiki – Full Beginner Setup Guide ukazuje jednu konkrétní implementaci tohohle patternu nad lokální složkou s markdown soubory. Jako prohlížeč používá Obsidian, zatímco samotnou údržbu wiki dělá coding agent nad soubory na disku.

Ve videu je užitečné hlavně to, že abstraktní tři vrstvy převádí do konkrétního setupu:

• v rootu vaultu jsou raw/, wiki/ a volitelně i templates/
• pravidla pro agenta jsou v claude.md v kořeni projektu
• ingest se spouští jednoduchým promptem typu I just added a new source to the raw folder please read it and update the wiki.
• po přidání dalšího zdroje agent nemá jen vytvářet nové stránky, ale i aktualizovat už existující témata a doplnit vazby
• průběžná kontrola kvality se dá spustit promptem Please lint the wiki.

Zároveň je dobré to chápat jen jako jednu praktickou podobu, ne jako jediné správné řešení. Video samo ukazuje Obsidian hlavně jako viewer a graph view nad markdown soubory; samotný princip LLM Wiki zůstává stejný i s jiným editorem nebo jiným agentem, pokud umí spolehlivě číst a zapisovat soubory. Soustředí se hlavně na menší osobní setup, ne na větší vyhledávací vrstvu nebo provoz ve větším měřítku.

Karpathy v gistu zmiňuje qmd jako vhodný doplněk pro větší wiki. Nejde o náhradu LLM Wiki, ale o lokální search engine pro markdown a dokumentaci. Prakticky to znamená, že samotná wiki zůstává persistentní znalostní vrstvou, zatímco qmd pomáhá agentovi rychle najít relevantní stránky, když už index nebo jednoduché procházení přestává stačit.

Podrobněji je to rozepsané v samostatném článku QMD.

LLM Wiki není konkrétní software, ale užitečný způsob uvažování o práci s LLM a dokumenty. Místo jednorázového prohledávání souborů staví na představě, že mezi zdroji a dotazem existuje průběžně udržovaná znalostní vrstva. Člověk spravuje vstupy a směr, LLM dělá většinu údržby, propojení a syntézy.

Pokud máš větší množství poznámek, článků nebo technických podkladů, je to zajímavý model hlavně proto, že nutí oddělit tři věci: zdroj pravdy, pracovní znalostní vrstvu a finální publikované výstupy.

• Karpathy – LLM Wiki gist
• Marigold.cz – Karpathy přišel na to, jak používat AI jinak. A má pravdu.
• Teachers Tech – Karpathy's LLM Wiki – Full Beginner Setup Guide
• tobi/qmd – GitHub