Rejestr luk. Miejsce, w którym osiada doświadczenie mojego agenta AI

Dwa tygodnie temu mój agent Alex AI podał klientowi zły cennik. Nie z głowy, tylko z naszego wewnętrznego dokumentu, tyle że ze starej wersji, obok której leżała nowsza. Zdarzyło się to trzeci raz w miesiącu. Za każdym razem tłumaczyłem sobie, że model się „nauczy”, że kolejnym razem będzie ostrożniejszy. Za każdym razem miałem rację ze dwa dni, dopóki nie wróciłem do tego samego pytania po tygodniu, w nowej sesji, z czystą pamięcią. Wtedy Alex znowu grzecznie podawał pierwszą liczbę, jaką znalazł.

I wtedy zrozumiałem coś, co powinienem zrozumieć wcześniej. Doświadczenie mojego agenta parowało po każdej sesji. Bez wyjątku. Nauka trwała dokładnie tyle, ile trwała rozmowa, w której go poprawiłem. Potem wszystko wracało do zera, bo nie miał gdzie tej lekcji odłożyć. Prowadzę agencję AI dla MŚP i wszystko, czego uczę klientów, najpierw testuję na sobie - opowiem, jak zbudowałem swojemu asystentowi coś, co sam nazywam rejestrem luk, ile to naprawdę kosztowało w tokenach i co się zmieniło, kiedy zaczął sam siebie napominać, zanim zdąży się pomylić.

Spis treści

• Skąd się to w ogóle wzięło
• Dlaczego reguła, a nie opis zdarzenia
• Jak to fizycznie działa w moim systemie
• Ile mnie kosztuje trzymanie doświadczenia w promptu
• Kiedy Alex po raz pierwszy sam siebie zatrzymał
• Reguły, których agent nigdy nie widzi, ale ja tak
• Czego już wiem, że nie wolno mi zrobić
• Co to zmienia w pracy z AI w małej firmie
• Słownik pojęć

Skąd się to w ogóle wzięło

Wracam do tego cennika, bo od niego wszystko się zaczęło. Klient zapytał w mailu o wycenę produktu, którego cenę zmienialiśmy trzy razy w ciągu roku. W naszym systemie plików leżały cztery wersje dokumentu - w różnych folderach, część z datą w nazwie, część bez. Alex miał do dyspozycji je wszystkie, bo mój agent wiedzy przeszukuje całą bazę firmową. Wybrał tę, która wyszła w wyszukiwaniu pierwsza. Nie tę najnowszą - tę najbardziej podobną leksykalnie do pytania. Podał liczbę sprzed dwóch aktualizacji. Klient chciał podpisać.

Wychwyciłem to na czas, ale przez pół dnia nie mogłem sobie darować. Nie dlatego, że pomylił się model - modele się mylą, taka ich natura, i nie za to płacę. Zawiodłem ja, bo widziałem, jak dwa razy przed tym Alex robił dokładnie ten sam błąd, tylko przy innych dokumentach. Za każdym razem gadałem z nim w bieżącej sesji, tłumaczyłem, prosiłem, żeby sprawdzał daty. On się zgadzał, poprawiał w tej rozmowie i szedł dalej. Ale każda taka nauka miała datę ważności równą długości sesji.

Rozmawiałem o tym z Jarkiem - sam ze sobą, bo Jarkiem jestem tutaj ja, i to trochę zabawne, że sam do siebie mówię „Jarek”, ale tak wygląda praca z agentem, którego się buduje. Padło zdanie, które we mnie osiadło: *„tylko doświadczenie może nam pokazać, gdzie jest luka”*. Zgadza się. Tylko że doświadczenie, którego nie ma gdzie odłożyć, przestaje być doświadczeniem. Staje się nastrojem sesji.

Musiałem zbudować mu miejsce, w którym to doświadczenie osiądzie. Fizyczne. Trwałe. Wchodzące do jego głowy zanim mnie usłyszy, nie po tym, jak się pomyli.

