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

Seizn Memory คือโครงสร้างพื้นฐานหน่วยความจำ AI ที่ให้หน่วยความจำถาวรที่ค้นหาได้สำหรับแอปพลิเคชัน AI ต่างจากฐานข้อมูล vector ที่เพียงจัดเก็บ/ค้นหา vector Seizn รวมเลเยอร์ผลิตภัณฑ์เต็มรูปแบบ: การดึงหน่วยความจำ การจัดการนโยบาย การจัดการคีย์ การลบ บันทึกการตรวจสอบ และ SDK มันแก้ปัญหาการรักษาบริบทข้ามเซสชัน AI และเปิดใช้งานประสบการณ์ AI แบบเฉพาะบุคคล

ฐานข้อมูล vector เป็นโครงสร้างพื้นฐานการจัดเก็บ/ค้นหาสำหรับ vector Seizn เป็นระบบหน่วยความจำที่สมบูรณ์ที่สร้างบนนั้น โดยมี: การดึงหน่วยความจำอัตโนมัติจากการสนทนา การจัดหมวดหมู่ประเภทหน่วยความจำ การจัดการ namespace/scope การหมุนเวียนคีย์ API บันทึกการตรวจสอบ SDK และคุณสมบัติการกำกับดูแล คิดว่ามันเหมือน 'โครงสร้างพื้นฐานหน่วยความจำ' เทียบกับ 'โครงสร้างพื้นฐานการค้นหา'

ไม่ จุดเริ่มต้นที่พบบ่อยที่สุดคือ: บันทึกหน่วยความจำ -> ค้นหา -> แทรกใน prompt RAG (การรวมบริบทอัตโนมัติ + การสร้างการตอบกลับ) เป็นขั้นตอนถัดไป คุณสามารถเริ่มต้นอย่างง่ายและเพิ่มความซับซ้อนเมื่อจำเป็น

1) POST /api/memories เพื่อบันทึกการตั้งค่าผู้ใช้ 2) GET /api/memories เพื่อค้นหา 3) แทรกผลลัพธ์ใน prompt LLM ของคุณ 4) จากนั้นเพิ่ม /api/extract สำหรับการดึงอัตโนมัติ และ /api/query สำหรับการตอบกลับที่เสริมด้วยหน่วยความจำ

บันทึกข้อมูลที่ยังคงถูกต้องข้ามการสนทนา: การตั้งค่า (โทน ภาษา รูปแบบ) ข้อเท็จจริง (งาน เครื่องมือ โครงสร้างโปรเจกต์) คำแนะนำ ("สรุปในตารางเสมอ") ความสัมพันธ์ ("Alice เป็นหัวหน้าทีม") หลีกเลี่ยงการบันทึกข้อมูลชั่วคราวหรือเฉพาะเซสชันเว้นแต่คุณจะใช้ session scope

อย่าบันทึก: รหัสผ่าน คีย์ API token cookie เซสชัน (ข้อมูลรับรอง) SSN หมายเลขหนังสือเดินทาง บัญชีธนาคาร (PII) ข้อมูลบัตรเครดิต (ข้อมูลการชำระเงิน) สำหรับข้อมูลชั่วคราว ใช้ session scope พร้อม TTL หากจำเป็น

Namespace แยกหน่วยความจำตามโปรเจกต์/ผู้เช่า/สภาพแวดล้อม หากไม่มี ข้อมูลจะผสมกัน คุณภาพการค้นหาลดลง และการลบ/ส่งออกจะยาก แนะนำ: 'org:acme/app:chat/env:prod' หรือ 'project:myapp/env:staging' อย่าใช้เพียง 'default' ในการผลิต

user: การตั้งค่าที่ใช้ทั่วโลกสำหรับผู้ใช้ session: เป้าหมายหรือบริบทที่ถูกต้องเฉพาะสำหรับการสนทนานี้ agent: กฎเฉพาะสำหรับ agent ใน ระบบหลาย agent การใช้ scope ที่ถูกต้องลดความยาว prompt และปรับปรุงความสอดคล้องของการตอบกลับ

memory_type จัดหมวดหมู่หน่วยความจำ: fact (ข้อมูลที่ไม่เปลี่ยนแปลง) preference (ตัวเลือกของผู้ใช้) instruction (กฎที่ต้องปฏิบัติตาม) relationship (การเชื่อมต่อคน/องค์กร) experience (เหตุการณ์ในอดีต) นี่คือแกนที่ทรงพลังที่สุดสำหรับการกรอง การลบ และการใช้นโยบาย

