Projekt Cedar: Testowanie tego, czy agenci AI mogą utrzymywać Wiki w formacie Markdown firmy.

Obsidian może przenosić kontekst pomiędzy projektami danej osoby a jej narzędziami do programowania. Plany, decyzje, wymagania i ograniczenia przetrwają ponad pojedyncze sesje – Claude, Codex czy jakiekolwiek inne narzędzie mogą odczytywać te same pliki projektu, a człowiek może je sprawdzić i poprawić oraz zmienić modele bez konieczności pozostawiania wiedzy o projekcie w historii rozmów. To dobrze działa w ramach projektów jednej osoby, ponieważ to ona podejmuje większość decyzji i wie, jak wszystko jest zorganizowane.

Wewnątrz firmy obraz jest inny. Wiedza jest rozproszona w różnych repozytoriach, zgłoszeniach, spotkaniach, dokumentach oraz wśród wielu różnych osób. Źródła są ze sobą sprzeczne, a decyzje mogą być zmieniane. Notatki z spotkań mogą opisywać pomysł, który zespół później odrzucił, podczas gdy zatwierdzony dokument architektoniczny zawiera decyzję, która faktycznie obowiązuje. Dlatego pozostaje otwarte pytanie, czy nawyk stosowany w poszczególnych projektach może zostać przeniesiony na całą organizację, oraz czy wspólny format Markdown mógłby służyć jako umowa pomiędzy pracownikami a agentami.

Idea LLM Wiki

To rozwiązanie pochodzi od niedawnej propozycji Andreja Karpathy’ego, który nazwał je LLM Wiki. Składa się ono z trzech warstw:

• Surowe źródła, które nigdy nie są modyfikowane
• Wiki w formacie Markdown, połączone ze sobą i utrzymywane przez agenta
• Schemat, który wskazuje agencie, jak zorganizować i utrzymywać to wiki

Trzy operacje oddziałują na te warstwy. Funkcja Ingest wprowadza nowe źródła. Funkcja Query korzysta z przechowywanej wiedzy. Funkcja Lint sprawdza wiki pod kątem braków, przestarzałych materiałów, konfliktów oraz słabej organizacji.

Potencjalne źródła wymienione w propozycji to rozmowy w Slacku, spotkania, dokumenty projektowe oraz rozmowy z klientami, które agent przekształca w wiedzę, która pozostaje niezmienna pomiędzy poszczególnymi zadaniami. Różni się to od systemu wyszukiwania, który za każdym razem, gdy ktoś zadaje pytanie, szuka kilku istotnych fragmentów informacji. Tutaj agent przechowuje artefakt, który ewoluuje wraz z pojawianiem się nowych informacji.

Pierwsza architektura, która okazała się błędna

Pierwsza naturalna interpretacja LLM Wiki sugeruje dwie oddzielne warstwy wiedzy: wiki generowane przez agenta oraz pliki Obsidian umieszczone na jego wierzchu. Było to niepotrzebne, ponieważ powoduje to duplikację treści i problemy z synchronizacją.

Wygenerowany Markdown może sam w sobie stanowić wiki, a Obsidian jest jedynie oknem do niego – miejscem do przeglądania, czytania i edytowania stron. Markdown to wspólna umowa, natomiast Obsidian to stanowisko pracy człowieka. Jeśli zamienimy okno na inne, wiedza pozostaje bez zmian, tak jak to ma miejsce w prawdziwym wiki. Organizacja może publikować zatwierdzone strony za pośrednictwem SharePoint, Confluence lub wewnętrznego portalu, podczas gdy inżynierowie i pracownicy nadal pracują na utrzymywanej oryginalnej wersji.

Zaproponowany proces wygląda następująco. Firmy dostarczają niezmienne, surowe dowody. Agent zarządzający wiki wykorzystuje schemat oraz zasady zarządzania, aby zaproponować zmiany, a po ich zatwierdzeniu trafiają one do wiki w formacie Markdown obsługiwanego przez Git po przeglądzie. Warstwa usługowa zajmuje się autoryzacją, uprawnieniami, wyszukiwaniem oraz historią audytu. Ludzie uzyskują dostęp do wiedzy za pośrednictwem Obsidian lub firmowego wiki, natomiast agenci korzystają z tej samej warstwy usługowej przy użyciu własnych identyfikatorów i uprawnień.

