การออกแบบหน่วยความจำระยะยาว (Long-term memory) สำหรับ AI Agent คือการออกแบบสถาปัตยกรรมเพื่อให้ Agent สามารถจัดเก็บและนำบริบทการทำงานมาใช้ข้ามผ่านเซสชันการสนทนาได้

การใช้เพียง RAG มาตรฐานหรือ Context Window ทั่วไปนั้น เป็นเรื่องยากที่จะจดจำกระแสการทำงานที่ต่อเนื่องยาวนานหลายสัปดาห์หรือหลายเดือน ในบทความนี้ เราจะอธิบายรูปแบบการออกแบบ (Design Pattern) เพื่อให้เกิดการรักษาบริบทในระยะยาว โดยการผสมผสาน MemGPT จาก UC Berkeley และ GraphRAG จาก Microsoft Research เข้าด้วยกัน

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

เมื่อเซสชันสิ้นสุดลง AI Agent จะลืมทุกอย่างไปจนหมดสิ้น คุณเคยรู้สึกกังวลกับการนำไปใช้งานจริงในธุรกิจเพราะเหตุนี้หรือไม่

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

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

Context Window คือขีดจำกัดของข้อความที่ LLM สามารถอ้างอิงได้ในการอนุมาน (Inference) หนึ่งครั้ง ตามรายงานวิจัย MemGPT (ตารางที่ 1) ระบุว่าขีดจำกัดในขณะนั้นอยู่ที่ประมาณ 4,000 token สำหรับ llama-2 และ 8,000 token สำหรับ GPT ซึ่งข้อมูลที่เกินจากนี้จะไม่สามารถอ้างอิงได้ภายในเซสชันนั้นๆ

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

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

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

ความจำเป็นของหน่วยความจำระยะยาว (Long-term memory) จะแตกต่างกันไปตามความต่อเนื่องและความซับซ้อนของงาน หากเป็นการถาม-ตอบแบบครั้งเดียวจบ การใช้ RAG มาตรฐานก็เพียงพอแล้ว แต่หากเป็นการติดตามโปรเจกต์เดียวกันเป็นเวลาหลายสัปดาห์หรือหลายเดือน การรักษาบริบทข้ามเซสชัน (Cross-session context retention) ถือเป็นสิ่งจำเป็นอย่างยิ่ง

การออกแบบหน่วยความจำระยะยาวมีความสำคัญเป็นพิเศษในสถานการณ์ดังต่อไปนี้:

• การส่งต่องานในฝ่ายสนับสนุนลูกค้า (Customer Support): หากเอเจนต์ไม่จดจำปัญหาที่ลูกค้าเคยรายงานหรือประวัติการตอบกลับ ลูกค้าจะต้องอธิบายเรื่องเดิมซ้ำทุกครั้ง ซึ่งจะส่งผลให้ประสบการณ์ของลูกค้าแย่ลงอย่างมาก
• ผู้ช่วยจัดการโปรเจกต์ (Project Management Assistant): หากต้องการติดตามที่มาของการตัดสินใจหรือเหตุผลของการเปลี่ยนแปลงข้ามสปรินต์ (Sprint) จะไม่สามารถให้คำแนะนำที่สอดคล้องกันได้เลยหากขาดบริบทของการสนทนาในอดีต
• การสะสมองค์ความรู้ภายในองค์กร (Internal Knowledge Accumulation): ในกรณีการใช้งานที่เอเจนต์ต้องเรียนรู้และสะสมความรู้เฉพาะทางที่รู้กันเฉพาะบุคคลผ่านการสนทนาอย่างต่อเนื่อง การเชื่อมโยงหน่วยความจำระหว่างเซสชันถือเป็นข้อกำหนดเบื้องต้น
• งานด้านกฎหมายและการปฏิบัติตามกฎระเบียบ (Legal & Compliance): ในสถานการณ์ที่ต้องอ้างอิงประวัติการเจรจาสัญญาหรือเหตุผลประกอบการตัดสินใจในอดีตเพื่อจัดการกับเคสใหม่ การค้นหาเอกสารเพียงอย่างเดียวถือว่าไม่เพียงพอ

หากงานมีความซับซ้อนต่ำและคำถามมีความเป็นอิสระต่อกัน สามารถจัดการได้ภายในขอบเขตของ Context Window แต่สำหรับงานที่มีผู้มีส่วนได้ส่วนเสียหลายฝ่ายเกี่ยวข้อง และการตัดสินใจขึ้นอยู่กับประวัติความเป็นมาในอดีต จำเป็นต้องมีสถาปัตยกรรมหน่วยความจำระยะยาว

สิ่งที่สถานการณ์ทางธุรกิจเหล่านี้มีร่วมกันคือ "บริบทในอดีตส่งผลโดยตรงต่อคุณภาพของการตัดสินใจในปัจจุบัน"

คำถามที่ว่า "ยังไม่ได้จัดระเบียบว่าควรให้เอเจนต์จดจำอะไรบ้าง" เป็นข้อสงสัยที่มักเกิดขึ้นในช่วงเริ่มต้นของการออกแบบ หากอ้างอิงการจำแนกประเภทความจำตามหลักวิทยาศาสตร์พุทธิปัญญา (Cognitive Science) จะทำให้เราเห็นโครงสร้างที่จำเป็นสำหรับการออกแบบหน่วยความจำระยะยาว (Long-term memory) ของ AI Agent

