Token Engineering — ניהול Context ותקציב Tokens

מאת צוות מדיה דיל · 09.08.2026 · AI · 8 דק׳

מדריך טכני ל-Token Engineering: איך מנהלים תקציב טוקנים מוגבל בין system prompt, היסטוריה, RAG וכלים - ומה קורה כשה-Context Window מתמלא ואיכות התשובות יורדת.

AI agent עם context window של מאה אלף טוקנים נשמע כמו שפע בלתי מוגבל - עד שמצרפים system prompt מפורט, היסטוריית שיחה שמתארכת, תוצאות RAG שנשלפות לכל שאלה, והגדרות כלים מרובות, ומגלים שהמקום נגמר מהר יותר משנדמה. גרוע מזה: מחקרים על ביצועי LLM מראים שאיכות התשובה לא נשארת קבועה ככל שה-Context מתמלא - מודלים נוטים "לאבד" מידע שנמצא באמצע חלון הקשר ארוך, תופעה שמכונה "Lost in the middle". Token Engineering הוא המשמעת ההנדסית של ניהול תקציב הטוקנים המוגבל הזה במודע ובכוונה, במקום להזין למודל כל מידע זמין ולקוות לטוב.

Context Window הוא משאב, לא אחסון בלתי מוגבל

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

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

חלוקת תקציב - ארבע הקטגוריות המרכזיות

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

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

Lost in the Middle - למה מיקום המידע קובע לא פחות מקיומו

מעבר לתקציב הכולל, יש להתחשב איפה בתוך הפרומפט המידע החשוב ביותר ממוקם. מחקרים אמפיריים על ביצועי מודלי שפה מראים שמידע שנמצא בתחילת או בסוף חלון ההקשר נוטה להישלף ולהיות מנוצל בצורה מדויקת יותר מאשר מידע שקבור באמצע - תופעה שקיבלה את הכינוי "Lost in the middle". המשמעות המעשית: אם יש עובדה אחת קריטית מבין כמה קטעי הקשר שנשלפו מ-RAG, כדאי לוודא שהיא ממוקמת קרוב לתחילת או לסוף הקטע הרלוונטי בפרומפט, ולא באמצע רשימה ארוכה של קטעים פחות חשובים.

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

אסטרטגיות דחיסת היסטוריה

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

Sliding Window

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

סיכום (Summarization) תקופתי

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

שילוב היברידי

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

מדידה - איך יודעים שהתקציב נכון

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

Context Compaction לעומת קיצוץ מוחלט

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

Token Budget למערכות Multi-Agent

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

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

כלים (Tools) ותקציב טוקנים - עלות נסתרת

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

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

טעויות נפוצות ב-Token Engineering

• הכנסת כל תוצאה אפשרית "ליתר ביטחון" - שליחת יותר קטעי RAG ממה שנחוץ, מתוך הנחה שיותר מידע תמיד עוזר, כשבפועל זה מוסיף עלות ולעיתים פוגע באיכות.
• הזנחת מיקום המידע החשוב - קבורת עובדה קריטית באמצע רשימה ארוכה של הקשר פחות רלוונטי, בלי להתחשב באפקט "Lost in the middle".
• אין אסטרטגיית ניהול היסטוריה - הנחה שה-context window "מספיק גדול" בלי תוכנית למה קורה כשהשיחה מתארכת מעבר לצפוי.
• אי-מדידת השפעת גודל ה-Context על איכות - קביעת מספר קטעי RAG או אורך היסטוריה שרירותית, בלי לבדוק אמפירית מה באמת משפר תשובות.

דוגמה מהשטח - כשיותר מידע הוריד את איכות התשובות

בפרויקט של עוזר AI פנימי לניתוח מסמכים משפטיים, הצוות התחיל בגישה של "בטוח יותר" - שליפת 15 קטעי הקשר רלוונטיים מ-RAG לכל שאלה, מתוך הנחה שיותר הקשר יבטיח שאף פרט חשוב לא יוחמץ. בבדיקה אמפירית עם סט Evals ייעודי, התברר שדיוק התשובות בפועל היה נמוך יותר עם 15 קטעים לעומת גרסה מכווננת ל-5 הקטעים הרלוונטיים ביותר בלבד, אחרי Reranking קפדני. הסיבה: חלק מהקטעים הנוספים היו רלוונטיים באופן שולי בלבד, אבל נוכחותם בפרומפט "דיללה" את תשומת הלב של המודל ולעיתים הובילה אותו לענות על היבט לא רלוונטי של השאלה שהוזכר באחד הקטעים הנוספים. הפתרון היה שילוב של Reranking אגרסיבי יותר לצמצום מספר הקטעים, ומיקום מכוון של הקטע החשוב ביותר בתחילת רשימת ההקשר. הלקח המרכזי: "יותר הקשר" הוא לא באופן אוטומטי "יותר טוב" - זו טענה שצריך לבדוק אמפירית לכל מערכת בנפרד, לא להניח.

שאלות נפוצות

מה ההבדל בין Token Engineering ל-Context Engineering?

Context Engineering הוא המושג הרחב יותר שכולל את כל ההחלטות על מה נכנס להקשר של המודל; Token Engineering מתמקד ספציפית בניהול התקציב הכמותי המוגבל של הטוקנים בתוך אותו הקשר.

מה זה "Lost in the middle" ולמה זה חשוב?

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

איך מנהלים היסטוריית שיחה ארוכה?

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

האם Context Window גדול יותר פותר את הבעיה?

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

איך מודדים אם תקציב הטוקנים מנוהל נכון?

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

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

תגיות: Token Engineering · Context Window · LLM · Context Engineering · Prompt Design · RAG · Token Budget

← חזרה לבלוג · צור קשר