ארכיטקטורת מערכות LLM – על Agentic Workflows

בפוסט הקודם, ארכיטקטורת מערכות LLM – אבני היסוד, ראינו כיצד אפשר בעזרת RAG ו Prompt Engineering לבנות על גבי LLM גנרי מגוון פונקציות מעבר לפונקציית ה Chat. לעתים, אלו פונקציות שיהיה מאתגר מאוד לממש באופן אחר. ראינו כיצד Tools use (או Tools Architecture) מצליח למתן (mitigate) אזורים בהם LLM אינו מוצלח.

בפוסט הזה נראה כיצד ניתן להשתמש במודלי הדור הבא (GPT 5.0 או Claude 4.0, בזמן כתיבת הפוסט) כבר היום, בעזרת Patterns הנקראים Agentic Workflows.

המודלים של הדור הבא לא באמת זמינים היום (ואין לבלוג קומבינות עם OpenAI או Anthropic), אלא ש Agentic Workflows מאפשרים למודלים הקיימים להגיע לביצועים משופרים – שהם בסדר גודל של הביצועים של דור אחד קדימה של מודלי LLM. היתרון הזה מגיע גם בעלויות גבוהות יותר, הדומות לעלויות של דור אחד קדימה – ומכאן נגזר התיאור ״להשתמש במודלי הדור-הבא, היום״.

ישנן שמועות, למשל, שמודל GPT-o1 של OpenAI הוא בעיקר מימוש פנימי של Agentic Workflows על גבי מודל GPT-4, ולא מודל חדש שאומן מאפס. אני לא יודע אם זה נכון, אבל זה אפשרי.

ניתן לראות בתרשים כיצד GPT-3.5 מצליח להגיע לביצועים טובים יותר מ GPT-4 בעזרת Agentic Workflows, וכיצד GPT-4 מצליח גם הוא לשפר ביצועים משופרים בעזרתם.

את הדפוס של Tools Use כיסינו כבר בפוסט הקודם.
בפוסט הזה נכסה את כל שאר ה Agentic Worfklows, ואת Conversational Memory.

רגע של אנגלית: Agentic איננה מילה תקנית באנגלית. ביטוי מקובל למערכת AI כיום הוא ״AI Agent״ (״סוכן חכם״), ומכאן המילה Agentic כמשהו שקשור ל Agent (AI).

Reflection

מי שעובד הרבה עם מודלי LLM אולי מכיר את ההתנהגות הבאה:

משתמש :שואל שאלה כלשהי.
ChatGPT: <תשובה>
התשובה מרגישה למשתמש קצת משונה..
משתמש: ״אתה בטוח ש…״
ChatGPT: אני מתנצל על הבלבול. בעצם <תשובה נכונה יותר>…

נתקלתם בזה? סיכוי טוב שכן. הדפוס הזה גרם לחוקרים לנסות ולבדוק האם כשמבקשים מ LLM לשפר את תשובותיו, הוא יצליח לעשות זאת? התשובה היא שהרבה פעמים כן, ומשם נולד דפוס ה Reflection. הרעיון הוא לקחת Prompt של משתמש, ולהריץ אותו בכמה איטרציות (להלן Nested Chat) מול ה LLM כדי להגיע לתשובה מדויקת יותר. בדוגמה הבאה לקוח נטפל בשאלה של משתמש מתי הביטוח שלו מכסה תאונות שנגרמו משריפה.

User (external) Prompt: “When am I covered for fire incidents?”

Nested Chat:
  Internal Prompt 1: “When am I covered for fire incidents?”
  Internal Response 1: "Generally, coverage for fire incidents 
    is included in standard homeowners or renters insurance
    policies from the start date of the policy. However, 
    specific details case like … cannot be covered"

  Internal Prompt 2: "Check carefully { Internal Response1 } for correctness. 
    and give constructive criticism for how to improve it".
  Internal Response 2: "<feedback>"

  Internal Prompt 3: "improve your answer based on <feedback>"
  Internal Response 3: "<improved answer>"

