ปลั๊กอินหน่วยความจำสำหรับ Hermes Agent: holographic และวิธีอัปเดต

Holographic ซึ่งเป็น provider หน่วยความจำระยะยาวของ Hermes Agent ได้แยกออกจากแกนหลักมาเป็นปลั๊กอินของตัวเองแล้ว: เมื่อ 11 ตุลาคม 2569 Nous Research ได้ merge การเปลี่ยนแปลงนี้เข้า main ถ้าคุณใช้ holographic อยู่แล้ว ก็อัปเดต Hermes ได้โดยไม่ต้องย้ายข้อเท็จจริงและการตั้งค่าที่สะสมไว้ด้วยมือ ด้านล่างคือขั้นตอนว่าต้องทำอะไรก่อนและหลัง hermes update ต่อจากนี้คนดูแลปลั๊กอินคือผม: ทีมรับ fork ของผมเข้าแคตตาล็อกปลั๊กอินทางการของ Hermes แล้ว

นี่ไม่ใช่บริการหน่วยความจำใหม่: ไฟล์ฐานข้อมูลยังเป็นไฟล์เดิม และไม่ต้องย้ายข้อเท็จจริงที่สะสมไว้ คอมโพเนนต์ที่มีอยู่แล้วแค่ได้รีโพแยกที่มีการดูแล และได้คนที่รับผิดชอบการพัฒนาต่อจากนี้ ด้านล่างคือการติดตั้ง โครงสร้างของหน่วยความจำ และการทำงานคู่กับ hermes-dreaming ส่วนการค้นหาตามความหมาย reranker และการรวมรายการซ้ำ อยู่ในภาคต่อ

ณ วันที่ 30 ตุลาคม 2569 รีลีสล่าสุดของ holographic คือ 0.23.1 ส่วนแคตตาล็อก Hermes ปักไว้ที่ 0.22.0 สำหรับ dreaming คือ 3.8.0 และ 3.7.1 ตามลำดับ มีข้อจำกัดหนึ่งข้อที่ควรรู้ไว้ก่อน: หลังรวมข้อเท็จจริงครั้งแรกด้วย merge แล้ว holographic เวอร์ชันที่ต่ำกว่า 0.19.0 จะเขียนลงฐานข้อมูลไม่ได้ การถอยกลับไปต่ำกว่าเวอร์ชันนี้จึงทำให้หน่วยความจำปิดไป รายละเอียดอยู่ในหัวข้อเรื่องประวัติของข้อเท็จจริง

หน่วยความจำสองแบบของเอเจนต์ และทำไมต้องมี holographic

Hermes มีหน่วยความจำสองแบบที่ต่างกัน แบบแรกคือไฟล์ MEMORY.md และ USER.md ทั้งสองไฟล์ถูกใส่เข้าไปทั้งไฟล์ในทุกเทิร์นของเอเจนต์ จึงมีลิมิตจำนวนตัวอักษรที่เข้มงวด: พอไฟล์ชนเพดาน รายการใหม่ก็เข้าไปไม่ได้อีก เอเจนต์แก้ไฟล์เหล่านี้เองด้วยเครื่องมือ memory

แบบที่สองคือ provider ภายนอกอย่าง holographic มันเก็บข้อเท็จจริงแยกเป็นรายการได้เป็นพัน ๆ รายการในฐานข้อมูล SQLite แต่ใส่เข้าไปในเทิร์นแค่ไม่กี่รายการที่เกี่ยวข้อง ปกติไม่เกินห้า ข้อเท็จจริงค้นหาได้ มีคะแนนความน่าเชื่อถือ และในเวอร์ชันหลัง ๆ ก็มีประวัติด้วย

หน่วยความจำแบบนี้พังเงียบ ๆ ได้สองแบบ แบบแรก เรื่องที่มีประโยชน์ไปไม่ถึงหน่วยความจำ: คนพูดเรื่องสำคัญ แต่เอเจนต์ไม่ได้บันทึก แบบที่สอง หน่วยความจำเต็มไปด้วยของที่ล้าสมัย: ข้อเท็จจริงเปลี่ยนไป แต่รายการยังอยู่ Holographic เก็บและค้นหาข้อเท็จจริงที่บันทึกไว้ ส่วน hermes-dreaming ซึ่งจะเล่าด้านล่าง ตอนกลางคืนจะคัดเรื่องสำคัญเข้าหน่วยความจำถาวรและทบทวนรายการที่ล้าสมัย การสกัดแคนดิเดตจากบทสนทนารันด้วยงานแยกของมัน หน่วยความจำทุกชั้นของ Hermes สัมพันธ์กันอย่างไร ผมเล่าละเอียดไว้ในบทความเรื่องหน่วยความจำของ Hermes Agent และการเลือก provider

holographic ทำงานอย่างไร

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

Holographic ไม่ได้มาแทนระบบหน่วยความจำทั้งหมดของ Hermes: มันคือ provider แบบเสียบเพิ่มสำหรับเก็บข้อเท็จจริงและดึงกลับมาใช้ หน่วยความจำทั้งหมดของมันคือไฟล์ SQLite ไฟล์เดียว และในโหมดค่าเริ่มต้น ปลั๊กอินไม่เรียกอะไรภายนอกเลยแม้แต่ครั้งเดียว provider นี้ผสมการค้นหาด้วยคำ ความเชื่อมโยงระหว่างเอนทิตี และ HRR ซึ่งเป็นการแทนความสัมพันธ์ด้วยเวกเตอร์ทางคณิตศาสตร์ ข้างในมีสี่กลไก:

• การค้นหาข้อความเต็ม FTS5 ที่รู้จักรูปคำ รากคำ และ n-gram ซึ่งคือลำดับตัวอักษรสั้น ๆ ที่ใช้ค้นข้อความในภาษาที่ไม่เว้นวรรคระหว่างคำ
• ความน่าเชื่อถือของข้อเท็จจริง เอเจนต์ประเมินผ่าน fact_feedback ว่าข้อเท็จจริงช่วยได้ไหม แล้วคะแนนความน่าเชื่อถือก็ขยับตาม ข้อเท็จจริงที่ความน่าเชื่อถือต่ำกว่าเกณฑ์ min_trust_threshold (ค่าเริ่มต้น 0.3) จะไม่ถูกดึงขึ้นมาอีก
• เอนทิตีที่มีชื่อแฝง เอเจนต์บันทึก “X aka Y” ได้ แล้วทั้งสองชื่อจะพาไปหาข้อเท็จจริงชุดเดียวกัน ชื่อใช้ได้ทั้งอักษรละตินและอักษรอื่นใดก็ได้ที่มีตัวพิมพ์ใหญ่
• HRR หรือ holographic reduced representations ที่มาของชื่อปลั๊กอิน เป็นวิธีเข้ารหัสความเชื่อมโยงระหว่างข้อเท็จจริงกับเอนทิตีด้วยเวกเตอร์โดยไม่ต้องใช้โมเดลภาษา และไม่จำเป็นต้องมีไลบรารี numpy

ในโหมดพื้นฐานไม่ต้องมี API key ไม่ต้องมีเน็ต และไม่ต้องเรียกโมเดลภาษา คำขอไปยังเซิร์ฟเวอร์แยกจะเกิดขึ้นก็ต่อเมื่อเปิดการค้นหาตามความหมาย (embeddings: on) หรือ reranker (rerank: on) ซึ่งทั้งคู่ปิดอยู่โดยค่าเริ่มต้น แต่ไม่ได้แปลว่าเอเจนต์ทั้งตัวทำงานออฟไลน์: ข้อเท็จจริงที่ค้นเจอจะเข้าไปอยู่ในบริบทของโมเดลที่คุณใช้ใน Hermes การเก็บข้อมูลไว้บนเครื่องกับการที่โมเดลบนคลาวด์ประมวลผลข้อมูลเป็นคนละเรื่องกัน

อัปเดต Hermes Agent อย่างไรไม่ให้หน่วยความจำหาย

