מודלי שפה גדולים נתקעים כשמבקשים מהם לעשות יותר מדי בבת אחת. זרקו קובץ PDF בן חמישים עמודים לחלון הצ'אט ובקשו ניתוח מובנה, הערכת סיכונים וסיכום מנהלים בנשימה אחת. התוצאה היא בדרך כלל דלה, מבולבלת או שגויה לחלוטין. גישה טובה יותר היא מכנית. פצלו את העבודה לשלבים נפרדים. הזינו את הפלט של השלב הראשון ישירות לשלב השני, וכן הלאה. Anthropic מכנה את התבנית הזו prompt chaining. Google מתייחסת אליה כאל sequential pipeline. שני השמות מתארים את אותו הדבר: קו ייצור שבו כל תחנה מטפלת בטרנספורמציה ספציפית אחת.

איך זה נראה בפועל

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

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

בנו שערים, לא ניחושים

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

שער אינו קריאה למודל. זהו קוד פשוט. אתם כותבים סקריפט קצר שרץ בין השלבים. הוא עשוי לבדוק את אורך הפלט כדי לוודא שהוא אינו ריק. הוא עשוי להריץ אימות סכימת JSON (JSON schema validation) כדי לוודא שהמפתחות תואמים למה ששלב שלוש מצפה לו. בדיקת regex יכולה לוודא שכתובת אימייל או שדה תאריך אכן קיימים לפני שהפרומפט הבא נבנה בכלל. זה עוצר שגיאות לפני שאתם מבזבזים כסף על פלטים גרועים. שער עולה מיקרו-שניות של חישוב. קריאה כושלת של LLM בהמשך השרשרת עולה טוקנים, זמן תגובה (latency) והשפיות שלכם.

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

מתי לשרשר, ומתי להפסיק

prompt chaining אינו מתאים לכל בעיה. השתמשו בו כאשר לעבודה יש שלבים קבועים וניתנים לחזרה. דוחות כספיים חודשיים, סקירת חוזים סטנדרטית וצינורות (pipelines) של ניתוח לוגים הם דוגמאות טובות. אם אתם יכולים לכתוב את ההליך כרשימת תיוג, כנראה שתוכלו לשרשר אותו. כדאי להשתמש בשרשור גם כשאתם זקוקים לדיוק גבוה בעבודה מורכבת. פירוק בעיה לשלבים מאלץ את המודל לטפל בשכבה לוגית אחת בכל פעם. לבסוף, קל יותר לדבג שרשראות מאשר פרומפטים מונוליטיים. כשהסיכום שגוי, אתם בודקים את החילוץ. כשהחילוץ שגוי, אתם בודקים את הטקסט המקור. יש לכם תוצרי ביניים לבדיקה.

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

מלכודת הנוקשות

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

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