Pertanyaan yang Sering Diajukan

Seizn Memory adalah infrastruktur memori AI yang menyediakan memori jangka panjang yang dapat dicari untuk aplikasi AI. Berbeda dengan database vektor yang hanya menyimpan/mencari vektor, Seizn mencakup lapisan produk lengkap: ekstraksi memori, manajemen kebijakan, manajemen kunci, penghapusan, log audit, dan SDK. Ini memecahkan masalah mempertahankan konteks lintas sesi AI dan memungkinkan pengalaman AI yang dipersonalisasi.

Database vektor adalah infrastruktur penyimpanan/pencarian untuk vektor. Seizn adalah sistem memori lengkap yang dibangun di atasnya, menyediakan: ekstraksi memori otomatis dari percakapan, kategorisasi tipe memori, manajemen namespace/scope, rotasi kunci API, log audit, SDK, dan fitur tata kelola. Anggap sebagai 'infrastruktur memori' vs 'infrastruktur pencarian'.

Tidak. Titik awal paling umum adalah: simpan memori -> cari -> masukkan ke prompt. RAG (komposisi konteks otomatis + pembuatan respons) adalah langkah selanjutnya. Anda dapat memulai sederhana dan menambahkan kompleksitas sesuai kebutuhan.

1) POST /api/memories untuk menyimpan preferensi pengguna. 2) GET /api/memories untuk mencari. 3) Masukkan hasil ke prompt LLM Anda. 4) Kemudian, tambahkan /api/extract untuk ekstraksi otomatis dan /api/query untuk respons yang ditingkatkan memori.

Simpan informasi yang masih valid lintas percakapan: preferensi (nada, bahasa, format), fakta (pekerjaan, alat, struktur proyek), instruksi ("selalu rangkum dalam tabel"), hubungan ("Alice adalah pemimpin tim"). Hindari menyimpan data sementara atau spesifik sesi kecuali Anda menggunakan session scope.

Jangan pernah menyimpan: kata sandi, kunci API, token, cookie sesi (kredensial), SSN, nomor paspor, rekening bank (PII), informasi kartu kredit (data pembayaran). Untuk data sementara, gunakan session scope dengan TTL jika diperlukan.

Namespace memisahkan memori berdasarkan proyek/tenant/lingkungan. Tanpanya, data tercampur, kualitas pencarian menurun, dan penghapusan/ekspor menjadi sulit. Rekomendasi: 'org:acme/app:chat/env:prod' atau 'project:myapp/env:staging'. Jangan pernah hanya menggunakan 'default' di produksi.

user: Preferensi yang berlaku global untuk pengguna. session: Tujuan atau konteks yang hanya valid untuk percakapan ini. agent: Aturan khusus untuk satu agent dalam sistem multi-agent. Menggunakan scope yang benar mengurangi panjang prompt dan meningkatkan konsistensi respons.

memory_type mengkategorikan memori: fact (informasi tidak berubah), preference (pilihan pengguna), instruction (aturan yang harus diikuti), relationship (koneksi orang/organisasi), experience (peristiwa masa lalu). Ini adalah sumbu paling kuat untuk pemfilteran, penghapusan, dan penerapan kebijakan.

limit: Jumlah kandidat memori yang diambil (terlalu rendah = melewatkan yang relevan, terlalu tinggi = konteks berisik). threshold: Ambang kesamaan 0-1 (lebih tinggi = lebih ketat). Mulai dengan limit=10, threshold=0.7. Jika melewatkan memori, turunkan threshold ke 0.6 dan naikkan limit ke 20. Jika ada hasil tidak relevan, naikkan threshold ke 0.75-0.8.

Biasanya salah satu dari: 1) namespace tercampur, 2) terlalu banyak memori disimpan (berisik), 3) threshold terlalu rendah, 4) konten terlalu abstrak ('suka segalanya' vs fakta spesifik). Solusi: pisahkan namespace, buat konten spesifik, naikkan threshold.

Tambahkan skor kepentingan dan hanya simpan memori penting. Gunakan TTL untuk kedaluwarsa otomatis memori lama. Gabungkan memori serupa secara berkala menjadi ringkasan. Pisahkan namespace untuk mengurangi cakupan pencarian.

Alur yang direkomendasikan: 1) Panggil dengan auto_store=false untuk pratinjau memori yang diekstrak. 2) Tampilkan hasil ke pengguna untuk konfirmasi. 3) Hanya simpan memori yang disetujui. 4) Setelah kualitas ekstraksi terbukti, beralih ke auto_store=true untuk otomatisasi.

haiku: Lebih cepat, lebih murah, baik untuk sebagian besar kasus. sonnet: Lebih akurat, lebih baik untuk ekstraksi penting (onboarding, kontrak, kebijakan). Gunakan haiku untuk ekstraksi batch/awal, sonnet untuk situasi berisiko tinggi.

Ya, tetapi pola yang direkomendasikan adalah: buat memori baru + hapus/arsipkan yang lama. Pendekatan ini lebih baik untuk jejak audit dan mencegah masalah regresi.

Dua pendekatan: 1) Hapus berdasarkan ID (presisi), 2) Hapus berdasarkan namespace (pembersihan batch). Untuk enterprise/kepatuhan, pastikan 'penghapusan lengkap + log audit'. Dokumentasikan kebijakan penghapusan Anda dengan jelas.

Anda telah mencapai batas rate. Solusi: 1) Implementasikan backoff eksponensial (1s -> 2s -> 4s). 2) Antrean permintaan di sisi server. 3) Kurangi frekuensi permintaan: cache query duplikat, operasi batch, kurangi frekuensi ekstraksi.

Faktor biaya terbesar: 1) Frekuensi ekstraksi - kurangi panggilan. 2) Cakupan pencarian - gunakan namespace untuk mempersempit. 3) Pemilihan model - gunakan haiku untuk rutin, sonnet untuk penting. 4) Cache - cache query berulang. 5) Operasi batch jika memungkinkan.

Tidak disarankan - risiko tinggi kebocoran kunci. Panggil Seizn dari server Anda (Next.js Route Handler, Cloudflare Worker, fungsi serverless) dan biarkan browser memanggil server Anda. Jangan pernah mengekspos kunci API ke kode sisi klien.

Mereka akan menginginkan: 1) Cakupan data (apa yang disimpan/tidak disimpan), 2) Enkripsi (saat istirahat: AES-256, saat transit: TLS), 3) Metode isolasi tenant, 4) Kebijakan penghapusan/retensi, 5) Akses log audit, 6) Kebijakan rotasi/kedaluwarsa kunci. Simpan halaman Keamanan dan Tata Kelola di dokumentasi Anda.