Agent Memory៖ បញ្ហាមិនមែនការ Recall ទេ វាជាការភ្លេច

ពេលមនុស្សព្រួយបារម្ភអំពី agent memory ពួកគេស្ទើរតែតែងតែព្រួយបារម្ភអំពី recall៖ តើ agent អាចចងចាំអ្វីដែលខ្ញុំប្រាប់វាបី session មុនបានទេ? វាជាការភ័យខ្លាចតាមសភាវគតិ ហើយវាភាគច្រើនជាការខុស។ ការស្រាវជ្រាវឆ្នាំ ២០២៦ លើ long-term agent memory បាន converge ទៅរករូបភាពដ៏មិនស្រួលជាង ដែលការបរាជ័យលំបាកមិនមែនអំពីការចងចាំទាល់តែសោះ។ ពួកវាអំពីរបៀបដែល memory ត្រូវ architect, របៀបដែលវាត្រូវ retrieve, និង — ដែលគ្មាននរណារចនាសម្រាប់ — របៀបដែលវាត្រូវ ភ្លេច។ Recall ជាផ្នែកងាយ។ អ្វីៗទាំងអស់ជុំវិញវាជាកន្លែងដែល agent ខូច។

នេះសំខាន់ព្រោះ memory ជាអ្វីដែលបំបែក tool one-shot ដ៏ឆ្លាតវៃពី agent ដែលអ្នកអាចធ្វើការជាមួយពិតប្រាកដតាមពេលវេលា។ ធ្វើវាខុស ហើយ agent មិនជា amnesiac ឬ កាន់តែអាក្រក់ មានទំនុកចិត្តខុសអំពី fact ចាស់ៗ។ ដូច្នេះវាសមនឹងស្វែងយល់ថា benchmark រកឃើញពិតប្រាកដអ្វី ព្រោះការបរាជ័យនីមួយៗក្នុងបីមាន fix ខុសគ្នា។

Context window មិនមែន memory

ចាប់ផ្ដើមជាមួយកំហុស architectural ដែលសាមញ្ញបំផុត ដាក់ឈ្មោះត្រង់ៗដោយ paper ឆ្នាំ ២០២៦ មួយ The Missing Memory Hierarchy (arXiv 2603.09023)៖ “The context window of a large language model is not memory. It is L1 cache: a small, fast, expensive resource that the field treats as the entire memory system.” ការ reframe តែមួយនោះពន្យល់ការរចនា agent អាក្រក់ច្រើន។ ក្រុមញាត់អ្វីៗគ្រប់យ៉ាងចូល window ព្រោះវាជា storage តែមួយដែលពួកគេបាន engineer — ហើយបន្ទាប់មកធ្វើភ្ញាក់ផ្អើលពេលវាថ្លៃ ខ្ជះខ្ជាយ និងមិន scale។

Paper វាស់ការខ្ជះខ្ជាយក្នុង production៖ 21.8% structural waste ទូទាំង 857 production session និង 4.45 million input token។ មួយភាគប្រាំនៃអ្វីដែលនៅក្នុង window ជាមធ្យម មិនត្រូវការនៅទីនោះ។ ការ fix ជាមួយដែល operating system បានដោះស្រាយជាច្រើនទសវត្សរ៍មុន — memory hierarchy មួយជាមួយ demand paging៖ រក្សា working set នៅក្នុង window ដ៏លឿន កម្រ រក្សាអ្វីៗផ្សេងទៀតក្នុង storage ថោកជាង ហើយ page បំណែកដែលពាក់ព័ន្ធចូលតាមតម្រូវការ ជាជាងកាន់វាទាំងអស់ស្ថិតនៅ។ ផលដែលពួកគេ report ធំ៖ រហូតដល់ 93% context reduction ក្នុង live production (session មួយផ្លាស់ពី 5,038KB ទៅ 339KB) នៅ 0.0254% fault rate ដ៏មិនសំខាន់ ទូទាំង 1.4 million simulated eviction។ ចាត់ទុក window ជា L1 cache ជំនួស memory ហើយ bloat — និងថ្លៃដើម — ភាគច្រើនបាត់ទៅ។

