0.2 איך מודל שפה חושב הרצאה

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

חיזוי הטוקן הבא - next-token prediction¶

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

Input: "def add(a, b):\n    return a"
The model computes a probability for the next token:
  " + b"     -> 0.71
  " b"       -> 0.14
  ";"        -> 0.05
  ... (thousands more low-probability options)
The model picks the most likely one, appends it to the text, and repeats the process

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

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

מודלים שונים בגדלים שונים¶

לא כל המודלים זהים. בתוך משפחת Claude, למשל, יש כמה דרגות: מודל כמו Sonnet 5 מאוזן בין מהירות ליכולת ומתאים לרוב משימות הפיתוח היומיומיות, מודל כמו Opus 4.8 חזק יותר במשימות שדורשות היגיון עמוק ומורכב אך איטי ויקר יותר, ומודל כמו Haiku 4.5 מהיר וזול במיוחד ומתאים למשימות פשוטות וחוזרות. ההבדל בין הדרגות הוא בעיקר בגודל הרשת ובעומק ההיגיון שהיא יכולה לבצע - לא בעקרון הבסיסי של חיזוי הטוקן הבא, שזהה לכל המודלים. נחזור לנושא בחירת המודל הנכון למשימה בהרצאה 1.4.

הcontext window - the context window¶

המודל לא "זוכר" שיחות קודמות בין הפעלה להפעלה. כל מה שהוא "יודע" ברגע נתון הוא הcontext window - כל הטקסט שנמצא כרגע בשיחה: הprompts, ההודעות שלכם, תשובות קודמות, קטעי קוד שהוצגו, תוצאות פקודות שהורצו. הcontext window נמדד בטוקנים, ויש לו גודל מקסימלי - כמה מאות אלפי טוקנים אצל המודלים המובילים כיום, אבל תמיד סופי.

שתי השלכות מעשיות:

מה שלא bcontext window - לא קיים עבור המודל. אם שאלתם על קובץ שהוא לא קרא, הוא לא "יודע" מה יש בו - אלא אם הוא tool agent שיכול לקרוא אותו בעצמו (על כך בפרק 2). בצ'אט רגיל, אם לא הדבקתם את הקוד, המודל פשוט מנחש.
ככל שהחלון מתמלא, איכות התשובות עלולה לרדת. שיחה ארוכה מדי, עם הרבה מידע לא רלוונטי, "מדללת" את תשומת הלב של המודל למידע החשוב. זו הסיבה שbagents CLI יש tools לניהול context - התחלת שיחה חדשה, סיכום, ניקוי - ונקדיש להם הרצאה שלמה בפרק 4.

חשבו על הcontext window כמו שולחן עבודה: אפשר לפרוש עליו רק כמות מוגבלת של ניירות בבת אחת. אם השולחן מלא בניירות ישנים ולא רלוונטיים, קשה יותר למצוא את הניר החשוב. ניהול context טוב הוא חלק מרכזי בעבודה יעילה עם agent, לא פרט טכני שולי.

דוגמה מוחשית לבעיה: אם תשאלו בשיחת צ'אט "מה הבאג בקובץ שהדבקתי לפני חצי שעה", אבל בינתיים הדבקתם שני קבצים נוספים וניהלתם דיון ארוך על ארכיטקטורה - המודל עדיין "רואה" את כל זה bcontext window, אבל הוא צריך לשייך נכון איזה קטע קוד רלוונטי לאיזו שאלה. ככל שהשיחה מתארכת ומתפזרת על נושאים שונים, הסיכוי לבלבול או לתשובה שמתייחסת לחלק הלא נכון עולה. הפתרון הפרקטי הוא לרוב לא "שיחה אחת ארוכה שמכילה הכל", אלא שיחות ממוקדות יותר סביב משימה אחת בכל פעם.

למה מודל "מזה" - hallucination¶

