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

LLM Wiki je Karpathyho popis patternu, jak s pomocí LLM budovat osobní nebo týmovou knowledge base nad lokálními soubory. Nejde o hotový produkt, ale o architekturu práce, kde člověk dodává zdroje a otázky, zatímco LLM průběžně udržuje wiki jako persistentní mezivrstvu mezi raw dokumenty a dotazy. Na princip v češtině upozornil i článek na Marigold.cz.

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.

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ů.

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.

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

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.