Memory Consolidation: ย่อความจำ Agent โดยรักษาหลักฐาน

คำตอบโดยตรง: Memory Consolidation ในบทความนี้หมายถึงการจัดระเบียบความจำภายนอกของ AI Agent ให้ใช้ต่อได้ภายใต้งบข้อมูลที่จำกัด เช่น เปลี่ยนบันทึกเหตุการณ์เป็นบทสรุปหรือข้อเท็จจริงที่ค้นคืนได้ คุณภาพไม่ได้วัดจากความสั้นเพียงอย่างเดียว ต้องตรวจว่าข้อมูลใหม่ยังรักษาคำตอบ เงื่อนไข ข้อยกเว้น ความไม่แน่นอน และทางกลับไปดูหลักฐานเดิมได้หรือไม่ การอัปเดตข้อมูลเหล่านี้ไม่เท่ากับการฝึกน้ำหนักโมเดล

Agent อาจอ่านความจำที่ย่อแล้วผ่าน context ของโมเดล และให้คำตอบต่างจากเดิมทั้งที่น้ำหนักโมเดลคงเดิม บทความนี้แยกกลไกที่มีงานวิจัยรองรับออกจากสถาปัตยกรรมที่เสนอ พร้อม Interactive และเกม SIMULATION เพื่อทดลองว่าเมื่อพื้นที่จำมีจำกัด ควรเก็บอะไรเพื่อช่วยงานถัดไป

กฎจัดส่งสมมติทั่วไปสามวันแต่เกาะเจ็ดวัน แยกไปเป็นสรุปที่ทำข้อยกเว้นหาย กับ structured record ที่เก็บค่าเกาะและ source E1 — **Memory Consolidation: อย่าย่อเงื่อนไขสำคัญทิ้ง** — SIMULATION / กฎจัดส่งสมมติมีระยะทั่วไป 3 วัน แต่เกาะ 7 วัน การสรุปเป็น “จัดส่ง 3 วัน” ทำข้อยกเว้นหาย แม้มี source ID ส่วน record ที่เก็บ default และ qualifier สามารถตอบกฎตัวอย่างนี้ได้ตรงต้นทาง โดยการ extraction, schema และ retrieval ยังผิดได้ ภาพปกบทความเชิงอธิบาย ภาพ Hook Facebook จัดทำแยก · แหล่งแนวคิด 1 · แหล่งแนวคิด 2

ทำไมความจำที่สั้นลงอาจทำให้คำตอบผิดขึ้น

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

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

สำหรับผู้พัฒนา Agent คำถามสำคัญคือ “หลังจัดระเบียบแล้ว ระบบยังทำงานที่ต้องทำได้หรือไม่” งานถามเวลา สถานที่ ข้อยกเว้น หรือที่มาของคำตอบใช้ข้อมูลคนละชนิด เราจึงต้องกำหนดงานปลายทางและชุดคำถามตรวจรับตั้งแต่ก่อนเลือกวิธีย่อ ความจำที่เหมาะกับการเล่าเรื่องภาพรวมอาจไม่เหมาะกับการตรวจเอกสารหรือการติดตามสถานะที่เปลี่ยนไป

แยกความจำสี่ชั้น ก่อนออกแบบการรวมข้อมูล

Context Window: ข้อมูลที่โมเดลอ่านในคำขอปัจจุบัน

Context Window เป็นขอบเขตของข้อมูลที่ใส่ในคำขอหนึ่งครั้ง ไม่ใช่คำรับรองว่าโมเดลใช้ทุกส่วนได้ดีเท่ากัน งาน Lost in the Middle ซึ่งตีพิมพ์ใน TACL ปี 2024 ทดลองงานตอบคำถามและค้นคู่ key–value พบความไวต่อตำแหน่งข้อมูลในบริบทภายใต้โมเดลและเงื่อนไขที่ศึกษา ผลนี้เป็นหลักฐานเฉพาะชุดทดลอง ไม่ใช่ข้อสรุปว่าทุกโมเดลปัจจุบันมีรูปแบบความผิดพลาดเหมือนกัน Lost in the Middle

Retrieved Context: ส่วนที่ระบบค้นแล้วเลือกส่งให้โมเดล

ระบบอาจเก็บเอกสารจำนวนมาก แต่ส่งให้โมเดลเพียงไม่กี่ชิ้น ปัญหามีอย่างน้อยสองด่าน: ข้อมูลสำคัญอาจไม่ได้ถูกเลือก หรือถูกเลือกแล้วแต่โมเดลใช้ไม่ถูก การเพิ่ม context จึงไม่แทนการตรวจ retrieval และการรักษาหลักฐาน ถ้าข้อยกเว้นถูกลบตั้งแต่ก่อนเก็บ การค้นคืนที่ดีขึ้นก็ไม่สามารถสร้างข้อยกเว้นนั้นกลับมาโดยอัตโนมัติ

External Memory: ข้อมูลที่คงอยู่ภายนอกโมเดล

