מה קורה בתוך מודל שפה? טוקנים, ייצוגים ו־Attention

אם וקטור, מכפלה פנימית או Softmax לא מוכרים, קראו קודם את המתמטיקה הקטנה

מפת הדרך: מה נחשב בפרק הזה#

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

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

האם "המודל פשוט מנחש את המילה הבאה" הוא הסבר מספיק?#

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

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

למה המודל לא מקבל "מילים" ישירות?#

לפני עיבוד המידע, המערכת עוברת דרך Tokenizer שממיר טקסט ליחידות — Tokens. שני שלבים שונים: (א) חלוקה ליחידות; (ב) מיפוי כל יחידה למזהה מספרי (ID) לפי מילון המודל. השלב השני אינו אופציונלי: המזהה הוא הבסיס לשכבת ה־Embedding, שבה כל מזהה מתורגם לווקטור (ראו בהמשך). טוקן אינו בהכרח מילה שלמה: הוא יכול להיות מילה, חלק ממילה, סימן פיסוק, רווח כחלק מרצף או יחידה אחרת, בהתאם לשיטת הקידוד ולמילון של המודל.

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

טקסט גולמי
   ↓  Tokenizer
מזהי טוקנים [t₁, t₂, ... tₙ]
   ↓  Embedding lookup
וקטורים צפופים במרחב מספרי
   ↓  Transformer layers
ייצוגים תלויי־הקשר
   ↓  Output projection
ציונים לכל טוקן אפשרי
   ↓  Sampling / Selection
הטוקן הבא, ואז שוב

איך נבנה מילון הטוקנים? דוגמת BPE#

אחת השיטות הנפוצות לבניית מילון טוקנים היא Byte Pair Encoding (BPE). במקור זה אלגוריתם דחיסה. Sennrich ושותפיו התאימו אותו לתרגום מכונה כדי לייצג מילים נדירות או חדשות כרצף של יחידות קטנות יותר [4]. הרעיון פשוט: מתחילים מתווים בודדים וממזגים שוב ושוב את הצמד הנפוץ ביותר ליחידה חדשה.

נניח קורפוס זעיר ומומצא. המילים והשכיחות שלהן: low ×5, lower ×2, newest ×6, widest ×3. כל מילה מסתיימת בסימן סיום _, כדי שהאלגוריתם יבדיל בין סוף מילה לאמצעה. נתחיל מתווים בודדים.

• סבב 1: הצמדים e s, s t ו־t _ מופיעים 9 פעמים כל אחד (6 ב־newest ו־3 ב־widest). בשוויון בוחרים את הראשון: ממזגים ל־es.
• סבב 2: הצמד es t מופיע 9 פעמים. ממזגים ל־est.
• סבב 3: הצמד est _ מופיע 9 פעמים. ממזגים ל־est_.
• סבב 4: הצמדים l o ו־o w מופיעים 7 פעמים (5 ב־low ו־2 ב־lower). בשוויון ממזגים את הראשון: lo.

עכשיו נקבל מילה שלא הופיעה בקורפוס: lowest. היא מתחילה כ־l o w e s t _. הפעלת ארבעת המיזוגים לפי הסדר נותנת lo, w, est_. המילה החדשה פורקה ליחידות מוכרות. זו בדיוק הסיבה שאין צורך במילון שמכיל כל מילה אפשרית.

איפה BPE מגביל, ומה הדוגמה אינה מוכיחה#

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

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

BPE ברמת בתים (byte-level). הדוגמה למעלה פועלת ברמת תווים. במאמר GPT-2 [7] מציינים שמימושי BPE רבים פועלים על נקודות קוד של Unicode, ושזה מחייב אוצר בסיס של יותר מ־130,000 סמלים. גרסה ברמת בתים דורשת אוצר בסיס של 256 בלבד, ובנוסף מונעים מיזוג בין קטגוריות תווים (עם חריג לרווחים). לעברית יש לכך משמעות: ב־UTF-8 תו עברי תופס יותר מבית אחד. חישוב בפייתון ('שלום'.encode('utf-8')) מראה שארבע האותיות של "שלום" הן 8 בתים, שניים לכל אות, לעומת 6 בתים לשש האותיות של shalom. ברמת בתים, מילה עברית שאינה שכיחה במילון עלולה להתפרק לבתים בודדים, אבל מספר הטוקנים שיתקבל בפועל תלוי ב־Tokenizer הספציפי ואינו נטען כאן.

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

