SILK — אינדקס סמלי לידע של מודלי שפה גדולים

Symbolic Index for LLM Knowledge — ארכיטקטורת חיפוש נוירו-סמלית.

מחפש באמצעות מספרים שלמים של 64 סיביות. אין צורך במסד נתונים וקטורי, גרף ANN או מודל הטמעה.

מאגר GitHub

הטענה המרכזית

חיפוש מעולם לא היה בעיה קשה — הוא היה סימפטום של נתונים חסרי מבנה. כשמעניקים מבנה של 64 סיביות ברגע הרישום, הסימפטום נעלם.

results = index[(index & mask) == pattern]

חיפוש ב-100 מיליון ישויות של Wikidata בזיכרון של 1.3GB בפחות משנייה. Python (NumPy) לבדה מנצחת מסדי נתונים וקטוריים מותאמים ב-C++/Rust — ניצחון של ארכיטקטורה.

למה לא הטמעת וקטורים?

הטמעת וקטורים מוחקת את המבנה.

"יהודה המכבי היה מנהיג צבאי יהודי בתקופה ההלניסטית"
 → אדם מבין מיד: יהודי, מפקד צבאי, המאה ה-2 לפנה"ס

מודל הטמעה:
 [0.234, -0.891, 0.445, ..., 0.112] (384 ממדים float)
 → המבנה נמחק. אי אפשר לקרוא אם זה person או location.

כדי לשחזר את המבנה שנמחק:
 גרף ANN (כמו HNSW, IVF-PQ), cross-encoder, reranker, מסנן מטא-דאטה...

SILK שומר על המבנה.

SIDX: [Human / military / west_asia / ancient]
 → המבנה חי בסיביות. אפשר לקרוא.
 → אין צורך לשחזר. כי הוא לא נמחק.

המפתח הוא היפוך הסדר.

מסורתי: קודם כותבים → אחר כך מבנים (אינדוקס)
SILK: מבנים בזמן הכתיבה → החיפוש בחינם

פריסת סיביות SIDX

SIDX עוקב אחר מפרט Entity Node בדקדוק GEUL.

[prefix 7 | mode 3 | entity_type 6 | attrs 48]
 MSB(63)                                  LSB(0)

טווח חיפוש: entity_type 6 סיביות + attrs 48 סיביות = 54 סיביות. QID לא נכלל ב-SIDX ונשמר במערך נפרד.

attrs 48 סיביות — סכמה לפי טיפוס

Human(0):       subclass 5 | occupation 6 | country 8 | era 4 | decade 4 | gender 2 | notability 3 | ...
Star(12):       constellation 7 | spectral_type 4 | luminosity 3 | magnitude 4 | ra_zone 4 | dec_zone 4 | ...
Settlement(28): country 8 | admin_level 4 | admin_code 8 | lat_zone 4 | lon_zone 4 | population 4 | ...
Organization(44): country 8 | org_type 4 | legal_form 6 | industry 8 | era 4 | size 4 | ...
Film(51):       country 8 | year 7 | genre 6 | language 8 | color 2 | duration 4 | ...

כרגע מוגדרת פריסת תכונות ל-5 טיפוסים. השאר מקודדים לפי entity_type בלבד.

ארכיטקטורה

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

צינור קידוד (בזמן כתיבה)
┌──────────────┐   ┌──────────────┐   ┌──────────────┐
│  תיוג LLM    │──►│  אימות VALID │──►│ קידוד קודבוק │
│  מסמך → JSON │   │ ערכים חוקיים │   │ JSON → SIDX  │
│  (סיווג דלאלי)│   │ בדיקת עקביות│   │ (הרכבת סיביות)│
│              │   │ הזיה → פסילה │   │              │
└──────────────┘   └──────────────┘   └──────────────┘
   LLM מתייג       הקוד מאמת       קידוד לפי קודבוק

צינור חיפוש (בזמן שאילתה)
┌──────────────┐   ┌──────────────┐   ┌──────────────┐
│  פירוש שאילתה│──►│ מסנן bit AND │──►│  הכרעת LLM   │
│  חיפוש קודבוק│   │  NumPy SIMD  │   │ מועמדים בלבד │
│  + סיוע LLM  │   │100M → עשרות │   │ עשרות → תשובה│
└──────────────┘   └──────────────┘   └──────────────┘
   חילוץ משמעות     סינון רחב        הכרעה מדויקת

האסטרטגיה המרכזית: סינון רחב עם bit AND על SIDX בלי להחמיץ דבר, ואז LLM מכריע רק על המועמדים המעטים.

כל צד עושה מה שהוא עושה הכי טוב:
 אדם: עיצוב מבנה (קודבוק)
 LLM:  סיווג סמנטי (תיוג) + הכרעה סמנטית (חיפוש)
 קוד: אימות כללים (VALID) + הרכבת סיביות
 CPU:  השוואה מסיבית (NumPy SIMD)