ถ้าในการตั้งค่าเลือก memory.provider: holographic ไว้ ระบบออกแบบมาให้ติดตั้งปลั๊กอินจากแคตตาล็อกอัตโนมัติตอน hermes update หรือตอนเปิดเอเจนต์หลังย้ายไปใช้โค้ดที่ลบสำเนาในตัวออกแล้ว การเปลี่ยนแปลงนี้ merge เมื่อ 11 ตุลาคม และอยู่ในรีลีส Hermes v0.21.7 วันที่ 12 ตุลาคม ส่วนในบทความสรุปรีลีส Hermes 0.22 ก็มีพูดถึงเป็นข้อแยกทั้งเรื่องการย้าย provider หน่วยความจำเข้าแคตตาล็อกและผู้ดูแลคนใหม่ของ holographic

สิ่งที่ยังอยู่คือฐานข้อมูล memory_store.db ที่เก็บข้อเท็จจริง และการตั้งค่า plugins.hermes-memory-store ชื่อ provider ก็ยังเหมือนเดิม ไม่ต้องสร้างฐานข้อมูลว่าง ไม่ต้องคัดลอกข้อเท็จจริงด้วยมือ และไม่ต้องเปลี่ยนไปใช้ provider อื่นเพียงเพราะมันแยกออกจากแกนหลัก

การย้ายอัตโนมัติมีใน Hermes v0.21.7 และทุกเวอร์ชันที่ใหม่กว่า ถ้าเวอร์ชันที่ติดตั้งไว้เก่ากว่านั้นและยังมี holographic ในตัว ระบบจะใช้สำเนาในตัว

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

1. สำรองข้อมูล วิธีที่ง่ายที่สุดคือคำสั่ง hermes backup: มันถ่ายสแนปช็อตฐานข้อมูลที่สอดคล้องกันได้แม้เอเจนต์กำลังทำงานอยู่ ถ้าคัดลอกเอง ให้หยุด Hermes ก่อน แล้วค่อยเก็บฐานข้อมูล (ค่าเริ่มต้นคือ memory_store.db หรือพาธใน db_path) และ config.yaml
2. เช็กเวอร์ชัน ให้แน่ใจว่าเวอร์ชัน Hermes ที่เลือกมีการย้ายนี้แล้ว
3. อัปเดต ด้วย hermes update
4. เช็กหน่วยความจำ ให้เอเจนต์หาข้อเท็จจริงที่บันทึกไว้ก่อนอัปเดตแน่ ๆ

ถ้าหลังอัปเดตแล้วหน่วยความจำปิดไปอยู่ดี ใน README ของปลั๊กอินมีหัวข้อ “Memory went off after hermes update” ที่ไล่สาเหตุไว้

สำหรับการติดตั้งจาก URL ของรีโพเก่าของ Nous Research ก็มีการย้ายไปยังรายการในแคตตาล็อกที่ได้รับการดูแลเช่นกัน README ของรีโพที่ถูก archive ไว้ยังแนะนำให้ติดตั้งใหม่จากแคตตาล็อกหนึ่งครั้งสำหรับกรณีนี้: hermes plugins remove holographic && hermes plugins install holographic ฐานข้อมูลและการตั้งค่าจะยังอยู่ครบ

ติดตั้ง holographic ตั้งแต่ศูนย์

นี่คือ holographic ในแคตตาล็อกทางการของ Hermes: ในนั้นจะเห็นรีโพที่ได้รับการดูแล เวอร์ชันที่ปักไว้ ข้อกำหนดด้าน Hermes และข้อจำกัดที่รู้แล้ว ณ วันที่ 30 ตุลาคม 2569 รายการนี้ชี้ไปที่ 0.22.0 และต้องใช้ Hermes เวอร์ชัน 0.21.5 ขึ้นไป นี่คือความเข้ากันได้ขั้นต่ำของปลั๊กอิน ไม่ใช่หมายเลขเวอร์ชันที่รับประกันการย้ายอัตโนมัติ

การย้ายอัตโนมัติจะติดตั้งเวอร์ชันที่ปักไว้ในแคตตาล็อก ณ ตอนที่ย้าย ส่วนเวอร์ชันที่คุณมีอยู่ ดูได้ด้วย hermes plugins list ถ้าเก่ากว่าเวอร์ชันที่ปักไว้ในแคตตาล็อก ให้ติดตั้งปลั๊กอินใหม่: hermes plugins install holographic --force ฐานข้อมูล memory_store.db และการตั้งค่าจะไม่ถูกแตะ

สำหรับการติดตั้งใหม่ เอกสารของ provider แนะนำแบบนี้:

hermes plugins install holographic
hermes config set memory.provider holographic

อีกทางคือรัน hermes memory setup แล้วเลือก holographic ถ้าตั้งค่า provider ไว้แล้ว ไม่ต้องมองคำสั่งเหล่านี้เป็นการย้ายด้วยมือที่จำเป็น: ผู้ใช้เดิมมีการย้ายอัตโนมัติรองรับอยู่แล้ว

ถ้าจะติดตั้งรีลีสที่ระบุเอง ไม่ใช่ตัวที่ปักไว้ในแคตตาล็อก README แนะนำให้ส่งแฮชคอมมิตแบบเต็ม: hermes plugins install holographic --ref <แฮช 40 ตัวอักษร> --force แฮชของแต่ละรีลีสอยู่ในหน้า releases ของรีโพ

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

การสะท้อน (mirroring) รายการจากหน่วยความจำในตัวไปยัง holographic ก็ปิดอยู่โดยค่าเริ่มต้นเช่นกัน: ปลั๊กอินไม่ได้สัญญาว่าจะจำทุกอย่างที่เคยพูดไว้เอง

ทำไม holographic ถึงแยกออกจากแกนหลักของ Hermes

เดิมทีวางแผนจะแยกออกวันที่ 15 ตุลาคม แต่สำหรับ holographic การย้ายเกิดเร็วกว่านั้น: มีผู้ดูแลแยกแล้ว และรายการในแคตตาล็อกก็ผ่านการตรวจแล้ว PR ที่ลบสำเนาในตัวออกก็ merge เข้า main เรียบร้อย

รีโพเก่าของ Nous Research ถูก archive และชี้ผู้ใช้มาที่ fork ของผม แบบนี้คนที่เคยติดตั้งสำเนาแยกตัวเดิมไว้ก็ยังมีเส้นทางที่ชัดเจน

ปลั๊กอินที่แยกออกมาพัฒนาได้อิสระจากรีลีสของแกนหลัก แต่เวลาติดตั้งจากแคตตาล็อก จะใช้คอมมิตที่ปักไว้ ไม่ใช่สถานะล่าสุดของ branch main ของผม: เวอร์ชันใหม่จะมาถึงหลังจากที่มีการอัปเดตคอมมิตที่ปักไว้ในแคตตาล็อก Hermes

เส้นทางของ fork ในสองสัปดาห์เป็นแบบนี้ 2 ตุลาคม เวอร์ชัน 0.1.1 ซึ่งเป็นสำเนาของสิ่งที่อยู่ในแกนหลัก 10–12 ตุลาคม เวอร์ชัน 0.2–0.6: แก้การค้นหา ตัวกรองความเกี่ยวข้อง ภาษา และคำสำคัญ 12 ตุลาคม 0.7 และ 0.8: ฐานข้อมูลแยกต่อแชท ประวัติข้อเท็จจริง และการลบจริง 13 ตุลาคม 0.9–0.13: 18 ภาษาพร้อมพจนานุกรม การ audit โค้ด และการตรวจข้อเท็จจริงตอนอ่าน

