pipeline แบบ “dreaming” ของนักพัฒนาจะทำงานวันละสองครั้ง โดยการย่อข้อมูล event log ดิบของ LLM-agent ให้กลายเป็นหน่วยจัดเก็บความจำ (memory store) ที่กระชับและผ่านการตรวจสอบแล้ว ซึ่งช่วยลดค่าใช้จ่ายด้าน token ลงอย่างมาก เทคนิคนี้มีความสำคัญเพราะระบบ agent ส่วนใหญ่มักจะใส่รายละเอียดทุกอย่างที่เห็นลงในหน่วยความจำขณะทำงาน (working memory) จนแน่นเกินไป ซึ่งนำไปสู่ความขัดแย้งกันเอง การลืมบริบท และค่าใช้จ่าย API ที่พุ่งสูงขึ้นอย่างรวดเร็ว

ทำไมหน่วยความจำจึงสำคัญสำหรับ LLM agents

LLM agents จะมองว่าทุกคำขอของผู้ใช้, การเรียกใช้เครื่องมือ (tool call) หรือการสังเกตการณ์ภายใน (internal observation) คือ “event” ใหม่ วิธีการแบบพื้นๆ (naïve approach) คือการนำทุก event ไปต่อท้าย prompt ที่ใช้ในการตัดสินใจครั้งถัดไป ในทางปฏิบัติ สิ่งนี้จะทำให้ prompt เต็มไปด้วยข้อมูลขยะ (noise) บังคับให้โมเดลต้องประเมินข้อเท็จจริงที่ล้าสมัยใหม่ และผลักดันการใช้งาน token ไปสู่ระดับราคาที่สูงที่สุด ผลลัพธ์ที่ได้คือ: ข้อผิดพลาดที่มากขึ้น และบิลค่าใช้จ่ายที่แฝงอยู่ซึ่งจะเพิ่มขึ้นตามทุกการโต้ตอบ

กระบวนการ dreaming ในตอนกลางคืนทำงานอย่างไร

ระบบจะแยก write path (log แบบเรียลไทม์ของ agent) ออกจาก work path (การตัดสินใจของโมเดล) วันละสองครั้ง งานเบื้องหลังที่เรียกว่า “dream” จะประมวลผล event ที่สะสมไว้ผ่าน 3 ขั้นตอน:

  • Reflect – LLM จะสแกนกลุ่มของ event ที่เกี่ยวข้องกัน เสนอข้อเท็จจริงที่กระชับ และบันทึกว่า event ใดบ้างที่สนับสนุนข้อเสนอนั้น
  • Score – pipeline จะตรวจสอบว่าข้อเท็จจริงนั้นมี event สนับสนุนเพียงพอหรือไม่ และ event เหล่านั้นมีระยะห่างของเวลาที่เหมาะสมพอที่จะเชื่อถือได้หรือไม่
  • Judge – การตรวจสอบความสมเหตุสมผล (sanity checks) สองขั้นตอนจะยืนยันว่าข้อเท็จจริงใหม่ไม่ขัดแย้งกับหน่วยความจำที่มีอยู่เดิม และไม่ใช่ข้อมูลที่ซ้ำซ้อน

ข้อเท็จจริงที่ผ่านการตรวจสอบทั้งหมดจะถูกยกระดับเป็น permanent memory ส่วนข้อเท็จจริงที่ไม่ผ่านจะไปอยู่ใน review queue ซึ่งผู้ควบคุมที่เป็นมนุษย์สามารถกดปุ่มเพียงครั้งเดียวเพื่ออนุมัติหรือปฏิเสธ ทุกการอนุมัติจะสร้าง commit ในรูปแบบเดียวกับ git ทำให้มี audit trail ที่สมบูรณ์ว่าหน่วยความจำส่วนใดเปลี่ยนไปและเปลี่ยนเมื่อใด

