Wiki LLM po 490 stronach: ile naprawdę kosztują 3 miesiące wiedzy utrzymywanej przez agentów

Baza wiedzy utrzymywana przez agentów przetrwa dopiero wtedy, gdy przestaje się pełnić rolę jej bibliotekarza. Opisywane tu wiki LLM osiągnęło w 3 miesiące 490 stron i trzyma się dzięki trzem decyzjom: warstwę skompilowaną prowadzą agenci, każda interakcja przechodzi przez jedną z sześciu nazwanych operacji, a linter z 20 kontrolami blokuje każdy commit poniżej ustalonego poziomu. Niemal żadnej z tych stron nie napisano ręcznie.

Ręcznie budowane drugie mózgi umierają zawsze tak samo: wartość tkwi w utrzymaniu, a to właśnie utrzymanie ustaje po trzecim tygodniu. Kto ma na koncie cmentarzysko porzuconych przestrzeni roboczych w Notion, zna ten wzorzec. Agenci kodujący znoszą ten koszt, bo nigdy się nie nudzą i chętnie naprawią 40 zepsutych odnośników we wtorkowy wieczór. Przewodnik po warstwie wiedzy AI opisuje budowę takiej warstwy w 20 minut; ten tekst to raport z jej eksploatacji przy 490 stronach, z 3 miesiącami cotygodniowych danych o stanie systemu i uwzględnionymi porażkami.

• Najpierw rozdzielić własność. Jedna warstwa źródeł należy do człowieka, jedna warstwa stron skompilowanych należy do agentów, wiedza płynie w jedną stronę. Ta pojedyncza decyzja czyni utrzymanie możliwym do delegowania.
• Zamknięty zestaw operacji bije improwizację. Sześć nazwanych operacji (ingest, aktualizacja, zapytanie, lint, wzbogacanie, reorganizacja) nie pozwala agentom wymyślać nowego przepływu pracy w każdej sesji.
• Deterministyczne bramki biją pisane wytyczne. Agenci respektują nieprzechodzący test, a od reguł zapisanych prozą z czasem odchodzą. Linter liczący 1671 wierszy z 20 kontrolami uruchamia się przy każdym commicie.
• Zdrowa baza wiedzy czasem się kurczy. Dwa tygodnie, w których liczba stron spadła, to były przebiegi konsolidacyjne, i były to najzdrowsze tygodnie w całym dzienniku.
• Każda reguła powinna wynikać z konkretnej porażki. Liczący 246 wierszy zbiór reguł rósł jak dziennik zmian rzeczy, które poszły źle, i właśnie dlatego agenci go przestrzegają.

Najpierw rozdzielić własność

Vault działa w Obsidianie, podzielony na dwie warstwy, a wszystko poniżej przenosi się na dowolny folder plików markdown. Warstwa raw należy do człowieka: 341 zapisanych artykułów, 20 transkryptów, notatek i wpisów dziennika, które agenci czytają, ale nigdy nie przepisują. Warstwa wiki należy do agentów: każdą stronę generują i utrzymują oni sami, a poprawki wprowadza się w rozmowie, nie ręcznie. Wiedza płynie w jedną stronę, z raw do wiki, nigdy z powrotem.

To rozdzielenie sprawia, że utrzymanie da się delegować. Gdy notatki człowieka i notatki agenta dzielą te same pliki, każda edycja agenta może nadpisać coś istotnego, więc trzeba przeglądać wszystko, czyli wraca się do roli bibliotekarza. Po rozdzieleniu warstw przegląd sprowadza się do jednego pytania: czy skompilowane rozumienie jest wierne źródłom?

To samo pytanie o własność decyduje, czy firmowa baza wiedzy działa. Ustalenie, która strona jest właścicielem którego faktu, to również pierwsze ćwiczenie w sprincie audytu i doradztwa AI webvise, bo automatyzacja zbudowana na sprzecznych dokumentach automatyzuje tę sprzeczność.

Reguły mieszkają w plikach, a każda z nich wynika z porażki

Wszystko, co agenci wiedzą o vaulcie, pochodzi z plików wewnątrz niego. Plik AGENTS.md w katalogu głównym to konstytucja: 246 wierszy obejmujących drzewo katalogów, szablon strony, reguły dotyczące źródeł i system indeksu. Sąsiadujący z nim CLAUDE.md liczy jeden wiersz i jest nakładką sprawiającą, że Claude Code wczytuje ten sam plik, który czyta Codex i każde inne narzędzie rozpoznające AGENTS.md.

• Zero wymyślania. Każde twierdzenie wynika ze źródła albo zostaje oznaczone jako niezweryfikowane.
• Czat nie jest źródłem. Oczyszczony fragment najpierw zapisuje się jako plik, dopiero potem cytuje się ten plik. "Użytkownik powiedział tak w czacie" to cytat, do którego nigdy nie da się wrócić.
• Jedna strona właścicielska na każdy zmienny fakt. Każda inna strona odsyła do niej zamiast go kopiować.
• Każda wzmianka o znanej encji jest odnośnikiem. Fakt bez odnośnika jest niewidoczny dla grafu i dla wyszukiwania.

