Dlaczego roleplay AI NSFW zapomina historię — i jak naprawić jego pamięć

Postać pamięta kolor swoich oczu, ale zapomina obietnicę z wczoraj. Relacja rozwijana przez cały wieczór wraca do etapu obcych ludzi. Sekret wspomina ktoś, kogo nigdy nie było w pokoju. Przy długim roleplayu AI NSFW takie błędy potrafią zniszczyć scenę szybciej niż niezgrabna proza.

Praktyczne rozwiązanie polega na przydzieleniu różnym rodzajom pamięci osobnych miejsc. Tożsamość i trwałe granice trzymaj w definicji postaci. Bieżące miejsce, relację i bezpośrednią sytuację umieść w krótkiej notatce aktualnego stanu. Zakończone sceny zamieniaj w rzeczowe podsumowania wydarzeń. Dawne zdarzenia przywołuj przez lorebook lub system wyszukiwania, gdy stają się potrzebne. Zachowaj ostatnie dialogi, aby postać nadal brzmiała jak ona sama.

Większe okno kontekstu daje więcej miejsca, lecz nie naprawi błędnego podsumowania ani nieaktualnego opisu relacji. Zanim zapłacisz za inny model, sprawdź, co frontend rzeczywiście wysłał. Brakujący fakt mógł wypaść z promptu, a niewłaściwy nadal w nim siedzieć.

Ten poradnik wykorzystuje SillyTavern, ponieważ jego źródła pamięci są widoczne i edytowalne. Przykłady dotyczą fikcyjnego romansu dorosłych: 32-letniej Mary i 35-letniego Juliana. To przykłady pisarskie, nie transkrypcje testu modelu. Ten sam układ możesz zastosować w innym frontendzie, jeśli pozwala edytować fakty postaci, podsumowania i trwałe notatki.

Najpierw ustal, z jakim rodzajem zapominania masz do czynienia

Nie każda błędna odpowiedź jest problemem pamięci. Postać może wiedzieć o zdarzeniu, ale reagować w sposób, który ci się nie podoba. Może zachować fakty, a stracić własny głos. Może odmówić sceny ze względu na zasady modelu lub usługi. Każda z tych sytuacji wymaga innej zmiany.

Zacznij od jednego konkretnego błędu. Zapisz oczekiwany fakt i znajdź moment rozmowy, w którym stał się prawdą. Następnie porównaj go z informacjami w następnym żądaniu. Dokumentacja promptów SillyTavern wyjaśnia sprawdzanie złożonego promptu, w tym Prompt Itemization przy odpowiedzi i opcjonalne rozszerzenie Prompt Inspector.

Szukasz jednej z trzech sytuacji:

• Faktu brakuje. Trzeba go przenieść do kolejnej sceny lub odzyskać przez wyszukiwanie. Przypomnienie, które nie trafia do żądania, nie pomoże modelowi.
• Fakt jest obecny, ale jest też jego starsza wersja. Usuń ją albo wyraźnie oznacz datą. Kolejne przypomnienie może nasilić sprzeczność.
• Poprawny fakt jest obecny i nic mu nie przeczy. Model może źle go odczytywać, zgadywać mimo niego lub mocniej uwzględniać inne instrukcje. Doprecyzuj sformułowanie, usuń rozpraszające treści i sprawdź krótką kontynuację, zanim zmienisz całą konfigurację.

Załóżmy, że po drugiej randce Mara zaprosiła Juliana do mieszkania. W następnej scenie pyta on, czy zgodziłaby się kiedyś na pierwszą randkę. Jeśli randki nie ma w żądaniu, to utracona historia. Jeśli karta nadal mówi „nigdy się nie spotkali”, to nieaktualna konfiguracja. Jeśli żądanie jasno opisuje obie randki i bieżącą relację, samo generowanie nie wykorzystało dostarczonych informacji.

To rozróżnienie wskazuje następny krok. Utracona historia wymaga wpisu pamięci. Nieaktualna konfiguracja wymaga edycji. Błąd generowania wymaga poprawionej kontynuacji lub bardziej skupionego promptu. Zainstalowanie drugiego rozszerzenia pamięci przed tą diagnozą dodaje mechanizmy, nie usuwając przyczyny.

Tabela jest punktem wyjścia do diagnozy, nie obietnicą jednej przyczyny każdego objawu. Jest użyteczna, ponieważ każda poprawka zmienia konkretny tekst zamiast prosić model, by „lepiej pamiętał”.

Pięciu rodzajom informacji przydziel pięć różnych zadań

Dobra pamięć historii nie zachowuje każdego zdania. Zachowuje to, czego potrzebuje następna scena, nie zatapiając jej we wczorajszej prozie. Pomyśl, jak przypomniałbyś sytuację partnerowi pisarskiemu: kim są bohaterowie, co się zmieniło, co robią teraz i które wcześniejsze momenty nadal na nich wpływają.

Trwałe fakty postaci: kim jest ta osoba

W definicji postaci umieszczaj informacje prawdziwe przez całą historię: wiek, tożsamość, podstawową osobowość, ustalone preferencje, trwałe relacje poza głównym romansem oraz granice roli, którą ma odgrywać AI.

Przydatna definicja Mary może brzmieć:

Mara jest 32-letnią fotografką dokumentującą prace konserwatorskie. Jest spostrzegawcza, ma suche poczucie humoru i powoli otwiera się na rozmowy o osobistych uczuciach. Jej siostra Leena mieszka w innym mieście. Mara okazuje sympatię praktyczną pomocą, zanim potrafi powiedzieć o niej wprost. Użytkownik kontroluje dialogi, decyzje i uczucia Juliana.

Model otrzymuje osobę, którą ma pisać. Definicja nie każe w każdej scenie wspominać siostry, pracy i objaśniać osobowości. Nie mówi też, że Mara zawsze pozostanie emocjonalnie zdystansowana. Podstawowa skłonność powinna pozostawiać miejsce na rozwój postaci.

Dokumentacja projektowania postaci SillyTavern wskazuje pola definicji dołączane do każdego generowania i wyjaśnia, że dłuższe trwałe definicje zostawiają mniej miejsca na historię czatu. Umieść tam kluczowe fakty tożsamości, a długie opisy świata i poboczną przeszłość przenieś gdzie indziej.

