Konserwacja Wiki LLM: dryf, sprzeczności i weryfikacja

Baza Wiedzy LLM (LLM Wiki) zawodzi, gdy stare fakty pozostają wiarygodne, sprzeczności stają się dopracowane, a generowane streszczenia odbiegają od swoich źródeł.

Utrzymanie jest prawdziwym produktem każdego systemu skompilowanej wiedzy. Tworzenie stron wiki jest proste w porównaniu do utrzymania ich wiarygodności przez miesiące wchłaniania danych, edycji, przepisania i nowych źródeł.

Ten artykuł omawia stronę operacyjną systemów LLM Wiki: wykrywanie dryfu, sprawdzanie sprzeczności, dyscyplinę cytowań, linting, przegląd Git i przepływy pracy utrzymaniowe. Zakłada się, że już rozumiesz podstawowy wzorzec opisany w LLM Wiki - Skompilowana wiedza, której RAG nie może zastąpić: surowe źródła są kompilowane w trwałe strony Markdown, które ludzie i agenci mogą później zapytać. Spokojne, ale stanowcze stanowisko jest takie, że LLM Wiki bez utrzymania to tylko ładniej wyglądający cmentarz wiedzy.

Co czyni utrzymanie LLM Wiki innym

Tradycyjne wiki zepsują się, ponieważ ludzie przestają je aktualizować. Systemy RAG dryfują, ponieważ korpus się zmienia, fragmenty stają się nieaktualne, metadane są słabe, a odzyskiwanie ciągle znajduje wiarygodne, ale przestarzałe fragmenty. Głębszą przyczyną jest to, że odzyskiwanie i reprezentacja rozwiązują różne problemy: odzyskiwanie można uruchomić ponownie na świeżych danych, ale reprezentację, którą już skompilowałeś, musisz aktywnie utrzymywać w stanie zgodności z prawdą.

LLM Wiki ma inny tryb awarii. Może wyglądać czysto, nawet gdy jest błędna.

Strony mogą być dobrze sformatowane. Linki mogą działać. Streszczenia mogą brzmieć zrównoważone. Ale pod tą schludną powierzchnią system mógł zgubić kluczowe fakty, połączyć niezgodne koncepcje, cytować streszczenia zamiast źródeł lub zachować starą decyzję, jakby nadal była aktualna.

Dlatego utrzymanie LLM Wiki musi sprawdzać zarówno strukturę, jak i znaczenie.

Cel utrzymania

Celem nie jest sprawienie, aby każda strona była idealna. Jest to zbyt kosztowne i zwykle prowadzi do porzucenia systemów.

Celem jest utrzymanie wiki przydatnej, inspekcjonowalnej i odzyskiwalnej.

Utrzymywana LLM Wiki powinna ułatwiać odpowiedzi na te pytania:

• Jakie źródła wspierają to twierdzenie?
• Kiedy po raz ostatni przeglądano tę stronę?
• Czy ta koncepcja się zmieniła?
• Czy istnieją sprzeczne strony?
• Czy to streszczenie jest nadal aktualne?
• Czy agent przepisał więcej, niż powinien?
• Czy możemy cofnąć złą aktualizację?
• Czy człowiek może zrozumieć, dlaczego strona mówi to, co mówi?

Jeśli odpowiedź brzmi nie, problem nie leży tylko w jakości treści. To problem projektu systemu.

Prosta pętla utrzymania

Przydatna LLM Wiki potrzebuje powtarzalnej pętli. Pętla powinna być na tyle prosta, aby można ją było często uruchamiać i na tyle ścisła, aby przechwytywać dryf, zanim stanie się niewidoczny.

Ta pętla nie jest glamorous. To jest właśnie sens.

System wiedzy staje się trwały dzięki nudnemu utrzymaniu: zachowaniu źródeł, jawnym przeglądom, przewidywalnej strukturze i małym, bezpiecznym aktualizacjom. Ten sam instinkt napędza notatki evergreen: notatka lub strona wiki zyskuje na wartości tylko wtedy, gdy ktoś ją udoskonala, zamiast zostawiać ją do zepsucia po pierwszej wersji.

Typy dryfu w LLM Wiki

