קונטקסט — החומר שהמודל רואה והמידע שהוא מחמיץ

מבחן הקונטקסט: מי יודע מה?#

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

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

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

מהו חלון הקשר (Context window)?#

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

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

החלון כמשאב: קלט, פלט ועלות#

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

יש גם עלות שלא רואים מיד. בשיחה ארוכה, יישום שולח בדרך כלל שוב את ההיסטוריה בכל קריאה. נניח, שוב כהמחשה, הוראות מערכת של 2,000 טוקנים, ובכל סבב הודעה של 200 טוקנים ותשובה של 600. בסבב הראשון נשלחים 2,200 טוקנים. בסבב השני 3,000. בסבב העשירי 9,400. סך כל הטוקנים שנשלחו בעשרת הסבבים הוא 58,000, אף שהשיחה כולה מכילה רק 10,000 טוקנים של תוכן. החישוב הורץ בפייתון ונבדק. מכאן ששיחה ארוכה היא לא רק עניין של "נכנס או לא נכנס", אלא גם של זמן ועלות חישוב. לא מציינים כאן מחירים, כי הם משתנים.

הדוגמה שאפשר לחשב#

בתמליל פגישה של 40,000 טוקנים ההחלטה החשובה מופיעה במשפט אחד באמצע. מבחינת מגבלת הגודל, המידע נכנס. מבחינת שליפה והסקה, המודל עדיין צריך לזהות את המשפט מבין אלפי אחרים ולפרש אותו במדויק. אלו שתי שאלות שונות: Can it fit? ו־Can it use it reliably?.

מחקר "Lost in the Middle" (2024) הראה בתנאי ניסוי מסוימים ירידה בביצועים כאשר מידע רלוונטי נמצא במרכז מסמכים ארוכים, גם במודלים שנועדו לטפל בקונטקסט ארוך. המחקר אינו מוכיח שכך יקרה בכל מודל ובכל אורך, אך הוא מפריך את ההנחה ש"הכול נכנס" פירושו "הכול מנוצל באותה איכות" [1].

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

איך סדר המידע וההוראות משפיע?#

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

דוגמה:

משימה: מהו סכום התקציב שאושר בפגישה?
מקורות:
[עמ' 4] הצעה ראשונית: 85,000 ₪.
[עמ' 17] לאחר דיון אושר תקציב 62,000 ₪.
[עמ' 28] החלטת המשך: רכישת ציוד בכפוף לתקציב שאושר.
הוראה: ענה עם סכום מאושר, מספר עמוד והסבר למה ההצעה הראשונה אינה ההחלטה הסופית.

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

איך RAG מספק מידע חדש בלי לאמן את המודל מחדש?#

Retrieval-Augmented Generation — RAG הוא דפוס שבו מערכת מאתרת קטעי מידע ממקור חיצוני ומצרפת אותם למודל לפני ההפקה. במקום לצפות שהמודל למד בעל־פה את כל מחירון החברה, הוא מחפש את הקטע המתאים כשהשאלה מגיעה. אין צורך לשנות את המשקלים כדי לעדכן קובץ מחירון: מעדכנים את מקור הנתונים או האינדקס, ואת המידע הרלוונטי שולפים מחדש. המודל לא "למד" את המידע; הוא מקבל אותו בקונטקסט של הקריאה הנוכחית בלבד.

שאלה חדשה: "מה תוקף הצעת המחיר?"
      ↓
מערכת חיפוש מאתרת קטעים קשורים
      ↓
הקטעים + מקור/תאריך נכנסים לקונטקסט
      ↓
המודל מנסח תשובה ומתבקש להצביע למקור
      ↓
בדיקת אמינות וציון אם אין מידע מספיק

מה עלול להשתבש?

• מסמך לא נכנס לאינדקס כלל.
• החיפוש שלף מחירון ישן במקום חדש.
• הקטע נחתך בדיוק לפני הסתייגות חשובה.
• מקור זדוני מכיל הוראות המנסות להשתלט על תגובת המודל (Prompt injection).
• המודל מתאר את מקור המידע באופן לא מדויק או מצטט מקור לא רלוונטי. מכאן ש־RAG לא "פותר הזיות", אלא נותן דרך לעגן תשובות במקורות תוך יצירת חוליות חדשות שצריך לבדוק.

צנרת RAG בשלבים#

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

1. הכנה: אוספים מסמכים וממירים אותם לטקסט.
2. חלוקה למקטעים (chunking): מפצלים כל מסמך לקטעים בגודל שאפשר לשלוף ולהציג.
3. ייצוג ואינדוקס: ממירים כל מקטע לווקטור (embedding) ושומרים אותו באינדקס.
4. שליפה: בגרסה הווקטורית הבסיסית, ממירים את השאלה לווקטור באותה דרך, ומדרגים מקטעים לפי דמיון. זו רק אחת מדרכי השליפה; ראו בהמשך חיפוש לקסיקלי, היברידי ודירוג מחדש.
5. הרכבה: מצרפים את k המקטעים הראשונים, עם מקור ותאריך, לקונטקסט.
6. הפקה ובדיקה: המודל עונה, ומתבקש לצטט ולהודות כשאין מידע.

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

דרכי שליפה: סמנטית, לקסיקלית, היברידית ודירוג מחדש#

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

לפי תיעוד של Elastic [8], חיפוש לקסיקלי (BM25) טוב כשהמשתמש יודע מה הוא מחפש, וחיפוש סמנטי עוזר בתוכן לא מובנה ובשאילתות מעורפלות. הם מציינים גם שציוני BM25 אינם חסומים בטווח קבוע, ולכן מיזוג ישיר של ציונים קשה, ושאחת משיטות המיזוג (Reciprocal Rank Fusion) פועלת לפי דירוג ולא לפי ציון. לפי Pinecone [9], תבנית נפוצה היא שליפה בשני שלבים: מודל מהיר שולף קבוצה רחבה של מועמדים, ו־reranker (cross-encoder) מדרג מחדש קבוצה קטנה, כי הוא איטי יותר אך מעריך את השאילתה והמסמך יחד. אלה תיעודי ספקים, לא מדידות עצמאיות, ואין כאן טענה איזו שיטה טובה יותר ביישום שלכם: זה דורש בדיקה על הנתונים שלכם. (BM25 כשיטה מקורו במחקר של Robertson ושותפיו.)

חלוקה למקטעים: דוגמה מחושבת#

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

מקטע 1: הצעת המחיר תקפה ל־30 יום מתאריך ההנפקה בכפוף לתנאי התשלום. על הזמנות
מקטע 2: מיוחדות התוקף הוא 7 ימים בלבד. אספקה תתבצע בתוך 14 ימי עסקים.

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

מקטע 1: הצעת המחיר תקפה ל־30 יום מתאריך ההנפקה בכפוף לתנאי התשלום. על הזמנות
מקטע 2: לתנאי התשלום. על הזמנות מיוחדות התוקף הוא 7 ימים בלבד. אספקה תתבצע
מקטע 3: ימים בלבד. אספקה תתבצע בתוך 14 ימי עסקים.

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

דירוג לפי דמיון: דוגמה מחושבת#

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

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

מה הדוגמאות אינן מוכיחות#

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

מצבי כשל נפוצים ואיך מזהים אותם#

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

זיכרון לעומת קונטקסט לעומת Cache#

המונחים נשמעים דומים אך מתארים מנגנונים נפרדים:

• Context: המידע שנמסר לקריאה הנוכחית למודל.
• Persistent memory: מידע שהיישום שומר ועשוי לבחור להוסיף לקריאות עתידיות.
• Conversation history: רשומת הודעות; לא חייבים לשלוח את כולה בכל פעם.
• Prompt caching: מנגנון תשתיתי של שימוש חוזר בחישוב עבור קידומת זהה, שעשוי לקצר זמן ולחסוך משאבים. הוא אינו הופך את המודל ללומד או לזוכר העדפות כפי שזיכרון מוצר עושה.

איך עובד Prompt caching#

לפי התיעוד של OpenAI ושל Anthropic, המטמון נשען על קידומת (prefix) של הבקשה, ומחייב התאמה מדויקת. OpenAI כותבת שניצול חוזר דורש שכל הקידומת תהיה זהה [3]. Anthropic מתארת סדר קבוע של כלים, הוראות מערכת והודעות, ומציינת שפגיעה במטמון דורשת קטעים זהים לחלוטין עד לנקודה שסומנה [5]. שינוי בכלי או בהוראות המערכת מבטל את המטמון מאותה נקודה ואילך [5].

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

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

חלון ארוך או שליפה: מתי מה?#

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

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

מה לא להסיק#

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

תרגול: למידה של כשל בלי צורך בקובץ אמיתי#

העתיקו את שלושת קטעי המקור לעיל ושאלו:

1. "מה התקציב?" — בדקו אם המודל מבדיל בין הצעה לאישור.
2. "עני בשתי מילים בלבד" — ראו האם קיצור התשובה מפחית עקיבות של מקור.
3. "מה התקציב לשנה הבאה?" — המידע אינו קיים בקטעים. תשובה ראויה מציינת היעדר מידע במקום להעתיק 62,000 ₪ ללא הצדקה.

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

תרגיל חישובי#

נתונות שלוש הוראות. בלי להריץ מודל, פתרו:

1. חלון של 20,000 טוקנים, קלט של 18,500 ותשובה מבוקשת של 2,000. האם הכול נכנס?
2. מסמך של 30 מילים מחולק למקטעים של 10 מילים, בחפיפה של 2 מילים בין סמוכים. כמה מקטעים יתקבלו? (רמז: כל מקטע חדש מתחיל 8 מילים אחרי הקודם.)
3. השאלה היא (1, 0), מקטע א הוא (1, 0), מקטע ב הוא (0.6, 0.8). חשבו דמיון קוסינוס של כל מקטע. מה אפשר ומה אי אפשר להסיק מהתוצאה על נכונות התשובה?

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

מקור וקריאה נוספת#

1. Liu et al., Lost in the Middle — TACL 2024 (ACL Anthology) — TACL כרך 12, עמ' 157–173, 2024; גרסת MIT Press: קישור.
2. Lewis et al., Retrieval-Augmented Generation (2020).
3. OpenAI API — Prompt Caching — מדריך תשתיתי שמתעדכן; לא להניח שהוא מתאר את כל מוצרי AI. תיעוד יצרן. עיקרי מה שנלקח ממנו: דרישת קידומת זהה, הצבת תוכן יציב בהתחלה, והמטמון אינו משנה את אופן יצירת הפלט.
4. Anthropic — Context windows — תיעוד יצרן. החלון כולל גם את התשובה; קידומת במטמון נספרת בחלון; "context rot" כטענת יצרן.
5. Anthropic — Prompt caching — תיעוד יצרן. סדר כלים, הוראות, הודעות; התאמה מדויקת; ביטול מטמון בשינוי.
6. Liu et al., Lost in the Middle — arXiv:2307.03172 — מאמר מחקר. גרסה ראשונה 6.7.2023, גרסה נוכחית מ־20.11.2023; התקציר מציין קבלה ל־TACL; שנת הפרסום בכתב העת: 2024 (מקור 1).
7. Lewis et al., Retrieval-Augmented Generation — arXiv:2005.11401 — מאמר מחקר. הוגש במאי 2020, התקבל ל־NeurIPS 2020.
8. Elastic Search Labs — Hybrid search (lexical BM25 מול סמנטי, מיזוג) — תיעוד/בלוג ספק. הבחנה בין חיפוש לקסיקלי וסמנטי, ושיטות מיזוג.
9. Pinecone — Rerankers and Two-Stage Retrieval — חומר חינוכי של ספק. שליפה דו־שלבית ו־cross-encoder.