Memoria activă și memoria persistentă în IA: cum își amintește, regăsește și uită IA

Memoria activă cuprinde informațiile de care dispune un sistem de IA pentru sarcina pe care o îndeplinește în acel moment. Memoria persistentă cuprinde informațiile pe care aplicația asociată le păstrează pentru a putea fi folosite din nou ulterior. Relația dintre ele determină dacă un asistent poate continua un proiect, poate aplica o preferință, poate corecta o presupunere depășită sau poate înceta să readucă în discuție ceva ce ar fi trebuit să uite.

Să luăm exemplul unui asistent care te ajută să pregătești un raport de cercetare. În timpul unei conversații, acesta se poate raporta la schiță, la cele mai recente modificări făcute de tine și la sursele pe care tocmai i le-ai furnizat. Dacă deschizi o conversație separată o săptămână mai târziu, continuitatea depinde de un alt mecanism: dacă aplicația a salvat informațiile relevante, le poate găsi și le furnizează din nou modelului.

De aceea, o IA poate părea că își amintește un detaliu, dar îl uită pe altul din aceeași conversație. Reamintirea presupune un lanț de operațiuni. O eroare poate apărea la captarea, stocarea, căutarea, selectarea, interpretarea sau actualizarea informațiilor.

Acest ghid analizează în detaliu acest lanț. Pentru o clasificare mai amplă a memoriei episodice, semantice și procedurale, consultă introducerea noastră în tipurile de memorie ale agenților IA. Aici ne concentrăm asupra graniței dintre ceea ce este activ în prezent și ceea ce poate persista dincolo de sarcina curentă.

Ce înseamnă, de fapt, memoria activă și memoria persistentă?

Acești termeni descriu distincții arhitecturale utile, dar nu formează o pereche standardizată universal. Interfețele produselor și lucrările de cercetare folosesc termeni precum „memorie de lucru”, „memorie pe termen scurt”, „context”, „stare” și „memorie pe termen lung” cu sensuri care se suprapun. Prin urmare, o explicație precisă trebuie să definească termenii folosiți.

În acest articol, contextul activ desemnează informațiile furnizate modelului pentru răspunsul curent: instrucțiuni, mesaje, rezultate selectate ale instrumentelor, materiale regăsite și alte date de intrare pe care modelul le poate procesa. Starea activă a sarcinii are un sens mai larg. Poate include un plan, o listă de verificare sau variabile pe care aplicația le păstrează, dar pe care nu le-a introdus încă în contextul modelului. Folosim termenul „memorie activă” ca noțiune generală practică pentru acest set de lucru curent, distingând între cele două atunci când este necesar.

Memoria persistentă desemnează informațiile păstrate care supraviețuiesc încheierii unui răspuns sau a unei sesiuni și rămân disponibile pentru utilizare ulterioară. Acestea pot fi o preferință salvată, o notă despre un proiect, o înregistrare a unui eveniment, un câmp structurat dintr-o bază de date sau un punct de control care permite reluarea unei sarcini neterminate. Persistența descrie păstrarea informațiilor; nu garantează că acestea vor fi partajate în fiecare conversație.

Prin urmare, există două întrebări distincte: Informația încă există? și Va primi modelul informația atunci când va avea nevoie de ea? O transcriere salvată poate răspunde la prima întrebare fără să o rezolve și pe a doua.

Excepția importantă: starea pe termen scurt poate fi salvată

„Pe termen scurt” nu înseamnă întotdeauna „stocată doar în memoria RAM volatilă”. Starea de lucru a unei conversații poate fi salvată ca punct de control într-o bază de date și reluată după o întrerupere. De exemplu, documentația despre memorie a LangChain face distincția între starea asociată unui fir de conversație, păstrată prin puncte de control, și memoria pe termen lung, organizată în spații de nume separate.

Imaginează-ți un agent de asistență care se oprește în timp ce așteaptă ca un client să încarce o chitanță. Punctul de control salvat aparține acelui caz de asistență. Punctul de control este durabil, dar nu ar trebui să devină automat o informație generală despre client și nici să apară în solicitări fără legătură cu acel caz.

O modalitate utilă de a evalua orice funcție de memorie este să iei în considerare trei dimensiuni: durata de păstrare, domeniul de aplicare și disponibilitatea pentru apelul curent al modelului. O etichetă precum „pe termen lung” nu răspunde pe deplin la niciuna dintre aceste întrebări.