למה אותו טקסט עולה מספר טוקנים שונה בשפות שונות?#

המילון נבנה מקורפוס מסוים. שפות שהיו נפוצות בו מקבלות יחידות ארוכות; שפות נדירות בו מתפרקות ליחידות קצרות, ולעיתים עד לבתים בודדים. התוצאה: אותו תוכן מתורגם דורש מספר שונה של טוקנים. Petrov ושותפיו מצאו בבדיקה שיטתית הבדלים של עד פי 15 באורך הקידוד בין שפות, גם בטוקנייזרים שנבנו לתמיכה רב־לשונית [5]. המשמעות המעשית: עלות לפי טוקנים, מהירות וכמות הטקסט שנכנסת לחלון ההקשר עלולים להיות פחות נוחים לשפות מסוימות.

המאמר אינו קובע כמה טוקנים תיתן עברית בטוקנייזר מסוים. את זה אין כאן; הדרך לדעת היא להריץ את ה־Tokenizer של המודל שבו משתמשים על טקסט עברי.

מהו Embedding — והאם זה "מפת משמעות"?#

לכל טוקן ניתן, בין היתר, וקטור מספרי. וקטור כזה הוא רשימה מסודרת של ערכים ממשיים; למשל [0.2, −0.4, 1.1] בדוגמה תלת־ממדית פשוטה, בעוד שמודלים אמיתיים משתמשים בממדים רבים ובייצוגים שעוברים דרך שכבות רבות. בזמן האימון המודל לומד ייצוגים המתאימים למשימותיו. ניתן למצוא בהם לעיתים דמיון סמנטי וקשרים דקדוקיים. עם זאת, קרבה בין וקטורים אינה "הוכחה למושג" ואינה מפרטת באופן ישיר מה המודל יודע על העולם.

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

דמיון קוסינוס: איך מודדים קרבה בין וקטורים?#

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

נניח, באופן מומצא, שלוש מילים עם וקטורים תלת־ממדיים: כלב = [0.9, 0.1, 0.3], גור = [0.8, 0.2, 0.4], מס = [0.1, 0.9, −0.2].

cos(כלב, גור) = (0.72 + 0.02 + 0.12) / (0.9539 × 0.9165) ≈ 0.984
cos(כלב, מס)  = (0.09 + 0.09 − 0.06) / (0.9539 × 0.9274) ≈ 0.136

גם החישוב הזה הורץ בקוד, והתקבלו 0.984 ו־0.136. הווקטורים הומצאו כדי שהחישוב יהיה קל לבדיקה.

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

איך מידע ממקומות אחרים ברצף מגיע לכל טוקן? (Attention דו־כיווני מול סיבתי)#

ב־Transformer פועל מנגנון Attention. המודל מחשב, באמצעות משקלים שנלמדו, שלוש משפחות ייצוגים המכונות Query, Key, Value (בקיצור Q, K, V). דרך החשיבה הפשוטה: כשמחשבים ייצוג של מקום מסוים ברצף, מודדים עד כמה מקומות אחרים רלוונטיים לו, ואז משלבים מידע מהם במשקלים שונים.

חשוב להבחין בין שני סוגים. ב־Encoder פועל בדרך כלל Attention דו־כיווני: כל טוקן יכול להתחשב בכל הרצף, לפניו ואחריו. ב־Decoder אוטורגרסיבי, כמו ברוב מודלי הצ'אט, פועל Attention סיבתי (causal): טוקן רואה רק את הטוקנים שלפניו ואת עצמו. הכותרת "מכל המשפט" נכונה רק למקרה הראשון; ההסבר על Causal mask בהמשך מפרט את השני.

בצורה הקלאסית של Scaled Dot-Product Attention:

