Twój asystent zna coraz więcej. Co tydzień dokarmiasz go notatkami, ustaleniami, kolejnymi dokumentami — a pewnego dnia z pełnym przekonaniem podaje ci odpowiedź, która jest nieaktualna albo po prostu nieprawdziwa. Pierwszy odruch brzmi: model zgłupiał. Prawie nigdy tak nie jest. Zestarzała się twoja baza wiedzy — zbiór faktów, z którego asystent czerpie, urósł i zaczął sam sobie przeczyć.
Bazą wiedzy AI, albo „drugim mózgiem”, nazywam wszystko, czym karmisz asystenta na swój temat i na temat firmy: notatki, procedury, ustalenia, historię projektów, zapisy spotkań. To pamięć, do której sięga, zanim ci odpowie. Kłopot w tym, że sama się nie pilnuje. Im jest większa, tym łatwiej się psuje, i tym pewniej brzmi w błędzie.
Zakładam, że masz taki system już zbudowany; jeśli nie, pokazuję to od zera w osobnym tekście. Tu chodzi o coś trudniejszego: jak utrzymać go w prawdzie, kiedy rośnie. Pokażę ci cztery sposoby, na jakie psuje się jego pamięć, jak zdecydować, co trzymać w niej na stałe, a co dociągać dopiero w potrzebie, i jak regularnie sprawdzać, czy wciąż mówi prawdę.
Cztery sposoby, na jakie psuje się kontekst
Kiedy asystent poda ci coś błędnego, przyczyna prawie zawsze leży w kontekście, czyli w danych, które miał pod ręką w chwili odpowiedzi. Wyróżniam cztery tryby awarii. Warto znać wszystkie, bo każdy naprawia się inaczej.
Zatrucie. W bazie siedzi jeden fałszywy fakt: nieaktualny numer telefonu albo cena sprzed dwóch cenników. Asystent trafia na niego wśród poprawnych danych i podaje dalej — wkłada do maila do klienta, wstawia do zestawienia. Nie kłamie; sięgnął po dane, które w bazie były, i uznał je za prawdziwe. To najłatwiejsza z awarii do naprawienia, bo wystarczy weryfikacja. Każesz asystentowi sprawdzać kluczowe fakty w wyszukiwarce albo w żywym źródle, na przykład w aktualnej bazie klientów, a kiedy nie jest pewny, ma zapytać ciebie, zanim ruszy dalej. Taki człowiek w pętli kosztuje kilka sekund, a wyłapuje trujący fakt, zanim ten dojedzie do klienta.
Przeładowanie. Danych jest po prostu za dużo. Model naraz obejmuje tylko pewną ilość tekstu — to jego okno kontekstowe. Im więcej w nie wrzucisz, tym trudniej mu wyłowić jedną istotną informację z gąszczu; wprost nazywa się to szukaniem igły w stogu siana. Odpowiedź robi się rozmyta, wnika do niej to, co akurat leżało obok, choć nie miało nic wspólnego z pytaniem. Kierunek naprawy: nie trzymać wszystkiego naraz, tylko dzielić bazę i zostawiać pod ręką to, co naprawdę potrzebne. Wrócę do tego przy segmentowaniu.
Dezorientacja. Brakuje faktu albo w pobliżu leży fakt zupełnie nie na temat, a asystent zamiast przyznać „nie wiem”, wypełnia lukę czymś zmyślonym. To klasyczna halucynacja. Od zatrucia różni się źródłem błędu: przy zatruciu model powtarza gotowy fałsz, który znalazł; tutaj gubi się, bo właściwej informacji nie ma, więc dopowiada ją sam.
Sprzeczność. Dwa źródła mówią co innego, a asystent nie wie, któremu zaufać. Prosty przykład: w marcu twoja polityka brzmiała „zawsze zwracamy pieniądze”, w czerwcu zmieniła się na „nie zwracamy nigdy”. Oba zdania nadal leżą w bazie. Gdy przychodzi pytanie o zwrot, raz sięgnie po starą wersję, raz po nową, a czasem sklei z nich coś trzeciego. Kierunek naprawy: pilnować świeżości i wycofywać dane, które się zdezaktualizowały, żeby została jedna obowiązująca odpowiedź.
Co trzymać zawsze, a co dociągać na żądanie
Skoro nadmiar danych sam w sobie szkodzi, trzeba zapytać: co asystent musi mieć pod ręką zawsze, a co ma pobierać dopiero wtedy, gdy jest potrzebne. Rozdzielam wiedzę na dwie warstwy.
Pierwsza to wiedza stała, czyli twój regulamin. Kim jesteś, czym zajmuje się firma, jakie masz cele i zasady, jakim tonem piszesz. To dane, które muszą towarzyszyć każdej rozmowie, bo bez nich asystent nie rozumie, dla kogo i po co pracuje. Działają trochę jak instrukcja wgrana na starcie.
Druga to wiedza sytuacyjna, czyli pojedynczy fakt potrzebny tu i teraz. Zgłoszenie od klienta, które przyszło wczoraj. Jeden konkretny rekord z bazy. Notatka z jednego spotkania. Takich rzeczy nie ma sensu trzymać na stałe.
Lubię obraz dyrektora szkoły i nauczyciela układających plan rozsadzenia klasy. Dyrektor wie, jak w ogóle powinna działać sala: gdzie jest tablica, gdzie drzwi, na czym polega dobry układ ławek. To wiedza stała. Ale to nauczyciel ma wiedzę sytuacyjną o każdym uczniu: który słabo widzi i musi siedzieć bliżej, którzy dwaj rozgadają się, gdy usiądą razem. Tę wiedzę wnosi się w ostatniej chwili, dokładnie wtedy, gdy układa się konkretny plan.
Rzecz w tym: wpisanie wiedzy sytuacyjnej na stałe to prosta droga do przeładowania, dezorientacji i sprzeczności. Wczorajsze zgłoszenie klienta, które zostaje w bazie na zawsze, jutro jest już tylko szumem, a za miesiąc nieaktualnym faktem wprowadzającym w błąd. Dlatego zamiast trzymać wszystko, dociągasz dane dopiero w chwili, gdy musisz na coś odpowiedzieć; takie pobieranie na żądanie fachowo nazywa się RAG. We wtorek o czternastej, gdy wraca sprawa konkretnego klienta, asystent sięga po żywy zapis, wzbogaca odpowiedź o świeży fakt i zapomina o nim, zamiast wlec go za sobą tygodniami.
Decyzję, co jest wiedzą stałą, a co sytuacyjną, podejmujesz świadomie dla każdego rodzaju danych. To ona najmocniej chroni bazę przed puchnięciem. Więcej o tym, która pamięć agenta jest trwała, a która podręczna, rozkładam osobno.
Mapa, nie prompt
Na szczycie takiego systemu leży zwykle jeden główny plik — w Claude Code to CLAUDE.md. Częsty błąd, który widzę, to traktowanie go jak kolejnej instrukcji w stylu „jesteś moim asystentem, robisz to i to”. Lepiej sprawdza się w innej roli: jako mapa, spis „co gdzie mieszka”. Zamiast opisywać, kim asystent ma być, plik mówi, gdzie leżą poszczególne dane — tu jest baza wiedzy, tu zapisy spotkań, tu ustalenia, tu materiały o kliencie. Dzięki temu asystent szybko trafia do właściwych danych, a ty sam odnajdujesz je bez przekopywania całości.
Jest prosty test, czy twoja baza jest ułożona sensownie. Otwórz własny eksplorator plików i przypomnij sobie coś, co niedawno zrobiłeś. Czy potrafisz do tego dojść bez wyszukiwarki, samym klikaniem w kolejne foldery, po nazwach? Jeśli tak, układ jest na tyle intuicyjny, że poradzi sobie z nim także agent AI, zwłaszcza gdy mapa podpowie mu drogę. Jeśli sam się gubisz, asystent tym bardziej. To jest sedno inżynierii kontekstu: nie liczy się, ile wiedzy zgromadzisz, tylko jak ją ułożysz, żeby właściwa trafiała we właściwe miejsce.
Audyt: sprawdzaj bazę względem rzeczywistości
Podsunę ci nastawienie, które najbardziej tu pomaga: potraktuj bazę wiedzy jako zbiór twierdzeń o rzeczywistości, które trzeba co jakiś czas sprawdzić. Każdy spis, każdy indeks, każda notatka mówi „tak wygląda świat”, a świat w międzyczasie się zmienił. Audyt polega na porównaniu tych twierdzeń z tym, jak jest naprawdę.
Kilka konkretnych pytań kontrolnych, wszystkie w prostych słowach. Czy wszystko, na co wskazuje mapa, faktycznie istnieje — czy któryś odnośnik nie prowadzi już w pustkę? Czy spisy i listy zgadzają się z tym, co realnie leży na dysku, na przykład czy indeks nie mówi o pięćdziesięciu kilku folderach, gdy na dysku leży ich grubo ponad siedemdziesiąt? Czy każde źródło jest świeże, czy powoli się starzeje, czy zamarło zupełnie? Gdzie te same dane leżą w dwóch miejscach naraz i zaczynają sobie przeczyć?
Taki przegląd uruchamiasz regularnie, a co ważne, w pierwszym kroku każesz asystentowi tylko czytać, nigdy od razu poprawiać. Ma zebrać raport w duchu „oto, co dziś dałoby ci błędną odpowiedź”. Każde pytanie o sprawy po ostatniej aktualizacji dostanie pewną, ale nieaktualną odpowiedź; pytanie o dany projekt trafi na stare dane. Dopiero gdy przeczytasz taką listę, decydujesz, które naprawy zatwierdzić. Najpierw diagnoza i twoja zgoda, potem zmiany, nie odwrotnie.
Utrzymuj ją w formie
Audyt pokazuje, co jest zepsute w danej chwili. Żeby baza nie psuła się w kółko, potrzebujesz kilku trwałych nawyków.
Automatyzuj dociąganie danych. Część informacji wraca regularnie: notatki z cotygodniowego spotkania zespołu, zapis poniedziałkowej sesji pytań i odpowiedzi. Jeśli za każdym razem masz je wgrać ręcznie, prędzej czy później zapomnisz, a w bazie zrobi się dziura. Dlatego takie stałe dopływy podłączasz przez zaplanowaną rutynę, która sama wciąga je o ustalonej porze. Kiedy następnym razem sięgniesz do asystenta, świeży zapis już tam jest, choć nikt niczego nie wklejał.
Segmentuj, gdy rośnie. Kiedy jakiś obszar wiedzy wyraźnie puchnie i wiesz, że będzie rósł dalej, wydziel go do osobnego zbioru. Osobno zapisy spotkań, osobno zebrane materiały źródłowe, osobno teczka każdego klienta czy projektu. Dzięki temu, szukając czegoś o konkretnym kliencie, asystent przeszukuje wąski, właściwy wycinek zamiast całej bazy. Odpowiada szybciej, celniej i taniej, bo zużywa mniej tokenów na przekopywanie się przez rzeczy bez związku. To ta sama zasada, co przy przeładowaniu: im węższy obszar do przeszukania, tym mniejsza szansa na pomyłkę.
Cofnij się do przyczyny. Gdy asystent czegoś nie znajdzie — mówi „nie mam do tego dostępu”, choć wiesz, że dane tam są — albo odpowie błędnie, łatwo rzucić „więcej tak nie rób”. To nic nie daje. Zamiast tego każ mu się cofnąć i prześledzić, dlaczego się potknął: gdzie szukał, czego nie sprawdził, co przeoczył. Kiedy sam wskaże miejsce, w które powinien był zajrzeć, poprawiasz układ i odnośniki tak, żeby błąd nie mógł się powtórzyć. Naprawa przyczyny działa trwale; samo strofowanie skutku wraca za tydzień.
Baza wiedzy jest warta dokładnie tyle, ile możesz jej zaufać. Największa pokusa przy budowaniu drugiego mózgu to dokładać, dokładać i dokładać, a prawdziwa dyscyplina polega na czym innym: na pilnowaniu, żeby to, co już masz, pozostało prawdziwe. Zacznij od jednego przejścia. Każ asystentowi przejrzeć bazę tylko do odczytu i wypisać, co dałoby ci dziś błędną odpowiedź. Zanim cokolwiek dołożysz, zobacz, co warto najpierw naprawić.