Warstwa wiedzy AI: 127 stron, zero baz wektorowych i to, co zrozumiałem dopiero po czasie

Andrej Karpathy opublikował w kwietniu 2026 roku gist opisujący wzorzec budowania osobistych baz wiedzy z wykorzystaniem LLM. Zebrał 99 000 zakładek w ciągu tygodnia. W ciągu kilku dni pojawiły się liczne implementacje open source. graphify powstał w 48 godzin i zdobył kolejne 27 000. Wzorzec trafił w punkt, bo nazwał dobrze znany problem: większość agentów nie ma pamięci między sesjami. Każda rozmowa zaczyna się od zera. Trzeba od nowa tłumaczyć kontekst, cele, styl i specyfikę projektu, a odpowiedź wychodzi generyczna, bo dane wejściowe nie miały na czym się oprzeć.

W webvise warstwa wiedzy służy do badań i dokumentacji projektowej. Poniżej wnioski z jej użytkowania.

Agenci zapominają między sesjami.

Standardowy przepływ pracy z AI jest bezstanowy. Otwiera się czat, opisuje problem, otrzymuje odpowiedź, zamyka czat. Przy kolejnej sesji to samo od początku. Zbudowany wcześniej kontekst przepada. Większość osób radzi sobie z tym, pisząc dłuższe prompty, wklejając dokumenty kontekstowe lub wgrywając pliki na początku każdej sesji. To działa, ale nie skaluje się. W pewnym momencie okno kontekstu jest pełne, jakość odpowiedzi spada i przygotowanie promptu zajmuje więcej czasu niż sama praca.

Warstwa wiedzy rozwiązuje ten problem na poziomie infrastruktury. Zamiast upychać kontekst w każdym prompcie, agent otrzymuje dostęp do trwałej, ustrukturyzowanej bazy wiedzy, którą czyta przed każdym działaniem. Zna już specyfikę projektu, konwencje, historię i styl. Ponowne tłumaczenie odpada, można od razu przejść do pracy.

Trzy warstwy, zero bazy wektorowej

Architektura składa się z trzech części:

• Surowe źródła. Folder z niemodyfikowalnymi dokumentami: artykuły, notatki, transkrypcje, PDF-y, nagrania, materiały badawcze. Agent czyta je, nigdy nie zmienia. To źródło prawdy.
• Wiki. Katalog plików markdown generowanych przez LLM z wzajemnymi odnośnikami: strony encji, strony koncepcji, syntezy, porównania, playbooki. Ta warstwa należy w całości do agenta. Tworzy strony, aktualizuje je po napłynięciu nowych źródeł, utrzymuje spójność odniesień. Agent pisze, człowiek czyta.
• Schemat. Dokument konfiguracyjny (CLAUDE.md, AGENTS.md lub odpowiednik) opisujący strukturę wiki, konwencje i przepływy pracy. To on zamienia generyczny LLM w zdyscyplinowanego opiekuna wiki.

Wiki to skompilowany artefakt. Agent nie wyprowadza wiedzy od nowa przy każdym zapytaniu, lecz kompiluje raz, utrzymuje spójność odsyłaczy i aktualizuje na bieżąco. Po dodaniu nowego źródła integruje je z istniejącym wiki i uaktualnia wszystkie powiązane strony. Zapytanie trafia na gotowe, skompilowane strony zamiast przeszukiwać surowe dokumenty.

Dlaczego to bije RAG w większości zastosowań

RAG wyprowadza odpowiedzi w czasie zapytania, dzieląc dokumenty na fragmenty i wyszukując te trafne. Skompilowane wiki pomija ten etap całkowicie. W opublikowanym benchmarku graphify zmierzył 71,5x mniej tokenów na zapytanie przy konkretnych charakterystykach korpusu i rozkładzie zapytań. Własne pomiary wskazują na około 1 000 tokenów treści z vaultu na zapytanie, wobec 3 000 lub więcej tokenów wstrzykiwanych przez typowy potok RAG.

Pełne techniczne porównanie RAG i wyszukiwania opartego na indeksie jest dostępne w artykule na blogu. Krótkie podsumowanie: w testowanych obciążeniach podejście ze skompilowanym wiki okazało się lepsze pod względem dokładności, kosztów i złożoności operacyjnej. Żadnej bazy wektorowej, żadnego modelu embeddingów, żadnej strategii chunkowania, żadnego zadania re-indeksowania. Pięć poleceń powłoki i zarządzany plik indeksu.