Attention(Q,K,V) = softmax(QKᵀ / √dₖ) V

הכתיב עלול להיראות מאיים, אבל כל רכיב ממלא תפקיד ברור:

• QKᵀ: מכפלות פנימיות שמעניקות ציוני התאמה בין שאילתות ומפתחות.
• √dₖ: גורם קנה מידה המסייע ליציבות החישוב.
• softmax: המרה למשקלים חיוביים שסכומם 1 לאורך המיקומים המותרים.
• הכפלה ב־V: ממוצע משוקלל של המידע שנשלף מהמיקומים השונים.

דוגמה מספרית זעירה#

נניח — באופן מומצא — שלטוקן הנוכחי שני ציוני התאמה אחרי חלוקה בגורם קנה המידה: 2 ו־0. פונקציית Softmax תפיק בערך 0.881 ו־0.119. אם וקטורי הערכים הם 10 ו־0 בדוגמה חד־ממדית, התוצאה המשוקללת היא בערך 8.81. אין זה "המודל הסתכל 88% מהזמן" במקום הראשון; אלו משקלי ערבוב מספריים בשכבה ובראש Attention מסוימים.

דוגמה מלאה יותר: שלושה מיקומים, שאילתה אחת#

נניח, באופן מומצא, שאילתה q = [1, 0] ושלושה מפתחות: k₁ = [1, 0], k₂ = [0, 1], k₃ = [1, 1]. כאן dₖ = 2, ולכן מחלקים ב־√2 ≈ 1.414.

1. מכפלות פנימיות: q·k₁ = 1, q·k₂ = 0, q·k₃ = 1.
2. קנה מידה: מחלקים ב־1.414 ומקבלים 0.707, 0 ו־0.707.
3. Softmax: מעלים את e בחזקת כל ציון ומנרמלים. התוצאה: 0.401, 0.198 ו־0.401. הסכום 1.
4. ערכים: נניח שוקטורי הערכים הם 10, 20 ו־30 (חד־ממדיים). הממוצע המשוקלל הוא 0.401×10 + 0.198×20 + 0.401×30 = 20.0.

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

למה בכלל מחלקים ב־√dₖ? במאמר המקורי כותבים שהם משערים כי בערכי dₖ גדולים המכפלות הפנימיות גדלות בגודלן ודוחפות את Softmax לאזורים שבהם הגרדיאנטים קטנים מאוד, והחלוקה נועדה לנטרל את האפקט [1]. זו הנמקה של המחברים, לא הוכחה כללית.

מה עושה Causal mask? חישוב#

נניח שבמקום הנוכחי (המיקום השלישי) המודל מחשב ציונים לארבעה מיקומים: 1.0, 0.5, 0.0 ו־2.0. המיקום הרביעי הוא עתידי. אם מסתירים אותו (מציבים מינוס אינסוף לפני Softmax), נשארים שלושה משקלים: 0.506, 0.307 ו־0.186. אם לא מסתירים, העתיד מקבל 0.579 מהמשקל, יותר מכל השאר. במצב כזה, בזמן אימון, המודל יכול "להציץ" בתשובה. המספרים מומצאים, והחישוב הורץ.

איך Attention הופך ייצוג כללי לייצוג תלוי־הקשר#

נחזור ל"ראש". נניח, באופן מומצא, שוקטור הערכים של "ראש" הוא [1, 1]. בצירוף "ראש מחלקה" וקטור הערכים של "מחלקה" הוא [0, 2]; בצירוף "ראש ההר" וקטור הערכים של "ההר" הוא [2, 0]. קודם נניח שבשני הצירופים הציונים של "ראש" הם 1 (כלפי עצמו) ו־2 (כלפי המילה השנייה). אחרי Softmax המשקלים הם 0.269 ו־0.731, זהים בשני המקרים.

ראש מחלקה: 0.269×[1,1] + 0.731×[0,2] = [0.269, 1.731]
ראש ההר:    0.269×[1,1] + 0.731×[2,0] = [1.731, 0.269]