הhallucination היא כשהמודל מייצר טקסט שנשמע בטוח ומדויק - אבל שגוי או מומצא לחלוטין. לדוגמה: שם פונקציה שלא קיימת בספרייה, ציטוט של מאמר שלא נכתב מעולם, תיאור API עם פרמטרים שלא קיימים.

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

A typical hallucination example:
Question: "What's the name of the pandas function that merges two DataFrames
          by index and automatically ignores duplicates?"
Possible answer: "You can use pandas.merge_unique()..."

The problem: pandas.merge_unique() doesn't exist. The model "made up" a
plausible name, because it sounds like something that could fit the
pattern of other pandas function names.

ההשלכה המעשית: כל פרט טכני ספציפי - שם פונקציה, מספר גרסה, טענה עובדתית - צריך אימות מול מקור אמיתי (תיעוד רשמי, הרצה בפועל, בדיקה). זו לא פרנויה, זו עבודה מקצועית רגילה. בפרק 3 נראה איך אימות (verification) הופך לחלק קבוע בזרימת העבודה עם agent.

דגלים אדומים שכדאי לזהות¶

אי אפשר לחוש hallucination "בטעימה", אבל יש כמה סימנים שכדאי שיפעילו אצלכם בדיקה נוספת:

דגל אדום	דוגמה
שם API מוכר-מדי ומדויק-מדי בלי קישור או ציטוט	"יש פונקציה בשם `list.deduplicate_sorted()`"
טענה על גרסה או תאריך שחרור ספציפיים	"התכונה הזו נוספה בגרסה 3.11.4"
תשובה בטוחה לשאלה נישתית מאוד	פרט מימוש פנימי של ספרייה קטנה ולא מוכרת
התאמה "נוחה מדי" בין הבעיה שלכם לפתרון	פתרון שמסתדר בול עם הניסוח שלכם, בלי אזכור מגבלות

כשנתקלים באחד הדגלים האלה, הצעד הבא הוא פשוט: לבדוק. להריץ את הקוד, לחפש בתיעוד הרשמי, או - כשעובדים עם agent - לבקש ממנו במפורש "תוודא שהפונקציה הזו קיימת בפועל בספרייה, ותראה לי איפה".

אקראיות ואי-דטרמיניזם - temperature and nondeterminism¶

שאלתם את אותה שאלה פעמיים וקיבלתם שתי תשובות שונות? זה לא באג. בבחירת הטוקן הבא, המודל לא תמיד בוחר את האפשרות הכי סבירה בוודאות - יש מרכיב אקראי מבוקר, שנקרא לעיתים "טמפרטורה" (temperature). טמפרטורה גבוהה יותר מאפשרת יותר גיוון ויצירתיות בתשובה, טמפרטורה נמוכה יותר מייצרת תשובות עקביות וצפויות יותר.

מה זה אומר עבורכם בפועל:

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

תאריך חיתוך האימון - training cutoff¶

לכל מודל יש תאריך אימון - נקודת זמן שאחריה הוא פשוט לא "ראה" מידע חדש. אירועים, ספריות שיצאו, גרסאות API שהשתנו אחרי תאריך החיתוך - המודל לא מכיר אותם, אלא אם הוא מקבל אותם דרך הcontext window (למשל, agent שקורא תיעוד עדכני מהאינטרנט או מהפרויקט עצמו).

זו הסיבה שagent כמו Claude Code שימושי כל כך בפועל: הוא לא נשען רק על מה שהמודל "זוכר" מהאימון - הוא קורא את הקוד שלכם בזמן אמת, מריץ פקודות, ובמקרים רבים גם יכול לגשת לתיעוד עדכני. ההבדל בין "לשאול את המודל מהזיכרון" לבין "לתת לagent לבדוק בפועל" הוא לפעמים ההבדל בין תשובה מיושנת לתשובה נכונה.

