Dlaczego fikcyjny chatbot zapomina swoje założenia po długiej rozmowie? Poradnik z pięcioma testami

Wybierz jeden szczegół, który powinien pozostać niezmienny i łatwo go sprawdzić. Na przykład: „Mira, fikcyjna latarniczka, trzyma mosiężny kompas w zielonej szufladzie biurka”. Używaj tego samego faktu we wszystkich testach i zadawaj konkretne pytanie, takie jak „Jakiego koloru jest szuflada?”. Unikaj danych osobowych i szczegółów, które mają znaczenie poza testem.

Zapisuj dokładną treść polecenia, odpowiedź, przybliżoną długość rozmowy oraz informację, czy rozpoczęto nowy czat. Jeśli testujesz chatbota należącego do kogoś innego, korzystaj tylko z założeń postaci i rozmowy testowej, do których masz uprawniony dostęp. Nie wyciągaj wniosków na podstawie jednej odpowiedzi: generowane odpowiedzi mogą się różnić, a pojedyncza pomyłka nie mówi, czy fakt był dostępny, lecz został przeoczony, czy też nie znalazł się w informacjach przekazanych modelowi.

Badania wskazują, że warto ostrożnie interpretować błędy w długich rozmowach. Liu i współautorzy wykazali, że skuteczność w zadaniach wyszukiwania informacji mogła zależeć od miejsca, w którym dany szczegół pojawiał się w długim wejściu, i często spadała, gdy znajdował się on w środku. Ich eksperymenty dotyczyły odpowiadania na pytania i wyszukiwania par klucz-wartość, a nie odgrywania fikcyjnych ról ani żadnej konkretnej aplikacji. Badanie Luz de Araujo i współautorów z 2026 roku bezpośrednio analizowało wierność personie w długich dialogach i wykazało jej spadek wraz z długością dialogu w badanych modelach. Żadna z tych prac nie wskazuje przyczyny błędu konkretnego chatbota. (Liu i in., „Lost in the Middle”, 2024; De Araujo i in., „Persistent Personas?”, 2026)

W obecnym czacie zapytaj o kompas i szufladę. Następnie rozpocznij nową rozmowę, ponownie podaj na początku założenia postaci i zadaj to samo pytanie. Jeśli w nowym czacie odpowiedź jest poprawna, a pod koniec starego nie, prawdopodobnym wyjaśnieniem staje się ograniczenie związane z długim kontekstem. Podany szczegół może już nie być dostępny w tej samej formie albo model może mieć coraz większe trudności z jego wykorzystaniem w miarę rozwoju rozmowy.

Ten wzorzec nie pozwala ustalić dokładnej granicy okna kontekstu. Nowy czat zmienia też inne warunki: umieszcza fakt na początku i usuwa późniejsze instrukcje, które mogłyby z nim konkurować. Okno kontekstu to ilość rozmowy i innych danych wejściowych, które system może przetwarzać w danym momencie; nie musi być tym samym co pamięć zapisana na potrzeby kolejnych czatów. Jeśli usługa nie podaje swoich limitów, nie wyciągaj wniosków o liczbie tokenów na podstawie pojedynczego błędu.

Jeśli usługa oferuje udokumentowaną funkcję wyszukiwania, przypominania lub historii rozmów, sprawdź, czy potrafi odnaleźć dokładny tekst założeń. Możesz też poprosić chatbota o odtworzenie faktu z odpowiedniego wcześniejszego fragmentu rozmowy, jeśli taka funkcja jest obsługiwana. Porównaj wynik z odpowiedzią w nowym czacie.

