Przejdź do treści
JT CONSULTING
Menu

Drugi mózg według Karpathy’ego: wiki, którą prowadzi model językowy

Juliusz Tomeczek,

W pierwszym odcinku tej serii opisałem drugi mózg jako zewnętrzną pamięć, która odpowiada na pytania, a nie tylko przechowuje notatki. Ten tekst opisuje metodę, na której stoi mój system.

Sama idea jest starsza niż modele językowe. W renesansie uczeni prowadzili księgi, w których pod hasłami układali wypisy z lektur, a polska szlachta prowadziła sylwy, do których wpisywano wszystko, co warto było zapamiętać. W XX wieku niemiecki socjolog Niklas Luhmann zbudował kartotekę liczącą około 90 000 kartek, w której każda notatka odsyłała do innych. Napisał kilkadziesiąt książek i kilkaset artykułów naukowych, a tak dużą liczbę publikacji zawdzięczał, jak sam mówił, właśnie tej kartotece. Nazwę „drugi mózg” spopularyzował Tiago Forte, autor wydanej w 2022 roku książki „Building a Second Brain”. Jego metoda opiera się na czterech krokach: zbieraniu materiałów, porządkowaniu ich, wydobywaniu z nich sedna i wykorzystywaniu w pracy. Wszystkie te kroki wykonywał jednak człowiek: sam decydował, co zapisać, sam porządkował notatki i sam dbał o to, żeby odsyłacze nie traciły aktualności.

W kwietniu 2026 roku Andrej Karpathy, jeden z założycieli OpenAI i były szef działu sztucznej inteligencji w Tesli, opublikował krótką notatkę o wzorcu nazwanym LLM Wiki. W skrócie: model językowy sam buduje i utrzymuje uporządkowaną wiki z Twoich materiałów, a Ty dostarczasz źródła, zadajesz pytania i rozstrzygasz.

Karpathy zaznacza, że nie publikuje programu ani instrukcji, tylko opis pomysłu. Taki opis wkleja się do własnego asystenta opartego na modelu językowym i razem z nim ustala szczegóły. Dlatego ten wzorzec łatwo przeoczyć: nie ma czego zainstalować. Mój sejf działa na nim od 23 czerwca 2026 roku, więc mogę opisać nie tylko samą ideę, ale też to, co z niej wynika po ponad trzech miesiącach codziennej pracy.

Problem, który rozwiązuje LLM Wiki

Najczęstszy sposób pracy z modelem i dokumentami wygląda tak: wrzucasz pliki, zadajesz pytanie, a model wyszukuje pasujące fragmenty i składa z nich odpowiedź. Tak działa NotebookLM, tak działają pliki dodane do rozmowy z czatem i większość systemów wyszukiwania w dokumentach.

Ten sposób działa, ale ma wadę, którą Karpathy nazywa wprost: model za każdym razem odkrywa wiedzę od nowa. Jeżeli odpowiedź wymaga zestawienia pięciu dokumentów, model zestawia je przy każdym pytaniu, a efekt tej pracy znika razem z rozmową. Nic się nie gromadzi. Jeżeli dwa źródła przeczą sobie nawzajem, model musi to zauważyć od nowa przy każdym pytaniu, którego ta sprzeczność dotyczy.

LLM Wiki działa odwrotnie. Pracę syntezy model wykonuje raz, przy dodaniu materiału, i zapisuje jej wynik jako trwałe strony. Przy kolejnym pytaniu powiązania już istnieją, sprzeczności są oznaczone, a podsumowanie uwzględnia wszystko, co wcześniej przeczytano.

Trzy warstwy

Wzorzec dzieli system na trzy części, a każda ma innego właściciela.

Źródła należą do Ciebie i nikt ich nie zmienia. Są to artykuły, dokumenty, transkrypcje i notatki ze spotkań. Model je czyta i cytuje, ale nigdy nie poprawia. To jest punkt odniesienia: za pół roku można sprawdzić, co dokładnie napisano, a nie to, co model z tego zapamiętał.

Wiki należy do modelu. Składa się ze zwykłych plików tekstowych, czyli stron opisujących pojęcia i konkretne byty (osoby, narzędzia, projekty), zestawień i analiz, gęsto połączonych odnośnikami. Model tworzy te strony, aktualizuje je po każdym nowym źródle i pilnuje spójności. Ty je czytasz.