דוגמה קלאסית: שאלה כמו "מה הפרמטרים החדשים ב-API שיצא החודש" תמיד תיתקל בבעיית תאריך החיתוך - אם ה-API יצא אחרי האימון, המודל פשוט לא מכיר אותו, ועלול לענות מתוך הכללה של APIs דומים שהוא כן מכיר - מה שנשמע סביר לגמרי אך שגוי. לעומת זאת, אם תבקשו מהagent "תבדוק בתיעוד הרשמי של הספרייה בפרויקט הנוכחי" או "תריץ pip show ותגיד לי איזו גרסה מותקנת", הוא בודק עובדה בזמן אמת במקום לשחזר אותה מהזיכרון.

במה המודל טוב ובמה הוא רע¶

הטבלה הזו היא אולי הtool המעשי החשוב ביותר בהרצאה - היא קובעת מתי כדאי לסמוך על המודל ומתי כדאי לבדוק ידנית פי כמה:

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

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

איך זה מתורגם לעבודה יומיומית עם agent¶

כל מה שנאמר עד כה נכון גם - ואולי במיוחד - כשמדובר בagent שמריץ קוד בפועל, לא רק "מדבר" איתכם:

הagent קורא context בעצמו (קבצים, תוצאות פקודות), מה שממתן חלק מבעיית "מה שלא bcontext window לא קיים" - אבל לא פותר אותה לגמרי. הוא עדיין יכול לפספס קובץ רלוונטי שלא חשב לקרוא.
הhallucination עדיין קיימת - agent יכול "להמציא" קריאה ל-API שלא קיים, ואז לתקן את עצמו כשהוא רואה שגיאת קומפילציה. זה בדיוק למה הרצה בפועל ובדיקות הן חלק חיוני מהתהליך, לא תוספת אופציונלית.
אי-דטרמיניזם אומר שאותה משימה יכולה להיפתר בדרך שונה בכל פעם - זו לא בעיה כשהתוצאה נבדקת, אבל מסוכנת אם סומכים על "זה עבד פעם שעברה" בלי לבדוק שוב.

בהרצאות הבאות (החל מפרק 2) נראה איך התכונות האלה - טוקנים, context, hallucination, אי-דטרמיניזם - מתורגמות לtools קונקרטיים: קובץ prompts פרויקט שנותן context קבוע, מצב תכנון שבודק לפני ביצוע, ותהליכי אימות שתופסים טעויות לפני שהן מגיעות לrepo. אבל כל הtools האלה בנויים על ההבנה הבסיסית שראינו כאן.

סיכום¶

מודל שפה עובד על ידי חיזוי חוזר של הטוקן (יחידת טקסט) הבא הכי סביר - אין "הבנה" במובן האנושי, אלא דפוס סטטיסטי חזק שמופעל טוקן אחרי טוקן.
הcontext window הוא כל מה שהמודל "רואה" כרגע - כל מה שמחוצה לו פשוט לא קיים עבורו, ושיחות ארוכות מדי עלולות לפגוע באיכות התשובה.
הhallucination קורית כשהדפוס הסטטיסטי ממשיך לייצר טקסט בטוח גם כשאין מידע אמיתי מאחוריו - לכן צריך לאמת פרטים ספציפיים כמו שמות פונקציות ומספרי גרסה.
אי-דטרמיניזם (טמפרטורה) גורם לכך שאותו פרומפט יכול לתת תשובות שונות - ניסוח מדויק ואימות תוצאה חשובים יותר מ"ניסיון נוסף".
לכל מודל יש תאריך חיתוך אימון - מידע אחריו לא מוכר לו, אלא אם הוא מגיע דרך הcontext window (למשל, קריאת קבצים בזמן אמת על ידי agent).
המודל חזק בטרנספורמציה, הסבר, boilerplate וכיסוי רוחב - וחלש בזיכרון מדויק, חשבון, עובדות טריות והודאה בחוסר ודאות. הכלל המעשי: סמכו על הטור הראשון, אמתו את הטור השני.