บทเรียนสำคัญทางวิศวกรรม

  • แยก write ออกจาก work. ปล่อยให้ agent บันทึกทุกการสังเกตการณ์ลงใน log แล้วให้กระบวนการเฉพาะทางเป็นตัวตัดสินว่าข้อมูลใดควรเก็บไว้
  • เน้นที่การปฏิเสธ ไม่ใช่การสร้าง. การสร้างไอเดียนั้นราคาถูก แต่การป้องกัน memory pollution (มลพิษทางหน่วยความจำ) คือส่วนที่ยาก
  • ใช้มนุษย์เป็นด่านตรวจในจุดที่ประหยัดที่สุด. การร่างแบบอัตโนมัติแล้วตามด้วยการลงนามด้วยมืออย่างรวดเร็ว ให้ผลลัพธ์ที่ดีกว่าการปล่อยให้ทำงานอัตโนมัติเต็มรูปแบบ ทั้งในด้านต้นทุนและความปลอดภัย
  • จำกัดการใช้ token ต่อรอบ. การกำหนดเพดาน token ต่อการรัน dreaming หนึ่งครั้งจะช่วยหยุดค่าใช้จ่ายที่บานปลาย
  • ตรวจสอบความล้มเหลวที่เงียบเชียบ. หากขั้นตอนหนึ่งใช้กฎที่ต่างจากขั้นตอนถัดไป ข้อมูลอาจหายไปโดยไม่มีใครสังเกตเห็น การตรวจสอบอย่างชัดเจนจะช่วยตรวจจับความไม่สอดคล้องกันนี้ได้

ข้อเสียที่อาจเกิดขึ้น

การรันกระบวนการรวบรวมข้อมูลแบบ offline ทำให้เกิดความล่าช้า (lag): agent จะยังไม่เห็นข้อเท็จจริงที่ผ่านการตรวจสอบใหม่จนกว่าจะถึงรอบการ dream ครั้งถัดไป ในแอปพลิเคชันที่เคลื่อนไหวอย่างรวดเร็วและต้องการการเรียนรู้ทันที ความล่าช้านี้อาจเป็นข้อด้อย นอกจากนี้ระบบยังต้องพึ่งพาผู้ตรวจสอบที่เป็นมนุษย์เพียงคนเดียว การขยายขนาดของ review queue โดยไม่ทำให้ต้นทุนแรงงานพุ่งสูงขึ้นยังคงเป็นคำถามที่ยังไม่มีคำตอบ

สิ่งที่ควรจับตามองต่อไป

นักพัฒนาที่กำลังทดลองกับ LLM agents ควรตรวจสอบบิลค่า token และ error logs เพื่อหาความผิดปกติของ “memory pollution” ซึ่งก็คือข้อความที่ซ้ำซ้อนหรือขัดแย้งกันซึ่งมีต้นตอมาจากการสะสม event ดิบ การเพิ่ม dreaming pipeline ช่วยให้มี “ปุ่มปรับ” ที่จับต้องได้เพื่อลดต้นทุนเหล่านั้น ในขณะที่ยังได้รับประวัติหน่วยความจำที่สามารถตรวจสอบได้ เมื่อมีทีมต่างๆ นำโมเดล split-log มาใช้มากขึ้น เครื่องมือที่ช่วยทำให้ขั้นตอน reflect-score-judge เป็นอัตโนมัติและรวมเข้ากับการตรวจสอบในรูปแบบ version-control ก็น่าจะปรากฏขึ้น ซึ่งจะทำให้แนวทางนี้ไม่ต้องปรับแต่งเองมากนัก (less bespoke) และสามารถนำไปใช้งานได้ทันที (more plug-and-play) การแลกเปลี่ยน (trade-off) ระหว่างความรวดเร็วทันใจและความสะอาดของข้อมูล จะเป็นตัวกำหนดว่า nightly dream จะกลายเป็นส่วนมาตรฐานของสถาปัตยกรรม LLM-agent ได้กว้างขวางเพียงใด