Plik z zasadami łączy obie warstwy. To dokument, w którym opisujesz modelowi, jak ma prowadzić wiki: jakie strony zakłada, jak je nazywa i co robi po dodaniu źródła. Karpathy nazywa go kluczowym plikiem całej konfiguracji, bo to on sprawia, że model zachowuje się jak zdyscyplinowany redaktor, a nie jak czat odpowiadający na pojedyncze pytania.

Podział na źródła i wiki odpowiada na pytanie, które zadaje sobie prawie każdy na początku: dlaczego model ma pisać syntezę, a nie same źródła. Źródła muszą zostać nietknięte, bo tylko wtedy da się sprawdzić, czy synteza jest prawdziwa. Syntezę wolno natomiast przepisywać dowolnie często, bo zawsze można wrócić do materiału, z którego powstała. Gdyby model poprawiał źródła, po kilku miesiącach nie byłoby już do czego wracać.

Karpathy porównuje ten układ do pracy programisty: Obsidian, w którym przeglądasz notatki, pełni rolę edytora, model językowy jest programistą, a wiki to kod, który ten programista pisze i poprawia.

Trzy czynności

Pierwsza czynność to przyjęcie źródła. Dodajesz nowy materiał, a model go czyta, omawia z Tobą najważniejsze wnioski i dopisuje je do wiki. Według Karpathy’ego jedno źródło potrafi zmienić od 10 do 15 stron, bo nowa informacja dotyczy wielu bytów i pojęć naraz.

Druga czynność to zadanie pytania. Pytasz, a model szuka odpowiedzi w wiki, nie w surowych plikach, i podaje ją razem ze źródłami. Karpathy zwraca tu uwagę na ważną rzecz: dobra odpowiedź nie powinna zniknąć w historii rozmowy. Jeżeli wymagała zestawienia albo analizy, trafia do wiki jako nowa strona, więc pytania budują system tak samo jak źródła.

Trzecia czynność to przegląd. Co jakiś czas prosisz model, żeby sprawdził stan wiki: czy strony sobie nie przeczą, czy nowsze źródła nie zdezaktualizowały wcześniejszych twierdzeń, czy są strony, do których nic nie prowadzi, i czy w tekście pojawiają się pojęcia bez własnej strony.

Po wiki pomagają się poruszać dwa pliki. Indeks to spis wszystkich stron z jednozdaniowym opisem, od którego model zaczyna każde szukanie. Dziennik to chronologiczny zapis tego, co się wydarzyło: każde przyjęcie źródła, każdy przegląd. Z indeksu dowiesz się, co jest w wiki, a z dziennika, skąd ta wiedza pochodzi i kiedy trafiła do systemu.

Dlaczego to działa

Większość osobistych wiki utrzymywanych ręcznie umiera z tego samego powodu: utrzymanie rośnie szybciej niż korzyść. Przeczytanie artykułu i przemyślenie go to przyjemność. Uzupełnienie odnośników na dwudziestu stronach, poprawienie podsumowania i zauważenie, że nowa liczba przeczy starej, to żmudna praca, której nikt nie lubi. Po kilku tygodniach wiki przestaje nadążać, więc nikt jej już nie ufa.

Model się tą pracą nie nudzi i nie zapomina o odnośniku. W jednym przebiegu potrafi poprawić kilkanaście plików. Koszt utrzymania spada prawie do zera, a rola człowieka przesuwa się tam, gdzie jest najbardziej potrzebna: na dobór źródeł, zadawanie pytań i ocenę, co z tego wynika.

Karpathy przypomina przy tym pomysł z 1945 roku. Vannevar Bush opisał wtedy Memex, osobiste urządzenie do gromadzenia dokumentów połączonych ścieżkami skojarzeń. Bush nie rozwiązał jednego problemu: kto ma te ścieżki utrzymywać. Według Karpathy’ego tę lukę wypełnia dziś model językowy.

Jak to wygląda u mnie po ponad trzech miesiącach

Pracuję w Obsidianie, a wiki prowadzi Claude Code. Na początku października 2026 roku mój sejf miał 374 notatki źródłowe i 421 stron syntezy, a dziennik liczył 901 wpisów. Liczby same w sobie mówią niewiele. Więcej mówi to, co w tym czasie musiałem dołożyć do wzorca, bo Karpathy celowo opisuje tylko szkielet.