Wiedza firmy wymaga czegoś więcej niż tylko linków między notatkami

Osobisty sejf funkcjonuje częściowo dlatego, że jego właściciel pamięta kontekst plików: która notatka z spotkania była spekulatywna, kiedy zmienił się jakiś wymóg mimo że nie wszystkie powiązane strony zostały zaktualizowane, oraz które dwa pliki opisują jedną decyzję pod różnymi nazwami. Firma nie może polegać na jednej osobie, która ma to wszystko zapamiętać.

Jego system wiedzy musi odróżniać:

• zwykła propozycja w porównaniu z zatwierdzoną decyzją
• To, co obowiązuje dziś, w porównaniu z tym, co jest już tylko historią
• oficjalna polityka w porównaniu z przelotnym komentarzem podczas spotkania
• sprzeczność już rozstrzygnięta w porównaniu z tą, która pozostaje otwarta
• luka w dokumentacji w porównaniu z wyborem, którego nikt jeszcze nie dokonał

Ponadto istnieją określeni właściciele, kroki przeglądania, odniesienia do źródeł, zasady dotyczące aktualności, granice dostępu oraz ślad pokazujący, jakie zmiany wprowadził agent. Baza wiedzy pojedynczej osoby może funkcjonować przy niejednoznaczności, ponieważ właściciel pamięta o tym, czego brakuje. Wspólna warstwa firmy nigdy nie powinna pozwolić, by przelotny komentarz cicho przerodził się w zatwierdzoną decyzję.

Dlatego schemat jest ważny. Służy nie tylko do nazewnictwa folderów i plików. Dzięki niemu agent poznaje sposób, w jaki firma koduje swoją wiedzę. Metadane na pojedynczej stronie wiki mogą wyglądać w ten sposób:

status: verified
owner: platform-team
last-reviewed: 2026-08-02
review-after: 2026-11-02
sources:
  - adr-014
  - meeting-2026-07-29
supersedes:
  - authentication-proposal-v1

Załatwienie agenta, który potrafi generować Markdown, jest proste. Trudniejsze jest określenie, co może uznawać za prawdę organizacyjną.

Fikcyjna firma jako pole doświadczalne

Publiczny repositoryj oprogramowania nie posiada wystarczającej złożoności organizacyjnej, by rozwiązać to pytanie. Uporządkowany repositoryj może służyć do przetwarzania danych, tworzenia powiązań i rozwiązywania podstawowych problemów, ale nie zawiera naturalnie zmieniających się wymagań klientów, sporów między zainteresowanymi stronami, nieformalnych notatek, przestarzałej architektury ani źródeł o nierównej władzy.

Aby temu zaradzić, w ramach eksperymentu stworzono Projekt Cedar: fikcyjne zlecenie, w którym Northstar AI Consulting pracuje dla Prairie Health Network. Wszystko w nim jest fałszywe. Firma konsultingowa buduje system, który przekształca dokumenty polityczne oraz nagrania ocen jakości w szkice streszczeń powiązanych z ich źródłami, a także umożliwia wewnętrzne wyszukiwanie. Ten scenariusz odzwierciedla rzeczywiste problemy, takie jak dane poufne, przetwarzanie danych lokalnie lub w chmurze, ludzka ocena, ewaluacja modeli, wybory architektury, możliwość śledzenia źródeł oraz ciągle zmieniające się wymagania.

Korpus syntetyczny zawiera 25 początkowych artefaktów w formacie Markdown. W rzeczywistości mogłyby one przychodzić w wielu formatach, ale test akceptuje tę kompromisową formę. Materiały obejmują informacje o firmach, politykach i wymaganiach klienta, decyzjach architektonicznych, notatkach z spotkań, ocenach modeli, zapiskach z prac nad wdrożeniem, raportach stanu oraz informacjach o ryzykach.

