MI-ügynökök memóriája: hogyan építs tartós kontextusú MI-ügynököket

Ha hat hónapon át minden reggel oda kellene kísérned egy új kollégát a nyomtatóhoz, előbb-utóbb aggódni kezdenél. Ha minden korábbi utat tökéletes részletességgel el tudna mondani, de továbbra is kísérni kellene, akkor kiváló az emlékezete… te viszont ugyanúgy felállnál az asztalodtól.

Az MI-ügynökök memóriája jelenleg ennek az örökös nyomtatóhoz kísérgetésnek egy változatával küzd. A Letta vezérigazgatója, Charles Packer úgy nyilatkozott a The New Stack számára, hogy a memória-benchmarkok telítődtek, mert a felidézést mérik, amelyet ő megoldott problémának tart. A nyitott kérdés az, hogy egy ügynök a megőrzött kontextus révén, újratanítás nélkül fejlődjön a munkájában.

Társalapítója, Sarah Wooders egy új munkahely első napjához hasonlítja – a benchmarkok minden szükséges kontextust az ügynök kezébe adnak –, egymástól független feladatok sorában, ami egyáltalán nem hasonlít ahhoz, ahogyan az emberek dolgoznak. Egy új munkatársat talán még oda kell kísérni a nyomtatóhoz. De három év után azt remélnéd, hogy elég egy egysoros eligazítást adnod neki, és fel sem kell állnod az asztalodtól.

Ez az a mérce, amely felé építkezni érdemes, és ez a cél áll a Brain mögött is: a Perplexity Computer számára készült, önmagát fejlesztő memóriarendszerünk a korábbi munkát és javításokat egy folyamatosan fejlődő tudás-wikibe rendezi.

Bemutatjuk, mire kell emlékeznie egy ügynöknek, és hogyan tesztelhető, hogy ez segít-e neki jobb munkát végezni.

Mi az MI-ügynökök memóriája?

Az MI-ügynök memóriája az az információ, amelyet egy ügynök a korábbi interakciókból és munkából megőriz, valamint azok a mechanizmusok, amelyekkel frissíti és felhasználja azt. A tartós memóriakontextus ezt az információt a munkamenetek között is átviszi, így egy beszélgetés lezárása nem jelenti azt, hogy a következő feladatot a nulláról kell kezdeni.

Az ezen a néven kínált megoldások többsége a felhasználóra emlékszik. A preferenciáidra, a kapcsolataidra, a szerepkörödre, arra, hogy PNG helyett PDF-et szeretnél. Ez a könnyebbik fele.

Amikor a Brain fejlesztésén dolgoztunk – ez a Perplexity Computer mögött álló memóriarendszer –, magára a munkára összpontosítottunk. Melyik megközelítés vált be? Melyik forrás miatt ment el feleslegesen húsz perc? Mit kellett kijavítanod, miután az ügynök bejelentette, hogy végzett? Ezek az előzmények jobb kiindulópontot adnak a következő feladathoz.

A Brain ezeket az információkat fájlokként tárolja az ügynök sandboxában, három rétegbe rendezve:

• A sessions/ a nyers átiratokat és azok összefoglalóit tartalmazza.
• A notes/ a témák szerint rendezett, sűrített információkat tartalmazza.
• A knowledge/ magát a wikit tartalmazza: emberekről, projektekről és fogalmakról szóló, egymásra hivatkozó Markdown-oldalakat.

Mindez nem javul magától. Éjszakánként a „Dream” nevű háttérügynökeink elolvassák a nap munkameneteit, összefoglalják őket, és mindenhol átdolgozzák a wikit, ahol a kép megváltozott. Ezeket a módosításokat előkészítjük és ellenőrizzük, mielőtt Git segítségével véglegesítenénk őket, így ha valami furcsának tűnik, van egy diff, amelyet meg lehet vizsgálni.

Jobbá teszi-e az ügynököt a munkájában? 30 napos páros értékelésünkben a Brain használatával futó munkamenetek 9,3 százalékponttal javították a helyességet és 8,9 százalékponttal a felidézést, miközben nagyjából 15%-kal kevesebb tokent használtak.