Memoria activă și memoria persistentă, pe scurt

Același fapt poate apărea în ambele coloane. O preferință salvată pentru un proiect este persistentă; copia inserată în promptul de astăzi este activă. Eliminarea acelei copii din prompt nu înseamnă neapărat că originalul salvat este șters.

Ce se întâmplă în timpul unui singur răspuns al IA?

Într-o aplicație obișnuită bazată pe un model lingvistic, software-ul care îl înconjoară asamblează o intrare, modelul generează un rezultat, iar software-ul decide ce urmează. Intrarea poate conține conversația vizibilă, dar poate include și instrucțiuni de sistem, descrieri ale instrumentelor, note regăsite și informații pe care utilizatorul nu le vede în transcrierea chatului.

Acest context asamblat reprezintă dovezile imediate de care dispune modelul. Dacă un mesaj anterior nu mai este inclus, modelul nu îi poate recupera în mod fiabil conținutul exact doar pentru că aplicația l-a afișat cândva. Ar putea deduce un răspuns plauzibil din indiciile din jur, dar deducția este diferită de reamintire.

Un instrument extinde ceea ce poate accesa sistemul. Modelul ar putea solicita un fișier de proiect, ar putea primi conținutul acestuia și l-ar putea folosi într-un răspuns ulterior. Fișierul era disponibil aplicației înainte de a deveni o dovadă activă. Această distincție explică de ce un agent poate avea acces la o arhivă mare fără să o citească în întregime la fiecare tură.

La nivel intern, implementările de tip transformer mențin și o stare computațională, inclusiv memorii cache folosite pentru a evita repetarea operațiilor. Aceste mecanisme sunt utile pentru inferențe eficiente, dar nu trebuie confundate cu o evidență editabilă, care ține cont de permisiuni, a preferințelor utilizatorului sau a istoricului proiectului. Un răspuns mai rapid nu demonstrează că a fost creată o memorie personală.

De ce o fereastră de context mai mare nu rezolvă problema memoriei

O fereastră de context mai mare permite unei aplicații să furnizeze mai mult material dintr-o dată. Acest lucru poate fi valoros atunci când răspunsul depinde de relațiile dintre elemente dintr-un document lung sau din mai multe surse conexe. Totuși, nu stabilește ce material merită păstrat, care versiune este cea oficială sau dacă un utilizator îl poate accesa.

Nici includerea informațiilor într-o fereastră de context nu garantează că modelul le va folosi corect. Studiul Lost in the Middle a arătat că modelele testate puteau avea performanțe diferite în funcție de locul în care apăreau dovezile relevante în intrările lungi. Rezultatul avertizează asupra necesității de a evalua folosirea efectivă a contextului, în loc să considerăm capacitatea declarată o garanție a reamintirii; nu este o predicție fixă a performanței pentru fiecare model mai nou.

Să presupunem că arhiva unui proiect conține patruzeci de discuții despre data lansării. În treizeci și nouă dintre ele este menționată data inițială, iar ultima modificare aprobată o schimbă. Furnizarea tuturor celor patruzeci de discuții creează o problemă de lectură și de stabilire a sursei cu autoritate. O evidență actualizată cu grijă, care indică starea curentă și trimite la modificarea aprobată, poate facilita stabilirea răspunsului relevant.

Prin urmare, contextul lung și regăsirea selectivă se pot completa reciproc. Regăsirea identifică un set util de dovezi; un context suficient de mare permite modelului să le examineze împreună. Alegerea de proiectare depinde de sarcină, de volumul materialului-sursă și de consecințele omiterii unei precizări.

Cum devin informațiile o memorie persistentă

Crearea unei memorii durabile începe cu decizia de a salva informații. O aplicație poate salva o instrucțiune explicită a utilizatorului, poate deduce un fapt candidat dintr-o conversație, poate păstra un eveniment sau poate crea un rezumat. Fiecare dintre aceste căi produce un tip diferit de dovezi.

„Pentru Proiectul Cedar, folosește unități metrice” este o preferință explicită pentru proiect. „Utilizatorul pare să prefere unitățile metrice” este o deducție. „Ultimele trei rapoarte Cedar au folosit unități metrice” este o observație. O evidență utilă păstrează aceste diferențe, în loc să le reducă la o afirmație fără rezerve despre orice sarcină viitoare.

