Aktivní vs. perzistentní paměť v AI: Jak si AI pamatuje, vyhledává a zapomíná

Aktivní paměť jsou informace, které má systém AI k dispozici pro právě řešený úkol. Perzistentní paměť tvoří informace, které okolní aplikace uchovává, aby je bylo možné použít znovu později. Vztah mezi nimi určuje, zda může asistent pokračovat v projektu, uplatnit určitou preferenci, opravit zastaralý předpoklad nebo přestat znovu vytahovat něco, na co už měl zapomenout.

Představte si asistenta, který vám pomáhá připravit výzkumnou zprávu. Během jedné konverzace se může odkazovat na osnovu, vaše nejnovější úpravy i zdroje, které jste mu právě poskytli. Pokud o týden později otevřete samostatnou konverzaci, kontinuita závisí na jiném mechanismu: zda aplikace uložila příslušné informace, dokáže je najít a znovu je předá modelu.

Proto se může zdát, že si AI jeden detail pamatuje, zatímco na jiný z téže výměny zapomněla. Vzpomínání je řetězec operací. K selhání může dojít při zachycení, uložení, vyhledání, výběru, interpretaci nebo aktualizaci informací.

Tento průvodce se řetězcem těchto operací zabývá podrobně. Širší přehled epizodické, sémantické a procedurální paměti najdete v našem úvodu do typů paměti agentů AI. Zde se zaměřujeme na hranici mezi tím, co je aktivní právě teď, a tím, co může přetrvat i po skončení aktuálního úkolu.

Co vlastně znamená aktivní a perzistentní paměť?

Tyto pojmy označují užitečné architektonické rozdíly, ale netvoří univerzálně ustálenou dvojici. Uživatelská rozhraní produktů a výzkumné práce používají pojmy „pracovní paměť“, „krátkodobá paměť“, „kontext“, „stav“ a „dlouhodobá paměť“ s překrývajícími se významy. Přesné vysvětlení proto vyžaduje, abychom si nejprve vymezili pojmy.

V tomto článku aktivní kontext označuje informace předávané modelu pro jeho aktuální odpověď: pokyny, zprávy, vybrané výstupy nástrojů, vyhledané materiály a další vstupy, které model dokáže zpracovat. Aktivní stav úkolu má širší význam. Může zahrnovat plán, kontrolní seznam nebo proměnné, které aplikace udržuje, ale ještě je nevložila do kontextu modelu. Pro tuto aktuální pracovní sadu používáme jako obecné označení pojem aktivní paměť; v případech, kdy na tom záleží, však oba pojmy rozlišujeme.

Perzistentní paměť označuje uchovávané informace, které přetrvají i po skončení odpovědi nebo relace a zůstávají dostupné pro pozdější použití. Může jít o uloženou preferenci, poznámku k projektu, záznam události, strukturované databázové pole nebo kontrolní bod, který umožňuje pokračovat v nedokončeném úkolu. Perzistence popisuje uchovávání informací; nezaručuje, že budou sdíleny napříč všemi konverzacemi.

Existují tedy dvě samostatné otázky: Jsou tyto informace stále k dispozici? a Dostane je model, až je bude potřebovat? Uložený přepis může odpovědět na první otázku, aniž by vyřešil tu druhou.

Důležitá výjimka: Krátkodobý stav lze uložit

„Krátkodobý“ neznamená vždy „uložený pouze ve volatilní paměti RAM“. Pracovní stav konverzace lze uložit do databáze jako kontrolní bod a po přerušení v něm pokračovat. Například dokumentace LangChainu k paměti rozlišuje stav vázaný na vlákno, uchovávaný prostřednictvím kontrolních bodů, a dlouhodobější paměť uspořádanou do samostatných jmenných prostorů.

Představte si pracovníka zákaznické podpory, který pozastaví práci, než mu zákazník nahraje účtenku. Uložený kontrolní bod patří k danému případu podpory. Je trvalý, ale neměl by se automaticky stát obecnou informací o zákazníkovi ani se objevovat v nesouvisejících požadavcích.

Užitečným způsobem, jak hodnotit jakoukoli funkci paměti, je položit si otázky ohledně tří aspektů: její doby uchování, jejího rozsahu a její dostupnosti pro aktuální volání modelu. Označení jako „dlouhodobá“ žádnou z těchto otázek nezodpovídá úplně.

