การออกแบบหน่วยความจำระยะยาวสำหรับ AI Agent — คู่มือการใช้งาน Persistent Memory, Memory Store และการค้นหาข้อมูล

AIエージェントのメモリ（記憶）とは、単発の推論で完結させず、タスクやセッションをまたいで情報を保持し、のちの判断に再利用する仕組みである。チャットの会話履歴を超えて「前回ユーザーが何を依頼し、どんな制約を示したか」を覚えておくことで、エージェントは長時間タスクや反復業務を安定してこなせるようになる。

本記事は、自律的に動くAIエージェントを設計・運用するエンジニアやプロダクト担当者に向けて、永続メモリ（長期記憶）の設計手順を実装目線でまとめたものだ。メモリストアの選び方、書き込み・検索・更新のフロー、記憶の陳腐化やメモリ汚染への対策、マルチエージェントでの共有設計までを扱う。なお、1回の推論に何を詰め込むかというコンテキストエンジニアリングの設計は別記事に譲り、本記事はセッションを越えて残す「永続層」に集中する。

หน่วยความจำ (Memory) ของ AI Agent คือกลไกที่ไม่จบลงเพียงแค่การอนุมาน (Inference) ในครั้งเดียว แต่เป็นการเก็บรักษาข้อมูลข้ามงาน (Task) หรือเซสชัน (Session) เพื่อนำกลับมาใช้ใหม่ในการตัดสินใจในภายหลัง การที่เอเจนต์สามารถจดจำได้ว่า "ผู้ใช้เคยขออะไรไว้และมีข้อจำกัดอย่างไรบ้าง" นอกเหนือจากประวัติการสนทนาในแชท จะช่วยให้เอเจนต์สามารถจัดการกับงานระยะยาวหรืองานที่ทำซ้ำๆ ได้อย่างเสถียร

บทความนี้สรุปขั้นตอนการออกแบบหน่วยความจำถาวร (Long-term Memory) ในมุมมองของการนำไปใช้งานจริง สำหรับวิศวกรและผู้ดูแลผลิตภัณฑ์ที่ออกแบบและดำเนินงาน AI Agent แบบอัตโนมัติ โดยครอบคลุมตั้งแต่การเลือกที่จัดเก็บหน่วยความจำ (Memory Store), ขั้นตอนการเขียน-ค้นหา-อัปเดต, มาตรการรับมือกับข้อมูลที่ล้าสมัยหรือการปนเปื้อนของหน่วยความจำ (Memory Contamination) ไปจนถึงการออกแบบการแชร์ข้อมูลในระบบ Multi-agent ทั้งนี้ ในส่วนของการออกแบบว่าควรใส่ข้อมูลอะไรลงไปในการอนุมานแต่ละครั้ง หรือ Context Engineering นั้น จะขอยกไปกล่าวถึงในบทความอื่น โดยบทความนี้จะมุ่งเน้นไปที่ "ชั้นข้อมูลถาวร" (Persistence Layer) ที่คงอยู่ข้ามเซสชันเท่านั้น

หน่วยความจำ (Memory) คือ "ข้อมูลที่เก็บไว้ข้ามเซสชัน" ส่วนบริบท (Context) คือ "ข้อมูลที่ส่งให้ในการอนุมาน (Inference) แต่ละครั้ง" หากสับสนสองสิ่งนี้เข้าด้วยกัน คุณอาจจะลงเอยด้วยการยัดข้อมูลที่ควรจะคงอยู่ถาวรลงใน Prompt ทุกครั้ง หรือในทางกลับกัน คือการเก็บข้อมูลชั่วคราวที่ไม่จำเป็นไว้ตลอดเวลา ต่อไปนี้คือการสรุปขอบเขตของทั้งสองสิ่งนี้ รวมถึงการแบ่งประเภทหน่วยความจำพื้นฐาน 3 ประเภท

เอเจนต์จำเป็นต้องมีหน่วยความจำ (Memory) เมื่อการประมวลผลไม่ได้จบลงภายใน "การถาม-ตอบเพียงครั้งเดียว" โดยมีสถานการณ์ตัวอย่างที่สำคัญ 3 ประการ ดังนี้

ประการแรก งานระยะยาว (Long-running tasks) ในงานประเภทการสืบค้น การสร้างโค้ด หรือการประมวลผลงานหลายขั้นตอน ซึ่งจำเป็นต้องอ้างอิงผลลัพธ์ระหว่างทางหรือการตัดสินใจที่เกิดขึ้นก่อนหน้า หากไม่สามารถเก็บรักษาการตัดสินใจจนถึงจุดนั้นไว้ได้ ก็จะทำให้ต้องเริ่มสืบค้นใหม่ตั้งแต่ต้น หรืออาจส่งผลลัพธ์ที่ขัดแย้งกันเองออกมา

