Tool: endeavor_memory_query — ค้นความจำโปรเจกต์พร้อมธง staleness บอกว่าอาจไม่ตรงของจริงแล้ว
endeavor_memory_query ค้นความจำที่บันทึกไว้ด้วยคำถามหรือเงื่อนไข เพื่อให้ agent ดึงเฉพาะข้อมูลที่เกี่ยวข้องกลับมาใช้ แทนการอ่านประวัติทั้งหมดยาว ๆ ในทุกครั้ง
Tool นี้คืออะไร
ค้นทั้ง Markdown-derived knowledge และ durable record ปัจจุบัน (current head ของ memory_records) พร้อมกันในคำเรียกเดียว — เป็น tool ที่ implement pipeline ที่อธิบายไว้ใน บทความ how it works ทั้งหมด: multi-pass lexical FTS, semantic search (ถ้า companion พร้อม), RRF fusion สองชั้น (ภายในแต่ละคลัง แล้วรวมข้ามคลังอีกที)
ธง stale: บอกตรงๆ ว่า index อาจไม่ตรงกับความจริงแล้ว
จุดสำคัญที่สุดของ tool นี้: ผลลัพธ์แต่ละรายการมีธง stale กำกับ — ถ้า stale=true แปลว่าhash ของเนื้อหาที่ index ไว้ไม่ตรงกับไฟล์ต้นฉบับบน disk อีกต่อไป (ไฟล์ถูกแก้ไปแล้วแต่ยังไม่ sync กลับเข้า index) Docstring บอกโมเดลตรงๆ ว่าเมื่อเจอ stale=true ต้องเปิดไฟล์ต้นฉบับดูจริง ไม่ใช่เชื่อเนื้อหาที่ query คืนมาตรงๆ — เพราะ ENDMEMEX ไม่มี filesystem watcher (ตามที่อธิบายใน how it works) การเปลี่ยนแปลงไฟล์ไม่ sync เข้า index อัตโนมัติ ธง stale จึงเป็นกลไกเดียวที่เตือนว่าเนื้อหาที่เห็นอาจล้าสมัยไปแล้ว
semantic เลือกได้ 3 โหมด — ไม่บังคับรอ companion เสมอ
พารามิเตอร์ semantic มี 3 ค่า: auto (ใช้ semantic เฉพาะถ้า MiniLM companion พร้อมอยู่แล้วเท่านั้น ไม่รอ ไม่ spawn ใหม่), on (ยอม spawn/รอ companion ให้พร้อมก่อนค้น), off (บังคับ lexical อย่างเดียว) — ดีฟอลต์เป็น auto เพราะการรอ companion โหลดโมเดลอาจกินเวลาหลายวินาที ถ้าไม่จำเป็นต้องได้ผลลัพธ์ semantic แม่นที่สุด auto ให้ผลตอบเร็วกว่าโดยยังได้ผล lexical เต็มรูปแบบ
Filter เจาะจงหลายมิติ ไม่ใช่แค่ full-text อย่างเดียว
นอกจาก query ยังกรองได้ด้วย category, status (open/resolved/accepted — สำหรับ Markdown-derived knowledge เท่านั้น), module (ชื่อไฟล์เป๊ะ เช่น react.py), bug_id, session_label — การมี filter หลายมิตินี้ทำให้ query แคบลงได้มากเมื่อรู้บริบทเจาะจง เช่นค้นเฉพาะความรู้ที่เกี่ยวกับไฟล์หนึ่งไฟล์ หรือ bug หนึ่งใบ แทนที่จะค้นแบบกว้างแล้วกรองเอาเองทีหลัง
compact: ตัดฟิลด์เหลือแค่ที่ต้องใช้บ่อย
ดีฟอลต์ compact=true ตัดผลลัพธ์ให้เหลือ ~8 ฟิลด์ที่ใช้บ่อยตอน browse (ไม่ใช่ทุกฟิลด์ในฐานข้อมูล) — ประหยัด context เมื่อแค่ต้องการดูภาพรวมผลลัพธ์ ปิด compact เฉพาะเมื่อต้องการรายละเอียดเต็มของ record จริงๆ
ไม่ใช้เขียน checkpoint — ระบุไว้ตรงๆ กันความเข้าใจผิด
Docstring ปิดท้ายด้วยประโยคสั้นแต่สำคัญ: “Do not use it to write a checkpoint” — เป็น READ ONLY tool ล้วนๆ แม้จะเจอสิ่งที่น่าบันทึกระหว่างค้น ก็ต้องเรียก endeavor_memory_checkpoint แยกต่างหาก การแยกความรับผิดชอบ read กับ write ให้ชัดเจนแบบนี้ช่วยให้ tool แต่ละตัวมีพฤติกรรมที่คาดเดาได้ ไม่มี side effect แอบแฝง
เพื่อนคู่กัน: endeavor_memory_feedback วัดคุณภาพการค้นจากการใช้งานจริง
หลังใช้ผลลัพธ์จาก query แล้ว มี tool คู่กันคือ endeavor_memory_feedback ให้บันทึกว่าผลลัพธ์ ID ไหนมีประโยชน์จริง — ข้อมูลนี้สะสมไว้ให้ “retrieval quality can be evaluated from production usage” พูดง่ายๆ คือ ENDMEMEX เก็บสถิติว่าการค้นแต่ละครั้งได้ผลลัพธ์ที่มีประโยชน์จริงแค่ไหนจากการใช้งานจริง ไม่ใช่แค่ประเมินจาก benchmark ที่ตั้งไว้ล่วงหน้าเท่านั้น (eval_queries.json ตามที่กล่าวถึงใน how it works) — เป็น feedback loop ที่ทำให้ปรับปรุงคุณภาพการค้นได้จากข้อมูลจริงในระยะยาว
ทำไมเรื่องนี้ถึงสำคัญ
endeavor_memory_query แสดงหลักการที่สำคัญของระบบความจำที่ไม่โกหกตัวเอง: แทนที่จะสมมติว่า index ตรงกับความจริงเสมอ ระบบรู้ตัวและบอกตรงๆ เมื่อความมั่นใจนั้นไม่ถูกต้องแล้ว (stale=true) — เป็นหลักการเดียวกับ [low_quality] ใน rag_search ของ ENDEAVOR RAG: tool ที่ดีไม่ใช่แค่ตอบคำถาม แต่ยังต้องบอกด้วยว่าคำตอบนั้นน่าเชื่อถือแค่ไหน
ความคิดเห็น
กำลังโหลดความคิดเห็น...