Dryf wiedzy nie jest jedną rzeczą. Różne typy dryfu wymagają różnych kontroli. Dobry system utrzymania powinien je jasno nazywać.

Dryf źródłowy

Dryf źródłowy występuje, gdy zmienia się materiał źródłowy.

Na przykład narzędzie wydaje nową wersję, polityka jest aktualizowana, API się zmienia lub dostawca wycofuje starą funkcję. Stara strona wiki może nadal być dokładna dla poprzedniej wersji, ale błędna dla obecnego użycia.

Dryf źródłowy jest niebezpieczny, ponieważ stare twierdzenie może nadal być prawdziwe w kontekście historycznym. Problemem nie jest to, że twierdzenie jest fałszywe. Problemem jest to, że nie odpowiada już na bieżące pytanie.

Reakcja utrzymaniowa:

• Rejestruj daty źródeł
• Rejestruj daty ostatniego przeglądu
• Jasno oznaczaj strony specyficzne dla wersji
• Linkuj stare strony do stron zastępujących
• Unikaj mieszania starych i nowych wersji bez etykiet

Dryf koncepcyjny

Dryf koncepcyjny występuje, gdy zmienia się znaczenie terminu z biegiem czasu.

Jest to częste w AI i architekturze oprogramowania. Terminy takie jak “agent”, “pamięć”, “RAG”, “przepływ pracy”, “użycie narzędzi”, “strukturalne wyjście” i “inżynieria kontekstu” mogą szybko zmieniać znaczenie.

Wiki może przypadkowo zachować kilka znaczeń tego samego terminu bez wyjaśniania różnicy. To tworzy mylące strony, które brzmią spójnie, ale łączą niezgodne idee.

Reakcja utrzymaniowa:

• Utrzymuj strony słownika
• Dodawaj sekcje “znaczenie w tym wiki”
• Oddzielaj przeciążone koncepcje do osobnych stron
• Jawne linkowanie powiązanych znaczeń
• Unikaj pozwalania modelowi na ciche łączenie terminów

Dryf terminologiczny

Dryf terminologiczny jest mniejszy niż dryf koncepcyjny, ale nadal szkodliwy.

Występuje, gdy wiki używa wielu nazw dla tej samej rzeczy: “LLM Wiki”, “skompilowana baza wiedzy”, “wiki utrzymywana przez AI”, “wiki utrzymywana przez agenta” i “baza wiedzy Markdown”.

Niektóre warianty są w porządku. Zbyt wiele wariantów psuje wyszukiwanie, linkowanie i przegląd.

Reakcja utrzymaniowa:

• Określaj kanoniczne nazwy stron
• Trzymaj aliasy w front matter lub metadanych strony
• Przekieruj zduplikowane strony
• Lintuj pod kątem niemal zduplikowanych tytułów
• Używaj spójnego tekstu kotwic w linkach wewnętrznych

Dryf decyzyjny

Dryf decyzyjny występuje, gdy dokumentowana przeszła decyzja już nie odzwierciedla bieżącej praktyki.

Na przykład strona może mówić, że projekt używa wektorowego RAG do wszystkich wyszukiwań dokumentów, podczas gdy nowsze strony opisują przepływ pracy LLM Wiki. Oba stwierdzenia mogą być historycznie prawdziwe, ale wiki musi pokazać, które jest aktualne.

Ma to znaczenie dla notatek architektonicznych, procesów inżynierskich, strategii treści i narzędzi wewnętrznych. Ta sama dyscyplina dotyczy rejestrów decyzji w napędzanym przez AI rozwoju: strona decyzji jest wiarygodna tylko wtedy, gdy zastąpione wybory są oznaczone jako zastąpione, a nie cicho nadpisane.

Reakcja utrzymaniowa:

• Oznaczaj decyzje jako zaproponowane, zaakceptowane, zastąpione lub odrzucone
• Zachowuj daty decyzji
• Linkuj zastąpione decyzje do zamienników
• Zachowuj kontekst historyczny
• Unikaj usuwania starych decyzji bez śladu

Dryf cytowań

Dryf cytowań występuje, gdy strona cytuje źródło, ale twierdzenie już nie pasuje do tego, co źródło mówi.

Może to nastąpić po przepisaniu. Cytat pozostaje w miejscu, ale zdanie wokół niego się zmienia. Strona nadal wygląda na źródłową, ale cytacja już nie wspiera twierdzenia.