Nagyítás

Forrás: X

Milyen típusai vannak az ügynöki memóriának?

Két nagy típus létezik, és a felosztás nagyon hasonlít ahhoz, amelyet egy emberre alkalmaznál: ami éppen most jár a fejedben, és amit a következő hónapban is tudni fogsz.

Rövid távú memória

A rövid távú memória az aktuális beszélgetés vagy feladat kontextusát tartalmazza. A kérésedet, a legutóbbi üzeneteket, egy eszközhívás eredményét, a dokumentumot, amelyet az ügynök épp megnyitott. Elég információt ahhoz, hogy kitalálja, mi legyen a következő lépés.

Ezt munkamemóriának is nevezik. Egy LLM esetében a kontextusablak tartalmazza az adott modellhívás során elérhető információkat. Az alkalmazás ezen felül további feladatállapotot is fenntarthat, és eldöntheti, hogy annak mely részeit adja át az egyes lépésekben.

A rövid távú ráadásul nem feltétlenül jelenti azt, hogy eldobható. Egy keretrendszer elmentheti a beszélgetés állapotát, és másnap folytathatja – ez továbbra is ahhoz a szálhoz tartozik. Az viszont külön tervezési döntés, hogy egy másik feladat felhasználhatja-e az információt.

Hosszú távú memória

A hosszú távú memória a munkamenetek között is elérhetővé teszi az információkat. A CoALA-tanulmány három kategóriát vett át a kognitív tudományból, így fogalomkészletet adott az ügynököket fejlesztők kezébe a tapasztalatok és a szakértelem leírásához:

• Az epizodikus memória az, ami történt: Ide tartoznak a korábbi munkamenetek, az ügynök által megtett lépések és az elért eredmény. A Brainben a sessions/ a nyers átiratokon és azok összefoglalóin keresztül biztosítja ezeket az előzményeket.
• A szemantikus memória az, amit az ügynök igaznak tekint: Ezek lehetnek a felhasználóról, a projektjeiről és a világáról szóló, a beszélgetésekből leszűrt tények. A Brain knowledge/ wikije ilyen információkat tárol, a bizonyítékokra visszamutató hivatkozásokkal.
• A procedurális memória az, hogy hogyan kell elvégezni a dolgokat: Ezek a promptok, az újrafelhasználható munkafolyamatok, a Perplexity által készített Skillek, amelyek megadják az ügynököknek a munkához szükséges utasításokat és eszközöket. Lehet, hogy ezek egy része már megvan nálad, csak nem nevezted memóriának.

Az érdekes munka a rétegek között zajlik. Egy munkamenet rögzíti, hogy elutasítottál egy PNG-t. Az utasításod, hogy PDF-et használjon, olyan preferenciává válik, amelyet az ügynök továbbvihet. Az exportálási folyamat egy javítása pedig olyasmivé válik, amit legközelebb követni tud.

Ez az átalakulás – az „ez történt” szinttől az „ez igaz” szinten át az „így csináljuk” szintig – része annak a tanulási problémának, amellyel kezdtük, és a Brain éjszakai Dream-ügynökfuttatásai éppen erre fordítják az erőfeszítéseik nagy részét.

Tegyük fel, hogy valaki halat melegít a mikróban egy közös konyhában. Panaszok érkeznek, valaki ablakot nyit. Végül megjelenik egy tábla: TILOS A HAL!

Hat hónappal később a tettes már elköltözött, de a tábla maradt. Ez a tartósság. A memóriatípusokat azon keresztül is elmagyarázhatod, hogy mi marad meg:

• A munkamemória az, amire ebédkészítés közben figyelsz, például hogy meg kell kavarni a levest.
• Az epizodikus memória a halas incidens; a szag, amely mindenkit követett a folyosóra.
• A szemantikus memória az a tudás, amelyet ebből leszűrtél – a hal újramelegítése tartós szagot hagyhat egy közös konyhában.
• A procedurális memória az az utasítás, amely meghatározza, mi történik ezután. Itt ne melegíts halat a mikróban. A tábla révén az is betarthatja a szabályt, aki az egész incidensről lemaradt.