ไฟล์ ฐานข้อมูล บันทึกเหตุการณ์ ดัชนีค้นหา และ structured records เป็นตัวอย่างความจำภายนอก แต่ละระบบต้องระบุว่าบันทึกจริงอยู่ที่ไหน อ่านกลับได้อย่างไร และใครมีสิทธิ์ใช้ การเขียนข้อความว่า “จำไว้แล้ว” ในคำตอบไม่ใช่หลักฐานว่าข้อมูลถูกบันทึกข้ามรอบ งาน MemGPT ใช้การจัดการข้อมูลระหว่างบริบทกับพื้นที่เก็บภายนอก โดยมี recall storage สำหรับข้อความที่ถูกนำออกจากบริบทและ recursive summary ช่วยรักษาบริบทภาพรวม MemGPT v2

Model Weight Updates: เปลี่ยนพารามิเตอร์ด้วยขั้นฝึกที่ระบุได้

การแก้บันทึกหรือเพิ่ม summary เปลี่ยนข้อมูลที่ Agent อาจอ่าน ไม่ได้พิสูจน์ว่าพารามิเตอร์โมเดลเปลี่ยน หากระบบมี fine-tuning หรือ online learning ต้องตรวจข้อมูลฝึก เป้าหมาย และ update rule แยกต่างหาก คำว่า consolidation ในบทความนี้เป็นกรอบเชิงวิศวกรรมสำหรับข้อมูลภายนอก ไม่ใช่หลักฐานว่าระบบทำงานเทียบเท่าความจำของสมองมนุษย์

งานวิจัยบอกอะไรเกี่ยวกับการย่อและการค้นกลับ

MemGPT — จัดชั้นความจำและรักษาทางค้นข้อมูลเดิม: งานฉบับ arXiv v2 วันที่ 12 กุมภาพันธ์ 2024 อธิบายการย้ายข้อมูลออกจากบริบทและเรียกคืนจากพื้นที่ภายนอก ประเด็นที่นำมาใช้ได้คือการแยกข้อความสรุปที่ใช้เฉพาะหน้าออกจากข้อมูลต้นทางที่ยังค้นได้ การมี summary ไม่ได้บังคับให้ลบทิ้งข้อความเดิม และความสำเร็จของระบบทดลองไม่ได้รับรองทุกนโยบายการสรุปที่ผู้พัฒนาจะสร้างขึ้น MemGPT

Generative Agents — Reflection เป็นข้อความอนุมานระดับสูง: งาน UIST 2023 ใช้ memory stream และสร้าง reflections ที่อ้างอิงรายการความจำเป็นหลักฐาน แนวคิดนี้ช่วยแยกเหตุการณ์ที่พบออกจากข้อสรุปเกี่ยวกับเหตุการณ์ แต่ข้อสรุปที่มี source IDs ก็ยังอาจตีความหลักฐานผิด งานรายงานข้อผิดพลาดในการค้นความจำและการแต่งเติมพฤติกรรมด้วย จึงไม่ควรใช้ reflection เป็นเครื่องตรวจความจริงที่รับรองตัวเอง Generative Agents

ReadAgent — ใช้ gist เป็นทางนำกลับสู่หน้าต้นฉบับ: preprint arXiv v3 วันที่ 22 กรกฎาคม 2024 ใช้ข้อความย่อระดับหน้าและกลไก look-up กลับไปอ่านส่วนต้นฉบับ แนวทางนี้สอดคล้องกับการให้ summary ทำหน้าที่เป็นแผนที่ค้นหา เมื่อต้องตอบรายละเอียดให้กลับไปดูหลักฐาน งานประเมินบนชุดงานและโมเดลที่กำหนด สถานะการตีพิมพ์ในประชุมหลักยังไม่ยืนยันในรอบวิจัยนี้ จึงใช้สถานะ preprint ReadAgent

งาน LLMLingua ที่ EMNLP 2023 เป็นอีกกลุ่มหนึ่งซึ่งศึกษาการบีบอัด prompt เพื่อช่วยประมวลผลข้อความ ต้องแยกจากการรวมประสบการณ์ของ Agent เป็นคลังความจำระยะยาว การลด token ใน prompt ไม่ได้ตอบโดยลำพังว่าข้อยกเว้น แหล่งที่มา และความเปลี่ยนแปลงของข้อมูลยังถูกเก็บครบหรือไม่ บทความนี้ไม่ได้รัน benchmark ของงานใดซ้ำ จึงไม่รายงานตัวเลขใหม่หรือรับรองประสิทธิภาพจากการทำซ้ำอิสระ LLMLingua

สถาปัตยกรรมที่เสนอ: ย่อเป็นผู้สมัคร แล้วตรวจรับก่อนเก็บ

ผังต่อไปเป็น Conceptual Architecture / HYPOTHESIS ของผู้เขียนสำหรับ Agent ที่ใช้ความจำภายนอก ไม่ใช่แผนภาพถอดจากระบบวิจัยใดระบบหนึ่ง และยังไม่ใช่ระบบ production ที่ผ่านการทดสอบครบ แนวคิดคือไม่เขียน summary ทับความจำหลักทันที แต่สร้าง candidate ที่ตรวจเทียบต้นทางและงานปลายทางได้