Ce conține o evidență utilă

Pentru un asistent ipotetic de proiect, o înregistrare ar putea include afirmația, identificatorul proiectului, utilizatorul sau organizația căreia îi aparține, interacțiunea din care provine, un marcaj temporal, un statut de valabilitate și orice excepție. Aceste câmpuri permit să aflăm de unde provine informația și dacă mai este valabilă.

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

Aceasta este o schemă ilustrativă, nu un standard universal. Scopul ei este să arate de ce o memorie trebuie să conțină mai mult decât o propoziție. O referință la sursă ajută la verificare; domeniul de aplicare împiedică generalizarea excesivă; un câmp de stare permite corectarea.

Scrierea imediată și procesarea în fundal

O scriere imediată poate face ca o corecție explicită să fie disponibilă chiar la următoarea solicitare. Procesarea în fundal poate analiza o interacțiune încheiată, poate combina înregistrările duplicate sau poate genera un rezumat mai bine cântărit. Documentația LangChain descrie ambele abordări și compromisurile aferente, inclusiv munca suplimentară introdusă în fluxul de răspuns imediat.

Un sistem bine conceput ar putea salva imediat o preferință confirmată și procesa ulterior o sesiune lungă de cercetare. Totuși, trebuie să gestioneze intervalul dintre acești pași. Dacă sistemul îi spune utilizatorului că a salvat o preferință înainte ca scrierea să reușească, conversația următoare poate scoate la iveală o întrerupere a continuității.

Scrierile în memorie au nevoie și de o strategie pentru situațiile de eșec. Dacă spațiul de stocare este temporar indisponibil, aplicația poate raporta că salvarea nu s-a încheiat sau poate păstra o operațiune în așteptare, marcată clar ca atare. Tratarea unei încercări de scriere ca pe o salvare reușită creează o experiență înșelătoare pentru utilizator.

Cum revine memoria persistentă în contextul activ

Recuperarea informațiilor presupune o serie de decizii privind eligibilitatea, relevanța și dovezile disponibile. Mai întâi, sistemul trebuie să identifice utilizatorul, clientul, proiectul sau sarcina ale căror înregistrări le poate consulta. Apoi găsește înregistrările candidate și selectează ce să includă în contextul răspunsului.

Metoda de recuperare ar trebui aleasă în funcție de întrebare. La întrebarea „Care este termenul-limită aprobat pentru Cedar?” se poate răspunde cel mai bine prin consultarea exactă a unui câmp al proiectului. Întrebarea „Am mai întâlnit această eroare de implementare?” poate beneficia de o căutare după cuvinte-cheie și de compararea semantică a incidentelor anterioare. O bază de date vectorială este o opțiune în cadrul acestui proces, nu o cerință pentru orice tip de memorie.

Căutarea semantică este deosebit de utilă atunci când formularea se schimbă. O căutare despre „menținerea conciziei rapoartelor” ar putea găsi o preferință salvată pentru „rezumate executive scurte”. Totuși, o afirmație similară poate privi un alt client sau o versiune abandonată a proiectului. Similaritatea identifică înregistrări candidate; nu dovedește că sunt adevărate și nici că există permisiunea de a le folosi.

Recuperarea informațiilor trebuie să prevadă un rezultat de tipul „Nu s-a găsit”

Să luăm întrebarea: „Ce limită de cheltuieli am aprobat luna trecută?” Dacă nu se găsește nicio sumă aprobată, un răspuns util precizează că lipsesc dovezile și cere lămuriri. Furnizarea unei cifre plauzibile transformă absența unei amintiri într-o autorizare inventată.

Prin urmare, interfața memoriei ar trebui să distingă între o potrivire confirmată, una incertă, un conflict și absența unei înregistrări care să susțină informația. Aceste rezultate pot duce la comportamente diferite: să răspundă direct, să formuleze răspunsul cu rezerve, să solicite clarificări sau să refuze să acționeze pe baza unei presupuneri nesusținute.