Van még egy megkülönböztetés, mert ez megváltoztatja, hogy mit építünk. Egy 2025 decemberében először megjelent áttekintő tanulmány, a Memory in the Age of AI Agents szerint a rövid és hosszú táv szerinti felosztás nem elég – a memóriát a formája szerint is osztályozza:

• Tokenszintű: Ez az a kifejezett tartalom, amelyet az ügynök olvas. Fájlok, tárolt rekordok, lekért szövegrészletek.
• Parametrikus: Ez a tanult súlyokba kódolt információ. A frissítéséhez tanításra vagy modellszerkesztési módszerekre van szükség.
• Látens: Ez a belső reprezentációkban megőrzött információ, amely nincs olvasható szövegként kiírva.

Itt a tokenszintű memóriára összpontosítunk, vagyis a modellen kívül tárolt információra, amely szükség esetén bekerül a kontextusába. A Brain Markdown-wikije is ilyen.

Nagyítás

Amikor frissítünk egy oldalt, azt változtatjuk meg, hogy az ügynök mit olvashat a következő feladatánál, de a mögöttes súlyai változatlanok maradnak. Ez Packer bevezetőben említett gondolata: fejlődés az ügynök által megőrzött kontextuson keresztül, újratanítás nélkül.

Hogyan működnek együtt az ügynöki memória típusai?

Egy ügynök újra megnézhet egy korábbi próbálkozást, láthatja, hol csúszott hiba, és betöltheti azokat az utasításokat, amelyeket utána adtál neki. Ugyanabban a feladatban többféle memória is részt vesz, és nem kell mindegyiknek külön kört vagy külön adatbázist kapnia.

Itt a tartósság határozza meg, mi marad elérhető a beszélgetés vége után, a visszakeresés pedig azt, hogy az ügynök egyáltalán látja-e még valaha.

A Brainben megőrizzük ezt az utat a tanulságtól vissza a bizonyítékig. Tegyük fel, hogy megkéred a Computert, hogy folytasson egy múlt heti projektet:

• A Brain indexe megmutatja neki, mely memóriaoldalak léteznek, és hol találja őket.
• A Brain megnyitja a projektoldalt, hogy elolvassa a mentett döntéseket és utasításokat.
• Ha egy jegyzet szerint elutasítottál egy megközelítést, az ügynök a hivatkozását követve visszajuthat a beszélgetéshez, és megnézheti, miért.

A kapcsolódó oldalakra mutató linkek révén utánanézhet az érintett személyeknek vagy más projekteknek. Ezt az ügynök fájlok olvasásával és keresésével teszi. A grep segítségével például név alapján megtalálhatja egy projekt említéseit.

Azt is teszteltük, mit nyernek az ügynökök azzal, hogy bejárhatják a fájlokat. Egy 150 pénzügyi dokumentumokkal kapcsolatos kérdésből álló belső benchmarkban a szabványos fájleszközöket használó felfedező ügynök 0,627-es válaszpontszámot ért el, szemben az ugyanazon a korpuszon végzett szemantikus keresés körülbelül 0,37-es eredményével.

Nagyítás

Forrás: X

Hogyan javítható az MI-ügynökök memóriája?

Orogat és Mansour 2026 májusi tanulmánya négy visszatérő hibát azonosít az ügynöki memóriában: a tár folyamatosan nő, az elavult feltevéseket senki sem vizsgálja felül, az információ elveszik, amikor elfogy a hely, a visszakeresés pedig olvas, de semmit sem tanul a látogatásból.

Javasolt megoldásuk az, hogy az ügynöki memóriát ne tárolóként kezeljük, hanem olyan „állapotként”, amely négy műveleten keresztül fejlődik: befogadás, felülvizsgálat, felejtés, visszakeresés. Ez a mi ellenőrzőlistánk ehhez a szakaszhoz.