แผนที่การพัฒนา: หน่วยความจำแยกต่อแชท (0.7.0) ประวัติข้อเท็จจริงและ “ลืมไปเลย” (0.8.0) การค้นหา 18 ภาษาพร้อมพจนานุกรม (0.9–0.11) การตรวจตอนเขียนและตอนอ่าน (0.12–0.13) การค้นหาตามความหมาย (0.14) ที่มาของข้อเท็จจริง (0.15) การเก็บกวาดเอนทิตี (0.16–0.17) reranker แบบทดลอง (0.18) การรวมรายการซ้ำโดยเก็บประวัติไว้ (0.19) บันทึกผลลัพธ์ของงาน (0.20) ลิมิต token ของบล็อกความจำ (0.21) ชื่อที่ตามข้อความของข้อเท็จจริงไปด้วย (0.22) และความน่าเชื่อถือที่ตรงไปตรงมาสำหรับข้อความที่ถูกแก้ (0.23) การเรียกเครื่องมือแบบเก่ายังใช้ได้ แต่ความเข้ากันได้ของไฟล์ฐานข้อมูลหลัง merge เปลี่ยนไป เรื่องนี้อยู่ด้านล่าง

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

ปรับปรุงอะไรบ้างหลังแยกออกจากแกนหลัก

สิ่งแรกที่ผมทำคือรันเวอร์ชัน 0.1.1 ที่มากับแกนหลักบนฐานข้อมูลสังเคราะห์ที่มีข้อเท็จจริง 200 รายการเกี่ยวกับคน 20 คน แล้วลงมือแก้การค้นหา ผลจากรายการการเปลี่ยนแปลงของเวอร์ชัน 0.2.0:

• probe การค้นหาข้อเท็จจริงเกี่ยวกับเอนทิตี: ความแม่นยำในผลห้าอันดับแรกเพิ่มจาก 0.02–0.04 เป็น 1.00
• reason การค้นหาจากหลายเอนทิตีพร้อมกัน: ตอนนี้ข้อเท็จจริงที่ต้องการติดห้าอันดับแรก 15 จาก 15 กรณี เทียบกับแค่กรณีเดียวก่อนหน้านี้
• HRR ในการค้นหา แยกข้อเท็จจริงออกจากกันได้แล้ว: ราว 0.69 สำหรับข้อเท็จจริงที่ตรงหัวข้อ เทียบกับ 0.51 สำหรับที่เหลือ
• ตัวนับการดึงข้อเท็จจริง retrieval_count ตอนนี้นับว่าข้อเท็จจริงถูกส่งให้โมเดลกี่ครั้ง
• ชื่อเอนทิตี ถูกจดจำได้ในอักษรใดก็ได้ที่มีตัวพิมพ์ใหญ่ ไม่ใช่แค่อักษรละติน
• ข้อผิดพลาดของ FTS5 ถูกเขียนลง log เป็นคำเตือน

ต่อมาผมก็ปรับการบันทึกข้อเท็จจริงจากงาน cron ร่วมกับ dreaming ด้วย รายละเอียดอยู่ในหัวข้อเรื่องการทำงานร่วมกันของปลั๊กอิน

holographic ดึงความจำก่อนตอบอย่างไร

ก่อนทุกเทิร์นของเอเจนต์ provider จะเลือกข้อเท็จจริงให้เข้ากับข้อความเอง ลำดับเป็นแบบนี้:

1. ตัดข้อความคุยเล่นทิ้ง ข้อความที่มีแต่คำทักทาย คำขอบคุณ และ “โอเค ขอบคุณ” จะไม่ดึงความจำอะไรขึ้นมาเลย
2. แตกคำเป็นคีย์: รูปคำ รากคำ คำที่มีรากเดียวกัน และ n-gram
3. รวบรวมแคนดิเดต จากดัชนี FTS5 จาก n-gram และด้วยการสแกนคำในจุดที่ดัชนีช่วยไม่ได้
4. ตัวกรองความเกี่ยวข้อง ข้อเท็จจริงจะผ่านถ้าครอบคลุมสัดส่วนของคำในข้อความมากพอ (prefetch_min_coverage ค่าเริ่มต้น 0.3) โดยคำที่พบน้อยมีน้ำหนักมากกว่าคำที่พบบ่อย
5. ไม่ซ้ำ ข้อเท็จจริงที่แสดงไปแล้วในไม่กี่เทิร์นล่าสุด (prefetch_repeat_turns ค่าเริ่มต้น 6) จะไม่ถูกใส่เข้ามาอีก
6. ส่งเข้าเทิร์นได้ไม่เกินห้าข้อเท็จจริง บวกข้อเท็จจริงของเอนทิตีที่ถูกเอ่ยชื่อในข้อความ ตั้งแต่ 0.21.0 จำกัดทั้งบล็อกด้วยจำนวน token โดยประมาณได้ (prefetch_max_tokens ค่าเริ่มต้นปิดอยู่): บรรทัดข้อเท็จจริงที่ใส่ไม่พอดีจะถูกตัดออกทั้งบรรทัด เพราะการตัดตามลิมิตอาจทำให้คำว่า “ไม่” เงื่อนไข หรือวันที่หายไป ลิมิตเดิม 300 ตัวอักษรต่อบรรทัดของบล็อกยังใช้อยู่ ทั้งเมื่อมีและไม่มีลิมิต token

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

ตั้งแต่เวอร์ชัน 0.14.0 บล็อก holographic ใน system prompt ไม่มีตัวเลขที่เปลี่ยนไปเรื่อย ๆ แล้ว ก่อนหน้านี้ในนั้นมีจำนวนข้อเท็จจริง ซึ่งเปลี่ยนทุกครั้งที่บันทึกรายการใหม่ และแคชพรอมต์ของโมเดลก็ถูกรีเซ็ตทุกเซสชันใหม่ ในการติดตั้งแห่งหนึ่ง เรื่องนี้กินราว 21,000 token สำหรับการอ่านซ้ำ ตอนนี้บรรทัดนั้นคงที่ และแคชก็ทำงานได้

ตั้งแต่เวอร์ชัน 0.6.2 โดยค่าเริ่มต้น holographic จะส่งบรรทัดบอก Hermes ว่าดึงความจำมากี่รายการสำหรับคำตอบนี้ ใน Telegram บรรทัดนี้จะมาเป็นข้อความแยกเป็นภาษาอังกฤษ สำเนาในตัวไม่ได้ทำแบบนี้ ปิดได้ด้วยพารามิเตอร์ recall_indicator: false ใน plugins.hermes-memory-store ซึ่งไม่มีผลต่อการค้นหา เช่นเดียวกับการตั้งค่าอื่นของปลั๊กอิน ค่านี้ถูกอ่านตอนเปิด gateway: การเปลี่ยนแปลงจะมีผลหลังรีสตาร์ต

เครื่องมือ: fact_store และ fact_feedback

เอเจนต์ใช้เครื่องมือได้สองตัว และตัวที่สามเปิดได้ตามต้องการ ใน holographic 0.23.1 fact_store รู้จัก 26 action:

• การเขียน: add, update, change, end, correct, revert, merge, forget, remove
• การค้นหา: search, probe, reason, related, contradict, history
• การดูแลรักษา: list, stats, export, review, enrich
• ชื่อและเอนทิตี: entities, alias, rename, delete_entity, split, rebuild_entities สี่ตัวสุดท้ายมาใน 0.16–0.17

เครื่องมือตัวที่สอง fact_feedback ใช้ประเมินว่าข้อเท็จจริงช่วยได้ไหม

