# โมเดล Memory
SUMMARY: วิธีที่ memory ถูกจัดโครงสร้าง — category, key, tag, priority, source, การยืนยัน

โมเดล Memory
โมเดล memory ของ Synapse ออกแบบมาเพื่อ LLM agent — มีโครงสร้างเพียงพอสำหรับ recall ที่เชื่อถือได้ และยืดหยุ่นพอสำหรับโดเมนใด ๆ
กายวิภาคของ Memory
[CODE BLOCK]
ฟิลด์
| Field | Type | Required | คำอธิบาย |
|-------|------|----------|-------------|
|  | string | auto | ID ที่ไม่ซ้ำ (memxxx) |
|  | enum | ✅ | หนึ่งใน 8 category |
|  | string | ✅ | identifier ที่คงทย (ใช้สำหรับอัปเดต) |
|  | string | ✅ | เนื้อหา memory (text ใด ๆ) |
|  | string[] | – | สำหรับการค้นหาและกรอง |
|  | enum | – | low, normal, high, critical (ค่าเริ่มต้น: normal) |
|  | enum | auto | user, agent (ใครเป็นผู้เก็บ) |
|  | bool | auto | human ยืนยันหรือยัง? |
|  | float | – | 0.0 ถึง 1.0 (ค่าเริ่มต้น: 1.0 สำหรับ user, 0.7 สำหรับ agent) |
|  | timestamp | – | เมื่อไรจะลืม memory นี้ |
|  | string | auto | mind ใดเป็นเจ้าของ |
|  | timestamp | auto | เก็บครั้งแรก |
|  | timestamp | auto | แก้ไขล่าสุด |
Category
แปด category ครอบคลุมกรณีใช้งาน LLM agent ทั่วไป:
| Category | วัตถุประสงค์ | เนื้อหาตัวอย่าง |
|----------|---------|-----------------|
|  | ผู้ใช้คือใคร | "User is Michael Schäfer, software engineer in Berlin" |
|  | ค่ากำหนดผู้ใช้ | "Prefers concise technical responses" |
|  | fact ที่ตรวจสอบได้ | "Office is in Berlin, timezone Europe/Berlin" |
|  | สถานะโปรเจกต์ | "Synapse v1.5.0 deployed, working on v1.6.0 docs" |
|  | ทักษะผู้ใช้ | "Advanced Python, 10+ years" |
|  | error ในอดีต | "Forgot to bump npm version — CI failed" |
|  | context ของ session | "Currently reviewing PR #42" |
|  | note อื่น ๆ | "Try Redis for caching next sprint" |
Key: identifier ที่คงที่
ฟิลด์  สำคัญมาก — เป็นวิธีที่คุณอัปเดต memory โดยไม่สร้างซ้ำ
[CODE BLOCK]
กฎของ key:
- ต้องไม่ซ้ำใน (category, mind)
- ใช้ 
- นำหน้าด้วย category เพื่อความชัดเจน: , 
- รักษาให้คงที่ — อย่าเปลี่ยน key หลังสร้าง
Tag: สำหรับการค้นหา
Tag เปิดใช้งานการกรองและค้นหาที่รวดเร็ว:
[CODE BLOCK]
แนวทางปฏิบัติที่ดีที่สุดสำหรับ tag:
- 2-5 tag ต่อ memory (อย่า tag มากเกินไป)
- ตัวพิมพ์เล็กเพื่อความสม่ำเสมอ
- ใช้ชื่อโปรเจกต์, หัวข้อ, เทคโนโลยี
- tag ไม่ sensitive ต่อตัวพิมพ์เล็ก/ใหญ่
ระดับ Priority
| Priority | เมื่อใช้ | พฤติกรรม Recall |
|----------|-------------|-----------------|
|  | ตัวตน, ทางกฎหมาย, ย้อนกลับไม่ได้ | อยู่บนสุดของ recall เสมอ |
|  | โปรเจกต์ที่ใช้งานอยู่, ค่ากำหนดหลัก | เด่นใน recall |
|  | memory ส่วนใหญ่ (ค่าเริ่มต้น) | ลำดับ recall มาตรฐาน |
|  | ชั่วคราว, รู้ไว้ก็ดี | อาจถูกสรุป |
 เรียงตาม priority (critical ก่อน) แล้วตามความใหม่
Source: User vs Agent
memory ถูก tag ด้วย :
-  — เก็บโดย human (ผ่าน JWT หรือ human UI)
-  — เก็บโดย LLM agent (ผ่าน Mind Key)
สิ่งนี้มีผลต่อ:
- การยืนยัน: memory  ถูก verify อัตโนมัติ, memory  ไม่ได้
- ความมั่นใจ:  ค่าเริ่มต้น 1.0,  ค่าเริ่มต้น 0.7
- Recall:  ทำเครื่องหมาย memory ที่ยังไม่ verify ด้วย "(unverified)"
> [!NOTE]
> ปฏิบัติต่อ memory source  ด้วยความสงสัยพอสมควร อาจเป็นการอนุมานหรือสมมติฐาน ไม่ใช่ที่ผู้ใช้ระบุโดยตรง
การยืนยัน
flag  บ่งชี้ว่า human ได้ยืนยัน memory แล้ว:
- memory : auto-verified ()
- memory : ค่าเริ่มต้น unverified ()
ยืนยัน memory ผ่าน:
[CODE BLOCK]
> [!NOTE]
> การยืนยันต้องใช้ JWT (human auth) ไม่ใช่ Mind Key (agent auth) สิ่งนี้รับประกันว่าเฉพาะ human เท่านั้นที่ทำเครื่องหมาย memory ว่า verified
ความมั่นใจ
ฟิลด์  (0.0 ถึง 1.0) บ่งชี้ความน่าเชื่อถือของ memory:
- 1.0 — ระบุโดยตรงโดยผู้ใช้
- 0.7 — อนุมานโดย agent
- 0.5 — ไม่แน่นอน ต้องตรวจสอบ
- 0.0 — สงสัยอย่างชัดเจน
ตั้งค่า confidence เมื่อเก็บ:
[CODE BLOCK]
การหมดอายุ
ตั้ง  สำหรับ memory ที่ sensitive ต่อเวลา:
[CODE BLOCK]
memory ที่หมดอายุจะไม่ถูกส่งกลับโดย  (แต่ยังมีใน DB) ใช้  เพื่อดู memory ที่จะหมดอายุเร็ว ๆ นี้
วงจรชีวิต Memory
[CODE BLOCK]
พฤติกรรม Recall
 ส่งกลับสรุปแบบ plain-text ที่ปรับให้เหมาะกับ LLM context:
[CODE BLOCK]
- เรียงตาม priority (critical → low) แล้วตามความใหม่
- memory ที่ยังไม่ verify ทำเครื่องหมายด้วย 
- รวม tag เพื่อ context
- Plain text (ไม่ต้อง parse JSON)
ขั้นตอนถัดไป
- Memory API
- Memory Best Practices
- FTS5 Search