เปเปอร์วัดว่า "ความจำ" ของเอเจนต์รอดจากการอัปเกรดโมเดลไหม — โน้ตที่โมเดลเขียนเองร่วง 13.3 จุดเมื่อสลับผู้เขียน ส่วน knowledge graph สคีมาตายตัวขยับแค่ 0.0004 จุด

ทีมที่ทำเอเจนต์เจอสถานการณ์นี้เกือบทุกไตรมาส: โมเดลใหม่ออก ราคาถูกลง เร็วขึ้น เก่งขึ้น เราก็สลับ model= ในคอนฟิกแล้วดีพลอย ส่วน “ความจำ” ของเอเจนต์ — โน้ตสรุปที่โมเดลเก่าเขียนไว้ ดัชนีเวกเตอร์ที่สะสมมาหลายเดือน — ยังอยู่ที่เดิม ไม่มีใครย้าย เพราะการสร้างใหม่ทั้งหมดแพงและบางทีต้นฉบับก็ไม่เหลือแล้ว

เปเปอร์ arXiv:2609.05339 ที่ Ankit Goyal และ Jaideep Ray (ทั้งคู่ใช้อีเมล @linkedin.com) ส่งเมื่อ 4 ก.ย. 2026 ในหมวด cs.AI ตั้งคำถามที่ตรงไปตรงมามากว่า ตอนนั้นเอเจนต์ “ลืม” หรือเปล่า และคำตอบคือ ลืม — แบบเงียบ ๆ ไม่มี exception ไม่มี migration error ฐานข้อมูลยังคืนผลลัพธ์เหมือนเดิม แค่คะแนนตก

สี่ฟอร์แมตความจำ แยกคนเขียนออกจากคนอ่าน

การออกแบบการทดลองคือส่วนที่ทำให้เปเปอร์นี้น่าเชื่อกว่าเปเปอร์ agent-memory ทั่วไป คณะผู้เขียนแยกบทบาทออกเป็นสี่ส่วน — actor สร้างประสบการณ์, writer แปลงเป็นความจำถาวร, reader เอาความจำมาตอบคำถามทีหลัง, embedder ทำเวกเตอร์เสิร์ช — แล้วเปลี่ยนทีละตัวเท่านั้น

ประวัติเดียวกันถูกเก็บสี่แบบ:

• LC-RAW — เก็บทั้งประวัติดิบไว้อ่านผ่านคอนเท็กซ์ยาว
• RAG — หั่นเป็น chunk เก็บเวกเตอร์ ค้นทีละคำถาม
• NOTES — ให้โมเดลบีบเป็นโน้ตภาษาธรรมชาติ
• KG-fixed — บังคับให้เป็น subject–predicate–object ตามสคีมาที่ทุกโมเดลใช้ร่วมกัน

ข้อมูลทดสอบเป็น ประวัติสังเคราะห์ 48 ชุด ชุดละ 160 คำถาม ที่ฝัง “รหัสคำตอบ” แบบสุ่ม ครอบคลุมข้อเท็จจริงตรง ๆ การเปลี่ยนแปลงตามเวลา ข้อขัดแย้ง ความสัมพันธ์หลายขั้น และชื่อพ้อง เหตุผลที่ใช้ข้อมูลสังเคราะห์แทนบทสนทนาจริงคือ รหัสสุ่มทำให้โมเดลเดาจาก pretraining ไม่ได้ ความแม่นแบบเดาสุ่มจึงเท่ากับศูนย์ และการให้คะแนนเป็นการเทียบรหัสแบบตรงตัว ไม่ต้องใช้ LLM judge เลย — ซึ่งตัดตัวแปรกวนที่ทำให้เปเปอร์สาย agent memory ส่วนใหญ่เถียงกันไม่จบ