នេះជាដៃគូ systems-level នៃចំណុចដែលយើងបានធ្វើក្នុង context engineering៖ window ជា resource កម្រដែលត្រូវគ្រប់គ្រង មិនមែន bucket ដែលត្រូវបំពេញ។ Memory hierarchy ជា architecture ដែលគ្រប់គ្រងវា។

Retrieval ជា lossy ហើយវាខកខានអ្វីដែលសំខាន់

ឧបមាថាអ្នកសាងសង់ storage នៅខាងក្រៅ window។ ឥឡូវសំណួរគឺអ្វីដែលអ្នកទាញ ត្រឡប់ចូល ហើយនេះជាការបរាជ័យទីពីរ៖ memory system ភាគច្រើន retrieve អាក្រក់។ AMA-Bench (arXiv 2602.22769) benchmark មួយសាងសង់លើ agent trajectory ជាក់ស្ដែង — state, action, observation, tool output មិនត្រឹមតែ chat log — បានរកឃើញថា “existing memory systems underperform because they fail to capture causal and objective information and rely heavily on lossy similarity-based retrieval។”

ឃ្លានោះ lossy similarity-based retrieval ជាបេះដូងរបស់វា។ វិធីសាស្ត្រស្ដង់ដារ embed អ្វីៗគ្រប់យ៉ាង ហើយ retrieve អ្វីដែលស្រដៀងតាមន័យ semantic បំផុតនឹង query បច្ចុប្បន្ន។ ប៉ុន្តែ ស្រដៀង មិនមែនដូចគ្នានឹង ពាក់ព័ន្ធ — fact ដែលអ្នកត្រូវការតាម causal ដើម្បីឆ្លើយសំណួរ ជាញឹកញាប់មិនមែនជា fact ដែលមើលទៅស្រដៀងសំណួរបំផុត។ សួរ agent ថា “ហេតុអ្វី staging deploy បរាជ័យ?” ហើយ similarity retrieval surface យ៉ាងសប្បាយរីករាយរាល់សារកន្លងមកដែលមាន “deploy” និង “staging” — ខណៈមូលហេតុពិតប្រាកដ ការផ្លាស់ប្ដូរ config បី session មុនដែលមិនដែលលើកឡើងពាក្យណាមួយ rank គ្មានកន្លែង។ Memory ដែលផ្ទុក causal និង memory ដែលស្រដៀងតាមអក្សរ ជា set ខុសគ្នា ហើយ similarity search optimize សម្រាប់មួយខុស។ ដូច្នេះ agent retrieve context ដែលមើលទៅសមហេតុផល ហើយខកខានព័ត៌មានលម្អិតដែលផ្ទុក។ សូម្បី system ដែលសាងសង់ដោយចេតនារបស់ paper គឺ AMA-Agent — ដែលសាងសង់ causality graph និងប្រើ tool-augmented retrieval ជាជាង similarity ឆៅ — ឈានដល់ត្រឹម 57.22% accuracy លើសពី baseline ខ្លាំងបំផុតដោយ 11.16%។ អានវាជា ceiling state-of-the-art៖ memory system ល្អបំផុត ដែលបានសាកល្បងទទួលបានត្រឹមជាងពាក់កណ្ដាលនៃចម្លើយត្រឹមត្រូវបន្តិច ហើយវាធ្វើដូច្នេះពិតប្រាកដដោយផ្លាស់លើស similarity ទៅ causal structure។ Retrieval នៅឆ្ងាយពីការដោះស្រាយ។

បញ្ហាលំបាកបំផុតគឺការភ្លេច