ตัวที่สาม fact_experience มาใน 0.20.0 พร้อมบันทึกผลลัพธ์ของงาน และทำงานก็ต่อเมื่อเปิด experience: on บันทึกนี้จดว่าเอเจนต์ได้รับข้อเท็จจริงเวอร์ชันไหนจริง ๆ ตอนค้นหาหรือก่อนตอบ และจดรายงานของเอเจนต์ว่ามันช่วยหรือทำให้พลาด นี่เป็นการบันทึกที่แยกจากความน่าเชื่อถือ: ข้อเท็จจริงที่ถูกต้องแต่ไม่เข้ากับสถานการณ์ไม่ต้องถูก “ลงโทษ” ด้วยคะแนนความจริงอีกต่อไป และบันทึกนี้ไม่ได้เปลี่ยนความน่าเชื่อถือ ที่มา หรือลำดับการแสดงผลเลย รายงานของเอเจนต์ไม่ใช่การยืนยันจากคน รายการถูกเก็บไว้ไม่เกิน 30 วัน และไม่เกิน 1,000 ครั้งต่อฐานข้อมูล ส่วน forget ข้อเท็จจริงจะลบรายการที่เกี่ยวข้องไปด้วย ตั้งแต่ 0.23.1 ข้อความของรายการที่หมดอายุจะถูกลบออกจากไฟล์ฐานข้อมูลทันที แม้ฐานข้อมูลจะเปิดค้างไว้นาน ไม่ต้องรอการเปิดครั้งถัดไป

เมื่อสั่ง add ปลั๊กอินจะตอบกลับพร้อมคำแนะนำ: รายการที่คล้ายกัน (similar) ความขัดแย้งที่อาจเกิดขึ้น (possible_conflicts) และเวอร์ชันก่อนหน้าของข้อเท็จจริงเดียวกัน (past_versions) การตัดสินใจยังเป็นของเอเจนต์

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

พรอมต์เก่ายังใช้ได้: add supersedes=X ตอนนี้หมายถึง change X, update content= หมายถึง correct และ remove หมายถึง forget

ประวัติของข้อเท็จจริง

ตั้งแต่เวอร์ชัน 0.8.0 ข้อเท็จจริงแต่ละรายการมีประวัติ และ action ต่าง ๆ แยกได้ว่าทำไมข้อเท็จจริงจึงไม่เป็นปัจจุบันแล้ว:

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

การค้นหารับ as_of=YYYY-MM-DD และตอบว่าอะไรเป็นจริง ณ วันนั้น ข้อเท็จจริงที่บอกเรื่องนี้ไม่ได้จะถูกแยกเป็นอีกรายการ: ปลั๊กอินไม่แต่งวันที่ขึ้นมาเอง และข้อเท็จจริงที่ไม่มีวันเริ่มต้นชัดเจนจะถือว่าเป็นจริงตั้งแต่วันที่บันทึก

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

ชื่อจะตามข้อความไปด้วย ตั้งแต่ 0.22.0 เมื่อเปลี่ยนข้อความผ่าน change, correct หรือ update รายการ entities ใหม่จะแทนชื่อเดิม และถ้าไม่ส่งรายการมา ชื่อที่ข้อความเก่าเอ่ยถึงแต่ข้อความใหม่ไม่มีแล้วจะถูกลบ ก่อนหน้านี้ ข้อเท็จจริง “ครูสอนกีตาร์ของ Leo คือ Ben Cole” ที่ถูกเขียนใหม่เป็น “…Omar Reid” ยังค้นเจอด้วยชื่อ Ben Cole ส่วน revert จะคืนชื่อของเวอร์ชันที่ย้อนกลับไปด้วย

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

ตั้งแต่ 0.19.0 มี action แยกสำหรับรายการซ้ำ: merge {fact_id: <ตัวที่เก็บไว้>, from: [<สำเนา>]} สำเนาจะหายไปจากการค้นหาและการดึงความจำ แต่ประวัติ แหล่งที่มา และการยืนยันของมันยังถูกเก็บไว้ใต้หมายเลขของมัน และดูได้จากประวัติของข้อเท็จจริงที่เก็บไว้ นี่คือการรวม ไม่ใช่การลบ: ไม่มีคำสั่งแยกสำหรับยกเลิกการรวม พารามิเตอร์ expect ทำให้รวมได้เฉพาะเวอร์ชันที่คนเห็นตอนตกลงกัน ถ้าข้อเท็จจริงเปลี่ยนไปแล้วระหว่างนั้น การทำงานจะไม่เขียนอะไรและตอบกลับ changed_since

ก่อน merge ครั้งแรก ให้สำรองข้อมูล การรวมครั้งแรกนี่เองที่ยกเวอร์ชันของ schema ประวัติเป็น 2 หลังจากนั้น holographic 0.15–0.18 จะปฏิเสธการเขียนลงไฟล์นี้ด้วยข้อผิดพลาด HistoryTooNew และหน่วยความจำของเอเจนต์หลักจะปิดไป ถ้าจะกลับมาใช้ได้ต้องใช้เวอร์ชัน 0.19.0 ขึ้นไป หรือใช้สำเนาฐานข้อมูลก่อนการรวม ห้ามเปลี่ยนหมายเลข schema ด้วยมือ ตอนนี้แคตตาล็อกให้ 0.22.0 ความเสี่ยงจึงเกิดขึ้นเมื่อถอยเวอร์ชันด้วยมือผ่านแฮชไปยังเวอร์ชันที่เก่ากว่า 0.19.0

“ลืมไปเลย” ทำงานอย่างไร

forget ใน holographic ไม่ได้แค่เอาข้อเท็จจริงออกจากผลการค้นหา แต่ยังเริ่มล้างร่องรอยของมันออกจากตัวไฟล์ฐานข้อมูลด้วย:

1. ลบข้อเท็จจริง ทุกเวอร์ชันของมัน ความเชื่อมโยง และเอนทิตีที่ไม่เหลือข้อเท็จจริงผูกอยู่
2. สร้างดัชนี FTS ทั้งสองใหม่: การลบใน FTS5 ยังทิ้งคำไว้ใน segment เก่า
3. เขียนไฟล์ใหม่ด้วยคำสั่ง VACUUM พร้อม secure_delete และล้าง journal WAL ให้ว่าง
4. เหลือไว้แค่ “ป้ายหลุมศพ” (tombstone) ซึ่งเป็นเครื่องหมายภายในว่ามีข้อเท็จจริงถูกลบ: หมายเลขของมันและ HMAC-SHA256 ของข้อความที่ normalize แล้ว โดยไม่มีตัวข้อความ คีย์สำหรับแฮชคือไบต์สุ่ม 16 ไบต์ แยกของแต่ละฐานข้อมูล

ถ้าตอนนั้นมีโปรเซสอื่นถือไฟล์อยู่ ขั้นตอนเขียนไฟล์ใหม่และล้าง journal จะถูกเลื่อนออกไป: คำตอบจะแจ้ง scrub: "pending" และการล้างจะทำซ้ำตอนเปิดฐานข้อมูลครั้งถัดไปหรือตอน forget ครั้งถัดไป ในฐานข้อมูลที่ใช้ journal แบบ DELETE ตัวอ่านจากโปรเซสอื่นอาจทำให้คอมมิตเองล้มได้ด้วย กรณีนั้นจะไม่มีอะไรเปลี่ยน ไม่มีการเขียนป้ายหลุมศพ และต้อง forget ซ้ำ

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

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

สิ่งที่ forget เอื้อมไปไม่ถึง: ฐานข้อมูลเซสชันของ Hermes ประวัติ Git dump ภายนอก และไฟล์สำรอง รวมถึง hermes backup พวกนี้ต้องล้างแยกต่างหาก การลบจากคลังสำเร็จไม่ได้พิสูจน์ว่าข้อความหายไปจากทุกที่เก็บถาวรแล้ว

หน่วยความจำแยกต่อแชท

พารามิเตอร์ scope (ตั้งแต่เวอร์ชัน 0.7.0) กำหนดว่าเอเจนต์มีฐานข้อมูลกี่ชุด:

• profile ฐานข้อมูลเดียว memory_store.db เหมือนเดิม
• chat ฐานข้อมูลแยกต่อแชทในโฟลเดอร์ holographic-chats/
• thread ฐานข้อมูลแยกต่อหัวข้อในฟอรัม
• user ฐานข้อมูลแยกต่อคนใน holographic-users/ ตามผู้เขียนเทิร์น