ความจำที่เอเจนต์ควรเก็บรักษาไว้สามารถแบ่งออกได้เป็น 3 ประเภทหลัก ดังนี้:

• ความจำเหตุการณ์ (Episodic Memory): บันทึกเหตุการณ์ตามลำดับเวลา เช่น "คุยอะไร เมื่อไหร่ กับใคร" ตัวอย่างเช่น ที่มาของการเปลี่ยนแปลงสเปกที่ตกลงกันไว้ในการประชุมเมื่อสัปดาห์ที่แล้ว หรือลำดับความสำคัญของความต้องการที่ผู้ใช้เคยระบุไว้ในอดีต ซึ่งเป็นรากฐานที่ช่วยให้การสนทนาต่อเนื่องข้ามเซสชันได้

• ความจำเชิงความหมาย (Semantic Memory): ระบบความรู้เกี่ยวกับแนวคิด กฎ และคำศัพท์เฉพาะทางในโดเมนธุรกิจ เช่น "ลูกค้ารายนี้ชอบการเรียกเก็บเงินแบบปิดยอดสิ้นเดือน" หรือ "ผลิตภัณฑ์ A ไม่อยู่ภายใต้ข้อบังคับเฉพาะบางประการ" ซึ่งเป็นชุดของข้อเท็จจริงที่คงอยู่ได้แม้แยกออกจากบริบทเดิม และเป็นส่วนที่ GraphRAG แสดงจุดแข็งออกมาได้ชัดเจนที่สุด

• ความจำเชิงกระบวนการ (Procedural Memory): ขั้นตอนการทำงานหรือรูปแบบของเวิร์กโฟลว์ เช่น "ขั้นตอนการอนุมัติคือ หัวหน้างาน → ฝ่ายกฎหมาย → ฝ่ายบัญชี" หรือ "เมื่อเกิดข้อผิดพลาด ให้ตรวจสอบบันทึก (Log) ก่อนแล้วค่อยลองใหม่" เป็นความรู้ที่ถูกทำให้เป็นรูปแบบมาตรฐานสำหรับการปฏิบัติงานที่ทำซ้ำๆ

หากนำความจำทั้ง 3 ประเภทมาเก็บรวมกันใน Vector Store เดียวกัน จะมีความเสี่ยงสูงที่ระบบจะไม่สามารถแยกแยะประเภทของความจำในขณะสืบค้น ทำให้เกิดการดึงบริบทที่ไม่เกี่ยวข้องออกมาได้ ดังนั้น การแยกพื้นที่จัดเก็บ (Storage) ตั้งแต่ขั้นตอนการออกแบบ และการกำหนดกลยุทธ์การทำดัชนี (Indexing strategy) ที่เหมาะสมกับความจำแต่ละประเภทจึงเป็นเรื่องสำคัญ ซึ่งจะช่วยให้เข้าใจข้อจำกัดของ Standard RAG ที่จะกล่าวถึงในหัวข้อถัดไปได้ง่ายขึ้น

"จำเรื่องที่คุยกันเมื่อสัปดาห์ที่แล้วได้ไหม?" — ประโยคนี้ที่มนุษย์คุยกันแล้วเข้าใจได้ทันที อาจใช้ไม่ได้ผลกับ AI Agent โดยทั่วไปแล้ว RAG มาตรฐานมีกลไกในการดึงเอกสารที่เกี่ยวข้องมาตอบคำถามผ่านการค้นหาแบบ Vector Search ซึ่งแม้จะทำงานได้ดีสำหรับการอ้างอิงแบบครั้งเดียวจบ แต่ไม่ได้ถูกออกแบบมาให้เก็บรักษาบริบทที่ต่อเนื่องข้ามช่วงเวลา เช่น "การอภิปรายเมื่อสัปดาห์ที่แล้ว" หรือ "ที่มาของการตัดสินใจในครั้งก่อน"

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

การนำ Vector Search มาใช้ดูเหมือนจะเป็นการแก้ปัญหาเรื่องหน่วยความจำระยะยาว (Long-term memory) แต่เมื่อเริ่มลงมือพัฒนาก็อาจต้องเผชิญกับกำแพงที่ว่า "แม้จะดึงข้อมูลส่วนที่ใกล้เคียงกันในเชิงความหมายมาได้ แต่บทสนทนากลับไม่ต่อเนื่อง"

หัวใจสำคัญของปัญหาที่ RAG มาตรฐานต้องเผชิญคือ การให้คะแนน (Scoring) นั้นพิจารณาเพียง "ความคล้ายคลึงในระดับ Chunk" เท่านั้น เนื่องจากแต่ละ Chunk ถูกประเมินอย่างเป็นอิสระต่อกัน จึงไม่สามารถแสดงความสัมพันธ์เชิงเหตุผลหรือลำดับเวลาที่ครอบคลุมหลายเซสชันได้ ข้อมูลที่มีความสัมพันธ์เชิงเวลา เช่น "นโยบายที่ตกลงกันในการประชุมเมื่อสัปดาห์ที่แล้ว" หรือ "ขั้นตอนการอนุมัติที่เปลี่ยนไปเมื่อหลายเดือนก่อน" มักจะไม่ปรากฏอยู่ในพื้นที่ใกล้เคียงกันใน Vector Space ทำให้เกิดการขาดช่วงของบริบท (Context) นอกจากนี้ หากพยายามดึง Chunk ที่เกี่ยวข้องออกมาจำนวนมาก ก็จะทำให้ Context Window ของ LLM เต็มอย่างรวดเร็ว ตามที่งานวิจัย MemGPT (arXiv: 2310.08560) ได้ชี้ให้เห็นว่า ความยาวบริบทของโมเดลหลักในขณะนั้นมีจำกัดเพียงไม่กี่พันโทเคนเท่านั้น (เช่น llama-1 = 2,000 tokens, llama-2 = 4,000 tokens, gpt-3.5-turbo = 4,000 tokens, gpt-4 = 8,000 tokens) ดังนั้นการออกแบบที่ส่ง Chunk จำนวนมากเข้าไปในคราวเดียวจึงไม่สามารถทำได้จริงตั้งแต่แรก

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