Response to user (external): { Internal Response 3 }

כלומר: סדר פעולות של:

1. שאלה
2. בקשה לאתגור
3. בקשה להתייחס לאתגור

יכול להוביל מודלי LLM לספק תשובות מדויקות יותר.
המחיר: קראנו ל LLM שלוש פעמים במקום פעם אחת – מה שמעלה לנו את זמן ביצוע ועלות חישוב.

אם ה LLM מגיב היטב לבקשה לבדוק את עצמו, מדוע לעשות זאת בשלוש איטרציות? מדוע לא לבקש ב Prompt כבר מראש ״חשוב מה עשוי להיות לא מדויק בתשובה – ותקן בהתאם״, או נוסח דומה?

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

באלו מקרים מתאים דפוס ה Reflection? – כאשר אנחנו רוצים לשפר את רמת הדיוק של התשובה.
דוגמה: GPT-4 becomes 30% more accurate when asked to critique itself
האם מובטחת הצלחה? כמו כל דבר בעולם ה LLM – בוודאי שלא. בוודאי ישנם מקרים בהם Reflection יפחית את דיוק התוצאה. זהו כלי בעל פוטנציאל, אבל עליכם לנסות ולבדוק מתי הוא עובד – וזה באחריותכם.
סה״כ כלי ה Reflection נחשב לדפוס יציב שקל להשיג בו תוצאות טובות. Reflection ו Tools Use הם הדפוסים בעלי שיעורי ההצלחה הגבוהים יותר והעקביים יותר.

Planning

Planning הוא דפוס העוזר ל LLM לשפר ביצועים במשימות מורכבות, לעתים מאפיינים את המשימות הללו כמשימות הדורשות "Reasoning״. גם אופן הפעולה שלו, בדומה לדפוס של ה Reflection – הוא דיי אינטואיטיבי.
גם כאן, נפעיל סדרה של קריאות פנימיות למודל (Nested Chat) כדי לקבל תוצאה טובה יותר.

User (external) Prompt: "Please suggest how thick an iron bridge should be in order to safely support <certain traffic>. 
The bridge properties are..."

<we recognize this request may be complex, and decide to activate the planning workflow>

Nested Chat:
  Internal Prompt 1: Given the user prompt, identify the key steps required to solve the problem. Break these into small, 
    logical steps, each achievable independently. Then, determine the optimal order of execution for these steps.
  Internal Response 1: Here is the <list of steps> 
    // e.g. 1: Define a structural formula for bridge strength, considering the material (iron) and design. 
    // 2. Estimate the total load based on the specified traffic properties. 
    // 3. Combine the results of Steps 1 and 2 to calculate the required material thickness to safely support the load.

  Internal Prompt 2: Execute step 1 suggested above
  Internal Response 2: <...>

  Internal Prompt 3: Execute step 2 suggested above, use response of step 1
  Internal Response 3: <...>

  Internal Prompt 4: Execute step 3 suggested above, use response of steps 1 and 2.
  Internal Response 4: <...>

  Internal Prompt 5: Combine the results from all steps to produce a final, coherent response to the original user query.
  Internal Response 5: <combined answer>

User response: <combined answer>

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

דפוס ה Planning משתלב יפה עם דפוס ה Tools Use בו למודל אין מספיק נתונים בכדי לסיים את המשימה, או שיש שלבים ש LLM באופן טבעי פחות מוצלח בהם. השימוש בכלים חיצוניים (גישה למאגי נתונים, שימוש במנוע חישוב ״דטרמיניסטי״) יכולים לעזור להגעה לתשובה נכונה ומדויקת.

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

הערה חשובה: הדוגמה למעלה הייתה לצורך המחשה. איני ממליץ, בשלב זה, לבנות גשר על בסיס חישוב של LLM, וללא ביקורת מעמיקה של מהנדס אנושי.

גיוון מודלים

לפני שנעבור לדפוסים הבאים, אני רוצה לעצור לרגע ולדבר על גיוון מודלים. לכאורה, אם אני משיג תוצאות טובות בעזרת GPT-4, למשל – למה שלא אשתמש בו תמיד, לכל הצרכים? להלן, ״לא מחליפים סוס מנצח״.

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