Dlaczego reguła, a nie opis zdarzenia

Pierwsza próba była naiwna. Otworzyłem zwykły plik z notatkami i zacząłem tam wpisywać, co Alex spartaczył: „11.07 podał zły cennik produktu X”, „19.07 pomylił nazwisko klientki, bo w bazie były dwie wersje pisowni”, „02.08 wysłał maila w nowym wątku zamiast odpowiedzieć w istniejącym”. Sześć wpisów w tydzień. Wrzuciłem to do jego promptu jako „poprzednie błędy”. Sprawdziłem, jak zadziała. Nic się nie zmieniło. Naprawdę nic. Alex czytał, kiwał metaforyczną głową i szedł popełnić błąd numer siedem.

Utknąłem na tym na kilka dni, aż w końcu do mnie doszło, na czym polega różnica. Opis zdarzenia mówi, co się stało. Reguła mówi, co masz zrobić, żeby to się nie powtórzyło. Dla modelu językowego to nie jest niuans - to są dwie zupełnie różne kategorie informacji. Zdanie *„podałeś zły cennik Sendavika”* jest dla niego opowieścią z przeszłości, którą może co najwyżej pokiwać. Zdanie *„przy każdej kwocie podaj datę źródła; przy kilku wersjach wymień wszystkie”* jest instrukcją, którą może wykonać teraz, w tej odpowiedzi.

Przerobiłem wszystkie sześć zdarzeń na sześć reguł. Wyrzuciłem daty, wyrzuciłem imiona, wyrzuciłem historię - została goła checklist. „Nazwiska zawsze z pola *corrections* w bazie kontaktów, nawet jeśli sam znasz inną wersję.” „Odpowiedź na maila w wątku, nie w nowym mailu; reply-all, chyba że wyraźnie proszę inaczej.” „Zanim powiesz *gotowe*, sprawdź, że to naprawdę zadziałało - nie tylko, że kod się wykonał.” Każda z nich wyprowadzona z konkretnego wpadku, ale zapisana tak, żeby model mógł ją wykonać, a nie tylko przeczytać.

I to zaczęło działać. Ale tylko dlatego, że reguła w tej formie rozstrzyga zachowanie, a nie oczekuje interpretacji. Model nie musi rozumieć historii Sendavika, żeby wiedzieć, że przy każdej kwocie ma podać datę. To ta sama różnica, co między „staraj się nie spóźniać” a „wychodź z domu o siódmej piętnaście”. Pierwsze jest życzeniem, drugie jest procedurą. Życzenia AI grzecznie potwierdza. Procedury wykonuje.

Jak to fizycznie działa w moim systemie

Konstrukcja jest banalna, jak zwykle w rzeczach, które działają. Jest jeden plik JSON, w którym siedzą wszystkie reguły z numerami, treścią i krótkim polem „skąd”, żebym za pół roku wiedział, dlaczego to zdanie w ogóle się tam znalazło. Jest mała biblioteka, która ten JSON czyta, sortuje reguły według dwóch kryteriów - dla kogo są przeznaczone i czy są twarde, czy miękkie - i skleja z tego blok tekstu.

Ten blok wchodzi do promptu systemowego Alexa, czyli tej części, którą model widzi na samym początku każdej rozmowy, zanim padnie pierwsze pytanie. Nie doklejam reguł per zadanie, tylko raz, w warstwie systemowej. Jest to ważne, ale zanim wyjaśnię dlaczego, powiem, jak wygląda zawartość.

Twarde reguły stoją nad miękkimi, bo model - jak człowiek czytający regulamin - lepiej trzyma się początku niż końca. Przy każdej regule jest identyfikator w rodzaju L001, L002 i tak dalej. Nie po to, żeby wyglądało profesjonalnie, tylko po to, żeby Alex mógł na tę regułę powołać się w swojej odpowiedzi. Bez identyfikatora nie da się zliczyć, która reguła realnie coś zmieniła, a która wisi tam dla ozdoby.