เมื่อบันทึกการทำงาน (Business Log) มีจำนวนเพิ่มขึ้นถึงระดับหลายหมื่นรายการ ความแม่นยำของการค้นหาแบบเวกเตอร์ (Vector Search) มักจะลดลงเร็วกว่าที่คาดไว้

สาเหตุหนึ่งคือ การปะปนกันของรายการที่มีความหมายใกล้เคียงกันแต่บริบทต่างกัน ตัวอย่างเช่น วลีที่ว่า "รอการอนุมัติ" (Pending Approval) ปรากฏทั้งในขั้นตอนการอนุมัติเอกสารคำร้องและขั้นตอนการอนุมัติสิทธิ์การเข้าถึงระบบ ในพื้นที่เวกเตอร์ (Vector Space) ระยะห่างของทั้งสองสิ่งนี้จะใกล้กันมาก ทำให้เอกสารที่ไม่เกี่ยวข้องมีโอกาสหลุดเข้ามาอยู่ในผลลัพธ์ลำดับต้นๆ ได้ง่าย

แหล่งที่มาของสัญญาณรบกวน (Noise) ที่พบได้บ่อยในบันทึกขนาดใหญ่ สามารถสรุปได้ดังนี้:

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

ความรุนแรงของการลดลงของความแม่นยำจะแตกต่างกันไปตามลักษณะของบันทึก หากเป็นบันทึกที่มีโครงสร้าง (Structured Log เช่น CSV หรือ DB Record) เป็นหลัก สามารถแก้ไขได้ด้วยการปรับความละเอียดในการแบ่ง Chunk แต่หากมีข้อความที่ไม่มีโครงสร้าง (เช่น อีเมล, รายงานการประชุม, ประวัติแชท) ปะปนอยู่ ขั้นตอนการทำความสะอาดข้อมูล (Noise Removal) ในช่วงการประมวลผลล่วงหน้าถือเป็นสิ่งจำเป็น

ปัญหาเหล่านี้ไม่สามารถแก้ไขได้ด้วยการเพิ่มขนาดดัชนีเพียงอย่างเดียว ในทางกลับกัน ยิ่งเป้าหมายการค้นหาเพิ่มมากขึ้นเท่าใด ความเสี่ยงที่รายการที่ไม่เกี่ยวข้องจะขึ้นมาอยู่ในอันดับต้นๆ ของคะแนน (Score) ก็จะยิ่งสูงขึ้น การรวมกันของ MemGPT และ GraphRAG ซึ่งจะอธิบายในส่วนถัดไป เป็นแนวทางที่จัดการกับปัญหาเชิงโครงสร้างนี้ในระดับสถาปัตยกรรม

คุณเคยรู้สึกไหมว่า "ทำไมเอเจนต์ถึงจำเนื้อหาการประชุมเมื่อสัปดาห์ที่แล้วไม่ได้ ทั้งที่ใส่ RAG มาตรฐานเข้าไปแล้ว" คำถามนั้นคือหัวใจสำคัญที่ MemGPT และ GraphRAG พยายามจะแก้ไข

ทั้งสองเทคโนโลยีต่างเข้ามาเติมเต็มจุดอ่อนซึ่งกันและกัน ดังนี้:

สิ่งที่ MemGPT เข้ามาเติมเต็ม

• มีกลไกในการจัดเก็บและเรียกคืนข้อมูลไปยังหน่วยความจำภายนอก เมื่อข้อมูลเกินขีดจำกัดทางกายภาพของ Context Window (ในตารางที่ 1 ของงานวิจัยระบุว่า GPT-4 อยู่ที่ 8,000 tokens)
• มีความโดดเด่นในการรักษา "ความจำเชิงเหตุการณ์" (Episodic Memory) ข้ามเซสชัน
• เอเจนต์สามารถควบคุมจังหวะการอ่านและเขียนความจำได้ด้วยตนเองผ่าน Function Call

สิ่งที่ GraphRAG เข้ามาเติมเต็ม

• จัดเก็บเอนทิตี (Entity) และความสัมพันธ์ (Relation) จากเอกสารทางธุรกิจจำนวนมหาศาลในรูปแบบโครงสร้างกราฟ เพื่อตอบคำถามว่า "ใคร ทำอะไร และเกี่ยวข้องกับโปรเจกต์ไหน"
• สามารถสืบค้นข้ามเอกสารผ่าน Graph Query ซึ่งเป็นความสัมพันธ์ที่การค้นหาแบบเวกเตอร์ (Vector Search) มักจะเข้าไม่ถึง
• GraphRAG ซึ่งเปิดตัวโดย Microsoft Research ในเดือนกุมภาพันธ์ 2024 มีรายงานว่า แม้การสกัดกราฟจะมีสัดส่วนต้นทุนการทำดัชนี (Indexing Cost) สูงถึงประมาณ 75% แต่ก็ช่วยเพิ่มความแม่นยำในการตอบคำถามเชิงอนุมานที่ซับซ้อนได้อย่างมาก