Nie zamieniaj karty postaci w rosnącą transkrypcję. Dopisywanie każdej randki, kłótni i stroju utrudnia oddzielenie tego, kim jest Mara, od tego, co jej się przydarzyło. Sprawia również, że wielokrotnie używana definicja staje się właściwa tylko jednej fabule. Zachowaj czystą kartę początkową, a rozwijającą się relację umieść w pamięci konkretnej rozmowy.

Bieżący stan: co jest prawdą teraz

Bieżący stan się zmienia. Bohaterowie przechodzą do innych pomieszczeń. Konflikt zostaje rozwiązany. Gość wychodzi. Relacja się zacieśnia albo ktoś prosi o przerwę. Nie są to trwałe cechy i nie powinny być przechowywane tak, jakby opisywały postać na zawsze.

Dla obecnej sceny napisz na przykład:

Obecna scena: piątkowy wieczór, mieszkanie Mary, po drugiej randce. Mara i Julian czują się razem swobodnie, ale nie rozmawiali o wyłączności relacji. Mara właśnie zaproponowała kawę. Julian jeszcze nie odpowiedział. Leeny nie ma. Kontynuuj od propozycji bez odpowiedzi; nie zaczynaj ponownie od przedstawiania się.

Notatka jest krótka do szybkiego przeczytania i konkretna na tyle, by zapobiec resetowi. Propozycja czekająca na odpowiedź wskazuje AI miejsce zatrzymania historii. Bez tego szczegółu podsumowanie może zachęcić do przeskoczenia kolejnej decyzji użytkownika.

W SillyTavern jednym z miejsc dla tego tekstu jest Author's Note właściwa konkretnej rozmowie. Przewodnik Author's Note opisuje konfigurowalne położenie i częstotliwość wstawiania. Jeśli używasz notatki jako aktywnego przypomnienia sceny, częstotliwość zero oznacza brak wstawiania. Jeden dołącza ją przy każdym wejściu użytkownika. To rzeczywiste ustawienia; najlepsze miejsce dla twojego modelu trzeba sprawdzić i dostosować.

Nie pozostawiaj dużej notatki stanu bez zmian przez cały wieczór. Idealny opis mieszkania staje się błędny, gdy bohaterowie z niego wyjdą. Aktualizuj notatkę przy zmianie sceny, zamiast dopisywać nowe pomieszczenie pod starym.

Podsumowania wydarzeń: co rzeczywiście się wydarzyło

Zakończona scena należy do podsumowania wydarzenia. Powinno odpowiadać, kto co zrobił, co się zmieniło, co uzgodniono i co pozostaje otwarte. To zapis zdarzeń, nie druga próba pięknego napisania sceny.

Dla naszego przykładu:

Piątek, druga randka: Mara i Julian wspólnie odwiedzili nocną wystawę. Julian zwrócił mosiężny klucz pożyczony mu przez Marę do pracowni. Mara przyznała, że unikała trudnej rozmowy z Leeną. Julian zaproponował wysłuchanie jej bez samodzielnego kontaktowania się z Leeną. Uzgodnili spotkanie w pracowni w niedzielne popołudnie. Później Mara zaprosiła go do mieszkania na kawę. Nie rozmawiali o wyłączności relacji.

Zwrot klucza ma konsekwencję: Julian już go nie ma. Obietnica dotycząca Leeny ma konsekwencję: nie powinien nagle do niej dzwonić. Niedzielne spotkanie jest przyszłym planem, nie odbytą wizytą. Ostatnie zdanie zachowuje niepewność, zamiast zamieniać miły wieczór w formalny związek.

Podsumowanie może pominąć powtarzane opisy światła wystawy, zachowując te zmiany. To wybiórcza pamięć służąca historii, nie bezstratne archiwum. Zachowaj oryginalną rozmowę jako archiwum, jeśli możesz później potrzebować dokładnego dialogu.

Wpisy lorebooka: co powinno pojawiać się tylko w odpowiednim momencie

Lorebook przydaje się dla faktów ważnych sporadycznie: miejsca, wspólnego przedmiotu, postaci pobocznej lub istotnego dawnego wydarzenia. Nie potrzebujesz szczegółowego wyjaśnienia pracowni w każdej rozmowie w kuchni.

Dokumentacja World Info SillyTavern opisuje warunkowe wstawianie przez słowa kluczowe i inne ustawienia aktywacji. Praktycznie ważne jest rozróżnienie zapisania wpisu od jego aktywacji. Zapisany wpis nie pomaga w kolejnej odpowiedzi, jeśli jego treść nie zostanie wstawiona.

Dla mosiężnego klucza użyj samodzielnie zrozumiałego wpisu:

Mosiężny klucz do pracowni: Mara pożyczyła go Julianowi podczas pierwszej wizyty w pracowni. Zwrócił go na piątkowej wystawie. Obecnie nie ma klucza do jej pracowni. Ta wymiana była wczesnym gestem zaufania, nie stałym pozwoleniem na wchodzenie, kiedy zechce.

Samo „key” jest nieprecyzyjnym wyzwalaczem w historii z kluczami hotelowymi, klawiszami fortepianu i kluczowymi decyzjami. Użyj charakterystycznych określeń, które bohaterowie naturalnie powiedzą, takich jak „studio key” lub „brass key”. Nie oczekuj, że ukryty tytuł albo lista słów wyjaśnią wydarzenie; wstawiona treść musi mieć sens sama w sobie.

Aby dodać ten przykład do rozmowy:

1. W World Info utwórz lub wybierz lorebook tej historii i dodaj wpis. Wklej akapit o kluczu do Content, a w Key wpisz studio key, brass key. Pozostaw wpis włączony.
2. Otwórz Character Management → Chat Lore i wybierz lorebook. Przypisuje to go do obecnej rozmowy. Jeśli książka jest już przypisana, Chat Lore otwiera jej edytor; użyj Shift+Click na komputerze albo dłuższego przytrzymania na telefonie, aby ponownie otworzyć wybór przypisania.
3. Wspomnij „brass key” w kontynuacji, a następnie otwórz Prompt Itemization przy wynikowej odpowiedzi. Poszukaj akapitu o zwróconym kluczu w złożonym żądaniu. Obecność potwierdza wstawienie, nie poprawne wykorzystanie przez odpowiedź.