Jeśli założenia nadal znajdują się w dostępnej historii lub zapisanej pamięci, ale chatbot z nich nie korzysta, jedną z możliwych przyczyn jest błąd wyszukiwania lub wyboru informacji. Przyczyną może też być pozycja faktu w kontekście, słaba odpowiedź albo działanie funkcji inne od oczekiwanego. Bez wglądu w informacje przekazane modelowi przy generowaniu tej odpowiedzi nie da się z pewnością rozróżnić tych możliwości. Nie zakładaj, że chatbot przeszukuje każdą poprzednią wiadomość tylko dlatego, że interfejs wyświetla pełny zapis rozmowy.

Niektóre systemy mogą skracać wcześniejsze tury do krótszego podsumowania. Jeśli aplikacja udostępnia takie podsumowanie, sprawdź, czy nadal jest w nim mowa o zielonej szufladzie i mosiężnym kompasie. Jeśli napisano tylko, że Mira „trzyma kompas w pobliżu”, zadaj konkretne pytanie o pominięty kolor i porównaj odpowiedź z tą, którą uzyskasz po jawnym podaniu założeń.

Błędne lub niepełne podsumowanie wskazuje, że podczas skracania treści mogło dojść do zmiany przekazywanych dalej informacji. Jednak podsumowanie widoczne dla ciebie może różnić się od tego, którego używa system, a nie należy zakładać istnienia podsumowania, którego nie widać. Traktuj ten test jako źródło dowodów tylko wtedy, gdy produkt rzeczywiście udostępnia odpowiedni zapis lub dokumentację.

Nie zmieniaj faktu, a następnie przyjrzyj się późniejszym instrukcjom, które mogły wpłynąć na odpowiedź. Fikcyjna scena może zawierać zdanie: „Mira jest dziś niepewna i zgaduje, że szuflada jest niebieska”. Ta instrukcja jest sprzeczna z założeniem, że szuflada jest zielona. Zadaj neutralne pytanie o fakt, a potem pytanie osadzone w scenie. Jeśli chatbot odpowie inaczej, na odpowiedź mogą wpływać sformułowanie lub priorytet instrukcji.

Aby uzyskać bardziej miarodajny test, usuń lub zmień jedną sprzeczną instrukcję, pozostawiając resztę fikcyjnych założeń bez zmian. Jeśli chatbot znów zacznie trzymać się założeń, konflikt staje się bardziej prawdopodobnym wyjaśnieniem niż zwykłe zapomnienie. Chatbot może też błędnie zinterpretować instrukcję lub improwizować; zmiana odpowiedzi po edycji nie ujawnia wewnętrznych reguł priorytetyzacji systemu. Badania nad długimi dialogami z personą pokazują, że wierność personie i stosowanie się do instrukcji można oceniać w długich interakcjach, ale nie mówią, którym regułom daje pierwszeństwo konkretna usługa. („Persistent Personas?”)

Szczegół podany w bieżącym czacie, zapisany profil postaci i pamięć między czatami to różne rzeczy. Sprawdź w ustawieniach lub dokumentacji produktu, czy oferuje on trwałe przechowywanie informacji o postaci, czy zapisywanie trzeba włączyć lub potwierdzić oraz czy dana pozycja ma być dostępna w kolejnych rozmowach. Testuj w nowym czacie tylko wtedy, gdy usługa informuje, że ta funkcja powinna tam działać.

Jeśli produkt nie udostępnia udokumentowanego sposobu zapisywania takich szczegółów postaci, brak przypomnienia ich w innym czacie nie świadczy o usunięciu zapisanej pamięci. Jeśli taka funkcja istnieje, przed wyciągnięciem wniosków sprawdź widoczny zapis i zakres jego działania. Zapisana notatka może zachować informację o „zielonej szufladzie” bez konieczności utrzymywania wszystkich wcześniejszych wiadomości w aktywnej rozmowie, ale nie przypisuj takiego działania konkretnej aplikacji bez dowodów dotyczących tego produktu.

Traktuj obserwacje jako wskazówki i formułuj każdą interpretację ostrożniej niż sam wzorzec:

Obserwacja: Nowy czat z podanymi założeniami działa; pod koniec starego czatu chatbot zawodzi. Możliwa interpretacja: Wrażliwość na długość lub pozycję w kontekście. To nie dowodzi: Dokładnej granicy okna kontekstu.

Obserwacja: Udokumentowana historia lub pamięć zawiera fakt, ale odpowiedź go pomija. Możliwa interpretacja: Błąd wyszukiwania lub wykorzystania informacji. To nie dowodzi: Że przyczyną pominięcia było wyłącznie wyszukiwanie.

Obserwacja: Udostępnione podsumowanie pomija lub zmienia szczegół. Możliwa interpretacja: Utrata lub zmiana informacji w podsumowaniu. To nie dowodzi: Że model otrzymał właśnie to podsumowanie.

Obserwacja: Usunięcie sprzecznej instrukcji sceny przywraca zgodność z założeniami. Możliwa interpretacja: Konflikt instrukcji lub sposób ich interpretacji. To nie dowodzi: Wewnętrznej hierarchii instrukcji aplikacji.

Obserwacja: Szczegółu brakuje w nowym czacie, a zapisywanie między czatami nie jest udokumentowane. Możliwa interpretacja: Brak potwierdzonego mechanizmu trwałej pamięci. To nie dowodzi: Usunięcia istniejącej pamięci.

Jeśli pojawia się kilka wzorców, ich przyczyny mogą się nakładać. Na przykład podsumowanie może pomijać kolor szuflady, a późniejsza instrukcja może dodatkowo wspominać o niebieskiej szufladzie. Ograniczaj każdy test do jednej zmiany naraz i zachowuj dokładne sformułowania, aby porównanie było miarodajne.

Zmiana sposobu mówienia postaci to inny objaw niż zapomnienie konkretnego faktu z założeń. Spójność głosu dotyczy stylu, słownictwa lub sposobu bycia; powyższe testy sprawdzają, czy konkretny fikcyjny szczegół jest dostępny i czy chatbot się go trzyma. Aktualizacja modelu lub usługi może zmienić styl, ale o ile usługa nie udokumentowała zmiany ani nie podała porównywalnych informacji o modelu, zmiana głosu nie dowodzi, że aktualizacja miała miejsce.

Podobnie przyjęcie poprawki w jednej odpowiedzi nie oznacza automatycznie, że zostanie ona zapamiętana na stałe. Najpierw sprawdź ją w tym samym czacie, a w nowym tylko wtedy, gdy produkt deklaruje, że poprawki są przenoszone między rozmowami. Jeśli postać raz stosuje się do informacji „szuflada jest zielona”, a później wraca do poprzedniej wersji, opisuje to trwałość poprawki; samo w sobie nie wskazuje, czy przyczyną jest kontekst, wyszukiwanie, podsumowanie, konflikt instrukcji czy sposób zaprojektowania pamięci.

Dla projektanta tych samych pięć przypadków podsuwa praktyczną metodę oceny: zachowaj jeden nieszkodliwy fikcyjny fakt, zmieniaj długość rozmowy i pozycję faktu, w razie potrzeby udostępniaj lub zapisuj logi wyszukanych notatek i podsumowań, wprowadzaj kontrolowaną sprzeczną instrukcję oraz określ, czy fakt powinien być dostępny w kolejnych sesjach. Zapisuj, na jakim źródle prawdy opiera się każdy test. Dzięki temu błąd łatwiej odtworzyć i łatwiej odróżnić problem z treścią od oczekiwania, którego produkt nigdy nie spełniał.

Starannie sformułowany wniosek powinien wskazywać dowody i ich ograniczenia: „Porównanie z nowym czatem sugeruje, że problem nasila się podczas długiej rozmowy, ale nie wiem, czy szczegół został ucięty, nieodnaleziony czy nadpisany”. To bardziej użyteczne niż nazywanie każdego błędu problemem z pamięcią — i dokładniejsze, gdy nie wiadomo, jak działa aplikacja.