כאן ההבדל נובע רק מערכי ה־Value של השכנה: המשקלים זהים. זה מראה שאותו ייצוג התחלתי הופך לשני וקטורים שונים לפי השכנה, אך לא מראה שההקשר משנה את המשקלים. במודל אמיתי גם הציונים תלויים בהקשר, כי הם מחושבים ממכפלה פנימית בין Query של "ראש" ל־Key של השכנה. נניח אפוא שבצירוף "ראש ההר" הציון כלפי "ההר" הוא 0 (במקום 2). אז המשקלים הופכים ל־0.731 ו־0.269, והתוצאה:

ראש ההר (ציון 0): 0.731×[1,1] + 0.269×[2,0] = [1.269, 0.731]

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

איפה המנגנון נכשל, ומה הדוגמאות אינן מוכיחות#

• משקל Attention גבוה אינו אומר שהמודל "הבין" שהמיקום חשוב. המשקל מערבב וקטורים; מה שנעשה בהם בהמשך תלוי בשכבות הבאות.
• בדוגמה היו שלושה מיקומים וממדים בודדים. במודל אמיתי יש ראשים ושכבות רבים, וקשה לצמצם את ההחלטה למשקל יחיד.
• הדוגמה לא בודקת דיוק: אין בה מדד על נתוני אמת. היא מדגימה חישוב, לא יכולת.

למה צריך מידע על המיקום?#

אם מנגנון החישוב היה מקבל רק אוסף של טוקנים, הוא היה מתקשה להבחין בין "החתול רדף אחרי הכלב" לבין "הכלב רדף אחרי החתול". לכן Transformer כולל שיטות לקידוד סדר ומיקום: בקוד המקורי מ־2017 נעשה שימוש ב־Positional Encoding; מערכות מאוחרות משתמשות גם בשיטות אחרות כגון Rotary Positional Embeddings. ייצוג המיקום אינו קישוט — הוא משפיע על הדרך שבה יחסי רצף נלמדים.

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

שכבות: מה נערם על מה?#

ברמה העקרונית, הקלט עובר דרך מחסנית של שכבות זהות במבנה (לא במשקלים). כל שכבה מקבלת ייצוגים ומחזירה ייצוגים משופרים באותו גודל. במאמר המקורי הוגדרו 8 ראשי Attention במודל הבסיסי, עם dₖ = 64 בכל ראש [1]. אלה פרטי המאמר ההוא; מודלים אחרים בוחרים מספרים אחרים. לכן אין להסיק שיש "שכבה שמטפלת בדקדוק" ו"שכבה שמטפלת בעובדות". חלוקת עבודה כזו, אם קיימת, היא שאלת מחקר ולא עיקרון ארכיטקטוני.

מה ההבדל בין Transformer מקודד למפענח?#

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

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

מה עוד יש בשכבת Transformer?#

השם Attention אינו אומר שכל העבודה נעשית במנגנון אחד. שכבות כוללות בדרך כלל גם Feed-forward networks, Normalization, Residual connections ורכיבים ארכיטקטוניים נוספים. הם משתתפים בטרנספורמציה של הייצוגים. מרכיב Multi-head Attention מאפשר מספר תתי־מרחבים של תשומת לב הנלמדים במקביל. מספר הראשים אינו שקול למספר "מומחים אנושיים" או לתפקידי עבודה קשיחים.

יש גם מודלים המשתמשים ב־Mixture of Experts (MoE): נתב (router) בוחר, לכל טוקן ובכל שכבה בנפרד, אילו מיחידות המודל להפעיל, ורק הן מופעלות. כך, במאמר על Mixtral 8x7B, בכל שכבה ולכל טוקן נבחרים שניים מתוך 8 מומחים, ואותו טוקן עשוי לקבל מומחים שונים בשכבות שונות [6]. "מומחה" הוא שם ארכיטקטוני ליחידת חישוב, לא אישיות עם התמחות יציבה בהכרח.

כיצד נוצר הטוקן הבא?#