ผังจาก Ingest Source Log ไป Candidate Builder Check Conflict Task-based Evaluator Commit Version และ External Memory ก่อน retrieval เข้าสู่ Model Context พร้อม Log Retention Policy — **Conceptual Memory Consolidation Architecture: Source ถึง Versioned Memory** — HYPOTHESIS / สถาปัตยกรรมเพื่อการศึกษา: ingest เก็บ event/source IDs สร้าง candidate summary หรือ structured facts ตรวจ qualifiers provenance และ conflict ประเมิน downstream tasks แล้วจึง commit/version หรือ reject การค้นคืนดึงส่วนที่เกี่ยวข้องเข้าสู่ model context ส่วน original log มี retention/access policy การอัปเดต external memory ในผังไม่เปลี่ยน model weights และไม่ใช่รายละเอียดของทุก Agent · แหล่งแนวคิด 1 · แหล่งแนวคิด 2 · แหล่งแนวคิด 3

Module	หน้าที่และ Input → Output	โครงสร้างข้อมูลและจุดตรวจ	Failure Mode
Evidence Store	รับเหตุการณ์และแหล่งอ้างอิง → บันทึกที่ค้นกลับได้	event_id, source, ข้อความ, เวลารับ; ตรวจ ID และการอ่านกลับ	ต้นทางหาย ลิงก์เสีย หรือเก็บผิดขอบเขต
Candidate Builder	รับเหตุการณ์ งบ และชนิดงาน → summary หรือ facts ที่เสนอ	candidate_id, assertions, source_ids, qualifiers; แยกข้ออนุมาน	ตัดคำปฏิเสธ รวมคนละเหตุการณ์ หรือสร้างข้อเท็จจริงเอง
Consistency Checker	รับ candidate กับหลักฐาน → รายการข้อผิดพลาดและข้อขัดกัน	ตรวจ schema, source ที่มีจริง, การแก้ไขและความไม่แน่นอน	มี source จริงแต่ไม่รองรับ assertion; verifier ตีความผิด
Retention Evaluator	รับ candidate กับชุดคำถาม → ผลตอบและเหตุผล	answer, evidence_ids, supported/unsupported, งบที่ใช้	ชุดทดสอบง่ายเกินไปหรือเลือกเฉพาะคำถามที่ summary ตอบได้
Commit and Retrieval	รับ candidate ที่ผ่าน → เวอร์ชันความจำที่ค้นใช้ได้	version, accepted_at, source pointers, retrieval trace	เขียนทับก่อนตรวจ ส่งเวอร์ชันเก่าให้โมเดล หรือย้อนตรวจไม่ได้

ข้อเท็จจริงหนึ่งรายการอาจมี entity, predicate, value, qualifier, status และ source_ids เช่น ข้อมูลสถานที่ต้องแยก “เสนอไว้” ออกจาก “ยืนยันแล้ว” ข้อมูลที่ไม่ทราบควรมีสถานะ unknown แทนการใส่ค่าที่ดูสมบูรณ์ โครงสร้างนี้ช่วยตรวจรูปแบบและค้นย้อนกลับ แต่ไม่ได้ทำให้ assertion กลายเป็นความจริงเพียงเพราะเก็บไว้ในตาราง

การตรวจว่า source ID มีอยู่เป็นงานที่โปรแกรมทำได้ชัดเจน ส่วนการตรวจว่าประโยคหนึ่งรองรับข้อสรุปอย่างไรเป็นงานด้านความหมาย หากใช้ LLM เป็นผู้ตรวจ ยังต้องประเมินความผิดพลาดของผู้ตรวจเอง การให้โมเดลตัวเดิมอ่านผลสรุปของตัวเองอีกครั้งไม่ถือว่าได้หลักฐานอิสระเพิ่มโดยอัตโนมัติ

ข้อมูลไหลอย่างไร และควรตรวจตรงจุดไหน

รับเหตุการณ์: บันทึกข้อความพร้อม source ID ก่อนเปลี่ยนรูปแบบ เก็บสถานะคำพูด เช่น ยืนยัน มีเงื่อนไข หรือยังไม่ทราบไว้ให้ตรวจ
สร้าง candidate: เลือกสิ่งที่จำเป็นต่อชนิดงาน หลีกเลี่ยงการรวม assertions ที่ขัดกันเป็นประโยคเดียว และระบุข้ออนุมานแยกจากเหตุการณ์
ทดสอบการรักษาข้อมูล: ถามเรื่องค่าปัจจุบัน ข้อยกเว้น และแหล่งที่มา เทียบกับหลักฐานที่ใช้สร้าง candidate รวมคำถามที่จงใจต้องตอบ unknown
ตัดสินใจเก็บ: รับ candidate เมื่อผ่านเงื่อนไขของงาน หากไม่ผ่านให้เก็บหลักฐานดิบไว้ เพิ่มงบ หรือปรับ representation ไม่ทำให้ candidate ที่ผิดกลายเป็นความจำหลัก
ค้นและประเมินรอบใช้จริง: เก็บร่องรอยว่า Agent อ่าน summary หรือหลักฐานชิ้นใด คำตอบผิดอาจเกิดในขั้นสรุป ค้นคืน หรือใช้เหตุผล ต้องตรวจแยกแต่ละขั้น