Válogasd meg, mi kerüljön a memóriába

Ha egy „rossz” memóriabejegyzés egyszer bekerül, minden lépés örökli.

A Workday AI Research egy szelektív megközelítést tesztelt a LoCoMo benchmark nagyjából 1500 jelölt memóriabejegyzésén, és mielőtt bármelyiket megtartotta volna, öt kérdést tett fel:

• Hasznos? Valószínű, hogy újra előkerül?
• Megbízható? Tényleg elhangzott ez a beszélgetésben, vagy a modell egészítette ki?
• Új, vagy már el van tárolva?
• Friss?
• Tartós tény vagy múló állapot?

Csak az első kérdéshez kellett modellhívás. A másik négy szabályként futott, összesen kevesebb mint 65 ezredmásodperc alatt. A módszer 12%-kal nagyobb pontosságot ért el a megtartási vagy elvetési döntésekben, miközben a releváns memóriabejegyzések 97%-át megőrizte.

A legnagyobb mértékben az utolsó kérdés járult hozzá – ha megszüntették a tartós és az ideiglenes információ közötti különbségtételt, a döntések minősége nagyjából 18%-kal romlott.

Frissítsd a választ az előzmények elvesztése nélkül

Rögzítsd, mikor vált érvényessé egy tény, melyik forrás támasztja alá, és mit váltott fel. Ha a források ellentmondanak egymásnak, tartsd láthatóan az ellentmondást, amíg nincs elég bizonyíték a feloldásához. A legújabb dokumentum is tévedhet.

A Brain forrásdokumentumok, a csatlakozók eredményei és felhasználói javítások alapján frissíti a wikit. Minden memóriabejegyzés visszamutat a forrására. Arra van szükségünk, hogy az ügynök megtalálja az aktuális választ, és legyen hol utánanéznie, ha a válasz gyanúsnak tűnik.

Felejts tudatosan

A tanulmány az egyik hibamódot „kapacitásvezérelt felejtésnek” nevezi: az információ azért törlődik, hogy teljesüljön egy tárolási korlát, nem pedig azért, mert már nem hasznos.

Vissza a közös konyhához. Hat hónap után már senkit sem érdekel, ki melegítette a halat a mikróban, vagy meddig volt nyitva az ablak. A táblának viszont még mindig van dolga.

Ha a következő ember ebédet készít, a szabály ott lesz előtte. A panaszokat egyszerűen archiválod.

A Workday frissességi és információtípus-ellenőrzései már a tárolás előtt működésbe lépnek, és kiszűrik, mi érdemes arra, hogy memóriabejegyzés legyen. A Brainben a meglévő tudást is újra átnézzük, ahogy a forrásdokumentumok változnak, és a felhasználók javításokat végeznek. A beavatkozást mindkét esetben a tartalom teszi szükségessé.

Hasznosítsd a visszakeresést a következő frissítéshez

Az ügynök lekér egy tényt, felhasználja, és pontosan úgy hagyja a tárat, ahogy találta. Ha a rendszer nem rögzíti, mi történt ezután, semmi sem jegyzi fel, hogy a tény segített-e, vagy újabb zsákutcába vezette az ügynököt.

Rögzítsd az eredményt, a forrást és minden javítást. Amikor a Brain fejlesztésén dolgoztunk, ezt a munkatörténetet annak részévé tettük, amire emlékszik: melyik megközelítés vált be, melyik forrás nem vezetett sehová, és mit javított ki a felhasználó, miután az ügynök bejelentette, hogy végzett. A Brain ezt a tapasztalatot beépíti a wiki rendszeres frissítéseibe, így a későbbi feladatok is hasznosíthatják.

Mindez azonban nem jelenik meg egy felidézési benchmarkon. Úgy lehet megtudni, hogy működik-e a ciklus, ha olyan feladatot adunk az ügynöknek, amelyet csak memóriával tud elvégezni, és megszámoljuk, milyen gyakran sikerül neki, a költséggel és a késleltetéssel együtt. Pontosan ezt teszi a DolphinBench, és ezért vannak a legjobb pontszámok még mindig a hetvenes tartományban.