Pamięć z wyszukiwaniem: co może się przydać z dużego archiwum

Wyszukiwanie odnajduje materiał związany z obecną rozmową zamiast wstawiać wszystkie stare wpisy. Pomaga przy wielu rozdziałach. Może też przywołać starszą wersję sytuacji, ponieważ podobieństwo tematu nie oznacza automatycznie „najnowszej prawdy”.

Dokumentacja Chat Vectorization SillyTavern wyjaśnia przeszukiwanie dawnych materiałów czatu i kompromis związany z cache promptów. Przewodnik Data Bank omawia dołączone dokumenty i ich zakresy. To użyteczne narzędzia do różnych zadań; żadnego nie traktuj jako magicznego przełącznika idealnej ciągłości.

Przy krótkim romansie z kilkoma ważnymi wydarzeniami zacznij od poprawionych podsumowań i jasnych wpisów. Dodaj wyszukiwanie, gdy masz rzeczywisty problem z przywołaniem, którego nie da się wygodnie obsłużyć w ten sposób: na przykład szczegół z rozdziału dwunastego staje się ważny w trzydziestym. Zdanie o dzisiejszej relacji w zawsze dostępnej notatce jest prostsze niż proszenie wyszukiwarki o odnalezienie go w każdej turze.

Fakty postaci, bieżący stan i dawne wydarzenia mają różne zadania; ostatnie dialogi podtrzymują głos postaci.

Mała konfiguracja, którą możesz zastosować bez instalowania czegokolwiek

Możesz naprawić szwankującą rozmowę bez przebudowy całego frontendu. Pierwsza użyteczna wersja wymaga tylko definicji postaci, jednej notatki aktualnego stanu i jednego czytelnego podsumowania. Wtedy masz gdzie umieścić ciągle znikający fakt.

Zacznij od kopii rozmowy. Będziesz edytować otaczającą ją pamięć i możesz chcieć wrócić do wcześniejszego stanu. SillyTavern oferuje eksport czatu i punkty kontrolne opisane w przewodniku zarządzania plikami czatu. Eksport zwykłego tekstu przydaje się do czytania, a JSONL zachowuje metadane do ponownego importu; obrazy i załączniki są osobne.

Następnie wykonaj trzy zmiany:

1. Usuń nieaktualne warunki początkowe. Szukaj zdań takich jak „Mara i Julian nigdy się nie spotkali” albo „Julian nie zdobył jej zaufania”. Zachowaj je tylko wtedy, gdy karta celowo jest szablonem startowym, a prompt jasno mówi, że późniejsze zdarzenia mają pierwszeństwo. Inaczej mogą ciągle cofać trwającą historię do początku.
2. Zapisz aktualny stan w kilku krótkich akapitach. Uwzględnij miejsce, obecne osoby, relację, bezpośrednią akcję i ostatni wybór bez odpowiedzi. Pomiń szczegóły, które nie wpływają na kolejną odpowiedź.
3. Podsumuj starsze wydarzenia, które nadal mają znaczenie. Uwzględnij obietnice, rozwiązania konfliktów, odkrycia i plany. Przy otwartych kwestiach wpisz „nie ustalono”, zamiast prosić model o uzupełnienie luk.

W tym przykładzie możesz skopiować następującą ręczną notatkę stanu:

To trwająca historia Mary, 32 lata, i Juliana, 35 lat. Spotkali się kilkukrotnie i są teraz w mieszkaniu Mary po drugiej randce. Oboje są zainteresowani, lecz nie uzgodnili wyłączności relacji. Mara opowiedziała Julianowi o konflikcie z Leeną; Julian obiecał nie kontaktować się z Leeną w imieniu Mary. Spotkanie w pracowni jest planowane na niedzielę i jeszcze się nie odbyło. Mara zaproponowała kawę i czeka na odpowiedź Juliana. Napisz odpowiedź Mary na następne działanie Juliana, nie decydując za niego.

Kontynuuj prostym zdaniem bez dodatkowej przeszłości: „Julian przyjmuje propozycję kawy i pyta, który kubek poleciłaby”. Sprawdź, czy Mara pozostaje w mieszkaniu, traktuje go jako znaną osobę i zachowuje nierozwiązany wątek rodzinny we właściwym miejscu. Nie testujesz wszystkich aspektów modelu. Sprawdzasz, czy poprawiony stan wystarcza do zwykłej kontynuacji.

Jeśli nadal następuje reset, ponownie sprawdź rzeczywiste żądanie. Notatka może być wyłączona, inny lorebook może jej przeczyć albo frontend używać innego czatu lub persony. Jeśli żądanie jest poprawne, edytuj lub wygeneruj ponownie złą odpowiedź, zanim stanie się przykładem dla następnej tury. Kontynuowanie tak, jakby błąd faktycznie się wydarzył, może zamienić pojedynczy błąd generowania w historię fabuły.

Pisz podsumowania zachowujące zmiany zamiast atmosfery

Niejasne podsumowanie często brzmi rozsądnie, ale gubi najpotrzebniejszy szczegół. „Mara i Julian spędzili serdeczny wieczór i zbliżyli się do siebie” pozostawia otwarte prawie wszystko, co decyduje o następnej scenie. Czy ujawniła sekret? Czy on obiecał coś? Czy rozwiązali konflikt? Czy umówili następne spotkanie?

Lepsze podsumowanie rozdziela obserwacje od interpretacji. Jeśli Mara powiedziała, że ufa Julianowi ze swoim aparatem, zapisz ten konkretny zakres zaufania. Nie uogólniaj do „Mara całkowicie ufa Julianowi”. Jeśli Julian podejrzewał, że ukrywa list, zapisz podejrzenie, nie odkrycie listu. Fikcja dla dorosłych jest pełna aluzji i wahania; pamięć powinna zachować te różnice zamiast je wygładzać.

