Aktivt kontra beständigt minne inom AI: hur AI minns, hämtar och glömmer

Aktivt minne är den information som ett AI-system har tillgång till för den uppgift det arbetar med just nu. Beständigt minne är information som den omgivande applikationen sparar så att den kan användas igen senare. Relationen mellan dem avgör om en assistent kan fortsätta med ett projekt, tillämpa en preferens, korrigera ett föråldrat antagande eller sluta ta upp något igen som den borde ha glömt.

Tänk dig en assistent som hjälper dig att ta fram en forskningsrapport. Under en konversation kan den hänvisa till dispositionen, dina senaste ändringar och källorna du just har skickat. Om du öppnar en separat konversation en vecka senare beror kontinuiteten på en annan mekanism: om applikationen sparade den relevanta informationen, kan hitta den och skickar den till modellen igen.

Därför kan en AI verka minnas en detalj men glömma en annan från samma utbyte. Att minnas är en kedja av operationer. Ett fel kan uppstå när information samlas in, lagras, söks fram, väljs ut, tolkas eller uppdateras.

Den här guiden går igenom den kedjan i detalj. Läs vår introduktion till typer av AI-agentminnen för en bredare taxonomi över episodiskt, semantiskt och procedurminne. Här ligger fokus på gränsen mellan det som är aktivt just nu och det som kan finnas kvar efter den aktuella uppgiften.

Vad betyder aktivt respektive beständigt minne egentligen?

Termerna beskriver användbara arkitektoniska skillnader, men de utgör inte ett universellt standardiserat begreppspar. I produktgränssnitt och forskningsartiklar används ”arbetsminne”, ”korttidsminne”, ”kontext”, ”tillstånd” och ”långtidsminne” på sätt som överlappar varandra. Därför behöver en precis förklaring definiera sina begrepp.

I den här artikeln betyder aktiv kontext den information som ges till modellen för dess aktuella svar: instruktioner, meddelanden, utvalda verktygsresultat, hämtat material och andra indata som modellen kan bearbeta. Aktivt uppgiftstillstånd är ett bredare begrepp. Det kan omfatta en plan, en checklista eller variabler som applikationen hanterar men ännu inte har lagt in i modellens kontext. Vi använder aktivt minne som ett praktiskt samlingsbegrepp för den aktuella arbetsmängden, men skiljer mellan de två när det är relevant.

Beständigt minne är information som bevaras över en svars- eller sessionsgräns och fortfarande är tillgänglig för senare användning. Det kan vara en sparad preferens, en projektanteckning, en händelselogg, ett strukturerat databasfält eller en kontrollpunkt som gör det möjligt att återuppta en oavslutad uppgift. Beständighet beskriver att informationen bevaras; det innebär inte någon garanti för att den delas mellan alla konversationer.

Det handlar alltså om två separata frågor: Finns informationen fortfarande kvar? och Får modellen tillgång till den när den behöver den? En sparad utskrift av en konversation kan besvara den första frågan utan att lösa den andra.

Det viktiga undantaget: kortvarigt tillstånd kan sparas

”Kortvarigt” betyder inte alltid ”lagrat enbart i flyktigt RAM-minne”. En konversations arbetsläge kan sparas som en kontrollpunkt i en databas och återupptas efter ett avbrott. Dokumentationen om minne från LangChain skiljer till exempel mellan trådspecifikt tillstånd som bevaras via kontrollpunkter och långtidsminne som organiseras i separata namnrymder.

Föreställ dig en supportagent som pausar i väntan på att en kund ska ladda upp ett kvitto. Den sparade kontrollpunkten hör till det supportärendet. Kontrollpunkten är beständig, men den bör inte automatiskt bli ett allmänt faktum om kunden eller dyka upp i orelaterade förfrågningar.

Ett användbart sätt att utvärdera en minnesfunktion är att undersöka tre dimensioner: dess livslängd, dess omfattning och dess tillgänglighet för det aktuella modellanropet. En beteckning som ”långsiktigt” besvarar inte någon av de frågorna fullständigt.

