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 pravdywiki/ nemá být mechanická kopie článků, bookmarků nebo dokumentace, ale syntéza, entity, porovnání, souvislosti a rozporyraw/, ne privilegovanou vrstvou architekturyJiný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
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:
Při ingestu LLM neudělá jen shrnutí nového zdroje. Má také:
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:
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ů:
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:
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:
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 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.