לאחר שכבות המודל, המערכת מחשבת ציון — logit — עבור כל טוקן במילון. Softmax יכול להפוך ציונים להתפלגות הסתברותית. במצב greedy decoding נבחר בכל צעד הטוקן בעל ההסתברות הגבוהה ביותר; בשיטות דגימה אחרות בחירת ההמשך יכולה להיות מגוונת יותר. פרמטרים כגון Temperature משנים את חדות ההתפלגות, אך אינם מתקנים עובדות שגויות באופן קסום.

דוגמה מחושבת: ציונים, הסתברויות ו־Temperature#

נניח, באופן מומצא, שלאחר שכבות המודל יש ארבעה טוקנים אפשריים בלבד, עם logits: 3.0, 1.0, 0.5 ו־0.0.

Softmax(3.0, 1.0, 0.5, 0.0) ≈ [0.789, 0.107, 0.065, 0.039]
Temperature = 0.5  → [0.973, 0.018, 0.007, 0.002]
Temperature = 2    → [0.533, 0.196, 0.153, 0.119]

חלוקת ה־logits ב־Temperature לפני Softmax מחדדת (ערך נמוך מ־1) או משטחת (ערך גבוה מ־1) את ההתפלגות. ב־greedy decoding הטוקן הראשון ייבחר בכל המקרים. בדגימה, ב־Temperature = 2 יש כ־47% סיכוי לטוקן אחר. כל המספרים מומצאים והחישוב הורץ בקוד. במילון אמיתי יש עשרות אלפי אפשרויות, ולא ארבע.

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

מדוע "חיזוי הטוקן הבא" מסוגל להיראות כמו חשיבה?#

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

ניסוי קריאה: מילה שנייה שמשנה את הראשונה#

הציגו למודל:

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

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

צעד אחד מקצה לקצה: סיכום המנגנון#

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

1. ה־Tokenizer מפרק את הטקסט לטוקנים ולמזהים מספריים.
2. לכל מזהה מוצמד וקטור התחלתי מטבלת Embeddings.
3. מוסיפים מידע על מיקום, כך שהסדר נשמר.
4. בכל שכבה, Attention מערבב מידע בין מיקומים (עם Causal mask במפענח), ואחריו רכיבי Feed-forward, Normalization ו־Residual connections מעבדים את התוצאה.
5. בסוף, שכבת פלט מחשבת logit לכל טוקן במילון.
6. Softmax (ואולי Temperature) הופך אותם להתפלגות; נבחר טוקן.
7. הטוקן מצטרף לרצף, והצעד חוזר.

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

תרחיש נגדי: כשהמנגנון מייצר המשך שגוי בביטחון#

נניח שהטוקן הראשון שנבחר ביצירת תשובה היה שגוי, למשל תאריך שגוי. הטוקנים הבאים מחושבים כשהתאריך הזה כבר חלק מההקשר. לכן ההמשך עשוי להיות קוהרנטי ושגוי. אי אפשר לסמוך מבחוץ על כך שהטוקן נכון (יש מחקר על ביטחון פנימי של מודלים, כמו Kadavath et al. 2022 המצוטט בפרק 9, אך הוא אינו תחליף לבדיקה); לשם כך צריך אימות חיצוני, כמו מקור, חישוב או בדיקה אנושית. המחשת הדוגמה בחלק של Temperature מראה שהמודל יכול להקצות הסתברות גבוהה לטוקן, אך הסתברות כזו אינה ערובה לאמת.

שאלות שכדאי לשאול מי שמוכר לנו מודל#

הידע בפרק הזה אינו תיאורטי בלבד. הוא הופך לשאלות מעשיות:

• איזה Tokenizer משמש, ואיך הוא מתנהג על טקסט בעברית? בקשו להריץ דוגמה אמיתית ולספור, במקום לקבל הערכה כללית.
• כמה טוקנים נכנסים לחלון ההקשר, ומה קורה כשחורגים? כאן עולה שוב ההבדל בין שפות שתואר למעלה.
• איך נבדקת איכות החיפוש בשיטת Embeddings? דמיון קוסינוס גבוה אינו מבטיח רלוונטיות; צריך אוסף שאלות עם תשובות ידועות כדי למדוד.
• האם הטענה על "הסבר" מסתמכת על מפת Attention? אם כן, זה סימן לזהירות.

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