หกขั้นตอนอ่าน Source E1 สร้าง Candidate ถามเกาะกี่วัน ตรวจพบคำตอบสามวันผิด สร้างใหม่ที่เก็บเกาะเจ็ดวันกับ source แล้ว commit หลังผ่าน probe นี้ — **ตรวจข้อยกเว้นที่หายด้วย Future-task Probe ก่อน Commit** — SIMULATION / ขั้นตอนกำหนดตายตัว: source E1 ระบุเกาะ 7 วัน candidate A สรุปเหลือ 3 วัน exception probe ตรวจพบคำตอบไม่ตรงต้นทาง จึง reject และสร้าง candidate B ที่เก็บ qualifier กับ E1 แล้วตอบ probe เดิม 7 วันจึง commit ผ่านเพียง probe นี้ การมี source ID ไม่รับรองความหมายครบ และผลนี้ไม่ใช่การทดสอบ LLM หรือ benchmark memory consolidation จริง · แหล่งแนวคิด 1 · แหล่งแนวคิด 2

ตัวอย่าง pseudocode ต่อไปเป็น ตัวอย่างเชิงแนวคิด ไม่ใช่โค้ดที่ทดสอบแล้ว ส่วนโค้ดของ Lab ในบทความเป็น simulator อีกชุดหนึ่งที่ทดสอบแยกกัน

events = load_allowed_source_events()
candidate = propose_memory(events, budget, task_profile)
checks = check_sources_qualifiers_conflicts(candidate, events)
results = evaluate_supported_answers(candidate, held_out_questions)
if checks.accepted and results.meet_task_requirements:
    commit_new_version(candidate, source_pointers)
else:
    retain_previous_memory_and_record_rejection()

การเก็บต้นฉบับต้องมีนโยบายอายุข้อมูล การลบ และสิทธิ์ เมื่อเลือกจะลบ ต้องทราบว่าคำถามใดจะตอบหรืออธิบายที่มาไม่ได้อีก ระบบที่อ้างย้อนกลับได้ควรตรวจการอ่านต้นทางจริง

เปรียบเทียบสามวิธี: ไม่มีตัวแทนความจำที่ชนะทุกงาน

สามคอลัมน์เปรียบเทียบ Raw Episodic Log Lossy Summary และ Structured Provenance ด้านรายละเอียด การค้นคืน failure และงานที่เหมาะ โดยไม่จัดอันดับรับรองประสิทธิภาพ — **Raw Episodic Log, Lossy Summary และ Structured Memory พร้อม Provenance** — ANALYSIS / เปรียบเทียบ representation เชิงกลไก: raw log เก็บรายละเอียดแต่ค้นคืนผิดได้ summary อ่านกระชับแต่ย่อเงื่อนไขหายได้ structured memory ตรวจ fields ได้แต่ extraction/schema/conflict ผิดได้ ใช้ร่วมกันตามชนิดงานและนโยบายเก็บต้นทาง ไม่จัดอันดับที่รับรอง structured memory ชนะทุกกรณี ต้องประเมิน retrieval คำตอบ error latency และต้นทุนของงานปลายทาง · แหล่งแนวคิด 1 · แหล่งแนวคิด 2 · แหล่งแนวคิด 3

แนวทาง	สิ่งที่ได้	สิ่งที่แลก	เหมาะกับงานแบบใด
Raw Episodic Log	รักษาข้อความและลำดับเหตุการณ์ให้กลับไปตรวจ	ข้อมูลมาก ต้องค้นและแยกข้อมูลเก่า/ใหม่	ตรวจรายละเอียด หลักฐาน และประวัติที่ยังไม่ทราบคำถามล่วงหน้า
Lossy Summary	ภาพรวมอ่านเร็ว ใช้พื้นที่น้อยตามวิธีที่เลือก	อาจเสียข้อยกเว้น คำปฏิเสธ และแหล่งอ้างอิง	นำทางการอ่านหรือเตือนบริบท โดยยังมีทางค้นต้นฉบับ
Structured Facts with Provenance	ค้นค่ากับเงื่อนไขและ source pointers ได้เป็นช่อง	schema และ metadata ใช้พื้นที่; extraction อาจผิด	คำถามชนิดค่อนข้างคงที่และมีวิธีตรวจ assertions

Structured memory ไม่ได้เล็กกว่า raw log เสมอ ถ้าเพิ่ม source links เวอร์ชัน และสถานะให้ทุก assertion พื้นที่อาจมากขึ้น และหากรู้ว่าจะถามเรื่องใด การค้น raw evidence เฉพาะที่เกี่ยวข้องอาจใช้ข้อมูลน้อยกว่าส่ง structured records ครบชุด รูปแบบที่ดูเป็นระเบียบจึงต้องวัดกับงานปลายทางและต้นทุนจริง