โมเดลที่ใช้เป็นโมเดลน้ำหนักเปิดต่ำกว่า 10B สองตัวที่ขนาดใกล้กัน: Llama-3.1-8B-Instruct กับ Qwen2.5-7B-Instruct-1M เสิร์ฟเองในเครื่อง อ่านแบบ deterministic เขียนที่อุณหภูมิต่ำพร้อม seed คงที่ (การอ่านซ้ำต่างกันแค่ 0.0016) และก่อนเก็บข้อมูลจริง ทีมล็อกแผนวิเคราะห์ไว้ใน Git tag ที่เซ็นชื่อชื่อ hypothesis-lock-v1 ระบุสมมติฐานสี่ข้อ ทิศทางที่คาดไว้ และเกณฑ์ห้าจุด เพื่อให้คนอื่นตรวจได้ว่าไม่ได้ไปแก้ทีหลัง

ผลหลัก: สคีมาตายตัวย้ายได้ โน้ตย้ายไม่ได้

ตารางกลางของเปเปอร์วัด “ความแม่นเมื่ออ่านคลังที่โมเดลอื่นเขียน” เทียบกับ “ความแม่นเมื่ออ่านคลังที่ตัวเองเขียน” โดยตรึง reader ไว้:

ฟอร์แมต	reader	อ่านคลังตัวเอง	อ่านคลังที่รับมา	ต่าง (จุด)
NOTES	Llama	0.3762	0.4753	+9.91
NOTES	Qwen	0.4719	0.3391	−13.28
KG-fixed	Llama	0.8456	0.8445	−0.11
KG-fixed	Qwen	0.9878	0.9880	+0.02

KG-fixed แทบไม่ขยับ (ค่าเฉลี่ยสมมาตร +0.0004 ± 0.0020) เพราะสคีมาที่แชร์กันทำให้ผู้อ่านคนใหม่ตีความเรกคอร์ดเดิมได้เหมือนเดิม ส่วน NOTES ผูกกับผู้เขียนอย่างรุนแรง

แต่ต้องอ่านเครื่องหมายให้ดี ตัวเลข ไม่ได้แปลว่า “โน้ตทำให้แย่ลงเสมอ” — Llama อ่านโน้ตของ Qwen แล้ว ดีขึ้น 9.9 จุด ส่วน Qwen อ่านโน้ตของ Llama แล้ว แย่ลง 13.3 จุด ความไม่สมมาตรนี้สะท้อนคุณภาพของ ผู้เขียน มากกว่าคุณสมบัติของฟอร์แมต และเปเปอร์มีหลักฐานตรงจากขั้น calibration: โน้ตของ Qwen เก็บช่วงหลักฐานที่จำเป็นไว้ 85.6% ที่ขนาด 143 KiB ขณะที่ Llama เก็บได้แค่ 64.5% ทั้งที่ใช้พื้นที่ 159 KiB มากกว่าด้วยซ้ำ (เกณฑ์ evidence coverage ที่ตั้งไว้แต่แรกคือ 90% แต่ NOTES ทำไม่ถึง ทีมจึงลดเหลือ 60% แล้วบันทึกการเปลี่ยนไว้ — เป็นความโปร่งใสที่ควรชม)

กฎที่ใช้ได้จริงจึงเป็น: ทดสอบทีละทิศทาง writer→reader และถือว่าคุณภาพของโมเดลที่เขียนโน้ตเป็นส่วนหนึ่งของสถาปัตยกรรมความจำ ไม่ใช่รายละเอียดที่เปลี่ยนได้ฟรี

การอัปเกรดโมเดลฝังแบบครึ่ง ๆ กลาง ๆ คือกับดักที่เงียบที่สุด

ส่วนที่ผมคิดว่ามีค่าที่สุดสำหรับคนทำระบบจริงคือการทดลองเปลี่ยน embedder จาก BAAI/bge-large-en v1.0 เป็น v1.5 — สองรุ่นนี้ให้เวกเตอร์ 1024 มิติเท่ากัน เวกเตอร์เก่ากับใหม่จึงอยู่ในดัชนีเดียวกันได้โดยไม่เกิด dimension error ทั้งที่มันคนละสเปซกัน ระบบยังทำงานปกติทุกอย่าง แค่ recall ค่อย ๆ แย่ลง