ការបរាជ័យទីបីជាមួយដែលស្ទើរតែគ្មាននរណារចនាសម្រាប់ ហើយវាគ្រោះថ្នាក់បំផុត។ Memora (arXiv 2604.20006) benchmark មួយលាតសន្ធឹងការសន្ទនាដែលមានរយៈ ប៉ុន្មានសប្ដាហ៍ដល់ប៉ុន្មានខែ បានចេញសាកល្បងមិនត្រឹមតែថាតើ agent ចងចាំ ប៉ុន្តែថាតើពួកវាអាច update — ហើយវាបានណែនាំ metric សម្រាប់ពិតនេះ៖ FAMA, Forgetting-Aware Memory Accuracy, ដែលផាកពិន័យការពឹងផ្អែកលើ memory ដែលលែងប្រើ ឬ invalidate។ លទ្ធផលធ្វើឱ្យគិត៖ “Evaluations of four LLMs and six memory agents reveal frequent reuse of invalid memories and failures to reconcile evolving memories. Memory agents offer marginal improvements។”

អង្គុយជាមួយ frequent reuse of invalid memories។ អ្នកប្រើប្ដូរការងារ; API ត្រូវ deprecate; ការសម្រេចចិត្ត architectural ត្រូវ reverse កាលពីខែមុន — ហើយ agent បន្តធ្វើសកម្មភាពលើ fact ចាស់ ដោយទំនុកចិត្ត ព្រោះវាចងចាំវាយ៉ាងល្អឥតខ្ចោះ។ ការចងចាំងាយ។ ការដឹងថាអ្វីដែលអ្នកចងចាំ លែងពិត ជារឿងលំបាក ហើយ system បច្ចុប្បន្នអាក្រក់នៅវា។ កាន់តែអាក្រក់ memory agent ឯកទេស — system ដែលសាងសង់ជាក់លាក់ដើម្បីគ្រប់គ្រងនេះ — ផ្ដល់ត្រឹម “marginal improvements” លើ model ធម្មតា។ ការភ្លេចមិនមែនជា sub-problem ដែលដោះស្រាយរបស់ memory ទេ វាជាបញ្ហាបើកចំហ ហើយវាជាការបរាជ័យដែលទំនងបំផុតធ្វើឱ្យ agent ដែលរស់នៅយូរមិនគួរទុកចិត្តយ៉ាងស្ងាត់។

ហើយកត់សម្គាល់ហេតុអ្វីវាលំបាកតាម structure។ Memory system ដ៏ឆោតល្ងង់ជា append-only៖ វាសរសេរ fact ថ្មីប៉ុន្តែមិនដែល retract fact ចាស់ ដូច្នេះព័ត៌មានផ្ទុយគ្នាប្រមូលផ្ដុំ ហើយ retrieval step គ្មានវិធីដ៏មានគោលការណ៍ដើម្បីដឹងថា version ណាបច្ចុប្បន្ន។ ការ fix វាមិនត្រឹមតែ “store a timestamp” — agent ត្រូវ recognize ថា observation ថ្មី invalidate observation ចាស់ (មិនត្រឹមតែបន្ថែម) ដែលជាញឹកញាប់តម្រូវឱ្យយល់ថា fact ពីរដែលសរសេរខុសគ្នាអំពីរបស់ដូចគ្នា។ នោះជាបញ្ហា reasoning ស្លៀកសម្លៀកបំពាក់របស់បញ្ហា storage ដែលជាមូលហេតុពិតប្រាកដ memory layer ដែល bolt-on ស្ទើរតែមិនផ្លាស់លេខ FAMA៖ ពួកវាធ្វើ storage និង retrieval ឱ្យល្អជាងខណៈទុកការវិនិច្ឆ័យ invalidation ឱ្យ model ដែលមិនដែលត្រូវសុំឱ្យធ្វើ។

Memory ជាវិន័យ engineering មិនមែន feature របស់ model