Hogyan építhetsz tartós memóriával rendelkező ügynököt a Perplexity segítségével

A Perplexity Agent API nem tartalmaz olyan önmagát karbantartó memóriarendszert, mint a Brain. Ezt inkább már az elején elmondjuk. Amit viszont megad, azok a szükséges memória építőelemei: hely az eljárások tárolásához, mód a kontextus körök közötti átvitelére, valamint eszközök egy általad kezelt tár olvasásához és írásához.

Kezdd a procedurális memóriával

Az egyéni Skill verziószám alatt csomagolja össze az utasításokat, az eljárásokat és a kiegészítő fájlokat. Egy platformcsapat egyszer megírhatja az üzembe helyezési ellenőrzéseit, a visszaállítási feltételeit és a jelentésformátumát, az alkalmazások pedig ezután ugyanarra a Skillre hivatkozhatnak. Ha az eljárás megváltozik, a csapat feltölt egy új verziót.

Nagyítás

Forrás: X

A Profil egy szinttel feljebb lép. A Profilok egyetlen verziózott azonosító alatt mentik el az ügynök modelljét, utasításait, eszközeit, Skilljeit, csatlakozóit és futtatási beállításait.

Szeptemberben mindkettőt bevezettük, a felügyelt csatlakozókkal együtt, így a projekt adminisztrátora egyszer konfigurálhat egy jóváhagyott GitHub- vagy Slack-kapcsolatot, és az alkalmazások erre hivatkozhatnak ahelyett, hogy külön hitelesítő adatokat tárolnának. Ha a hozzáférés megváltozik, az adminisztrátor egyetlen helyen frissíti a kapcsolatot.

Miért számít ez memóriának? Térjünk vissza még egyszer a mikróban melegített hal miatti konyhai esethez. Aki legközelebb érkezik, betarthatja a „HALAT TILOS” szabályt anélkül, hogy tanúja lett volna a panaszoknak.

A Skill ugyanezt a feladatot látja el egy ügynök számára, és elférnek benne azok a lépések, kivételek és ellenőrzések is, amelyek nem férnének fel a mikró ajtajára. A Skillek írásban rögzítettek, verziózottak, és elérhetők, amikor a feladat legközelebb előkerül.

A Dream memóriafrissítéseit is Skillekkel irányítjuk. Amire viszont egy Skill nem képes, az az önálló tanulás. Az utasítások akkor változnak, amikor új verziót töltenek fel – akár egy ember, akár egy automatizált folyamat.

Ha azt szeretnéd, hogy az ügynök észrevegye, hogy a visszaállítási ellenőrzés egy szolgáltatásnál újra és újra meghiúsul, és ehhez alkalmazkodjon, akkor a korábban bemutatott, munkamenetekből wikit építő ciklusra van szükséged.

Meg kell őrizned, mi történt, ki kell derítened, minek kellene változnia, és a javítást elérhetővé kell tenned a következő alkalomra. Ehhez a következő két elemre van szükség.

Vidd át a munkamemóriát a fordulók között

Az ügynök lefuttat egy üzembe helyezési ellenőrzést. Megkérdezed: „Ez miért nem sikerült?” Ésszerű kérdés, feltéve, hogy az ügynök még látja, mire vonatkozik az „ez”.

Az Agent API-nk kétféleképpen tudja továbbvinni a beszélgetés kontextusát:

• A beszélgetés visszajátszása saját kezűleg: Vedd fel a korábbi üzeneteket a következő kérés input tömbjébe. Te döntöd el, mit tartasz meg, foglalsz össze, takarsz ki vagy hagysz el, mielőtt elküldöd.
• Folytatás egy befejezett válaszból: Mentsd el a válasz azonosítóját, és add át previous_response_id paraméterként a következő üzenettel. A beszélgetés állapotát szerveroldalon tároljuk, így az alkalmazásodnak nem kell újraküldenie a korábbi fordulókat. A lánc legutóbbi válaszától folytathatod.