După recuperarea informației, interpretarea rămâne importantă. O înregistrare care spune „buget maxim propus: 5.000 USD, în așteptarea aprobării” nu trebuie transformată în „buget aprobat: 5.000 USD”. Păstrarea calificărilor în reprezentarea stocată și în contextul furnizat este la fel de importantă ca găsirea documentului corect.

Un exemplu practic: cum păstrăm memoria unui proiect în timp

Imaginați-vă un asistent care ajută o echipă să redacteze raportul de cercetare Cedar. Exemplul următor este ipotetic, dar scoate în evidență câteva opțiuni obișnuite de proiectare a memoriei.

Sesiunea unu: stabilirea proiectului

Utilizatorul solicită un raport, specifică folosirea unităților metrice, furnizează trei surse și spune că proiectul de raport trebuie predat vineri. Contextul activ include instrucțiunile și fragmentele din surse. Starea activă a sarcinii consemnează ce secțiuni au fost finalizate și ce afirmații mai trebuie verificate.

Înregistrările persistente potențiale au scopuri diferite. Preferința pentru sistemul metric ține de proiect. Termenul de predare a proiectului de raport ține de etapa curentă. Sursele furnizate aparțin arhivei de documentare a proiectului. Afirmațiile neverificate aparțin unei liste de cercetări în așteptare, iar incertitudinea lor trebuie păstrată.

Sesiunea doi: reluarea lucrului pe baza dovezilor potrivite

Trei zile mai târziu, utilizatorul cere finalizarea secțiunii de metodologie. Asistentul are nevoie de cea mai recentă structură, de sursele relevante, de stadiul actual al sarcinii și de regula de formatare aplicabilă. Nu are neapărat nevoie de fiecare propoziție eliminată din sesiunea anterioară de brainstorming.

Dacă punctul de verificare indică faptul că analiza literaturii este completă, asistentul ar trebui totuși să deschidă documentul salvat înainte de a face modificări în jurul lui. „Finalizat” este o afirmație despre progres; documentul propriu-zis este dovada a ceea ce a fost finalizat. Referințele persistente la documente pot fi mai utile decât un rezumat care încearcă să le reproducă integral conținutul.

Sesiunea trei: aplicarea unei excepții fără rescrierea întregului set de reguli

Utilizatorul solicită o ediție pentru client, cu unități atât metrice, cât și imperiale. Sarcina curentă ar trebui să folosească ambele sisteme de unități. Modificarea regulii generale a proiectului depinde de formularea utilizatorului și de domeniul ei de aplicare: „pentru această ediție” are un domeniu mai restrâns decât „de acum înainte, folosește-le pe amândouă”.

Un asistent atent înregistrează o excepție specifică ediției. Un asistent care generalizează excesiv rescrie preferința globală și introduce erori în rapoartele ulterioare. Este vorba despre o defecțiune a memoriei chiar dacă toate operațiunile de scriere în baza de date și toate solicitările de recuperare a informațiilor reușesc.

Sesiunea patru: finalizarea lucrului și eliminarea stării temporare

După livrare, etapa ar trebui marcată ca finalizată. O instrucțiune de tipul „continuă raportul” ar trebui să-l îndrume pe asistent către versiunea livrată și să-l determine să întrebe ce revizuiri sunt necesare, în loc să reia o listă de verificare învechită. Notițele de lucru temporare pot expira conform politicii proiectului, în timp ce raportul final și deciziile importante rămân disponibile.

Aici se vede avantajul memoriei persistente: explicații repetate mai puține și o continuitate mai bună. Se vede și costul ei: aplicația trebuie să mențină relațiile dintre preferințe, excepții, documente și stadiul în schimbare al sarcinilor.

Rezumarea, compactarea și riscul de a pierde excepția

În interacțiunile îndelungate se poate acumula mai mult material decât este util pentru următorul răspuns. Compactarea înlocuiește o parte din istoricul respectiv cu o reprezentare mai succintă. Un rezumat poate păstra obiectivul, deciziile, întrebările nerezolvate și referințele la lucrările de bază.

Îndrumările Anthropic privind ingineria contextului descriu compactarea și notițele stocate în afara ferestrei de context drept metode de menținere a continuității în cadrul unor activități îndelungate. Ambele tehnici modifică materialul disponibil pentru răspunsurile viitoare, așa că este important să fie aplicate corect.

