Aktivt vs. vedvarende minne i KI: Hvordan KI husker, henter frem og glemmer

Aktivt minne er informasjonen et KI-system har tilgjengelig for oppgaven det arbeider med akkurat nå. Vedvarende minne er informasjon som programmet rundt systemet beholder, slik at den kan brukes igjen senere. Forholdet mellom dem avgjør om en assistent kan fortsette et prosjekt, følge en preferanse, korrigere en utdatert antakelse eller slutte å hente frem noe den burde ha glemt.

Tenk deg en assistent som hjelper deg med å lage en forskningsrapport. I én samtale kan den vise til disposisjonen, de siste endringene dine og kildene du nettopp la ved. Hvis du åpner en ny samtale en uke senere, avhenger kontinuiteten av en annen mekanisme: om programmet lagret den relevante informasjonen, kan finne den igjen og gir den til modellen på nytt.

Derfor kan en KI se ut til å huske én detalj, men glemme en annen fra den samme samtalen. Det å huske er en kjede av operasjoner. En feil kan oppstå når informasjon fanges opp, lagres, søkes frem, velges ut, tolkes eller oppdateres.

Denne veiledningen undersøker denne kjeden i detalj. Hvis du vil lese mer om den bredere inndelingen i episodisk, semantisk og prosedyrebasert minne, kan du se introduksjonen vår til ulike typer minne for KI-agenter. Her retter vi oppmerksomheten mot grensen mellom det som er aktivt nå, og det som kan bevares etter at den aktuelle oppgaven er over.

Hva betyr aktivt og vedvarende minne egentlig?

Disse begrepene beskriver nyttige arkitektoniske skiller, men de utgjør ikke et universelt standardisert begrepspar. Brukergrensesnitt og forskningsartikler bruker «arbeidsminne», «korttidsminne», «kontekst», «tilstand» og «langtidsminne» på måter som overlapper. En presis forklaring må derfor definere begrepene.

I denne artikkelen betyr aktiv kontekst informasjonen som gis til modellen for det aktuelle svaret: instruksjoner, meldinger, utvalgte verktøyresultater, innhentet materiale og andre inndata modellen kan behandle. Aktiv oppgavetilstand er et bredere begrep. Det kan omfatte en plan, en sjekkliste eller variabler som programmet vedlikeholder, men ennå ikke har lagt inn i modellens kontekst. Vi bruker aktivt minne som en praktisk samlebetegnelse for dette aktuelle arbeidssettet, men skiller mellom de to når det er relevant.

Vedvarende minne er informasjon som beholdes etter at et svar eller en økt er avsluttet, og som fortsatt er tilgjengelig for senere bruk. Det kan være en lagret preferanse, et prosjektnotat, en hendelsesregistrering, et strukturert databasefelt eller et sjekkpunkt som gjør det mulig å fortsette en uferdig oppgave. Vedvarenhet beskriver hvor lenge informasjonen beholdes; det garanterer ikke at den deles på tvers av alle samtaler.

Det er derfor to separate spørsmål: Finnes informasjonen fortsatt? og Får modellen den når den trenger den? En lagret samtalelog kan besvare det første spørsmålet uten å løse det andre.

Det viktige unntaket: Kortvarig tilstand kan lagres

«Kortvarig» betyr ikke alltid «lagret bare i flyktig RAM». Arbeidstilstanden i en samtale kan lagres som et sjekkpunkt i en database og gjenopptas etter et avbrudd. LangChains dokumentasjon om minne skiller for eksempel mellom tilstand med omfang begrenset til en samtaletråd, som bevares gjennom sjekkpunkter, og langtidsminne som organiseres i separate navnerom.

Se for deg en kundestøtteagent som setter arbeidet på pause mens den venter på at en kunde skal laste opp en kvittering. Det lagrede sjekkpunktet hører til den aktuelle kundestøttesaken. Sjekkpunktet er varig, men bør ikke automatisk bli en generell opplysning om kunden eller dukke opp i forespørsler som ikke har med saken å gjøre.

En nyttig måte å vurdere en minnefunksjon på er å undersøke tre dimensjoner: varigheten, omfanget og tilgjengeligheten for det aktuelle modellkallet. En betegnelse som «langtidsminne» besvarer ikke alle disse spørsmålene fullt ut.