ผลลัพธ์ที่เกิดจากการใช้งานร่วมกัน

MemGPT จะทำหน้าที่จัดการบริบทตามลำดับเวลาว่า "คุยอะไร เมื่อไหร่ กับใคร" ในขณะที่ GraphRAG จะให้ความรู้เชิงโครงสร้างว่า "บุคคลหรือแนวคิดนั้นๆ เชื่อมโยงกันอย่างไรภายในองค์กร"

บทสรุป: MemGPT ได้รับการออกแบบมาเพื่อเลียนแบบลำดับชั้นหน่วยความจำของ OS ซึ่งช่วยให้ LLM สามารถมีหน่วยความจำระยะยาวที่เหนือกว่าข้อจำกัดด้านบริบท (Context Constraints) ได้

MemGPT เป็นเฟรมเวิร์กที่ทีมวิจัยจาก UC Berkeley และสถาบันอื่นๆ ได้นำเสนอในปี 2023 โดยจัดการหน่วยความจำผ่านการแยกส่วนระหว่าง Main Context และ External Storage ในหัวข้อ H3 ต่อไปนี้ จะอธิบายถึงโครงสร้างสถาปัตยกรรม การตั้งค่าเริ่มต้น และขั้นตอนการควบคุม Function Call ตามลำดับ

เมื่อเห็น MemGPT ครั้งแรก หลายคนมักจะมองว่า "มันก็เป็นแค่ปลั๊กอินขยายหน่วยความจำธรรมดา" แต่ในความเป็นจริงแล้ว มันคือสถาปัตยกรรมแบบลำดับชั้นที่ได้รับแรงบันดาลใจจากการจัดการหน่วยความจำของ OS ซึ่งการทำความเข้าใจแนวคิดการออกแบบนี้ถือเป็นหัวใจสำคัญของการนำหน่วยความจำระยะยาว (Long-term memory) ไปใช้งาน

ในงานวิจัยของ MemGPT (UC Berkeley และคณะ, ตุลาคม 2023) ได้นำเสนอโครงสร้างที่เปรียบ LLM เป็นเสมือน OS โดยมองว่า Context Window คือ "หน่วยความจำหลัก (RAM)" และมองที่เก็บข้อมูลภายนอกเป็น "ดิสก์" จากตารางเปรียบเทียบในงานวิจัยระบุว่า ความยาว Context ของโมเดลหลักในขณะนั้นอยู่ที่ 2,000 tokens สำหรับ llama-1 และ 8,000 tokens สำหรับ GPT-4 ซึ่งถือว่ายากในเชิงโครงสร้างที่จะบรรจุบริบทการทำงานระยะยาวไว้ในหน้าต่างเดียว

องค์ประกอบหลักของสถาปัตยกรรมมี 3 ชั้น ดังนี้:

• Main Context (In-Context Storage): พื้นที่ทำงานหลักที่ LLM สามารถอ้างอิงได้โดยตรง ทำหน้าที่เก็บ System Prompt, บทสนทนาล่าสุด และสรุปใจความสำคัญ
• External Storage (External Storage): หน่วยความจำระยะยาวที่จัดเก็บอยู่ใน Vector DB หรือ KV Store

โปรดทราบว่าขั้นตอนการตั้งค่า MemGPT จะแตกต่างกันไปตามการใช้งานระหว่างสภาพแวดล้อมภายในเครื่อง (Local) หรือ Cloud API หากใช้ Local LLM (เช่น LM Studio) จะต้องมีการดาวน์โหลดโมเดลและตั้งค่า API Endpoint เพิ่มเติม แต่หากใช้ OpenAI API Key คุณสามารถดำเนินการจนถึงขั้นตอนการทดสอบการทำงานได้รวดเร็วที่สุดเพียงแค่ตั้งค่า Environment Variables เท่านั้น

ขั้นตอนการติดตั้ง (กรณีใช้ OpenAI API)

ขั้นแรก โปรดเตรียมสภาพแวดล้อม Python 3.10 ขึ้นไป

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

ในวิซาร์ด ให้ตั้งค่าหัวข้อต่างๆ ตามลำดับดังนี้:

• LLM Provider: เลือก openai (หากใช้ Local LLM ให้เลือก local)
• Model Name: ระบุโมเดลที่ต้องการใช้งาน
• Embedding Model: แนะนำให้ใช้โมเดล Embedding ของ OpenAI ตามค่าเริ่มต้น
• External Storage Backend: เลือก chroma (Local) หรือ postgres

การสร้างเอเจนต์เริ่มต้น

หลังจากตั้งค่าเสร็จสิ้น ให้สร้างเอเจนต์ด้วยคำสั่งต่อไปนี้

ในการเรียกใช้งานครั้งแรก ระบบจะขอให้คุณป้อน System Prompt (Persona/การตั้งค่าตัวละคร) และค่าเริ่มต้นของหน่วยความจำส่วนบุคคล (Archival Memory)

«MemGPT นำมาใช้แล้ว แต่ควบคุมไม่ได้ว่า Agent จะเขียนหรืออ่านความจำเมื่อใด» เป็นเสียงที่ได้ยินบ่อยในสภาพแวดล้อมการพัฒนา ใน MemGPT การควบคุมนี้ทำได้ผ่านกลไก Function Call (การเรียกใช้ฟังก์ชัน)