ประการที่สอง การใช้งานหลายเซสชัน (Multi-session) สำหรับผู้ช่วยงานที่ผู้ใช้คนเดิมเข้ามาสนทนาซ้ำหลายครั้งในหลายวัน หากไม่จดจำ "เนื้อหาที่เคยขอไว้ก่อนหน้า" "ตำแหน่งหน้าที่หรือความชอบของผู้สนทนา" หรือ "โปรเจกต์ที่กำลังดำเนินการอยู่" ผู้ใช้จะต้องอธิบายใหม่ตั้งแต่ศูนย์ทุกครั้ง ซึ่งไม่สามารถนำไปใช้งานจริงได้

ประการที่สาม การทำซ้ำและการเรียนรู้ (Iteration/Learning) คือกรณีที่มีการบันทึกความผิดพลาดในอดีตหรือการแก้ไขจากผู้ใช้ เพื่อนำไปปรับปรุงพฤติกรรมในครั้งถัดไป ตัวอย่างเช่น หากได้รับคำสั่งแก้ไขว่า "สำหรับคู่สนทนารายนี้ ให้ตอบกลับเป็นภาษาญี่ปุ่นแทนภาษาอังกฤษ" เมื่อได้รับคำสั่งแล้ว ก็จะบันทึกข้อมูลนั้นไว้อย่างถาวรเพื่อป้องกันไม่ให้เกิดปัญหาเดิมซ้ำอีก

ในทางกลับกัน สำหรับการใช้งานที่ไม่จำเป็นต้องส่งต่อสถานะ (State) เช่น การถาม-ตอบแบบครั้งเดียวจบ หรือบอต FAQ ที่ตอบโต้แบบคำถามต่อคำถาม การไม่สร้างเลเยอร์หน่วยความจำขึ้นมาจะช่วยให้โครงสร้างระบบมีความเรียบง่ายกว่า

หน่วยความจำ (Memory) และบริบท (Context) มักถูกกล่าวถึงว่าเป็นสิ่งเดียวกัน แต่ในเชิงการออกแบบแล้ว ทั้งสองอยู่คนละเลเยอร์กัน บริบทคือ "ชุดข้อมูลนำเข้าที่ส่งให้โมเดลในการอนุมานครั้งนี้" ซึ่งประกอบขึ้นจากพร้อมท์ (Prompt), ความรู้ภายนอกที่ดึงมา, คำนิยามของเครื่องมือ และบทสนทนาล่าสุด ในขณะที่หน่วยความจำคือ "ข้อมูลที่เก็บไว้ในที่จัดเก็บภายนอกเพื่อใช้ในครั้งถัดไป"

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

บทความนี้จะมุ่งเน้นไปที่ส่วนแรก นั่นคือการออกแบบเลเยอร์ถาวร (Persistence Layer) ส่วนประเด็นเรื่อง Context Engineering (เช่น การจัดโครงสร้าง Context Window หรือวิธีการบีบอัดบริบท) ว่าควรใส่ข้อมูลเท่าใดในการอนุมานหนึ่งครั้ง หรือควรบีบอัดและจัดรูปแบบอย่างไรนั้น จะขอยกไปไว้ในบทความดังกล่าว การแยกบทบาทในการออกแบบจะช่วยให้การตัดสินใจชัดเจนขึ้น เช่น "เก็บไว้แต่ไม่ต้องอ่านทุกครั้ง" หรือ "อ่านแต่ไม่ต้องเก็บ"

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

หน่วยความจำระยะสั้น (Short-term memory / Conversation history) คือการโต้ตอบล่าสุดที่อ้างอิงภายในเซสชันที่กำลังดำเนินอยู่ ส่วนใหญ่มักจะถูกขยายเข้าสู่บริบท (Context) ในทุกๆ การอนุมาน (Inference) และจะถูกลบทิ้งเมื่อจบเซสชัน หรืออาจสรุปเฉพาะใจความสำคัญเพื่อเลื่อนระดับไปเก็บไว้ในหน่วยความจำระยะยาว

หน่วยความจำระยะยาว (Long-term memory / Persistent memory) คือข้อมูลที่คงอยู่ข้ามเซสชัน โดยจะจัดเก็บคุณลักษณะของผู้ใช้ การตัดสินใจในอดีต และความรู้ที่ใช้ซ้ำๆ ไว้ในที่จัดเก็บข้อมูลภายนอก (External storage) และจะดึงข้อมูลออกมาใช้เฉพาะเมื่อจำเป็นเท่านั้น ซึ่งเป็นหัวข้อหลักของบทความนี้

