סוכן AI ללא זיכרון תקוע בלהציג את עצמו מחדש בכל שיחה. התיקון הוא מסד נתונים וקטורי — הוא מאחסן embeddings של המסמכים, ההערות או השיחות הקודמות שלכם כך שהסוכן יכול לזכור את החלקים הרלוונטיים לפי דרישה (זה ה-"R" ב-RAG). אתם יכולים לשכור את זה כשירות מנוהל, או שאתם יכולים להריץ אותו בעצמכם על VPS ולשמור את הנתונים שלכם — שלעתים קרובות הם הנתונים הפרטיים שלכם — על ארגז שאתם שולטים בו. הנה איך, ומה זה באמת עולה ב-RAM.
שתי אופציות טובות
אתם לא צריכים שום דבר אקזוטי. שני נתיבים מכסים כמעט את כולם:
pgvector — הרחבה של Postgres. אם אתם כבר מריצים Postgres (או שמחים לכך), זה מוסיף חיפוש וקטורי למסד הנתונים שכבר יש לכם. שירות אחד, גיבוי אחד, SQL שאתם מכירים. ההתחלה עם הכי פחות מאמץ בפער רחב.
Qdrant — מנוע וקטורי בנוי-למטרה. הושיטו אליו יד כשיש לכם הרבה וקטורים (מיליונים בודדים+) או רוצים סינון metadata מהיר ו-API ייעודי. זה שירות נפרד להריץ, אבל הוא בנוי בדיוק לעבודה הזו.
לרוב הסוכנים שמוצאים את הרגליים, pgvector היא התשובה הראשונה הנכונה. עברו ל-Qdrant כשגדלתם מעבר לה, לא לפני.
מציאות ה-RAM (זה החלק שאנשים מזלזלים בו)
חיפוש וקטורי מהיר כי האינדקס חי בזיכרון — אז RAM, לא דיסק, הוא האילוץ האמיתי שלכם. מדריך גס:
- כמה מאות אלפי embeddings — נוח ב-2 GB.
- מיליונים בודדים — תכננו ל-4 GB+ וכווננו את האינדקס.
- דיסק הוא החלק הקל: מיליון embeddings הם רק כמה GB, אז 25–45 GB מכסים store רציני.
אז מדדו לאינדקס, לא לקובץ. (אותה לוגיקה כמו מדריך המדידה הכללי — הדבר הכבד אינו מובן מאליו עד שאתם מודדים.)
התחלה מהירה: pgvector
על ארגז עם Postgres (Docker הכי קל — אותו דפוס כמו אחסון-עצמי של n8n):
CREATE EXTENSION IF NOT EXISTS vector;
CREATE TABLE memory (
id bigserial PRIMARY KEY,
content text,
embedding vector(1536) -- match your embedding model's dimensions
);
-- after you have data, build an index for fast search:
CREATE INDEX ON memory USING hnsw (embedding vector_cosine_ops);
הסוכן שלכם מכניס content + ה-embedding שלו, ואז שואל עם ORDER BY embedding <=> $query_embedding LIMIT 5 כדי למשוך את הזיכרונות הקרובים ביותר. זו כל הלולאה.
מעדיפים Qdrant? זה קונטיינר Docker בודד שחושף API של HTTP/gRPC; אתם יוצרים collection עם גודל הווקטור שלכם ועושים upsert ל-points. אותו רעיון, מנוע ייעודי.
האם הוא יכול לחלוק ארגז עם הסוכן?
כן — ל-stores זיכרון קטנים-עד-בינוניים, הריצו את ה-vector DB על אותו VPS של הסוכן. זה פשוט יותר וההשהיה בעצם אפס. פצלו אותם לשרתים נפרדים רק כשאחד מתחיל לדחוק את השני מחוץ ל-RAM. זו החלטה מאוחרת, בעיה-נחמדה-שיש-לך, לא כזו של היום הראשון.
הסתייגויות כנות
- RAM הוא הקיר, והוא שקט. החיפוש נשאר מהיר עד שהאינדקס כבר לא נכנס לזיכרון, ואז הוא מתדרדר. צפו בזיכרון ושנו גודל לפני שזה נושך — אל תחכו לשאילתות איטיות שיגידו לכם.
- embeddings עולים טוקנים ליצירה. כל מסמך שאתם עושים לו embedding הוא קריאת API למודל embedding. ה-store זול לאחסן; יצירת הווקטורים היא העלות החוזרת — רלוונטי למה שהרצת סוכן באמת עולה.
- גבו אותו. הזיכרון של הסוכן שלכם הוא נתונים כמו כל דבר אחר. אם זה חשוב, צלמו אותו.
בתוך זה, vector store באחסון-עצמי הוא דרך נקייה לתת לסוכן זיכרון עמיד בלי למסור את הנתונים הפרטיים שלכם לצד שלישי. התחילו עם pgvector על ארגז של 2 GB, שמרו עין על RAM, וגדלו ל-Qdrant או לתוכנית גדולה יותר רק כשהמספרים אומרים לכם.
תגובות
אין עדיין תגובות. היו הראשונים.