Memory Consolidation ต่างจากการเลือกข้อความที่อนุญาตให้บันทึกตั้งแต่ต้น และต่างจากการเลือกเวลาของ record เมื่อมีการแก้ย้อนหลัง เรื่องนี้มุ่งตรวจว่าการเปลี่ยน representation ทำให้ข้อมูลที่ใช้ตอบงานถัดไปหายหรือไม่ ส่วนเงื่อนไขสองเวลาศึกษาต่อได้ใน Bitemporal Memory ของ AI Agent

Interactive: ทดลองงบความจำและนโยบายเลือกหลักฐาน

Lab ต่อไปเป็น SIMULATION ใช้เหตุการณ์สมมติ E1–E8 ของงานเวิร์กช็อป มีคำถามปลายทางสามข้อ: สถานที่ปัจจุบัน เวลาเริ่มล่าสุด และมีการรับรองว่าอาหารปลอดถั่วแล้วหรือยัง เหตุการณ์สำคัญคือ E3 ยืนยันฝนตกและใช้ห้องหลัก E5 เปลี่ยนเวลา 18:00 เป็น 17:30 และ E7 ระบุว่าผู้จัดอาหารยังรับรองเรื่องถั่วไม่ได้ สถานะสุดท้ายจึงเป็น unknown ไม่ใช่ข้อพิสูจน์ว่ามีหรือไม่มีถั่ว

รหัส E1 ในภาพกฎจัดส่งเป็นคนละชุดกับ E1–E8 ของเวิร์กช็อป ผู้ใช้เปลี่ยนงบและการเลือก raw log แบบเก็บล่าสุดก่อนหรือเลือกตามคำถาม แล้วดูข้อมูลที่ถูกเก็บและจำนวนคำตอบที่มีหลักฐานรองรับ หน่วยใน Lab เป็น หน่วยบันทึกสมมติ: raw event ใช้สองหน่วย ส่วน fact ที่มีเงื่อนไขและ source ใช้สามหน่วย ไม่ใช่ token, byte, ราคา หรือ latency ของโมเดลจริง

SIMULATIONข้อมูลสมมติ • อัลกอริทึมที่กำหนดไว้ • ไม่มี LLM

ทดลอง: บีบอัดความจำแล้วอะไรหาย?

อ่านบันทึกงานเวิร์กช็อป 8 เหตุการณ์ แล้วดูว่าความจำแต่ละแบบยังรองรับคำตอบ 3 ข้อได้กี่ข้อ: สถานที่ล่าสุด เวลาเริ่มล่าสุด และการรับรองอาหารปลอดถั่ว

งบความจำ (หน่วยระเบียนสมมติ)9นโยบายเก็บ raw log

Raw 1 event = 2 หน่วย • Fact พร้อมที่มา/เงื่อนไข = 3 หน่วย • สรุปทั้งชุด = 2 หน่วย หน่วยนี้ตั้งขึ้นเพื่อสาธิต ไม่ใช่ token, byte, latency หรือผล benchmark

Input: เปิดบันทึกต้นฉบับ E1–E8

State → Output: คำตอบที่มีหลักฐานอยู่จริง

เปิดกติกาวัดและคำตอบอ้างอิง

นับ 1 ข้อเมื่อความจำมีค่าถูกต้องพร้อม source ที่ตรงกับเหตุการณ์ยืนยันล่าสุด: venue = hall จาก E3, time = 17:30 จาก E5, nuts = unverified จาก E7 การตอบถูกโดยไม่มีหลักฐานไม่นับ การมี source อย่างเดียวไม่รับรองว่าแหล่งนั้นเป็นความจริงในโลกจริง

เลือกแบบตรงคำถามได้เพราะ SIMULATION นี้รู้คำถามทั้งสามล่วงหน้า จึงอย่าใช้ผลนี้สรุปความเหนือกว่าของ schema หรือระบบ retrieval จริง

นี่คือ external memory ใน session หน้าเว็บ ไม่เปลี่ยนน้ำหนักโมเดล ไม่จำลองการสรุปของ LLM และไม่รับประกันคำถามที่ไม่ได้เตรียมไว้

เมื่อรู้คำถามล่วงหน้า raw E3/E5/E7 ใช้หกหน่วยและรองรับสามคำตอบ ส่วน structured facts สามรายการใช้เก้าหน่วยตามกติกาที่ตั้งไว้ จึงเห็นได้ว่าการเพิ่มโครงสร้างมีต้นทุนจริงในแบบจำลอง ขณะเดียวกัน latest-first อาจใช้พื้นที่ไปกับเหตุการณ์ใหม่ที่ไม่เกี่ยวกับคำถาม การเปลี่ยนนโยบาย retrieval จึงเปลี่ยนผลแม้ยังไม่ได้เปลี่ยนวิธีสรุป