หน่วยความจำขณะทำงาน (Working memory) คือพื้นที่ชั่วคราว (Scratchpad) ที่เก็บข้อมูลไว้เฉพาะในระหว่างการทำภารกิจหนึ่งๆ ให้สำเร็จ เช่น สถานะระหว่างการวางแผน ผลลัพธ์ระหว่างทางของการใช้เครื่องมือ หรือสมมติฐานที่ยังไม่สรุป โดยจะถูกลบทิ้งเมื่อภารกิจเสร็จสิ้น

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

สิ่งแรกที่ต้องตัดสินใจในการออกแบบหน่วยความจำ (Memory Design) คือ "จะเก็บอะไรไว้ และจะทิ้งอะไร" หากบันทึกทุกอย่างไว้จะทำให้ความแม่นยำในการค้นหาลดลง อีกทั้งยังเพิ่มต้นทุนและความเสี่ยงด้านความเป็นส่วนตัว ดังนั้นจึงต้องกำหนดเกณฑ์การคัดเลือกข้อมูลที่จะจัดเก็บ รวมถึงระยะเวลาในการเก็บรักษา และมุมมองด้านการคุ้มครองข้อมูลส่วนบุคคลให้ชัดเจนเสียก่อน

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

• ความสามารถในการนำกลับมาใช้ใหม่ (Reusability): ข้อมูลนั้นถูกอ้างอิงซ้ำๆ โดยผู้ใช้คนเดิมหรือในงานเดิมหรือไม่ หากเป็นข้อมูลที่ใช้เพียงครั้งเดียว ไม่จำเป็นต้องเก็บไว้
• ต้นทุนในการเรียกคืน (Retrieval Cost): ข้อมูลที่สามารถดึงมาจากระบบภายนอกหรือฐานข้อมูลได้ทุกเมื่อ (เช่น จำนวนสินค้าคงคลังล่าสุด, ราคา) ไม่ควรนำมาตรึงไว้ในหน่วยความจำ แต่ควรยึดแหล่งข้อมูลต้นทางเป็นหลัก เพราะหากนำมาตรึงไว้ ข้อมูลจะล้าสมัยได้ง่าย
• บันทึกการตัดสินใจและการแก้ไข (Decision/Correction Records): ข้อมูลที่เป็น "ผลลัพธ์จากการตกลง" เช่น ความชอบของผู้ใช้, ข้อมูลจำเพาะที่สรุปแล้ว หรือการแก้ไขในอดีต เป็นสิ่งที่จำลองขึ้นมาใหม่ได้ยาก จึงมีคุณค่าสูงในการเก็บรักษา
• ความสามารถในการสรุปความ (Summarizability): ไม่ควรเก็บประวัติที่ยาวเหยียดไว้ในรูปแบบบันทึกดิบ (Raw log) แต่ควรสรุปประเด็นสำคัญเพื่อลดสัญญาณรบกวนและประหยัดพื้นที่จัดเก็บ

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

หน่วยความจำมักเป็นแหล่งเก็บข้อมูลส่วนบุคคล หากมีการจัดเก็บชื่อผู้ใช้ ข้อมูลติดต่อ หรือข้อมูลที่ละเอียดอ่อนทางธุรกิจไว้ในหน่วยความจำระยะยาว กฎหมายคุ้มครองข้อมูลส่วนบุคคลของไทย (PDPA) รวมถึงกฎระเบียบของประเทศต่างๆ จะกำหนดให้ต้องมีการระบุวัตถุประสงค์การใช้งานให้ชัดเจน จำกัดระยะเวลาการจัดเก็บ และรองรับการร้องขอให้ลบข้อมูล

ในการออกแบบควรคำนึงถึงสิ่งต่อไปนี้:

• ระยะเวลาการจัดเก็บ (TTL): กำหนดวันหมดอายุให้กับความจำแต่ละรายการ เพื่อให้ข้อมูลหมดอายุและถูกลบโดยอัตโนมัติ ไม่ควรตั้งค่าการจัดเก็บแบบไม่มีกำหนดเป็นค่าเริ่มต้น
• ช่องทางการลบข้อมูล: จัดเก็บข้อมูลโดยเชื่อมโยงกับขอบเขต (Scope - จะกล่าวถึงในภายหลัง) เพื่อให้สามารถลบความจำของผู้ใช้รายนั้นๆ ได้ทั้งหมด การออกแบบที่ไม่สามารถรองรับคำร้องขอให้ลบข้อมูลได้ถือเป็นความเสี่ยงด้านกฎระเบียบ
• การลดข้อมูลให้น้อยที่สุด (Minimization): ไม่ควรจัดเก็บคุณลักษณะที่ไม่จำเป็นต่อวัตถุประสงค์ตั้งแต่แรก สำหรับข้อมูลที่ละเอียดอ่อน ควรพิจารณาใช้การปกปิดข้อมูล (Masking) หรือใช้ ID อ้างอิงแทน