แบบนี้จำเป็นเมื่อบอตตัวเดียวดูแลหลายกลุ่มที่ไม่เกี่ยวกัน: provider ดึงข้อเท็จจริงเข้าทุกคำตอบเอง และถ้าไม่แยกกัน มันอาจเล่าให้กลุ่มหนึ่งฟังถึงสิ่งที่พูดกันในอีกกลุ่ม การแยกทำเป็นไฟล์แยกต่อแชท ไม่ใช่คอลัมน์ chat_id: ข้อเท็จจริงปรากฏทั้งในดัชนี ใน n-gram ในเอนทิตี และในเวกเตอร์ HRR ตัวกรองที่หลุดไปแค่ตัวเดียวก็หมายถึงข้อมูลรั่ว ถ้าไม่มีแชท เช่น CLI, cron หรือ subagent ในโหมดเหล่านี้จะไม่มีการอ่านหรือเขียนอะไรเลย

การค้นหาตามความหมาย: เปิดได้ตามต้องการ ตั้งแต่เวอร์ชัน 0.14

การค้นหาด้วยคำจะเจอข้อเท็จจริงที่มีอะไรบางอย่างร่วมกับคำถาม สำหรับคำถามที่ใช้ถ้อยคำต่างไปโดยสิ้นเชิง ใน 0.14.0 จึงมีการค้นหาตามความหมายผ่าน embeddings เพิ่มเข้ามา ฟีเจอร์นี้ปิดอยู่โดยค่าเริ่มต้น และเปิดได้ใน plugins.hermes-memory-store:

embeddings: on
embedding_url: https://api.openai.com/v1
embedding_model: text-embedding-3-small
embedding_key_env: OPENAI_API_KEY

ใช้ API embeddings ใดก็ได้ที่เข้ากันได้กับ OpenAI: OpenAI, Gemini หรือเซิร์ฟเวอร์บนเครื่องอย่าง Ollama ใน embedding_key_env ให้ใส่ชื่อตัวแปรสภาพแวดล้อม ไม่ใช่ตัวคีย์ ถ้าใช้บริการคลาวด์ ข้อความของข้อเท็จจริงและข้อความแชทจะถูกส่งไปที่บริการนั้น ถ้าใช้เซิร์ฟเวอร์บนเครื่อง ทุกอย่างจะอยู่บนเครื่องของคุณ

การทำงานเป็นแบบนี้:

• คำยังเป็นฐานหลัก ความหมายจะจัดลำดับใหม่ให้ข้อเท็จจริงที่หาเจอด้วยคำ และอาจเพิ่มได้อีกหนึ่งรายการ ต่อท้ายพร้อมป้าย (by meaning) เฉพาะเมื่อมันโดดเด่นกว่ารายการอื่นอย่างชัดเจน ส่วน fact_store search จะต่อข้อเท็จจริงที่ความหมายใกล้ที่สุดไว้หลังผลที่ตรงด้วยคำ
• เทิร์นแทบไม่ต้องรอ เวกเตอร์ของข้อความถูกขอก่อนตอบโดยมี timeout 3 วินาที ส่วนเวกเตอร์ของข้อเท็จจริงขอหลังตอบในเบื้องหลัง ถ้ามีข้อผิดพลาดใด ๆ ปลั๊กอินจะกลับไปใช้การค้นหาด้วยคำ
• ความลับไม่ถูกส่งออกไป ข้อเท็จจริงและข้อความที่ดูเหมือนคีย์ รหัสผ่าน หรือ header การยืนยันตัวตน จะไม่ถูกส่งไปยังเซิร์ฟเวอร์ embeddings คำสั่ง forget ลบเวกเตอร์ของข้อเท็จจริงด้วย และหลังปิดฟีเจอร์ เวกเตอร์ทั้งหมดจะถูกลบ

บนชุดข้อมูลสังเคราะห์ 100 ข้อเท็จจริงในห้าภาษา คำถามที่ถูกเรียบเรียงใหม่หาข้อเท็จจริงที่ต้องการเจอก่อนตอบ 54 จาก 67 กรณีด้วย text-embedding-3-small และ 59 กรณีด้วย gemini-embedding-001 เทียบกับ 22 กรณีเมื่อค้นด้วยคำอย่างเดียว ข้อความคุยเล่นก็ยังไม่ดึงความจำอะไรขึ้นมาเหมือนเดิม

การค้นหาตามความหมายมีอยู่ในเวอร์ชันจากแคตตาล็อก ส่วนการปรับจูนบนฐานข้อมูลจริง ทั้ง bge-m3 เซิร์ฟเวอร์บนเครื่องที่ช้า และกฎว่าเมื่อไหร่ข้อเท็จจริงที่เจอตามความหมายจะแสดงคู่กับผลที่ตรงด้วยคำได้ อยู่ในภาคต่อ

Reranker: ของเกินน้อยลง แต่มีข้อแม้

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

เมื่อใช้ rerank: on ข้อความแชทและข้อความของแคนดิเดตจะถูกส่งไปที่ rerank_url ที่กำหนด ทดสอบแล้วกับ llama-server ต้องได้คำตอบในรูปแบบ Cohere โดยไม่มีการยืนยันตัวตน เพราะไคลเอนต์ไม่ส่งคีย์ ถ้าเกิดข้อผิดพลาดหรือ timeout ผลลัพธ์จะเหมือนตอนปิด reranker ใน 0.19.2 แก้ปัญหาคำขอเบื้องหลังของ reranker และ embeddings ที่ค้างเมื่อเซิร์ฟเวอร์ส่ง header ช้าเกินไป ตั้งแต่ 0.22.2 เซิร์ฟเวอร์ที่ช้าจะได้รับแคนดิเดตเท่าที่มันให้คะแนนทันภายในครึ่งหนึ่งของ timeout ชุดใหญ่จึงไม่ถูกตัดเพราะหมดเวลาและไม่ทำให้เซิร์ฟเวอร์ถูกพักอีก การตั้งค่าและผลการวัดอยู่ในภาคต่อ

18 ภาษาโดยไม่ใช้โมเดลและเน็ต

ปลั๊กอินเข้าใจ 18 ภาษาโดยไม่ต้องพึ่งทั้งโมเดลและเน็ต:

• Snowball stemmer ซึ่งเป็นอัลกอริทึมที่ตัดส่วนท้ายของคำออกและแยกรากคำ สำหรับภาษาอังกฤษ รัสเซีย สเปน ฝรั่งเศส โปรตุเกส อินโดนีเซีย เยอรมัน ฮินดี อิตาลี ตุรกี โปแลนด์ และดัตช์
• อาหรับ ใช้ light stemmer ของ Larkey คู่กับ Snowball ส่วน เบงกาลี มี stemmer ของตัวเอง
• จีน ญี่ปุ่น เกาหลี และไทย ใช้ n-gram ของตัวอักษร

ภาษาของข้อความที่เขียนด้วยอักษรละตินดูจากคำไวยากรณ์ (function words) ในชุดมีพจนานุกรมมาด้วย:

• DerivBase.Ru: คำที่มีรากเดียวกันในภาษารัสเซีย ไลเซนส์ Apache-2.0
• Open English Wordnet: คำที่มีรากเดียวกันในภาษาอังกฤษ ไลเซนส์ CC BY 4.0
• jieba: คำในภาษาจีน ไลเซนส์ MIT และ OpenCC ที่ทำให้อักษรจีนตัวเต็มเทียบเท่ากับตัวย่อ ไลเซนส์ Apache-2.0
• SudachiDict: รูปแบบการเขียนภาษาญี่ปุ่นที่ต่างกัน เช่น 子ども และ 子供 ไลเซนส์ Apache-2.0
• Wikidata Lexemes: คำประสมภาษาเยอรมัน และรูปกริยาของภาษาเยอรมันและสเปน ไลเซนส์ CC0