A visszajátszással te szabályozod, mit lát az ügynök, az azonosító alapján történő folytatással pedig megspórolod a beszélgetés újbóli összeállítását. Mindkét esetben add meg a következő válaszhoz szükséges új utasításokat, eszközöket vagy modellbeállításokat.

Használd a saját epizodikus és szemantikus tárolódat

Ezt a részt az Agent API rád bízza.

Az egyik lehetőség a függvényhívás. Te definiálod az eszközöket, az ügynök hívást kér, az alkalmazásod pedig végrehajtja azt, és visszaadja az eredményt. A memória esetében egyszerű kiindulópont egy olvasási művelet, mielőtt az ügynök cselekszik, és egy írási művelet utána.

Ha csak a lekért tényt naplózod, továbbra sem tudod, hogy segített-e. Ha naplózod az eredményt, a forrást és mindazt, amit a felhasználó kijavított, máris megvan egy epizodikus réteg alapja.

Az MCP-támogatásunk egy másik lehetőséget kínál. Ha egy kompatibilis távoli MCP-szerver elérhetővé teszi a szükséges műveleteket, az ügynök meghívhatja őket anélkül, hogy mindegyiket egyéni függvénybe kellene csomagolnod.

A csatlakozóink hozzáférést adnak az ügynöknek az emlékek mögötti bizonyítékokhoz. A GitHub, a Slack, a Google Drive, a Datadog, a Linear és a Notion szerepel a felügyelt katalógusunkban, a belső rendszerekhez pedig egyéni csatlakozókat adhatsz hozzá.

Végül döntsd el, mikor kerüljön sor az előzmények áttekintésére és az aktuális összkép átdolgozására.

Teszteld, mi marad meg egy új munkamenetben

Most zárd le a beszélgetést. Indíts egy új kérést a régi üzenetek visszajátszása és a previous_response_id átadása nélkül, de adj az ügynöknek hozzáférést ugyanahhoz a memóriatárolóhoz. Kérd meg, hogy végezzen el egy kapcsolódó feladatot anélkül, hogy megismételnéd a javítást.

Ha szüksége van az emlékeztetőre, még nem végeztél.

Az üzembe helyezési ügynökhöz készíts néhány tesztet arra vonatkozóan, aminek meg kell maradnia:

• A javítás megmarad: Lekéri és használja az érintett szolgáltatás ellenőrzött visszaállítási parancsát.
• A javítás a hatókörén belül marad: A többi szolgáltatás eljárásait érintetlenül hagyja.
• Az új információ felváltja a régi útmutatást: Ha a parancs ismét megváltozik, az aktuális verziót használja, és a változást vissza tudja vezetni a forrásáig.

A regressziós tesztelési receptgyűjteményünk bemutatja, hogyan mentheted el az ügynök kimeneteit és a lekért bizonyítékokat, hogyan vetheted össze őket az elvárt viselkedéssel, és hogyan hasonlíthatod össze a futtatásokat az utasítások vagy a modellek módosítása után.

Tartsd rögzítve a modell-, a Profil- és a Skill-verziókat, miközben memóriával és anélkül végzett futtatásokat hasonlítasz össze. Minden összehasonlítást a tároló egy ismert pillanatképéből indíts; különben az egyik teszt megtaníthatja az ügynöknek a következő teszt megoldását.

Ha valami meghiúsul, mentsd el az esetet. A következő módosításnak már át kell mennie rajta.

Vagy hagyd ki az építést: Brain a Computerben

Ha nem az alkotóelemekre, hanem a kész ciklusra van szükséged, akkor a Computer a megoldás. Alatta a Brain fut, amely négy forrásból tanul: a munkameneteidből, a csatlakoztatott eszközökből, az általad készített fájlokból és műtermékekből, valamint a javításaidból. A Brain háttérfrissítései megerősítik azt, ami még érvényes, átdolgozzák azt, ami megváltozott, és megjelölik az elavult információkat.

Ezt a ciklust nem neked kell felépítened. Te csak végzed a munkát.