การที่ "จำไว้เพราะสะดวก" กับ "ได้รับอนุญาตให้จัดเก็บหรือไม่" เป็นคนละประเด็นกัน โดยเฉพาะในโครงสร้างที่ต้องจัดการข้อมูลข้ามพรมแดน ควรตรวจสอบภูมิภาคที่จัดเก็บ (Region) และความเป็นไปได้ในการโอนย้ายข้อมูลตั้งแต่ขั้นตอนการออกแบบ

การออกแบบหน่วยความจำถาวร (Persistent Memory) แบ่งออกเป็น 3 ขั้นตอน ได้แก่ "การเลือก Store → ขั้นตอนการเขียน ค้นหา และอัปเดต → การจัดการความสดใหม่ (Freshness)" โดยต้องกำหนดลำดับว่าควรเขียนลงใน Store ใด เมื่อใด จะดึงข้อมูลออกมาอย่างไร และจะลบทิ้งเมื่อใด ต่อจากนี้จะเป็นส่วนของการลงมือปฏิบัติจริงซึ่งเป็นหัวใจสำคัญของบทความนี้

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

เวกเตอร์ฐานข้อมูล (Vector Database): ใช้เมื่อต้องการค้นหา "ความจำที่มีความหมายใกล้เคียงกัน" โดยจะแปลงความจำให้เป็น Embedding แล้วจัดเก็บไว้ใน Vector Database เมื่อมีการสอบถาม ระบบจะดึงความจำที่เกี่ยวข้องออกมาโดยใช้การค้นหาความคล้ายคลึง (Similarity Search) เหมาะสำหรับการค้นหาประวัติหรือความรู้จากข้อความอิสระด้วย "เบาะแสที่ไม่ชัดเจน"

คีย์-แวลู สโตร์ (Key-Value Store: KVS): เหมาะสำหรับข้อมูลที่ทราบคีย์ที่แน่นอนและสามารถดึงข้อมูลได้ด้วยการจับคู่ที่สมบูรณ์ (Exact Match) เช่น "การตั้งค่าของแต่ละ User ID" หรือ "สถานะของแต่ละ Project ID" มีความหน่วงต่ำและจัดการได้ง่ายในฐานะที่เก็บข้อมูลในหน่วยความจำที่มีโครงสร้างเรียบง่าย

ฐานข้อมูลเชิงสัมพันธ์ / เอกสาร (Relational / Document DB): เหมาะสำหรับความจำที่มีความสัมพันธ์หรือเงื่อนไขการกรองที่ซับซ้อน (เช่น การค้นหาประวัติแบบมีเงื่อนไข, การสรุปผลข้อมูล)

ในทางปฏิบัติ การใช้ที่เก็บข้อมูลหลายแบบร่วมกันถือเป็นแนวทางที่สมเหตุสมผลมากกว่าการใช้เพียงที่เก็บข้อมูลเดียว ตัวอย่างเช่น การแบ่งบทบาทหน้าที่โดยใช้ "KVS สำหรับคุณลักษณะของผู้ใช้ และ Vector DB สำหรับประวัติความเป็นมา" การพิจารณาว่าวัตถุประสงค์หลักของการค้นหาคือการจับคู่ที่สมบูรณ์หรือความคล้ายคลึงทางความหมาย จะช่วยหลีกเลี่ยงความผิดพลาดในการใช้ Vector DB มากเกินความจำเป็น ซึ่งจะช่วยลดต้นทุนและความซับซ้อนลงได้

เมื่อกำหนด Store ได้แล้ว ให้กำหนดวงจรชีวิต (Lifecycle) ดังนี้

การเขียน (จะบันทึกเมื่อใด): การบันทึกทุกคำพูดจะทำให้เกิดสัญญาณรบกวน (Noise) มากเกินไป ให้จำกัดช่วงเวลาในการบันทึก เช่น เมื่อเสร็จสิ้นงาน, เมื่อผู้ใช้แก้ไขหรือยืนยันข้อมูล, หรือเมื่อเกิดเหตุการณ์ที่ชัดเจน (เช่น การทำสัญญาสำเร็จ, การเปลี่ยนการตั้งค่า) ในการบันทึกทุกครั้ง ต้องระบุแหล่งที่มา (ว่าเป็นคำพูดของใคร หรือผลลัพธ์จากเครื่องมือใด) และเวลาที่สร้างเสมอ

