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

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

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

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

ההקשר כולל בין היתר את הרכיבים הבאים:

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

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

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

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

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

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

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


הפוסט של אנדריי קרפטי אודות הנדסת הקשר
https://x.com/karpathy/status/1937902205765607626

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

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

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

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

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

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

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

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

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

5 פורמט נכון ומדויק (Effective Formatting)
אופן הצגת המידע למודל משפיע באופן ישיר על היכולת שלו להבין אותו. פורמט לא מסודר יכול לגרום לבלבול, להחמצת פרטים ולהחלטות שגויות.
פורמט נכון כולל שימוש בסיכומים במקום גושי מידע גולמיים, הצגת תוכן בטבלאות כשיש צורך בהשוואות, והגדרת סכמות מדויקות עבור כלים ופלט.
בחלב מהמקרים העברת המידע בצורה מובנית כמו MarkDown, YAML, XML, JSON או פורמטים אחרים יסייעו למודל להבין טוב יותר את ההקשר עליו הוא צריך להתבסס.
הנדסת הקשר מתייחסת גם לצורה ולא רק לתוכן, מבנה ברור מאפשר למודל לפענח את הנתונים בקלות ולפעול באופן עקבי ואמין.

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

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

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

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

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

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