ความจำ AI agent ไม่ใช่ประวัติแชต: เก็บทุกอย่างยิ่งเรียกผิดบริบท

ความจำของ AI agent ควรแยกตามหน้าที่ก่อนแยกตามระยะเวลา: state เก็บสถานะของงานที่กำลังเดินอยู่, scratchpad เก็บบันทึกชั่วคราว, โปรไฟล์เก็บข้อเท็จจริงเฉพาะผู้ใช้ที่ยังใช้ได้ และความรู้ระยะยาวเก็บข้อมูลที่ได้รับอนุญาตให้ใช้ซ้ำข้ามเซสชัน การเก็บประวัติแชตทั้งหมดไว้ในที่เดียวทำให้ระบบแยกคำสั่งเฉพาะครั้งออกจากข้อมูลถาวรได้ยาก และเพิ่มโอกาสเรียกเรื่องเก่ามาใส่งานใหม่

ให้ผูก state กับงานและ thread ส่วนโปรไฟล์กับความรู้ระยะยาวต้องมีเจ้าของ ขอบเขตการใช้ และกฎหมดอายุของตนเอง ก่อนส่งข้อมูลกลับเข้าโมเดลให้กรองตามสิทธิ์ งานปัจจุบัน และความใหม่ แล้วค่อยเลือกเฉพาะส่วนที่ช่วยตอบคำถาม คู่มือ LangGraph ใช้ state เป็นข้อมูลร่วมระหว่างขั้นตอน และใช้ checkpointer กับ thread_id เพื่อกลับมาทำงานในบทสนทนาเดิม

แยกข้อมูลตามหน้าที่ก่อนเลือกว่าจะเก็บที่ไหน

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

• State คือข้อมูลที่ขั้นตอนถัดไปของงานเดียวกันต้องใช้ เช่น เป้าหมายที่เพิ่งตกลง ผลการจัดประเภทอีเมล ผลจากเครื่องมือที่ยังเกี่ยวข้อง และร่างคำตอบที่รออนุมัติ เก็บพร้อมตัวระบุงานและ thread เพื่อให้การกลับมาทำงานต่อมีจุดเริ่มที่ชัดเจน เมื่อปิดงานให้จัดการ checkpoint ตามนโยบายเก็บรักษา ไม่ยกทั้ง state ไปเป็นโปรไฟล์ผู้ใช้
• Scratchpad คือพื้นที่สำหรับแผนย่อย คำถามที่ต้องตรวจ และร่างระหว่างทาง อาจอยู่ใน state หรือพื้นที่ชั่วคราวแยกต่างหากก็ได้ แต่ต้องมีขอบเขตของงานที่ชัดเจน สิ่งที่เอเจนต์คาดเดาในพื้นที่นี้ยังไม่ใช่ข้อเท็จจริง เมื่องานจบให้ลบทิ้งหรือย้ายเฉพาะข้อสรุปที่ผ่านเกณฑ์บันทึก
• โปรไฟล์ คือข้อกำหนดเกี่ยวกับผู้ใช้ซึ่งมีผลต่อคำตอบในอนาคต เช่น ภาษาที่เจ้าตัวต้องการใช้เป็นปกติ หรือรูปแบบคำตอบที่ยืนยันว่าใช้กับงานประเภทหนึ่ง ควรเก็บแหล่งที่มา ขอบเขต และเวลายืนยันไว้ด้วย คำขอให้ตอบสั้นในครั้งเดียวไม่ควรถูกตีความเป็นความชอบถาวร
• ความรู้ระยะยาว คือข้อเท็จจริงหรือวิธีทำงานที่มีโอกาสใช้ซ้ำได้โดยชอบในเซสชันใหม่ เช่น ขั้นตอนบริการที่ทีมอนุมัติหรือคำอธิบายโครงการที่ยังใช้ได้ ต้องระบุเจ้าของและแหล่งต้นทาง หากระบบต้นทางเปลี่ยนบ่อย ให้ดึงข้อมูลจากระบบนั้นเมื่อจำเป็นแทนการเก็บสำเนาที่อาจล้าสมัย

ตัวอย่างสมมติ: เอเจนต์กำลังร่างอีเมลตอบคำร้องของลูกค้า อีเมลต้นทาง ผลจัดประเภท และร่างที่รออนุมัติเป็น state; รายการประเด็นที่ยังต้องตรวจเป็น scratchpad หากผู้ใช้ยืนยันว่าต้องการคำตอบภาษาไทยทุกครั้ง ข้อกำหนดนั้นจึงเป็นโปรไฟล์ ส่วนแนวทางจัดการคำร้องที่ทีมอนุมัติอาจเป็นความรู้ร่วมของทีม ความแตกต่างอยู่ที่ผู้ใช้ข้อมูลและเวลาที่ต้องใช้ ไม่ได้อยู่ที่ข้อมูลนั้นเคยปรากฏในแชตหรือไม่

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

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

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