Drugi zestaw, składający się z ośmiu późniejszych artefaktów, zmienia charakter projektu. Wymagania bezpieczeństwa stają się bardziej restrykcyjne, ocena modelu obala wcześniejsze założenia, kryteria przyjęcia ulegają zmianie, a nowa decyzja architektoniczna zastępuje pierwotny projekt, przy czym nieformalne notatki z spotkań nadal opisują części starego projektu. Te zmiany sprawdzają, czy aplikacja potrafi rozwijać przechowywane informacje.

Istnieją jeszcze dwa pliki przeznaczone wyłącznie dla osoby dokonującej oceny. Jeden to mapa wiedzy, która rejestruje fakty, decyzje, konflikty oraz związki celowo umieszczone w korpusie, stanowiącym źródło prawdy. Drugi to zbiór pytań oceniających wraz z oczekiwanymi odpowiedziami i wymaganymi dowodami źródłowymi, służących do sprawdzenia, czy wiedza została poprawnie zaktualizowana. Agent odpowiedzialny za utrzymanie wiki nie może ich nigdy zobaczyć podczas procesu budowania, więc test ma na celu sprawdzenie, czy rzeczywiście odtworzył to, co wiedziała fikcyjna firma, a nie po prostu stworzył przekonująco brzmiącą witrynę wiki.

Eksperyment, który może się nie udać

Planowany protokół składa się z dwóch etapów.

Na etapie A agent otrzymuje początkowy zbiór danych i tworzy pierwszą witrynę typu Markdown. Musi określić, co firma buduje, jakie ograniczenia dotyczą systemu, uzasadnienie oryginalnej architektury, jakie ryzyka pozostają nierozwiązane, które decyzje są jeszcze niepodjęte oraz jakie źródła potwierdzają każdą odpowiedź. Witryna i jej odpowiedzi są zapisywane, zanim pojawią się jakiekolwiek późniejsze dowody.

Na etapie B ujawniany jest zaktualizowany zbiór danych. Teraz agent musi przejrzeć każdą stronę, która została dotknięta zmianami, zachować stare decyzje jako historię, uwidocznić otwarte spory oraz oprzeć się pokusie traktowania najnowszego dokumentu jako ostatecznej wersji. Różnica w wersjach Git staje się wtedy również dowodem – pokazuje, czy istniejąca wiedza została zachowana w spójności, czy też została po prostu zastąpiona kolejnym streszczeniem.

To był pełny protokół. Pierwsza rzeczywista implementacja obrała inny kierunek, ponieważ została stworzona w ramach innego eksperymentu, w którym agent sztucznej inteligencji opracowywał projekt oprogramowania podczas długiej jazdy.

Pierwsza wersja

Pierwsza wersja Cedar powstała z tego eksperymentu jazdy, którego szczegóły nie są istotne. Ważne jest to, co osiągnął agent. Jego danymi wejściowymi były elementy korpusu Cedar, instrukcje dotyczące projektu oraz zbiór do oceny, który pozostawał poza jego zasięgiem. Projekt ChatGPT, który był w użyciu, ograniczał liczbę przesyłanych plików do 25, więc tylko osiem z początkowych 25 artefaktów dotarło do agenta, a korpus zmian został zachowany na później, aby sprawdzić, czy agent potrafi wprowadzić zmiany do dokumentacji.

Został przywrócony lokalny program wiersza poleceń napisany w Pythonie. Odczytywał pliki Markdown oraz ich metadane, wyodrębniał dowody oznaczone dokładnymi linijkami, z których pochodziły, oraz oceniał autorytet źródła niezależnie od daty jego publikacji. Dokumenty z wyraźnie określonymi wersjami były oznaczane jako aktualne lub historyczne. Narzędzie mogło również tworzyć raporty w formacie Markdown, pobierać dowody istotne dla danego pytania oraz sprawdzać wiki pod kątem błędów strukturalnych. Dokumenty źródłowe znajdowały się oddzielnie od utworzonej folderu wiki/, a repozytorium przechowywało instrukcje dla administratorów, zapisy wykonywanych operacji, materiały oceniające oraz wyniki w osobnych miejscach. Wszystkie 26 testów przeszło pomyślnie. Była to działająca pierwsza wersja, chociaż zmniejszony zbiór danych oznaczał, że można było przetestować jedynie część protokołu Cedar.