Summary S1 เป็น ข้อความที่ผู้เขียนตั้งใจให้เสียรายละเอียดเพื่อสอน failure mode โดยคงเวลาเก่าและละรายละเอียดการแก้ไขเวลา/สถานะการรับรองเรื่องถั่ว ไม่ใช่ output จาก LLM หรือผลสุ่มประเมินโมเดล คะแนนอธิบายกติกาใน toy scenario เท่านั้น ไม่พิสูจน์ว่างานสรุปทุกแบบด้อยกว่า raw หรือ structured memory

นำไปใช้กับ Agent ที่ทำงานจริงอย่างไร

ผู้ช่วยอ่านเอกสารสามารถใช้ summary เป็นดัชนีหัวข้อ แล้วค้นหลักฐานต้นฉบับเมื่อคำถามต้องการข้อยกเว้นหรือคำตอบพร้อมที่มา แนวทาง gist และ look-up ใน ReadAgent เป็นตัวอย่างการออกแบบที่ศึกษาแล้ว แต่การต่อระบบของตนเองต้องทดสอบเอกสาร รุ่นโมเดล และ query distribution ที่ใช้งานจริง ไม่ยืมผลบน benchmark มาเป็นคำรับรองระบบใหม่ ReadAgent

ผู้ช่วยโครงการที่ติดตามหลายรอบงานควรแยกเหตุการณ์ดิบ ข้อเสนอ และข้อสรุปที่รับรองให้ใช้ปัจจุบัน เมื่อผู้ใช้แก้คำสั่ง ต้องไม่ให้ summary เก่ากลบเหตุการณ์ใหม่ หากคำถามต้องตรวจสิ่งที่ระบบรู้ในอดีต ให้ใช้การเก็บเวอร์ชันและเวลาที่ออกแบบมาสำหรับงานนั้น แทนการใส่ timestamp ช่องเดียวแล้วคาดว่าจะได้ประวัติครบ

ส่วน Agent ที่สะสมบทเรียนจาก feedback สามารถอัปเดตข้อความหรือดัชนีความจำเพื่อช่วยครั้งต่อไปได้ แต่ต้องรายงานระดับการเปลี่ยนให้ถูก หากเพียงบันทึกบทเรียน ยังไม่ควรกล่าวว่าโมเดลฝึกน้ำหนักตัวเอง เรื่องนี้เชื่อมกับ Reflection Loop และระดับการเรียนรู้ของ Agent ซึ่งแยกการเปลี่ยนชิ้นงาน ความจำ และพารามิเตอร์ไว้

Failure Modes ที่ต้องวัดแยกจากความสั้น

Qualifier Loss: เงื่อนไข เช่น เฉพาะบางพื้นที่หรือเมื่อฝนตก หายไปจน assertion กว้างกว่าต้นทาง
Uncertainty Collapse: ข้อความ “ยังไม่ยืนยัน” กลายเป็น “ยืนยันแล้ว” หรือข้อมูลที่ไม่ทราบถูกแทนด้วยค่าที่คาดเดา
Revision Loss: ค่าก่อนและหลังการแก้ถูกสรุปรวมกันจนเลือกค่าปัจจุบันไม่ได้
Provenance Illusion: มี source ID แต่ source ไม่รองรับข้อสรุป ลิงก์เสีย หรือเชื่อมไปเอกสารคนละเรื่อง
Recursive Drift: การสรุปใช้ summary รอบก่อนเป็นหลักฐานแทนต้นฉบับจนการแต่งเติมสะสม
Evaluation Leakage: ใช้คำถามสร้างความจำชุดเดียวกับที่ใช้ทดสอบ จึงยังไม่รู้ว่าจะรักษารายละเอียดสำหรับคำถามใหม่ได้หรือไม่

การวัดควรเก็บอัตราคำตอบที่มีหลักฐานรองรับ อัตราข้อยกเว้นที่ยังอยู่ อัตราตอบ unknown ได้เหมาะสม ความสามารถค้นต้นทาง และต้นทุนที่นิยามจริง Compression ratio บอกได้ว่าข้อมูลสั้นลงเพียงใด แต่ไม่บอกคุณภาพคำตอบด้วยตัวมันเอง ผลต้องระบุวิธีคำนวณและชุดคำถาม อย่าเรียกจำนวนการ์ดใน Lab ว่าประสิทธิภาพของ AI จริง

เกมจำลอง: เลือกความจำให้พอตอบงานถัดไป

เกมให้เลือกเก็บ raw events หรือ structured facts ภายใต้งบที่กำหนด มีตัวเลือก merge แบบหยาบเพื่อทดลองการประหยัดพื้นที่ที่แลกกับ revision และหลักฐาน จากนั้นตอบสามคำถามพร้อม source IDs เป้าหมายคือคำตอบถูกตามเหตุการณ์และชี้กลับหลักฐานได้ทั้งหมดโดยไม่เกินงบ

SIMULATION GAMEภารกิจจัดความจำ • ไม่มีการเรียกโมเดลจริง

เกม: เก็บหลักฐานให้รอดจากการบีบอัด

เป้าหมาย: ตอบเรื่องสถานที่ เวลา และการรับรองอาหารให้ถูกทั้ง 3 ข้อ พร้อมอ้างหลักฐานที่ยังอยู่ในความจำ เลือกสิ่งที่จะเก็บในงบจำกัด ระวังข้อมูลเก่า เงื่อนไข และการรวมที่ทำรายละเอียดหาย