Jest to jeden z najpoważniejszych trybów awarii LLM Wiki, ponieważ tworzy fałszywą pewność.

Reakcja utrzymaniowa:

• Sprawdzaj wsparcie cytowań na poziomie twierdzenia
• Unikaj cytowania tylko streszczeń
• Zachowuj surowe źródła
• Wymagaj cytowań dla ważnych twierdzeń
• Oznacz akapity ze źródłami, ale bez bezpośredniego wsparcia
• Przeglądaj zmiany cytowań w diffach Git

Dryf strukturalny

Dryf strukturalny występuje, gdy wiki powoli traci nawigowalność.

Zamiast aktualizować stare, tworzone są nowe strony. Strony indeksowe opóźniają się. Pojawiają się zduplikowane strony. Akumulują się strony osierocone. Powiązane strony przestają łączyć się ze sobą.

Wiki nadal zawiera przydatną wiedzę, ale znalezienie i zaufanie jej staje się trudniejsze.

Reakcja utrzymaniowa:

• Lintuj pod kątem stron osieroconych
• Utrzymuj strony indeksowe
• Wykrywaj zduplikowane tematy
• Wymagaj linków zwrotnych do stron kanonicznych
• Archiwizuj zamiast rozsyłać
• Trzymaj role folderów jasne

Podstawowe pliki utrzymania

LLM Wiki nie powinna polegać na pamięci, wibracjach lub powtarzającym się promptowaniu. Potrzebuje plików operacyjnych, które mówią ludziom i agentom, jak ją utrzymywać.

Praktyczna struktura może wyglądać tak:

llm-wiki/
  raw/
    sources/
    transcripts/
    documents/
  wiki/
    index.md
    concepts/
    entities/
    projects/
    decisions/
  maintenance/
    review-log.md
    lint-report.md
    stale-pages.md
    contradiction-report.md
  rules/
    AGENTS.md
    schema.md
    style-guide.md
    citation-policy.md
    source-policy.md

Dokładne nazwy nie mają znaczenia. Role mają.

Wiki potrzebuje magazynu źródeł, skompilowanych stron, artefaktów przeglądu i zasad, które przetrwają przez sesje.

AGENTS.md

AGENTS.md powinna wyjaśniać, jak agentowi jest dozwolone działanie.

Powinien odpowiadać na pytania takie jak:

• Czy agent powinien aktualizować istniejące strony przed tworzeniem nowych?
• Kiedy powinien poprosić o przegląd?
• Jak powinien cytować źródła?
• Czy może reorganizować foldery?
• Czy może przepisać stare strony?
• Co powinien zrobić ze sprzecznościami?
• Czego nigdy nie powinien usuwać?

Przydatna zasada to:

Preferuj małe, oparte na źródłach aktualizacje zamiast szerokich przepisów.

To jedno zdanie zapobiega wielu złym nawodom utrzymania. Również rysuje przydatną granicę względem pamięci agenta: pamięć kształtuje, jak agent zachowuje się w danym momencie, podczas gdy plik zasad wiki kształtuje, co agentowi jest dozwolone zmieniać w wspólnej bazie wiedzy.

schema.md

schema.md powinna zdefiniować strukturę strony.

Na przykład:

# Tytuł Strony

## Streszczenie
Krótkie, bieżące streszczenie.

## Kluczowe twierdzenia
- Twierdzenie ze źródłem odniesienia.
- Twierdzenie ze źródłem odniesienia.

## Bieżący status
Aktualny, historyczny, zastąpiony, wersja robocza lub niepewny.

## Szczegóły
Główna skompilowana wyjaśnienie.

## Powiązane strony
Wewnętrzne linki.

## Źródła
Surowe odniesienia źródłowe.

## Notatki z przeglądu
Data ostatniego przeglądu i recenzent.

Schemat nie musi być sztywny. Ale bez schematu wiki staje się stosem niespójnych esejów. Schemat daje agentowi coś do zachowania.

citation-policy.md

Polityka cytowań powinna mówić, co wymaga źródła. Co najmniej wymagaj cytowań dla:

• Twierdzeń technicznych
• Porównań
• Zachowania produktu
• Stwierdzeń specyficznych dla wersji
• Wyników benchmarków
• Cen
• Twierdzeń prawnych lub zgodności
• Twierdzeń o bieżącym statusie
• Twierdzeń skopiowanych lub wywiedzionych ze źródła

Dobra polityka cytowań również mówi, czego nie robić. Nie cytuj skompilowanej strony, jakby była oryginalnym źródłem. Nie dołączaj cytowań do akapitów, których nie wspierają. Nie zachowuj cytatu po przepisaniu twierdzenia, chyba że źródło nadal je wspiera.

Dyscyplina cytowań to różnica między przydatną LLM Wiki a dekoracyjną pewnością.

source-policy.md

Polityka źródeł powinna zdefiniować, jak są przechowywane surowe źródła.

Na przykład:

• Zachowuj oryginalne pliki, gdy to możliwe
• Zachowuj URL-e i daty dostępu
• Przechowuj skopiowane notatki osobno od generowanych streszczeń
• Rejestruj typ źródła
• Oznaczaj źródła o niskim zaufaniu
• Unikaj nadpisywania surowego materiału
• Zachowuj zastąpione źródła, gdy wyjaśniają one decyzje historyczne

Ta polityka chroni wiki przed częstym błędem: streszczenie źródła, odrzucenie oryginału, a następnie traktowanie streszczenia jako dowodu.

To nie jest zarządzanie wiedzą. To stratowa kompresja.

Co powinien sprawdzać linter LLM Wiki

Linter powinien najpierw sprawdzać strukturę. Problemy strukturalne są łatwiejsze do automatyzacji i często ujawniają głębsze problemy semantyczne.

Przydatne kontrole strukturalne obejmują:

• Złamane linki wewnętrzne
• Strony osierocone
• Zduplikowane tytuły
• Brakujące sekcje źródłowe
• Brakujące daty przeglądu
• Strony bez linków zwrotnych
• Puste lub placeholderowe sekcje
• Bardzo długie strony bez struktury sekcji
• Strony bez przychodzących linków z indeksu
• Niespójne konwencje nazewnicze
• Nieprawidłowe front matter
• Przestarzałe “aktualne” strony starsze niż próg przeglądu

Te kontrole nie dowodzą, że wiedza jest prawdziwa. Dowodzą, że wiki jest nadal utrzymana. To jest konieczny punkt wyjścia.

Kontrole semantyczne

Kontrole semantyczne są trudniejsze, ale bardziej wartościowe.

Przydatne kontrole semantyczne obejmują:

• Twierdzenia bez bezpośredniego wsparcia źródłowego
• Dwie strony robzące niezgodne twierdzenia
• Stare decyzje prezentowane jako aktualne
• Zduplikowane koncepcje z różnymi nazwami
• Jedna strona koncepcji mieszająca kilka znaczeń
• Streszczenia, które pomijają znane ograniczenia
• Twierdzenia “najlepsze” lub “zalecane” bez kryteriów
• Twierdzenia specyficzne dla wersji bez etykiet wersji
• Strony, które sprzeczają się z nowszymi źródłami

Te kontrole nie powinny automatycznie przepisywać wiki. Zwykle powinny generować raport do przeglądu.

Bezpieczniejszy wzorzec to:

Wykrywaj automatycznie.
Wyjaśniaj jasno.
Aktualizuj świadomie.
Przeglądaj ryzykowne zmiany.

Wykrywanie sprzeczności

Wykrywanie sprzeczności to nie tylko pytanie LLM, czy dwie strony sprzeczają się ze sobą.

To może pomóc, ale jest zbyt niejasne. Lepiej porównać twierdzenia.

Przepływ pracy wykrywania sprzeczności może wyglądać tak:

To działa lepiej, ponieważ wiele pozornych sprzeczności nie jest prawdziwymi sprzecznościami.

Jedna strona może opisywać wersję 1.0, a inna wersję 2.0. Jedna strona może opisywać użycie osobiste, a inna użycie korporacyjne. Jedna strona może opisywać cel projektowy, a inna rzeczywistość implementacji.

Raport o sprzeczności powinien zawierać:

• Sprzeczne twierdzenia
• Zaangażowane strony
• Odniesienia źródłowe
• Kontekst daty lub wersji
• Prawdopodobne wyjaśnienie
• Sugestia rozwiązania
• Czy wymagany jest przegląd człowieka

Nie pozwól agentowi cicho rozwiązywać sprzeczności, mieszając oba twierdzenia w niejasny kompromis. To tworzy gładkie nonsensy.

Jak rozwiązywać sprzeczności

Istnieje kilka ważnych sposobów rozwiązania sprzeczności.

• Jeśli jedno twierdzenie jest przestarzałe, oznacz je jako zastąpione i podaj link do nowszej strony.
• Jeśli oba twierdzenia są prawdziwe w różnych kontekstach, wyraźnie podziel kontekst.
• Jeśli źródła się sprzeczają, zachowaj rozbieżność i ją wyjaśnij.
• Jeśli strona wiki wymyśliła lub uogólniła twierdzenie, usuń lub zawęż twierdzenie.
• Jeśli sprzeczność odzwierciedla rzeczywistą nierozwiązaną decyzję, stwórz lub zaktualizuj stronę decyzji.

Celem nie jest usunięcie całej napiętości. Niektóre napięcie jest przydatne. Dobra wiki pokazuje, gdzie wiedza jest rozstrzygnięta, a gdzie jest nadal niepewna.

Przegląd przestarzałych stron

Każda skompilowana strona powinna mieć status przeglądu.

Prosty blok metadanych może wystarczyć:

status: current
last_reviewed: 2026-07-10
review_after: 2026-10-10
source_confidence: medium

Dla szybko zmieniających się tematów używaj krótkich okien przeglądowych. Dla stabilnych koncepcji używaj dłuższych okien.

Okres jest mniej ważny niż nawyk. Strona bez daty przeglądu to strona, która w końcu cicho skłamie.

Aktualizacje świadome źródeł

Gdy pojawia się nowe źródło, agent nie powinien po prostu pisać nowej strony streszczenia.

Powinien zapytać:

• Czy to aktualizuje istniejącą koncepcję?
• Czy to zastępuje poprzednie źródło?
• Czy to sprzeczności z istniejącą stroną?
• Czy dodaje nową jednostkę lub termin?
• Czy zmienia zalecenie?
• Czy wymaga aktualizacji indeksu?
• Czy wpływa na strony decyzji?

Dobry przepływ pracy wchłaniania aktualizuje wiki jako graf, a nie jako stos izolowanych streszczeń.

Dlatego jedno źródło może dotknąć wiele stron. To jest normalne. Wyzwanie utrzymania polega na sprawieniu, aby te aktualizacje były małe, przeglądowe i śledzalne.

Przegląd z diffami Git

Git jest jednym z najlepszych narzędzi utrzymania dla LLM Wiki.

Nie dlatego, że Git jest modny, ale dlatego że generowana wiedza potrzebuje przeglądowej historii zmian. Diff Git pokazuje, co agent zmienił, usunął, przeniósł lub przeformułował.

Używaj Gita do przeglądu:

• Nowych stron
• Usuniętych sekcji
• Zmienionych twierdzeń
• Zmienionych cytowań
• Przemianowanych stron
• Aktualizacji indeksu
• Zmian linków
• Zmian statusu
• Szerokich przepisów

Najważniejszą nawyką przeglądu jest inspekcja usunięć. LLM często usuwa szczegóły, czyniąc prozę czystszą.

Czysta proza nie zawsze jest lepszą wiedzą.

Bezpieczna strategia commitów

Unikaj gigantycznych commitów takich jak:

Aktualizuj wiki

Używaj commitów, które wyjaśniają operację:

ingest: dodaj notatki źródłowe dla wydania embeddingu Qwen
maint: oznacz starą porównanie magazynu wektorowego jako zastąpione
lint: napraw złamane linki wewnętrzne w stronach RAG
review: zaktualizuj cytowania na stronie LLM Wiki
refactor: podziel koncepcję pamięci agenta od pamięci długoterminowej

To daje przyszłym ludziom i agentom przydatną historię.

Komunikaty commitów są częścią systemu wiedzy. Wyjaśniają, dlaczego wiki się zmieniła.

Poziomy przeglądu