Ewolucja przebiegała w trzech fazach: jednorazowy RAG od 2020 do 2023 roku, agentyczny RAG z wieloetapowym wyszukiwaniem od 2023 do 2024 roku, a od 2025 roku inżynieria kontekstu, w której agent sam buduje kontekst z wielu źródeł. Warstwa wiedzy to infrastruktura dla tej trzeciej fazy. Większość zespołów wciąż buduje rozwiązania dla fazy pierwszej.

Wnioski z eksploatacji

Wewnętrzne wiki obejmuje obecnie 127 ustrukturyzowanych stron w siedmiu kategoriach: ludzie, firmy, koncepcje, playbooki, kolekcje, syntezy i narzędzia. Każda strona stosuje standardowy szablon z frontmatterem YAML, odnośnikami przez wikiliniki Obsidian i atrybucją źródeł. Agent obsługuje sześć zdefiniowanych operacji: ingest, aktualizacja konwersacyjna, zapytanie, lint, wzbogacanie i reorganizacja.

• Plik schematu to fundament całości. Wszystko inne z niego wynika. Dobrze napisany schemat daje zdyscyplinowane wiki ze spójnymi konwencjami. Niejasny schemat prowadzi do halucynacji i rozrostu. Aktualna wersja ma około 200 wierszy i obejmuje strukturę katalogów, format stron, wszystkie sześć operacji, konwencje nazewnictwa i obsługę sprzeczności. Doprowadzenie go do właściwej postaci wymagało kilku iteracji.
• Deduplikacja na wejściu zapobiega nadmiernemu rozrostowi stron. Zasada: przed utworzeniem nowej strony należy przeszukać istniejące wiki pod kątem nakładających się treści. Jeśli istniejąca strona pokrywa 60% lub więcej tego samego materiału, wzbogaca się ją zamiast tworzyć nową. Bez tej reguły wiki zapełnia się redundantnymi stronami fragmentującymi wiedzę na bezużyteczne kawałki.
• Zapytania wzbogacają bazę wiedzy. Dobre pytanie i użyteczna odpowiedź trafiają z powrotem do wiki jako nowa strona. Przy kolejnym pokrewnym zapytaniu agent ma już gotową skompilowaną syntezę. To efekt kumulacji, który sprawia, że system staje się lepszy, a nie tylko większy.
• Jakość ingestu zależy wyłącznie od dyscypliny. Wrzucenie surowego artykułu z poleceniem 'poddaj ingestowi' daje cienkie streszczenie. Omówienie z agentem kluczowych wniosków i wskazanie, co podkreślić, daje strony użyteczne w miarę wzrostu wiki. Obowiązuje ścisły przepływ: czyszczenie pliku, dyskusja nad wnioskami, zatwierdzenie, pełna ekstrakcja.
• Plik indeksu to system wyszukiwania. Indeks główny ma 22 wiersze. Każdy podkatalog ma własny indeks wymieniający każdą stronę z jednolinijkowym opisem. Agent czyta indeks główny przy około 400 tokenach, identyfikuje właściwy podkatalog, czyta tamtejszy indeks, po czym pobiera potrzebne strony. Większość zapytań kończy się trzema odczytami i około 1 000 tokenami treści z vaultu.

Schemat to najważniejszy plik, jaki się pisze

Karpathy nazywa go schematem. Tu nosi nazwę CLAUDE.md. Niektóre frameworki dzielą go na Knowledge Base Layer i Brand Foundation. Nazwa jest drugorzędna. Operacyjny fakt jest jeden: ten plik decyduje o zachowaniu agenta w każdej sesji.

Dobry schemat definiuje:

• Strukturę katalogów. Gdzie trafiają surowe źródła, gdzie strony wiki, jak są pogrupowane w kategorie.
• Format stron. Pola frontmattera, strukturę sekcji, zasady atrybucji źródeł, konwencje odsyłaczy.
• Operacje. Krok po kroku przepływy pracy dla ingestu źródeł, odpowiadania na zapytania, kontroli jakości i bieżącego utrzymania wiki.
• Kryteria jakości. Co czyni stronę kompletną. Kiedy sygnalizować niepewność. Jak postępować ze sprzecznymi źródłami. Zasada, że każde twierdzenie musi mieć źródło.

Bez tego agent improwizuje. Tworzy strony w przypadkowych miejscach, stosuje niespójne formaty, powiela treści i z każdą sesją oddala się od przyjętych konwencji. Schemat zapobiega dryfowi. Traktuje się go jak kod produkcyjny: każda zmiana jest celowa i przetestowana na realnym ingecie.