Wiedzę o świecie trzymam osobno od zapisów własnej pracy. Z tych 421 stron 67 opisuje moją działalność: serwery, narzędzia, projekty, decyzje. Pozostałe 354 to wiedza ogólna, na przykład notatki z przeczytanych książek. Na początku wszystko trafiało do jednej wiki: pierwszy przyjęty wywiad o sztucznej inteligencji stanął obok kart moich serwerów i projektów. Po niecałych trzech tygodniach rozdzieliłem te warstwy, bo jedna opisuje fakty z mojej pracy, a druga czyjeś poglądy i ustalenia, a model powinien zawsze wiedzieć, o którą z nich go pytam.

Obok wiki prowadzę ewidencję. Projekty, kontakty, narzędzia i dokumenty to nie wiedza do syntezy, tylko sprawy, które mają swój stan i zmieniają się z dnia na dzień. Mają własne karty pisane według stałych wzorów, a strony wiki do nich odsyłają.

Zdanie bez pomiaru jest oznaczone jako hipoteza. Model pisze płynnie, więc wniosek brzmi tak samo pewnie jak sprawdzony fakt. Zdarzyło mi się przenieść do notatek i do zlecenia dla programisty zdanie o usterce, którego nikt nie zmierzył, a pomiar pokazał zupełnie inną usterkę. Od tamtej pory zdanie o stanie rzeczy podaję razem ze źródłem tej wiedzy, a jeśli źródła nie mam, piszę wprost, że to hipoteza.

Wpis w dzienniku nosi godzinę, a nie kolejny numer. Często pracuję w kilku rozmowach z modelem naraz, a każda z nich dopisuje do tego samego dziennika i nie widzi pozostałych. Kolejne numery zaczęły się przez to dublować. Godzinę podaje zegar, więc żadna rozmowa nie musi już zgadywać, ile wpisów powstało przed nią.

Każda z tych zmian trafiła do pliku z zasadami. Od lipca urósł on z 1329 do 3836 słów, a zmieniałem go w 15 różnych dniach. Karpathy pisze, że plik z zasadami rozwija się razem z systemem. U mnie każda pomyłka, która się powtórzyła, kończy się nową regułą.

Czego ten wzorzec nie załatwia

Wzorzec nie daje gotowego systemu. Notatka Karpathy’ego opisuje kształt, a nie wykonanie. Strukturę, nazewnictwo i zasady trzeba ustalić dla własnej pracy, a ich ustalenie zajmuje więcej czasu niż samo uruchomienie narzędzi.

LLM Wiki nie zwalnia ze sprawdzania. Model porządkuje notatki i podpowiada powiązania, ale bywa, że się myli. Potrafi zapisać jako pewny fakt coś, co sam tylko wywnioskował, albo uznać, że dwie sprawy są ze sobą związane, choć w rzeczywistości nic ich nie łączy. Odpowiedzialność za to, co twierdzi system, zostaje po stronie człowieka, dlatego źródła muszą być nietknięte, a przeglądy regularne.

System działa najlepiej z jednym gospodarzem. Karpathy wspomina o wiki dla zespołu, zasilanej rozmowami i dokumentami firmy, z ludźmi zatwierdzającymi zmiany. Opisuję jednak system jednej osoby. Wspólna baza kilku autorów wymaga ustalenia uprawnień i rozstrzygania sprzecznych zapisów, a to inne zadanie.

Co dalej w tej serii

W następnym odcinku opiszę budowę takiego systemu od zera: od czego zacząć, co przenieść ze starych notatek i kiedy wiki zaczyna odpowiadać na pytania lepiej niż wyszukiwanie w plikach. Jeżeli wolisz zbudować drugi mózg na własnych materiałach razem ze mną, zakres współpracy opisałem na stronie usługi „Drugi mózg”, a przebieg warsztatu dla zespołu pokazuje strona realizacji.

Źródło: Andrej Karpathy, „LLM Wiki”, kwiecień 2026.

Ten tekst powstał z użyciem narzędzi sztucznej inteligencji, bo tak pracuję na co dzień i tego uczę. Każde twierdzenie w nim sprawdziłem i odpowiadam za nie z imienia i nazwiska. Rysunki w tym dziale powstały tak samo: są wektorowe, napisane jako kod przy tej samej pomocy. Zrzuty ekranu pokazują prawdziwe programy i robię je sam.

Juliusz Tomeczek, JT CONSULTING

Porozmawiajmy o współpracy

Napisz krótko, czego potrzebujesz, a odezwę się z propozycją następnego kroku. Odpowiadam osobiście, bo w JT CONSULTING nie ma działu obsługi.

Jeżeli wolisz najpierw poczytać, więcej tekstów o sztucznej inteligencji znajdziesz na moim blogu AI for Everyone. Zobacz blog