ดัชนี	ความแม่น	เทียบดัชนีเก่า	recall@k	MRR
ดัชนีเก่า (v1.0)	0.4257	—	0.4846	0.3237
re-embed ใหม่ทั้งหมด	0.5447	+11.90	0.5998	0.4068
ผสม 50/50	0.4753	+4.96	0.5208	0.3643
routing ในอุดมคติ (เพดาน)	0.5960	+17.03	0.6505	0.4390

การผสมเวกเตอร์เก่ากับใหม่ในดัชนีเดียว ทิ้งกำไรจากการอัปเกรดไปเกือบ 60% โดยไม่มีสัญญาณเตือนใด ๆ คำแนะนำของเปเปอร์ตรงไปตรงมา: สร้างดัชนีใหม่แยกให้เสร็จก่อนแล้วค่อย cut over ถ้าจำเป็นต้องทยอยจริง ๆ ก็ต้องแยกสเปซและ route คำถามตามเวอร์ชันของดัชนีที่รู้แน่ชัด

อีกผลที่ควรจำคือ ลำดับการดีบัก เมื่อเอเจนต์ที่เพิ่งอัปเกรดตอบผิด คนส่วนใหญ่โทษ reader ตัวใหม่ก่อน แต่การแยกส่วนของเปเปอร์บอกว่าความสูญเสียเกิดต้นน้ำ — สำหรับ NOTES 80% ของส่วนต่างมาจากขั้นเขียน (0.467 ± 0.014 จากทั้งหมด 0.584 ± 0.013) ส่วนการค้นภายในโน้ตมีแค่ 6%; สำหรับ RAG กลับด้าน 81% มาจากขั้นค้นคืน (0.364 ± 0.012 จาก 0.450 ± 0.012) ขณะที่ chunk ที่เก็บไว้แทบไม่สูญเสียข้อมูลเลย พูดง่าย ๆ คือ NOTES ต้องไปแก้ที่การสรุป RAG ต้องไปแก้ที่ chunking/indexing/ranking และการเปลี่ยน reader เป็นสิ่งสุดท้ายที่ควรทำ

ซ่อมได้ก็ต่อเมื่อยังเก็บต้นฉบับ — และโมเดลซ่อมทำงานจนจบ

การทดสอบสุดท้ายคือ ถ้าคลังเสียแล้วซ่อมได้ไหม ผลคือ การเขียนโน้ตใหม่จากตัวคลังเองไม่เคยแตะเป้า 90% ของประสิทธิภาพเดิมเลยสักเคสจาก 48 เคส ที่งบใดก็ตาม เพราะสิ่งที่ผู้เขียนคนแรกตัดทิ้งไปแล้วสร้างกลับมาไม่ได้

พอเก็บประวัติดิบไว้ด้วย การซ่อมดีขึ้น 8.9 จุดโดยเฉลี่ย แต่ตัวเลขรวมนี้ซ่อนความจริงที่สำคัญกว่า: Qwen ซ่อมสำเร็จ 34 จาก 48 เคส ที่ต้นทุนกลาง ~$0.76 ต่อเคส ขณะที่ Llama ซ่อมสำเร็จศูนย์เคส เพราะทุกครั้งชนเพดานโทเคนขาออกก่อนทำงานเสร็จ — ไม่ใช่เพราะฉลาดน้อยกว่าเสมอไป แต่เพราะข้อจำกัดทรัพยากร ซึ่งเปเปอร์ระบุเองว่าตัวแปร “โมเดลซ่อม” กับ “ทิศทางการย้าย” เปลี่ยนไปพร้อมกัน จึงไม่ใช่การเทียบความสามารถที่สะอาด ในทางกลับกัน การซ่อมข้อมูลที่มีโครงสร้างถูกและแน่นอนกว่ามาก — re-embed RAG กู้ได้ครบ 96/96 เคสที่ ~$0.013 ต่อเคส และสร้าง KG-fixed ใหม่กู้ได้ 91–96 จาก 96 ที่ต้นทุนเกือบเป็นศูนย์