Aktivt og vedvarende minne – en rask oversikt

Den samme opplysningen kan forekomme i begge kolonnene. En lagret prosjektpreferanse er vedvarende; kopien som legges inn i dagens ledetekst, er aktiv. Hvis denne kopien fjernes fra ledeteksten, betyr ikke det nødvendigvis at den lagrede originalen også fjernes.

Hva skjer under ett enkelt AI-svar?

I en typisk applikasjon for språkmodeller setter den omkringliggende programvaren sammen et inndata, modellen genererer et svar, og programvaren avgjør hva som skal skje videre. Inndataene kan inneholde samtalen slik den vises, men også systeminstruksjoner, verktøybeskrivelser, hentede notater og informasjon som brukeren ikke ser i samtaleloggen.

Denne sammensatte konteksten er modellens umiddelbare grunnlag. Hvis en tidligere melding ikke lenger er med, kan modellen ikke pålitelig hente fram det nøyaktige innholdet bare fordi applikasjonen en gang viste det. Den kan utlede et plausibelt svar fra omkringliggende ledetråder, men utledning er ikke det samme som gjenkalling.

Et verktøy utvider hva systemet har tilgang til. Modellen kan be om en prosjektfil, motta innholdet og bruke det i et senere svar. Filen var tilgjengelig for applikasjonen før innholdet ble en del av det aktive grunnlaget. Denne forskjellen forklarer hvorfor en agent kan ha tilgang til et stort arkiv uten å lese hele arkivet hver gang den svarer.

Implementasjoner av transformermodeller opprettholder også interne beregningstilstander, blant annet hurtigbuffere som brukes for å unngå å gjenta arbeid. Disse mekanismene er nyttige for effektiv inferens, men må ikke forveksles med en redigerbar oversikt over brukerens preferanser eller prosjekthistorikk som tar hensyn til tillatelser. Et raskere svar er ikke bevis på at et personlig minne er opprettet.

Hvorfor et større kontekstvindu ikke løser minneproblemet

Et større kontekstvindu gjør det mulig for en applikasjon å gi modellen mer materiale på én gang. Det kan være nyttig når svaret avhenger av sammenhenger på tvers av et langt dokument eller flere relaterte kilder. Det avgjør ikke hvilket materiale som bør bevares, hvilken versjon som er autoritativ, eller om en bruker har tilgang til det.

At informasjon får plass i et kontekstvindu, garanterer heller ikke at modellen bruker den riktig. Studien Tapt i midten viste at modellene som ble testet, kunne prestere ulikt avhengig av hvor i lange inndata relevant grunnlag forekom. Resultatet er en påminnelse om å evaluere hvor effektivt konteksten brukes, i stedet for å behandle oppgitt kapasitet som en garanti for gjenkalling; det er ikke en fast ytelsesprognose for alle nyere modeller.

Tenk deg at et prosjektarkiv inneholder førti diskusjoner om en lanseringsdato. I trettini av dem nevnes den opprinnelige datoen, og den siste godkjente endringen flytter den. Hvis alle førti diskusjonene legges fram, oppstår det et problem med både gjennomlesning og autoritet. En nøye vedlikeholdt oversikt over gjeldende status, knyttet til den godkjente endringen, kan gjøre det enklere å fastslå det relevante svaret.

Lang kontekst og selektiv gjenfinning kan derfor utfylle hverandre. Gjenfinning finner et nyttig utvalg av grunnlagsmateriale; et tilstrekkelig stort kontekstvindu lar modellen undersøke dette materialet samlet. Valget av løsning avhenger av oppgaven, omfanget av kildematerialet og konsekvensene av å overse et forbehold.

Slik blir informasjon til vedvarende minne

Et varig minne begynner med en beslutning om hva som skal lagres. En applikasjon kan lagre en uttrykkelig brukerbeskjed, utlede en mulig opplysning fra en samtale, ta vare på en hendelse eller lage et sammendrag. Hver framgangsmåte gir en ulik type grunnlag.