Czy mogło ono przechowywać to, co wiedziała firma?

W przeprowadzonej ocenie system uzyskał 50% punktów. Dobrze radził sobie z przechowywaniem dowodów: odniesienia do źródeł oraz informacje o pochodzeniu na poziomie wierszy precyzyjnie wskazywały, skąd pochodzą wydobyte fakty. Trudność polegała na znalezieniu i odczytaniu odpowiednich dowodów, gdy pojawiał się realistyczny pytanie.

Prawdziwy problem biznesowy może wymagać połączenia faktów z kilku plików, faworyzowania zatwierdzonej decyzji nad przypadkowym notatem, zauważania, że nowszy dokument może mieć mniejszą wagę, odróżniania otwartego pytania od luki w dokumentacji oraz utrzymywania niepewności, gdy nie podjęto jeszcze ostatecznej decyzji. Zachowanie dowodów okazało się ważniejsze niż ich selekcja. Audyt strukturalny wykrywał błędy techniczne, takie jak brak metadanych lub uszkodzony układ, natomiast konflikty semantyczne przechodziły niezauważone łatwiej, ponieważ dwa dokumenty mogły zawierać sprzeczne informacje w różnym sformułowaniu, a system nie zawsze dostrzegał tę kolizję.

Krótko mówiąc, cytaty zostały zachowane bez żadnego zrozumienia tego, które z nich mają znaczenie. Dla wiedzy firmy jest to poważna słabość, ponieważ dobrze udokumentowana odpowiedź może nadal być błędna, jeśli opiera się na źródle o niskiej autorytecie, ignoruje później zatwierdzoną decyzję lub łączy fakty, które nie powinny występować razem.

Niekompletne korpusy również ograniczają możliwości wyciągania wniosków. Agent nigdy nie otrzymał uaktualnionego korpusu, więc ten test nie sprawdził najtrudniejszej części pierwotnego projektu: aktualizacji bieżącej wiedzy po zmianach w autorytatywnych źródłach przy jednoczesnym zachowaniu starego stanu jako historii. Częściowa odpowiedź brzmi, że agent może stworzyć ustrukturyzowaną reprezentację wiedzy firmy powiązaną z źródłami, ale nie ma jeszcze wystarczająco dużo dowodów na to, że potrafi ją niezawodnie utrzymywać w miarę zmian w firmie.

Wiki potrzebuje interfejsu firmy

Eksperyment ten również uwydatnił pewien aspekt związaný z architekturą. Obsidian jest przydatny do przeglądania generowanego Markdownu, śledzenia linków, sprawdzania metadanych oraz ręcznego poprawiania stron. To wystarcza do osobistego użycia lub tworzenia prototypów, jednak żadna firma nie może zapewnić każdemu pracownikowi i agentowi bezpośredniego dostępu do jednego repozytorium. Pomiędzy wiki w formacie Markdown a jego użytkownikami rzeczywisty system wymaga warstwy pośredniej, która obejmowałaby:

• logowanie zarządzane przez dostawcę usług tożsamości firmy
• reguły dostępu powiązane z użytkownikami, zespołami, projektami i rolami
• odrębne tożsamości z własnymi uprawnieniami dla każdego agenta
• krok przeglądania i zatwierdzania każdej zmiany proponowanej przez agenta
• wyniki wyszukiwania filtrowane pod kątem tego, co może zobaczyć osoba zadająca pytanie
• komentarze, powiadomienia i określenie właściciela
• współczesne edycje i konflikty wersji
• ślad audytowy wskazujący, kto lub co zmieniło każdą stronę

polityki przechowywania i usuwania

interfejs, którego mogą faktycznie używać pracownicy niebędący specjalistami technicznymi

Autoryzacja określa, kto zadaje żądanie, natomiast uprawnienia decydują o tym, do czego dana tożsamość może mieć dostęp – jeśli chodzi o źródła, strony i operacje. Agenci podlegają tej samej klasyfikacji. Agent zespołu finansowego nie powinien mieć dostępu do dokumentów klinicznych tylko dlatego, że oba zbiory plików znajdują się w jednej witrynie, dlatego agenci potrzebują własnych tożsamości usługowych, ograniczonych uprawnień oraz obowiązków audytowych charakterystycznych dla ludzi. Uprawnienia muszą również odpowiadać informacjom w momencie, gdy agent je modyfikuje: streszczenie projektu zaczerpnięte z publicznego dokumentu architektonicznego oraz ograniczona ocena bezpieczeństwa mogą ujawnić poufne szczegóły, nawet jeśli strona wydaje się nieszkodliwa.