Comprimarea este selectivă. Un rezumat precum „Folosește unități metrice” este mai scurt decât „Folosește unități metrice, cu excepția ediției pentru client, care impune folosirea ambelor sisteme”. Este însă greșit într-unul dintre cazurile importante ale proiectului. Excepția omisă se poate perpetua pe nesimțite în rezumatele ulterioare și poate deveni greu de identificat.

Pentru asistentul nostru Cedar, o predare mai eficientă ar păstra regula generală și excepția de la aceasta, secțiunile finalizate, sarcinile de verificare rămase și referințele la cele mai recente fișiere. Detaliile exacte, precum sumele aprobate sau identificatorii, ar trebui să rămână în înregistrări structurate sau în documentele-sursă atunci când aproximarea ar putea avea consecințe negative.

Rezumatele ar trebui să păstreze și incertitudinea. „Am luat în considerare utilizarea Survey B” nu trebuie să devină „Am selectat Survey B”. Dacă istoricul comprimat face ca deciziile provizorii să pară definitive, sistemul a creat o amintire falsă în încercarea de a economisi spațiu în context.

Cum ar trebui memoria AI să gestioneze corecturile și conflictele

Memoria persistentă devine mai puțin utilă dacă nu poate fi modificată. Proiectele evoluează, preferințele se schimbă, iar unele informații anterioare se dovedesc greșite. Dacă o corectare este adăugată ca încă o înregistrare fără nicio calificare, sistemul de regăsire poate ajunge să aleagă între două afirmații contradictorii.

O actualizare mai utilă precizează ce înlocuiesc noile dovezi. Dacă responsabilul de proiect schimbă data lansării din 15 noiembrie în 29 noiembrie, înregistrarea veche poate fi marcată ca înlocuită și asociată noii decizii. Pentru întrebările despre termenul-limită actual se folosește versiunea nouă; pentru cele despre planul inițial se poate consulta versiunea istorică.

Doar caracterul recent al unei informații nu poate soluționa orice conflict. O notă recentă dintr-un proiect poate avea mai puțină autoritate decât o politică mai veche, dar aprobată. Un utilizator poate avea dreptul să-și schimbe o preferință personală, fără să fie autorizat să modifice o regulă valabilă la nivelul întregii organizații. Politica de actualizare trebuie să țină cont de tipul informației și de autoritatea sursei sale.

Unele contradicții ar trebui să rămână nesoluționate până când o persoană oferă clarificări. Dacă doi responsabili de proiect indică date incompatibile, fără să precizeze explicit că una o înlocuiește pe cealaltă, asistentul le poate prezenta pe amândouă și poate întreba care dintre ele prevalează. Alegerea tacită a înregistrării celei mai asemănătoare sau celei mai recente ascunde o decizie pe care este posibil ca sistemul să nu aibă dreptul să o ia.

Ce înseamnă ca IA să uite?

Uitarea nu se reduce la un singur comutator. Un produs poate să nu mai includă o informație în prompturi, să o excludă din căutările obișnuite, să o marcheze ca depășită, să-i șteargă înregistrarea din memorie sau să elimine alte copii păstrate. Aceste operațiuni au efecte diferite asupra comportamentului viitor și asupra datelor păstrate.

Ieșirea din contextul activ

O informație poate să nu mai apară în următorul input al modelului deoarece mesajele mai vechi au fost omise sau rezumate. Astfel, modelul dispune imediat de mai puține informații pe care să le poată folosi. Transcrierea inițială sau înregistrarea din memorie poate exista în continuare și poate reapărea în urma unei regăsiri ulterioare.

Expirarea sau suprimarea regăsirii

Un termen-limită expirat poate rămâne într-o arhivă, fără să fie inclus în interogările despre activitatea curentă. Suprimarea este utilă când există un motiv pentru păstrarea informațiilor istorice, dar nu ar trebui prezentată drept ștergere completă. Înregistrarea poate fi accesată în continuare printr-o căutare în arhivă sau printr-un flux de lucru administrativ.

Ștergerea memoriei stocate

Ștergerea unei înregistrări persistente ar trebui să vizeze și reprezentările pentru regăsire derivate din aceasta. Dacă o propoziție este eliminată dintr-un profil, dar rămâne într-un rezumat care poate fi căutat, asistentul poate reconstitui ulterior aceeași preferință. În funcție de arhitectură, înregistrările-sursă, vectorii de încorporare, rezumatele, memoria cache și copiile replicate pot necesita operațiuni distincte de eliminare.

