הנדסת הקשר: העבודה לפני ההנחיה
· 5 min read · Filippo Spinella · AI, Agents, Prompting, Developer Tools
המילה של הרגע, בעולם הקטן של סוכני AI, היא הנדסת הקשר.
נראה כאילו עוד תווית המציאה כדי למכור משהו שכבר עשינו. בחלקו כן. עם זאת, כפי שקורה לעתים קרובות, התווית תופסת כי היא נותנת שם לכאב אמיתי.
הכאב הוא כזה: דוגמניות לא נכשלות רק בגלל שהן "לא חושבות". לעתים קרובות הם נכשלים כי אנחנו שולחים אותם לעבוד עם החדר הלא נכון.
אנחנו נותנים להם הוראות ישנות. אנחנו מסתירים ממנו קבצים חשובים. אנחנו מעבירים להם מסמכים ארוכים מדי ולא אומרים מה חשוב. אנו מראים להם יומנים ללא עדיפות. אנו נותנים להם עשרה כלים מבלי להסביר מתי להשתמש בהם. אז אנחנו מופתעים אם הסוכן זז כמו אדם שהתעורר בדירה לא מוכרת.
ההנחיה היא הביטוי שאתה אומר לו. ההקשר הוא העולם שאתה מכין סביבו.
מהנדסה מהירה להנדסת הקשר
הנדסה מהירה נחשבה לעתים קרובות ככתיבה. בחר את המילים הנכונות, שאל בצורה הנכונה, הוסף דוגמאות, ציין את הפורמט.
הנדסת הקשר קרובה יותר לארכיטקטורה.
לא סתם שואלים "איך אני מנסח את הבקשה?". זה שואל:
- איזה מידע באמת נחוץ?
- מה זה רעש?
- מה צריך לשחזר תוך כדי תנועה?
- מה צריך לזכור?
- אילו כלים צריכים להיחשף?
- אילו הוראות יציבות ואילו תלויות במשימה?
- איך אני גורם לסוכן להבין מה סמכותי?
זה שינוי עדין אבל עצום. כי כשאתה עובד עם סוכנים, ההקשר אינו חסם סטטי. זה משתנה בכל שלב.
הסוכן פותח קובץ, לומד משהו, מריץ בדיקה, מקבל שגיאה, מעדכן את התוכנית, קורא לכלי, מגלה תלות. בכל סיבוב הוא צריך להחליט מה לקחת איתו ומה להשאיר בחוץ.
זו הנדסה.
ההקשר אינו מזבלה
תבניות עם חלונות הקשר גדולים נתנו לנו פיתוי: בואו נזרוק הכל פנימה.
זה מובן. אם יש לי מיליון אסימונים, למה לי לבחור?
כי גם כשאפשר להכניס הכל, זה לא אומר שהכל עוזר. אכן, לרעש יש מחיר. זה עולה אסימונים, זה עולה תשומת לב, זה עולה חביון, זה עולה איכות. דוגמנית יכולה ללכת לאיבוד בפרטים לא רלוונטיים בדיוק כמונו כשאנחנו פותחים עשרים טאבים וכבר לא זוכרים למה.
להקשר טוב יש היררכיה:
- הוראות מערכת ומדיניות;
- מטרה ספציפית;
- מצב נוכחי;
- נתונים רלוונטיים;
- אילוצים;
- כלים זמינים;
- לעקוב אחר ההחלטות שכבר התקבלו.
אין צורך להתייחס לכל דבר באותה רמה. פקודת משתמש שווה יותר מפתק ישן. מבחן שנכשל שווה כעת יותר מהעדפה אסתטית מלפני שלושה חודשים. מדיניות אבטחה שווה יותר מקיצור דרך ייצור.
הנדסת הקשר פירושה גם לתת משקלים, לא רק נתונים.
זיכרון: זכור פחות, זכור טוב יותר
זיכרון אצל סוכנים הוא אחד הנושאים החלקלקים ביותר.
כמשתמש, אתה רוצה שהסוכן יכיר אותך. אתה רוצה שהוא יזכור את הטון, התוכנית, המוסכמות, הדברים שכבר הוחלט. כמהנדס, אתה יודע שכל זיכרון מתמשך הוא גם סיכון: הוא יכול להיות שגוי, ישן, אישי מדי, גנרי מדי, בלתי ניתן לאימות.
לזיכרון שימושי צריך להיות לפחות שלוש תכונות:
- מקור: מאיפה המידע הזה מגיע?
- תאריך: מתי זה היה נכון?
- מטרה: לאיזה סוג משימה יש להשתמש בה?
בלי שלושת הדברים האלה, הזיכרון הופך לאמונה תפלה.
אני אוהב לחשוב על זיכרון סוכן כעל חוברת עבודה, לא על מוח קסום. יש הערות זמניות, החלטות מאושרות, העדפות סגנון, אילוצים טכניים, קישורים למקורות. יש דברים שפג תוקף. חלקם צריכים להיכתב מחדש. יש לחסל חלקם כי הסוכן הסיק אותם לא נכון.
מערכת טובה חייבת להפוך את התחזוקה הזו לנורמלית. לא הרואי.
שליפה וכלים אינם אותו דבר
כשאנחנו מדברים על הקשר, לעתים קרובות אנחנו מגיעים מיד ל- RAG. הטבעה, מסד נתונים וקטוריים, chunking, דירוג מחדש.
הכל שימושי. אבל שליפה היא רק דרך אחת להביא מידע למודל. הוא לא היחיד.
סוכן יכול לקבל הקשר על ידי קריאת קבצים, שאילתות API, קריאה לשרת MCP, פתיחת דפדפן, הפעלת בדיקות, חיפוש ב-Slack, הסתכלות על לוח מחוונים, שאילת האדם.
החלק המעניין הוא להחליט באיזה מסלול להשתמש ומתי.
אם הסוכן צריך לענות על שאלה היסטורית, אולי מספיק רק השליפה. אם הוא צריך לתקן באג, הוא צריך לקרוא קוד אמיתי. אם הוא צריך להבין מדוע פריסה נכשלת, הוא צריך להסתכל על יומנים חדשים. אם אתה צריך לכתוב ללקוח, אתה צריך לאחזר את הטון, ההיסטוריה והסטטוס של הכרטיס. אם עליו לפעול בהפקה, עליו לבקש רשות.
ההקשר אינו מסד נתונים. זה זרימת עבודה.
הסוכן הטוב יודע גם להתעלם
סימן לבגרות אצל סוכנים יהיה היכולת לומר: אני לא צריך את המידע הזה.
זה נראה טריוויאלי, אבל זה מאוד קשה. מערכות סוכן רבות מצטברות. כל קריאת כלי מוסיפה טקסט. כל שגיאה נשארת במאגר. כל קובץ שנקרא מוסיף לערימה. בסופו של דבר לדגם יש היסטוריה ארוכה מאוד וללא מפה.
יש צורך בדחיסה. יש צורך בסינתזה ביניים. זה צריך להיות מובנה.
לא "זה כל מה שקרה", אלא:
- המטרה עדיין תקפה;
- השערה נוכחית;
- קבצים שכבר נבדקו;
- החלטות שהתקבלו;
- סיכונים פתוחים;
- הפעולה הבאה.
זה הופך את הסוכן לפחות תיאטרלי ויותר מועיל. לא בגלל שהוא נראה חכם יותר, אלא בגלל שהוא עובד עם שולחן מסודר.
הנדסת הקשר לצוותים, לא לאמנים מהירים
הסיבה שהנושא הזה מעניין אותי היא שהוא מעביר אחריות מהפרט למערכת.
בהנדסה מהירה, מי שיכול לדבר עם הדגם בצורה הטובה ביותר לרוב מנצח. בהנדסת הקשר, הצוות שמארגן את עבודתו בצורה הטובה ביותר מנצח: תיעוד, מוסכמות, בעיות, יומנים, בדיקות, בעלות, שמות, מקורות.
מאגר נקי הופך להקשר טוב יותר. גיליון כתוב היטב הופך לדלק טוב יותר. ספר הפעלה מעודכן חוסך אסימונים וחרדות. יומן שינויים ברור מפחית הזיות.
אלו חדשות טובות וקצת לא נוחות. יפה כי זה מתגמל שיטות עבודה טובות. לא נוח כי אי אפשר לפתור הכל עם הנחיה חכמה.
הסוכנים מגבירים את ההיגיינה של המערכת שהם מוצאים.
איך הייתי מיישם את זה מחר
אם הייתי מכניס הנדסת הקשר לפרויקט אמיתי, הייתי מתחיל מדברים קטנים:
- קובץ הוראות פרויקט קצר ומתוחזק;
- דוגמאות טובות לתפוקה צפויה;
- רשימה של כלים זמינים ומקרים שבהם ניתן להשתמש בהם;
- החלטות אדריכליות שנכתבו בצורה ניתנת לציטוט;
- בעיה עם מינימום הקשר חובה;
- קל לאחזר יומנים ובדיקות;
- זיכרון מתמשך שניתן לשינוי על ידי בני אדם.
ואז הייתי מודד דבר פשוט: כמה פעמים הסוכן צריך לבקש הבהרות או שהוא יוצא לכיוון הלא נכון?
אם זה קורה לעתים קרובות, לא הייתי מוסיף דגם גדול יותר מיד. הייתי מסתכל על ההקשר.
הקריאה שלי
הנדסת הקשר היא מילה קצת נפוחה, כן. אבל הקונספט נכון.
זה מזכיר לנו שהאינטליגנציה של סוכן היא לא רק במודל. זה טמון בסביבה שאנחנו מכינים לו: מה הוא רואה, מה הוא זוכר, מה הוא יכול לעשות, מה אסור לו לעשות, אילו מקורות הוא מזהה כנכונים.
החלק האנושי הוא זה: הכנת ההקשר היטב היא סוג של טיפול. זה אומר לסוכן, אבל גם לצוות, "אני לא רוצה שתנחש, אני רוצה שיהיה לך את מה שאתה צריך".
פחות קסם. חדר נקי יותר. הסוכנים צריכים את זה כמונו.