การตรงกันที่รากคำ รูปในพจนานุกรม หรือส่วนหนึ่งของคำประสม มีน้ำหนัก 0.6 ของการตรงกันแบบเป๊ะ และไม่มีวันดึงข้อเท็จจริงขึ้นมาได้ด้วยตัวเองเพียงลำพัง บนชุดทดสอบแบบ blind ภาษารัสเซียของผม 12 คำถามที่ใช้คำรากเดียวกัน การค้นหาเจอข้อเท็จจริงที่ต้องการ 92% ของกรณี เทียบกับ 75% ใน 0.8.0 และดึงมันเข้าคำตอบเองได้ 67% เทียบกับ 42% พจนานุกรมจะโหลดตอนเจอภาษานั้นครั้งแรก ตัวที่หนักที่สุดคือภาษาจีน ใช้ราว 0.2 วินาทีและ 30 MB

ในการใช้งานจริงเป็นแบบนี้ สิ่งที่หาเจอ: Маши เจอข้อเท็จจริงเรื่อง Машу (ชื่อ Masha ในรูปคำที่ต่างกันของภาษารัสเซีย) คำเยอรมัน Zahnarzttermin เจอ “Termin beim Zahnarzt” คำสเปน fue เจอกริยา ir และ ser ด้วยน้ำหนัก 0.6 İstanbul ตรงกับ ISTANBUL 引越し ตรงกับ 引っ越し อักษรตัวเต็ม 學校 ตรงกับตัวย่อ 学校 สิ่งที่ไม่สับสน: 和服 (กิโมโน) ไม่ถูกเจอในวลี 我和服务员 (“ฉันกับพนักงานเสิร์ฟ”) คำเยอรมัน Hochzeit กับ Zeit และ Matrose กับ Rose เป็นคนละคำ media ไม่ถูกมองว่าเป็นคำอินโดนีเซีย dia คำถามภาษาญี่ปุ่นที่เขียนด้วยคานะเรื่อง 手紙 (จดหมาย) ไม่เจอคำจีน 手纸 (กระดาษชำระ) อีกแล้ว แต่ทิศกลับยังเป็นปัญหาอยู่: คำถามที่มีแต่อักษรคันจิล้วน ๆ ยังแยกไม่ออกจากภาษาจีน

การค้นหายังอาจพลาดได้กับคำที่ไม่มีในพจนานุกรม เช่น มันยังเชื่อม дачный กับ дача ไม่ได้ (คำคุณศัพท์และคำนามของคำว่า “บ้านพักตากอากาศ” ในภาษารัสเซีย)

สิ่งที่ปลั๊กอินไม่ยอมให้เข้าหน่วยความจำ

ตอนเขียน holographic จะปฏิเสธและอธิบายเหตุผลกับสิ่งเหล่านี้:

• คำสั่งสำหรับโมเดลอย่าง “ignore previous…”
• รหัสผ่าน คีย์ โทเค็น และ PIN ที่มาพร้อมค่าจริง (ตั้งแต่ 0.12.0) และตั้งแต่ 0.14.5 แม้ไม่มีคำว่า “รหัสผ่าน” ก็ปฏิเสธคีย์ โทเค็นของบอต และ JWT ที่จำได้จากรูปแบบ ตั้งแต่ 0.15.2 ปฏิเสธค่าของตัวแปรอย่าง OPENAI_API_KEY ด้วย
• รูปภาพแบบ Markdown และ HTML (ตั้งแต่ 0.13.0) เพราะเป็นช่องทางรั่วไหล: ไคลเอนต์จะโหลดรูปภาพจาก URL นั้นเองโดยอัตโนมัติ และข้อมูลอาจแฝงออกไปใน URL นั้น
• markup ของบทบาท (role) JSON ของเครื่องมือ และอักขระที่มองไม่เห็น

ตั้งแต่ 0.22.1 การตรวจนี้เร็วขึ้นราว 30 เท่ากับข้อความยาว ๆ โดยยังตัดสินเหมือนเดิม: ข้อความภาษารัสเซียขนาดหนึ่งเมกะไบต์ใช้เวลาตรวจ 0.3 วินาที แทนที่จะเป็น 9 วินาที

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

สิทธิ์การเขียนถูกแยกกัน การเรียกแบบระบุชัดจาก cron จะเขียนได้ถ้าเปิด cron_writes ส่วนการเขียนอัตโนมัติใน cron ถูกปิดไว้โดยการออกแบบ subagent และบริบทภายในสำหรับการบีบอัดอ่านได้อย่างเดียว

Hermes-dreaming: การนอนหลับของหน่วยความจำตอนกลางคืน

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

โดยค่าเริ่มต้น รอบกลางคืนคือสคริปต์ Python แบบ deterministic ที่ใช้แค่ standard library: มันไม่เรียกโมเดลและไม่เขียนหน่วยความจำ แต่ปลุกเอเจนต์เมื่อมีเรื่องให้ตัดสินใจ ไอเดียนี้ยืมมาจาก dreaming ของ OpenClaw ตั้งแต่เวอร์ชัน 3.3 เปิดผู้ตัดสินบนคลาวด์ได้ แล้วสคริปต์จะส่งคู่ “ข้อเท็จจริง — ข้อความ” ที่อนุญาตไว้ไปให้โมเดลตัดสินแยกต่างหาก ใน dreaming 3.4 มีข้อเสนอให้รวมรายการซ้ำผ่าน holographic 0.19 ถ้าคนไม่ตอบ รอบกลางคืนจะไม่รวมเอง ตั้งแต่ 3.5 ตัวติดตั้งอัปเดตงาน cron ให้เอง และตั้งแต่ 3.8 หน่วยความจำถาวรจะรับเฉพาะสิ่งที่คนพูดเองหรือยืนยันแล้ว รายละเอียดอยู่ในภาคต่อเรื่อง dreaming

หนึ่งคืนผ่านไปแบบนี้:

1. อินพุต: ข้อเท็จจริงจาก holographic ข้อความของคนจากฐานข้อมูลเซสชันของ Hermes และไฟล์ MEMORY.md กับ USER.md
2. การยืนยัน แคนดิเดตเข้าหน่วยความจำต้องมาจากปากคนในหลายวันที่ต่างกัน ข้อความจาก cron ลิงก์ และเธรดของรอบ dreaming เองไม่นับ
3. เทียบกับหน่วยความจำ: รายการซ้ำ ชื่อแฝง และ “เรื่องเดียวกันแต่ตัวเลขต่างกัน”
4. กักกัน: ความลับและความพยายามทำ injection ถูกตัดออก เหตุการณ์ที่มีวันที่จะหมดอายุไป

ถ้าไม่มีงาน รอบนี้จะตอบ {"wakeAgent": false} และโมเดลจะไม่ถูกเรียกเลย ถ้ามีงาน เอเจนต์จะได้หนึ่งเทิร์น เขียนด้วยเครื่องมือ memory และในหนึ่งคืนแก้ได้ไม่เกินหกรายการ เพิ่มรายการใหม่ได้ไม่เกินสาม การให้คะแนนแคนดิเดตใช้น้ำหนักหกตัวจาก OpenClaw วันที่และเหตุการณ์อ่านได้ 15 ภาษา ส่วนจีน ญี่ปุ่น เกาหลี และไทยใช้ n-gram

สิ่งที่เอเจนต์ได้รับในเทิร์นนี้:

• แคนดิเดตที่จะบันทึก ต้องบันทึกหรือปฏิเสธ ไม่มีทางที่สาม ข้อสรุปของเอเจนต์ที่ไม่มีใครยืนยันจะไม่กลายเป็นแคนดิเดต: ถ้าคนพูดซ้ำในหลายวัน รอบ dreaming จะเสนอให้ถามเพื่อยืนยัน
• ข้อมูลที่คงที่เกี่ยวกับตัวคน สำหรับ USER.md
• ความขัดแย้ง คือเรื่องเดียวกันแต่ตัวเลขต่างกัน: แทนที่หรือถาม
• รายการที่ล้าสมัย พร้อมคำถาม “ยังเป็นปัจจุบันอยู่ไหม?” ซึ่งเอเจนต์ลบเองไม่ได้
• คำเตือนเมื่อไฟล์หน่วยความจำถูกใช้ไป 85% ของลิมิตขึ้นไป ให้ยุบรายการที่ใกล้เคียงกัน
• การกักกันในบรรทัดเดียว โดยไม่เล่าเนื้อหาซ้ำ
• สัญญาณเตือนเรื่องหน่วยความจำสูญหาย