Aktivt kontra beständigt minne i korthet

Samma uppgift kan förekomma i båda kolumnerna. En sparad projektinställning är beständig; den kopia som infogas i dagens prompt är aktiv. Att ta bort kopian från prompten innebär inte nödvändigtvis att det sparade originalet tas bort.

Vad händer under ett enskilt AI-svar?

I en typisk applikation med en språkmodell sammanställer den omgivande programvaran en indata, modellen genererar en utdata och programvaran avgör vad som händer härnäst. Indatan kan innehålla den synliga konversationen, men också systeminstruktioner, verktygsbeskrivningar, hämtade anteckningar och information som användaren inte ser i chatttranskriptionen.

Den här sammanställda kontexten är modellens omedelbara underlag. Om ett tidigare meddelande inte längre ingår kan modellen inte tillförlitligt återskapa dess exakta innehåll bara för att applikationen en gång visade det. Modellen kan dra en rimlig slutsats utifrån ledtrådar i omgivningen, men att dra slutsatser är inte detsamma som att minnas.

Ett verktyg utökar vad systemet kan komma åt. Modellen kan begära en projektfil, få dess innehåll och använda det i ett efterföljande svar. Filen var tillgänglig för applikationen innan den blev aktivt underlag. Den skillnaden förklarar varför en agent kan ha tillgång till ett stort arkiv utan att läsa igenom hela arkivet vid varje tur.

Transformerimplementationer upprätthåller också beräkningstillstånd internt, bland annat cacheminnen som används för att undvika att arbete upprepas. De mekanismerna är användbara för effektiv inferens, men ska inte förväxlas med en redigerbar, behörighetsmedveten registrering av en användares preferenser eller projekthistorik. Ett snabbare svar visar inte att ett personligt minne har skapats.

Varför ett större kontextfönster inte löser minnesproblemet

Ett större kontextfönster gör det möjligt för en applikation att tillhandahålla mer material på en gång. Det kan vara värdefullt när svaret beror på samband i ett långt dokument eller mellan flera relaterade källor. Det avgör inte vilket material som bör bevaras, vilken version som är auktoritativ eller om en användare får komma åt det.

Att information ryms i ett kontextfönster garanterar inte heller att modellen använder den korrekt. Studien Förlorad i mitten visade att de testade modellerna kunde prestera olika beroende på var relevant underlag förekom i långa indata. Resultatet är en varning om att utvärdera hur effektivt kontexten används, i stället för att betrakta den annonserade kapaciteten som en garanti för att modellen minns; det är inte en fast förutsägelse om prestanda för varje nyare modell.

Anta att ett projektarkiv innehåller fyrtio diskussioner om ett lanseringsdatum. I trettionio av dem nämns det ursprungliga datumet, och den senast godkända ändringen flyttar det. Om alla fyrtio diskussioner tillhandahålls uppstår ett problem med både genomläsning och frågan om vilket underlag som gäller. En noggrant underhållen registrering av den aktuella statusen, med en länk till den godkända ändringen, kan göra det lättare att fastställa det relevanta svaret.

Långa kontexter och selektiv informationshämtning kan därför komplettera varandra. Informationshämtning hittar ett användbart urval av underlag, och en tillräckligt stor kontext gör det möjligt för modellen att granska underlaget samlat. Valet av utformning beror på uppgiften, källmaterialets omfattning och konsekvenserna av att missa en reservation.

Hur information blir beständigt minne

Ett beständigt minne börjar med ett beslut om vad som ska sparas. En applikation kan spara en uttrycklig användarinstruktion, härleda en möjlig uppgift från en konversation, bevara en händelse eller skapa en sammanfattning. Varje tillvägagångssätt ger upphov till en annan typ av underlag.