Copiile de rezervă și jurnalele pot avea propriile perioade de păstrare. Un produs ar trebui să explice clar aceste limite și să împiedice reactivarea materialelor șterse în timpul unei restaurări. „Nu vom mai folosi această memorie” și „toate copiile păstrate au fost eliminate” sunt promisiuni diferite.

Modificarea ponderilor modelului

Ștergerea memoriei externe nu modifică, prin ea însăși, parametrii modelului. Dacă informațiile au fost folosite la antrenare, tratarea lor în cadrul modelului este o problemă separată, care ține de procesul de antrenare și de implementare. De asemenea, ștergerea unei amintiri personale nu poate garanta că modelul nu va genera niciodată o informație similară pe baza cunoștințelor generale sau a indiciilor furnizate într-un prompt nou.

Prin urmare, un test relevant al uitării verifică atât dacă sistemul încă stochează informația, cât și dacă aceasta poate fi readusă prin căile obișnuite de recuperare. Un singur răspuns în chat în care sistemul spune „am uitat” nu dovedește niciuna dintre aceste lucruri.

Memoria, RAG, antrenarea și memorarea în cache: unde sunt limitele

Generarea augmentată prin recuperare, sau RAG, furnizează unui model dovezi externe în timpul generării. Cercetarea originală despre RAG combina parametrii modelului cu un index de documente care putea fi consultat. Un sistem de memorie personală poate folosi și el recuperarea, dar are nevoie și de politici pentru crearea, actualizarea și eliminarea înregistrărilor provenite din interacțiuni.

Un manual al companiei poate fi consultat fără să constituie o amintire despre utilizator. O notă despre o interacțiune anterioară poate fi recuperată dintr-un fișier simplu, fără un index vectorial. Recuperarea este un mecanism; scopul și ciclul de viață al înregistrărilor subiacente determină ce tip de sistem se construiește.

Antrenarea și ajustarea fină modifică parametrii modelului. În schimb, memoria externă obișnuită modifică dovezile furnizate modelului. Un asistent care respectă o preferință salvată recent se poate comporta diferit, chiar dacă ponderile modelului său rămân neschimbate.

Memorarea în cache a prompturilor și a inferențelor reutilizează calcule anterioare, acolo unde acest lucru este acceptat. Aceste tehnici pot spori eficiența, dar nu stabilesc, de la sine, dacă o afirmație reținută este actuală, autorizată sau potrivită pentru sarcini viitoare. Aceste straturi pot coexista, iar depanarea presupune identificarea stratului responsabil pentru comportamentul observat.

MemGPT oferă un exemplu arhitectural important: explorează mutarea informațiilor între un context limitat și niveluri externe de memorie, folosind o analogie cu sistemul de operare. Lecția utilă este că deplasarea informațiilor trebuie gestionată explicit, nu că stocarea extinde automat, fără limite, contextul imediat al modelului.

De ce memoria persistentă poate greșelile mai durabile

Un răspuns greșit poate afecta o singură interacțiune. O amintire greșită poate afecta multe. Dacă un asistent deduce că un utilizator a aprobat o decizie, salvează deducția ca fapt și citează ulterior înregistrarea salvată, propria eroare anterioară poate căpăta aparența unei dovezi independente.

În cazul asistentului nostru de proiect, sursa originală ar trebui să poată fi deosebită de interpretarea modelului. Un rezumat al unei decizii poate facilita consultarea, dar orice acțiune cu consecințe ar trebui să se bazeze pe decizia aprobată în sine. Repetarea unei deducții nesusținute în mai multe note generate nu o transformă în mai multe confirmări independente.

Memoria persistentă creează și o cale prin care instrucțiunile pot fi contaminate. Un document care nu este de încredere ar putea conține o propoziție care îi cere asistentului să-și schimbe comportamentul viitor. Stocarea acelei propoziții ca regulă de funcționare ar trece conținutul extern dincolo de o limită de autoritate. Aplicația ar trebui să trateze propoziția în funcție de sursa ei, nu să o promoveze la rangul de instrucțiune de încredere doar pentru că apare într-un depozit de memorie.