การค้นหา (จะดึงข้อมูลออกมาอย่างไร): หากดึงข้อมูลโดยพิจารณาจากความเกี่ยวข้องเพียงอย่างเดียว อาจทำให้ความจำเก่าๆ ปะปนเข้ามาได้ นอกเหนือจากความคล้ายคลึงทางความหมาย (Semantic similarity) แล้ว ควรให้น้ำหนักกับความใหม่ (Recency) และความสอดคล้องของขอบเขต (Scope - เช่น เป็นผู้ใช้หรือโปรเจกต์เดียวกันหรือไม่) แล้วคัดเลือกเฉพาะรายการที่ตรงที่สุดเพียงไม่กี่รายการ ความจำที่ดึงออกมาไม่ควรถูกนำไปเชื่อถือในทันที แต่ต้องตรวจสอบก่อนว่าขัดแย้งกับบริบทปัจจุบันหรือไม่ ก่อนที่จะนำไปใส่ใน Context

การอัปเดต (จะแก้ไขข้อมูลอย่างไร): หากข้อเท็จจริงเดิมมีการอัปเดต ให้ใช้วิธีเขียนทับ (Upsert) ข้อมูลเดิมแทนการเพิ่มข้อมูลใหม่ เพื่อไม่ให้เหลือค่าเก่าทิ้งไว้ สำหรับความจำที่ซ้ำซ้อนให้ทำการรวม (Merge) และหากมีความจำที่ขัดแย้งกัน ให้กำหนดกฎการแก้ไขข้อขัดแย้งไว้ เช่น การให้ความสำคัญกับข้อมูลใหม่มากกว่า หากละเลยส่วนนี้จะนำไปสู่สถานการณ์ที่ "ทั้งที่อยู่เก่าและที่อยู่ใหม่ถูกดึงออกมาพร้อมกัน"

ความจำจะเก่าลงหากปล่อยทิ้งไว้ เราจึงต้องใส่กลไกเพื่อรักษาความสดใหม่ไว้ตั้งแต่ต้น

• TTL และการหมดอายุ: กำหนดวันหมดอายุให้กับความจำแต่ละรายการ และตัดรายการที่หมดอายุออกจากการค้นหา โดยกำหนดระยะเวลาตามลักษณะของข้อมูล (ข้อมูลติดต่อควรเก็บไว้นาน ส่วนสถานะของงานที่กำลังดำเนินการควรเก็บไว้สั้น)
• การถ่วงน้ำหนักด้วยเวลาที่อัปเดต: ในขณะค้นหา ให้ความสำคัญกับความจำใหม่ก่อน และลดคะแนนของความจำเก่าลง
• ตัวกระตุ้นการตรวจสอบซ้ำ: สำหรับความจำที่สำคัญ เมื่อมีการอ้างอิง ให้ตรวจสอบกับแหล่งข้อมูลปัจจุบันว่า "ข้อมูลนี้ยังคงถูกต้องหรือไม่" โดยเฉพาะค่าที่เปลี่ยนแปลงบ่อย เช่น สต็อกสินค้า ราคา หรือผู้รับผิดชอบ โดยใช้หน่วยความจำเป็นเบาะแส แต่ให้ตรวจสอบค่าล่าสุดจากแหล่งที่มาโดยตรง
• การจัดระเบียบ (Inventory): จัดการความจำที่ไม่ได้ถูกเรียกใช้หรือข้อมูลที่ซ้ำซ้อนเป็นระยะ

หัวใจสำคัญของการป้องกันความล้าสมัยคือ "อย่าให้หน่วยความจำ (Memory) เป็นแหล่งข้อมูลที่ถูกต้องเพียงแหล่งเดียว" อย่าตรึงข้อเท็จจริงที่เปลี่ยนแปลงง่ายไว้ในหน่วยความจำ แต่ให้เก็บเฉพาะข้อเท็จจริงที่เปลี่ยนแปลงยากและผลลัพธ์ของข้อตกลงไว้ให้นาน การแบ่งแยกเช่นนี้จะช่วยป้องกันการแสดงผลที่ผิดพลาดจากความจำเก่าได้

การจะสนทนาต่อเนื่องข้ามเซสชัน จำเป็นต้องตัดสินใจว่า "จะเก็บประเด็นสำคัญของการสนทนาไว้ในระดับใด และด้วยความละเอียดระดับไหน" โดยต้องออกแบบว่าจะจัดเก็บสรุปการสนทนาไว้ในเลเยอร์บริบท (Context Layer) หรือเลื่อนระดับไปไว้ในเลเยอร์ถาวร (Persistent Layer) รวมถึงการกำหนดว่าจะแบ่งหน่วยความจำตามรายบุคคลอย่างไร

การบันทึกบทสนทนายาวๆ ทั้งหมดไว้จะทำให้เปลืองพื้นที่จัดเก็บและเพิ่มสัญญาณรบกวนในการค้นหา ในทางปฏิบัติ การแบ่งหน้าที่โดยให้ "การโต้ตอบล่าสุดระหว่างเซสชันอยู่ในหน่วยความจำระยะสั้น (Context Layer) และสรุปเฉพาะประเด็นสำคัญที่ควรค่าแก่การเก็บไว้ข้ามเซสชันเพื่อเลื่อนระดับไปสู่หน่วยความจำระยะยาว" จะจัดการได้ง่ายกว่า

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

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

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

