מה זה חלון הקשר? המגבלה בבינה מלאכותית שמסבירה הכל

חלון הקשר הוא כל זיכרון העבודה של המודל

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

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

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

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

טוקן אחד שווה בערך לשלושה רבעים ממילה

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

ההמרות המקורבות ששווה לזכור:

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

זה נותן דרך לדמיין את המספרים שרואים בחומרי שיווק:

חלון הקשר	שווה בערך ל
8,000 טוקנים	מאמר ארוך
32,000 טוקנים	מאמר מחקר קצר עם הערות
128,000 טוקנים	ספר בן 300 עמודים
200,000 טוקנים	מדריך טכני צפוף, או בסיס קוד בגודל בינוני
1,000,000 טוקנים	כמה ספרים, או שנה של תמלולי פגישות

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

מה בעצם ממלא את החלון שלך?

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

1. הנחיית המערכת (system prompt). ההוראות שהמוצר שולח לפני שהקלדת משהו: איך להתנהג, אילו כלים קיימים, מה התאריך היום, כללי בטיחות. לרוב אלפי טוקנים, ואף פעם לא רואים אותה.
2. ההנחיות המותאמות אישית או הזיכרון שלך. כל מה שהמוצר שמר עליך ומזריק אוטומטית.
3. כל הודעה קודמת, שלך ושל המודל, במלואה. גם התשובות הארוכות של המודל נספרות, והן בדרך כלל התורמות הגדולות ביותר.
4. כל קובץ שהעלית, או החלקים שחולצו ממנו. קובץ PDF בן 40 עמודים הוא בערך 20,000 עד 30,000 טוקנים.
5. תוצאות כלים וחיפוש. חיפוש באינטרנט שמביא חמישה עמודים יכול להוסיף יותר מכל השיחה שלך עד כה.
6. התשובה שנוצרת כרגע. הפלט חולק את אותו התקציב כמו הקלט.

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

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

האיכות יורדת עוד לפני המגבלה המפורסמת

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

הגרסה המתועדת ביותר של התופעה הזו נקראת לרוב אפקט "אבוד באמצע" (lost in the middle). שים עובדה ספציפית בתחילת מסמך ארוך והמודל מוצא אותה. שים אותה בסוף והמודל מוצא אותה. קבור אותה באמצע והדיוק יורד: בניסויי Lost in the Middle המקוריים (Liu et al., 2023, מקושר בהמשך), העברת המסמך המרכזי מהקצוות של הקלט אל האמצע עלתה למודלים בערך 20 נקודות דיוק. תשומת הלב לא מתחלקת באופן שווה על פני קלט ארוך, והקצוות מקבלים ממנה יותר.

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

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

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

מה קורה כשנגמר לך המקום

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

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

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

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

שבע טקטיקות שבאמת עובדות

אלה מסודרות לפי כמה הבדל הן עושות ביחס למאמץ.

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

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

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

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

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

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

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

כמה חלון באמת צריך?

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

העבודה שלך	מה אתה צריך	למה
אימיילים, ניסוח, שאלות מהירות	כל מודל מודרני	לעולם לא תתקרב למגבלה
עריכת מסמכים ארוכים	100,000 ומעלה	המסמך בתוספת השיחה שלך עליו
בדיקת חוזים ומדיניות	200,000 ומעלה, ולוודא	המסמך בתוספת ההיסק עליו, עם ההסתייגות שלמעלה
היסק על פני בסיס קוד שלם	הכי גדול שיש	קוד צפוף בטוקנים והיסק חוצה קבצים דורש רוחב
ניתוח חודשים של תמלולים	הכי גדול שיש, או אחזור	לרוב עדיף אחזור מאשר כוח גס
בניית מוצר על גבי API	קטן יותר ממה שחושבים, בתוספת caching	הנחיות ארוכות הן הגורם העיקרי לעלות ולזמן תגובה

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

אם אתה רוצה לבדוק זאת בעצמך, הגישה המעשית היא להריץ את אותו מסמך ארוך דרך שניים או שלושה מודלים ולבדוק את התשובות מול משהו שאתה כבר יודע. סביבת עבודה כמו Whizi מקלה על זה כי GPT, Claude, Gemini, Grok, ו-DeepSeek נמצאים תחת מנוי אחד, וגם החלון הגדול מאוד של Gemini נמצא קליק אחד מהסינתזה הזהירה של Claude. ראה השוואת מודלים זה מול זה, או קרא איך לבחור מודל בינה מלאכותית להחלטה הרחבה יותר.