limit: จำนวนหน่วยความจำผู้สมัครที่จะเรียกค้น (ต่ำเกินไป = พลาดสิ่งที่เกี่ยวข้อง สูงเกินไป = บริบทรก) threshold: เกณฑ์ความคล้ายคลึง 0-1 (สูงกว่า = เข้มงวดกว่า) เริ่มด้วย limit=10, threshold=0.7 หากพลาดหน่วยความจำ ลด threshold เป็น 0.6 และเพิ่ม limit เป็น 20 หากมีผลลัพธ์ไม่เกี่ยวข้อง เพิ่ม threshold เป็น 0.75-0.8

มักจะเป็นหนึ่งใน: 1) namespace ผสมกัน 2) บันทึกหน่วยความจำมากเกินไป (รก) 3) threshold ต่ำเกินไป 4) เนื้อหาเป็นนามธรรมเกินไป ('ชอบทุกอย่าง' เทียบกับข้อเท็จจริงที่เฉพาะเจาะจง) วิธีแก้: แยก namespace ทำเนื้อหาให้เฉพาะเจาะจง เพิ่ม threshold

เพิ่มคะแนนความสำคัญและเก็บเฉพาะหน่วยความจำที่สำคัญ ใช้ TTL เพื่อหมดอายุหน่วยความจำเก่าโดยอัตโนมัติ รวมหน่วยความจำที่คล้ายกันเป็นสรุปเป็นระยะ แยก namespace เพื่อลดขอบเขตการค้นหา

กระบวนการที่แนะนำ: 1) เรียกด้วย auto_store=false เพื่อดูตัวอย่างหน่วยความจำที่ดึงมา 2) แสดงผลลัพธ์ให้ผู้ใช้ยืนยัน 3) บันทึกเฉพาะหน่วยความจำที่ได้รับการอนุมัติ 4) เมื่อคุณภาพการดึงได้รับการพิสูจน์แล้ว สลับไปใช้ auto_store=true สำหรับการทำงานอัตโนมัติ

haiku: เร็วกว่า ถูกกว่า ดีสำหรับกรณีส่วนใหญ่ sonnet: แม่นยำกว่า ดีกว่าสำหรับการดึงที่สำคัญ (onboarding สัญญา นโยบาย) ใช้ haiku สำหรับการดึงเป็นกลุ่ม/เริ่มต้น sonnet สำหรับสถานการณ์ที่มีความเสี่ยงสูง

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

สองแนวทาง: 1) ลบตาม ID (แม่นยำ) 2) ลบตาม namespace (ล้างเป็นกลุ่ม) สำหรับองค์กร/การปฏิบัติตาม ตรวจสอบให้แน่ใจว่า 'ลบสมบูรณ์ + บันทึกการตรวจสอบ' บันทึกนโยบายการลบของคุณอย่างชัดเจน

คุณถึงขีดจำกัดอัตรา วิธีแก้: 1) ใช้การถอยกลับแบบเลขชี้กำลัง (1s -> 2s -> 4s) 2) คิวคำขอฝั่งเซิร์ฟเวอร์ 3) ลดความถี่คำขอ: แคชคำค้นหาที่ซ้ำกัน การดำเนินการเป็นกลุ่ม ลดความถี่การดึง

ปัจจัยค่าใช้จ่ายที่ใหญ่ที่สุด: 1) ความถี่การดึง - ลดการเรียก 2) ขอบเขตการค้นหา - ใช้ namespace เพื่อจำกัด 3) การเลือกโมเดล - ใช้ haiku สำหรับงานปกติ sonnet สำหรับงานสำคัญ 4) แคช - แคชคำค้นหาที่ซ้ำ 5) การดำเนินการเป็นกลุ่มเมื่อเป็นไปได้

ไม่แนะนำ - มีความเสี่ยงสูงในการรั่วไหลคีย์ เรียก Seizn จากเซิร์ฟเวอร์ของคุณ (Next.js Route Handler, Cloudflare Worker, serverless function) และให้เบราว์เซอร์เรียกเซิร์ฟเวอร์ของคุณ อย่าเปิดเผยคีย์ API ให้กับโค้ดฝั่งไคลเอนต์

พวกเขาจะต้องการ: 1) ขอบเขตข้อมูล (อะไรถูก/ไม่ถูกบันทึก) 2) การเข้ารหัส (ขณะเก็บ: AES-256 ขณะส่ง: TLS) 3) วิธีการแยกผู้เช่า 4) นโยบายการลบ/เก็บรักษา 5) การเข้าถึงบันทึกการตรวจสอบ 6) นโยบายการหมุนเวียน/หมดอายุคีย์ เก็บหน้าความปลอดภัยและการกำกับดูแลไว้ในเอกสารของคุณ