Aktivní a perzistentní paměť v kostce

Stejný fakt se může objevit v obou sloupcích. Uložená preference projektu je trvalá; její kopie vložená do dnešního promptu je aktivní. Odstranění této kopie z promptu nemusí nutně znamenat, že se smaže i uložený originál.

Co se děje během jedné odpovědi AI?

V typické aplikaci založené na jazykovém modelu okolní software sestaví vstup, model vytvoří výstup a software rozhodne, co bude následovat. Vstup může obsahovat viditelnou konverzaci, ale také systémové pokyny, popisy nástrojů, načtené poznámky a informace, které uživatel v přepisu chatu nevidí.

Takto sestavený kontext představuje bezprostřední podklady modelu. Pokud v něm už není zahrnuta dřívější zpráva, model nedokáže spolehlivě zrekonstruovat její přesný obsah jen proto, že ji aplikace kdysi zobrazila. Na základě okolních vodítek může odvodit věrohodnou odpověď, odvozování se však liší od vzpomínání.

Nástroj rozšiřuje, k čemu má systém přístup. Model si může vyžádat soubor projektu, získat jeho obsah a použít ho v následující odpovědi. Aplikace měla soubor k dispozici ještě předtím, než se stal aktivním podkladem. Právě tento rozdíl vysvětluje, proč může mít agent přístup k rozsáhlému archivu, aniž by ho při každém kroku musel celý pročítat.

Implementace transformerů navíc interně uchovávají výpočetní stav, včetně mezipamětí, které slouží k tomu, aby se práce nemusela opakovat. Tyto mechanismy zefektivňují odvozování, nelze si je však plést s upravitelným záznamem o preferencích uživatele nebo historii projektu, který zohledňuje oprávnění. Rychlejší odpověď nedokazuje, že byla vytvořena osobní paměť.

Proč větší kontextové okno problém paměti neřeší

Větší kontextové okno umožňuje aplikaci předat najednou více materiálu. To může být užitečné, když odpověď závisí na souvislostech napříč dlouhým dokumentem nebo několika souvisejícími zdroji. Samo o sobě však nerozhodne, které informace stojí za to uchovat, která verze je směrodatná ani zda k nim uživatel smí mít přístup.

Ani umístění informací do kontextového okna nezaručuje, že je model správně využije. Studie Ztraceni uprostřed ukázala, že testované modely mohly podávat rozdílné výkony podle toho, kde se v dlouhých vstupech nacházely relevantní podklady. Tento výsledek varuje před tím, abychom účinné využití kontextu řádně nevyhodnotili a považovali inzerovanou kapacitu za záruku, že si model informace vybaví; nejde o pevnou předpověď výkonu každého novějšího modelu.

Představme si, že archiv projektu obsahuje čtyřicet diskusí o datu uvedení na trh. Ve třiceti devíti z nich se uvádí původní datum a poslední schválená změna ho posouvá. Předat všech čtyřicet diskusí představuje problém z hlediska orientace i určení toho, co je směrodatné. Pečlivě udržovaný záznam o aktuálním stavu, propojený se schválenou změnou, může usnadnit zjištění správné odpovědi.

Dlouhý kontext a selektivní vyhledávání se proto mohou vzájemně doplňovat. Vyhledávání najde užitečný soubor podkladů; dostatečně velký kontext pak modelu umožní posoudit je společně. Volba řešení závisí na úkolu, rozsahu zdrojových materiálů a důsledcích přehlédnutí nějaké výhrady.

Jak se z informací stává trvalá paměť

Základem trvalé paměti je rozhodnutí, co uložit. Aplikace může uložit výslovný pokyn uživatele, odvodit možný fakt z konverzace, uchovat událost nebo vytvořit shrnutí. Každý z těchto postupů vytváří jiný druh podkladu.

„U projektu Cedar používej metrické jednotky“ je výslovně uvedená preference projektu. „Zdá se, že uživatel dává přednost metrickým jednotkám“ je odvozený závěr. „V posledních třech zprávách o projektu Cedar byly použity metrické jednotky“ je pozorování. Užitečný záznam tyto rozdíly zachovává, místo aby je sloučil do nekvalifikovaného tvrzení o všech budoucích úkolech.