ដាក់ទាំងបីជាមួយគ្នា ហើយសេចក្ដីសន្និដ្ឋានច្បាស់៖ agent memory មិនមែនជាអ្វីដែលអ្នកទទួលដោយជ្រើស model ធំជាង ឬ context window វែងជាង។ វាជា system ដែលអ្នករចនា ជាមួយបញ្ហាបីផ្សេងគ្នាដែលត្រូវដោះស្រាយ។ Architecture៖ ចាត់ទុក window ជា L1 cache ហើយសាងសង់ hierarchy ដែល page information ចូលតាមតម្រូវការ។ Retrieval៖ ទាញអ្វីដែលពាក់ព័ន្ធតាម causal មិនត្រឹមតែអ្វីដែលស្រដៀងតាមផ្ទៃ។ Invalidation៖ សម្រេចថាអ្វីត្រូវភ្លេច ហើយ reconcile fact ពេលវាផ្លាស់ប្ដូរ — ផ្នែកដែលគ្មាន default ល្អ។ Window ធំជាងធ្វើ cache ធំជាង វាមិនធ្វើអ្វីសម្រាប់គុណភាព retrieval ឬ invalidation។ ទាំងនេះជាបញ្ហា engineering ហើយពួកវារស់នៅក្នុង harness ជុំវិញ model មិនមែនក្នុង weight។

នោះក៏ជាមូលហេតុដែល memory មិនអាចជា component ទូទៅ ទិញចេញពីធ្នើ។ អ្វីដែលរាប់ជា “working set”, អ្វីដែល “ពាក់ព័ន្ធតាម causal”, និងអ្វីដែលធ្វើ fact ឱ្យ “ចាស់” សុទ្ធតែជាការវិនិច្ឆ័យជាក់លាក់តាម domain។ Memory system សម្រាប់ customer-support agent មួយ និងមួយសម្រាប់ code agent មិនយល់ស្របគ្នាអំពីទាំងបី ហើយមានតែអ្នកដែលយល់ domain អាច specify ពួកវា។

ហេតុអ្វីនេះអនុគ្រោះអាស៊ីអាគ្នេយ៍

នេះជាផ្នែកដែលសំខាន់សម្រាប់តំបន់នេះ ហើយវាជារូបរាងដ៏ស៊ាំ។ ការរចនា memory របស់ agent — hierarchy របស់វា, logic retrieval របស់វា, ច្បាប់ invalidation របស់វា — ជា ការវិនិច្ឆ័យ systems engineering សុទ្ធ។ វាមិនចំណាយ GPU ទេ និងគ្មាន frontier model វាចំណាយការគិតយ៉ាងប្រុងប្រយ័ត្នអំពីអ្វីដែល agent ត្រូវរក្សា ទៅយក និងបោះចោល។ នោះជាវិន័យ laptop ហើយវាពិតជាប្រភេទនៃសមត្ថភាពដ៏ស្ថិតស្ថេរ ស្រាល-ដើមទុនដែលយើងបន្តអះអាងថាតំបន់គួរសាងសង់ — GPU-free leverage ដូចគ្នានឹង loop និងការងារ context ដែលវាអង្គុយក្បែរ។

ហើយ domain-specificity ជាប្រៀបធៀប មិនមែនបន្ទុក។ គ្មាន memory system ចេញពីធ្នើសម្រាប់ legal-document agent ភាសាខ្មែរ workflow compliance របស់ធនាគារកម្ពុជា ឬ logistics coordinator ខេត្ត — ព្រោះអ្វីដែលពាក់ព័ន្ធ និងអ្វីដែលចាស់ក្នុង domain ទាំងនោះអាច specify បានតែដោយមនុស្សនៅខាងក្នុង។ ក្រុមមួយដែលធ្វើ memory ត្រូវសម្រាប់បញ្ហាខ្លួនឯងសាងសង់អ្វីដែល frontier lab គ្មាន incentive និងគ្មានសមត្ថភាព replicate។ Vendor model នឹងបន្តពង្រីក context window ហើយហៅវាថា memory។ ក្រុមដែលយល់ថាវាគ្រាន់តែជា L1 cache — ហើយ engineer memory system ពិតប្រាកដជុំវិញវា — ជាក្រុមដែល agent របស់ពួកគេនឹងនៅតែគួរទុកចិត្តមួយពាន់ turn ពីឥឡូវ។