קידוד: תיוג LLM ← אימות VALID

LLM קורא את המסמך ומתייג ל-JSON. VALID מבצע בדיקה מכנית לפי הקודבוק. ערכים שאינם בקודבוק, הפרות עקביות בין טיפוסים ואילוצים שהופרו לא יכולים פיזית להיכנס לאינדקס.

תיוג LLM:  {"type": "Human", "occupation": "military", "country": "israel"}
VALID:    occupation="military" ∈ קודבוק? ✓  country="israel" ∈ קודבוק? ✓
          Human עם שדה constellation? ✗ נפסל
קידוד:   "military"→6 סיביות, "israel"→8 סיביות מהקודבוק → הרכבת סיביות → SIDX uint64

LLM יכול להזות. אבל VALID משמש כשומר סף ולכן הסיכוי לזהם את האינדקס הוא אפס. רק JSON שעובר VALID מקודד למספר שלם SIDX של 64 סיביות לפי הקודבוק.

חיפוש: סינון רחב, LLM מצמצם

1. חילוץ משמעות שאילתה   חיפוש קודבוק 80% / סיוע LLM 20%
2. הרכבת מסכת סיביות     דטרמיניסטי — אלגוריתם
3. bit AND עם NumPy      דטרמיניסטי — סריקה מלאה של 100M ב-20ms
4. הכרעה סופית של LLM    מועמדים מעטים בלבד — הכרעה סמנטית מדויקת

80% מהחיפושים הם שאילתות מבניות

"יהודה המכבי"     → Q484523 exact match. bit AND. סיום.
"חדשות סמסונג"    → org/company + doc_meta/news. bit AND. סיום.
"פסגת ביידן-שי"   → Q6279 ∩ Q15031 ∩ meeting. חיתוך. סיום.

שאילתות מבניות (80%): bit AND ב-SILK מספיק. אין צורך ב-LLM.
שאילתות סמנטיות (15%): SILK מצמצם מועמדים → LLM מכריע ב-5-10 מקרים.
שאילתות יצירתיות  (5%): SILK מזהה מסמך → LLM מייצר.

Multi-SIDX

מסמך/אירוע אחד נושא מספר SIDX.

כתבה חדשותית: "פגישת מנהיגי Samsung, NVIDIA והיונדאי":

SIDX[0]: [Human / business / east_asia ]  לי ג'ה-יונג
SIDX[1]: [Org   / company / east_asia ]  Samsung
SIDX[2]: [Human / business / n_america]  ג'נסן הואנג
SIDX[3]: [Org   / company / n_america]  NVIDIA
SIDX[4]: [Human / business / east_asia ]  צ'ונג אוי-סון
SIDX[5]: [Org   / company / east_asia ]  Hyundai
SIDX[6]: [Event / meeting / east_asia ]  הפגישה

הכול SIDX של 64 סיביות. אותו אינדקס. אותו bit AND לחיפוש. שדה entity_type מבחין בין ישויות (Human, Org) לאירועות (Event).

מבנה האינדקס

sidx_array = np.array([...], dtype=np.uint64)  # 108.8M × 8B = 870MB
qid_array  = np.array([...], dtype=np.uint32)  # 108.8M × 4B = 435MB
# סה"כ ~1.3GB זיכרון

בניית אינדקס:
 Elasticsearch: טוקניזציה → ניתוח → אינדקס הפוך → מיזוג סגמנטים
 Pinecone:      הטמעה → גרף HNSW → קלסטור
 SILK:          sort

אין מבני נתונים. מערך ממוין אחד.

השוואה למסדי נתונים וקטוריים

bit AND לא תלוי בסדר, חסר מצב, ניתן לצבירה.
מסד וקטורי: הגרף כולו חייב להיות בזיכרון. פיצול = הרס.
SILK:    חותכים בכל מקום וזה עובד. פיצול = רק איטיות. תוצאות זהות.

צינור ביקורת

הטמעת וקטורים היא קופסה שחורה שלא ניתנת לביקורת. SIDX הוא JSON שניתן לביקורת.

שלב 1 — תיוג LLM קטן      Llama 8B / GPT-4o-mini. דיוק 85-90%.
שלב 2 — בדיקת VALID מכנית  ערכים חוקיים, עקביות, אילוצים. עלות $0.
שלב 3 — ביקורת LLM גדול    רק confidence=low. דיוק 99%+.

VALID הוא שומר הסף: הזיות מחוץ לערכים החוקיים בקודבוק לא יכולות פיזית להיכנס לאינדקס.

רישיון

MIT — מאגר GitHub