แคนดิเดตแต่ละรายการมีคำพูดของคนและรายการหน่วยความจำที่ใกล้ที่สุดพร้อมข้อความตรงตัว เพื่อให้ memory replace แทนได้ตรงจุด ข้อเท็จจริงที่คนปฏิเสธ รอบ dreaming จะส่งให้เอเจนต์พร้อมคำสั่ง fact_feedback สำเร็จรูป เพื่อให้การปฏิเสธสอนการค้นหาของ holographic ไปด้วย คำสำคัญสำหรับข้อเท็จจริงเปิดได้ตามต้องการ (keywords.enabled): ในหนึ่งคืน ข้อเท็จจริงจำนวนหนึ่งจะมาพร้อมคำสั่ง fact_store update สำเร็จรูป และรอบ dreaming จะไม่ปลุกโมเดลเพื่อเรื่องนี้

ไม่มีคำถามไหนถูกถามซ้ำตลอดไป

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

• รายการที่ถูกปฏิเสธ เก็บสิ่งที่ถูกปฏิเสธตามข้อความ ไม่ใช่ตามหมายเลข ตั้งแต่ 2.7.0 ถามซ้ำได้หลังครึ่งปี (reject_reask_days 180 วัน) ถ้ามีคนพูดถึงข้อเท็จจริงนั้นอีก: มีรายการใหม่ในฐานข้อมูล และคนพูดถึงหลังจากการปฏิเสธ
• การพัก ข้อเท็จจริงใหม่ ความขัดแย้ง และคำถามเรื่องความเป็นปัจจุบัน แสดงไม่บ่อยกว่าหนึ่งครั้งใน 14 วัน รายการที่ผ่านคำถาม “ยังเป็นปัจจุบันอยู่ไหม?” มาได้จะนับว่าได้รับการยืนยันแล้วและพักไป 90 วัน การนับเริ่มหลังเอเจนต์ตอบเท่านั้น: คืนที่พังกลางทางจะแสดงเรื่องเดิมอีกครั้ง
• ความขัดแย้ง จับได้จากตัวเลข วันที่ เดือน และตั้งแต่ 2.7.0 ก็จากวันในสัปดาห์: “บัลเลต์ย้ายไปวันอังคาร” คือการอัปเดต
• ตัวเฝ้าการสูญหาย ส่งสัญญาณเตือนถ้ารายการหรือตัวอักษรในหน่วยความจำหายไปเกิน 25%
• Probe (ตั้งแต่ 2.7.0) คือวลีที่ต้องอยู่ในหน่วยความจำเสมอ เช่น “แพ้ถั่วลิสง” ถ้าหายไปจะมีสัญญาณเตือนหนึ่งครั้ง
• รายการซ้ำในฐานข้อมูล ตรวจอย่างฉลาด: วันที่สองวันของเหตุการณ์เดียวกันไม่ใช่รายการซ้ำ

holographic กับ dreaming ทำงานร่วมกันอย่างไร

เวอร์ชันใหม่ของทั้งสองปลั๊กอิน ผมทำไปพร้อมกัน ใน holographic 0.8.0 งาน cron กลับมาเขียนข้อเท็จจริงด้วยการเรียกแบบระบุชัดได้อีกครั้ง (พารามิเตอร์ cron_writes ค่าเริ่มต้นเปิดอยู่): ตั้งแต่ 0.2.0 การเขียนจาก cron ถูกปิดไว้ และเปิดกลับมาด้วยพารามิเตอร์แยกเพื่อการสกัดข้อเท็จจริงตอนกลางคืนของ dreaming ส่วนการสกัดอัตโนมัติและการ mirroring ใน cron ยังปิดอยู่เหมือนเดิม

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

บทบาทแบ่งกันแบบนี้:

• holographic เก็บข้อเท็จจริงและประวัติของมัน
• สคริปต์ dreaming เปิดฐานข้อมูลแบบอ่านอย่างเดียว เทียบข้อเท็จจริงกับบทสนทนาของคน และเสนอการเปลี่ยนแปลง
• เอเจนต์ใน cron ลงมือตามการตัดสินใจ: เขียนหน่วยความจำด้วยเครื่องมือ memory และเขียนลง holographic ผ่าน fact_store โดยแปลง “อันนี้ไม่จริงแล้ว” “อันนั้นผิดมาตั้งแต่แรก” และ “ลืมไปเลย” เป็น end, correct และ forget
• งานแยก ลบสำเนาภายในของข้อเท็จจริงที่ถูกลืม

จุดเชื่อมระหว่างสองปลั๊กอินมีสามจุด:

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

สัญญาระหว่างสองปลั๊กอินคือชื่อไฟล์ ตารางข้อเท็จจริงและตารางสิ่งที่ถูกลืม และคีย์การตั้งค่า plugins.hermes-memory-store

การใช้คู่กันนี้มีขอบเขต เมื่อใช้ scope: user, chat หรือ thread ข้อเท็จจริงจะอยู่ในไฟล์แยก: โดยค่าเริ่มต้นรอบกลางคืนจะไม่อ่านไฟล์เหล่านี้ ไม่อย่างนั้นมันอาจย้ายข้อเท็จจริงของแชทหนึ่งไปไว้ในหน่วยความจำที่ทุกคนเห็น และงาน cron ที่ไม่มีบริบทของแชทก็ไม่ได้เขียนลงที่นั่นอยู่แล้ว เมื่อ cron_writes: false การเขียนจาก cron ก็ถูกปิดเช่นกัน ตั้งแต่ 2.5.3 dreaming จะบอกสาเหตุในรายงานและไม่ปลุกโมเดลเพื่อการสกัด ส่วนการตรวจอื่นตอนกลางคืนยังทำงานตามปกติ

ตั้งแต่เวอร์ชัน 2.6.0 dreaming ทำงานกับฐานข้อมูลของแต่ละแชทได้ด้วย (chat_stores ค่าเริ่มต้นปิดอยู่) ในโหมดอ่าน แต่ละฐานข้อมูลจะเข้าไปในรายงานแค่เป็นตัวเลข ไม่มีข้อความและไม่มีหมายเลข ในโหมดโปรโมต ข้อเท็จจริงของแชทที่เลือกจะเข้าร่วมในรอบนี้ แต่แต่ละรายการจะได้รับการยืนยันจากข้อความในแชทของตัวเองเท่านั้น ข้อเท็จจริงแบบนี้จะมีหมายเลขแบบ <ฐานข้อมูล>#17 และเข้าไปที่ memory เท่านั้น ไม่มี fact_store เลย “ลืมไปเลย” ต้องพูดในแชทนั้นเอง สิ่งที่ถูกบันทึกลงหน่วยความจำส่วนกลาง ทุกแชทจะเห็น เรื่องนี้ควรจำไว้ รวมถึงตอนโปรโมตด้วย

ติดตั้งสองปลั๊กอินนี้คู่กันอย่างไร

Holographic ติดตั้งจากแคตตาล็อก ถ้ามีปลั๊กอินอยู่แล้ว ให้เติม --force ในคำสั่งติดตั้งเพื่ออัปเดตเป็นเวอร์ชันที่ปักไว้: การสกัดข้อเท็จจริงตอนกลางคืนต้องใช้ 0.8.0 ขึ้นไป

hermes plugins install holographic
hermes config set memory.provider holographic

Dreaming:

hermes plugins install hermes-dreaming
hermes plugins enable hermes-dreaming
python3 ~/.hermes/plugins/hermes-dreaming/skills/dreaming/scripts/install.py

