המוצר
מחקר ונימוקים
לכל חלק ב-ai-memory יש סיבה שאפשר לבדוק: רעיון שממנו הוא הגיע, באג בכלי קודם שהוא נמנע ממנו, או מספר שמולו הוא נמדד. הדף הזה עובר עליהם בשישה פרקים קצרים.
בונים את הוויקי תוך כדי העבודה
באפריל 2026 פרסם Andrej Karpathy "קובץ רעיון" קצר על מה שהוא כינה LLM wiki. ai-memory הוא הרעיון הזה, מותאם לסוכני קוד שלא מפסיקים לייצר חומר.
"הידע מקומפל פעם אחת ואז נשמר מעודכן, במקום להיגזר מחדש בכל שאילתה."
שלוש שכבות
מקורות גולמיים שלא משתנים אף פעם, ויקי של דפי markdown שה-LLM מתחזק, וקובץ סכמה שמסביר לסוכן איך הוויקי עובד.
שלוש פעולות
הזנה של מקור, עם עדכון הדפים שהוא נוגע בהם. שאילתה מול הוויקי. lint שמחפש סתירות ודפים יתומים.
מקורות גולמיים
תצפיות מה-hooks
ויקי
Markdown ב-git
סכמה
בלוק ב-AGENTS.md
מה ai-memory שמר
- קובצי markdown ב-repository של git, בתור הדבר שאדם יכול לפתוח, לעשות לו diff ולקרוא.
- קומפילציה של הידע ברגע שהוא מגיע, כשסשן אחד מתפצל לכמה דפים.
- wikilinks בין דפים בתור הגרף.
- lint לסתירות, לדפים מיושנים, לדפים יתומים ולכותרות כפולות.
- בלוק סכמה שמותקן בתוך CLAUDE.md או AGENTS.md, כדי שהסוכן יידע איך להשתמש בוויקי.
מה הוא שינה
את הדפוס של Karpathy אוצר אדם, מקור אחד בכל פעם. סוכן קוד מייצר חומר ברצף, ואף אחד לא משגיח.
| ב-gist | ב-ai-memory |
|---|---|
| מוסרים ל-LLM מקור אחד בכל פעם | hooks של מחזור החיים לוכדים כל סשן בעצמם |
| הסוכן קורא קודם את index.md | אינדקס משולב אחד: טקסט מלא, ישויות, קישורים ווקטורים |
| LLM עושה את כל התחזוקה | סיכומים מבוססי כללים כברירת מחדל. LLM הוא opt-in |
| אדם אחד, ויקי אחד | העברות בין סוכנים, כמה משתמשים, scope לכל פרויקט |
| דפים חיים לנצח | שכבות זיכרון, דעיכה, החלפת עובדות ישנות ו-TTL משאירים דפים מיושנים בחוץ |
שכבות זיכרון, דעיכה והחלפת עובדות ישנות לא מופיעות ב-gist של Karpathy. הן מגיעות מ-agentmemory ומהכתיבה על "LLM Wiki v2" שסביבו. סיכומי הקריאה המלאים נמצאים ב-repository.
הזיכרון שלכם כבר בפורמט פתוח
Open Knowledge Format הוא מפרט ש-Google Cloud פרסמה ביוני 2026. הוא מתאר ידע כתיקייה פשוטה של קובצי markdown עם YAML frontmatter, מושג אחד לכל קובץ, ושדה חובה יחיד: type. אין SDK ואין runtime.
- מאז 2.0 הוויקי הוא bundle של OKF v0.2 באופן מובנה. הקבצים ש-ai-memory עובד עליהם הם קובצי ה-OKF עצמם, כך שאין שלב export שיכול לסטות מהאמת.
- פרויקט אחד הוא bundle אחד, עם
index.mdשנוצר אוטומטית בשורש שלו. - לכל דף יש YAML frontmatter עם
type, שנגזר מהתיקייה שבה הדף נמצא. - שדרוג מ-1.x כותב מחדש את ה-frontmatter במקום, אחרי גיבוי מאומת. אם הגיבוי נכשל, המיגרציה נעצרת.
ai-memory export-okf --project myproject -o myproject-bundle.tar.gz
אין פקודת import. פורסים bundle לתוך תיקיית הוויקי של פרויקט, וה-file watcher מאנדקס אותו. המיפוי ל-OKF מתועד שדה אחר שדה, והמפרט נמצא בrepository knowledge-catalog של Google Cloud.
| תיקייה | type ב-OKF |
|---|---|
sessions/ | Session Summary |
decisions/ | Decision |
gotchas/ | Gotcha |
procedures/ | Procedure |
concepts/ | Concept |
_rules/ | Rule |
notes/ | Note |
runbooks/ | Runbook |
_slots/ | Invariant או State |
פרויקט אחד
index.md
החלטה
מלכודת
נוהל
Obsidian
grep
כלי OKF אחר
"את המודל ואת ה-harness שוכרים. הזיכרון של הפרויקט שלך."
שמונה החלטות, והסיבה לכל אחת
רובן מובילות חזרה ל-issue מסוים בכלי זיכרון קודם.
בחרנו
Markdown ב-git בתור האמת
כי כלי Markdown רגילים יכולים לקרוא את הדפים. אפשר לבנות מחדש את אינדקס החיפוש שלהם, אך סשנים, העברות וחשבונות דורשים גם גיבוי של המסד.
בחרנו
קובץ SQLite אחד
כי טקסט מלא, וקטורים דחוסים וטבלאות קישורים יושבים בקובץ embedded יחיד. ה-issue trackers של פרויקטים אחרים הראו כמה באגי נכונות עולה סנכרון של שלושה stores.
בחרנו
אפס קריאות LLM כברירת מחדל
כי סיכומי הסשנים מבוססי כללים, כך שהתקנה חדשה לא עולה כלום. הלקח הגיע מפיצ'רים של LLM במקומות אחרים שהיו דלוקים כברירת מחדל והפתיעו משתמשים בחשבונות על טוקנים.
בחרנו
קובץ בינארי אחד
כי SQLite מגיע בפנים, libgit2 הוא vendored וה-embedder כתוב ב-Rust טהור. מנוע sidecar נפרד היה מקור הכאב הגדול ביותר של משתמשים בפרויקט שהפרויקט הזה מחליף.
בחרנו
בלי מסד נתונים גרפי
כי הגרף הוא טבלאות SQL: טבלת קישורים ושאילתות רקורסיביות. זה מכסה הרחבה של קפיצה אחת וקשתות מטופסות, בלי מנוע גרפים embedded שצריך להחזיק בחיים.
בחרנו
וקטורים הם אופציונליים
כי embeddings מקומיים דלוקים מאז 2.0 ועדיין אף פעם לא חובה. החיפוש הוא קוסינוס ב-brute force בתוך SQLite; הרחבת וקטורים מחכה עד שמספר הדפים או ההשהיה יצדיקו אותה.
בחרנו
העברות כפרוטוקול מטופס, שנתפס פעם אחת בלבד
כי כל סבב מחקר סימן את ההעברה בין סוכנים כנקודת התורפה של הכלים הקודמים. העברה היא רשומה מטופסת שמותאמת לפי תיקייה, ורק סשן אחד בדיוק יכול לקבל אותה.
בחרנו
דפים במקום שורות של עובדות
כי דף על החלטה אפשר לקרוא, לערוך ולהסביר בפרוזה. טבלה של עובדות שחולצו אי אפשר לפתוח ב-Obsidian או לסקור ב-diff.
על כתפי מי שקדמו
הפרויקט קרא את הקוד ואת ה-issue trackers של הכלים שהיו קודם, שמר את הרעיונות שהחזיקו מעמד והשאיר בחוץ את החלקים שנשברו שוב ושוב.
Karpathy wiki
agentmemory
basic-memory
cognee
Hermes Agent
A-MEM
Hindsight
ai-memory
- Karpathy LLM Wiki
- לקמפל, לא לאחזר. הוויקי שעל הדיסק הוא התוצר.
- agentmemory
- לכידה אוטומטית מ-hooks, שכבות זיכרון, החלפת עובדות ישנות, דעיכה כנוסחה ודירוג משולב. ai-memory הוא היורש שלו ב-Rust: הרעיונות נשארו, התשתית התחלפה.
- basic-memory
- קבצים כמקור האמת עם אינדקס נגזר, וקישורים קדימה לדפים שעדיין לא קיימים.
- cognee
- המבנה של צינור משימות, חותמות של מקור המידע על כל דף ופידבק שמכוונן את הדירוג.
- Hermes Agent
- התכנון של לולאת השיפור העצמי, שסוקרת ברקע סשנים שהסתיימו.
- A-MEM
- פתקים אטומיים בסגנון Zettelkasten שמתקשרים זה לזה אוטומטית.
- Hindsight
- תוויות מיסוך מטופסות, ספירת ראיות לכל דף ותדריך שפותח בכללים שכבר הוכרעו.
- Honcho
- תשובות עם ציטוטים, רמות reasoning, והתזמון של סבב החלום: טריגר של חוסר פעילות, ביטול כשיש פעילות, והחדשני ביותר קודם.
אף אחד מהפרויקטים האלה לא נותן חסות ל-ai-memory. כדי לראות איפה כל אחד מהם מקדים, ראו את ההשוואה.
מה נמדד
ריצת גרסה 3.3.3 בחנה 470 שאלות ניתנות למענה מתוך LongMemEval-S באמצעות לכידה וחיפוש בפועל. חיפוש טקסט מלא הגיע ל־0.951 ב־hit@5, והטמעות מקומיות ל־0.943. אלה ציוני אחזור, לא דיוק תשובות. ה־hit@10 המקומי חזר ל־0.977, ודוח המקור עוקב אחר התנודות בין ריצות במצב המקומי.
- טקסט מלא בלבד, לפני 2.00.617
- טקסט מלא עם סינון stopwords0.666
- בתוספת embeddings מקומיים0.815
- 3.3.3: טקסט מלא, עם ערוץ התצפיות0.951
- 3.3.3: embeddings נייטיב, עם ערוץ התצפיות0.943
מה היה כל צעד
- הסרת stopwords משאילתות טקסט מלא הוסיפה 4.9 נקודות ל-hit@5.
- מודל ה-embeddings שרץ בתוך התהליך הוסיף עוד, בלי מפתח API.
- ערוץ התצפיות, שפעיל כברירת מחדל מאז 3.0, נותן לתצפיות הגולמיות של סשן להצביע עבור הדף שלו. הוא העלה את הטקסט המלא מ-0.662 ל-0.951.
- אף שורה לא מערבת מפתח API או LLM.
| מדד | לפני 2.0 | טקסט מלא מסונן | embeddings מקומיים | 3.3.3, טקסט מלא | 3.3.3, embeddings נייטיב |
|---|---|---|---|---|---|
| hit@5 | 0.617 | 0.666 | 0.815 | 0.951 | 0.943 |
| hit@1 | 0.449 | 0.532 | 0.536 | 0.857 | 0.760 |
להריץ בעצמכם
מוסיפים --candidate-embeddings local לפקודה השנייה כדי להריץ טקסט מלא ו-embeddings מקומיים זה לצד זה. ההרצות שפורסמו הן מתאריך 3 בנובמבר 2026, על Ryzen 9 7950X3D.
cargo build --release -p ai-memory-cli
cargo run --release -p ai-memory-eval -- retrieval --fetch
גם קצב הכתיבה נמדד. המספרים נמצאים בדף הארכיטקטורה.
מה ערוץ התצפיות החזיר
דף סשן שומר רק קטע קצר מכל תור, ולכן הפרט ששאלה מבקשת נמצא לעיתים קרובות רק בתצפיות של הסשן. כשהערוץ פועל, כל סשן מתאים מצביע פעם אחת, דרך התצפית הטובה ביותר שלו, עבור הדף שלו. אותן 470 שאלות, אותו build, הערוץ כבוי ואז פועל.
| מדד | טקסט מלא, בלי LLM | embeddings מקומיים |
|---|---|---|
| hit@5 | 0.662 → 0.951 | 0.796 → 0.936 |
| hit@1 | 0.511 → 0.857 | 0.536 → 0.757 |
| hit@10 | 0.687 → 0.972 | 0.881 → 0.970 |
| recall@5 | 0.533 → 0.893 | 0.657 → 0.871 |
| זמן שאילתה, אחוזון 95 | 90 ms → 112 ms | 264 ms → 234 ms |
| טוקנים של הקשר, חמש התוצאות הראשונות | 256.3 → 266.1 | 225.7 → 264.1 |
- השוואת הזרמים הזו היא ניסוי הפירוק מ-12 באוקטובר. הריצה הנפרדת של גרסה 3.3.3 מדדה 0.943 עם embeddings נייטיב. היא אינה הרצה חוזרת של ניסוי הכיבוי וההפעלה הזה.
- כשהערוץ פועל, טקסט מלא לבדו מקבל ציון מעט גבוה מ-embeddings מקומיים. גם הווקטור של הדף, כמו שורת הטקסט המלא שלו, עדיין רואה רק גוף שמכיל כותרת בלבד.
- בתוך הרצה אחת ה-harness דטרמיניסטי. בין הרצות נפרדות, סוגי השאלות הקטנים זזים עד 0.03 לכל כיוון, ולכן ירידה באחד מהם בהרצה בודדת כמעט לא אומרת דבר.
- המספרים שכלים אחרים מפרסמים על ה-dataset הזה מגיעים מה-harness שלהם, ולרוב מאנדקסים סשנים גולמיים שלמים בלי שלב לכידה. הם לא ניתנים להשוואה ישירה, ואין כאן טענה על דירוג בין כלים.
מה הלאה, ואיפה הפרויקט מאחור
אלה המלצות מתועדות ב-repository. לאף אחת מהן אין תאריך.
מומלץ בהמשך
דיוק התשובות בקנה מידה מלא
ל-harness השני יש כבר הרצת אחזור מלאה, עם דיוק, זמן שאילתה וטוקנים של הקשר. במצב דיוק התשובות שלו יש בינתיים רק מדגם של 20 שאלות, והסעיפים שמתחת מחכים לו.
reranker מקומי
cross-encoder שרץ בתוך התהליך, בלי LLM. בסט של 102 שאלות מתורם, adapter מתועד למודל שיפוט מקומי כבר השיג תוצאה שווה לזו של ה-reranker המתארח, בשבריר מזמן ההשהיה.
ברירות מחדל שמגובות במספרים
דירוג לפי ביטחון, דחיסת דפים קרים, איחוד כפילויות ו־dream pass דורשים הגדרות מפורשות. שימור לפי קריאות כבר פועל כברירת מחדל. שינויים נוספים בברירות המחדל דורשים ראיות מדודות; לקישורים מטיפוסים מוגדרים עדיין אין משקל נוסף בדירוג.
התחלה קלה יותר למשתמשי Claude Code
כלי ייבוא למי שמגיע מהזיכרון המובנה של Claude.
לא מתוכנן: מסד נתונים גרפי, מערכת הפעלה לזיכרון שעורכת את עצמה, מחברים לענן, או הגדלת מספר הכלים רק לשם ההגדלה.
איפה הוא מאחור היום
עדיין אין reranker מקומי, ולהתיישנות הזיכרון אין תוצאה מדודה. הרשימה המלאה נמצאת בדף ההשוואה.
"1.x הוכיחה שהרעיון עובד. 2.0 היא הגרסה שהייתי ממליץ עליה בלי כוכבית למי שרוצה להכניס אותה לצוות."
שאלות ותשובות
מה רעיון ה-LLM Wiki של Karpathy שמאחורי ai-memory?
ה-gist של Andrej Karpathy מאפריל 2026 מתאר LLM שבונה ומתחזק ויקי קבוע של קובצי markdown, שעומד בינכם לבין המקורות הגולמיים, כך שהידע מקומפל פעם אחת ונשמר מעודכן. ai-memory מיישם את זה לסוכני קוד, עם לכידה אוטומטית מ-hooks של מחזור החיים ומסלול ברירת מחדל שלא מבצע קריאות LLM.
האם ai-memory תואם ל-Open Knowledge Format?
מאז 2.0 כל פרויקט בוויקי הוא bundle של OKF v0.2 באופן מובנה. לכל דף יש YAML frontmatter עם type, לכל פרויקט יש index.md שנוצר אוטומטית, והפקודה ai-memory export-okf אורזת פרויקט ל-tarball מאומת.
מה הבנצ'מרק LongMemEval-S מודד אצל ai-memory?
אחזור בלבד: האם סשן שמחזיק את הראיה מופיע בתוצאות הראשונות, על פני 470 שאלות. hit@5 הוא 0.951 עם טקסט מלא וערוץ התצפיות, ו-0.943 עם embeddings מקומיים. הוא לא מודד דיוק של תשובות.
קוראים את הנימוקים. אחר כך מנסים.
חינם ובקוד פתוח. התקנת ברירת המחדל לא מבצעת קריאות LLM ומאזינה רק על המחשב שלכם.