ขอบเขตหลักๆ มีลำดับชั้นดังนี้:

• ระดับผู้ใช้ (User unit): ความชอบ คุณลักษณะ และประวัติการร้องขอส่วนบุคคล โดยจะอ้างอิงเฉพาะในเซสชันของบุคคลนั้นเท่านั้น
• ระดับองค์กร (Tenant unit): ความรู้และกฎเกณฑ์ที่ใช้ร่วมกันภายในบริษัทหรือทีมเดียวกัน ในโครงสร้างแบบ Multi-tenant จำเป็นต้องมีการแยกข้อมูลเพื่อไม่ให้ความจำรั่วไหลระหว่าง Tenant
• ระดับเซสชัน (Session unit): ความจำสำหรับการทำงานเฉพาะในเซสชันนั้นๆ โดยจะถูกทำลายหรือยกระดับความสำคัญเมื่อสิ้นสุดเซสชัน

การรวมขอบเขตไว้ในคีย์ (Key) เมื่อจัดเก็บข้อมูล จะช่วยให้สามารถดึงข้อมูลความจำเฉพาะ "ผู้ใช้นี้ และ Tenant นี้" ในระหว่างการค้นหาได้ และยังสามารถลบข้อมูลแบบกลุ่มตามขอบเขตที่กำหนดไว้ได้อีกด้วย โดยเฉพาะอย่างยิ่งเมื่อให้บริการ Agent เดียวกันแก่หลายบริษัท การแยก Tenant ถือเป็นหัวใจสำคัญของความปลอดภัย ซึ่งต้องดำเนินการอย่างเคร่งครัดแม้ในระดับหน่วยความจำ (Memory layer)

อุบัติเหตุในการจัดการหน่วยความจำมักเกิดจากการ "เชื่อในความจำที่ปนเปื้อน" โดยมีสาเหตุหลักสองประการคือ การแทรกแซงหน่วยความจำที่ไม่พึงประสงค์จากภายนอก (Memory Poisoning) และการปนเปื้อนของสัญญาณรบกวนจากหน่วยความจำที่ไม่เกี่ยวข้อง เรามาทำความเข้าใจสัญญาณเตือนและแนวทางป้องกันของแต่ละกรณีกัน

メモリポイズニング（Memory Poisoning）とは、悪意ある入力やツール出力を通じて、エージェントの長期記憶に誤った情報や不正な指示を書き込ませる攻撃だ。汚染された記憶は次回以降のセッションで引き出され、エージェントの判断を継続的に歪める。永続層は「一度書かれると長く効く」ため、その場限りのプロンプト注入より影響が深刻になりうる。

防御の基本は「保存する前に検証し、読み出すときに鵜呑みにしない」ことだ。

• 出典の記録（provenance）: すべての記憶に「誰の・どの経路の情報か」を付与する。ユーザー入力やツール出力をそのまま事実として保存しない。
• 書き込みの検証: 記憶として保存する内容に、指示文（「今後は必ず〜せよ」）や外部リンク・コードが紛れていないか検査し、疑わしいものは隔離する。
• 読み出し時の不信: 取り出した記憶を「ユーザーが言ったこと」として扱い、「システムの指示」として扱わない。記憶の中の命令文をそのまま実行しない。
• 権限分離: 記憶の書き込み権限を、信頼できる経路に限定する。

汚染は「いつの間にか効いている」のが怖い。保存・読み出しの両端で検証する二重化が要点になる。

แม้จะไม่ดูรุนแรงเท่ากับปัญหาการปนเปื้อน (Contamination) แต่สิ่งที่บั่นทอนคุณภาพของข้อมูลอยู่บ่อยครั้งกว่าคือ "การปนเปื้อนของความจำที่ไม่เกี่ยวข้อง" (Irrelevant memory intrusion) การค้นหาด้วยความคล้ายคลึง (Similarity search) บางครั้งอาจดึงเอาความจำที่มีบริบทต่างกันออกมาเพียงเพราะมีหน้าตาของคำที่คล้ายกัน ตัวอย่างเช่น หากการตัดสินใจจากโปรเจกต์อื่นหลุดเข้ามาปะปนในโปรเจกต์ปัจจุบัน ก็จะทำให้เกิดข้อผิดพลาดที่ดูสมเหตุสมผลขึ้นมาได้

แนวทางแก้ไขสรุปได้ที่การออกแบบความแม่นยำในการค้นหา:

• จำกัดขอบเขตก่อน (Scope filtering): ก่อนทำการค้นหาเชิงความหมาย (Semantic search) ให้จำกัดเป้าหมายด้วยผู้ใช้, เทนแนนท์ (Tenant) หรือโปรเจกต์เสียก่อน
• กำหนดค่าเกณฑ์ (Thresholding): ไม่ดึงความจำที่มีค่าความคล้ายคลึงต่ำกว่าเกณฑ์ที่กำหนดออกมา และยอมรับ "การไม่พบผลลัพธ์" (Not hitting)
• จำกัดจำนวนรายการ (Limit results): จำกัดไว้เพียงไม่กี่รายการแรก เพื่อไม่ให้บริบทเต็มไปด้วยความจำที่มีความเกี่ยวข้องต่ำ
• ถ่วงน้ำหนักด้วยความใหม่ (Recency weighting): ลดคะแนนของความจำเก่าลง และให้ความสำคัญกับข้อตกลงล่าสุดเป็นอันดับแรก

หากเพิ่มขั้นตอนที่ให้เอเจนต์ตัดสินใจเองว่า "ควรใช้ความจำนี้หรือไม่" เช่นเดียวกับ Agentic RAG จะช่วยลดผลกระทบจากความจำที่ไม่เกี่ยวข้องได้ดียิ่งขึ้น หัวใจสำคัญไม่ใช่การดึงความจำออกมาให้มากที่สุด แต่คือการดึงเฉพาะสิ่งที่เกี่ยวข้องออกมาให้น้อยและแม่นยำที่สุดต่างหาก

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

ในโครงสร้างแบบ Multi-agent เราต้องตัดสินใจว่าข้อมูลความจำส่วนใดควรแชร์ระหว่างเอเจนต์ และส่วนใดควรเก็บไว้เป็นส่วนตัวของแต่ละเอเจนต์

Shared Memory (หน่วยความจำที่แชร์ร่วมกัน): ใช้สำหรับเก็บข้อมูลที่ทุกคนในทีมต้องใช้เป็นพื้นฐานเดียวกัน เช่น เป้าหมายร่วม ข้อเท็จจริงที่ยืนยันแล้ว และความคืบหน้าโดยรวม การแชร์ข้อมูลนี้ช่วยป้องกันการทำงานซ้ำซ้อนและการตัดสินใจที่ขัดแย้งกัน อย่างไรก็ตาม เนื่องจากพื้นที่ส่วนกลางที่ใครก็สามารถเขียนได้นั้นมีความเสี่ยงที่จะเกิดการปนเปื้อนของข้อมูลในวงกว้าง จึงจำเป็นต้องมีการควบคุมสิทธิ์การเขียนและการตรวจสอบที่เข้มงวด

Isolated Memory (หน่วยความจำแยกส่วน): สมมติฐานหรือบันทึกระหว่างการทำงานของเอเจนต์แต่ละตัวควรเก็บไว้เป็นส่วนตัว หากแชร์ผลลัพธ์ระหว่างทางที่ยังไม่แน่นอนออกไป อาจทำให้เอเจนต์ตัวอื่นเริ่มทำงานโดยใช้พื้นฐานที่ผิดพลาดได้

หลักการออกแบบคือ "ข้อมูลที่ยืนยันแล้วให้แชร์ ข้อมูลที่ยังไม่แน่นอนให้แยกส่วน" นอกจากนี้ การแบ่ง Namespace ใน Shared Memory และบันทึกว่าเอเจนต์ตัวใดเป็นผู้เขียน จะช่วยให้สามารถตรวจสอบย้อนกลับได้เมื่อเกิดปัญหา เช่นเดียวกับระบบ Multi-tenant การกำหนดการควบคุมการเข้าถึง (Access Control) ให้ชัดเจนว่า "ใครเขียนได้ ใครอ่านได้" คือกุญแจสำคัญที่นำไปสู่ทั้งความร่วมมือและความปลอดภัย

Q. メモリとRAGはどう違いますか？ RAG คือกลไกที่ดึงเอกสารที่เกี่ยวข้องจากฐานความรู้ภายนอกมาใส่ไว้ในบริบท ซึ่งส่วนใหญ่ใช้สำหรับอ้างอิง "ความรู้ที่ไม่ค่อยเปลี่ยนแปลง" ส่วน Memory คือชั้นที่เก็บ "ประวัติหรือการตัดสินใจเฉพาะของผู้ใช้" ที่เอเจนต์ได้ประสบมาด้วยตัวเอง แม้วิธีการนำไปใช้ (เช่น Vector Search) จะทับซ้อนกัน แต่ RAG มีจุดประสงค์เพื่อการอ้างอิงความรู้ ในขณะที่ Memory มีจุดประสงค์เพื่อการสะสมประสบการณ์ โดยทั่วไปแล้วทั้งสองอย่างมักถูกนำมาใช้ร่วมกัน