A Memória megőrzi az általad megosztott preferenciákat és részleteket. A Brain összekapcsolja a projekteket, az embereket, a döntéseket és a befejezetlen munkát a mögöttük álló bizonyítékokkal.

A Memória nézetben megtekintheted, mit tanult, visszakövetheted a bejegyzéseket a forrásukig, és szerkesztheted vagy törölheted őket. A Brain a saját tevékenységedet használja, kizárja az inkognitó munkameneteket, és saját kapcsolóval rendelkezik.

Nagyítás

A Rho-nál például egy számlázási projekt döntései szét voltak szórva a Slack, a Notion, a Jira, a Figma és a Google Docs között. A csapat úgy állította be a Computert, hogy éjszaka áttekintse a változásokat, jelezze az ellentmondásokat, és reggeli összefoglalót tegyen közzé a Slacken.

A cég szoftvermérnöke, Oktawian Jurkiewicz észrevette, hogy a Computer memóriát is épít a projekthez. „Nem mi határoztuk meg” – mondja. „A Computer maga jött rá, mely adatpontokat érdemes eltárolnia az egyes forrásokból.”

A csapat beszámolója szerint a heti megbeszélésekre fordított időt 2,5 óráról 15 percre csökkentették, és becslésük szerint a 12 hetes projekt során 120 munkaórát takarítottak meg.

A 120 óra a teljes munkafolyamat érdeme: a csatlakozóké, az éjszakai futtatásoké és a Slack-összefoglalóé. Mennyi volt a megtakarított időből kizárólag a memória érdeme? Ezt egyelőre nem tudjuk számszerűsíteni.

Azt viszont tudjuk tanácsolni, hogy a saját megoldásodnál térj vissza a korábbi teszthez – futtass egyenértékű feladatokat bekapcsolt és kikapcsolt memóriaréteggel, majd hasonlítsd össze a teljesítési arányokat, a költséget és az időt, beleértve azt az időt is, amelyet valaki az eredmény javításával tölt.

GYIK az MI-ügynökök memóriájáról

Lehet memóriájuk az MI-ügynököknek?

Igen. Az MI-ügynökök a tárolt beszélgetések, tények, preferenciák és újrafelhasználható eljárások révén munkameneteken átívelően is megőrizhetnek információkat. A rendszernek elő kell hívnia ezeket az információkat, amikor relevánsak, és frissítenie kell őket, amikor a körülmények megváltoznak.

A Perplexity Computer Brain funkciója például a munkamenetekből, a csatlakoztatott eszközökből, a fájlokból és a felhasználói javításokból épít munkakontextust.

Mennyi RAM-ot használ egy MI-ügynök?

Nincs egységes követelmény. Ha az ügynököd a Perplexity Agent API-n keresztül hív meg egy hosztolt modellt, nem kell betöltened azt a modellt a saját RAM-odba. Az alkalmazásodnak és a helyi eszközeidnek azonban továbbra is szükségük van memóriára.

A helyi modellfuttatás más eset. Paraméterenként négy bittel számolva nyolcmilliárd paraméter nagyjából 4 GB nyers súlyadatot jelent. A ténylegesen szükséges memória ennél több, ha figyelembe vesszük a kvantálás többletterhelését, a kontextus feldolgozását és a modellt futtató szoftvert.

Mi a legjobb memória egy MI-ügynök számára?

A legjobb felállás attól függ, mit kell az ügynöknek továbbvinnie. A beszélgetési állapot a ráépülő kérdéseket támogatja; az epizodikus rekordok megőrzik, mi történt; a szemantikus memória az aktuális tudást tárolja; a procedurális memória pedig újrafelhasználható utasításokat biztosít.

A legtöbb folyamatos munkának a kombináció válik javára. A Brainhez egy összekapcsolt, forrásokkal alátámasztott wikit használunk. A saját megoldásodnál teszteld, hogy a felállás segít-e az ügynöknek elvégezni a feladatokat, alkalmazni a javításokat és kivezetni az elavult útmutatásokat.