”För Project Cedar ska du använda metriska enheter” är en uttrycklig projektinställning. ”Användaren verkar föredra metriska enheter” är en slutsats. ”De tre senaste Cedar-rapporterna använde metriska enheter” är en observation. En användbar registrering bevarar skillnaderna i stället för att slå ihop dem till ett oreserverat påstående om alla framtida uppgifter.

Vad en användbar registrering innehåller

För en hypotetisk projektassistent kan en post innehålla påståendet, projektidentifieraren, användaren eller organisationen som det hör till, källinteraktionen, en tidsstämpel, en giltighetsstatus och eventuella undantag. Med dessa fält går det att ta reda på var informationen kommer ifrån och om den fortfarande gäller.

{
  "scope": "project:cedar",
  "statement": "Use metric units in project reports",
  "source_type": "explicit_user_instruction",
  "source_ref": "conversation_17/message_8",
  "status": "current",
  "exception": "Client edition may require dual units"
}

Det här är ett exempel på ett schema, inte en universell standard. Syftet är att visa varför ett minne behöver innehålla mer än en mening. En källhänvisning underlättar verifiering, en avgränsning förhindrar övergeneralisering och ett statusfält gör det möjligt att korrigera informationen.

Direkta skrivningar och bakgrundsbehandling

En direkt skrivning kan göra en uttrycklig korrigering tillgänglig redan vid nästa förfrågan. Bakgrundsbehandling kan granska en avslutad interaktion, slå samman dubbletter eller ta fram en mer genomtänkt sammanfattning. LangChains dokumentation beskriver båda metoderna och deras avvägningar, däribland det extra arbete som tillkommer i den direkta svarskedjan.

En praktisk utformning kan spara en bekräftad preferens direkt och behandla en lång forskningssession senare. Systemet måste ändå hantera tiden mellan dessa steg. Om systemet talar om för användaren att en preferens har sparats innan skrivningen har slutförts, kan nästa konversation blotta ett avbrott i kontinuiteten.

Det behövs också en rutin för hur misslyckade minnesskrivningar ska hanteras. Om lagringen tillfälligt inte är tillgänglig kan programmet meddela att sparandet inte slutfördes eller behålla en tydligt markerad väntande åtgärd. Att behandla ett skrivförsök som ett lyckat minne ger användaren en missvisande upplevelse.

Så förs beständiga minnen tillbaka till den aktiva kontexten

Återhämtning av minnen består av en rad beslut om behörighet, relevans och evidens. Först måste systemet identifiera den användare, klientorganisation, det projekt eller den uppgift vars poster det får använda. Därefter hittar det möjliga poster och väljer vilka som ska ingå i svarskontexten.

Metoden för att hämta information bör anpassas efter frågan. Frågan ”Vilket slutdatum har godkänts för Cedar?” besvaras kanske bäst genom en exakt sökning i ett projektfält. Frågan ”Har vi sett det här driftsättningsfelet förut?” kan ha nytta av en sökning med nyckelord och semantisk likhet mellan tidigare incidenter. En vektordatabas är ett möjligt verktyg i den processen, inte ett krav för alla minnen.

Semantisk sökning är särskilt användbar när ordalydelsen ändras. En sökning efter ”hålla rapporter kortfattade” kan matcha en sparad preferens om ”korta sammanfattningar för ledningen”. Ett närliggande påstående kan dock gälla en annan kund eller en övergiven projektversion. Likhet hjälper till att hitta möjliga träffar, men fastställer varken sanningshalt eller behörighet.

Det måste gå att ange att ingen träff hittades

Tänk på frågan: ”Vilken utgiftsgräns godkände jag förra månaden?” Om det inte går att hitta något godkänt belopp bör ett hjälpsamt svar ange vilken information som saknas och be om ett förtydligande. Att hitta på ett rimligt belopp förvandlar ett minne som saknas till ett fabricerat godkännande.

Minnesgränssnittet bör därför skilja mellan en bekräftad träff, en osäker träff, en konflikt och avsaknad av stödjande uppgifter. Dessa utfall kan leda till olika ageranden: svara direkt, förbehålla svaret med en reservation, be om ett förtydligande eller avstå från att agera utifrån ett antagande som saknar stöd.

