Brain-AI Memory – สถาปัตยกรรมแบบเปิดสำหรับวินิจฉัยความล้มเหลวด้านความจำของเอเจนต์ LLM ที่ทำงานระยะยาว

หากมองปัญหาที่เอเจนต์ใช้ความทรงจำเก่า ถามซ้ำสิ่งที่เคยบันทึกไว้แล้ว ละเลยกฎ หรือเลิกทำขั้นตอน fallback กลางคัน ว่าเป็นเพียง “ปัญหา retrieval” ทั้งหมด ก็จะหาสาเหตุได้ยาก
Brain-AI Memory ไม่ใช่โปรเจ็กต์ที่แค่เรียก RAG, hook, guard, harness และ loop ด้วยชื่อใหม่ แต่แยกสิ่งเหล่านี้ออกเป็น episodic·semantic memory, procedural rule·execution, numerical state, routing และ input gate พร้อมเชื่อมแต่ละแบบเข้ากับเงื่อนไขความล้มเหลวและ lifecycle ของมัน
โครงสร้างนี้ถูกเปิดเผยในรูปแบบ clean-room หลังจากใช้งานจริงในระบบ multi-project agent system มาหลายเดือน โดยมีทั้งตัวอย่างการทำงาน 60 วินาที, hook และ memory template ที่นำกลับมาใช้ใหม่ได้, เหตุผลเชิงปฏิบัติการ และผลลัพธ์การ retrieval ของ LongMemEval-S จำนวน 500 ข้อ
ผลลัพธ์ด้านลบของ benchmark ก็เปิดเผยตามจริงเช่นกัน pointer แบบ 96-keyword ลด indexed text ลงได้ 93% แต่ recall@3 ลดลงจาก 86.1% ของ full BM25 เหลือ 71.0%
โดยเฉพาะอย่างยิ่ง ผู้เขียนต้องการรับฟังฟีดแบ็กว่าความล้มเหลวของ agent ในโลกจริงสอดคล้องกับ component mapping นี้มากน้อยเพียงใด และตรงไหนที่ยังไม่สอดคล้อง

[gkgusdl4]

README ภาษาเกาหลี:
https://github.com/Hahyun-Lee/brain-ai-memory/blob/main/README.ko.md

รันภายใน 60 วินาที:
git clone https://github.com/Hahyun-Lee/brain-ai-memory.git
cd brain-ai-memory
python3 examples/01_guard_in_action.py
python3 examples/02_lifecycle_decision.py

อยากได้ฟีดแบ็กเป็นพิเศษในสองประเด็นนี้ครับ/ค่ะ

1. failure ของ agent ที่รันระยะยาวในสถานการณ์จริง สามารถแยกแยะได้เพียงพอด้วย component mapping นี้หรือไม่?
2. สิ่งที่จำเป็นกว่าเพื่อให้มีการนำไปใช้จริงคือ installable reference implementation หรือ end-to-end QA benchmark?