Wokół tego jest jeszcze narzędzie w linii komend - żeby dodać nową regułę, nie muszę edytować pliku ręcznie. Wpisuję `dodaj`, mały skrypt pyta mnie o trzy rzeczy - kiedy reguła się aktywuje, jak brzmi i skąd się wzięła - i sam zapisuje ją w formacie, z którym reszta systemu umie rozmawiać. Trzy pytania. Trzydzieści sekund. Reguła jest w promptu przy najbliższej sesji.

Cała infrastruktura to jeden plik danych i jedna klasa z siedmioma metodami. Napisanie zajęło mi popołudnie. Piszę o tym tak drobiazgowo, bo w AI dla małych firm najczęściej stracone pieniądze to nie te wydane na skomplikowane wdrożenia, tylko te wydane na budowanie w wielkim stylu czegoś, co powinno się mieścić w jednym pliku. Rejestr luk mieści się w jednym pliku. I to jest cała jego siła.

Ile mnie kosztuje trzymanie doświadczenia w promptu

To jest pytanie, którego w większości tekstów o AI się nie zadaje, bo psuje narrację o darmowym cudzie. Trzymanie ośmiu twardych reguł w promptu systemowym kosztuje mnie w tej chwili około 700 tokenów. Doliczyłbym drugie tyle na miękkie, gdybym je włączył wszystkie. Powiedzmy okrągły tysiąc.

Tysiąc tokenów wchodzących do modelu przy każdym zapytaniu - w cenniku dużego modelu klasy Opus to jest kilka groszy za wywołanie. Wywołań miesięcznie robimy tysiące. Bez ostrożności byłoby to widać na fakturze bardzo szybko. Dlatego kluczowa jest jedna decyzja, o której chcę powiedzieć wprost: reguły idą do części promptu, która jest buforowana, a nie do tej, która za każdym razem leci do modelu na nowo.

Wyjaśnię to porządnie. Duże modele mają mechanizm zwany prompt cachingiem. Fragment promptu, który się nie zmienia - u nas prompt systemowy - jest po pierwszym wywołaniu utrzymywany po stronie dostawcy w postaci już przetworzonej. Kolejne wywołania w tej samej sesji nie płacą za jego wprowadzenie po raz drugi, tylko za sam nowy fragment, czyli moje pytanie. Koszt bufora to jakieś dziesięć procent normalnej ceny wejścia. Innymi słowy: doklejenie tysiąca tokenów reguł do promptu systemowego, przy sensownej sesji, kosztuje jak sto tokenów, a nie tysiąc.

Widziałem projekty, w których ktoś doklejał reguły do każdego zapytania osobno - to znaczy do fragmentu, który przy każdym wywołaniu leci od nowa. W małej skali to nawet działa, w większej dopala fakturę tak, że wdrożenie przestaje mieć sens. To jest ten moment, w którym różnica między „wdrożyłem AI” a „wdrożyłem AI, wiedząc jak to naliczają” zaczyna być liczona w tysiącach złotych. Napisałem o tym więcej w tekście o kosztach AI w mojej agencji, bo to jedna z najczęściej pomijanych pułapek u początkujących.

Rejestr luk mam więc w buforze. Płacę za wprowadzenie reguł raz na sesję, nie raz na pytanie. Osiem reguł to koszt zaokrąglony do zera. Osiemdziesiąt też będzie do przełknięcia. Osiemset - już nie i wtedy trzeba będzie mądrzej ładować, ale to zmartwienie na inny rok.

Kiedy Alex po raz pierwszy sam siebie zatrzymał

Ten moment pamiętam, bo mnie zaskoczył.

Rejestr działał od dwóch dni. Zapytałem Alexa o cennik Sendavika - właśnie ten, na którym się poprzednio przejechał. Nie zasygnalizowałem żadnego kontekstu, żadnego przypomnienia, żadnego „uważaj, bo już raz podałeś zły”. Zwykłe pytanie. I dostałem odpowiedź, która zaczynała się od zdania mniej więcej takiego: *„Uwaga L001, w bazie są cztery wersje cennika, najświeższa nosi datę 27 czerwca 2026, poniżej podaję z niej, ale przed wysłaniem do klienta zweryfikuj, czy nie pojawiła się kolejna”*.