Även efter hämtningen är tolkningen viktig. En uppgift som säger ”föreslagen högsta budget: $5,000, godkännande inväntas” får inte bli ”godkänd budget: $5,000”. Att behålla förbehållen i den lagrade representationen och i den information som tillhandahålls är lika viktigt som att hitta rätt dokument.

Ett konkret exempel: att hålla reda på ett projekt över tid

Föreställ dig en assistent som hjälper ett team att ta fram Cedar-rapporten. Följande exempel är hypotetiskt, men belyser flera vanliga val när man utformar minnesfunktioner.

Session ett: etablera projektet

Användaren ber om en rapport, anger att metriska enheter ska användas, tillhandahåller tre källor och säger att utkastet ska vara klart på fredag. Den aktiva kontexten innehåller dessa instruktioner och utdrag ur källorna. Det aktiva uppgiftstillståndet visar vilka avsnitt som har färdigställts och vilka påståenden som fortfarande behöver verifieras.

Möjliga beständiga minnesposter fyller olika syften. Önskemålet om metriska enheter hör till projektet. Tidsfristen för utkastet hör till den aktuella milstolpen. De tillhandahållna källorna hör hemma i projektets källarkiv. Påståenden som inte har verifierats hör till en lista över sådant som återstår att undersöka, där osäkerheten bevaras.

Session två: återuppta arbetet med rätt underlag

Tre dagar senare ber användaren assistenten att färdigställa metoddelen. Assistenten behöver den senaste dispositionen, relevanta källor, aktuell uppgiftsstatus och tillämpliga formateringsregler. Den behöver inte nödvändigtvis varje bortvald mening från den tidigare brainstormingsessionen.

Om kontrollpunkten visar att litteraturöversikten är färdig bör assistenten ändå öppna den sparade filen innan den gör ändringar runt omkring. ”Färdig” är ett påstående om hur arbetet fortskrider; det faktiska dokumentet visar vad som har färdigställts. Beständiga hänvisningar till filer kan vara mer användbara än en sammanfattning som försöker återge hela innehållet.

Session tre: tillämpa ett undantag utan att skriva om allt

Användaren ber om en kundversion med både metriska och brittiska måttenheter. Den aktuella uppgiften bör använda båda enhetssystemen. Om den allmänna projektregeln ska ändras beror på användarens formulering och omfattningen av önskemålet: ”för den här versionen” är snävare än ”från och med nu ska båda användas”.

En noggrann assistent registrerar ett undantag som bara gäller den aktuella versionen. En assistent som generaliserar för långt skriver om den allmänna inställningen och för in fel i senare rapporter. Det är ett minnesfel även om varje skrivning till databasen och varje hämtningsförfrågan lyckas.

Session fyra: slutför arbetet och rensa bort tillfälliga uppgifter

När rapporten har levererats bör milstolpen markeras som slutförd. En instruktion om att ”fortsätta med rapporten” bör leda assistenten till den levererade versionen, så att den kan fråga vilken ändring som behövs, i stället för att återuppta en inaktuell checklista. Tillfälliga arbetsanteckningar kan löpa ut enligt projektets policy, medan slutrapporten och viktiga beslut finns kvar.

Här blir värdet av beständigt minne tydligt: mindre upprepad förklaring och bättre kontinuitet. Även kostnaden framgår: applikationen måste hålla reda på sambanden mellan önskemål, undantag, filer och en uppgiftsstatus som förändras över tid.

Sammanfattning, komprimering och risken att undantaget går förlorat

Långa interaktioner kan samla på sig mer material än vad som är användbart för nästa svar. Komprimering ersätter delar av historiken med en mer begränsad representation. En sammanfattning kan bevara målet, besluten, de obesvarade frågorna och hänvisningarna till det underliggande arbetet.