Oto ręczne polecenie podsumowania, którego możesz użyć poza wymaganym formatem wyjścia rozszerzenia:

Podsumuj zakończoną scenę jako notatki ciągłości trwającej fikcyjnej historii. Zachowaj ustalone działania, zmiany relacji, obietnice, zwrócone lub przekazane przedmioty, odkrycia, bieżące miejsce i niezakończone plany. Wskaż, kto był świadkiem każdego prywatnego wyznania. Rozróżniaj potwierdzone wydarzenia od przypuszczeń, wyobrażonych możliwości i przyszłych zamiarów. Nie dodawaj motywów, zobowiązań ani zdarzeń nieustalonych w dialogu. Zakończ ostatnim nierozstrzygniętym działaniem. Używaj zwięzłego prostego języka i zachowuj imiona zamiast niejednoznacznych zaimków.

To pomoc pisarska, nie przetestowany uniwersalny preset. Nadaje się do ręcznego podsumowania zwykłym tekstem. Rozszerzenie oczekujące strukturalnego JSON wymaga zachowania własnego formatu; zastąpienie go takim poleceniem prozą może zepsuć tworzenie pamięci.

Rozważ celowo błędne podsumowanie:

Mara i Julian zostali parą po wystawie. Opowiedziała mu wszystko o siostrze i dała dostęp do pracowni. Postanowił pomóc, dzwoniąc do Leeny. Poszli do mieszkania i wypili kawę.

Prawie każde zdanie zmienia historię. „Zostali parą” wymyśla zobowiązanie. „Wszystko” wyolbrzymia wyznanie. „Dostęp” ignoruje zwrot klucza. „Postanowił” wymyśla decyzję Juliana. „Wypili kawę” przeskakuje propozycję bez odpowiedzi.

Naprawiaj to na podstawie rozmowy, nie prośbą o bardziej elegancki język. Użyteczne podsumowanie to powyższa rzeczowa notatka wydarzenia. Czytając automatyczne podsumowanie, sprawdzaj nie to, czy brzmi jak tekst z okładki książki, lecz czy zachowało decyzje naprawdę podjęte przez bohaterów.

Wyraźnie zachowuj ważne niewydarzone zdarzenia

Niekiedy najważniejszy fakt to coś, co jeszcze się nie wydarzyło. Nie rozmawiali o wyłączności relacji. Julian nie spotkał Leeny. Mara nie ujawniła treści listu. Niedzielna wizyta się nie odbyła.

Takie zdania zapobiegają łatwym skrótom fabularnym modelu. Używaj ich tam, gdzie istnieje realne ryzyko pomyłki, zamiast tworzyć ogromną listę wszystkiego, co nigdy nie zaszło. „Jeszcze nie rozmawiali o wyłączności” ma znaczenie w tym romansie. „Nigdy nie odwiedzili Marsa” nie ma.

Zachowaj jedną konkretną przyczynę emocjonalną

Całkowicie suchy dziennik może zachować wydarzenia, ale utracić ich znaczenie. Przyczynę zmiany emocjonalnej zapisz jednym precyzyjnym zdaniem. Na przykład: „Mara rozluźniła się, gdy Julian zwrócił klucz, nie prosząc o zatrzymanie go”. Daje to następnemu autorowi punkt zaczepienia bez deklarowania nowej trwałej osobowości.

Porównaj to z „Mara jest teraz szczęśliwa”. Z jakiego powodu, na jak długo i w której scenie? Konkretna przyczyna pozwala postaci później odczuwać sprzeczne emocje. Ogólna etykieta zachęca model do spłaszczenia jej do jednego nastroju aż do następnej aktualizacji trackera.

Oddziel archiwum od przypomnienia do następnej sceny

Możesz zachować szczegółowe archiwum zdarzeń, korzystając jednocześnie z krótkiej aktywnej notatki. Archiwum odpowiada „co wydarzyło się w tym rozdziale?”, a aktywne przypomnienie „co musi uwzględnić następna odpowiedź?”. Nie muszą mieć tej samej długości.

Po dziesięciu scenach pełne chronologiczne archiwum może zawierać pierwsze spotkanie, wizytę w pracowni, wystawę, rozmowę w mieszkaniu i niedzielne plany. Scena w mieszkaniu potrzebuje tylko obecnego etapu relacji, odpowiedniej obietnicy i miejsca zatrzymania dialogu. Jeśli pojawi się mosiężny klucz, wtedy przywołaj jego konkretną historię.

W ten sposób projekt pamięci nie zamienia się w pracę domową. Nie przepisuj całej historii po każdych dwóch wiadomościach. Zapisuj znaczące zmiany, utrzymuj małą notatkę stanu i pozostaw zwykłe szczegóły rozmowy w ostatniej historii do zakończenia sceny.

Użyj wbudowanego Summarize, gdy potrzebujesz prostego aktualizowanego skrótu

Wbudowane rozszerzenie Summarize jest rozsądną pierwszą opcją, jeśli głównie chcesz „zachować dostępny zarys tej rozmowy”. W panelu Extensions otwórz Summarize i wybierz działające źródło. Main API używa aktywnego połączenia. Przeczytaj pierwszy wynik w Current summary i popraw go, zanim zaczniesz na nim polegać.

Oficjalny przewodnik Summarize opisuje też Pause i Restore Previous. Te ustawienia przydają się, gdy aktualizacja wymyśli zobowiązanie lub usunie obietnicę. Możesz zatrzymać automatyczne aktualizacje podczas naprawy notatki albo przywrócić starsze podsumowanie i dopisać poprawne zmiany.

Dostosuj odstęp aktualizacji do rozmowy, nie traktuj go jako rytualnej liczby. Dwadzieścia krótkich odpowiedzi może ledwo ruszyć fabułę; dwadzieścia długich może obejmować konfrontację, wyznanie i zmianę miejsca. Zamów nowe podsumowanie przed wypadnięciem ważnych dawnych wydarzeń z aktywnej historii i po scenie zmieniającej to, co musi wiedzieć następna odpowiedź.