Jak zbudować własną warstwę w 20 minut

Nie są potrzebne 17 plików, graf umiejętności treści ani niestandardowy potok embeddingów. Wystarczą cztery rzeczy:

• Vault Obsidian z dwoma folderami. `raw/` na dokumenty źródłowe i `wiki/` na strony generowane przez agenta. Obsidian zapewnia widok grafu i nawigację.
• Plik schematu. Wyjście od gista Karpathy'ego. Dostosowanie struktury katalogów i formatu stron do własnej domeny. Na start wystarczy limit 200 wierszy.
• Agent LLM z dostępem do plików. Claude Code, OpenAI Codex lub dowolny agent potrafiący czytać i zapisywać pliki markdown. Wskazuje się mu vault, a schemat wczytuje się przy starcie.
• Pierwsze źródło. Artykuł, zestaw notatek lub dokument trafia do `raw/`. Agent otrzymuje polecenie ingestu, tworzy strony wiki, buduje odsyłacze i aktualizuje indeks.

To zamknięta pętla. System poprawia się każdego dnia, bo każde dodane źródło i każde zadane pytanie wzbogaca wiki. Pierwszy ingest wymaga 10 minut aktywnej uwagi. Przy dwudziestym agent zna domenę na tyle dobrze, że ekstrahuje i tworzy powiązania przy minimalnym nadzorze.

Opcjonalne narzędzia przy skalowaniu: qmd autorstwa Tobi Lutke do lokalnego wyszukiwania hybrydowego z BM25 i retrieval wektorowym, gdy liczba stron przekroczy 300. Rozszerzenie Obsidian Web Clipper do szybkiego pobierania artykułów z sieci do folderu raw. Dataview do zapytań nad frontmatterem stron. Git do historii wersji. Żadne z nich nie jest wymagane na start.

Co nie ma znaczenia

Większość złożoności kojarzonej z systemami wiedzy AI to narzut na problemy, których jeszcze nie ma. Baza wektorowa dla 200 dokumentów, niestandardowy model embeddingów tam, gdzie zarządzany indeks wystarcza do wyszukiwania, potok re-indeksowania przy dodawaniu dokumentu sprowadzającym się do zapisania pliku, strategia chunkowania gdy stroną jest jednostka. Przy skali, w jakiej działa większość firm, nic z tego nie jest potrzebne.

Wzorzec działa, bo markdown jest prosty, a LLM-y dobrze go czytają i piszą. Koszt infrastruktury wynosi zero. Koszt utrzymania jest niski, bo LLM obsługuje aktualizacje indeksu, choć okresowy przegląd przez człowieka pozostaje wskazany dla zachowania dokładności. Jedynym realnym kosztem jest dyscyplina: dbałość o schemat i wysoką jakość ingestu. To problem ludzki, nie technologiczny.

Zastosowania biznesowe

Ta sama architektura sprawdza się w skali całej firmy. Osobiste notatki zastępuje się dokumentacją klientów, playbook'ami sprzedażowymi, materiałami do onboardingu i wewnętrznymi SOP-ami. Zamiast jednego agenta każdy członek zespołu korzysta z agenta czytającego ze wspólnej bazy wiedzy.

Wzorzec jest identyczny: surowe źródła trafiają do systemu, agent kompiluje ustrukturyzowane strony, odsyłacze budują się automatycznie, ludzie zatwierdzają. Różnica polega na tym, że wspólna warstwa wiedzy sprawia, iż nowi członkowie zespołu są produktywni od razu. Ich agent zna już historię klienta, wewnętrzne konwencje i kontekst projektu. Bez sześciotygodniowego wdrożenia, bez wiedzy plemiennej zamkniętej w czyjejś głowie.

Karpathy nazywa to LLM wiki. Eric Osiu mówi o wspólnym mózgu. Cody Schneider o hurtowni danych. Nazwa się zmienia. Wzorzec nie: agenci potrzebują skompilowanej, ustrukturyzowanej wiedzy, żeby wykonywać użyteczną pracę. Bez trwałego kontekstu prompty działają bez instytucjonalnej wiedzy, której potrzebują.

webvise buduje warstwy wiedzy dla firm, które chcą, by ich agenci AI naprawdę wiedzieli, o czym mówią. Jeśli więcej czasu zajmuje tłumaczenie kontekstu narzędziom niż czerpanie z nich wartości, to właśnie ten problem tu się rozwiązuje. Skontaktuj się.