Nic z tego nie wzięło się z modelu zarządzania zaprojektowanego z góry. Pewnego ranka pliki z instrukcjami okazały się wyzerowane do 0 bajtów, więc vault przeniesiono z synchronizacji plików do repozytorium git z bramką na commity. W listach źródeł wciąż pojawiały się niemożliwe do zweryfikowania cytaty z czatów, więc czaty zakazano jako źródła, a rekordy w stylu CRM zaczęły zaśmiecać strony wiedzy, więc rekordy usunięto z vaulta całkowicie. Regułę warto spisać w tygodniu, w którym jej brak coś kosztuje, a pominąć 50 spekulacyjnych.

Sześć operacji i nic ponadto

Agent z dostępem do vaulta, ale bez zdefiniowanych operacji, wymyśla nowy przepływ pracy w każdej sesji. Jednego dnia scala duplikaty, kolejnego je tworzy, i za każdym razem potrafi to uzasadnić. Dlatego każda interakcja przechodzi przez jedną z sześciu operacji, każda zapisana jako plik umiejętności wczytywany przez każde narzędzie agentowe.

Zabezpieczenia wewnątrz operacji robią więcej niż sama lista. Ingest traktuje instrukcje osadzone w zapisanych artykułach jako treść niezaufaną, bo lista lektur to powierzchnia ataku: artykuł, który mówi "zignoruj poprzednie instrukcje", zostaje zapisany jako artykuł mówiący to zdanie, a nic, co mówi artykuł, nie może w tym samym przebiegu autoryzować zmian schematu. Zapytanie ma twardy próg: agent może stwierdzić, że w vaulcie brakuje informacji, dopiero gdy pełnotekstowe wyszukiwanie nie da wyniku, bo inaczej "indeks tego nie pokazał" zmienia się w "to nie istnieje". Reorganizacja wymaga pełnego mapowania plików ze starych na nowe oraz wyraźnego potwierdzenia, zanim cokolwiek się przesunie.

Deterministyczna bramka pod modelem

Agenci respektują nieprzechodzącą bramkę, a od pisanej wytycznej z czasem odchodzą. Można zapisać w regulaminie "utrzymuj indeksy w zgodzie" i patrzeć, jak zasada rozmywa się w ciągu tygodnia, albo sprawić, że niezgodny indeks nie przechodzi kontroli blokującej commit, i wtedy problem znika na stałe.

Bramka to linter w Pythonie liczący 1671 wierszy, wyłącznie standardowa biblioteka, 20 kontroli, około 2 sekundy na pełny przebieg. Problemy strukturalne to błędy: zepsute wikilinki, wadliwy frontmatter, wpisy indeksu wskazujące na pliki, które już nie istnieją. Problemy z dryfem to ostrzeżenia: osierocone strony, liczby w indeksie, które przestały odpowiadać rzeczywistości, strony nietknięte od 90 dni. Liczący 13 wierszy hook pre-commit uruchamia linter w trybie ścisłym, w którym ostrzeżenia też blokują commit, więc do historii gita nie trafia nic poniżej ustalonego poziomu.

Bramka czyta wszystko, łącznie z tekstem o samej bramce. Podczas redagowania rozbudowanej wersji tego raportu 2026-07-21 pojawił się przykładowy niemiecki zwrot z terminem, i linter odczytał go jako przeterminowany termin wewnątrz artykułu. Przykładowa pieczątka cytowania została zarejestrowana jako źródło brakujące z listy źródeł. Oba fragmenty trzeba było przeformułować, zanim commit przeszedł.

Trzy miesiące strojenia sprowadziły się do jednego kierunku: gdy tylko ocenę dało się zamienić w kontrolę, zamieniano ją w kontrolę. Koszt spadał, a niezawodność rosła na każdym kroku. Model jest najdroższym i najmniej powtarzalnym elementem systemu, więc rezerwuje się go wyłącznie do oceny.

Co mówią liczby po 3 miesiącach

Cotygodniowe raporty pokazują liczbę stron: 188 w połowie kwietnia, 279 na początku maja, spadek do 263 po przebiegu konsolidacyjnym, wzrost do 479 na początku lipca, potem spadek do 430, zanim pod koniec lipca osiągnięto 490. Oba spadki były najzdrowszymi tygodniami w dzienniku, bo złączyły cienkie i zdublowane strony z ich właścicielami. Nieutrzymywane bazy wiedzy tylko rosną. Jeśli liczba stron nigdy nie spadła, nikt nie pielęgnuje tego ogrodu.