Nie każda strona potrzebuje takiego samego poziomu przeglądu. Używaj przeglądu opartego na ryzyku.

Zmiany o niskim ryzyku:

• Naprawy złamanych linków
• Porządkowanie formatowania
• Dodawanie linków zwrotnych
• Dodawanie wpisów indeksowych
• Poprawki literówek
• Dodawanie aliasów

Zmiany o średnim ryzyku:

• Dodawanie streszczeń źródłowych
• Tworzenie nowych stron koncepcyjnych
• Aktualizowanie zaleceń
• Łączenie zduplikowanych stron
• Zmiana statusu strony

Zmiany o wysokim ryzyku:

• Usuwanie twierdzeń
• Przepisywanie stron kanonicznych
• Zmiana rejestrów decyzji
• Aktualizowanie twierdzeń dotyczących bezpieczeństwa, prawa, cen lub benchmarków
• Rozwiązywanie sprzeczności
• Oznaczanie treści jako aktualnych lub zastąpionych

Zmiany o wysokim ryzyku powinny otrzymać przegląd człowieka. Może to być Ty, opiekun lub właściciel domeny.

Agent może przygotować zmianę, ale nie powinien być zawsze ostateczną władzą.

Dashboard utrzymania

Prosty dashboard utrzymania może istnieć w Markdown.

Przykład:

# Dashboard Utrzymania LLM Wiki

## Potrzebne przeglądu
- wiki/concepts/agent-memory.md - przegląd przeszedł termin
- wiki/projects/search-index.md - znaleziono sprzeczne twierdzenia

## Przestarzałe strony
- wiki/tools/ollama.md - ostatni przegląd 120 dni temu
- wiki/concepts/rag.md - szybko zmieniający się temat, przegląd due

## Złamane linki
- wiki/index.md -> wiki/concepts/old-page.md

## Strony osierocone
- wiki/entities/vendor-x.md

## Raporty o sprzecznościach
- reports/contradictions/2026-07-10-agent-memory.md

## Ostatnie wchłaniania
- raw/sources/2026-07-09-new-paper.md

To nie jest fancy panel administracyjny. To jest powierzchnia robocza.

Dla wielu systemów solo lub małych zespołów dashboard Markdown wystarcza.

Metryki zdrowej LLM Wiki

Możesz śledzić zdrowie wiki bez nadmiernego inżynierowania.

Przydatne metryki obejmują:

• Liczbę stron
• Strony bez źródeł
• Strony bez dat przeglądu
• Strony przekraczające datę przeglądu
• Złamane linki wewnętrzne
• Strony osierocone
• Zduplikowane tytuły lub aliasy
• Otwarte raporty o sprzecznościach
• Rozwiązane raporty o sprzecznościach
• Średni wiek strony w klastrze
• Surowe źródła jeszcze niewchłonięte
• Strony zmienione bez przeglądu człowieka
• Strony kanoniczne zmienione w ciągu ostatnich 30 dni

Te metryki nie są liczbami wizerunku. Mówią Ci, czy system staje się łatwiejszy czy trudniejszy do zaufania.

Rosnąca wiki z rosnącymi stronami osieroconymi i przestarzałe przeglądy nie kompują wiedzy. Kompują dług utrzymania.

Prompty utrzymania

Prompty utrzymania powinny być wąskie. Szerokie prompty produkują szerokie przepisy.

Prompt Lint Strukturalnego

Przeglądaj strukturę wiki.

Sprawdź:
- złamane linki wewnętrzne
- strony osierocone
- zduplikowane lub niemal zduplikowane tytuły stron
- strony bez sekcji źródłowych
- strony bez metadanych last_reviewed
- strony indeksowe, które nie łączą się z nowymi stronami

Nie przepisz treści.
Wygeneruj raport Markdown z ustaleniami i sugerowanymi poprawkami.

Prompt Przeglądu Cytowań

Przeglądaj cytowania dla wybranej strony.

Dla każdego ważnego twierdzenia:
- zidentyfikuj wspierające źródło
- sprawdź, czy źródło bezpośrednio wspiera twierdzenie
- oznacz twierdzenia ze słabym, brakującym lub niezgodnym wsparciem
- nie przepisz strony jeszcze

Zwróć tabelę z:
twierdzenie, bieżące cytowanie, poziom wsparcia, problem, sugerowana akcja.