Co obsahuje užitečný záznam

Záznam pro hypotetického projektového asistenta by mohl obsahovat tvrzení, identifikátor projektu, uživatele nebo organizaci, ke které patří, zdrojovou interakci, časové razítko, stav platnosti a případné výjimky. Díky těmto údajům lze zjistit, odkud informace pochází a zda je stále platná.

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

Jde o ilustrativní schéma, nikoli o univerzální standard. Jeho účelem je ukázat, proč by paměť měla obsahovat víc než jen jednu větu. Odkaz na zdroj usnadňuje ověření, vymezení rozsahu brání přílišnému zobecňování a pole se stavem umožňuje provádět opravy.

Okamžitý zápis versus zpracování na pozadí

Díky okamžitému zápisu může být výslovná oprava k dispozici už při následujícím požadavku. Zpracování na pozadí může vyhodnotit dokončenou interakci, sloučit duplicitní záznamy nebo vytvořit promyšlenější shrnutí. Dokumentace LangChain popisuje oba přístupy i jejich kompromisy, včetně dodatečné práce, kterou okamžitý zápis přináší do procesu generování odpovědi.

Praktické řešení může ihned uložit potvrzenou preferenci a dlouhou výzkumnou relaci zpracovat později. Musí však zvládnout i dobu mezi těmito kroky. Pokud systém uživateli oznámí, že preferenci uložil, ještě než se zápis úspěšně dokončí, může se při příští konverzaci projevit narušení návaznosti.

Zápisy do paměti také vyžadují postup pro případ selhání. Pokud je úložiště dočasně nedostupné, aplikace může oznámit, že se uložení nedokončilo, nebo ponechat operaci ve frontě a zřetelně ji označit jako čekající. Považovat pokus o zápis za úspěšně uloženou vzpomínku vede k zavádějící uživatelské zkušenosti.

Jak se trvalá paměť vrací do aktivního kontextu

Načítání zahrnuje posloupnost rozhodnutí o tom, zda lze záznamy použít, zda jsou relevantní a jaké důkazy poskytují. Systém musí nejprve určit uživatele, tenanta, projekt nebo úlohu, jejichž záznamy smí prohledávat. Poté najde možné záznamy a vybere, které z nich zahrne do kontextu odpovědi.

Způsob načítání by měl odpovídat otázce. Na otázku „Jaký je schválený termín projektu Cedar?“ může nejlépe odpovědět přesné vyhledání pole projektu. U otázky „Setkali jsme se už s touto chybou nasazení?“ může pomoci vyhledávání podle klíčových slov a sémantické porovnání s dřívějšími incidenty. Vektorová databáze je jednou z možností, jak tento proces řešit, nikoli požadavkem pro každou paměť.

Sémantické vyhledávání je zvlášť užitečné, když se změní formulace. Dotaz na „stručné zprávy“ může odpovídat uložené preferenci „krátkých shrnutí pro vedení“. Související tvrzení se však může týkat jiného klienta nebo opuštěné verze projektu. Podobnost pomáhá najít možné záznamy, ale nedokazuje jejich pravdivost ani oprávněnost jejich použití.

Vyhledávání musí umožňovat i výsledek „nenalezeno“

Představte si otázku: „Jaký limit výdajů jsem schválil minulý měsíc?“ Pokud se nepodaří najít žádnou schválenou částku, užitečná odpověď označí chybějící důkaz a požádá o upřesnění. Uvedení věrohodně vypadajícího čísla by proměnilo chybějící vzpomínku ve smyšlené schválení.

Rozhraní paměti by proto mělo rozlišovat potvrzenou shodu, nejistou shodu, rozpor a případ, kdy záznam nic nepodporuje. Každý z těchto výsledků může vést k jinému postupu: odpovědět přímo, odpověď formulovat s výhradou, požádat o upřesnění nebo odmítnout jednat na základě nepodloženého předpokladu.

I po vyhledání záleží na správné interpretaci. Záznam „navržený maximální rozpočet: 5 000 $, čeká se na schválení“ se nesmí změnit na „schválený rozpočet: 5 000 $“. Zachovat upřesňující údaje v uloženém záznamu i v poskytnutém kontextu je stejně důležité jako najít správný dokument.

