Inference כזרימה, לא כבקשה - למה מודלי שפה לא “עובדים” אלא מתנהלים

פתיחה - למה לחשוב על Inference כבקשה זו טעות

כשאנחנו משתמשים במודל שפה, החוויה שלנו פשוטה מאוד:

אנחנו שואלים שאלה - ומקבלים תשובה.

מבחינת המשתמש, זה נראה כמו פעולה אחת: קלט → פלט.

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

המודל לא “יודע” את התשובה כשהוא מתחיל. הוא לא מחזיק תשובה מוכנה. הוא בונה אותה - חלק אחרי חלק.

כל מילה שהוא מייצר נשענת על כל מה שנאמר לפניה. וכל מילה כזו דורשת חישוב, זמן, וזיכרון.

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

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

Inference מפסיק להיות “הרצה של מודל”, והופך למערכת שמתמודדת עם:

• זמן משותף
• זיכרון משותף
• ותשומת לב מוגבלת

וזו בדיוק הנקודה שבה צריך לשנות את צורת החשיבה.

חלק 1 - Streaming Inference: למה תשובה היא תהליך מתמשך

נתחיל מהדבר הכי בסיסי: איך מודל שפה בכלל מייצר תשובה.

הוא לא כותב פסקה שלמה. הוא לא “חושב” ואז מדפיס.

הוא עושה פעולה אחת שוב ושוב:

1. מסתכל על מה שכבר נאמר
2. מחשב מה הטוקן הבא
3. מוסיף אותו לרצף
4. ואז חוזר לשלב 1

כלומר: התשובה נוצרת בזמן אמת.

אם כך, עולה שאלה פשוטה: למה לחכות עד הסוף?

אם התשובה נבנית בהדרגה - אפשר גם לצרוך אותה בהדרגה.

זו המשמעות של Streaming Inference: לא לראות תשובה כמשהו שמופיע בסוף, אלא כזרם שנפתח מיד.

ברגע שמבינים את זה, מבינים גם שהמערכת לא צריכה “לסיים” כדי להיות מועילה.

היא צריכה רק להתחיל לזוז.

חלק 2 - Partial Results: למה תשובה חלקית היא לא פשרה

יש נטייה טבעית לחשוב: “או שיש תשובה - או שאין”.

אבל בעולם של Inference, זו דיכוטומיה שגויה.

נניח שיש שתי בקשות:

• אחת פשוטה
• אחת מורכבת מאוד

אם המערכת מתנהגת כך שכל בקשה חייבת להגיע ל-100% כדי להיחשב “מוכנה” - הקצרה תסבול בגלל הארוכה.

אבל אם המערכת מוכנה להוציא תוצאה חלקית:

• הקצרה תתקדם מהר
• והארוכה תמשיך ברקע

תשובה חלקית אינה חצי תשובה. היא תשובה בזמן מוקדם יותר.

וברוב המערכות האמיתיות - זמן חשוב לא פחות מתוכן.

הבחירה להציג תוצאה חלקית היא בחירה מערכתית: להעדיף זרימה על שלמות.

חלק 3 - Incremental Decoding: למה להתקדם לאט זה יתרון

עכשיו נעמיק רגע בשאלה כיצד המערכת עובדת פנימית.

אפשר לדמיין שני סגנונות עבודה:

1. לצבור הרבה עבודה - ואז לבצע הכול
2. לבצע מעט עבודה - ולעשות את הפעולה הזו שוב ושוב

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

Incremental decoding מבוסס על הגישה השנייה.

המערכת לא מחכה לרגע “גדול”. היא לא אומרת: “כשיהיה מספיק - נתחיל”.

היא מתחילה מיד, וממשיכה להתקדם בצעדים קטנים.

התוצאה היא מערכת:

• שקל לעצור
• שקל לשלב
• שקל להאט או להאיץ

כלומר: מערכת שניתן לנהל.

חלק 4 - Time-sliced Execution: למה לא נותנים לבקשה לרוץ לבד

כשהרבה בקשות חיות יחד, הסכנה הגדולה ביותר היא זו:

בקשה אחת תופסת את המערכת ולא משחררת.

Time-slicing פותר בדיוק את זה.

במקום לתת לבקשה אחת לרוץ עד הסוף, המערכת מחלקת את הזמן לחתיכות קטנות.

כל בקשה מקבלת:

• קצת זמן
• ואז מפנה מקום לאחרות

אף אחת לא “מסיימת” מיד, אבל כולן מתקדמות.

זה אולי נשמע פחות יעיל - אבל בפועל, זו הדרך היחידה לשמור על מערכת תגובתית.

סיכום - Inference אינו פעולה. הוא התנהלות.

אם נחבר את כל החלקים יחד, מתגלה תמונה ברורה:

Inference טוב לא נמדד לפי כמה מהר הוא נגמר, אלא לפי כמה טוב הוא מתנהל לאורך זמן.

מערכת שחושבת במונחים של בקשות מנסה לסגור דברים.

מערכת שחושבת במונחים של זרימה מנסה להישאר יציבה, קשובה, וחיה.

שורת סיום:

Inference לא נועד “להסתיים”. הוא נועד להמשיך לנוע - בלי ליפול.