งบสำหรับรอบนี้ (เปลี่ยนแล้วเริ่มใหม่)

ต้นทุนเป็นหน่วยระเบียนสมมติ: raw 2, fact 3, summary 2 การเลือกไม่ฝึกโมเดล งบวัดขนาดความจำที่เก็บ ไม่ใช่จำนวนคลิก

Input: เลือกสิ่งที่จะเก็บ

State: ความจำที่เหลือ

เปิดกติกาและร่องรอยที่ตรวจได้

ชนะเมื่อค่าทั้งสามตรงคำตอบอ้างอิง อ้าง E3/E5/E7 ได้ตรงข้อ และยังมี raw event หรือ fact พร้อมที่มานั้นอยู่ในความจำ สรุป S1 และ merge M-time ไม่มีหลักฐานที่ผ่านเกณฑ์นี้ การมีข้อมูลเก่าร่วมกับใหม่ไม่แพ้อัตโนมัติ แต่ต้องเลือกใช้การแก้ไขล่าสุด

SIMULATION ใช้ multiple choice และคำตอบสมมติที่กำหนดไว้ ไม่ใช่การประเมิน reasoning ของ AI ผลจะเปลี่ยนหากเปลี่ยนข้อมูล กติกาต้นทุน คำถาม หรือวิธีบีบอัด State อยู่เฉพาะหน้าเว็บ โหลดใหม่แล้วหาย

ลองเล่นด้วย raw E3/E5/E7 แล้วเทียบกับ structured facts ที่ครบสามเรื่อง เปลี่ยนงบและ Reset เพื่อเห็นว่าความสามารถตอบขึ้นกับการเลือกข้อมูลและค่าใช้พื้นที่ที่สมมติไว้ การตอบเวลาได้ถูกแต่ให้หลักฐานเก่าที่ยังเป็น 18:00 ไม่ผ่านเงื่อนไขของเกม คำตอบกับหลักฐานต้องสอดคล้องกัน

เกมนี้ไม่มีโมเดลภาษา ไม่มี vector database และไม่ฝึกน้ำหนัก เป็นโค้ดกำหนดกฎที่ทำงานในหน้าบทความ การเลือก merge ไม่ได้เรียก LLM ให้สรุป และไม่ได้วัดราคาการเรียก API ทั้งคะแนนและหน่วยงบจึงมีขอบเขตเฉพาะสถานการณ์ที่เห็น ผู้อ่านควรใช้มันตั้งคำถามต่อระบบจริง มากกว่านำผล toy scenario ไปอ้างเป็น benchmark

สิ่งที่ยังต้องวิจัยและทดลองเพิ่มเติม

งานที่ยังเปิดอยู่คือการเลือกความจำให้รองรับคำถามที่ยังไม่ทราบล่วงหน้า ควรเปรียบเทียบหลาย task distribution และรายงานเมื่อโจทย์เปลี่ยน ไม่ทดสอบเฉพาะคำถามที่ช่วยให้วิธีตนดูดี อีกเรื่องคือการตรวจ semantic entailment: source IDs ทำให้ตรวจที่มาได้ง่ายขึ้น แต่ตัวตรวจยังต้องแยกความจริง เงื่อนไข และข้ออนุมานได้อย่างน่าเชื่อถือ

การย่อระยะยาวควรศึกษาการสะสมความผิดเมื่อสรุปหลายรอบ การค้นต้นทางที่ถูกลบตามนโยบาย และต้นทุน metadata เทียบกับ raw retrieval ส่วนงานระบบต้องตรวจการบันทึก การ rollback และ consistency ระหว่างเวอร์ชันให้ชัด สถาปัตยกรรมที่เสนอในบทความและ simulator นี้ยังไม่พิสูจน์คุณสมบัติเหล่านั้นในฐานข้อมูลจริง

สิ่งที่ผู้พัฒนานำไปทำได้ทันที

เริ่มจากกำหนดคำถามปลายทางที่สำคัญอย่างน้อยเรื่องค่าปัจจุบัน ข้อยกเว้น การแก้ไข และที่มาของข้อมูล เก็บคำถามบางส่วนไว้ทดสอบภายหลัง สร้าง raw baseline ที่ค้นเฉพาะหลักฐานเกี่ยวข้องก่อน แล้วเปรียบเทียบ summary และ structured records ภายใต้งบที่วัดได้จริง วิธีนี้ช่วยแยกผลของ retrieval ออกจากผลของการเปลี่ยน representation

กำหนด schema ให้มี qualifiers และ unknown ที่ชัด ไม่ใช้ข้อความสวยงามเป็นเกณฑ์ผ่าน สร้าง candidate แยกจาก memory ที่รับใช้งาน เก็บผลตรวจและเวอร์ชันที่อ่านกลับได้ ตัดสินใจเรื่องอายุหลักฐานก่อนรับรองว่าอธิบายที่มาภายหลังได้ และตรวจทั้งคำตอบกับ source ที่ใช้จริงหลัง Agent ลงมือ