«For Project Cedar, bruk metriske enheter» er en uttrykkelig prosjektpreferanse. «Brukeren ser ut til å foretrekke metriske enheter» er en slutning. «De tre siste Cedar-rapportene brukte metriske enheter» er en observasjon. En nyttig oppføring bevarer disse forskjellene i stedet for å slå dem sammen til en udifferensiert påstand om alle framtidige oppgaver.

Hva en nyttig oppføring inneholder

For en tenkt prosjektassistent kan en oppføring inneholde utsagnet, prosjektidentifikatoren, brukeren eller organisasjonen den tilhører, kildeinteraksjonen, et tidsstempel, en gyldighetsstatus og eventuelle unntak. Disse feltene gjør det mulig å undersøke hvor informasjonen kom fra, og om den fortsatt gjelder.

{
  "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"
}

Dette er et illustrerende skjema, ikke en universell standard. Hensikten er å vise hvorfor et minne bør inneholde mer enn én setning. En kildehenvisning gjør det enklere å kontrollere opplysningen, avgrensning hindrer overgeneralisering, og et statusfelt gjør det mulig å korrigere den.

Umiddelbar lagring eller behandling i bakgrunnen

En umiddelbar lagring kan gjøre en uttrykkelig korrigering tilgjengelig allerede for den neste forespørselen. Behandling i bakgrunnen kan gå gjennom en fullført interaksjon, slå sammen duplikater eller utarbeide et mer gjennomarbeidet sammendrag. Dokumentasjonen til LangChain beskriver begge tilnærmingene og avveiningene ved dem, blant annet det ekstra arbeidet som legges til i den umiddelbare svarprosessen.

En praktisk løsning kan lagre en bekreftet preferanse umiddelbart og behandle en lang forskningsøkt senere. Den må likevel håndtere tidsrommet mellom disse trinnene. Hvis systemet forteller brukeren at det har lagret en preferanse før lagringen er fullført, kan den neste samtalen avdekke et brudd i kontinuiteten.

Lagring av minner må også ha en strategi for feil. Hvis lagringsplassen midlertidig er utilgjengelig, kan programmet opplyse om at lagringen ikke ble fullført, eller beholde en tydelig merket, ventende operasjon. Hvis et forsøk på lagring behandles som et vellykket minne, gir det brukeren en misvisende opplevelse.

Slik hentes vedvarende minner inn i den aktive konteksten

Gjenfinning innebærer en rekke beslutninger om hva som er relevant, hvilke opplysninger som kan brukes, og hvilket grunnlag de har. Først må systemet identifisere brukeren, kundeinstansen, prosjektet eller oppgaven det kan hente oppføringer fra. Deretter finner det aktuelle oppføringer og velger hva som skal inngå i konteksten for svaret.

Metoden for gjenfinning bør passe til spørsmålet. «Hva er den godkjente fristen for Cedar?» besvares kanskje best ved å slå opp et bestemt prosjektfelt. «Har vi sett denne distribusjonsfeilen før?» kan være lettere å besvare ved å søke etter nøkkelord og semantisk likhet i tidligere hendelser. En vektordatabase er ett alternativ i denne prosessen, men er ikke et krav for alt minne.

Semantisk søk er særlig nyttig når ordlyden endres. Et spørsmål om «å holde rapporter konsise» kan samsvare med en lagret preferanse for «korte sammendrag for ledelsen». En beslektet uttalelse kan imidlertid gjelde en annen klient eller en forlatt prosjektversjon. Likhet identifiserer mulige treff; den fastslår verken sannhet eller tillatelse.

Gjenfinning må kunne gi beskjed når ingenting blir funnet

Tenk på spørsmålet «Hvilken utgiftsgrense godkjente jeg forrige måned?» Hvis det ikke er mulig å finne et godkjent beløp, bør et nyttig svar gjøre oppmerksom på at dokumentasjonen mangler, og be om en avklaring. Å oppgi et sannsynlig beløp gjør fravær av et minne om til en oppdiktet godkjenning.

Minnegrensesnittet bør derfor skille mellom et bekreftet treff, et usikkert treff, en motstrid og ingen støttende opplysninger. Disse utfallene kan føre til ulik atferd: svare direkte, ta forbehold i svaret, be om en avklaring eller avstå fra å handle på grunnlag av en udokumentert antakelse.