กำหนดอายุจากเหตุการณ์ที่ทำให้ข้อมูลหมดหน้าที่

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

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

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

โปรไฟล์มีอายุยาวกว่า thread แต่ไม่ได้คงอยู่ตลอดไป ความต้องการด้านภาษาอาจเปลี่ยนได้เมื่อผู้ใช้เปลี่ยนบทบาทหรือชนิดงาน ควรมีช่องให้แก้ ลบ หรือจำกัดขอบเขต เช่น ใช้กับงานส่วนตัวแต่ไม่ใช้กับงานของทีม เวลายืนยันครั้งล่าสุดช่วยให้ตัดสินใจได้ว่าควรถามซ้ำเมื่อใด โดยไม่ต้องสมมติว่าข้อมูลเก่ายังถูกต้องเสมอ

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

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

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

ใช้ namespace เป็นขอบเขตเจ้าของข้อมูล

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

โครงสร้างสมมติอย่าง tenant/app/user/type ใช้กับโปรไฟล์ส่วนบุคคล ส่วน tenant/app/team/type ใช้กับความรู้ที่ทีมตกลงให้แชร์ ค่า tenant และ user ต้องมาจากข้อมูลยืนยันตัวตนของระบบ ไม่ใช่ชื่อที่ปรากฏในข้อความ ผู้ใช้สองรายอาจมีชื่อเล่นเหมือนกัน หรือคำถามอาจกล่าวถึงบุคคลอื่น การใช้ข้อความสนทนาเป็นตัวเลือก namespace จึงเปิดช่องให้เลือกเจ้าของผิด

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

thread_id มีหน้าที่ระบุตำแหน่งสถานะที่ค้างอยู่ ไม่ใช่หลักฐานว่าผู้เรียกมีสิทธิ์เปิดสถานะนั้น เมื่อมีคำขอกลับไปทำงานต่อ ระบบควรตรวจว่า thread นี้อยู่ใน tenant และบัญชีที่ได้รับอนุญาต แล้วจึงอ่าน checkpoint หลักเดียวกันใช้เมื่อส่งต่อบทสนทนาระหว่างผู้ปฏิบัติงาน เพราะผู้รับงานอาจมีสิทธิ์เห็นเฉพาะส่วนที่จำเป็น

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

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

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

ค้นคืนตามสิทธิ์ งาน และความใหม่ ก่อนจัดอันดับความคล้าย

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

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

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

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

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

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

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

อัปเดตข้อเท็จจริงเดิมแทนการสะสมรายการขัดกัน

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

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

ตัวอย่างสมมติ: ผู้ใช้เคยขอให้ตอบภาษาอังกฤษเฉพาะงานหนึ่ง แล้วภายหลังยืนยันว่าในงานบริการลูกค้าให้ตอบภาษาไทยเสมอ ระบบควรเก็บความชอบใหม่โดยจำกัดชนิดงาน และปล่อยให้คำขอครั้งก่อนอยู่เพียงใน thread เดิม หากระบบเคยสร้างโปรไฟล์ภาษาอังกฤษผิดไว้ ต้องลบหรือเลิกใช้รายการนั้นพร้อมแก้ดัชนีค้นหา ไม่ใช่เขียนโปรไฟล์ภาษาไทยเพิ่มแล้วหวังให้โมเดลเลือกเอง

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

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

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

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

ทดสอบให้เห็นทั้งสิ่งที่ค้นได้และสิ่งที่โมเดลได้รับ

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

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

ทดสอบการกลับไปยัง thread ที่ไม่ใช่ของบัญชีปัจจุบันด้วย เพราะ thread_id อาจถูกส่งผิดหรือถูกคัดลอกจากคำขออื่น ระบบต้องปฏิเสธก่อนอ่าน checkpoint และไม่ควรเผยแม้แต่สรุปของงานที่ค้างอยู่ อีกกรณีคือผู้ใช้คนเดิมมีหลายโครงการและถามด้วยถ้อยคำคล้ายกัน ระบบควรเลือก state และความรู้ของโครงการที่กำลังทำ ไม่ใช่ของโครงการที่มีข้อความใกล้เคียงกว่า

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

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

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

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

อ่านเพิ่มเติม:

• Docker หรือ DigitalOcean: sandbox สำหรับ AI agent คิดเงินคนละจังหวะ