Praktický příklad: jak si pamatovat projekt v průběhu času

Představme si asistenta, který týmu pomáhá připravit výzkumnou zprávu Cedar. Následující příklad je hypotetický, ale ukazuje několik běžných rozhodnutí při návrhu paměti.

První sezení: vymezení projektu

Uživatel požádá o zprávu, určí metrické jednotky, poskytne tři zdroje a řekne, že návrh má být hotový v pátek. Aktivní kontext zahrnuje tyto pokyny i úryvky ze zdrojů. Aktivní stav úkolu zaznamenává, které části jsou hotové a která tvrzení je ještě třeba ověřit.

Různé záznamy určené k trvalému uchování mohou mít odlišný účel. Preference metrických jednotek se vztahuje k projektu. Termín odevzdání návrhu se váže k aktuálnímu milníku. Poskytnuté zdroje patří do archivu podkladů k projektu. Neověřená tvrzení patří na seznam bodů, které je třeba dále prozkoumat, a jejich nejistota musí zůstat zachována.

Druhé sezení: pokračování se správnými podklady

O tři dny později uživatel požádá o dokončení metodické části. Asistent potřebuje nejnovější osnovu, relevantní zdroje, aktuální stav úkolu a platné pravidlo formátování. Nemusí však potřebovat každou vyřazenou větu z předchozího brainstormingu.

Pokud kontrolní záznam uvádí, že rešerše literatury je hotová, asistent by si měl před úpravami navazujících částí přesto otevřít uložený soubor. „Hotovo“ je tvrzení o průběhu; skutečný dokument dokládá, co bylo dokončeno. Trvalé odkazy na soubory mohou být užitečnější než souhrn, který se snaží reprodukovat celý jejich obsah.

Třetí sezení: uplatnění výjimky bez přepisování všeho

Uživatel požádá o verzi pro klienta, která bude obsahovat metrické i imperiální jednotky. V aktuálním úkolu je tedy třeba použít obě soustavy. Zda se změní obecné pravidlo pro projekt, závisí na formulaci uživatelova požadavku a jeho rozsahu: „pro tuto verzi“ je užší než „odteď používej obě soustavy“.

Pečlivý asistent zaznamená výjimku platnou pouze pro konkrétní verzi. Asistent, který příliš zobecňuje, přepíše obecnou preferenci a zanese chyby do pozdějších zpráv. Jde o selhání paměti, i když všechny zápisy do databáze i požadavky na vyhledávání proběhnou úspěšně.

Čtvrté sezení: dokončení a odstranění dočasných údajů

Po odevzdání by měl být milník označen jako dokončený. Na pokyn „pokračuj ve zprávě“ by měl asistent navázat na odevzdanou verzi a zeptat se, jaké úpravy jsou potřeba, nikoli pokračovat podle zastaralého kontrolního seznamu. Dočasné pracovní poznámky mohou podle pravidel projektu po určité době vypršet, zatímco závěrečná zpráva a důležitá rozhodnutí zůstanou dostupné.

Přínos trvalé paměti je zde zřejmý: méně opakovaného vysvětlování a lepší návaznost. Zřejmá je i její cena: aplikace musí udržovat vztahy mezi preferencemi, výjimkami, soubory a proměnlivým stavem úkolu.

Shrnování, zhušťování a riziko ztráty výjimky

V dlouhých interakcích se může nahromadit více materiálu, než je užitečné pro další odpověď. Při zhuštění se část této historie nahradí stručnějším záznamem. Souhrn může zachovat cíl, rozhodnutí, nevyřešené otázky a odkazy na původní podklady.

Doporučení společnosti Anthropic k práci s kontextem popisují zhušťování a poznámky uložené mimo kontextové okno jako způsoby, jak zachovat návaznost při dlouhodobé práci. Obě techniky mění materiály dostupné pro budoucí odpovědi, takže záleží na jejich kvalitě.