Også etter at informasjonen er hentet fram, er tolkningen viktig. En oppføring som sier «foreslått maksimumsbudsjett: 5 000 dollar, godkjenning avventes», må ikke bli til «godkjent budsjett: 5 000 dollar». Det er like viktig å bevare forbeholdene i den lagrede informasjonen og den tilførte konteksten som å finne riktig dokument.

Et gjennomarbeidet eksempel: Slik husker man et prosjekt over tid

Se for deg en assistent som hjelper et team med å utarbeide Cedar-rapporten. Eksemplet nedenfor er hypotetisk, men viser flere vanlige valg knyttet til minneutforming.

Økt én: Etabler prosjektet

Brukeren ber om en rapport, angir metriske måleenheter, oppgir tre kilder og sier at utkastet skal leveres fredag. Den aktive konteksten omfatter disse instruksjonene og kildeutdragene. Den aktive oppgavestatusen registrerer hvilke avsnitt som er ferdige, og hvilke påstander som fortsatt må verifiseres.

Mulige opplysninger som kan lagres permanent, har ulike formål. Preferansen for metriske måleenheter hører til prosjektet. Fristen for utkastet gjelder den aktuelle milepælen. De oppgitte kildene hører hjemme i prosjektets dokumentasjonsarkiv. Påstander som ikke er verifisert, hører hjemme på en liste over videre undersøkelser, og usikkerheten rundt dem må bevares.

Økt to: Fortsett med riktig dokumentasjon

Tre dager senere ber brukeren om å ferdigstille metodedelen. Assistenten trenger den nyeste disposisjonen, relevante kilder, gjeldende oppgavestatus og den aktuelle formateringsregelen. Den trenger ikke nødvendigvis hver eneste setning som ble forkastet under den tidligere idémyldringsøkten.

Hvis kontrollpunktet sier at litteraturgjennomgangen er ferdig, bør assistenten likevel åpne det lagrede dokumentet før den redigerer videre. «Ferdig» er en påstand om framdrift; selve dokumentet viser hva som faktisk ble ferdigstilt. Varige lenker til dokumenter kan være mer nyttige enn en oppsummering som forsøker å gjengi hele innholdet deres.

Økt tre: Bruk et unntak uten å skrive om alt

Brukeren ber om en kundeutgave med både metriske og imperiale måleenheter. Den aktuelle oppgaven skal bruke begge målesystemene. Om den generelle prosjektregelen også skal endres, avhenger av brukerens ordlyd og hvor omfattende forespørselen er: «for denne utgaven» er mer avgrenset enn «bruk begge fra nå av».

En grundig assistent registrerer et unntak som gjelder for den aktuelle utgaven. En assistent som generaliserer for mye, skriver om den globale preferansen og fører dermed til feil i senere rapporter. Dette er en svikt i minnehåndteringen, selv om alle databaseoperasjoner for lagring og gjenfinning fungerer som de skal.

Økt fire: Gjør ferdig arbeidet og fjern midlertidig informasjon

Etter leveringen bør milepælen markeres som fullført. En instruksjon om å «fortsette rapporten» bør få assistenten til å gå til den leverte versjonen og spørre hvilken revisjon som trengs, i stedet for å gjenoppta en utdatert sjekkliste. Midlertidige arbeidsnotater kan utløpe i tråd med prosjektets retningslinjer, mens den endelige rapporten og viktige beslutninger fortsatt er tilgjengelige.

Her ser vi verdien av vedvarende minne: færre gjentatte forklaringer og bedre kontinuitet. Vi ser også kostnaden: Programmet må holde oversikt over sammenhengene mellom preferanser, unntak, dokumenter og endringer i oppgavestatus.

Oppsummering, komprimering og risikoen for å miste unntaket

Lange samtaler kan etter hvert inneholde mer informasjon enn det som er nyttig for neste svar. Komprimering erstatter deler av samtalehistorikken med en kortere framstilling. En oppsummering kan bevare målet, beslutningene, uavklarte spørsmål og lenker til det underliggende arbeidet.

Anthropics veiledning om kontekstutforming beskriver komprimering og notater som lagres utenfor kontekstvinduet, som metoder for å opprettholde kontinuitet under langvarig arbeid. Begge metodene endrer hvilket materiale framtidige svar bygger på, så kvaliteten er viktig.

