Varför glömmer en fiktiv chatbot sin grundinställning efter ett långt samtal? En guide med fem kontroller

Välj en detalj som ska förbli oförändrad och som är lätt att kontrollera. Till exempel: ”Mira, en fiktiv fyrvaktare, har en kompass av mässing i den gröna skrivbordslådan.” Använd samma faktum genom alla kontroller och ställ en avgränsad fråga som ”Vilken färg har lådan?” Undvik personuppgifter eller detaljer som har betydelse utanför testet.

Anteckna den exakta prompten, svaret, ungefär hur långt samtalet är och om du startade en ny chatt. Om du testar någon annans chatbot ska du bara använda en grundinställning och ett testsamtal som du har tillåtelse att komma åt. Dra inga slutsatser från ett enda svar: genereringen kan variera, och ett enstaka missat svar avslöjar inte om faktumet fanns med men förbises eller saknades i informationen som gavs till modellen.

Forskningen talar för försiktighet när man tolkar fel i långa chattar. Liu och kollegor fann att resultaten på informationshämtningsuppgifter kunde variera beroende på var den relevanta detaljen fanns i en lång inmatning, och att resultaten ofta försämrades när den låg i mitten. Deras experiment gäller frågesvar och hämtning av nyckel–värde-par, inte fiktivt rollspel eller någon specifik app. En studie från 2026 av Luz de Araujo och kollegor undersökte direkt hur väl en persona upprätthålls i längre dialoger och rapporterade försämringar med ökad samtalslängd för de modeller de utvärderade. Ingen av artiklarna identifierar orsaken till ett enskilt chatbotfel. (Liu et al., ”Lost in the Middle”, 2024; De Araujo et al., ”Persistent Personas?”, 2026)

Fråga om kompassen och lådan i den befintliga chatten. Öppna sedan en ny konversation, ange karaktärens grundinställning igen i början och ställ samma fråga. Om svaret fungerar i den nya chatten men uteblir sent i den gamla blir en begränsning för långa kontexter mer sannolik. Detaljen du angav kanske inte längre är tillgänglig på samma sätt, eller så kan modellen ha svårare att använda den när samtalet växer.

Det här mönstret fastställer inte en exakt gräns för kontextfönstret. Den nya chatten ändrar också andra villkor: faktumet ligger nära början, och senare instruktioner som kan konkurrera med det har tagits bort. Ett kontextfönster är den mängd samtal och annan inmatning som ett system kan bearbeta åt gången; det är inte nödvändigtvis samma sak som sparat minne mellan chattar. Dra ingen slutsats om ett visst antal token utifrån ett enstaka misslyckat svar, såvida tjänsten inte redovisar sina begränsningar.

Om tjänsten erbjuder en dokumenterad sök-, återkallnings- eller historikfunktion kan du testa om den hittar den exakta texten i grundinställningen. Du kan också be chatboten hämta faktumet från den relevanta tidigare delen av samtalet, om det stöds. Jämför resultatet med baslinjen från den nya chatten.

Om grundinställningen fortfarande finns i en tillgänglig historik eller minnespost men chatboten inte använder den är problem med informationshämtning eller urval en möjlig förklaring. Det kan också bero på detaljens placering i kontexten, ett svagt svar eller att en funktion inte beter sig som väntat. Utan att se vilken information som gavs till modellen för svaret går det inte att skilja dessa förklaringar åt med säkerhet. Utgå inte från att en chatbot söker igenom alla tidigare meddelanden bara för att gränssnittet visar hela transkriptionen.

Vissa system kan kondensera tidigare turer till en kortare sammanfattning. Om appen visar sammanfattningen kan du kontrollera om det fortfarande står att lådan är grön och kompassen av mässing. Om det i stället bara står att Mira ”har en kompass i närheten” kan du ställa en avgränsad fråga om den utelämnade färgen och jämföra svaret med versionen där du uttryckligen angav grundinställningen.

En felaktig eller ofullständig sammanfattning stöder möjligheten att komprimeringen ändrade det som fördes vidare. Men en sammanfattning som är synlig för dig behöver inte vara den sammanfattning som systemet använder, och du kan inte utgå från att det finns en osynlig sammanfattning. Se den här kontrollen som belägg endast när produkten faktiskt visar den relevanta posten eller dokumentationen.

Låt faktumet vara oförändrat och leta sedan efter senare instruktioner som kan påverka svaret. En fiktiv scen kan säga: ”Mira är osäker i dag och gissar att lådan är blå.” Den instruktionen står i konflikt med en grundinställning som säger att lådan är grön. Ställ en neutral sakfråga och därefter en fråga formulerad inom scenen. Om chatboten svarar olika kan formuleringen eller instruktionernas prioritet påverka svaret.