Při zhušťování se vybírá, co zachovat. Souhrn typu „Používej metrické jednotky“ je kratší než „Používej metrické jednotky, s výjimkou verze pro klienta, která musí obsahovat obě soustavy“. V jednom z důležitých případů projektu je však také nesprávný. Ztracená výjimka se může nenápadně přenášet do dalších souhrnů a být stále obtížnější dohledat.

Lepší předání pro našeho asistenta Cedar by zachovalo obecné pravidlo, jeho výjimku, dokončené části, zbývající úkoly k ověření a odkazy na nejnovější soubory. Přesné údaje, například schválené částky nebo identifikátory, by měly zůstat ve strukturovaných záznamech nebo zdrojových dokumentech, pokud by jejich přibližné uvedení mohlo způsobit škodu.

Souhrny by měly zachovat také nejistotu. „Uvažovali jsme o použití průzkumu B“ se nesmí změnit na „Byl vybrán průzkum B“. Pokud zhuštěná historie vydává předběžná rozhodnutí za konečná, systém při snaze ušetřit místo v kontextu vytvořil falešnou vzpomínku.

Jak by měla paměť AI pracovat s opravami a rozpory

Trvalá paměť je méně užitečná, pokud ji nelze měnit. Projekty se vyvíjejí, preference se mění a ukazuje se, že dřívější informace byly chybné. Pokud se oprava přidá jako další záznam bez dalšího upřesnění, systém pro vyhledávání může vybírat mezi dvěma protichůdnými tvrzeními.

Užitečnější aktualizace určuje, co nové důkazy nahrazují. Pokud vlastník projektu posune datum spuštění z 15. listopadu na 29. listopadu, lze starý záznam označit jako nahrazený a propojit ho s novým rozhodnutím. Při dotazech na aktuální termín se použije nová verze; při dotazech na původní plán lze nahlédnout do historické verze.

Samotná aktuálnost nevyřeší každý rozpor. Nedávná poznámka v návrhu může mít menší váhu než starší schválená směrnice. Uživatel může mít oprávnění změnit osobní preferenci, ale nemusí mít oprávnění měnit pravidlo platné pro celou organizaci. Pravidla pro aktualizace musí zohledňovat typ informace i autoritu jejího zdroje.

Některé rozpory by měly zůstat nevyřešené, dokud je někdo neobjasní. Pokud dva vlastníci projektu uvedou neslučitelná data a žádné z nich výslovně nenahrazuje to druhé, asistent může zobrazit oba zdroje a zeptat se, který údaj platí. Když systém bez upozornění vybere záznam, který se nejvíce podobá ostatním nebo je nejnovější, skrývá tím rozhodnutí, k němuž nemusí mít oprávnění.

Co znamená, když AI zapomene?

Zapomínání není jediný přepínač. Produkt může přestat vkládat určitou informaci do promptů, vyloučit ji z běžného vyhledávání, označit ji za zastaralou, smazat její záznam v paměti nebo odstranit další uchované kopie. Tyto operace mají různé dopady na budoucí chování i na uchovávaná data.

Mimo aktivní kontext

Informace může zmizet z dalšího vstupu modelu, protože starší zprávy byly vynechány nebo shrnuty. Tím se omezuje, co může model bezprostředně použít. Původní přepis konverzace nebo záznam v paměti však může stále existovat a později se znovu objevit při vyhledávání.

Vypršení platnosti nebo potlačení vyhledávání

Prošlý termín může zůstat v archivu, a přitom být vyloučen z dotazů týkajících se aktuální práce. Potlačení vyhledávání je užitečné, pokud má uchovávání historických údajů svůj účel, nemělo by se však popisovat jako úplné smazání. Záznam může být stále dostupný při historickém vyhledávání nebo v rámci administrativního postupu.

Smazání uložené paměti

Při mazání trvalého záznamu je třeba řešit i reprezentace používané při vyhledávání, které z něj byly odvozeny. Pokud se věta odstraní z profilu, ale zůstane v prohledávatelném souhrnu, asistent může později tutéž preferenci znovu odvodit. V závislosti na architektuře může být nutné samostatně odstranit zdrojové záznamy, vektorové reprezentace, souhrny, mezipaměti i repliky.