Na początek ręcznie podsumowuj zakończenia scen. Przeczytaj dwa lub trzy wyniki i zauważ, co konfiguracja zwykle pomija. Dopiero wtedy włącz automatyczne aktualizacje w odstępie odpowiednim dla typowej długości twoich odpowiedzi. Otrzymasz użyteczny punkt odniesienia, zamiast po tygodniu odkryć, że każde podsumowanie zmieniało relację.

Aktualizowany skrót jest wygodny, ale ponowne kompresowanie starego skrótu w nowy może gubić drobne fakty. Trwałą obietnicę chroń w osobnym wpisie, zamiast liczyć, że przetrwa każdą redakcję. Skrót może mówić „obietnica dotycząca Leeny nadal obowiązuje”, a osobny wpis zachowywać jej dokładny zakres.

Nie obciążaj podsumowania całym głosem postaci. Powinno zachowywać użyteczne zdarzenia. Ostatnie wiadomości i mały przykład dialogu mogą utrzymać suche poczucie humoru, rytm i formalność. Długa instrukcja stylu w każdym wpisie zdarzenia zmniejsza ich czytelność i może przytłoczyć rozmowę, gdy kilka aktywuje się jednocześnie.

Użyj Memory Books, gdy chcesz edytowalną pamięć osobnych scen

ST Memory Books przydaje się, gdy jeden aktualizowany skrót przestaje być wygodny. Zamiast polegać wyłącznie na ciągle zmieniającym się podsumowaniu, możesz zachować oddzielne wspomnienia scen i edytować te istotne. To praktyczna różnica w długim romansie: pierwsza randka, rodzinne wyznanie i zwrócony klucz pozostają osobnymi czytelnymi zapisami.

Niedawna dyskusja społeczności SillyTavern wskazuje rozszerzenia pamięci, zwłaszcza STMB, jako poprawę doświadczenia autora. Inna rozmowa o rozszerzeniach podsumowujących pokazuje wybory między edytowalnymi pamięciami lorebooka i bardziej automatycznymi narzędziami skrótów. To indywidualne preferencje, nie kontrolowany dowód poprawy każdego modelu.

Zacznij od projektu i jego przewodnika startowego. Opisuje instalację, wybór lorebooka i pierwszą ręczną pamięć. Na próbę wybierz odpowiednią książkę pamięci, profil Current SillyTavern Settings, zaznacz zakończoną scenę ustawieniami początku i końca oraz utwórz jedną pamięć. Otwórz wynikowy wpis przed uruchomieniem automatyzacji.

Przeczytaj aktualne wymagania, jeśli używasz połączenia lokalnego lub Text Completion. Projekt opisuje dodatkowe wymagania połączenia i strukturalnego wyjścia; model dobrze piszący odpowiedzi czatu nadal może nie umieć utworzyć JSON wymaganego przez pamięć. Zachowaj wbudowany format wyjścia, dopóki nie uruchomisz pierwszej pamięci.

Na pierwszy raz wybierz krótkie zakończone wydarzenie. W naszej historii wymiana na wystawie jest odpowiednia, bo ma początek, zwrot przedmiotu, wyznanie i plan. Zaznaczenie całego wieczoru wraz z niedokończoną rozmową w mieszkaniu ułatwia pomylenie wydarzeń zakończonych z tym, co dopiero może się stać.

Gdy ręczne tworzenie zadziała, przewodnik użytkownika Memory Books opisuje tworzenie automatyczne, polecenia wybierania scen i inne ustawienia. Sugerowany początkowy odstęp to dwadzieścia–trzydzieści wiadomości, nie gwarancja, że każda scena ma taką długość. Przeczytaj pierwsze automatyczne wpisy i dostosuj do swojego sposobu pisania.

Przydatny rytm jest prosty: pozwól rozszerzeniu zapisywać zwykłe zmiany scen, a ręcznie poprawiaj te nieliczne wydarzenia, których zniekształcenie zaszkodzi ciągłości. W notatce z wystawy sprawdź, kto zwrócił klucz, kto usłyszał o problemie rodzinnym, czy plan niedzielny nadal oczekuje i czy rzeczywiście padło zobowiązanie dotyczące relacji.

Nie instaluj trzech narzędzi podsumowujących naraz. Jeśli każde dodaje nieco inny skrót, trzy wersje tego samego wieczoru mogą rywalizować w żądaniu. Zacznij od jednego systemu pamięci zdarzeń i jednej jasnej notatki aktualnego stanu. Kolejne narzędzie dodaj dopiero, gdy rozwiązuje odrębny problem, który potrafisz nazwać.

Popraw wydarzenie, nie styl pisania: zwrócony klucz i niezrealizowany plan powinny takie pozostać w pamięci.

Utrzymuj aktualną relację bez przepisywania postaci

Odchylenia relacji są szczególnie frustrujące w roleplayu NSFW, bo wiele scen zależy od rozwiniętego zaufania, znajomości lub niepewności. Model pamiętający miejsce, ale nie relację, może napisać technicznie spójną scenę, która wydaje się całkowicie nietrafiona.

Użyj dwóch osobnych zapisów. Jeden opisuje, co zmieniło relację. Drugi opisuje, na jakim etapie jest teraz. Pierwszy jest historyczny, drugi bieżący.

Wydarzenie historyczne:

Po wystawie Mara zaprosiła Juliana do mieszkania. Powiedziała, że czuje się swobodnie sam na sam z nim i docenia, że nie naciskał w sprawie Leeny. Była to ich druga randka. Żadne nie zaproponowało wyłączności relacji.

Bieżąca relacja:

Mara i Julian spotykają się i swobodnie okazują zainteresowanie. Nadal poznają swoje preferencje. Nie uzgodnili wyłączności relacji i żadne nie powinno zakładać przyszłych decyzji drugiego.

Jeśli później uzgodnią zobowiązanie, zmień drugi zapis. Zachowaj pierwszy jako wcześniejsze wydarzenie. Późniejsza pamięć może mówić „Niedziela: uzgodnili wyłączność”. Notatka stanu niesie wtedy nową relację. Piątkowa niepewność jest historią, nie konkurencyjną instrukcją teraźniejszości.