Pełny audyt vaulta 2026-06-22 wykrył jedną tabelę cenową powtórzoną na 4 różnych stronach oraz historię jednego projektu opowiedzianą 3 razy w formie akapitu. Każda kopia była poprawna w momencie powstania i każda kopia była przyszłym kłamstwem, bo kolejna zmiana trafiłaby w jedną z nich, pomijając resztę. Rozwiązaniem była jasno przypisana własność: rejestr wskazuje dokładnie jedną stronę właścicielską na każdy zmienny fakt, a małe, jednotematyczne strony pozostają małe, bo taki kształt najlepiej się wyszukuje. Ten sam audyt nie znalazł ani jednej twardej sprzeczności faktograficznej wśród ponad 400 stron, bo struktura nie zostawia sprzecznościom miejsca do istnienia.

Metodą oceny wartą naśladowania jest karta wyników, nie widok grafu. Wystarczy spisać 15 pytań, na które baza wiedzy najbardziej musi umieć odpowiedzieć, zadać je bez przygotowania i ocenić każdą odpowiedź jako jednoznacznie klarowną albo rozproszoną. W tym przypadku 13 odpowiedzi wypadło jednoznacznie klarownie, a 2 rozproszone dotyczyły gustu, który mieszka w decyzjach nigdy niezapisanych. Metryką jest to, czy system odpowiada na realne pytania za jednym skokiem.

Bieżący koszt utrzymania to 5 minut dziennie plus jedna sesja agenta trwająca 30 do 45 minut w niedziele, a repozytorium pokazuje 880 commitów od maja.

Co wciąż nie działa

Jakość wyszukiwania to zakład, i pozostaje otwarty. Agent zawsze znajduje wiarygodnie wyglądającą stronę, a błędna, lecz wiarygodna odpowiedź jest gorsza niż brak wyniku, bo nic nie wygląda na zepsute. Robocze założenie brzmi: poniżej mniej więcej 10 000 stron wyszukiwanie po słowach kluczowych w dobrze ustrukturyzowanym markdownie ma odpowiedni rozmiar, a przy 490 stronach ten próg jest daleki od przetestowania.

Rozrost tagów i tak nastąpił: 662 odrębne tagi, dodawane po jednym wiarygodnie brzmiącym tagu naraz, bo agenci generują wiarygodne tagi za darmo. Nieaktualność wciąż kosztuje: około 30 stron oznaczonych jako autorytatywne, a mimo to nieaktualnych, pomimo dat aktualności i 90-dniowego ostrzeżenia lintera. W kwietniu vault działał przy 0,68 surowego źródła na skompilowaną stronę, co oznacza, że system pisał szybciej, niż czytał. Gdy pisanie nic nie kosztuje, strony bez źródeł stają się ścieżką najmniejszego oporu, a reguła zakazu wymyślania jest jedyną rzeczą stojącą między bazą wiedzy a bardzo uporządkowanym stosem twierdzeń.

Dedykowane produkty pamięciowe obiecują rozwiązać wyszukiwanie za granicą 10 000 stron, a uczciwa odpowiedź brzmi, że ten vault jest daleko poniżej tego progu. Podział tego rynku na dwa obozy opisują Warstwy kontekstu dla długo działających agentów.

Ten sam wzorzec wewnątrz firmy

Karpathy naszkicował wzorzec wiki LLM w giście, a Google wypuściło w czerwcu 2026 roku pasujący otwarty format wiedzy, pakiety markdown z typowanym frontmatterem, które odwzorowują ten układ niemal pole po polu. Tę zbieżność da się odczytać jako dowód, że kształt jest właściwy. Wersja biznesowa kompiluje pozycjonowanie, cennik, SOP-y, dzienniki decyzji i kontekst klienta zamiast notatek osobistych, i zawodzi identycznie: wiki, które ktoś zbudował z zapałem i którego nikt nie utrzymuje. Dla firmowej bazy wiedzy liczącej 200 dokumentów opisana wyżej maszyneria to już więcej, niż potrzeba, a Większość firmowych baz wiedzy nie potrzebuje RAG wyjaśnia dlaczego.

Praca oceny leży w konfiguracji: które fakty dostają strony właścicielskie, gdzie stoją bramki przeglądu i do czego agenci mogą pisać. To mapowanie ma taki sam kształt jak zaangażowanie audytu i doradztwa AI webvise: wybór jednego przepływu pracy, zmapowanie danych wejściowych, wyjątków i punktów przeglądu, a na koniec działający prototyp i plan budowy. Warstwa wiedzy zwykle okazuje się warunkiem wstępnym dla każdej automatyzacji, która przychodzi po niej.

webvise buduje systemy wiedzy utrzymywane przez agentów oraz automatyzacje na nich oparte, z bramką ludzkiego przeglądu zachowaną w każdym przepływie pracy. Aby sprawdzić, jak to wygląda na własnych dokumentach, wystarczy skorzystać z formularza kontaktowego.