หกกล่องสรุป Retain Qualifiers Keep Provenance Evaluate Future Tasks Context versus Storage Commit Version และ Memory Update ไม่เท่ากับ Training — **หกหลักการประเมิน Agent Memory Consolidation** — เก็บ qualifiers และ provenance ประเมิน future tasks มากกว่า compression ratio แยก context window retrieved context external storage แยก candidate กับ accepted/versioned memory และไม่อ้างการสรุปหรือเปลี่ยน prompt เป็นการฝึก model weights Original logs ต้องมีสิทธิ์และนโยบายเก็บ ไม่เก็บตลอดไปโดยไม่มีขอบเขต ผล simulation ไม่เท่ากับผล AI benchmark · แหล่งแนวคิด 1 · แหล่งแนวคิด 2 · แหล่งแนวคิด 3

เมื่อเชื่อมความจำเข้ากับ planning ให้แยกสิ่งที่เกิดแล้ว ข้อสรุปที่เชื่อ และสถานะโลกที่คาดการณ์จากกัน ข้อมูลย่อที่รักษาหลักฐานได้ช่วยเป็น input ของระบบอื่น แต่ไม่ทำให้ Agent มี world model หรือวางแผนถูกเองโดยอัตโนมัติ ศึกษาความต่างนี้ต่อใน World Model ของ AI Agent

FAQ

Memory Consolidation คือการสรุปข้อความอย่างเดียวหรือไม่

ไม่จำเป็น อาจเป็นการรวม facts จัดดัชนี เชื่อม source แยกข้ออนุมาน หรือรักษาเวอร์ชัน บทความนี้ใช้คำดังกล่าวกับการจัดระเบียบความจำภายนอกให้ใช้ต่อได้ การสรุปเป็นเพียงวิธีหนึ่ง

Summary ที่มี source IDs เชื่อถือได้ทันทีหรือไม่

ยังไม่ได้ source IDs ช่วยค้นกลับและตรวจได้ แต่ข้อสรุปอาจไม่สอดคล้องกับต้นทาง ต้องตรวจว่า source รองรับ value เงื่อนไข และสถานะความไม่แน่นอนที่กล่าวไว้จริง

Structured Memory ดีกว่า Raw Log เสมอหรือไม่

ไม่เสมอ schema และ metadata มีต้นทุน หากรู้ query การเลือก raw evidence เฉพาะส่วนอาจใช้ข้อมูลน้อยกว่า การเปรียบเทียบต้องใช้ชุดงาน งบ และวิธีนับที่ชัดเจน

เมื่อ Agent บันทึกบทเรียนใหม่ ถือว่าฝึกโมเดลแล้วหรือยัง

ยังสรุปเช่นนั้นไม่ได้ การเขียนความจำอาจเปลี่ยนพฤติกรรมผ่านบริบทที่อ่าน แต่การฝึกน้ำหนักต้องมีขั้น update พารามิเตอร์ที่ตรวจได้ รายงานกลไกทั้งสองแยกกัน

ถ้า Context Window ใหญ่มาก ยังต้องจัดการความจำหรือไม่

ยังต้องตัดสินใจว่าจะเก็บ ค้น และส่งอะไรให้โมเดล ขนาด context ไม่ยืนยันว่าข้อมูลถูกเลือกหรือใช้ถูก และไม่แก้ข้อมูลสำคัญที่ถูกลบทิ้งก่อนบันทึก

คะแนนจาก Lab นี้พิสูจน์ว่าวิธีไหนใช้กับ LLM ได้ดีที่สุดหรือไม่

ไม่ได้ Lab เป็นกฎสมมติและคำตอบที่ผู้เขียนกำหนด มีหน่วยบันทึกเฉพาะสถานการณ์ ไม่เรียก LLM ไม่ใช้ token จริง และไม่ได้ทำซ้ำ benchmark ต้นฉบับ

References

MemGPT: Towards LLMs as Operating Systems — arXiv v2, 12 กุมภาพันธ์ 2024; preprint อธิบาย memory tiers, recall storage และ recursive summary
Generative Agents: Interactive Simulacra of Human Behavior, งาน UIST 2023; memory stream, reflections/evidence และข้อจำกัดการค้น/แต่งเติม
Lost in the Middle: How Language Models Use Long Contexts, TACL 2024; peer-reviewed ทดลอง QA และ key–value retrieval ภายใต้โมเดล/ข้อมูลที่ระบุ
A Human-Inspired Reading Agent with Gist Memory of Very Long Contexts — ReadAgent v3, 22 กรกฎาคม 2024; ใช้สถานะ arXiv preprint ในบทความนี้ สถานะประชุมหลักยัง UNKNOWN
LLMLingua: Compressing Prompts for Accelerated Inference of Large Language Models, EMNLP 2023; peer-reviewed งาน prompt compression ซึ่งต้องแยกจาก agent memory consolidation

Memory Consolidation ของ AI Agent: ย่อความจำอย่างไรไม่ให้ข้อเท็จจริงสำคัญหาย