Nie redukuj całej relacji do wyniku liczbowego. Tracker wskazujący zaufanie osiemdziesiąt na sto nie wyjaśnia, czy Mara ufa Julianowi w sprawie sekretu, pożyczonego przedmiotu czy przedstawienia rodzinie. Liczby mogą wspierać świadomie zaprojektowaną mechanikę gry. Słabo zastępują zdanie o rzeczywistej relacji.

Zgodę i preferencje zapisuj równie konkretnie. „Mara woli omówić zmiany planów przed zobowiązaniem się” mówi autorowi, jak traktować nowe zaproszenie. „Mara zgodziła się na niedzielną wizytę w pracowni” zapisuje jedną zgodę. Żadne nie oznacza nieograniczonej zgody na wszystko, co będzie dalej.

Nie chodzi o wstawienie wykładu do historii. Chodzi o zachowanie znaczących wyborów, zamiast pozwalać językowi podsumowania je usuwać. Relacja jest ciekawa, bo niektóre pytania nadal są otwarte. Dobra pamięć przenosi je dalej bez odpowiadania za użytkownika.

Nie pozwalaj starym wspomnieniom przeważać nad nowymi wydarzeniami

Narzędzie wyszukiwania może zwrócić właściwy temat z niewłaściwego momentu. Rozmowa Mary i Juliana o pracowni może przywołać wczesną kłótnię i późniejsze pojednanie. Bez kolejności lub rozwiązania model może otworzyć konflikt, który już rozwiązałeś.

Wpisy historyczne opatruj etykietą wydarzenia i jasną zmianą. „Pierwsza wizyta w pracowni: Mara poczuła się nieswojo, gdy Julian przestawił statywy oświetleniowe bez pytania” jest lepsze od „Mara czuje się nieswojo z Julianem w pracowni”. Drugie brzmi jak stały warunek teraźniejszości.

Zapisz rozwiązanie jako kolejne wydarzenie:

Druga wizyta w pracowni: Julian przeprosił za przesuwanie sprzętu i pytał, zanim dotknął czegoś następnego. Mara przyjęła przeprosiny. Wcześniejsza niezgoda jest rozwiązana; nadal woli, aby goście pytali przed przestawianiem materiałów pracy.

Rozwiązanie kłótni nie usuwa preferencji. Relacja może się poprawić przy zachowaniu zasad pracowni. To użyteczniejsze niż skasowanie każdej negatywnej pamięci albo instrukcja ignorowania wszystkich dawnych problemów.

Gdy nieaktualny wpis ciągle się aktywuje, otwórz go i zamień fragmenty teraźniejsze na fakty historyczne. Jeśli nie ma wartości poza nieaktualnym stanem, wyłącz go. Aktywny stan zachowaj w jednym miejscu. Nie potrzebujesz serii notatek „ignoruj poprzednią pamięć” zagnieżdżonych w nowych notatkach.

Przydatne jest oznaczanie planów statusem. „Planowane”, „zakończone”, „odwołane” i „zmienione” wyraźnie poprawiają czytelność. „Spotkać się w pracowni w niedzielę” można pomylić z obecną akcją. „Oczekujący plan: spotkanie w niedzielne popołudnie; jeszcze się nie odbyło” trudniej źle odczytać.

Gdy nadejdzie niedziela, zapisz wizytę lub odwołanie i zaktualizuj oczekujący plan. Jeśli historia przeskoczy o dwa tygodnie, usuń przeterminowane zaproszenie z bieżącej notatki. Inaczej dawne spotkanie może nadal wracać jako pilne następne działanie, choć bohaterowie dawno przeszli dalej.

Przypisz sekrety postaciom, które rzeczywiście je znają

Jednym z najgorszych błędów ciągłości jest wyciek sekretu przez narratora. Podsumowanie może poprawnie zapisać, że Mara opowiedziała Julianowi o konflikcie z Leeną. Później scena grupowa daje Leenie szczegółową wiedzę o tej rozmowie, choć nikt jej nie powiedział.

Pamięć wydarzenia i wiedza postaci to różne rzeczy. Archiwum historii może wiedzieć, że wydarzenie zaszło. Konkretna postać powinna reagować tylko na to, czego była świadkiem lub o czym się dowiedziała. Umieść to rozróżnienie we wpisie zawierającym sekret.

Na przykład:

Prywatna rozmowa, piątkowy wieczór: Mara powiedziała Julianowi, że nie odpowiedziała na list Leeny. Julian usłyszał to bezpośrednio. Leena wie, że wysłała list, lecz nie wie, że Mara omawiała go z Julianem. Nikogo innego nie było.

Następnie pisz bieżącą scenę z perspektywy Leeny. Może zauważyć niepokój Mary. Może zapytać, czy list dotarł. Nie powinna znać obietnicy Juliana, dopóki historia nie przekaże jej tej informacji.

W roleplayu grupowym podawaj imiona jasno. „Ona powiedziała mu o niej” jest kruchą pamięcią, gdy w rozdziale są trzy kobiety i dwóch mężczyzn. „Mara opowiedziała Julianowi o Leenie” jest nieco mniej literackie i znacznie użyteczniejsze.

Nie gwarantuje to idealnego rozdzielenia wiedzy w wyniku modelu. Dostarcza jasną granicę do sprawdzenia. Jeśli model nadal ujawnia sekret, popraw odpowiedź przed dalszą grą i sprawdź, czy inne podsumowanie nie przedstawia wyznania jako wiedzy publicznej.

Nie naprawiaj wycieku przez całkowite usunięcie sekretu. Poprawiłoby to wiedzę Leeny, lecz usunęło również to, co powinien pamiętać Julian. Celem jest zachowanie tego samego wydarzenia z właściwymi świadkami, nie spłaszczenie historii do sytuacji, w której nikt nie ma prywatnej informacji.

Rozdziel gałęzie historii przed sprawdzeniem innego wyniku

Eksplorowanie alternatywnych wyników jest częścią uroku roleplayu. Możesz chcieć jednej gałęzi, gdzie Julian przyjmuje niedzielne zaproszenie, i drugiej, gdzie prosi o czas. Mogą dzielić definicje postaci i historię sprzed wyboru. Nie powinny dzielić zmiennych zapisów tego, co nastąpiło później.