Vägledning från Anthropic om kontextutformning beskriver komprimering och anteckningar som lagras utanför kontextfönstret som metoder för att upprätthålla kontinuitet under längre arbetsprocesser. Båda teknikerna förändrar vilket material framtida svar kan bygga på, så kvaliteten är viktig.

Komprimering innebär att man väljer ut viss information. En sammanfattning som ”Använd metriska enheter” är kortare än ”Använd metriska enheter utom i kundversionen, där båda enhetssystemen krävs.” Men den är också fel i ett av projektets viktiga fall. Det borttappade undantaget kan i tysthet följa med i senare sammanfattningar och bli svårt att spåra.

För vår Cedar-assistent skulle en bättre överlämning bevara den allmänna regeln, dess undantag, de färdigställda avsnitten, de återstående verifieringsuppgifterna och hänvisningar till de senaste filerna. Exakta uppgifter, som godkända belopp eller identifierare, bör finnas kvar i strukturerade poster eller källdokument när det kan vara skadligt att ange dem ungefärligt.

Sammanfattningar bör också bevara osäkerhet. ”Vi övervägde att använda Survey B” får inte bli ”Survey B valdes”. Om den komprimerade historiken får preliminära beslut att framstå som slutgiltiga har systemet skapat ett falskt minne i försöket att spara utrymme i kontexten.

Hur AI-minnen bör hantera korrigeringar och motstridiga uppgifter

Det bestående minnet blir mindre användbart om det inte går att ändra. Projekt förändras, preferenser utvecklas och det visar sig att tidigare information var felaktig. Om en korrigering läggs till som ytterligare en okvalificerad post kan hämtningssystemet tvingas välja mellan två motstridiga påståenden.

En mer användbar uppdatering visar vad de nya beläggen ersätter. Om projektägaren flyttar ett lanseringsdatum från 15 november till 29 november kan den gamla posten markeras som ersatt och länkas till det nya beslutet. Frågor om den aktuella tidsfristen besvaras med den nya versionen, medan frågor om den ursprungliga planen kan besvaras med den historiska versionen.

Det går inte att lösa alla konflikter enbart genom att välja den senaste uppgiften. En ny anteckning i ett utkast kan ha lägre auktoritet än en äldre, godkänd policy. En användare kan ha behörighet att ändra en personlig preferens utan att ha behörighet att ändra en regel som gäller hela organisationen. Policyn för uppdateringar måste ta hänsyn till vilken typ av uppgift det gäller och vilken auktoritet källan har.

Vissa motsägelser bör förbli olösta tills en person har rett ut dem. Om två projektägare anger oförenliga datum utan att uttryckligen ersätta det ena med det andra kan assistenten visa båda källorna och fråga vilket datum som gäller. Att i tysthet välja den mest likartade eller senaste posten döljer ett beslut som systemet kanske inte har rätt att fatta.

Vad innebär det att AI glömmer?

Glömska är ingen enskild strömbrytare. En produkt kan sluta lägga in en uppgift i promptar, utesluta den från vanliga sökningar, markera den som inaktuell, radera minnesposten eller ta bort andra sparade kopior. Åtgärderna påverkar framtida beteende och sparade data på olika sätt.

När information lämnar den aktiva kontexten

En uppgift kan försvinna från nästa indata till modellen för att äldre meddelanden har utelämnats eller sammanfattats. Då minskar mängden information som modellen kan använda direkt. Det ursprungliga transkriptet eller minnesposten kan fortfarande finnas kvar och hämtas in igen senare.

När återkallning upphör eller undertrycks

En utgången tidsfrist kan finnas kvar i ett arkiv samtidigt som den utesluts från sökningar om det aktuella arbetet. Undertryckning är användbar när det finns ett syfte med att bevara historiken, men bör inte beskrivas som fullständig radering. En historisk sökning eller ett administrativt arbetsflöde kan fortfarande komma åt posten.

Radera lagrat minne

