בקצרה: כשתהליך AI שעבד היטב מתחיל לייצר תוצרים חלשים, הסיבה היא בדרך כלל לא המודל ולא הפרומפט, אלא ההקשר: כל החומר שהמודל קורא בזמן העבודה. חומר כזה נרקב בשש צורות: עודף מידע, יותר מדי אפשרויות, עותקים שהתפצלו, מידע מיושן, הוראות סותרות וטעות שחלחלה הלאה. הפתרון הוא סקירה קבועה של קובצי ההנחיות, הזיכרון ומאגרי הידע, ושינוי של דבר אחד בכל פעם.
אנחנו משתמשים ב-SEO-UP בכלי AI כחלק מתהליכי העבודה: מחקר מילות מפתח, בריפים לתוכן, ניתוח מתחרים ודוחות. אחד הדברים הראשונים שלמדנו הוא שתהליך AI הוא לא משהו שבונים פעם אחת ושוכחים ממנו. הוא דורש תחזוקה, בדיוק כמו אתר.
מה זה הקשר, ולמה הוא חשוב יותר מהפרומפט
הקשר הוא כל מה שהמודל קורא בזמן שהוא מבצע משימה. הפרומפט הוא רק חלק ממנו. מעבר לו, ההקשר כולל:
- קבצים ומסמכים שצירפתם.
- קובצי הנחיות ומיומנויות (skills) שהכלי טוען.
- הזיכרון של הכלי וההעדפות ששמר עליכם.
- ידע שמור ברמת הפרויקט.
- מה שכלים מחוברים מחזירים, למשל נתונים ממערכת מחקר מילות מפתח.
- מה שהועבר משלב קודם בתהליך.
- ההודעות הקודמות בשיחה ארוכה.
הרבה מהחומר הזה נטען בלי שביקשתם. לא כתבתם אותו בפרומפט ולא הפניתם אליו, ולכן אין רגע בתהליך שבו תחשבו לבדוק אותו. ניהול מכוון של החומר הזה הוא מה שנקרא הנדסת הקשר (Context Engineering). הבעיה היא שקל לעשות את זה פעם אחת, בזמן שבונים את התהליך, ולעולם לא לחזור לתחזוקה.
מה זה ריקבון הקשר
ריקבון הקשר הוא מה שקורה כשהחומר שהתהליך קורא מתיישן, בזמן שהתהליך עצמו נשאר אותו דבר. דוגמאות מוכרות:
- הוספתם או הורדתם שירות, וקובץ ההנחיות עדיין מתאר את ההצעה הישנה.
- הצוות התארגן מחדש או שינה את דרך העבודה.
- כלי מחובר שינה את המבנה או את הפורמט של הנתונים שהוא מחזיר.
- מדריך הסגנון עודכן, אבל הכללים הישנים עדיין נמצאים בקבצים.
- נוספו קבצים חדשים שסותרים את הקיימים.
- העברתם או שיניתם שם של קובץ, וההנחיות עדיין מפנות למיקום הישן.
אף אחד מהשינויים האלה לא מגיע לתהליך מעצמו, והתהליך ממשיך לקרוא את החומר הישן בכל הרצה.
שש צורות של ריקבון הקשר
| סוג | הסימפטום | מה בודקים קודם |
|---|---|---|
| עודף מידע | תוצרים כלליים שמדלגים על הוראות | כמה חומר המודל קיבל |
| תחרות | תוצרים לא עקביים | בין אילו כלים ותבניות הוא יכול לבחור |
| התפצלות | תשובה שונה לאותה בקשה | האם יש כמה עותקים של אותו קובץ |
| התיישנות | מידע שגוי שנאמר בביטחון | תאריכי קובצי הייחוס |
| סתירה | אי־דיוק עקבי | הוראות שסותרות זו את זו |
| זיהום | טעות שחוזרת בכל שלב | מה הועבר משלב קודם בלי בדיקה |
1. עודף מידע: תוצרים כלליים שמדלגים על הוראות
כשיש מול המודל יותר מדי חומר בבת אחת, התוצר נעשה מעורפל ומפספס הוראות שבוודאות כתובות בקובץ. נניח שתהליך הבריפים שלכם מושך את כל קובץ מילות המפתח לעמוד ואת שלושת עמודי המתחרים במלואם. הבריף חוזר עם 40 מילות מפתח בלי סדר עדיפויות, ומדלג על כלל הקישור הפנימי. שיחה ארוכה עושה אותו דבר: בבריף החמישי באותה שיחה, המודל קורא גם את ארבעת הקודמים.
הפתרון: מפרידים בין חילוץ לניתוח. בשיחה אחת מחלצים את מבנה הכותרות והטענות המרכזיות מעמודי המתחרים, ובשיחה נפרדת כותבים את הבריף מהסיכומים. מסננים את קובץ מילות המפתח מראש, ומתחילים כל בריף בשיחה חדשה.
2. תחרות: יותר מדי אפשרויות תקפות
כל אפשרות נכונה בפני עצמה, אבל הן הצטברו. אם מחוברים לכם שני כלים למחקר מילות מפתח, בריף אחד ימשוך את רמת הקושי מכלי אחד והבא מהכלי השני, עם מספרים שונים ובלי לציין מאיזה כלי. ואם יש שלוש תבניות בריף זמינות, המבנה ישתנה מהרצה להרצה.
הפתרון: מציינים במפורש בהנחיות באיזה כלי ובאיזו תבנית להשתמש, ומוחקים אפשרויות שכבר לא בשימוש.
3. התפצלות: עותקים שכבר לא תואמים
עדכנתם את תבנית הבריף, אבל דוגמאות הבריפים המצורפות עדיין בפורמט הישן, וגם העותק של התבנית שהדבקתם בידע של הפרויקט. הבריפים החדשים יוצאים עם ערבוב של שני המבנים.
הפתרון: כל חומר נשמר במקום אחד, וכל השאר מפנה אליו. כשמשנים כלל או פורמט, מעדכנים באותה ישיבה גם את הדוגמאות שנבנו ממנו. ואם חייבים עותקים, מוסיפים לכל אחד מספר גרסה או תאריך.
4. התיישנות: מידע שהיה נכון ונשאר בביטחון מלא
זה הסוג היקר ביותר, כי התוצר נשאר בטוח בעצמו וספציפי. הורדתם שירות ברבעון הקודם, אבל רשימת השירותים בהנחיות עדיין כוללת אותו. הבריפים ממליצים לקשר לעמוד שכבר מפנה לכתובת אחרת, ומציעים את השירות הישן בקריאה לפעולה.
הפתרון: כותבים את התאריך בתוך כל קובץ ייחוס, ולא רק בשם הקובץ. בודקים רשימות שירותים, רשימות מתחרים, פרופיל לקוח אידיאלי ומדריכי סגנון לפי לוח זמנים קבוע, ומעדכנים את רשימת השירותים באותו שבוע שבו השירות משתנה.
5. סתירה: שתי הוראות, ואף אחת לא מנצחת
ההנחיות אומרות לכתוב בריפים בפרוזה. לפני כמה חודשים אמרתם לכלי שאתם מעדיפים נקודות, וההעדפה הזו עדיין שמורה בזיכרון. הבריפים יוצאים בפרוזה עם קטעים של נקודות באמצע, משהו ששני המקורות לא ביקשו.
הפתרון: שואלים את הכלי מאיפה הגיעה ההוראה שהוא פעל לפיה. הוא יכול להפנות לקובץ ההנחיות, לידע של הפרויקט או לזיכרון. מתייחסים לתשובה כרמז ומאמתים אותה בקובץ עצמו. אחר כך מחליטים מה גובר ומוחקים את השני. וכשמוסיפים כלל חדש, מבקשים מהכלי לבדוק אותו מול מה שכבר קיים לפני ששומרים.
6. זיהום: טעות שהופכת לעובדה
שלב המחקר מעלה נתון על שיעור החיפושים המקומיים לשירות של הלקוח, ואף אחד לא בודק אותו. הבריף משתמש בו כדי להצדיק עמוד נחיתה מקומי, והטיוטה שנכתבת מהבריף חוזרת עליו בפתיח. כשהנתון מגיע ללקוח, הוא כבר חזר על עצמו מספיק פעמים כדי להיראות מבוסס.
הפתרון: מאמתים את התוצר של כל שלב לפני שהשלב הבא קורא אותו, ומריצים את בדיקת העובדות בשיחה חדשה שמכילה רק את הטענות ואת המקורות שלהן. בודק שרואה את הנימוקים של הבריף יודע למה אתם רוצים שהטענה תהיה נכונה, ונוטה יותר למצוא מקור שתומך במשהו קרוב. זה המקום להציב שער קשיח, כי זיהום מתפשט לכל מה שבא אחריו.
איך מאתרים ומתקנים ריקבון הקשר
- בוחרים את התהליך שמריצים הכי הרבה ומריצים אותו פעם אחת.
- בודקים מה הוא קרא: רוב הכלים מציגים כל צעד, כמו קובץ שנפתח, מיומנות שנטענה או כלי שהופעל. בכלי עבודה מבוססי שורת פקודה יש בדרך כלל פקודה שמציגה את כל מה שנטען להקשר, כולל קובצי זיכרון. ואת מה שלא מוצג, פשוט שואלים את הכלי.
- כותבים מה התהליך באמת צריך ומשווים בין שתי הרשימות.
- מתקנים במקור: מנקים את קובץ ההנחיות, מכבים מיומנויות שלא רלוונטיות למשימה, מוחקים מהזיכרון העדפות ישנות, משאירים גרסה אחת עדכנית ומתוארכת של כל קובץ ייחוס, ומוציאים טיוטות ישנות מתיקיות מחוברות.
- משנים דבר אחד בכל פעם, מריצים שוב ומשווים להרצה הקודמת. אם משנים כמה דברים יחד, תדעו אם התוצר השתפר, אבל לא תדעו מה השפיע.
תחזוקה קבועה
- סקירה רבעונית של קובצי ההנחיות, הידע של הפרויקטים, התיקיות המחוברות והזיכרון.
- סקירה חודשית של כל מה שמתאר איך פלטפורמת AI מתנהגת, כי זה משתנה הכי מהר.
- משימה מתוזמנת שמציגה רשימה של קובצי ייחוס שלא עודכנו ב-90 הימים האחרונים, כדי שהסקירה תתחיל מרשימה ולא מדף ריק.
כדי לקבל את התוצרים הטובים ביותר מכלי AI, כולנו צריכים להיות קצת מהנדסי הקשר. מי שמשלב את זה בשגרת העבודה ימשיך לקבל ערך מהכלים, גם כשהעסק, השירותים והכלים עצמם משתנים.
שאלות נפוצות
איך אדע אם הבעיה היא במודל או בהקשר?
אם אותו פרומפט עבד היטב לאורך כמה גרסאות של המודל ופתאום התוצרים נחלשו, הסבירות גבוהה שמשהו השתנה בהקשר: קובץ שהתיישן, העדפה שנשמרה בזיכרון או כלי שמחזיר נתונים אחרת.
כל כמה זמן לתחזק תהליכי AI?
מומלץ לבצע סקירה רבעונית של קובצי ההנחיות, הזיכרון ומאגרי הידע, וסקירה חודשית של מידע על התנהגות הפלטפורמות. ובנוסף, לעדכן מיד כל שינוי בשירותים, במחירים או בקהל היעד.
האם שיחה ארוכה עם כלי AI פוגעת באיכות?
כן, היא עלולה לפגוע. ככל שהשיחה מתארכת, המודל קורא גם את כל מה שקדם. לכן עדיף לפתוח שיחה חדשה לכל משימה, ולהעביר אליה רק את ההחלטות שעדיין רלוונטיות.
שאלות נפוצות
אם אותו פרומפט עבד היטב לאורך כמה גרסאות של המודל ופתאום התוצרים נחלשו, הסבירות גבוהה שמשהו השתנה בהקשר: קובץ שהתיישן, העדפה שנשמרה בזיכרון או כלי שמחזיר נתונים אחרת.
מומלץ לבצע סקירה רבעונית של קובצי ההנחיות, הזיכרון ומאגרי הידע, וסקירה חודשית של מידע על התנהגות הפלטפורמות. ובנוסף, לעדכן מיד כל שינוי בשירותים, במחירים או בקהל היעד.
כן, היא עלולה לפגוע. ככל שהשיחה מתארכת, המודל קורא גם את כל מה שקדם. לכן עדיף לפתוח שיחה חדשה לכל משימה, ולהעביר אליה רק את ההחלטות שעדיין רלוונטיות.
הקשר הוא כל מה שהמודל קורא בזמן שהוא מבצע משימה. הפרומפט הוא רק חלק ממנו. מעבר לו, ההקשר כולל:
- קבצים ומסמכים שצירפתם.
- קובצי הנחיות ומיומנויות (skills) שהכלי טוען.
- הזיכרון של הכלי וההעדפות ששמר עליכם.
- ידע שמור ברמת הפרויקט.
- מה שכלים מחוברים מחזירים, למשל נתונים ממערכת מחקר מילות מפתח.
- מה שהועבר משלב קודם בתהליך.
- ההודעות הקודמות בשיחה ארוכה.
הרבה מהחומר הזה נטען בלי שביקשתם. לא כתבתם אותו בפרומפט ולא הפניתם אליו, ולכן אין רגע בתהליך שבו תחשבו לבדוק אותו. ניהול מכוון של החומר הזה הוא מה שנקרא הנדסת הקשר (Context Engineering). הבעיה היא שקל לעשות את זה פעם אחת, בזמן שבונים את התהליך, ולעולם לא לחזור לתחזוקה.
ריקבון הקשר הוא מה שקורה כשהחומר שהתהליך קורא מתיישן, בזמן שהתהליך עצמו נשאר אותו דבר. דוגמאות מוכרות:
- הוספתם או הורדתם שירות, וקובץ ההנחיות עדיין מתאר את ההצעה הישנה.
- הצוות התארגן מחדש או שינה את דרך העבודה.
- כלי מחובר שינה את המבנה או את הפורמט של הנתונים שהוא מחזיר.
- מדריך הסגנון עודכן, אבל הכללים הישנים עדיין נמצאים בקבצים.
- נוספו קבצים חדשים שסותרים את הקיימים.
- העברתם או שיניתם שם של קובץ, וההנחיות עדיין מפנות למיקום הישן.
אף אחד מהשינויים האלה לא מגיע לתהליך מעצמו, והתהליך ממשיך לקרוא את החומר הישן בכל הרצה.
- בוחרים את התהליך שמריצים הכי הרבה