install.py วางสคริปต์ภายใน สร้าง ~/.hermes/dreaming.json จากไฟล์ตัวอย่าง และรันทดลองหนึ่งรอบ ต่อจากนั้นคือส่วนที่ไม่มีใครทำแทนคุณได้: ระบุกลุ่มที่เชื่อถือได้ใน trusted_chat_ids เขตเวลาไม่ต้องใส่ซ้ำ เพราะดึงมาจากการตั้งค่าของ Hermes ตราบใดที่รายการยังว่าง จะไม่มีแชทกลุ่มไหนยืนยันข้อเท็จจริงได้ ถ้าแชทที่เชื่อถือได้เป็นฟอรัม ให้ระบุใน excluded_threads ว่าเธรดไหนไม่ใช่คนคุยกัน เช่น การแจ้งเตือนของเอเจนต์ bridge และการ์ดอัตโนมัติ

งาน cron ติดตั้งด้วย interpreter ของ Hermes โดยลองแบบทดลองก่อน:

~/.hermes/hermes-agent/venv/bin/python \
    ~/.hermes/plugins/hermes-dreaming/skills/dreaming/scripts/install_cron.py --deliver local --dry-run

ถ้าแผนโอเค ให้รันซ้ำโดยไม่มี --dry-run จะได้งานสามงาน: รอบ dreaming ตอนกลางคืน การสกัดข้อเท็จจริง (รันสัปดาห์ละครั้งก็พอ) และการล้างสิ่งที่ถูกลืมทุก 15 นาที หลังอัปเดตปลั๊กอินทุกครั้ง ให้รัน install_cron.py --upgrade (ลองด้วย --dry-run ก่อน) และ install.py --check: ตัวแรกอัปเดตสคริปต์ภายในและคำสั่งมาตรฐานของงาน ตัวที่สองตรวจการติดตั้งโดยไม่เปลี่ยนอะไร ต้องใช้ Hermes 0.21 ขึ้นไป

README ของ dreaming แนะนำให้ติดตั้งจากแคตตาล็อก ไม่ใช่จากลิงก์ ณ วันที่ 30 ตุลาคม แคตตาล็อกให้ dreaming 3.7.1 ส่วนรีลีสล่าสุดคือ 3.8.0 Holographic เป็นแหล่งข้อเท็จจริงโดยค่าเริ่มต้น แต่ใช้ไฟล์ export เป็น SQLite หรือ JSONL ก็ได้ การสกัดข้อเท็จจริงตอนกลางคืนต้องใช้ holographic 0.8.0 ขึ้นไป การรวมรายการซ้ำต้องใช้ holographic 0.19.0+ และ dreaming 3.4.0+ ตั้งแต่ dreaming 3.5.0 ตัวติดตั้งจะอัปเดตคำสั่งมาตรฐานของงาน cron ที่มีอยู่ให้เอง ส่วนงานที่แก้ด้วยมือจะปล่อยไว้พร้อมคำเตือน ขั้นตอนอยู่ในภาคต่อ

สิ่งที่ต้องคำนึงเวลาใช้งาน

• การเรียบเรียงใหม่ เมื่อไม่ใช้โมเดล ประโยคที่เรียบเรียงใหม่โดยไม่มีคำร่วมกันจะเชื่อมกันได้ด้วยคำสำคัญที่เอเจนต์เพิ่มให้ข้อเท็จจริง เช่น คำพ้องความหมาย คำที่มีรากต่างกัน หรือคำแปล ตั้งแต่เวอร์ชัน 0.14 เปิดการค้นหาตามความหมายได้ คำที่มีรากเดียวกันหาเจอด้วยพจนานุกรม ถ้าคู่คำไม่มีในพจนานุกรม อย่าง дачный กับ дача คำสำคัญจะช่วยได้
• ฐานข้อมูลใหญ่ สำหรับภาษาที่ค้นด้วยการสแกนคำ การค้นหาแบบนี้ครั้งแรกหลังเปิดระบบจะไล่ข้อเท็จจริงทั้งหมด: ถ้ามี 20,000 รายการ จะใช้ 4–6 วินาที สำหรับฐานข้อมูลที่ใหญ่กว่านั้น มีแผนจะทำดัชนีคีย์แบบถาวร
• scope: user ใน dreaming ข้อความในฐานข้อมูลของ Hermes ไม่มีผู้เขียน ในกลุ่มจึงนับเจ้าของเซสชันเป็นผู้เขียน
• วันในสัปดาห์ dreaming อ่านเป็นคำเต็ม ตัวย่ออย่าง Tue และ Wed ยังไม่รองรับ
• forget ลบข้อเท็จจริงออกจากฐานข้อมูล holographic ส่วน dreaming ลบสำเนาภายในของตัวเอง ฐานข้อมูลเซสชันของ Hermes ประวัติ Git และที่เก็บถาวรภายนอกต้องล้างแยกต่างหาก

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

ใครดูแล holographic

holographic ตัวแรกสร้างโดย dusterbloom และ provider นี้ก็มากับ Hermes อยู่แล้ว บทบาทของผมคือดูแลและพัฒนาเวอร์ชันแยกของมันหลังออกจากแกนหลัก

fork ของผมได้เข้าแคตตาล็อก: itpartypattaya/hermes-plugin-holographic ณ วันที่ 30 ตุลาคม แคตตาล็อกทางการบันทึกเวอร์ชัน 0.22.0 คอมมิต ff558dd และผู้ดูแล itpartypattaya เวอร์ชันนี้มีการค้นหาตามความหมาย การเก็บกวาดเอนทิตี reranker แบบทดลอง การรวมรายการซ้ำ บันทึกผลลัพธ์ของงาน และลิมิต token ของบล็อกความจำ รีลีสล่าสุดของรีโพคือ 0.23.1

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

คำถามที่พบบ่อย

ข้อเท็จจริงจะหายไหมหลัง hermes update? ไม่หาย ถ้าในการตั้งค่าเป็น memory.provider: holographic: การอัปเดตจะติดตั้งปลั๊กอินจากแคตตาล็อก และเก็บ memory_store.db กับการตั้งค่าเดิมไว้ แต่ก็ยังควรสำรองข้อมูลก่อนอัปเดต

ต้องทำอะไรด้วยมือไหม? คนที่เคยใช้ provider ในตัวไม่ต้องย้ายข้อเท็จจริง hermes plugins list จะแสดงเวอร์ชันที่ติดตั้งอยู่ ส่วน hermes plugins install holographic --force จะติดตั้งเวอร์ชันที่ปักไว้ในแคตตาล็อก ณ วันที่ 30 ตุลาคม คือ 0.22.0 ถ้าคุณเคยใช้ merge แล้ว อย่าถอยไปต่ำกว่า 0.19.0 โดยไม่กู้ฐานข้อมูลก่อนการรวมกลับมา สำหรับคนที่เคยติดตั้งรีโพเก่าของ Nous Research จากลิงก์ README แนะนำให้ติดตั้งใหม่จากแคตตาล็อกหนึ่งครั้ง

หลังย้ายอัตโนมัติ จะได้เวอร์ชันไหน? เวอร์ชันที่ปักไว้ในแคตตาล็อก ณ ตอนที่ย้าย ส่วนวันที่ 30 ตุลาคม แคตตาล็อกปักไว้ที่ 0.22.0 ส่วนในรีโพออก 0.23.1 แล้ว เวอร์ชันของคุณดูได้ด้วยคำสั่ง hermes plugins list

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

holographic ทำงานร่วมกับ hermes-dreaming ได้ไหม? ได้ holographic เป็นแหล่งข้อเท็จจริงโดยค่าเริ่มต้นของ dreaming การสกัดข้อเท็จจริงตอนกลางคืนต้องใช้ holographic 0.8.0 ขึ้นไป ส่วนประวัติและการลืมต้องใช้ dreaming 2.4.0 ขึ้นไปด้วย เวอร์ชันล่าสุดอยู่ในรีโพ holographic และ hermes-dreaming