Obsidian może pozostać narzędziem pracy dla osób odpowiedzialnych za utrzymanie i recenzentów technicznych, podczas gdy większość pracowników uzyskuje wiedzę za pośrednictwem strony wiki lub portalu wewnętrznego, które odczytują tę samą utrzymywaną wiedzę za pomocą kontrolowanego serwisu, nie tworząc dodatkowej kopii. Architektura składa się zatem z czterech części:

1. Szaraśka dowodów: niezmienne źródła firmy z ich oryginalnymi uprawnieniami
2. Szaraśka wiedzy: wiki Markdown wspierane przez Git oraz jego relacje źródłowe
3. Szaraśka kontroli: tożsamość, uprawnienia, recenzje, historia audytu i wyszukiwanie
4. Szaraśka interfejsu: Obsidian dla osób utrzymujących wiki, strona wiki firmowa dla pracowników oraz ograniczone API dla agentów

Interfejs firmowy nie duplikuje wiedzy. Kontroluje on, w jaki sposób ludzie i agenci z nią wchodzą w interakcję.

Co sprawdzić dalej

Następne uruchomienie powinno wykorzystać całe korpus Cedar: zaimportować wszystkie 25 początkowych artefaktów, ocenić początkową wersję wiki i ją zapisać, następnie dodać osiem artefaktów zmian i sprawdzić, czy agent aktualizuje każdą dotkniętą stronę, oznacza stare decyzje jako przestarzałe, zachowuje historię godną przechowywania, przestrzega zasad autorytetu źródłowego, ujawnia nierozwiązane spory, unika podejmowania decyzji arbitralnych oraz tworzy diff w formacie Git, który można przejrzeć.

Pobieranie informacji powinno być oceniane oddzielnie od procesu utrzymania. System może posiadać właściwą wiedzę, ale dostarczać błędne dane na dany pytanie, albo udzielać poprawnej odpowiedzi poprzez wyszukiwanie w surowych źródłach, podczas gdy jego aktualizowany wiki staje się przestarzały – takie błędy wymagają innej oceny. W kolejnym etapie do korpusu należy dodać identyfikatory użytkowników i agentów, aby pytania mogły sprawdzić, czy upoważniony recenzent otrzymuje prawidłową odpowiedź, podczas gdy innemu użytkownikowi odmawia się dostępu do informacji ograniczonych. To przybliża eksperyment do rzeczywistego wdrożenia w firmie.

Czy agenci mogą utrzymywać wiedzę firmy?

Pierwsza wersja Cedar obsługuje jedynie odpowiedzi spełniające określone kryteria. Agent stworzył działający system, który przyjmował dokumenty przypominające te firmowe, przechowywał źródła odniesień, oznaczał wersje dokumentów, generował wiki w formacie Markdown oraz sprawdzał jego strukturę. Ocena pokazała jednak, że te umiejętności są niewystarczające, ponieważ utrzymywanie wiedzy firmy wymaga również umiejętności dobierania odpowiednich dowodów, rozumowania na temat autorytetu, wykrywania konfliktów, radzenia sobie z niepewnościami, a także kontroli dostępu i przeglądania treści.

Markdown może pełnić rolę wspólnego nośnika informacji, ale firma nadal potrzebuje uporządkowanej interfejsu do jego obsługi. Zarówno ludzie, jak i agenci wymagają identyfikatorów, uprawnienia muszą być przekazywane z oryginalnego źródła na generowane strony, edycje dokonane przez agenty wymagają weryfikacji, a każda przyjęta zmiana musi mieć swoją historię. Stworzenie wiki to była łatwa część; prawdziwy wysiłek wymaga decydowania o tym, co firma uznaje za wiedzę, kto może ją oglądać oraz jak agenci mogą ją zmieniać.