เชิงอรรถที่เปเปอร์เขียนเอง และควรอ่านก่อนเอาไปอ้าง

เครดิตต้องให้ตรงนี้: หัวข้อ “Scope and limits” เขียนข้อจำกัดไว้ตรงกว่าเปเปอร์ส่วนใหญ่ และมีอย่างน้อยสามข้อที่เปลี่ยนวิธีอ่านผลลัพธ์

หนึ่ง — การเทียบ NOTES กับ KG-fixed ไม่ได้เทียบเฉพาะฟอร์แมต ทีมจำกัด NOTES ไว้ที่ 128 KiB (ส่งถึง reader จริงราว 111 KiB) ขณะที่ reader ฝั่ง KG-fixed คิวรีคลังที่มีโครงสร้างซึ่ง ใหญ่กว่า ผลต่าง 0.34 กับ 0.99 จึงสะท้อนทั้งฟอร์แมตและวิธีเข้าถึงข้อมูล ไม่ใช่ฟอร์แมตล้วน ๆ เปเปอร์เขียนประโยคนี้ไว้เอง แต่มันหายไปทันทีเมื่อสรุปเป็นพาดหัวว่า “knowledge graph ชนะ”

สอง — อัตราค้นคืนพลาด 40% ของ RAG เป็นสมบัติของไปป์ไลน์ที่เลือกทดสอบ ไม่ใช่ของ RAG ทีมตั้งใจใช้ dense retriever ขั้นเดียว chunk ตามอีเวนต์ cosine top-k=8 ไม่มี reranker ไม่มี lexical search ซึ่งเป็นการตั้งค่าที่ตั้งใจให้เรียบง่ายเพื่อวัดผลกระทบให้ชัด แต่ทีมที่ทำ RAG ระดับโปรดักชันในปี 2026 แทบไม่มีใครรันแบบนี้แล้ว ตัวเลข 0.535–0.565 จึงอ่านเป็นเส้นฐานที่ต่ำโดยการออกแบบ

สาม — ทุกอย่างวัดจากโมเดลสองตัวขนาดใกล้กัน หนึ่งคู่ครอบครัว บนประวัติสังเคราะห์ที่ใส่ในคอนเท็กซ์ทั้งสองตัวได้สบาย เปเปอร์ระบุเองว่านี่คือการประเมิน “การย้ายข้ามครอบครัวหนึ่งกรณี ไม่ใช่ตัวอย่างของการอัปเกรดโมเดลทั้งหมด” และการอัปเกรดที่คนทำจริงส่วนใหญ่ (เช่น 8B → โมเดลแนวหน้าที่ใหญ่กว่ามาก) ไม่ได้อยู่ในการทดลองนี้เลย นอกจากนี้ผู้เขียนยังยอมรับว่า hypothesis-lock-v1 เป็น “internal analysis lock” ไม่ใช่ preregistration เต็มรูปแบบ และรัน bootstrap หลัง t-test แม้จะได้ข้อสรุปเดียวกัน

และตามธรรมเนียม: นี่คือ preprint ยังไม่ผ่าน peer review

มุมมอง AI Curator

สิ่งที่เปเปอร์นี้ทำได้ดีที่สุดไม่ใช่ตารางคะแนน แต่คือการเปลี่ยนคำถามจาก “ฟอร์แมตความจำไหนดีที่สุด” เป็น “ฟอร์แมตไหนยังใช้ได้เมื่อชิ้นส่วนรอบตัวมันเปลี่ยน” ซึ่งเป็นคำถามคนละข้อ และเป็นข้อที่ตรงกับความเป็นจริงของทีมที่ต้องดูแลระบบไปอีกสองปีมากกว่า คลังความจำมีอายุเป็นเดือนเป็นปี ส่วนโมเดลรอบตัวมันเปลี่ยนทุกไตรมาส — ตัวเลือกที่ชนะในวันเปิดตัวจึงอาจเป็นตัวเลือกที่แย่ที่สุดในระยะยาว