Komprimering innebærer utvalg. En oppsummering som «Bruk metriske måleenheter», er kortere enn «Bruk metriske måleenheter, bortsett fra i kundeutgaven, som krever begge målesystemene». Men den er også feil i et viktig tilfelle i prosjektet. Det utelatte unntaket kan bli videreført ubemerket i senere oppsummeringer og bli vanskelig å spore.

For Cedar-assistenten vår ville en bedre overlevering bevart den generelle regelen, unntaket fra den, avsnittene som er ferdige, oppgavene som gjenstår for verifisering, og henvisningene til de nyeste filene. Nøyaktige opplysninger, som godkjente beløp eller identifikatorer, bør fortsatt stå i strukturerte oppføringer eller kildedokumenter når det kan være skadelig å bruke omtrentlige verdier.

Oppsummeringer bør også bevare usikkerhet. «Vi vurderte å bruke Survey B» må ikke bli til «Survey B ble valgt». Hvis den komprimerte historikken får foreløpige beslutninger til å framstå som endelige, har systemet skapt et falskt minne i forsøket på å spare kontekst.

Slik bør AI-minne håndtere korrigeringer og motstridende opplysninger

Vedvarende minne blir mindre nyttig hvis det ikke kan endres. Prosjekter utvikler seg, preferanser endrer seg, og tidligere informasjon viser seg å være feil. Hvis en korrigering legges til som enda en udifferensiert oppføring, kan gjenfinningssystemet bli stående og velge mellom to motstridende påstander.

En mer nyttig oppdatering angir hva de nye opplysningene erstatter. Hvis prosjektansvarlig flytter en lanseringsdato fra 15. november til 29. november, kan den gamle oppføringen merkes som erstattet og kobles til den nye beslutningen. Spørsmål om gjeldende frist besvares ut fra den nye versjonen, mens spørsmål om den opprinnelige planen kan besvares ved å se på den historiske versjonen.

Det er ikke alltid nok å se på hva som er nyest for å løse en konflikt. Et nylig notat i et utkast kan være mindre autoritativt enn en eldre, godkjent retningslinje. En bruker kan ha fullmakt til å endre en personlig preferanse uten å ha fullmakt til å endre en regel som gjelder hele organisasjonen. Retningslinjene for oppdateringer må ta hensyn til hva slags opplysning det dreier seg om, og hvor autoritativ kilden er.

Noen motsetninger bør forbli uløste til en person avklarer dem. Hvis to prosjektansvarlige oppgir datoer som ikke stemmer overens, uten at det uttrykkelig er fastslått at den ene erstatter den andre, kan assistenten vise til begge kildene og spørre hvilken dato som gjelder. Å velge den mest like eller nyeste oppføringen uten å si fra skjuler en beslutning systemet kanskje ikke har myndighet til å ta.

Hva vil det si at KI glemmer?

Glemsel er ikke én enkelt bryter. Et produkt kan slutte å sette inn en opplysning i ledetekster, utelate den fra vanlige søk, merke den som utdatert, slette minneoppføringen eller fjerne andre lagrede kopier. Disse handlingene har ulike følger for fremtidig atferd og lagrede data.

Ute av den aktive konteksten

En opplysning kan forsvinne fra neste inndata til modellen fordi eldre meldinger er utelatt eller oppsummert. Dermed får modellen mindre informasjon den kan bruke med en gang. Den opprinnelige samtaleloggen eller minneoppføringen kan fortsatt finnes og kan dukke opp igjen ved en senere gjenfinning.

La gjenfinning utløpe eller undertrykk den

En utløpt frist kan fortsatt finnes i et arkiv, samtidig som den utelates fra søk etter opplysninger om pågående arbeid. Undertrykking er nyttig når det er en hensikt med å bevare historiske data, men bør ikke omtales som fullstendig sletting. Oppføringen kan fortsatt være tilgjengelig gjennom historiske søk eller administrative arbeidsflyter.

Sletting av lagret minne