Mediile partajate introduc o altă limită. O informație poate fi relevantă pentru o întrebare, dar poate aparține altui client sau altui proiect. Verificările de acces ar trebui să limiteze recuperarea înainte ca informațiile să ajungă la model. Este o soluție mai puțin sigură să i se ceară modelului să ignore înregistrările neautorizate după ce acestea i-au fost deja furnizate.

Cum evaluăm dacă memoria funcționează cu adevărat

O demonstrație convingătoare îi cere adesea asistentului să repete o preferință salvată. O evaluare riguroasă urmărește informațiile care se schimbă de-a lungul mai multor sesiuni și verifică dacă memoria îmbunătățește îndeplinirea sarcinii.

LongMemEval evaluează extragerea informațiilor, raționamentul între sesiuni, raționamentul temporal, actualizarea cunoștințelor și abținerea de la răspuns. Aceste categorii arată de ce calitatea memoriei pe termen lung depășește simpla recuperare a unei singure propoziții potrivite. Rezultatele publicate la teste de referință ar trebui interpretate în raport cu sistemele și configurațiile testate, nu presupuse relevante pentru toate produsele actuale.

Pentru fluxul de lucru Cedar, o evaluare ar putea introduce o preferință, relua proiectul, adăuga o excepție, revizui un termen-limită, șterge o notă și apoi pune întrebări concepute pentru a scoate la iveală amintiri depășite sau nesusținute. Același model ar trebui testat și fără funcția de memorie, pentru a stabili dacă sistemul adăugat îmbunătățește rezultatele.

• Exactitatea înregistrării: A salvat sistemul afirmația dorită, împreună cu domeniul de aplicare și calificările acesteia?
• Utilitatea recuperării: A găsit dovezile necesare pentru sarcină fără să aglomereze contextul cu informații irelevante din istoricul anterior?
• Gestionarea actualizărilor: A înlocuit o corectare informația valabilă în prezent, păstrând totodată distincțiile istorice utile?
• Abținerea de la răspuns: A recunoscut asistentul când nu exista nicio înregistrare care să susțină răspunsul?
• Izolarea: Au rămas înregistrările limitate la utilizatorul, organizația-client și proiectul corespunzătoare?
• Uitarea: Au împiedicat ștergerea sau expirarea recuperarea ulterioară intenționată a informației, inclusiv prin rezumate derivate?
• Costul operațional: Au justificat îmbunătățirile latența, apelurile suplimentare către model, stocarea și întreținerea?

Eșecurile ar trebui urmărite până la etapa la care apar. Un răspuns absent ar putea fi rezultatul unei scrieri eșuate, al unui domeniu de căutare incorect, al unei decizii de ierarhizare necorespunzătoare, al unei calificări omise sau al unui model care a interpretat greșit dovezi solide. Mărirea dimensiunii contextului nu va remedia toate aceste probleme.

Alegerea arhitecturii de memorie potrivite

Un rezumat punctual al unui document poate necesita doar documentul curent și instrucțiunile. O analiză întreruptă beneficiază de un punct de control al sarcinii. Un asistent pentru un proiect recurent poate avea nevoie de decizii versionate și referințe la artefacte. Un asistent care lucrează în multe sesiuni ale utilizatorului poate avea nevoie de un spațiu separat, editabil, pentru preferințe.

Începeți prin a preciza ce întrebare viitoare ar trebui să răspundă memoria. „Ce a rămas neterminat?” necesită păstrarea stării sarcinii. „Ce format solicită acest client?” necesită o preferință cu domeniu de aplicare limitat. „De ce am respins această abordare?” necesită o înregistrare a deciziei, însoțită de dovezi justificative. Întrebări diferite merită reprezentări diferite.

Preferați un număr mic de înregistrări clare, atribuibile, în locul unei arhive nediscriminatorii prezentate drept personalizare. Păstrați starea curentă separat de evenimentele istorice, mențineți legăturile către artefactele-sursă și includeți corectarea și ștergerea în proiectare încă de la început.

Memoria activă îi oferă unui sistem AI un prezent coerent. Memoria persistentă îi poate oferi continuitate în timp. Calitatea acestei continuități depinde de deciziile dintre cele două: ce se salvează, ce revine, care versiune are prioritate și ce poate dispărea.