מה זה שרשור-פרומפטים: רצף קבוע, לא החלטה-דינמית
שרשור-פרומפטים (Prompt Chaining) הוא טכניקה לבניית מערכות-AI שמפרקת משימה מורכבת-מדי לקריאה-בודדת-למודל, לרצף-שלבים קבוע-מראש: פלט-הקריאה-הראשונה מוזן כקלט לקריאה-השנייה, וכן הלאה, עד שהתוצאה-הסופית מוכנה. בניגוד לסוכן-AI שמחליט-בעצמו כמה צעדים לבצע ואילו, בשרשור-פרומפטים מי שבנה את המערכת קבע מראש את מספר-השלבים ואת תוכנם המדויק — לכן זו נחשבת ל"תהליך-עבודה" (Workflow), לא ל"סוכן" במובן המלא, גם כשהיא מיושמת באמצעות מודל-שפה בכל שלב. תוספת נפוצה ומומלצת: "שער" (Gate) תוכנתי בין שלב לשלב — בדיקה פשוטה שמוודאת שהפלט של השלב הקודם עומד בקריטריון מוגדר, לפני שהוא מוזן הלאה, כדי לתפוס טעות מוקדם ולא לתת לה להצטבר לאורך כל השרשרת. היתרון המרכזי של הגישה הוא פשוט: קריאת-מודל שמתמקדת במשימה צרה-אחת נוטה להצליח בה יותר מקריאה-אחת שמתבקשת לבצע כמה משימות-שונות בבת-אחת, גם אם המחיר הוא זמן-ריצה כולל ארוך-יותר, כי צריך להמתין לכמה תשובות ברצף במקום לתשובה אחת. יתרון-נוסף, פחות מדובר אך משמעותי בפרקטיקה: כל שלב בשרשרת אפשר לבנות עם הוראות-מערכת (System Prompt) שונות, ואפילו עם מודל-שפה שונה — למשל, מודל זול-ומהיר לשלב-החילוץ הפשוט, ומודל יקר-ומדויק-יותר רק לשלב-הניסוח-הסופי — מה שמאפשר לשלוט בעלות הכוללת של המערכת, ולא רק באיכותה.
המקור: "בניית סוכנים יעילים" של Anthropic, דצמבר 2024
המקור המוביל למונח, בצורתו-הנוכחית ובהקשר-בניית-הסוכנים, הוא מאמר שפרסמה Anthropic (מפתחת Claude) ב-19 בדצמבר 2024, בשם "Building Effective Agents" ("בניית סוכנים יעילים"). המאמר מגדיר הבחנה מרכזית בין "תהליכי-עבודה" (Workflows) — מערכות שבהן מודלים-וכלים מתוזמרים דרך נתיבי-קוד קבועים-מראש — לבין "סוכנים" (Agents) במובן-המלא, שבהם המודל עצמו מכוון-דינמית את התהליך ואת השימוש-בכלים. שרשור-פרומפטים הוא הראשון מבין חמש תבניות-תהליך-עבודה שהמאמר מתאר, ולפי הגדרתו-שם, מתאים במיוחד "כשניתן לפרק את המשימה בנקל ובבירור לתת-משימות קבועות" — המחיר הוא זמן-ריצה-כולל-ארוך-יותר, אבל התמורה היא דיוק גבוה-יותר בכל שלב, כי כל קריאה מתמקדת במשימה צרה-ומוגדרת-יותר במקום בכל הבעיה בבת-אחת. ארבע התבניות-הנוספות שהמאמר מתאר אחרי שרשור-פרומפטים ממחישות עד כמה המשפחה הזו רחבה: "ניתוב" (Routing) מסווג קלט ומכוון אותו למשימת-המשך מותאמת; "הרצה-מקבילית" (Parallelization) מריצה כמה קריאות-מודל בו-זמנית — פיצול-משנה או הצבעה בין כמה תשובות — ומאחדת את התוצאות; "תזמור-עובדים" (Orchestrator-workers) נותנת למודל-מרכזי-אחד לפרק משימה ולחלק אותה למודלים-מבצעים בעצמו, כך שתת-המשימות אינן קבועות-מראש אלא נקבעות דינמית לפי הקלט הספציפי; ו"הערכה-ואופטימיזציה" (Evaluator-optimizer) מריצה מודל-אחד שמייצר תשובה, ומודל-שני שמבקר אותה בלולאה חוזרת, עד שהאיכות מספקת. שרשור-פרומפטים הוא הפשוטה והנוקשה מביניהן — בדיוק בגלל זה היא גם המתאימה-ביותר כשהמשימה עצמה קבועה וידועה-מראש. המאמר עצמו ממליץ להתחיל תמיד מהתבנית הפשוטה-ביותר שמספיקה למשימה, ולעבור לתבנית-מורכבת-יותר רק כשהיא באמת נדרשת — עצה שחוזרת אצל מהנדסים רבים שבנו מערכות-סוכן בפועל: מערכת מורכבת-מדי-מדי-מוקדם קשה יותר לנפות-שגיאות ולתחזק מאשר שרשרת-פשוטה שעושה בדיוק את מה שצריך.
דוגמה מהמאמר: מתווה-מסמך ואישור-איכות באמצע
המאמר עצמו נותן שתי דוגמאות מוחשיות לשימוש-מתאים בשרשור-פרומפטים. הראשונה: כתיבת-תוכן-שיווקי בשלב-אחד, ואז תרגומו לשפה אחרת בשלב-נפרד — שני שלבים נפרדים-לגמרי, שכל אחד מהם קל-יחסית כמשימה-בודדת, אבל קשה לבצע-בו-זמנית באיכות-גבוהה בקריאה-אחת. השנייה, מורכבת-יותר: כתיבת-מתווה (Outline) למסמך ארוך בשלב-ראשון; בדיקה תוכנתית שהמתווה עומד בקריטריונים-מוגדרים-מראש בשלב-שני — זהו ה"שער" שהוזכר קודם; וכתיבת-המסמך-המלא על בסיס המתווה-המאושר בשלב-שלישי. אם הבדיקה בשלב-השני נכשלת, המערכת יכולה לחזור-אחורה ולבקש מתווה-מתוקן, במקום להמשיך לבזבז-משאבים על כתיבת-מסמך-שלם שנשען על תשתית-פגומה. דוגמה שלישית, נפוצה-לא-פחות בפרקטיקה: מענה-על-שאלה בתוך מסמך ארוך, בשני שלבים — קריאה-ראשונה שמחלצת רק את הציטוטים-הרלוונטיים-לשאלה מתוך המסמך, ואז קריאה-שנייה שמקבלת את הציטוטים-שחולצו (לא את המסמך המלא) ומנסחת מהם תשובה שלמה. הפרדת "מציאת-המידע-הרלוונטי" מ"ניסוח-התשובה" לשני שלבים נפרדים משפרת גם שקיפות (אפשר לבדוק אילו ציטוטים נבחרו) וגם ניפוי-שגיאות, כי טעות אפשר לאתר בשלב הספציפי שבו היא קרתה.
שורשים אקדמיים קודמים: "AI Chains", 2021
הרעיון-הבסיסי — חיבור פלט-קריאה-אחת לקלט-קריאה-הבאה — קדם למאמר של Anthropic בכשלוש שנים. מאמר-מחקר אקדמי בשם "AI Chains: Transparent and Controllable Human-AI Interaction by Chaining Large Language Model Prompts", מאת חוקרים מקבוצת PAIR (People + AI Research) של Google ומאוניברסיטת וושינגטון, שהוגש לראשונה באוקטובר 2021 והוצג בכנס CHI ב-2022, כבר טבע במפורש את הרעיון: "אנו מציגים את הרעיון של שרשור-צעדי-מודל-שפה זה-לזה, כשפלט-של-שלב-אחד הופך לקלט-של-השלב-הבא, ובכך צוברים את התרומה של כל שלב" (מתוך תקציר-המאמר). המאמר גם טוען, כבר אז, שגישת-השרשור "נתפסת כשקופה ובת-שליטה יותר" מהרצה-בודדת-וסגורה של מודל-שפה על כל המשימה בבת-אחת — בדיוק הטיעון שחוזר, בניסוח-שונה-מעט, במאמר של Anthropic שלוש שנים אחר-כך. מה שהשתנה בין 2021 ל-2024 הוא בעיקר ההקשר: המאמר האקדמי-המוקדם התמקד בכלי-ממשק-אנושי-בינה-מלאכותית שקוף-יותר, למען חוקרי-חוויית-משתמש; מאמר Anthropic מיקם את אותו הרעיון-בדיוק כאבן-הבניין הראשונה בתוך משפחה שלמה של חמש תבניות לבניית מערכות-סוכן-AI מודרניות, למען מהנדסי-תוכנה שבונים מוצרים בפועל.
היישום בפועל: LangChain ומסגרות-פיתוח אחרות
כלי-פיתוח פופולריים למערכות-מבוססות-LLM הפכו את שרשור-הפרומפטים ליכולת-מובנית, לא רק לתבנית-תיאורטית. LangChain, אחת ממסגרות-הפיתוח הנפוצות ביותר לבניית-אפליקציות-סביב-מודלי-שפה, מציעה מנגנון "שרשראות" (Chains) מובנה: PromptTemplate מגדיר תבנית-פרומפט-לשימוש-חוזר עם משתני-קלט, LLMChain בונה שרשרת-משימה-בודדת שמחברת תבנית-כזו למודל-שפה ספציפי, ו-SequentialChain מחברת כמה שרשראות-כאלה לתהליך-עבודה יחיד, כשהפלט של כל שרשרת מוזן אוטומטית, דרך מפתח-פלט מתויג, כקלט לשרשרת-הבאה. דוגמה מוחשית מתיעוד-הכלי: שרשרת-ראשונה מחלצת מילות-מפתח מטקסט קלט, שרשרת-שנייה מנתחת את הסנטימנט של אותן מילות-מפתח, ושרשרת-שלישית מנסחת-מחדש את התוצאה — שלושה שלבים נפרדים, כל אחד עם תפקיד-צר-ומוגדר, ושמות-פלט מתויגים שמונעים בלבול לגבי מה בדיוק זורם לאן. מסגרות-פיתוח מתחרות (למשל LlamaIndex, שמתמחה יותר בחיפוש-במסמכים) מציעות מנגנוני-שרשור דומים-ברוח, אם לא זהים-בפרטים הטכניים. הפיכת-הרעיון לרכיב-ספרייה-מוכן, ולא רק לתיאור-ארכיטקטוני, היא חלק מהותי מהסיבה ששרשור-פרומפטים הפך לדפוס-הנפוץ-ביותר בבניית-מערכות-AI מעשיות: לא צריך לתכנן-מאפס את לוגיקת-ההזנה-בין-שלבים בכל פרויקט חדש, אלא רק להגדיר את השלבים ואת סדרם.
את התשתית הזאת פיתח במקור הריסון צ'ייס (Harrison Chase): לפי הבלוג הרשמי של החברה, LangChain יצאה לדרך כחבילת-פייתון פשוטה בת כ-800 שורות-קוד בלבד, בסתיו 2022. מאז, הפרויקט גדל לכדי חברה עצמאית; באוקטובר 2025 הודיעה LangChain על גיוס-מימון בהיקף 125 מיליון דולר, לפי שווי-חברה של 1.25 מיליארד דולר — קפיצה משמעותית מנקודת-הפתיחה שלה כחבילת-קוד-פתוח קטנה.
מתי לא להשתמש בו: מול סוכן דינמי ומול מחקר-עמוק
שרשור-פרומפטים מתאים דווקא כשהמשימה ידועה-מראש ובעלת-מבנה-קבוע — לא כשהיא דורשת גמישות-החלטה-בזמן-אמת. כשהצעדים הנדרשים משתנים ממשימה-למשימה, ואי-אפשר לדעת-מראש כמה שלבים יידרשו, דפוס-שרשור-קשיח נשבר: אין בו מנגנון להוסיף-שלב בלתי-צפוי, או לדלג-על-שלב-שהתברר-כמיותר, או לחזור-אחורה-רחוק-יותר משלב אחד. הדוגמה הברורה-ביותר לניגוד היא "מחקר עמוק" (Deep Research) — סוכן שמבצע גם-הוא רצף-קריאות-מודל, אבל מחליט-בעצמו, בזמן-אמת, כמה סבבי-חיפוש להריץ ומה לחפש בכל סבב, בהתאם למה שכבר גילה; מספר-הצעדים שם משתנה מהרצה-להרצה, בעוד ששרשור-פרומפטים תמיד עובר את אותו מספר-שלבים-קבוע, בדיוק כפי שתוכנן. הבחירה בין השניים היא, בסופו-של-דבר, שאלה של ודאות: ככל שיודעים מראש טוב-יותר איך בדיוק המשימה אמורה להיפתר, שרשור-פרומפטים נותן שליטה, יציבות-תוצאות וקלות-ניפוי-שגיאות רבה-יותר מסוכן-דינמי — במחיר הגמישות שהסוכן-הדינמי כן מציע. גם מאמר Anthropic עצמו ממסגר את הבחירה באותם מונחים בדיוק: "התחילו בפרומפטים פשוטים, שפרו אותם באמצעות הערכה מקיפה, והוסיפו מערכות-סוכן-רב-שלביות רק כשפתרונות-פשוטים-יותר אינם מספיקים" — כלומר, שרשור-פרומפטים הוא לרוב תחנת-הביניים הראשונה בדרך למערכת-סוכן-מלאה, לא הפתרון-הסופי לכל בעיה. מי שבונה מערכת-AI חדשה, לפי אותה-עצה, עדיף שיתחיל תמיד משאלת-הבדיקה הפשוטה-ביותר: האם פרומפט-בודד, בלי שרשור ובלי סוכן, כבר פותר את הבעיה מספיק-טוב? רק כשהתשובה היא לא, שווה לעבור לתבנית-מורכבת-יותר.
מגבלה: שגיאות מצטברות לאורך השרשרת
למרות היתרונות, לשרשור-פרומפטים יש מחיר-סמוי שהמאמר של Anthropic עצמו אינו דן בו: כל שלב בשרשרת נושא סיכוי-משלו לטעות, וכשפלט שגוי מוזן כקלט לשלב-הבא, הטעות אינה נעצרת אלא מצטברת. מאמר-ניתוח של חברת-הבינה-המלאכותית Wand AI מנסח זאת כך: "כל שלב בשרשרת-נימוק נושא הסתברות מסוימת לטעות, שיכולה בסופו-של-דבר לפסול את התשובה כולה". תיאור-נוסף, מתוך כתיבה-טכנית פרקטית על בניית-שרשראות בפועל, ממשיל את התהליך למשחק "טלפון שבור": בלי מנגנון-שחזור-משגיאות מובנה בתוך התהליך, "שגיאות מצטברות לכדי פלטים משונים-ומשונים-יותר" ככל שהשרשרת מתקדמת. זו הסיבה המעשית שבגללה מנגנון ה"שער" התוכנתי בין שלבים, שהוזכר קודם, אינו רק שיפור-איכות אופציונלי אלא הגנה ממשית מפני הצטברות-שגיאות שקטה — כל שלב נוסף בשרשרת הוא, במקביל ליתרון-הדיוק שלו, גם הזדמנות-נוספת לכשל שלא ייתפס עד לתוצאה הסופית.