Prompt Sprawdzania Sprzeczności

Sprawdź tę stronę pod kątem sprzeczności ze stronami powiązanymi.

Kroki:
1. Wyciągnij główne twierdzenia ze strony.
2. Znajdź powiązane strony przez linki, linki zwrotne, aliasy i wyszukiwanie.
3. Wyciągnij potencjalnie sprzeczne twierdzenia.
4. Klasyfikuj każdy konflikt jako:
   - prawdziwa sprzeczność
   - różnica wersji
   - różnica zakresu
   - różnica terminologiczna
   - nierozstrzygnięta niepewność
5. Zaleć rozwiązanie.

Nie edytuj plików, dopóki raport o sprzeczności nie zostanie przeglądnięty.

Prompt Przeglądu Przestarzałych Stron

Przeglądaj tę stronę pod kątem przestarzałości.

Sprawdź:
- daty
- twierdzenia specyficzne dla wersji
- zachowanie narzędzi
- zalecenia
- linki do zastąpionych stron
- źródła nowsze niż data przeglądu strony
- twierdzenia oznaczone jako aktualne bez niedawnego wsparcia

Zwróć:
- zachowaj aktualne
- potrzebna aktualizacja
- oznacz historyczną
- oznacz zastąpioną
- podziel na strony wersjonowane

Prompt Bezpiecznej Aktualizacji

Zaktualizuj wybraną stronę wiki, używając dostarczonego źródła.

Zasady:
- zachowaj istniejącą przydatną strukturę
- nie usuwaj twierdzeń ze źródłem, chyba że źródło jest zastąpione
- dodaj cytowania dla nowych twierdzeń
- jawne oznaczanie niepewności
- aktualizuj powiązane strony tylko wtedy, gdy to konieczne
- dodaj notatkę przeglądu wyjaśniającą, co się zmieniło
- trzymaj diff mały

Te prompty nie są magiczne. Są barierami ochronnymi. Prawdziwa wartość pochodzi z czynienia działania utrzymania jawnym.

Częste błędy utrzymania

Pierwszym błędem jest pozwolenie agentowi na przepisanie zbyt dużo.

Duże przepisy wydają się produktyjne, ponieważ czynią strony gładkimi. Również czynią trudniejszym zobaczenie, co się zmieniło, i łatwiejszym zgubienie ostrych szczegółów.

Drugim błędem jest traktowanie generowanych streszczeń jako źródeł.

Streszczenie może być przydatne, ale nie jest dowodem. Zachowuj surowe źródła i cytuj je, gdy twierdzenia są ważne.

Trzecim błędem jest tworzenie nowych stron zamiast aktualizowania starych.

To produkuje zduplikowane koncepcje, sprzeczne zalecenia i zamieszanie w wyszukiwaniu. Agent powinien najpierw szukać, drugie aktualizować i tworzyć nowe strony tylko wtedy, gdy koncepcja jest naprawdę nowa.

Czwartym błędem jest usuwanie kontekstu historycznego.

Stare decyzje, nieudane eksperymenty i zastąpione zalecenia mogą być wartościowe. Oznaczaj je jasno zamiast wymazywać.

Piątym błędem jest zapomnienie o indeksach.

Strona, która nie jest powiązana z odpowiedniego miejsca, jest półstracą. Utrzymanie indeksu to nie praca kancelaryjna. To architektura nawigacji.

Szóstym błędem jest używanie tej samej polityki przeglądu dla każdej strony.

Stabilna strona koncepcyjna i szybko zmieniające się porównanie narzędzi nie powinny mieć tego samego harmonogramu przeglądu.

Archiwizuj, zastąp lub usuń

Większość przestarzałych stron nie powinna być natychmiast usunięta.

Zastąpiona strona powinna linkować do zamiennika.

Na przykład:

Status: superseded
Superseded by: wiki/concepts/agent-memory-architecture.md
Reason: This page used an older definition of agent memory before the project separated session memory, user memory, and compiled knowledge.

To zachowuje kontekst i redukuje zamieszanie.

Usuwanie powinno być rzadkie i przeglądowe. Systemy wiedzy potrzebują przycinania, ale niewidzialne przycinanie jest niebezpieczne.