Zapatrzyłem się w to zdanie na dłuższą chwilę. Nie dlatego, że jest szczególnie mądre - to jest banał. Zapatrzyłem się, bo Alex sam podpisał się pod regułą, o której istnieniu nie wiedziałby, gdybym mu jej nie doklejał do promptu systemowego. Wskazał ją identyfikatorem, jakby to była procedura pracowniczej biurowej rutyny. Pierwszy raz miałem wrażenie, że rozmawiam z asystentem, który się uczy między dniami, a nie z bardzo dobrym stażystą, który każdego ranka przychodzi na pierwszy dzień pracy.

To była miła chwila, ale ważniejsze było to, co przyszło potem. Ponieważ Alex cytuje identyfikator w swoich odpowiedziach, po prostu zliczam, ile razy dana reguła zadziałała. Zwykłe grepowanie logów, żadna magia. Reguła L001, czyli ta o cennikach, w ciągu pierwszego tygodnia zadziałała szesnaście razy - piętnaście przy naszych własnych produktach, raz przy klienckim dokumencie, w którym były trzy różne wersje umowy. Reguła L004, „zanim usuniesz cokolwiek nieodwracalnego, pokaż listę i poczekaj na akceptację”, zadziałała dwa razy. Reguła L006, o wygaszaniu list zadań, zero razy.

Ta ostatnia informacja jest cenniejsza od pozostałych. Zero trafień w tydzień to sygnał, że reguła albo dotyczy sytuacji, która się nie zdarza, albo została napisana tak, że model jej nie rozpoznaje w kontekście. W obu przypadkach ma to konsekwencję: reguła wisi w promptu za darmo i przyda się jej refaktoryzacja albo skasowanie. Bez identyfikatorów nigdy bym tego nie wiedział. Miałbym po prostu pęczniejącą listę „mądrości”, które konsumują tokeny i nie robią nic. Widziałem takie listy u klientów, którzy próbowali wdrażać własne prompty inżynieryjne. Rosną w miesiąc do rozmiarów małej książki.

Reguły, których agent nigdy nie widzi, ale ja tak

Zaskoczyło mnie też, że rejestr, który zbudowałem dla Alexa, zaczął mi się przydawać do siebie. Nie do rozmów, do pracy w ogóle - do tego, co robię ręcznie na serwerach klientów, do audytów bezpieczeństwa, do decyzji, których nie oddaję maszynie.

Podzieliłem reguły na trzy odbiorców. Część idzie do wszystkich agentów w firmie, część tylko do Alexa - bo dotyczy jego specyfiki, na przykład sposobu wysyłania maili - a część jest oznaczona jako „dla mnie”, ludzka. Te ostatnie nie trafiają nigdzie do promptu, po prostu leżą w tym samym pliku, żebym miał je pod ręką, kiedy siadam do robót ryzykownych. Traktuję je jak checklist pilota przed startem. Nie dlatego, że ich nie znam - dlatego, że pod presją zawsze zapomnę tej jednej rzeczy, której nie wolno mi zapomnieć.

Kilka z nich, dosłownie, bez upiększeń:

