שאלות נפוצות

Seizn Memory היא תשתית זיכרון AI שמספקת זיכרון מתמשך וניתן לחיפוש עבור יישומי AI. בניגוד למסדי נתונים וקטוריים שרק מאחסנים/מחפשים וקטורים, Seizn כולל את שכבת המוצר המלאה: חילוץ זיכרון, ניהול מדיניות, ניהול מפתחות, מחיקה, יומני ביקורת ו-SDKs. הוא פותר את בעיית שמירת ההקשר בין סשנים של AI ומאפשר חוויות AI מותאמות אישית.

מסדי נתונים וקטוריים הם תשתית אחסון/חיפוש עבור וקטורים. Seizn היא מערכת זיכרון מלאה הבנויה עליהם, שמספקת: חילוץ זיכרון אוטומטי משיחות, סיווג סוגי זיכרון, ניהול namespace/scope, רוטציית מפתחות API, יומני ביקורת, SDKs ותכונות ממשל. חשוב על זה כ'תשתית זיכרון' לעומת 'תשתית חיפוש'.

לא. נקודת ההתחלה הנפוצה ביותר היא: לאחסן זיכרון -> לחפש -> להזריק לפרומפט. RAG (הרכבת הקשר אוטומטית + יצירת תגובה) הוא השלב הבא. אתה יכול להתחיל פשוט ולהוסיף מורכבות לפי הצורך.

1) POST /api/memories לאחסון העדפת משתמש. 2) GET /api/memories לחיפוש. 3) להזריק תוצאות לפרומפט ה-LLM שלך. 4) מאוחר יותר, להוסיף /api/extract לחילוץ אוטומטי ו-/api/query לתגובות מועשרות בזיכרון.

אחסן מידע שנשאר תקף בין שיחות: העדפות (טון, שפה, פורמט), עובדות (עבודה, כלים, מבנה פרויקט), הנחיות ("תמיד סכם בטבלאות"), קשרים ("אליס היא מנהלת הצוות"). הימנע מאחסון נתונים זמניים או ספציפיים לסשן אלא אם אתה משתמש ב-scope סשן.

לעולם אל תאחסן: סיסמאות, מפתחות API, טוקנים, עוגיות סשן (מידע אימות), מספרי ביטוח לאומי, מספרי דרכון, חשבונות בנק (PII), פרטי כרטיס אשראי (נתוני תשלום). עבור נתונים זמניים, השתמש ב-scope סשן עם TTL אם נדרש.

Namespace מפריד זיכרונות לפי פרויקט/דייר/סביבה. בלעדיו, נתונים מתערבבים, איכות החיפוש יורדת, ומחיקה/ייצוא נעשים קשים. מומלץ: 'org:acme/app:chat/env:prod' או 'project:myapp/env:staging'. לעולם אל תשתמש רק ב-'default' בייצור.

user: העדפות שחלות גלובלית על משתמש. session: מטרות או הקשר תקפים רק לשיחה זו. agent: כללים ספציפיים לסוכן במערכת רב-סוכנית. שימוש נכון ב-scope מצמצם אורך פרומפט ומשפר עקביות תגובות.

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) namespaces מעורבים, 2) יותר מדי זיכרונות מאוחסנים (רעש), 3) threshold נמוך מדי, 4) תוכן מופשט מדי ('אוהב דברים' לעומת עובדות ספציפיות). פתרון: להפריד namespaces, להפוך תוכן לספציפי, להעלות threshold.

להוסיף ניקוד חשיבות ולשמור רק זיכרונות חשובים. להשתמש ב-TTL לפקיעה אוטומטית של זיכרונות ישנים. מדי פעם למזג זיכרונות דומים לסיכומים. להפריד namespaces לצמצום טווח החיפוש.

זרימה מומלצת: 1) לקרוא עם auto_store=false לתצוגה מקדימה של זיכרונות מחולצים. 2) להציג תוצאות למשתמש לאישור. 3) לאחסן רק זיכרונות מאושרים. 4) ברגע שאיכות החילוץ מוכחת, לעבור ל-auto_store=true לאוטומציה.

haiku: מהיר יותר, זול יותר, טוב לרוב המקרים. sonnet: מדויק יותר, טוב יותר לחילוצים חשובים (onboarding, חוזים, מדיניות). השתמש ב-haiku לחילוץ המוני/ראשוני, sonnet לתרחישים בסיכון גבוה.

כן, אבל התבנית המומלצת היא: ליצור זיכרון חדש + למחוק/לארכב את הישן. גישה זו טובה יותר למסלולי ביקורת ומונעת בעיות רגרסיה.

שתי גישות: 1) למחוק לפי ID (מדויק), 2) למחוק לפי namespace (ניקוי המוני). לארגונים/תאימות, להבטיח 'מחיקה מלאה + יומן ביקורת'. לתעד בבירור את מדיניות המחיקה שלך.

הגעת למגבלת הקצב. פתרונות: 1) ליישם backoff אקספוננציאלי (1s -> 2s -> 4s). 2) לתור בקשות בצד השרת. 3) להפחית תדירות בקשות: לשמור בקשות כפולות במטמון, פעולות אצווה, להפחית תדירות חילוץ.

גורמי עלות עיקריים: 1) תדירות חילוץ - להפחית קריאות. 2) טווח חיפוש - להשתמש ב-namespace לצמצום. 3) בחירת מודל - להשתמש ב-haiku לשגרתי, sonnet לחשוב. 4) מטמון - לשמור שאילתות חוזרות במטמון. 5) פעולות אצווה כשאפשר.

לא מומלץ - סיכון גבוה לחשיפת מפתח. קרא ל-Seizn מהשרת שלך (Next.js Route Handler, Cloudflare Worker, פונקציית serverless) ותן לדפדפן לקרוא לשרת שלך. לעולם אל תחשוף מפתחות API בקוד צד לקוח.

הם ירצו: 1) היקף נתונים (מה מאוחסן/לא מאוחסן), 2) הצפנה (במנוחה: AES-256, בתעבורה: TLS), 3) שיטת בידוד דיירים, 4) מדיניות מחיקה/שמירה, 5) גישה ליומני ביקורת, 6) מדיניות רוטציה/פקיעה של מפתחות. לשמור דף אבטחה וממשל בתיעוד.