Pro zálohy a protokoly mohou platit vlastní lhůty uchovávání. Produkt by měl tyto hranice jasně vysvětlit a zabránit tomu, aby se smazaný materiál znovu aktivoval při obnovení dat. „Tuto paměť už nebudeme používat“ a „všechny uchované kopie byly odstraněny“ jsou dva odlišné sliby.

Změna parametrů modelu

Smazání externí paměti samo o sobě parametry modelu nemění. Pokud byly informace použity při trénování, jejich odstranění z modelu představuje samostatný problém, který se týká procesu trénování a nasazení. Smazání osobní vzpomínky zároveň nemůže zaručit, že model nikdy nevygeneruje podobnou informaci na základě obecných znalostí nebo vodítek uvedených v novém promptu.

Smysluplný test zapomínání proto ověřuje jak to, zda systém danou informaci stále uchovává, tak to, zda ji lze znovu zpřístupnit běžnými cestami vyhledávání. Jediná odpověď v chatu „Zapomněl jsem“ nedokazuje ani jedno.

Paměť, RAG, trénování a ukládání do mezipaměti: kde leží hranice

Generování rozšířené o vyhledávání neboli RAG poskytuje modelu během generování externí podklady. Původní výzkum RAG spojil parametry modelu s prohledávatelným rejstříkem dokumentů. Osobní paměťový systém může také využívat vyhledávání, potřebuje však rovněž pravidla pro vytváření, aktualizaci a vyřazování záznamů z interakcí.

Firemní příručku lze vyhledat, aniž by šlo o vzpomínku na uživatele. Záznam o předchozí interakci lze zase najít v obyčejném souboru bez vektorového indexu. Vyhledávání je mechanismus; o tom, jaký systém se vytváří, rozhoduje účel a životní cyklus podkladových záznamů.

Trénování a dolaďování mění parametry modelu. Běžná externí paměť naproti tomu mění podklady, které model dostává. Asistent, který se řídí nově uloženou preferencí, se může chovat jinak, přestože váhy jeho modelu zůstávají beze změny.

Ukládání promptů a inferencí do mezipaměti umožňuje tam, kde je to podporováno, znovu využít předchozí výpočty. Může zvýšit efektivitu, samo o sobě však neurčuje, zda je zapamatované tvrzení aktuální, oprávněné nebo vhodné pro budoucí úkoly. Tyto vrstvy mohou fungovat současně a při řešení problémů je třeba zjistit, která z nich odpovídá za pozorované chování.

MemGPT představuje vlivný příklad architektury: zkoumá přesouvání informací mezi omezeným kontextem a externími vrstvami paměti na základě analogie s operačním systémem. Užitečným ponaučením je, že přesun informací je třeba výslovně spravovat, nikoli předpokládat, že samotné úložiště bez omezení rozšíří bezprostřední kontext modelu.

Proč může trvalá paměť způsobit, že chyby přetrvávají déle

Chybná odpověď může ovlivnit jednu interakci. Chybná vzpomínka jich může ovlivnit mnoho. Pokud asistent usoudí, že uživatel schválil nějaké rozhodnutí, uloží tento závěr jako fakt a později se na uložený záznam odvolá, může jeho vlastní dřívější chyba působit jako nezávislý důkaz.

U našeho projektového asistenta by měl původní zdroj zůstat odlišitelný od interpretace modelu. Shrnutí rozhodnutí může usnadnit orientaci, při každém kroku s významnými důsledky by však mělo sloužit jako podklad samotné schválené rozhodnutí. Opakováním v několika vygenerovaných poznámkách se nepodložený závěr nestane několika nezávislými potvrzeními.

Trvalá paměť zároveň vytváří cestu ke kontaminaci instrukcí. Nedůvěryhodný dokument může obsahovat větu, která asistentovi přikazuje změnit jeho budoucí chování. Uložením této věty jako provozního pravidla by se externí obsah dostal přes hranici důvěryhodnosti. Aplikace by s ním měla nakládat podle jeho zdroje, nikoli z něj udělat důvěryhodnou instrukci jen proto, že se objevil v úložišti paměti.

Sdílená prostředí přidávají další hranici. Nějaký fakt může být pro otázku relevantní, ale může se týkat jiného zákazníka nebo projektu. Kontrola přístupu by měla omezovat vyhledávání ještě předtím, než se informace dostane k modelu. Požádat model, aby ignoroval neoprávněné záznamy, které mu už byly poskytnuty, je méně spolehlivé řešení.