1. עלויות – קריאה למודל LLM היא יקרה, ככל שהמודל גדול יותר. העלות היא גם כספית וגם ב Latency. בהפעלת Agentic Workflows אנו מבצעים מספר קריאות ל LLM עבור כל בקשה של המשתמש – מה שגורם לעלויות (הגבוהות גם כך) לעלות באופן ניכר. אם נוכל לבצע חלק מהקריאות למודל קטן וזול יותר (פרקטי במיוחד ב Tool Use) – נוכל לחסוך עלויות ולהיות יעילים יותר.
   • בחודשים האחרונים יש שיח רב מסביב ל״מודלים קטנים״, בעיקר בשל ההבנה שהמשך התקדמות על בסיס מודלים גדולים יותר ויותר – אינה sustainable לרוב היישומים.
2. התמחות – מודלים שונים טובים יותר במשימות שונות. למשל, אומרים ש PaLM2 מוצלח יותר בהסבר של קטע קוד, בעוד GPT-4 מוצלח יותר בזיהוי באגים בקוד. שימוש במודל המתאים יותר למשימה – היא דרך לשפר ביצועים.
   • כיום ההבדלים בהתמחות בין המודלים הנפוצים אינם הבדלים דרמטים. יש סברה שעם הזמן והצורך להתבדל – זה ישתנה. כמו כן, ההנחה היא שעם הזמן נראה מודלים שנבנו למטרות ספציפיות ולא General Purpose כמו היום.
3. השלמה הדדית – יש טענה ששילוב בין מודלים שונים למשימות שונות, מביאות לתוצאות טובות יותר משימוש במודל יחיד.
   ב Reflection, למשל, מדווחים על שיפורי ביצועים כאשר משתמשים במודל שונה בשלב הביקורת (שלב 2) מאשר המודל לשאר השלבים. למשל: שילוב בין GPT ל Claude.

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

• ייתכן יידרשו אופטימיזציה שונה ב Prompt Engineering ו RAG על מנת להשיג תוצאות מיטביות ממודלים שונים.
• מודלים שונים לרוב דורשים Encoding שונה – מכאן שלאותם נתונים ייתכן ותצטרכו לעשות Encoding מספר פעמים למגוון המודלים שאתם עובדים איתם (עבור Knoledge bases, למשל).

Multi-Agent Collaboration

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

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

לאחר שראינו שגיוון מודלים עובד. נניח ב Reflection יש לנו תוצאות טובות יותר כאשר מודל B מאתגר ומבקר את מודל A – ננסה לקחת את העקרון הזה קדימה.

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

באופן דומה, ננסה להשתמש ב Agents שונים עם הגדרות שונות (context) על מנת לכוון אותם טוב יותר למשימות שונות. ההכוונה היא בבסיסה הוראות שונות ב Prompt (למשל: ״אתה מבקר קפדן המתמחה בזיהוי תקלות תכנון…״). האם זה תמיד עובד? בוודאי שלא, אבל יש מספיק נסיונות שמצביעים שזה לפעמים עובד.

ניקח את ההכוונה עוד צעד אחד קדימה, ונספק למודל B גם גישה לנתונים מתאימים יותר (נניח, כ RAG או Tool Use). ייתכן ומודל B יצליח להשתמש ולשלב את הנתונים הללו בצורה יותר טובה בשלב הביקורת, מאשר יכול היה מודל A להשתמש בו בשלב התכנון.

מכאן אנחנו מגיעים למודל בו אנחנו מחלקים את המערכת שלנו ל Agents שכל אחד בעל תחום התמחות מוגדר. הוא מקבל את ה Prompt/Context המתאים, והזרקה של נתונים (RAG) או כלים (Tools Use) המתאימים לתפקיד שלו. לבסוף – ייתכן ונתאים ל Agents שונים מודלי LLM שונים המתאימים יותר לצרכים. מכיוון שכולם מדברים בשפה משותפת (טקסט אנושי) – ניתן לבקש מהם להיעזר אחד בשני.

