ลูกค้าเปลี่ยนสถานที่ส่งของระหว่างการคุยงานที่ยาวขึ้น แต่เมื่อถึงเวลาสรุป Agent กลับใช้ที่อยู่เดิมอย่างมั่นใจ ปัญหาอาจอยู่ที่ข้อมูลซึ่งถูกเลือกมาให้ตัดสินใจในรอบนั้น ไม่ใช่เพียงความสามารถในการเข้าใจข้อความล่าสุด การเพิ่มขนาด Context อย่างเดียวไม่ได้ช่วยตัดสินว่าข้อมูลรุ่นใดเป็นข้อมูลที่ควรใช้
สำหรับ Agent ในธุรกิจ Context คือข้อมูลที่นำมาใช้กับการตัดสินใจครั้งปัจจุบัน ส่วน Memory คือข้อมูลที่เก็บไว้ใช้ภายหลัง ทั้งสองอย่างไม่ควรทำหน้าที่แทนระบบที่เป็นเจ้าของออร์เดอร์ การอนุมัติ หรือข้อมูลลูกค้า สิ่งที่ต้องออกแบบคือการเลือกข้อเท็จจริงที่เกี่ยวข้อง รู้ที่มาและขอบเขต และเลิกใช้สมมติฐานที่หมดอายุแล้ว
เริ่มจากงานที่ข้อมูลเปลี่ยนระหว่างทาง
ลองดูตัวอย่างสมมติของงานติดตั้ง ลูกค้าเริ่มจากขอเข้าบริการวันธรรมดาที่สำนักงานใหญ่ ต่อมาเปลี่ยนเป็นสาขาและขอวันหยุด ขณะที่ช่างประเมินสถานที่เดิมไปแล้ว Agent ต้องเก็บผลประเมินเดิมเป็นประวัติ ระบุว่าการเปลี่ยนสถานที่ทำให้ส่วนใดใช้ต่อไม่ได้ และขอตรวจเวลานัดใหม่ การนำผลประเมินเก่ามารวมกับสถานที่ใหม่แล้วเสนอแผนทันทีจึงผิดในสาระสำคัญ
ก่อนเรียกโมเดล ให้ระบุว่าการตัดสินใจขั้นถัดไปต้องรู้อะไร เช่น สถานที่ปัจจุบัน ช่วงเวลาที่ต้องการ เงื่อนไขที่ยังไม่ตกลง การยืนยันล่าสุด และนโยบายบริการ ประวัติแชททั้งหมดอาจมีข้อมูลเหล่านี้ แต่มีตัวเลือกที่ยกเลิกไปแล้วปะปนด้วย ระบบจึงควรมีข้อมูลเคสปัจจุบัน และเรียกข้อความหลักฐานมาเพิ่มเมื่อจำเป็น
แยกคำขอล่าสุด ข้อเท็จจริงที่ยืนยันแล้ว ข้อสันนิษฐาน และข้อมูลประกอบออกจากกัน สิ่งที่โมเดลตีความเองต้องอยู่ในกลุ่มข้อสันนิษฐานจนกว่าจะตรวจสอบ การเขียนข้อความเดิมซ้ำในสรุปหลายรอบไม่ได้ทำให้ข้อความนั้นกลายเป็นข้อเท็จจริง
กำหนดขอบเขตให้ความจำแต่ละชนิด
LangGraph แยกสถานะระดับบทสนทนาออกจากข้อมูลที่เก็บข้ามบทสนทนา และมีตัวอย่างใช้ฐานข้อมูลรองรับการเก็บสถานะในระบบจริง ความแตกต่างนี้ช่วยเลือกวิธีจัดเก็บ แต่ตัวแอปยังต้องกำหนดว่าข้อมูลแต่ละรายการเป็นของลูกค้า ผู้ใช้ หรือโครงการใด เอกสาร Memory ของ LangGraph
| ข้อมูล | ที่เก็บที่ควรพิจารณา | เงื่อนไขก่อนใช้ซ้ำ |
|---|---|---|
| คำขอปัจจุบันและคำถามค้าง | สถานะของเคส | เป็นเคสเดียวกันและข้อมูลรุ่นปัจจุบัน |
| สถานที่ส่งของที่ยืนยันแล้ว | ระบบออร์เดอร์หรือข้อมูลลูกค้าหลัก | อ่านค่าปัจจุบันก่อนสั่งงานที่มีผลจริง |
| รูปแบบการเขียนที่ผู้ใช้ชอบ | ที่เก็บความชอบแบบมีขอบเขต | ผู้ใช้และวัตถุประสงค์ตรงกัน ข้อมูลยังใช้ได้ |
| สิ่งที่ผู้ขายกล่าวอ้าง | หลักฐานพร้อมแหล่งที่มา | ยังถือเป็นคำกล่าวอ้างจนกว่าจะตรวจ |
| การอนุมัติให้ทำรายการหนึ่ง | บันทึกการอนุมัติ | รายละเอียดตรงกับที่อนุมัติและผู้อนุมัติมีสิทธิ์ |
การแยกเช่นนี้ช่วยป้องกันการนำความจำว่าเคยอนุมัติเมื่อสัปดาห์ก่อน มาใช้กับอีกออร์เดอร์ในวันนี้ Memory ช่วยค้นการอนุมัติเก่าได้ แต่ไม่ทำให้ขอบเขตการอนุมัติขยายตามไปด้วย เช่นเดียวกับการจำว่าลูกค้าชอบรับอีเมล ไม่ได้ให้สิทธิ์ส่งเอกสารลับไปยังที่อยู่ที่พบในไฟล์
เอกสาร Long-term memory ของ LangChain อธิบายการจัดข้อมูลด้วย Namespace และ Key สามารถนำมาแบ่งตามลูกค้า ผู้ใช้ หรือโครงการได้ แต่ต้องตรวจสิทธิ์ในตัวแอปด้วย ชื่อ Namespace ที่โมเดลส่งมาไม่ใช่หลักฐานว่าผู้ใช้มีสิทธิ์อ่านข้อมูลกลุ่มนั้น เอกสาร Long-term memory ของ LangChain
ทำสรุปสำหรับงานถัดไป ไม่ใช่ย่อทุกอย่างให้เล็กลง
สรุปการทำงานควรทำให้เข้าใจขั้นถัดไปได้ สำหรับเคสติดตั้ง อาจประกอบด้วยเป้าหมาย ข้อมูลปัจจุบันที่ยืนยันแล้ว ตัวเลือกที่ยกเลิก คำถามค้าง งานที่ทำเสร็จ และแหล่งหลักฐาน เก็บรหัสและรุ่นข้อมูลให้ตรง หากเปลี่ยนสถานที่ ต้องรักษาความสัมพันธ์ด้วยว่าผลประเมินก่อนหน้าใช้ไม่ได้แล้ว สรุปที่สั้นลงแต่ทำความหมายส่วนนี้หายย่อมไม่ช่วยงาน
Anthropic อธิบายการย่อบริบทหรือ Compaction และการจดข้อมูลที่เก็บต่อเนื่อง เพื่อจัดการงานที่กินเวลาหลายรอบ วิธีเหล่านี้ช่วยลดข้อมูลในหน้าต่างปัจจุบัน แต่ผลลัพธ์ขึ้นกับสิ่งที่ยังเหลืออยู่หลังย่อ แนวทางจัดการ Context จาก Anthropic
กำหนดช่องข้อมูลในสรุปให้ชัด แทนการขอให้โมเดลเขียนย่อหน้าอิสระเพียงอย่างเดียว ข้อเท็จจริงสำคัญควรมีแหล่งอ้างอิง สถานะยืนยัน และเวลาที่ปรับล่าสุด ส่วนหลักฐานเต็มเก็บแยกไว้ให้ย้อนดูได้ ผู้ตรวจจึงแก้ความคลุมเครือได้โดยไม่ต้องนำประวัติทั้งหมดกลับเข้าโมเดล
เมื่อข้อมูลเปลี่ยนมาก ให้สร้างส่วนที่ได้รับผลกระทบใหม่จากข้อมูลหลัก ไม่ควรย่อสรุปเก่าต่อกันไปเรื่อย ๆ จนความไม่แน่นอนหายไปจากถ้อยคำ ก่อนสั่งงานสำคัญให้เทียบข้อมูลที่จะส่งกับค่าปัจจุบันอีกครั้ง ไม่ถือว่าสรุปที่เตรียมไว้ก่อนหน้านั้นยังถูกต้องเสมอ
ออกแบบสิ่งที่ Agent ควรลืมด้วย
ความจำถาวรมีภาระดูแล ต้องกำหนดว่าใครแก้ความชอบที่บันทึกไว้ได้ ข้อสันนิษฐานควรมีอายุเท่าไร และเมื่อผู้ใช้ออกจากโครงการจะจัดการข้อมูลอย่างไร ระยะเวลาเก็บควรสอดคล้องกับวัตถุประสงค์ ไม่จำเป็นต้องเก็บทุกบทสนทนาตลอดไปเพื่อให้งานต่อเนื่อง
หน้าจอแก้ความจำที่ใช้งานได้ควรแสดงข้อมูลที่จำ แหล่งที่มา และส่วนที่นำไปใช้ เมื่อเจ้าหน้าที่เปลี่ยนหรือลบข้อมูล ต้องปรับสรุปหรือดัชนีค้นที่เกี่ยวข้องด้วย มิฉะนั้นหน้าจออาจบอกว่าลบแล้ว แต่สำเนาเก่ายังคงมีผลต่อคำตอบ
กำหนดข้อมูลที่ไม่ควรเก็บเป็นความจำทั่วไป เช่น รหัสผ่าน ลิงก์เข้าถึงชั่วคราว หรือรายละเอียดลับที่ไม่เกี่ยวกับงาน เก็บข้อมูลธุรกิจที่จำเป็นในระบบควบคุมสิทธิ์ และเลือกอ่านเฉพาะช่องที่ได้รับอนุญาตสำหรับงานปัจจุบัน
หากเป็นผู้ช่วยที่หลายทีมใช้ร่วมกัน ต้องทดลองเรื่องการแยกลูกค้าโดยตรง ลูกค้าคนละรายอาจใช้สินค้าชื่อเดียวกัน และพนักงานอาจชื่อคล้ายกัน ตัวตนต้องมาจากการล็อกอินและข้อมูลที่ตรวจแล้ว ไม่ใช่ให้โมเดลเดาว่าบทสนทนาเก่าใดฟังดูเกี่ยวข้อง
ทดสอบการทำงานต่อเมื่อข้อมูลเปลี่ยน
การทดสอบความจำควรมากกว่าถามว่า Agent จำชื่อได้หรือไม่ ลองทำงานเคสเดิมต่อหลังระบบเริ่มใหม่ เปลี่ยนข้อกำหนดสำคัญ ถอนสิทธิ์ เพิ่มเอกสารเก่าที่ขัดแย้ง และให้ Agent ระบุว่ายังติดเรื่องใดอยู่ คำตอบที่ถูกอาจเป็นการขอตรวจใหม่ ไม่ใช่ทำงานต่อทันที
ดูว่าใช้ข้อมูลยืนยันล่าสุด รักษาข้อจำกัดสำคัญ และไม่นำข้อมูลจากอีกเคสเข้ามาหรือไม่ ตรวจรายการที่จะส่งให้ระบบจริงด้วย การตอบรับว่าเปลี่ยนที่อยู่แล้วไม่มีประโยชน์ หากคำสั่งอัปเดตออร์เดอร์ยังเป็นที่อยู่เดิม
เก็บบันทึกบทสนทนา Context ที่เลือก การอ่านและเขียน Memory รวมถึงสถานะเคสหลังทำงานไว้ในพื้นที่ตรวจสอบที่ควบคุมสิทธิ์ ปัญหาอาจเกิดจากข้อมูลต้นทางผิด ค้นเจอรุ่นเก่า หรือโมเดลไม่ทำตามสรุปที่ถูกต้อง ซึ่งต้องแก้คนละจุด
หากผู้ช่วยต้องค้นเอกสารภายในด้วย ให้ออกแบบร่วมกับ ระบบค้นความรู้ของธุรกิจ และหากหลายทีมแก้ข้อมูลเดียวกัน ควรกำหนดก่อนว่า ระบบใดเป็นเจ้าของข้อมูลแต่ละชุด
Talvyn Labs ช่วยพัฒนาจากต้นแบบแชทให้เป็น AI Product ที่เก็บบริบทของเคส ดึงหลักฐานตามสิทธิ์ และผูกคำสั่งกับข้อมูลปัจจุบันได้ นำตัวอย่างบทสนทนาที่ผู้ช่วยหลงประเด็น พร้อมระบบที่ใช้อยู่มาเริ่มงาน เราจะใช้ปัญหานั้นกำหนดขอบเขตความจำ กรณีทดสอบ และขั้นตอนใช้งานที่ทีมต้องการจริง
พัฒนา Agent ที่ตามงานต่อได้ แม้ข้อมูลเปลี่ยนระหว่างทาง
ให้ Talvyn Labs ออกแบบบริบท ความจำ และการเชื่อมข้อมูลหลักจากเคสจริงของคุณ พร้อมเกณฑ์ตรวจว่าผู้ช่วยใช้ข้อมูลล่าสุดและไม่ข้ามสิทธิ์
เริ่มพัฒนา Agent สำหรับงานต่อเนื่อง