För ett tydligare test kan du ta bort eller ändra en enda motstridig instruktion och låta resten av den fiktiva grundinställningen vara oförändrad. Om följsamheten återkommer blir konflikten en starkare förklaring än ren glömska. Chatboten kan också misstolka en instruktion eller improvisera; en förändring efter redigeringen avslöjar inte systemets interna prioritetsregler. Forskning om utökad personadialog visar att det går att utvärdera både personaföljsamhet och instruktionsföljande i långa interaktioner, men den kan inte tala om vilken regel en viss tjänst prioriterar. (”Persistent Personas?”)

En detalj i den aktuella chatten, en sparad karaktärsprofil och minne mellan chattar är olika saker. Kontrollera produktens egna inställningar eller dokumentation för att se om den erbjuder bestående karaktärsinformation, om sparandet måste aktiveras eller bekräftas och om den valda uppgiften är tänkt att följa med mellan konversationer. Använd en ny chatt som test endast om tjänsten säger att funktionen ska gälla där.

Om produkten inte har något dokumenterat sätt att spara den här typen av karaktärsdetalj är utebliven återkallning i en annan chatt inget belägg för att ett sparat minne har raderats. Om funktionen finns bör du kontrollera den synliga sparade posten och dess omfattning innan du drar slutsatser. En sparad anteckning kan bevara ”grön låda” utan att alla tidigare meddelanden behöver finnas kvar i den aktiva konversationen, men hävda inte att en viss app fungerar så utan produktspecifika belägg.

Använd observationerna som ledtrådar och håll varje tolkning snävare än själva mönstret:

Observation: En ny chatt fungerar när grundinställningen anges; en sen fråga i den gamla chatten misslyckas Möjlig tolkning: Känslighet för lång kontext eller placering Bevisar inte: En exakt gräns för kontextfönstret

Observation: En dokumenterad historik eller ett minne innehåller faktumet, men svaret missar det Möjlig tolkning: Problem med informationshämtning eller användning Bevisar inte: Att informationshämtningen ensam orsakade missen

Observation: En visad sammanfattning utelämnar eller ändrar detaljen Möjlig tolkning: Förlust eller förändring i sammanfattningen Bevisar inte: Att modellen faktiskt fick den sammanfattningen som indata

Observation: Följsamheten återkommer när en motstridig sceninstruktion tas bort Möjlig tolkning: Instruktionskonflikt eller tolkning Bevisar inte: Appens interna instruktionshierarki

Observation: En detalj saknas i en ny chatt och sparande mellan chattar är inte dokumenterat Möjlig tolkning: Ingen påvisad väg till bestående minne Bevisar inte: Att ett befintligt minne har raderats

Om flera mönster förekommer kan orsakerna överlappa. En sammanfattning kan till exempel utelämna lådans färg samtidigt som en senare instruktion introducerar en blå låda. Håll varje test litet, ändra ett villkor i taget och bevara den exakta formuleringen så att jämförelsen förblir användbar.

Att en karaktär låter annorlunda är ett separat symtom från att en specifik grunduppgift glöms bort. Konsekvent röst handlar om stil, ordval eller sätt att tala; kontrollerna ovan handlar om huruvida en konkret fiktiv detalj är tillgänglig och följs. En modell- eller tjänsteuppdatering kan förändra stilen, men om inte tjänsten dokumenterar en ändring eller tillhandahåller jämförbar modellinformation visar en röstförändring inte att en uppdatering har skett.

På samma sätt innebär en korrigering som godtas i ett svar inte automatiskt att den består. Testa den först i samma chatt och sedan i en ny chatt endast om produkten uppger att korrigeringar ska föras över. Om karaktären följer ”lådan är grön” en gång men senare återgår beskriver det korrigeringens beständighet; det identifierar inte i sig om orsaken är kontext, informationshämtning, sammanfattning, instruktionskonflikt eller minnesutformning.

För en designer pekar samma fem fall mot en praktisk utvärdering: behåll ett harmlöst fiktivt faktum oförändrat, variera samtalets längd och faktumets placering, visa eller logga hämtade anteckningar och sammanfattningar där det är lämpligt, inför en kontrollerad motstridig instruktion och ange om faktumet förväntas bestå mellan sessioner. Anteckna vilken källa till sanning varje test bygger på. Då blir ett misslyckande lättare att återskapa, och det blir enklare att skilja ett innehållsproblem från en förväntan som produkten aldrig har utlovat.

En välgrundad slutsats bör ange beläggen och deras begränsning: ”Jämförelsen med en ny chatt tyder på en effekt av det långa samtalet, men jag kan inte avgöra om detaljen kapades bort, inte hämtades eller åsidosattes.” Det är mer användbart än att kalla varje miss en minnesmiss — och mer korrekt när appens implementation är okänd.