# แนวทางปฏิบัติที่ดีที่สุดสำหรับ Memory
SUMMARY: วิธีจัดโครงสร้าง memory เพื่อ recall ที่มีประสิทธิภาพ — category, key, tag, priority

แนวทางปฏิบัติที่ดีที่สุดสำหรับ Memory
วิธีที่คุณจัดโครงสร้าง memory กำหนดว่ามันจะมีประโยชน์แค่ไหน คู่มือนี้ครอบคลุมรูปแบบสำหรับจัด category, tag และกำหนด priority ของ memory เพื่อให้ LLM recall ข้อมูลที่ถูกต้องในเวลาที่เหมาะสม
Category: เลือกอันที่เฉพาะเจาะจงที่สุด
| Category | ใช้สำหรับ | ตัวอย่าง |
|----------|---------|---------|
|  | ชื่อผู้ใช้, role, ข้อมูลติดต่อ |  |
|  | สิ่งที่ชอบ/ไม่ชอบ, สไตล์การทำงาน |  |
|  | fact ที่ตรวจสอบได้ |  |
|  | สถานะโปรเจกต์, การตัดสินใจ |  |
|  | ทักษะผู้ใช้ |  |
|  | error ในอดีตที่ต้องหลีกเลี่ยง |  |
|  | context ที่เกี่ยวข้องกับ session |  |
|  | note อื่น ๆ |  |
> [!TIP]
> เมื่อไม่แน่ใจ ใช้  สำหรับข้อมูลที่ตรวจสอบได้ และ  สำหรับทุกอย่างอื่น อย่า categorize มากเกินไป —  ที่ชัดเจนดีกว่า  ที่สับสน
Key: identifier ที่มีความหมาย
ฟิลด์  เป็น identifier ของ memory ใช้ key ที่มีความหมายและคงที่:
Key ที่ดี:
- 
- 
- 
- 
Key ที่ไม่ดี:
-  (ไม่มีความหมาย)
-  (ไม่บรรยาย)
-  (วันที่ไม่ช่วย recall)
หลักการตั้งชื่อ key
-  (ตัวพิมพ์เล็กด้วย underscore)
- นำหน้าด้วย category: , , 
- ใช้คำนามที่บรรยาย ไม่ใช่กริยา
- ความยาวไม่เกิน 50 ตัวอักษร
Tag: สำหรับการค้นหาและกรอง
Tag เปิดใช้งานการกรองและค้นหาที่รวดเร็ว เพิ่ม 2-5 tag ต่อ memory:
[CODE BLOCK]
รูปแบบ tag
- ชื่อโปรเจกต์: , , 
- หัวข้อ: , , , 
- สถานะ: , , 
- ตัวบ่งชี้ priority: , 
> [!NOTE]
> tag ไม่ sensitive ต่อตัวพิมพ์เล็ก/ใหญ่ ใช้ตัวพิมพ์เล็กเพื่อความสม่ำเสมอ
Priority: สมจริง
| Priority | ใช้สำหรับ | % ของ Memory |
|----------|---------|---------------|
|  | ตัวตนผู้ใช้, ข้อมูลทางกฎหมาย, การตัดสินใจย้อนกลับไม่ได้ | 5% |
|  | โปรเจกต์ที่ใช้งาน, ค่ากำหนดสำคัญ | 20% |
|  | fact, note, context ส่วนใหญ่ | 65% |
|  | ชั่วคราว, รู้ไว้ก็ดี | 10% |
> [!WARNING]
> อย่าทำเครื่องหมายทุกอย่างเป็น  ถ้าทุกอย่าง critical ก็ไม่มีอะไร critical เลย สงวน  สำหรับสิ่งที่จะก่อให้เกิดอันตรายจริงหากลืม
เมื่อใดเก็บ vs ไม่เก็บ
เก็บเสมอ
- ตัวตนผู้ใช้ (ชื่อ, email, role)
- ค่ากำหนดระยะยาว
- การตัดสินใจและเหตุผลของโปรเจกต์
- mistake และบทเรียนในอดีต
- คำมั่นสัญญาที่ให้กับผู้ใช้
ไม่เก็บ
- state ชั่วคราว (ใช้ variable แทน)
- ประวัติการสนทนาแบบ verbatim (ระบบแช็ตจัดการสิ่งนี้)
- ข้อมูล sensitive (รหัสผ่าน, API key)
- fact ที่ derive ง่าย (วันที่ปัจจุบัน, เนื้อหาไฟล์)
- context ชั่วคราว (ใช้ category  พร้อม priority ต่ำ)
การอัปเดต Memory
POST  ด้วย  +  เดิมจะอัปเดต memory ที่มีอยู่:
[CODE BLOCK]
> [!TIP]
> ใช้ key ที่คงที่เพื่อให้อัปเดตได้โดยไม่สร้างซ้ำ LLM ควร POST ซ้ำ key เดิมเมื่อข้อมูลเปลี่ยน ไม่ใช่สร้าง memory ใหม่
วงจรชีวิต Memory
[CODE BLOCK]
- Create: POST /memory พร้อม context เต็ม
- Active: recall บ่อย, อัปเดตตามต้องการ
- Stale: ยังเกี่ยวข้องแต่ไม่ได้ใช้งาน (priority ต่ำกว่า?)
- Archive: ตั้ง priority เป็น , เก็บเพื่ออ้างอิงทางประวัติศาสตร์
- Delete: DELETE /memory/:id เมื่อไม่เกี่ยวข้องอีก
การทำความสะอาดเป็นคาบ
[CODE BLOCK]
รูปแบบ: การสืบทอด Memory
สำหรับ context แบบลำดับชั้น (โปรเจกต์ → โปรเจกต์ย่อย → task):
[CODE BLOCK]
LLM สามารถค้นหา  เพื่อหา memory ที่เกี่ยวข้องทั้งหมด
รูปแบบ: Decision Log
เก็บการตัดสินใจพร้อมเหตุผลเพื่อให้ LLM ไม่ต้องถกเถียงใหม่:
[CODE BLOCK]
รูปแบบ: การหลีกเลี่ยง Mistake
เก็บ mistake พร้อมคำแนะนำการหลีกเลี่ยงเฉพาะ:
[CODE BLOCK]
รูปแบบที่ควรหลีกเลี่ยง
> [!WARNING]
> - เก็บ log การสนทนา — ระบบแช็ตจัดการสิ่งนี้
> - เก็บไฟล์ทั้งหมด — ใช้ script store หรือ external storage
> - เก็บ state ชั่วคราว — ใช้ variable
> - เก็บ secret — ใช้ environment variable
> - ซ้ำ memory — ใช้ key ที่คงที่
> - tag มากเกินไป — 2-5 tag ต่อ memory เป็นอุดมคติ
> - ทุกอย่างเป็น critical — สมจริงกับ priority
ขั้นตอนถัดไป
- Memory API
- Persistent LLM Agent
- Memory Tagging Strategy