מה לא להסיק#

• "טוקן הוא מילה." לא. טוקן הוא יחידה שנקבעה על ידי מילון ספציפי, וכמות הטוקנים תלויה ב־Tokenizer.
• "קרבה בין וקטורים היא הבנה." לא. זו תכונה גאומטרית של ייצוג שנלמד.
• "משקל Attention גבוה הוא ההסבר להחלטה." לא. ראו את האזהרה למעלה.
• "טמפרטורה נמוכה מגדילה אמת." לא. היא מחדדת את ההתפלגות, גם כשהיא מוטעית.
• "אם דוגמה הורצה בקוד היא מוכיחה משהו על מודלים אמיתיים." לא. החישובים כאן בודקים אריתמטיקה, לא ביצועים.

תרגיל#

1. אחרי ארבעת המיזוגים מדוגמת ה־BPE (es, est, est_, lo), איך תפורק המילה widest? ומה תהיה פירוק המילה lower?
2. חשבו את דמיון הקוסינוס בין [1, 0] ל־[1, 1].
3. בדוגמת ה־Attention, מה יקרה למשקלים אם כל שלושת הציונים שווים לאפס?
4. הסבירו במשפט אחד למה אי אפשר להסיק מהתרגיל הראשון משהו על אופן הפירוק של עברית.

תשובות בדיקה#

1. widest → w, i, d, est_. lower → lo, w, e, r, _.
2. 1 חלקי √2, כלומר כ־0.707.
3. Softmax של ציונים שווים נותן משקלים שווים: שלושה משקלים של כ־0.333 כל אחד.
4. הקורפוס, האותיות והשכיחויות הומצאו. פירוק עברית תלוי במילון של Tokenizer ספציפי.

לבדיקה עצמית#

מה ההבדל בין טוקן לווקטור Embedding? הראשון יחידת קידוד, השני ייצוג מספרי שלה. מה עושה Attention? משלב מידע ממיקומים שונים בהתאם לציוני התאמה נלמדים, בהקשר של הארכיטקטורה. האם כל המודלים משתמשים באותו Tokenizer? לא. האם מפה של Attention מסבירה לבד למה מודל ענה כך? לא.

מקורות#

1. Vaswani et al. (2017), Attention Is All You Need.
2. Harvard NLP — The Annotated Transformer, with mathematical and code explanations.
3. Jay Alammar — The Illustrated Transformer, an explanatory supplement.
4. Sennrich, Haddow, Birch — Neural Machine Translation of Rare Words with Subword Units. מאמר מחקר; הוגש ב־31.8.2015, גרסה אחרונה 10.6.2016. מציג שימוש ב־BPE לפירוק מילים נדירות ליחידות משנה.
5. Petrov, La Malfa, Torr, Bibi — Language Model Tokenizers Introduce Unfairness Between Languages. מאמר מחקר; הוגש ב־17.5.2023, גרסה אחרונה 20.10.2023. הפערים בקידוד בין שפות (עד פי 15 לפי המחברים).
6. Jiang et al., Mixtral of Experts (arXiv 2401.04088, 2024). מאמר מחקר; לפי התקציר: לכל טוקן ובכל שכבה router בוחר שני מומחים. לרקע: Shazeer et al. 2017 (arXiv 1701.06538) הגדירו שער שבוחר מומחים לכל דוגמה ("per example"), ו־Switch Transformer (arXiv 2101.03961) בוחר פרמטרים לכל דוגמה נכנסת.
7. Radford et al. (2019), Language Models are Unsupervised Multitask Learners (GPT-2). דוח טכני, סעיף 2.2 Input Representation: BPE ברמת בתים, אוצר בסיס 256, מניעת מיזוג בין קטגוריות תווים.

המקור הראשון (Vaswani et al., 2017, arXiv, הוגש 12.6.2017) הוא מאמר מחקר. המקורות 2 ו־3 הם חומרים חינוכיים.