När en beständig post raderas bör även de representationer som härletts från den och används för informationshämtning hanteras. Om en mening tas bort från en profil men finns kvar i en sökbar sammanfattning kan assistenten senare återskapa samma preferens. Källposter, inbäddningar, sammanfattningar, cachar och repliker kan kräva separata borttagningsåtgärder beroende på arkitekturen.

Säkerhetskopior och loggar kan omfattas av egna lagringsfrister. En produkt bör tydligt förklara dessa gränser och förhindra att raderat material blir aktivt igen vid en återställning. ”Vi kommer inte längre att använda det här minnet” och ”alla sparade kopior har tagits bort” är två olika löften.

Ändra modellvikter

Att radera ett externt minne ändrar inte i sig modellens parametrar. Om informationen användes vid träning är det en separat fråga att hantera den i modellen, vilket kräver åtgärder i tränings- och driftsättningsprocessen. På samma sätt kan radering av ett personligt minne inte garantera att modellen aldrig genererar en liknande uppgift utifrån allmän kunskap eller ledtrådar i en ny prompt.

Ett meningsfullt test av glömska undersöker därför både om systemet fortfarande lagrar informationen och om dess vanliga sökvägar kan göra den tillgänglig igen. Ett enda chattsvar där systemet säger ”jag har glömt” bevisar inget av detta.

Minne, RAG, träning och cachelagring: var gränserna går

Retrieval-augmented generation, eller RAG, förser en modell med externa belägg medan den genererar svar. Den ursprungliga RAG-forskningen kombinerade modellparametrar med ett sökbart dokumentindex. Ett personligt minnessystem kan också använda sökning, men behöver dessutom regler för att skapa, uppdatera och ta bort poster från interaktioner.

En företagshandbok kan hämtas utan att vara ett minne av användaren. En anteckning om en tidigare interaktion kan hämtas från en enkel fil utan vektorindex. Hämtning är en mekanism; syftet med och livscykeln för de underliggande posterna avgör vilken typ av system som byggs.

Träning och finjustering ändrar modellparametrarna. Externt minne ändrar i stället de belägg som tillförs en modell. En assistent som följer en nyligen sparad preferens kan bete sig annorlunda även om modellens vikter förblir oförändrade.

Prompt- och inferenscachelagring återanvänder tidigare beräkningar där det stöds. Det kan öka effektiviteten, men fastställer inte i sig om ett ihågkommet påstående är aktuellt, godkänt eller lämpligt för framtida uppgifter. Dessa lager kan samexistera, och vid felsökning måste man identifiera vilket lager som orsakar det observerade beteendet.

MemGPT är ett inflytelserikt arkitektoniskt exempel: där undersöktes hur information kunde flyttas mellan ett begränsat kontextfönster och externa minnesnivåer med hjälp av en analogi till operativsystem. Den viktiga lärdomen är att informationsflödet måste hanteras uttryckligen, snarare än att anta att lagring automatiskt utökar modellens omedelbara kontext utan begränsningar.

Varför bestående minne kan göra misstag mer långlivade

Ett felaktigt svar kan påverka en interaktion. Ett felaktigt minne kan påverka många. Om en assistent drar slutsatsen att en användare har godkänt ett beslut, sparar slutsatsen som ett faktum och senare hänvisar till den sparade posten kan assistentens eget tidigare misstag börja framstå som oberoende belägg.

För vår projektassistent bör det gå att skilja den ursprungliga källan från modellens tolkning. En sammanfattning av ett beslut kan underlätta orienteringen, men själva det godkända beslutet bör ligga till grund för alla åtgärder med betydande konsekvenser. Att samma sak upprepas i flera genererade anteckningar gör inte ett obestyrkt antagande till flera oberoende bekräftelser.

Bestående minne skapar också en väg för instruktionskontaminering. Ett dokument från en opålitlig källa kan innehålla en mening som uppmanar assistenten att ändra sitt framtida beteende. Om den meningen lagras som en operativ regel flyttas externt innehåll över en auktoritetsgräns. Applikationen bör hantera innehållet utifrån dess källa, i stället för att upphöja det till en betrodd instruktion bara för att det finns i ett minneslager.