לב העניין אם כן הוא יצירת Agents או תצורות שונות של הפעלת LLM למשימות שונות. הדפוס של Multi-Agent Collaboration יכול להיות מיושם מצוין גם על גבי מודל יחיד.

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

בצד המעשי, מניסיון קצר למדי, אני יכול לומר שתכנון מערכת Multi-Agent מוסיפה הרבה סיבוכיות למערכת, ולא הייתי רץ לממש אותה, אלא כדי לנסות לשפר מערכת פשוטה יותר שלא עובדת טוב מספיק.

כמו בדפוס ה Planning, דפוס ה Multi-Agent הוא יותר רעיון לחקור ולהתנסות בו, מאשר ״דפוס ליישום מיידי״.

Conversational Memory

הדפוס הזה לא כלול ברשימה ״המקורית״ של ה Agentic Workflows, אבל הוא עדיין דפוס פופולרי.

דפוס ה Conversational Memory נועד ליצור חווית שיחה עם LLM שהיא דומה יותר לחוויה אנושית. למשל להימנע מהתסריט הבא:

משתמש: היי דוקטור

דוקטור (Agent): יום נפלא! מה שלומך? מה שלום הילדים או האשה?

משתמש: עדיין כואב הגב. כואב מאוד.

דוקטור (Agent): אוי, אני מצטער לשמוע. האם הרמת חפץ כבד או עשית תנועה חדה לאחרונה?

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

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

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

דוקטור (Agent): אהה. אז אולי….

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

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

הרעיון הוא שנשמור memory של שיחות שהיו למשתמש עם ה LLM, בכדי להשתמש בזיכרונות הללו כ context לשיחות עתידיות על מנת לאפשר ל LLM להגיב טוב יותר למשתמש. הנה כמה עקרונות / רעיונות:

• נחזיק Storage (להלן ״Memory״) ששומר פרטים משיחות קודמות עם המשתמש.
• לשמור את כל השיחות יגרור context גדול מדי (= איבוד Attention) – ולכן:
  • נזהה מקטעים משמעותיים במיוחד בשיחה – ונשמור רק אותם (בד״כ: בעזרת מודל קטן ומותאם).
  • נבצע סיכום של המקטעים הללו – על מנת לצמצם את ה context ולהיות יעילים וממוקדים יותר (בד״כ: בעזרת מודל קטן).
• בעת שיחה חדשה, נזהה נושאים שדיברנו עליהם בעבר, ונטען באופן דינמי ל Context סיכומים של מקטעים משמעותיים רלוונטיים משיחות עבר. זה ממש סוג של RAG כאשר ההבדל העיקרי הוא שהמאגר ממנו שולפים נתונים הוא ספציפי למשתמש, ולא משותף.
• על מנת שהזיכרונות יישארו יעילים ורלוונטיים לשימוש, יש לרוב מנגנון ״שכחה״ שמסיר זיכרונות ישנים לאחר פרק זמן, או אם יש עדכון חדש יותר שסותר את הנאמר בזיכרון הישן.

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

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

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

סיכום

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

אני מקווה שהפוסט הזה הצליח לחשוף אתכם בצורה רלוונטית ופוקחת עיניים ל Workflows הללו – גם אם לא סיפקתי תשובות (שאין לי) לשאלות רבות שצצות.

צצים לאחרונה גם לא מעט Frameworks המסייעים ליישם את ה Workflows הללו. אפשר לציין את Dify, את AutoGen של מייקרוסופט, Flowise.AI או Swarm של OpenAI, יש ויהיו כמובן עוד. נזכור שמה שחשוב הוא לא כל-כך ה Framework אלא ההבנה את ה Workflow ומה ההיגיון מאחוריו.

נ.ב. באופן לא ממש מפתיע, פייטון היא השפה הדומיננטית בתחום הזה – וזה נקודה לקחת בחשבון.

שיהיה בהצלחה!