Q. メモリは必ず実装すべきですか？ ไม่จำเป็น สำหรับการถาม-ตอบแบบครั้งเดียวจบ หรือการใช้งานที่ไม่จำเป็นต้องเก็บสถานะ การไม่สร้างชั้น Memory จะทำให้โครงสร้างระบบเรียบง่ายและปลอดภัยกว่า ควรพิจารณานำมาใช้เมื่อจำเป็นต้องรองรับงานระยะยาว, การใช้งานหลายเซสชัน (Multi-session) หรือการเรียนรู้ซ้ำ

Q. 会話履歴を全部保存すれば長期記憶になりますか？ ไม่เป็นเช่นนั้น การเก็บ Log ดิบทั้งหมดจะเพิ่มความเสี่ยงด้านสัญญาณรบกวนในการค้นหา (Search Noise), ปริมาณความจุ และความเป็นส่วนตัว สิ่งที่ควรเก็บคือบทสรุปของ "ผลลัพธ์ที่ตกลงกัน" และ "ข้อเท็จจริงที่ไม่ค่อยเปลี่ยนแปลง" ส่วนผลลัพธ์ระหว่างทางชั่วคราวหรือข้อมูลที่สามารถดึงมาใหม่ได้ตลอดเวลานั้น ควรคัดออกจากการจัดเก็บ

Q. 保存した記憶が古くなったらどうしますか？ ให้กำหนดวันหมดอายุด้วย TTL (Time To Live) และใช้การถ่วงน้ำหนักตามความใหม่ (Recency) ในขณะค้นหา สำหรับค่าที่เปลี่ยนแปลงบ่อย เช่น สินค้าคงคลังหรือราคา ไม่ควรใช้ Memory เป็นแหล่งข้อมูลความจริงเพียงแหล่งเดียว (Single Source of Truth) แต่ควรออกแบบให้ตรวจสอบค่าล่าสุดจากแหล่งข้อมูลต้นทางเสมอ

การออกแบบหน่วยความจำ (Memory) สำหรับ AI Agent เริ่มต้นจากการแยก "ชั้นข้อมูลถาวรที่คงอยู่ข้ามเซสชัน" ออกจากชั้นการออกแบบบริบท (Context) โดยมีประเด็นสำคัญดังนี้:

• แยกหน่วยความจำ (สิ่งที่ต้องเก็บ) ออกจากบริบท (สิ่งที่ต้องส่งให้ในขณะนั้น) และแบ่งข้อมูลออกเป็น 3 ชั้น ได้แก่ ความจำระยะสั้น (Short-term), ความจำระยะยาว (Long-term) และความจำขณะทำงาน (Working memory)
• สิ่งที่ควรจัดเก็บคือ "ข้อมูลที่มีความสามารถในการนำกลับมาใช้ใหม่สูงแต่เรียกคืนได้ยาก" กล่าวคือ ผลลัพธ์จากการตกลงและข้อเท็จจริงที่ไม่ค่อยเปลี่ยนแปลง โดยต้องคำนึงถึงระยะเวลาการจัดเก็บและการคุ้มครองข้อมูลส่วนบุคคลเป็นพื้นฐาน
• การออกแบบหน่วยความจำถาวร (Persistent memory) ให้เรียงลำดับจาก การเลือก Store → ขั้นตอนการเขียน ค้นหา และอัปเดต → การจัดการความสดใหม่ของข้อมูล โดยการค้นหาควรจำกัดขอบเขตตามความเกี่ยวข้องและความใหม่ของข้อมูล
• ป้องกัน Memory Poisoning และการปนเปื้อนของข้อมูลที่ไม่เกี่ยวข้องด้วยการตรวจสอบข้อมูลขณะบันทึกและการตั้งค่าความไม่ไว้วางใจขณะอ่านข้อมูล
• ในระบบ Multi-agent ให้ใช้แนวทาง "ข้อมูลที่ยืนยันแล้วให้แชร์ร่วมกัน ข้อมูลที่ยังไม่ยืนยันให้แยกออกจากกัน" พร้อมระบุการควบคุมการเข้าถึงให้ชัดเจน

หน่วยความจำไม่ใช่สิ่งที่ "ยิ่งจำได้มากยิ่งฉลาด" แต่จะช่วยให้งานระยะยาวมีความเสถียรได้ก็ต่อเมื่อ "จัดเก็บสิ่งที่จำเป็นอย่างแม่นยำ และเรียกใช้ได้อย่างถูกต้อง" เท่านั้น หากมุ่งหวังที่จะนำ AI Agent ไปใช้งานจริง การออกแบบชั้นหน่วยความจำจะเป็นหัวใจสำคัญไม่แพ้ไปกับการออกแบบบริบท (Context)