• *Backup weryfikujesz odczytem, nie tym, że widnieje na liście.* To kosztowało mnie w lipcu sprostowanie do jednej z osób z zespołu, bo w pierwszej diagnozie powiedziałem, że kopia zapasowa jednej ze stron klienta jest do niczego, a po sprawdzeniu odczytem okazało się, że stanowi wszystko, czego potrzebowaliśmy.
• *Dyrektywa `Disallow:` w robots.txt konserwuje spam w indeksie Google, nie usuwa go.* Bot nie wejdzie, więc nie zobaczy statusu 410. Do usuwania wchodzi 410 Gone, a nie blokada w robots.txt. Wpisałem odruchowo, cofnąłem po godzinie, ale ta godzina wystarczyła, żebym już nigdy nie chciał tego powtórzyć.
• *Nazwa wpisu w bazie nie dowodzi jego niewinności.* Trzeba dekodować duże wartości, bo backdoory potrafią się nazywać `_site_transient_health_...` i podszywać się pod systemowe rekordy WordPressa. Dwa razy w tym miesiącu prawie odhaczyłem ślad włamania jako „to nasza rzecz”.
• *Daty na plikach są sfałszowane.* Chronologię buduj na kopiach zapasowych i zewnętrznych logach, bo atakujący cofnął `mtime` o rok, żeby zniknąć z osi czasu.
• *Cisza w porcie nie znaczy, że jest zamknięty.* Brak potwierdzenia SYN-ACK i brak odrzucenia RST to DROP - filtr wcześniej łyknął pakiet i nie odpowie na niego nigdy. Sprawdzać wszystkie warstwy filtrowania, nie tylko regułę firewalla.

Widzę w tym coś ciekawego. Reguły dla mnie nie różnią się formą od tych dla agenta. Też są procedurą, nie opowieścią. „Backup weryfikujesz odczytem” to instrukcja, którą wykonujesz. „Wtedy w lipcu nie sprawdziłem backupu i wyszedłem na durnia” to opowieść, którą sobie opowiadasz. Pierwsze zmienia zachowanie, drugie zmienia nastrój. Ja też, w tym sensie, jestem modelem, który lepiej wykonuje niż wspomina.

Czego już wiem, że nie wolno mi zrobić

Rejestr istnieje od dwóch tygodni, więc pułapek, o które sam się otarłem, jest dopiero kilka - ale są konkretne i wolę je od razu zapisać, żebyśmy - ty i ja, jeśli zechcesz iść tą samą drogą - nie musieli ich przechodzić na własnej skórze.

Nie doklejaj reguł do każdego zapytania. Wiem, że pisałem o tym wyżej, ale powtórzę, bo widziałem projekty, w których świetne pomysły zabił rachunek. Prompt systemowy, buforowany - to jest właściwa warstwa. Jeżeli twój dostawca modelu nie ma prompt cachingu, sprawdź, ile go to naprawdę kosztuje, zanim zbudujesz cokolwiek na produkcji.

Nie pisz reguł jako opowieści. Model przeczyta, pokiwa, pójdzie dalej. Jeśli po tygodniu widzisz, że dana reguła ma zero trafień, spróbuj przeformułować - może zaczyna się od słów, które model interpretuje jako „historia”, a nie „instrukcja”. Bardzo pomaga zdanie w trybie rozkazującym, w drugiej osobie, teraz. „Podaj datę”, a nie „warto podawać datę”.

Nie zostawiaj reguł bez wygaszania. Rejestr będzie pęczniał. Za pół roku będziesz miał sześćdziesiąt reguł i nie będziesz wiedział, które z nich w ogóle się jeszcze aktywują. Właśnie dlatego zliczam trafienia. To nie jest ozdobnik - to jest sitko, przez które przepuszczam listę raz na kwartał. Reguły bez trafień w tym okresie odchodzą, chyba że dotyczą zdarzenia, o którym wiem, że jest rzadkie, ale kosztowne (na przykład kasowanie danych - to zostaje, nawet jeśli w tym kwartale nie zadziałało ani razu).

Nie kopiuj reguł do trzech miejsc naraz. Wcześniej trzymałem tę samą lekcję i w rejestrze luk, i w moich notatkach twórczych, i w pliku z konwencjami. Trzy egzemplarze tej samej myśli. Kiedy zmieniałem jedną, dwie pozostałe wisiały nieaktualne miesiącami. Reguła ma jeden dom. Reszta miejsc może do niej linkować.

Co to zmienia w pracy z AI w małej firmie