Nazwij gałęzie jasno: „Niedziela przyjęta” i „Niedziela przełożona”. Dla każdej utrzymuj małą notatkę aktualnego stanu i przed tworzeniem pamięci sprawdzaj przypisaną książkę. Jeśli obie zapisują do jednej rozwijającej się książki, późniejsze wyszukiwanie może powiedzieć gałęzi przyjętej, że zaproszenie odrzucono.

Punkt kontrolny zachowuje rozmowę w miejscu rozgałęzienia, ale nie zakładaj, że każde rozszerzenie lub zewnętrzne źródło pamięci automatycznie tak samo izoluje dane. Sprawdź aktywną książkę po utworzeniu gałęzi. Przed poleganiem na kopiowaniu i blokowaniu przeczytaj aktualną dokumentację rozszerzenia dla jego własnych opcji.

Jeśli znajdziesz pomieszane dane, wskaż wpisy utworzone po rozgałęzieniu. Skopiuj właściwe do źródła docelowej gałęzi, a niepowiązane tam wyłącz. Historię sprzed podziału dziel tylko wtedy, gdy rzeczywiście pozostaje niezmieniona. Trwałą cechę postaci można dzielić; wyniku rozmowy właściwej jednej gałęzi nie.

Przy czystym restarcie zdecyduj, którą z trzech rzeczy masz na myśli. „Nowa rozmowa z tą samą postacią” może zacząć od pierwotnego scenariusza. „Kontynuacja tej samej historii w nowym czacie” potrzebuje przeniesienia stanu i istotnych wspomnień. „Alternatywna historia z tą samą obsadą” potrzebuje osobnej rozwijającej się przeszłości. Traktowanie wszystkich trzech jako nowego czatu sprawia, że postać pamięta randkę, której w tej wersji nie było.

Przy eksporcie lub synchronizacji z innym urządzeniem przenieś potrzebne źródła pamięci wraz z rozmową. Widoczny czat nie dowodzi, że przeniosły się przypisany lorebook, dokument lub stan rozszerzenia. Otwórz aktywne źródła na urządzeniu docelowym i sprawdź jeden jednoznaczny fakt przed kontynuacją.

Alternatywne wyniki mogą dzielić wcześniejszą historię; późniejsze zdarzenia potrzebują oddzielnej pamięci.

Zmieniaj modele bez zmuszania nowego do zgadywania całej historii

Zmiana modelu może zmienić głos nawet przy identycznych faktach fabuły. Może też zmienić ilość historii mieszczącą się w żądaniu i interpretację presetu. Nowy model nie dziedziczy niewidocznej pamięci poprzedniego; widzi to, co wysyła frontend.

Przed zmianą przygotuj zwięzłe przekazanie historii. Uwzględnij tożsamość, aktualną relację, istotną ostatnią scenę, oczekujące plany i krótki przykład głosu. Nie dołączaj całego archiwum, chyba że nadchodząca scena naprawdę go potrzebuje.

Dla Mary przekazanie może brzmieć:

Kontynuuj istniejącą historię. Mara jest 32-letnią fotografką z suchym poczuciem humoru i skłonnością do praktycznych gestów. Julian ma 35 lat i jest kontrolowany przez użytkownika. Spotykają się po drugim wspólnym wyjściu, nie poznają się pierwszy raz. Są obecnie w mieszkaniu Mary. Julian przyjął propozycję kawy. Niedzielna wizyta w pracowni nadal oczekuje. Obiecał nie kontaktować się z Leeną w imieniu Mary. Dialog Mary jest zwięzły; zanim odpowie szczerze, odsuwa temat małym żartem. Nie decyduj o odpowiedzi Juliana.

Przykładem głosu może być krótka oryginalna kwestia: „Wyszczerbiony kubek jest dla ludzi, których lubię. Dobra porcelana dla tych, na których próbuję zrobić wrażenie”. Oddaje rytm i charakter, nie zamieniając pamięci w ścianę poleceń stylistycznych.

Do krótkiego porównania zmiany użyj tego samego przekazania. Poproś o jedną kontynuację sceny kawy. Porównaj zachowanie miejsca, oczekującego planu, granicy wiedzy i głosu. Nie porównuj starego modelu po dwóch godzinach starannie kształtowanego dialogu z nowym, który otrzymał tylko jednozdaniowe powitanie.

Jeśli potrzebujesz innego modelu tekstowego, przewodnik modeli do roleplayu omawia tę osobną decyzję. Gdy w prompcie jest zły fakt, najpierw napraw pamięć. Sprawniejszy model też może podążyć za błędnym podsumowaniem, a tańszy wystarczyć dla jasno uporządkowanej sceny.

Oddziel zasady treści nowego modelu od tego sprawdzianu. Odmowa nie dowodzi zapomnienia randki. Ciepła, ale mniej dojrzała kontynuacja nie jest automatycznie błędem pamięci. Sprawdź dostarczony stan i rzeczywistą odpowiedź, zanim zdecydujesz, czy zmienić narzędzie pamięci, prompt czy model.

Zmiana modelu potrzebuje tych samych faktów fabuły i małego przykładu głosu, nie nowego pierwszego spotkania.

Obniż koszt pamięci bez utraty ważnych szczegółów

Długi kontekst ma praktyczny koszt w API rozliczanych tokenami: tekst dołączony do każdego żądania powiększa użycie wejściowe. Tworzenie pamięci może wymagać osobnych wywołań modelu. Nie zakładaj, że działanie rozszerzenia jest darmowe tylko dlatego, że jego instalacja nic nie kosztuje.

Możesz przeanalizować rozmiar konfiguracji bez konkretnej ceny modelu. Załóżmy ilustracyjne żądanie z czterdziestoma tysiącami tokenów wejściowych i skupioną wersję z dwunastoma tysiącami. Przy pięćdziesięciu odpowiedziach daje to dwa miliony wobec sześciuset tysięcy tokenów wejściowych, przed uwzględnieniem cache i innych szczegółów wyceny. To przykłady arytmetyczne, nie zmierzony rachunek ani obietnica oszczędności.