Delade miljöer skapar ytterligare en gräns. Ett faktum kan vara relevant för en fråga men tillhöra en annan kund eller ett annat projekt. Åtkomstkontroller bör begränsa vad som hämtas innan informationen når modellen. Det är en sämre lösning att be modellen ignorera obehöriga poster efter att de redan har förmedlats till den.

Så utvärderar du om minnet faktiskt fungerar

En övertygande demonstration ber ofta assistenten upprepa en sparad preferens. En grundlig utvärdering följer information som förändras över flera sessioner och undersöker om minnet förbättrar den slutförda uppgiften.

LongMemEval utvärderar informationsutvinning, resonemang över flera sessioner, tidsmässigt resonemang, kunskapsuppdateringar och förmågan att avstå från att svara. Dessa kategorier visar varför kvaliteten på långtidsminne omfattar mer än att hitta en enda matchande mening. Publicerade benchmarkresultat bör tolkas utifrån de system och inställningar som testats, inte antas beskriva alla aktuella produkter.

För arbetsflödet Cedar skulle en utvärdering kunna introducera en preferens, återuppta projektet, lägga till ett undantag, ändra en tidsfrist, radera en anteckning och därefter ställa frågor som är utformade för att avslöja inaktuell eller obestyrkt återgivning. Samma modell bör också testas utan minnesfunktionen för att fastställa om det tillagda systemet förbättrar resultaten.

• Skrivprecision: Sparade systemet det avsedda påståendet med dess räckvidd och förbehåll?
• Ändamålsenlig hämtning: Hittade systemet de belägg som behövdes för uppgiften utan att fylla kontexten med ovidkommande historik?
• Hantering av uppdateringar: Ersatte en korrigering det aktuella faktumet samtidigt som användbara historiska skillnader bevarades?
• Förmåga att avstå: Medgav assistenten när det saknades en post som stödde svaret?
• Isolering: Hölls posterna åtskilda för rätt användare, kundmiljö och projekt?
• Glömska: Förhindrade radering eller upphörande att informationen återkallades i framtiden, även via härledda sammanfattningar?
• Driftskostnad: Motiverade förbättringarna den ökade fördröjningen, de extra modellkörningarna, lagringen och underhållet?

Fel bör spåras till ett visst steg. Ett uteblivet svar kan bero på en misslyckad skrivning, ett felaktigt sökomfång, ett dåligt rangordningsbeslut, en utelämnad reservation eller att modellen misstolkade välgrundade belägg. Att öka kontextstorleken löser inte alla sådana problem.

Att välja rätt minnesdesign

En engångssammanfattning av ett dokument kanske bara behöver det aktuella dokumentet och instruktionerna. En avbruten analys har nytta av en kontrollpunkt för uppgiften. En assistent för återkommande projekt kan behöva versionshanterade beslut och referenser till artefakter. En assistent som arbetar över många användarsessioner kan behöva ett separat, redigerbart preferensregister.

Börja med att precisera vilken framtida fråga minnet är tänkt att besvara. ”Vad återstår att göra?” kräver information om uppgiftens status. ”Vilket format kräver den här klienten?” kräver en avgränsad preferens. ”Varför avvisade vi det här tillvägagångssättet?” kräver en beslutsanteckning med stödjande belägg. Olika frågor kräver olika representationer.

Föredra ett litet antal tydliga poster med angiven källa framför ett urskillningslöst arkiv som presenteras som personalisering. Håll aktuell status åtskild från historiska händelser, bevara länkar till källartefakter och bygg in möjligheter till korrigering och radering redan från början.

Aktivt minne ger ett AI-system en sammanhängande nutid. Beständigt minne kan ge det kontinuitet över tid. Kvaliteten på den kontinuiteten beror på besluten däremellan: vad som sparas, vad som hämtas tillbaka, vilken version som gäller och vad som får försvinna.