Strony kanoniczne potrzebują dodatkowej troski

Każda LLM Wiki ostatecznie rozwija strony kanoniczne.

Są to strony definiujące kluczowe koncepcje, wybory architektury, przepływy pracy lub słownictwo projektu. Są ważniejsze niż zwykłe notatki, ponieważ wiele innych stron od nich zależy.

Przykłady:

• Co to jest LLM Wiki
• RAG vs skompilowana wiedza
• Pamięć agenta
• Polityka źródeł
• Przepływ przeglądu
• Architektura projektu
• Słownik
• Indeks

Zmiany w stronach kanonicznych powinny wymagać ścisłego przeglądu.

Mały błąd na nieznanej stronie jest lokalny. Mały błąd na stronie kanonicznej może zniekształcić całą wiki.

Jak często należy uruchamiać utrzymanie

Dla aktywnej LLM Wiki uruchamiaj małe utrzymanie często i głębokie utrzymanie okazjonalnie.

Harmonogram powinien pasować do ryzyka. Osobista wiki badawcza może być lżejsza. Wiki używana do publikacji technicznych, obsługi klienta lub decyzji inżynierskich potrzebuje więcej dyscypliny.

Używanie LLM Wiki do publikacji technicznych

Dla bloga technicznego lub strony dokumentacji, LLM Wiki może stać się warstwą wiedzy za planowaniem artykułów.

Może śledzić:

• Kanoniczne wyjaśnienia
• Powtarzające się definicje
• Szanse na linki wewnętrzne
• Przestarzałe porównania
• Luki w artykułach
• Klastry tematyczne
• Notatki źródłowe
• Decyzje dotyczące struktury
• Twierdzenia wymagające weryfikacji

To jest przydatne, ale podnosi poprzeczkę utrzymania.

Jeśli wiki karmi opublikowane artykuły, to przestarzałe strony wiki mogą stać się przestarzałą treścią publiczną. Jeśli wiki zawiera sprzeczności, te sprzeczności mogą przeciekać do artykułów. Jeśli cytowania są słabe, generowane szkice odziedziczą tę słabość. Zakresowe streszczenia, ekstrakcja oparta na schemacie i pętle przeglądu człowieka opisane w AI dla zarządzania wiedzą: rzeczywiste przepływy pracy, które trzymają się są dobrym szablonem do utrzymania tego procesu redakcyjnego w uczciwości.

Dla przepływów publikacyjnych traktuj LLM Wiki jako system redakcyjny, a nie tylko prywatny notes. Ogród cyfrowy czyni to jawnym, pokazując czytelnikom, które strony wciąż rosną, a które są dojrzałe, co jest dokładnie rodzajem sygnału statusu, który dobrze utrzymana LLM Wiki również powinna eksponować.

Utrzymanie nie jest opcjonalne

LLM Wiki jest atrakcyjna, ponieważ obiecuje kompującą wiedzę.

Ale kompując tylko wtedy, gdy stara wiedza pozostaje przydatna. W przeciwnym razie system kompuje szum, a nie wgląd.

Ciężar utrzymania nie znika, bo zaangażowany jest agent. Zmienia kształt.

Ludzie nie muszą robić każdej nudnej zadania. Agenci mogą sprawdzać linki, znajdować przestarzałe strony, porównywać twierdzenia, tworzyć raporty i proponować aktualizacje. Ale ludzie nadal muszą ustalać politykę, przeglądać ryzykowne zmiany i decydować, co wiki ma prawo znaczyć.

To jest prawdziwy układ.

Wniosek

Utrzymanie LLM Wiki polega na utrzymaniu skompilowanej wiedzy uczciwej.

Ważne praktyki nie są skomplikowane: zachowuj źródła, cytuj twierdzenia, utrzymuj bieżące indeksy, wykrywaj sprzeczności, przeglądaj diffy Git, oznaczaj przestarzałe strony i unikaj szerokich, nieprzeglądanych przepisów.

Dobra LLM Wiki nie udaje, że jest magicznie samokorygująca. Ułatwia korektę.

To jest standard, do którego warto dążyć: nie doskonała wiedza, ale inspekcjonowalna wiedza, która może być przeglądana, naprawiana i zaufana z biegiem czasu.