Użyteczne pytanie brzmi: jakie dwadzieścia osiem tysięcy tokenów usunąłeś? Jeśli powtarzane opisy pomieszczeń i nieaktualne sceny, krótsze żądanie nadal może zachować wszystko potrzebne. Jeśli jedyny zapis obietnicy Juliana, może być tańsze i gorsze. Kompresja ma wartość, gdy zachowuje znaczące zmiany historii.

Podobnie podsumowywanie każdej wiadomości może kosztować więcej i tworzyć zbędne pośrednie wspomnienia. Prosta propozycja kawy może nie zasługiwać na nowe zadanie pamięci. Wyznanie dotyczące Leeny prawdopodobnie tak. Zacznij od zakończeń scen albo odstępu obsługiwanego przez narzędzie i sprawdź, czy takie granice tworzą spójne wpisy.

Wyszukiwanie może komplikować cache, ponieważ wybrany materiał zmienia się między turami. Oficjalna dokumentacja Chat Vectorization wskazuje ten kompromis. Jeśli konfiguracja API korzysta z powtarzanej zawartości promptu, porównaj rzeczywiste użycie po włączeniu wyszukiwania zamiast zakładać, że mniej widocznych wiadomości zawsze oznacza niższy rachunek.

W osobistej sesji pisarskiej najprostsze oszczędności zwykle wynikają z odchudzenia rozrośniętej karty, krótkiego stanu bieżącego i unikania nadmiarowych automatycznych podsumowań. W aplikacji musisz także wiedzieć, czy pamięć powstaje w każdej turze użytkownika, w tle czy tylko w wybranym momencie. To odmienne wzorce żądań z odmiennymi kosztami.

Nie umieszczaj każdego faktu w zawsze aktywnym wpisie tylko po to, by uniknąć błędów wyszukiwania. Wracasz wtedy do wysyłania całego archiwum za każdym razem. Zawsze dostępne miejsce zachowaj dla tożsamości, aktualnego stanu i kilku kluczowych ograniczeń. Resztę przywołuj, gdy staje się potrzebna.

Co zrobić, gdy narzędzie pamięci działa, ale historia nadal się psuje

Powiadomienie sukcesu może oznaczać, że utworzono pamięć. Nie oznacza, że jest poprawna, że się aktywowała ani że model właściwie ją wykorzystał. Prześledź problematyczny fakt kolejno przez te etapy.

Najpierw otwórz zapisany wpis. Jeśli mówi, że Julian zatrzymał klucz, popraw treść przed zmianą wyszukiwania. Żadne ustawienie aktywacji nie uczyni błędnego wpisu prawdziwym. Jeśli zwrot klucza całkowicie pominięto, dodaj zdarzenie albo wygeneruj ponownie z odpowiedniego zakresu sceny.

Następnie sprawdź źródło i aktywację. Czy książka jest przypisana do obecnego czatu? Czy wpis wymaga słowa, którego rozmowa nigdy nie używa? Czy filtr wyklucza obecną postać? Czy wpis mieści się w ustawionym budżecie? Sprawdź opcje dotyczące tego wpisu, zamiast podnosić wszystkie globalne limity.

Potem sprawdź końcowe żądanie. Pamięć może być zapisana i kwalifikować się, ale zostać wyparta przez inne źródło. Poszukaj charakterystycznego faktu, na przykład „zwrócił mosiężny klucz”. Poszukaj też starej sprzeczności, takiej jak „Julian zatrzymuje klucz Mary do pracowni”. Obecność obu wyjaśnia, dlaczego pozornie poprawna pamięć nadal sprawia problem.

Na końcu przeczytaj wygenerowaną kontynuację. Jeśli poprawny fakt jest obecny bez sprzeczności, spróbuj bardziej bezpośredniego zdania stanu dla bieżącej sceny. Jeśli nadal zawodzi, odpowiednie może być inne generowanie lub model. Wykluczyłeś już brakującą lub uszkodzoną pamięć, zamiast ślepo zmieniać narzędzia.

Ogranicz pytanie diagnostyczne. „Dlaczego model ma złą pamięć?” trudno rozstrzygnąć. „Dlaczego dał Julianowi klucz, skoro wpis mówi, że go zwrócił?” prowadzi do źródła, wyzwalacza, żądania i poprawki. Taką naprawę możesz rzeczywiście skończyć przed następną sceną.

Powtarzalny rytm dla długiej historii dla dorosłych

Przed sesją przeczytaj notatkę aktualnego stanu zamiast całej historii. Potwierdź miejsce bohaterów, obecne znaczenie relacji, oczekujące plany i to, kto ma podjąć decyzję. Trzydziestosekundowa lektura może wykryć starą scenę, zanim wpłynie na dziesięć nowych wiadomości.

Podczas sesji pozostaw zwykły dialog w spokoju. Zapisuj pamięć, gdy coś się zmienia: obietnica, odkrycie, rozwiązanie konfliktu, nowa granica, przekazany przedmiot lub wykonany plan. W narzędziach automatycznych sprawdzaj wpisy wokół takich zmian zamiast korygować każdą banalną wymianę.

Na końcu sceny rozdziel wydarzenie i stan obecny. Zapisz to, co się wydarzyło, w pamięci zdarzenia. Zastąp notatkę stanu miejscem obecnego zatrzymania historii. Nie dopisuj nowej „bieżącej” sceny pod trzema starymi bieżącymi scenami.

Przed rozgałęzieniem skopiuj lub rozdziel rozwijającą się pamięć. Przed zmianą modelu przygotuj krótkie przekazanie i zachowaj mały przykład głosu. Przed zmianą urządzenia potwierdź przeniesienie źródeł pamięci. Każde działanie zapobiega innemu resetowi; żadne nie wymaga dłuższej karty postaci.

Oczekiwany efekt jest skromny, ale wartościowy: postać pamięta obietnicę, relacja nie zaczyna się od nowa, a następna scena startuje tam, gdzie poprzednia się zatrzymała. Zacznij od naprawy jednego przeszkadzającego faktu. Gdy widzisz go we właściwym źródle pamięci i rzeczywistym żądaniu, masz znacznie mocniejszą podstawę do oceny następnej odpowiedzi modelu.