Når en varig oppføring slettes, bør også gjenfinningsrepresentasjonene som er avledet av den, håndteres. Hvis en setning fjernes fra en profil, men fortsatt finnes i et søkbart sammendrag, kan assistenten senere gjenskape den samme preferansen. Kildeoppføringer, vektorrepresentasjoner, sammendrag, hurtigbuffere og replikaer kan kreve separate slettetiltak, avhengig av arkitekturen.

Sikkerhetskopier og logger kan ha egne oppbevaringsfrister. Et produkt bør forklare disse begrensningene tydelig og hindre at slettet materiale blir aktivt igjen ved gjenoppretting. «Vi kommer ikke lenger til å bruke dette minnet» og «alle lagrede kopier er fjernet» er to forskjellige løfter.

Endring av modellvekter

Sletting av eksternt minne endrer ikke i seg selv modellens parametere. Hvis informasjon ble brukt under trening, er det et separat problem å håndtere den i modellen, og det innebærer trenings- og distribusjonsprosessen. På samme måte kan sletting av et personlig minne ikke garantere at modellen aldri vil generere en lignende opplysning basert på generell kunnskap eller ledetråder i en ny ledetekst.

En meningsfull test av glemming undersøker derfor både om systemet fortsatt lagrer informasjonen, og om de vanlige gjenfinningsveiene kan hente den inn igjen. Et enkelt chatsvar der systemet sier «Jeg har glemt det», beviser ingen av delene.

Minne, RAG, trening og bufring: hvor grensene går

Generering med utvidet gjenfinning, eller RAG, tilfører en modell eksterne bevis mens den genererer svar. Den opprinnelige RAG-forskningen kombinerte modellparametere med en søkbar dokumentindeks. Et personlig minnesystem kan også bruke gjenfinning, men trenger i tillegg retningslinjer for å opprette, oppdatere og arkivere oppføringer fra interaksjoner.

En bedriftsmanual kan hentes fram uten å være et minne om brukeren. Et notat om en tidligere interaksjon kan hentes fra en enkel fil uten en vektorindeks. Gjenfinning er en mekanisme; formålet med og livssyklusen til de underliggende oppføringene avgjør hva slags system som bygges.

Trening og finjustering endrer modellparametere. Vanlig ekstern hukommelse endrer i stedet hvilke bevis som tilføres en modell. En assistent som følger en nylig lagret preferanse, kan oppføre seg annerledes selv om modellvektene er uendret.

Bufring av ledetekster og inferens gjenbruker tidligere beregninger der dette støttes. Slik bufring kan øke effektiviteten, men avgjør ikke i seg selv om en opplysning som huskes, er oppdatert, autorisert eller egnet for framtidige oppgaver. Disse lagene kan eksistere side om side, og feilsøking krever at man finner ut hvilket lag som er ansvarlig for den observerte atferden.

MemGPT er et innflytelsesrikt arkitektonisk eksempel: Det utforsket hvordan informasjon kunne flyttes mellom en begrenset kontekst og eksterne minnelag, med en analogi til operativsystemer. Den nyttige lærdommen er at informasjonsflyten må styres eksplisitt, ikke at lagring automatisk utvider modellens umiddelbare kontekst uten begrensninger.

Hvorfor vedvarende minne kan gjøre feil mer langvarige

Et feilaktig svar kan påvirke én interaksjon. Et feilaktig minne kan påvirke mange. Hvis en assistent trekker den slutningen at en bruker har godkjent en beslutning, lagrer slutningen som et faktum og senere viser til den lagrede oppføringen, kan assistentens egen tidligere feil framstå som uavhengig dokumentasjon.

For prosjektassistenten vår bør originalkilden fortsatt kunne skilles fra modellens tolkning. Et sammendrag av en beslutning kan gjøre det enklere å finne fram, men det er selve den godkjente beslutningen som bør ligge til grunn for handlinger med betydelige konsekvenser. At den samme slutningen gjentas i flere genererte notater, gjør den ikke til flere uavhengige bekreftelser.

Vedvarende minne skaper også en mulig kanal for instruksjonsforurensning. Et dokument man ikke stoler på, kan inneholde en setning som ber assistenten endre framtidig atferd. Hvis setningen lagres som en operativ regel, krysser eksternt innhold en autoritetsgrense. Applikasjonen bør behandle setningen ut fra kilden den kommer fra, i stedet for å oppgradere den til en betrodd instruksjon fordi den finnes i et minnelager.