Jak vyhodnotit, zda paměť skutečně funguje

Přesvědčivá ukázka často spočívá v tom, že asistent zopakuje jednu uloženou preferenci. Důkladné vyhodnocení sleduje, jak si paměť poradí s měnícími se informacemi napříč několika relacemi, a ověřuje, zda zlepšuje výsledek dokončeného úkolu.

LongMemEval hodnotí získávání informací, uvažování napříč relacemi, časové uvažování, aktualizaci znalostí a zdržení se odpovědi. Tyto kategorie ukazují, proč kvalita dlouhodobé paměti přesahuje pouhé vyhledání jediné odpovídající věty. Zveřejněné výsledky benchmarků je třeba vztahovat na testované systémy a nastavení, nikoli předpokládat, že popisují každý současný produkt.

V rámci pracovního postupu Cedar by vyhodnocení mohlo zahrnovat zadání preference, pokračování v projektu, přidání výjimky, změnu termínu, smazání poznámky a následné položení otázek, které odhalí zastaralé nebo nepodložené vzpomínky. Stejný model by se měl otestovat také bez funkce paměti, aby bylo možné ověřit, zda přidaný systém zlepšuje výsledky.

• Přesnost zápisu: Uložil systém zamýšlené tvrzení včetně jeho rozsahu platnosti a upřesňujících podmínek?
• Užitečnost vyhledávání: Našel systém podklady potřebné pro daný úkol, aniž by zahltil kontext nesouvisející historií?
• Zpracování aktualizací: Nahradila oprava aktuální údaj a zároveň zachovala užitečné historické souvislosti?
• Zdržení se odpovědi: Přiznal asistent, že neexistuje žádný záznam, který by odpověď podpořil?
• Oddělení: Zůstaly záznamy přístupné pouze správnému uživateli, tenantovi a projektu?
• Zapomínání: Zabránilo smazání nebo vypršení platnosti zamýšlenému budoucímu vybavení informace, a to i prostřednictvím odvozených shrnutí?
• Provozní náklady: Odpovídalo zlepšení vyšší latenci, většímu počtu volání modelu, úložišti a nákladům na údržbu?

Selhání je třeba dohledat v konkrétní fázi. Chybějící odpověď může být důsledkem neúspěšného zápisu, nesprávně vymezeného rozsahu vyhledávání, chybného rozhodnutí při řazení výsledků, vynechané výhrady nebo toho, že model nesprávně vyhodnotil kvalitní důkazy. Zvětšení kontextového okna nevyřeší všechny tyto problémy.

Jak zvolit správný návrh paměti

Jednorázové shrnutí dokumentu může vyžadovat pouze aktuální dokument a pokyny. Přerušené analýze pomůže kontrolní bod úkolu. Asistent pro opakovaně řešený projekt může potřebovat verzovaná rozhodnutí a odkazy na artefakty. Asistent pracující napříč mnoha uživatelskými relacemi může potřebovat samostatné, upravitelné úložiště preferencí.

Nejprve určete, na jakou budoucí otázku má paměť odpovídat. Otázka „Co ještě zbývá dokončit?“ vyžaduje uchování stavu úkolu. Otázka „Jaký formát tento klient vyžaduje?“ vyžaduje preferenci vymezenou pro konkrétní kontext. Otázka „Proč jsme tento postup odmítli?“ vyžaduje záznam rozhodnutí s podpůrnými důkazy. Různé otázky si žádají různé způsoby zaznamenání.

Dejte přednost menšímu počtu jasných, přiřaditelných záznamů před bezhlavým archivem vydávaným za personalizaci. Oddělte aktuální stav od historických událostí, zachovávejte odkazy na zdrojové artefakty a od začátku počítejte s možností oprav i mazání.

Aktivní paměť dává systému umělé inteligence ucelený obraz současnosti. Trvalá paměť mu může zajistit kontinuitu v čase. Kvalita této kontinuity závisí na rozhodnutích, která určují, co se mezi oběma paměťmi děje: co se ukládá, co se znovu načítá, která verze má přednost a co může být zapomenuto.