ข้อสรุปที่ผมคิดว่าเอาไปใช้ได้ทันทีโดยไม่ต้องรอ peer review มีสองข้อ และทั้งคู่แทบไม่ต้องแลกอะไรเลย ข้อแรกคือ ห้ามผสมเวกเตอร์จากโมเดลฝังคนละรุ่นในดัชนีเดียว — นี่ไม่ใช่ผลการทดลองที่ต้องเถียงกัน มันเป็นคุณสมบัติทางเรขาคณิตของสเปซเวกเตอร์ที่ตัวเลข 4.96 จาก 11.90 แค่มายืนยัน และความอันตรายอยู่ที่มันไม่พังแบบมี error ให้เห็น ทีมที่ทยอยอัปเกรด embedder ทีละส่วนเพื่อ “ลดความเสี่ยง” กำลังสร้างความเสี่ยงที่ตรวจไม่เจอแทน ข้อสองคือ เก็บประวัติดิบไว้ถ้านโยบายอนุญาต เพราะโน้ตที่บีบแล้วซ่อมตัวเองไม่ได้ — แต่ต้องพูดให้ครบว่าเปเปอร์เตือนเองว่าการเก็บประวัติดิบสร้างภาระด้านความเป็นส่วนตัว ความปลอดภัย และกำหนดการลบข้อมูล ซึ่งสำหรับทีมไทยที่อยู่ใต้ PDPA ไม่ใช่เชิงอรรถเล็ก ๆ แต่เป็นเงื่อนไขที่ต้องออกแบบตั้งแต่ต้น (เข้ารหัส จำกัดสิทธิ์เข้าถึง มีตารางลบชัดเจน)

ส่วนข้อสรุป “KG-fixed ชนะ” ผมจะยังไม่รีบเชื่อ ไม่ใช่เพราะตัวเลขน่าสงสัย แต่เพราะเงื่อนไขที่ทำให้มันชนะถูกระบุไว้ชัด ๆ ในเปเปอร์เอง — สคีมาต้องแทนงานได้ครบ และงานทดสอบเป็นข้อเท็จจริงที่ normalize ลงเป็น triple ได้พอดี ซึ่งเป็นกรณีที่เอื้อกับ KG มากที่สุดเท่าที่จะเป็นไปได้ ความจำของผู้ช่วยงานจริงเต็มไปด้วยความชอบที่คลุมเครือ เหตุผลเบื้องหลังการตัดสินใจ และบริบทที่ไม่มีสคีมาไหนออกแบบรอไว้ก่อนได้ สิ่งที่ผลนี้พิสูจน์จริง ๆ จึงไม่ใช่ “ใช้ KG สิ” แต่คือ “ส่วนไหนของความจำที่ normalize ลงสคีมาที่แชร์กันได้ ให้ย้ายไปอยู่ตรงนั้น” — แล้วยอมรับว่าส่วนที่เหลือจะผูกกับโมเดลที่เขียนมันเสมอ และต้องมีเทสต์ทิศทาง writer→reader คอยจับตอนอัปเกรด

สำหรับทีมไทยที่กำลังต่อเอเจนต์เข้ากับงานจริง บทเรียนที่ปฏิบัติได้เลยคือ เพิ่ม “memory migration test” เข้าไปใน CI เหมือนที่เรามี regression test — ชุดคำถามเล็ก ๆ ที่รู้คำตอบแน่นอน รันซ้ำทุกครั้งที่เปลี่ยนโมเดลหลักหรือโมเดลฝัง ต้นทุนแทบเป็นศูนย์ และเป็นวิธีเดียวที่จะจับความล้มเหลวชนิดที่ไม่ส่ง exception มาให้เห็น

แหล่งข่าว

• Does Your Agent’s Memory Survive a Model Upgrade? A Controlled Study of Memory Portability — arXiv:2609.05339
• PDF ฉบับเต็ม (arXiv)
• BAAI/bge-large-en-v1.5 บน Hugging Face (โมเดลฝังที่ใช้ทดลอง)