למה לשמור הסקה במטמון כקוד?

הטיעון לגיבוש הסקה לפרוצדורות

AI שחושב מאפס בכל פעם

דמיין שאתה מלמד עמית צעיר איך ליצור טבלת Pivot בגיליון אלקטרוני.

ביום הראשון, הוא שואל. אתה מקדיש שלושים דקות להסבר. ביום השני, אותו עמית שואל את אותה שאלה. שלושים דקות נוספות. יום שלישי, יום רביעי – אותו דבר.

כך בדיוק פועלים LLM-ים של ימינו.

בקש מ-GPT “לנתח CSV ב-Python,” והמודל מגייס מיליארדי פרמטרים כדי להסיק מאפס. שאל את אותה שאלה מחר, או מחרתיים, והוא משלם את אותה עלות בכל פעם. ההסקה של אתמול מתאדה. היא לא נרשמת, לא נעשה בה שימוש חוזר, לא מצטברת.

זהו שרת אינטרנט שרץ ללא מטמון. תלמיד שפותר את אותה בעיית בחינה שוב ושוב בלי לרשום הערות. ואינטליגנציה שלא צוברת ניסיון לעולם לא יכולה לצמוח.

ה-LLM הוא מהדר, לא מנוע ריצה

SEGLAM מציע תשובה שונה מהיסוד לבעיה הזו.

ה-LLM אינו מנוע ריצה שמבצע כל בקשה – הוא מהדר שמגבש הסקה לקוד.

כך זה עובד:

1. כשבקשה מגיעה, בדוק במטמון ההסקה קודם.
2. Cache Hit: תהליך הסקה זהה או דומה כבר גובש לקוד. ה-LLM לא מופעל. הקוד המתאים מתבצע מיידית. מהיר, זול ודטרמיניסטי.
3. Cache Miss: זהו סוג הסקה שלא נראה קודם. עכשיו ה-LLM מופעל. אבל ה-LLM לא מייצר “תשובה” – הוא מייצר “קוד שמפיק את התשובה.” קוד זה מתווסף למטמון.

כשבקשה דומה מגיעה בפעם הבאה? Cache hit. ה-LLM יכול להמשיך לישון.

האנלוגיה להידור JIT

ארכיטקטורה זו היא גילוי מחדש של תבנית שכבר הוכחה במדעי המחשב.

חשוב על מהדר JIT (Just-In-Time). מנועי Java ו-JavaScript בתחילה מריצים קוד שורה אחרי שורה דרך מפרש. איטי, אבל פונקציונלי. כשאותו נתיב קוד מתבצע שוב ושוב – “זהו נתיב חם” – המנוע מהדר את הנתיב הזה לקוד מכונה ילידי. מאותו רגע, הוא רץ ישירות בלי לעבור דרך המפרש.

ב-SEGLAM:

• מפרש = LLM. איטי, יקר והסתברותי, אבל מסוגל לטפל בכל בקשה.
• קוד ילידי = קוד הסקה שנשמר במטמון. מהיר, זול ודטרמיניסטי.
• הידור JIT = התהליך שבו ה-LLM מייצר קוד ב-cache miss. יקר, אבל צריך לקרות רק פעם אחת.

כשם שמהדר JIT ממטב “נתיבים חמים,” SEGLAM מגבש “הסקה חמה” לקוד.

למה לשמור “קוד” במטמון במקום “תשובות”?

זהו עיקר העניין. מטמון תשובות פשוט ומטמון ההסקה של SEGLAM שונים מהיסוד.

מטמון תשובות שומר “שאלה: מהי בירת קוריאה? -> תשובה: סיאול.” זה פוגע רק כשהשאלה זהה בדיוק. שאל “מהי בירת הרפובליקה של קוריאה?” וזה מפספס. זהו מילון, לא אינטליגנציה.

מטמון ההסקה של SEGLAM שומר קוד שאומר “לסוג שאלה כזה, בנה תשובה דרך הפרוצדורה הזו.” הוא מגבש לא את הערך הספציפי, אלא את נתיב ההסקה עצמו. לכן, גם כשהקלט משתנה, אותו סוג שאלה עדיין פוגע. זו הבנה. זו צמיחה.

אנלוגיה: מטמון תשובות שונן את לוח הכפל; מטמון הסקה לומד איך להכפיל.

מה קורה לאורך זמן

המאפיין החזק ביותר של העיצוב הזה הוא שהזמן עובד לטובתו.

• יום 1: המטמון ריק. כמעט כל בקשה היא cache miss. ה-LLM עובד קשה. איטי ויקר.
• יום 30: חלק ניכר מדפוסי ההסקה השגרתיים נמצאים במטמון. הפעלות LLM פוחתות.
• יום 365: רוב הבקשות הן cache hit. ה-LLM מופעל רק לסוגי בעיות חדשניים באמת. המערכת מהירה, זולה וצפויה.
• מעבר לכך: המטמון עצמו הופך ל"אינטליגנציה מגובשת" לתחומו. נכסים אינטלקטואליים ניידים, ניתנים לאימות ולצבירה.

התלות ב-LLM יורדת עם הזמן. יעילות המערכת עולה עם הזמן. העקומה הזו לעולם לא מתהפכת.

עקרון שימור ההסקה

העיקרון הבסיסי ביותר של הגישה הזו הוא:

“תהליך ההסקה של AI לא צריך להיזרק – הוא חייב להירשם.”

מטמון ההסקה הוא המימוש הישיר ביותר של פילוסופיה זו.

הסקה שה-LLM מבצע פעם אחת מגובשת לייצוג מובנה ונשמרת. היא לא נזרקת. נעשה בה שימוש חוזר. היא מאומתת. משתפרת. מצטברת.

וכיוון שקוד זה שנשמר במטמון מתואר בשפה מובנית וברורה:

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

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

סיכום

להפעיל LLM לכל בקשה זה כמו לקחת מטוס לשכן. ברגע שסוללים כביש, אפשר ללכת ברגל מאז ואילך.

SEGLAM היא המערכת שסוללת כבישים.