Delte miljøer innebærer enda en grense. En opplysning kan være relevant for et spørsmål, men tilhøre en annen kunde eller et annet prosjekt. Tilgangskontroller bør begrense gjenfinningen før informasjonen når modellen. Det er en svakere løsning å be modellen ignorere uautoriserte oppføringer etter at de allerede er blitt gjort tilgjengelige for den.

Slik vurderer du om minnet faktisk fungerer

En overbevisende demonstrasjon ber ofte assistenten gjenta én lagret preferanse. En grundig evaluering følger informasjon som endrer seg, gjennom flere økter og undersøker om minnet forbedrer oppgaven som fullføres.

LongMemEval evaluerer informasjonsuttrekk, resonnering på tvers av økter, tidsresonnering, kunnskapsoppdateringer og avståelse fra å svare. Disse kategoriene viser hvorfor kvaliteten på langtidsminne handler om mer enn å hente fram én setning som samsvarer. Publiserte referanseresultater bør tolkes ut fra systemene og innstillingene som ble testet, ikke antas å beskrive alle produkter som finnes i dag.

For arbeidsflyten i Cedar kan en evaluering legge inn en preferanse, gjenoppta prosjektet, legge til et unntak, endre en frist, slette et notat og deretter stille spørsmål som er ment å avdekke foreldet eller udokumentert gjenkalling. Den samme modellen bør også testes uten minnefunksjonen for å fastslå om systemet som er lagt til, gir bedre resultater.

• Nøyaktighet ved lagring: Lagret systemet den tiltenkte formuleringen med riktig omfang og forbehold?
• Nyttig gjenfinning: Fant systemet dokumentasjonen som var nødvendig for oppgaven, uten å fylle konteksten med irrelevant historikk?
• Håndtering av oppdateringer: Erstattet en korrigering det gjeldende faktumet, samtidig som nyttige historiske forskjeller ble bevart?
• Avståelse fra å svare: Opplyste assistenten når det ikke fantes noen støttende oppføring?
• Isolering: Ble oppføringene holdt adskilt og begrenset til riktig bruker, leietaker og prosjekt?
• Glemming: Hindret sletting eller utløp den ønskede framtidige gjenkallingen, også via avledede sammendrag?
• Driftskostnader: Forsvarte forbedringene økt forsinkelse, flere modellkall, lagring og vedlikehold?

Feil bør spores tilbake til et bestemt trinn. Et manglende svar kan skyldes en mislykket lagring, feil søkeomfang, en dårlig rangeringsbeslutning, en utelatt presisering eller at modellen feiltolket gode bevis. Det er ikke alle slike feil som kan løses ved å øke kontekststørrelsen.

Slik velger du riktig minneutforming

En oppsummering av et enkeltstående dokument trenger kanskje bare det aktuelle dokumentet og instruksjonene. En avbrutt analyse kan ha nytte av et kontrollpunkt for oppgaven. En assistent for et løpende prosjekt kan trenge versjonerte beslutninger og referanser til arbeidsmateriale. En assistent som arbeider på tvers av mange brukerøkter, kan trenge et separat, redigerbart lager for preferanser.

Begynn med å definere hvilket framtidig spørsmål minnet skal kunne besvare. «Hva gjenstår?» krever at oppgavetilstanden lagres. «Hvilket format krever denne klienten?» krever en avgrenset preferanse. «Hvorfor forkastet vi denne tilnærmingen?» krever en beslutningslogg med underbyggende bevis. Ulike spørsmål krever ulike representasjonsformer.

Foretrekk et lite antall tydelige oppføringer med kjent opphav framfor et ukritisk arkiv som presenteres som personalisering. Hold nåværende status atskilt fra historiske hendelser, ta vare på lenker til kildematerialet, og bygg inn muligheter for korrigering og sletting helt fra starten.

Aktivt minne gir et AI-system et sammenhengende nåtidsperspektiv. Vedvarende minne kan gi det kontinuitet over tid. Hvor god denne kontinuiteten er, avhenger av beslutningene mellom de to: hva som lagres, hva som hentes fram igjen, hvilken versjon som gjelder, og hva som kan få forsvinne.