Agent ของ MemGPT จะจัดการความจำโดยการเรียกใช้ฟังก์ชันเฉพาะดังต่อไปนี้ควบคู่ไปกับการตอบสนองด้วยข้อความปกติในรูปแบบ Output ของ LLM

• core_memory_append: เพิ่มข้อมูลต่อท้ายในพื้นที่ความจำถาวรภายใน Main Context
• core_memory_replace: อัปเดตทับรายการความจำที่มีอยู่เดิม
• archival_memory_insert: บันทึกข้อมูลลงใน External Storage ระยะยาว
• archival_memory_search: ดึงข้อมูลจาก External Storage โดยใช้คีย์เวิร์ดหรือความคล้ายคลึงเชิงความหมาย

ฟังก์ชันเหล่านี้ถูกฝังไว้เป็น Definition ใน System Prompt และตัว LLM เองจะอนุมานและตัดสินใจว่า «ควรเรียกใช้ฟังก์ชันใด» ตัวอย่างเช่น หากผู้ใช้พูดว่า «ต่อจากนี้ให้โอนงานนี้ให้ผู้รับผิดชอบ A» Agent จะเรียกใช้ core_memory_replace เพื่ออัปเดตข้อมูลผู้รับผิดชอบตามลำดับขั้นตอนดังกล่าว

ประเด็นที่ควรระวังในการ Implement มีดังต่อไปนี้ 3 ข้อ

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

GraphRAG เป็นโปรเจกต์ที่ Microsoft Research เปิดตัวเมื่อเดือนกุมภาพันธ์ 2024 โดยมีจุดเด่นคือการแปลงข้อความเป็นโครงสร้างกราฟ ซึ่งช่วยให้สามารถสืบค้นข้อมูลโดยยังคงรักษาความสัมพันธ์ระหว่างเอนทิตีไว้ได้

ในตอนแรก หลายคนมักคิดว่า "ยิ่งสกัด Entity ออกมาได้มากเท่าไหร่ ความแม่นยำก็จะยิ่งสูงขึ้น" แต่ในความเป็นจริงแล้ว การจำกัดความละเอียด (Granularity) ของ Entity ให้เหลือเพียงหน่วยที่มีความหมายทางธุรกิจจะช่วยให้คุณภาพการค้นหาดีขึ้น การสกัดข้อมูลที่มากเกินไปจะเพิ่ม Noise ให้กับกราฟ และเป็นสาเหตุที่ทำให้ต้นทุนในการค้นหาเส้นทาง (Path exploration cost) ในระหว่างการ Query สูงขึ้น

หลักการพื้นฐานในการออกแบบ Entity

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

• การระบุโดเมนเป้าหมาย: คัดแยกกลุ่มคำนามที่ปรากฏซ้ำๆ ในการทำงาน เช่น "ลูกค้า" (Customer), "โปรเจกต์" (Project), "ผู้รับผิดชอบ" (Person in charge), "ผลิตภัณฑ์" (Product), "วันที่" (Date)
• การกำหนดความละเอียดให้เป็นมาตรฐาน: กำหนดกฎสำหรับการทำ Normalization ล่วงหน้า เพื่อให้ "บริษัท A จำกัด" และ "บริษัท A" เป็น Entity เดียวกัน
• การตั้งกฎการยกเว้น: ยกเว้นคำนามทั่วไปหรือ Stop words ที่พบบ่อยออกจากรายการ Entity เพื่อป้องกันไม่ให้กราฟมีขนาดใหญ่เกินไป

จุดสำคัญในการกำหนด Relation

ความสัมพันธ์ระหว่าง Entity (Relation) โดยพื้นฐานแล้วควรนิยามโดยใช้คำกริยาเป็นหลัก ตัวอย่างเช่น การใช้คำกริยาที่สอดคล้องกับขั้นตอนการทำงาน เช่น "รับผิดชอบ" (Responsible for), "อนุมัติ" (Approved), "ขึ้นอยู่กับ" (Depends on) จะช่วยให้สามารถดึงเส้นทางที่ต้องการในการทำ Graph Query ในภายหลังได้ง่ายขึ้น

ในเอกสารของ GraphRAG มีการระบุตัวอย่างการตั้งค่า Text chunk size ไว้ที่ 50–100 tokens ซึ่งต้องระวังว่ายิ่ง Chunk มีขนาดเล็กเท่าไหร่ ก็จะยิ่งจับความสัมพันธ์แบบ Co-occurrence ในระดับท้องถิ่นของ Entity ได้ง่ายขึ้น แต่ในขณะเดียวกันก็จะทำให้ต้นทุนในการสกัดกราฟเพิ่มสูงขึ้นด้วย

การระบุให้ชัดเจนว่าการกำหนด Relation นั้นเป็น "แบบสองทิศทาง (Bidirectional)" หรือ "แบบทิศทางเดียว (Unidirectional)" จะช่วยรักษาความสอดคล้องในการออกแบบ Query ได้เป็นอย่างดี

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

ขั้นตอนพื้นฐานของไปป์ไลน์ มีดังนี้:

1. การประมวลผลล่วงหน้า (Chunking): ในเอกสารของ GraphRAG ได้ระบุตัวอย่างการตั้งค่าขนาดของ Text Chunk ไว้ที่ 50–100 tokens สำหรับเอกสารที่มีการแบ่งบริบทชัดเจน เช่น รายงานการประชุมหรือเอกสารข้อกำหนด การใช้ Chunk ขนาดเล็กจะมีประสิทธิภาพมากกว่า แต่หากเป็นเอกสารที่มีความเชื่อมโยงระหว่างย่อหน้าสูง เช่น รายงานฉบับยาวหรือสัญญา การตั้งค่า Chunk ให้ใหญ่ขึ้นเล็กน้อยมักจะช่วยเพิ่มความแม่นยำในการดึงข้อมูลเอนทิตี (Entity) ได้
2. การดึงข้อมูลเอนทิตีและความสัมพันธ์ (Entity & Relation Extraction): ใช้ LLM ในการดึงข้อมูลเอนทิตีและความสัมพันธ์ออกจาก Chunk ต่างๆ เอกสารระบุว่าขั้นตอนนี้ใช้ต้นทุนประมาณ 75% ของการสร้างดัชนีกราฟ (Graph Index) ดังนั้นจึงควรประเมินความสมดุลระหว่างปริมาณการประมวลผลและต้นทุนไว้ล่วงหน้า
3. การสร้างและจัดเก็บกราฟ (Graph Construction & Storage): จัดเก็บผลลัพธ์ที่ได้ลงใน Graph DB (เช่น Neo4j) หรือที่จัดเก็บข้อมูลภายในของ GraphRAG

เกณฑ์การตัดสินใจตามประเภทเอกสาร: สำหรับความรู้ภายในองค์กร (เช่น FAQ หรือคู่มือการปฏิบัติงาน) ที่มีการอัปเดตไม่บ่อยนัก การออกแบบให้ประมวลผลแบบ Batch เพื่อทำดัชนีใหม่เป็นระยะถือเป็นวิธีที่สมเหตุสมผล ในทางกลับกัน หากเป็นข้อมูลที่มีการเปลี่ยนแปลงรวดเร็ว เช่น บันทึกการทำงานรายวันหรือบันทึก CRM การเตรียมไปป์ไลน์สำหรับดึงข้อมูลส่วนต่าง (Differential Extraction) เพื่ออัปเดตกราฟแบบเพิ่มข้อมูล (Incremental) จะเป็นโครงสร้างที่เหมาะสมกว่า

"สร้างกราฟเสร็จแล้ว แต่จะส่งคำถาม (Query) อย่างไรให้ได้บริบททางธุรกิจออกมาจริง ๆ" เป็นคำถามที่พบบ่อยในหน้างานจริง

ใน GraphRAG เราจะใช้โหมดการค้นหาหลัก 2 รูปแบบสำหรับ Knowledge Graph ที่สร้างขึ้น:

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

ขั้นตอนพื้นฐานในการนำไปใช้งานมีดังนี้:

1. แปลงสตริงของคำถามให้เป็น Entity ที่เป็นไปได้ แล้วระบุโหนดที่เกี่ยวข้องภายในกราฟ
2. ขยายขอบเขตจากโหนดไปยัง Edge ข้างเคียงและ Community ที่เกี่ยวข้องเพื่อดึง Subgraph ออกมา
3. นำข้อความที่แสดงถึง Subgraph นั้นไปใส่ในบริบทของ LLM เพื่อสร้างคำตอบ

สำหรับขนาดของ Chunk นั้น เอกสารแนะนำค่ามาตรฐานไว้ที่ 50-100 tokens ยิ่งแบ่งย่อยมากเท่าไร ความละเอียดของโหนดก็จะยิ่งสูงขึ้นและมักจะช่วยเพิ่มความแม่นยำ แต่ในขณะเดียวกันก็จะทำให้ต้นทุนในการสกัดกราฟเพิ่มขึ้นด้วย ทั้งนี้ เอกสารระบุว่าการสกัดกราฟคิดเป็นประมาณ 75% ของต้นทุนการสร้าง Index ทั้งหมด ดังนั้นการตั้งค่าขนาด Chunk จึงจำเป็นต้องคำนึงถึงการแลกเปลี่ยน (Trade-off) ระหว่างต้นทุนและความแม่นยำเป็นสำคัญ

บทสรุป: การบูรณาการ MemGPT และ GraphRAG เข้าด้วยกัน จะช่วยสร้างรากฐานหน่วยความจำระยะยาวที่แข็งแกร่ง ซึ่งผสมผสานการจัดการหน่วยความจำข้ามเซสชันเข้ากับการสืบค้นผ่านกราฟความรู้ (Knowledge Graph)

กุญแจสำคัญสู่ความสำเร็จในการบูรณาการคือการกำหนดบทบาทหน้าที่ของทั้งสองส่วนให้ชัดเจน พร้อมทั้งตั้งค่าทริกเกอร์สำหรับการเขียนข้อมูล (Write Triggers) และการให้คะแนนการสืบค้น (Search Scoring) อย่างเหมาะสม

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

ในสถาปัตยกรรมแบบบูรณาการ เราจะกำหนดความรับผิดชอบให้แต่ละส่วนประกอบดังนี้:

• MemGPT (ชั้นหน่วยความจำเซสชัน): จัดการประวัติการสนทนาล่าสุด สถานะการทำงานของผู้ใช้ และคำสั่งระยะสั้นในบริบทหลัก (Main Context) และย้ายข้อมูลไปยังที่จัดเก็บภายนอกเมื่อความจุเกิน
• GraphRAG (ชั้นกราฟความรู้): เก็บความสัมพันธ์ระหว่างเอนทิตี กฎทางธุรกิจ และข้อมูลที่มีโครงสร้างของโปรเจกต์ในอดีต เพื่อให้สามารถสืบค้นผ่านความเชื่อมโยงเชิงความหมายได้
• Orchestrator: รับอินพุตจากผู้ใช้ อ้างอิงบริบทจาก MemGPT จากนั้นส่งคำสั่ง (Query) ไปยัง GraphRAG ตามความจำเป็นเพื่อรวมผลลัพธ์เข้าด้วยกัน