Mam wrażenie, że opowiadam tu o czymś technicznym, ale zwabił mnie tu wniosek, który jest zupełnie nietechniczny. Chodzi o to, że doświadczenie w AI nie jest darmowe. Trzeba zbudować mu miejsce, żeby zostało. Inaczej trafisz w tę samą ścianę drugi raz w tym samym miejscu, a między jedną a drugą sesją nie wydarzy się nic - żaden model nie „się nauczy”, żaden nie „zapamięta z rozmowy”. Zapominanie jest u nich stanem domyślnym.

W małej firmie ma to konkretną konsekwencję. Jeżeli wdrażasz asystenta, który ma robić coś powtarzalnego - pisać maile, wystawiać dokumenty, klasyfikować sprawy - musisz od pierwszego dnia założyć, że pojawi się miejsce, w którym twoje uwagi do jego pracy będą siadały. Nie w twojej głowie, nie w wątku rozmowy, nie w mailu, którego wysłałeś do samego siebie o północy. W pliku, który agent czyta przy każdym starcie, w formie procedury, a nie w formie opowieści. To jest, moim zdaniem, brakujący etap większości wdrożeń AI, które widziałem u innych. Ludzie kupują model, integrują go z pocztą, cieszą się przez trzy tygodnie, a potem zapadają się w miejscu, bo model powtarza te same wpadki i nikt nie ma jak temu zaradzić.

Powiem jedną rzecz nietaktowną: to nie AI musi się nauczyć. To ty musisz zbudować mu miejsce, w którym twoje doświadczenie z pracy z nim osiądzie. Model jest tylko silnikiem. Rejestr luk jest skrzynią biegów. Bez skrzyni biegów silnik kręci na jałowym, spala paliwo i nigdzie cię nie zawozi.

Zbudowanie tego u mnie zajęło popołudnie. Utrzymanie kosztuje mnie chwilę na tydzień, kiedy dodaję jedną nową regułę - i nie mniej cennego wysiłku raz na kwartał, kiedy usuwam martwe. W zamian za to trzy błędy, których nienawidziłem u siebie i u Alexa, przestały mnie już budzić w nocy. To mi wystarczy, żeby uważać, że to była jedna z lepszych rzeczy, jakie zrobiłem swojej firmie w tym roku. A rok jeszcze się nie skończył.

Słownik pojęć

• Prompt systemowy - fragment instrukcji, który model dostaje na samym początku każdej rozmowy, zanim padnie pierwsze pytanie. Definiuje jego rolę, zasady i to, co ma zawsze pamiętać.
• Prompt caching (buforowanie promptu) - mechanizm dużych modeli, w którym niezmieniana część promptu jest utrzymywana w postaci przetworzonej po stronie dostawcy. Kolejne wywołania w tej samej sesji płacą za nią kilka razy mniej niż normalnie. Kluczowe dla utrzymania kosztów przy długich promptach systemowych.
• Token - jednostka rozliczeniowa modeli językowych. Mniej więcej ćwierć słowa polskiego. Wszystkie modele naliczają cenę za wejście i wyjście w tokenach.
• Multi-agent debate - wzorzec, w którym kilku agentów AI dyskutuje między sobą, żeby wypracować lepszą odpowiedź. Zmierzone w literaturze i - w większości scenariuszy - słabsze od dobrze prowadzonego pojedynczego agenta.

Zbudujmy ten sam mechanizm u ciebie, zanim wpadniesz w to trzeci raz

Jeśli pracujesz z asystentem AI dłużej niż miesiąc i masz wrażenie, że mniej więcej co drugą sesję zaczynasz od tłumaczenia mu tej samej rzeczy - napisz do mnie na [email protected]. Pokażę ci, jak wygląda mój rejestr luk od środka, i pomogę ci zbudować twój, dopasowany do tego, jak twoja firma go używa. Nie potrzebujesz do tego działu IT ani wielkiego budżetu, potrzebujesz jednego pliku i pół dnia pracy. Więcej o tym, jak wygląda współpraca ze mną - od pierwszej rozmowy po wdrożenie.