กระแสข้อมูลจะถูกประมวลผลตามลำดับดังนี้:

1. อินพุตจากผู้ใช้ → Orchestrator ทำการจำแนกเจตนา
2. ตรวจสอบบริบทหลักของ MemGPT เพื่อตัดสินว่าสามารถแก้ไขปัญหาภายในเซสชันได้หรือไม่
3. หากไม่สามารถแก้ไขได้ ให้ส่งคำสั่งค้นหาเอนทิตีไปยัง GraphRAG
4. นำความรู้ที่ได้รับมาใส่ในบริบทหลักเพื่อให้ LLM สร้างคำตอบ
5. ข้อมูลสำคัญจะถูกเขียนลงในที่จัดเก็บภายนอกของ MemGPT เพื่อส่งต่อไปยังเซสชันถัดไป

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

การตัดสินใจว่าจะเขียนข้อมูลลงในหน่วยความจำเมื่อใดและอย่างไร ถือเป็นหัวใจสำคัญในการออกแบบที่ส่งผลต่อคุณภาพของระบบหน่วยความจำระยะยาว (Long-term memory system)

ทริกเกอร์สำหรับการเขียนข้อมูลสามารถแบ่งออกได้เป็น 3 ประเภทหลัก ดังนี้:

• แบบขับเคลื่อนด้วยเหตุการณ์ (Event-driven): เขียนข้อมูลเมื่อผู้ใช้สั่งให้ "จำไว้" อย่างชัดเจน หรือเมื่อเกิดเหตุการณ์ทางธุรกิจ เช่น การทำภารกิจเสร็จสิ้น หรือการอนุมัติ
• แบบอิงการอนุมาน (Inference-based): เอเจนต์ประเมินเนื้อหาการสนทนาและเขียนข้อมูลโดยอัตโนมัติเมื่อคะแนนความสำคัญสูงเกินเกณฑ์ที่กำหนด
• แบบประมวลผลเป็นรอบ (Periodic batch): สร้างและบันทึกสรุปข้อมูลในช่วงเวลานั้นๆ เมื่อจบเซสชันหรือตามระยะเวลาที่กำหนด

ในการออกแบบนโยบายการอัปเดต (Update policy) การระบุเงื่อนไขการทำงานให้ชัดเจนเป็นสิ่งสำคัญ โดยต้องแยกนโยบายให้ชัดเจนว่า หากข้อมูลใหม่เกี่ยวกับเอนทิตี (Entity) เดียวกันไม่ขัดแย้งกับความจำเดิมให้ใช้วิธีการเพิ่มข้อมูลต่อท้าย (Append) แต่หากพบว่าขัดแย้งหรือข้อมูลเดิมล้าสมัยให้ใช้วิธีการเขียนทับ (Overwrite)

คุณเคยรู้สึกไหมว่า "ทำไมคำตอบของ Agent ถึงดูไม่ตรงประเด็น ทั้งที่ดึงโหนดที่เกี่ยวข้องมาจาก GraphRAG แล้ว" สาเหตุส่วนใหญ่มักเกิดจากการที่การออกแบบการให้คะแนน (Scoring) ในการค้นหา ไม่สอดคล้องกับความสำคัญของงานจริง

ในสภาพแวดล้อมที่รวม MemGPT และ GraphRAG เข้าด้วยกัน การใช้ปัจจัยต่อไปนี้ร่วมกันในการให้คะแนนผลลัพธ์การค้นหาถือว่ามีประสิทธิภาพ:

• ความคล้ายคลึงเชิงความหมาย (Semantic Similarity): คะแนนพื้นฐานจากระยะห่างของเวกเตอร์
• ความใกล้ชิดในกราฟ (Graph Proximity): จำนวน Hop จากโหนดเป้าหมายไปยังเอนทิตีที่อ้างอิง (ยิ่งใกล้ ยิ่งได้คะแนนสูง)
• น้ำหนักความสดใหม่ (Recency Weight): การลดทอนคะแนนของหน่วยความจำเก่าลงตามลำดับโดยอิงจาก Timestamp
• ความถี่ในการเข้าถึง (Access Frequency): การบวกคะแนนเพิ่มตามจำนวนครั้งที่เคยถูกอ้างอิง เพื่อให้ความสำคัญกับหน่วยความจำที่ผ่านการใช้งานจริง

การนำปัจจัยทั้ง 4 ประการนี้มาคำนวณแบบ Linear Combination และปรับน้ำหนักตามประเภทของงาน จะช่วยให้สามารถจัดลำดับผลการค้นหาที่ตรงกับบริบททางธุรกิจได้

กลยุทธ์การสำรองข้อมูล (Fallback Strategy) ก็มีความสำคัญไม่แพ้กัน หากการสืบค้นด้วยกราฟ (Graph Query) ของ GraphRAG ให้ผลลัพธ์ว่างเปล่า แล้วส่งต่อไปยัง Agent โดยตรง จะทำให้คุณภาพของคำตอบลดลงอย่างมาก เราขอแนะนำกลยุทธ์ Fallback 3 ขั้นตอน ดังนี้:

1. Graph Query — ค้นหาความสัมพันธ์ของเอนทิตีเป็นอันดับแรก
2. Vector Search (Standard RAG) — ดำเนินการหากไม่พบข้อมูลในกราฟ
3. MemGPT Summary Memory — อ้างอิงหาก 2 วิธีแรกได้คะแนนต่ำ

เมื่อมีการเรียกใช้ Fallback ให้ทำการบันทึก Flag ลงใน Log เพื่อใช้เป็นตัวกระตุ้น (Trigger) ในการอัปเดตกราฟในภายหลัง ซึ่งจะช่วยให้สามารถเติมเต็มช่องว่างของหน่วยความจำได้อย่างต่อเนื่อง

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

ทันทีที่เริ่มนำหน่วยความจำระยะยาว (Long-term memory) มาใช้ หลายทีมมักมีแนวโน้มที่จะใช้นโยบาย "บันทึกทุกอย่างที่สามารถบันทึกได้" แต่ในความเป็นจริง มีรายงานว่ายิ่งจำนวนรายการ (Entry) เพิ่มมากขึ้น ค่าความหน่วงในการค้นหา (Search latency) จะยิ่งแย่ลงในระดับที่มากกว่าเชิงเส้น (Linear) จนกลายเป็นคอขวดของความเร็วในการตอบสนอง การออกแบบเพื่อจำกัดปริมาณการจัดเก็บข้อมูลจึงเป็นกุญแจสำคัญในการรักษาประสิทธิภาพในระยะยาว

มาตรการหลักในการป้องกันข้อมูลบวม (Bloating) มีดังนี้:

• การตั้งค่า TTL (Time To Live): กำหนดวันหมดอายุให้กับหน่วยความจำเชิงเหตุการณ์ (Episodic memory) เพื่อจัดเก็บถาวรหรือลบรายการที่ไม่มีการอ้างอิงในช่วงเวลาที่กำหนดโดยอัตโนมัติ สำหรับข้อมูลที่ความสดใหม่มีความสำคัญ เช่น บันทึกการทำงาน ควรออกแบบโดยใช้ TTL ประมาณ 30-90 วัน
• การจัดการลำดับความสำคัญด้วยคะแนนความสำคัญ (Importance Score): กำหนดคะแนนความสำคัญในขณะเขียนข้อมูลผ่านฟังก์ชันคอล (Function call) ของ MemGPT โดยรายการที่มีคะแนนต่ำจะถูกบีบอัดหรือสรุปก่อนจัดเก็บ การแทนที่ด้วยรายการสรุปแทนการเก็บต้นฉบับที่ละเอียดไว้ทั้งหมด จะช่วยลดทั้งพื้นที่จัดเก็บและต้นทุนในการค้นหาไปพร้อมกัน
• การปรับขนาด Chunk ให้เหมาะสมในฝั่ง GraphRAG: ตามเอกสารประกอบ ตัวอย่างการตั้งค่าขนาด Chunk ของข้อความอยู่ที่ 50-100 tokens การแบ่ง Chunk ที่ละเอียดเกินไปจะนำไปสู่การเพิ่มขึ้นของจำนวนโหนดอย่างมหาศาล จึงจำเป็นต้องปรับให้เหมาะสมกับความละเอียดของเอกสารงาน
• การตัดแต่งกราฟเป็นระยะ (Graph Pruning): ลบโหนดที่โดดเดี่ยวหรือเส้นเชื่อม (Edge) ที่มีการอ้างอิงต่ำด้วยการประมวลผลแบบแบตช์เป็นระยะ เพื่อรักษาความหนาแน่นของกราฟให้อยู่ในระดับที่เหมาะสม

การผสมผสานมาตรการเหล่านี้จะช่วยให้สามารถรักษาสมดุลระหว่างความสดใหม่ของหน่วยความจำและความเร็วในการค้นหาได้

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

แนวทางหลักในการตรวจจับความขัดแย้งมี 2 วิธีดังนี้:

• การเปรียบเทียบ Timestamp: หากมีหลายรายการสำหรับเอนทิตีและคุณลักษณะเดียวกัน ให้ถือว่ารายการที่มี Timestamp ล่าสุดเป็นข้อมูลที่ถูกต้อง และกำหนดสถานะ "obsolete" ให้กับรายการที่เก่ากว่า
• การตรวจสอบความคล้ายคลึงโดยใช้ Embedding: เมื่อมีการบันทึกรายการใหม่ ให้ดึงรายการที่มีอยู่เดิมซึ่งมีค่า Cosine similarity เกินเกณฑ์ที่กำหนด (เช่น 0.90 ขึ้นไป) ออกมาเป็นตัวเลือก แล้วให้ LLM เป็นผู้ตัดสินว่ามีความขัดแย้งหรือไม่

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

หากใช้ GraphRAG การออกแบบโดยบันทึกประวัติการเปลี่ยนแปลงคุณลักษณะของโหนด (Node attributes) ไว้เป็น Edge จะช่วยในการติดตามความขัดแย้งได้ ในส่วนของ MemGPT แนะนำให้ฝังตรรกะการตรวจสอบข้อมูลซ้ำลงในฟังก์ชันการเขียนไปยัง archival storage และใช้การตั้งค่าให้เอเจนต์ดำเนินการตรวจสอบขั้นตอนดังกล่าวด้วยตนเองเมื่อตรวจพบความขัดแย้งที่อาจเกิดขึ้น