ככל שסוכני AI עוברים מפרוטוטיפים ניסיוניים ליישומים במציאות, היכולת להבין את התנהגותם, לעקוב אחרי ביצועיהם ולהעריך באופן מסודר את הפלטים שלהם נעשית חשובה.
לאחר שתסיימו את השיעור הזה, תוכלו לדעת/להבין:
המטרה היא להעניק לכם את הידע להפוך את הסוכנים שלכם מ”תיבת שחור” למערכות שקופות, ניתנות לניהול ואמינות.
הערה: חשוב לפרוס סוכני AI שהם בטוחים ואמינים. כדאי לעיין גם בשיעור Building Trustworthy AI Agents.
כלי קיימות כמו Langfuse או Microsoft Foundry בדרך כלל מציגים ריצות סוכן כמעקבים וקטעים.
ללא קיימות, סוכן AI יכול להרגיש כמו “תיבת שחור” – מצבו הפנימי והנימוקים שלו אטומים, מה שמקשה לאבחן בעיות או לאפיין ביצועים. עם קיימות, הסוכנים הופכים ל”תיבות זכוכית”, ומציעים שקיפות חיונית לבניית אמון ולהבטחת תפקוד בהתאם למיועד.
המעבר של סוכני AI לסביבות פרודקשן מביא עמו סט חדש של אתגרים ודרישות. קיימות היא כבר לא “נחמד שיהיה” אלא יכולת קריטית:
כדי לעקוב ולהבין את התנהגות הסוכן, יש לעקוב אחר מגוון מדדים ואותות. מדדים ספציפיים משתנים לפי מטרת הסוכן, אך כמה מהם אוניברסליים.
להלן כמה מהמדדים הנפוצים שכלי קיימות עוקבים אחריהם:
השהיה: כמה מהר הסוכן מגיב? זמני המתנה ארוכים פוגעים בחוויית המשתמש. מומלץ למדוד השהיה למשימות ולשלבים נפרדים באמצעות מעקב אחרי ריצות הסוכן. לדוגמה, סוכן שדורש 20 שניות לכל קריאות המודל יכול לזרז זאת באמצעות מודל מהיר יותר או ריצה מקבילה של הקריאות.
עלויות: מהו המחיר לכל ריצת סוכן? סוכני AI מסתמכים על קריאות LLM החויבות לפי טוקן או קריאות API חיצוניות. שימוש תכוף בכלים או פרומטים רבים יכול להעלות עלויות במהירות. לדוגמה, אם סוכן קורא ל-LLM חמש פעמים כדי לשפר את האיכות במעט, יש לבדוק אם העלות מוצדקת או שניתן להפחית את מספר הקריאות או להשתמש במודל זול יותר. ניטור בזמן אמת עוזר גם לזיהוי קפיצות לא צפויות (למשל, באגים שגורמים ללולאות API מיותרות).
שגיאות בבקשות: כמה בקשות נכשלו? זה יכול לכלול שגיאות API או קריאות כלי שלא צלחו. כדי להקשות על סוכן בפורדקשן, אפשר להגדיר פונקציות גיבוי או ניסיונות חוזרים. למשל: אם ספק LLM א’ לא פעיל, עוברים לספק LLM ב’ כגיבוי.
משוב משתמש: יישום הערכות משתמש ישירות מספק תובנות חשובות. זה יכול לכלול דירוג מפורש (👍לאאאאאאאאאאאאאאאאאאאאאאאאאאאאאאאאאאאאאאאאאאאאאאאאאאאאאאאאאאאאaugh/👎down, ⭐1-5 כוכבים) או תגובות טקסטואליות. משוב שלילי עקבי צריך להדליק נורה אדומה מכיוון שזהו סימן שהסוכן לא מתפקד כמצופה.
משוב משתמש מרומז: התנהגויות משתמש מספקות משוב עקיף גם ללא דירוג מפורש. זה יכול לכלול פרפראזת שאלות מידית, חזרה על שאלות או לחיצה על כפתור ניסיון חוזר. לדוגמה, אם משתמשים שואלים שוב ושוב את אותה שאלה, זה סימן שהסוכן אינו מתפקד כמצופה.
דיוק: כמה פעמים הסוכן מפיק פלט נכון או רצוי? הגדרות הדיוק משתנות (למשל, נכונות פתרון בעיות, דיוק שליפת מידע, שביעות רצון משתמש). השלב הראשון הוא להגדיר מה נחשב להצלחה עבור הסוכן שלכם. ניתן לעקוב אחרי הדיוק באמצעות בדיקות אוטומטיות, ציוני הערכה או תוויות סיום משימה. לדוגמה, לסמן מעקבים כ”מוצלחים” או “נכשלו”.
מדדי הערכה אוטומטית: ניתן גם להגדיר הערכות אוטומטיות. לדוגמה, להשתמש ב-LLM כדי לדרג את הפלט של הסוכן – האם הוא מועיל, מדויק או לא. קיימות מספר ספריות קוד פתוח שעוזרות לדרג היבטים שונים של הסוכן. לדוגמה, RAGAS לסוכני RAG או LLM Guard לזיהוי שפה מזיקה או הזרקת פרומפט.
בפועל, שילוב של מדדים אלה נותן את הכיסוי הטוב ביותר למצב הבריאותי של סוכן AI. בדוגמה מחברת הקוד בפרק הזה, נראה כיצד מדדים אלו נראים בדוגמאות ממשיות, אך קודם כל נלמד כיצד נראה תהליך הערכה טיפוסי.
כדי לאסוף נתוני מעקב, עליך לדרכן את הקוד שלך. המטרה היא לדרכן את קוד הסוכן כדי לשדר מעקבים ומדדים שניתן ללכוד, לעבד ולחזות אותם בפלטפורמת קיימות.
OpenTelemetry (OTel): OpenTelemetry הפכה לסטנדרט בתעשייה לקיימות LLM. היא מספקת ממשקי API, SDK וכלים ליצירה, איסוף וייצוא נתוני טלמטריה.
קיימות ספריות הדרכה רבות שעוטפות מסגרות סוכן קיימות וקל לשדר דרך OpenTelemetry קטעים לכלי קיימות. Microsoft Agent Framework משתלב באופן נייטיב עם OpenTelemetry. להלן דוגמה להדרכת סוכן MAF:
from agent_framework.observability import get_tracer, get_meter
tracer = get_tracer()
meter = get_meter()
with tracer.start_as_current_span("agent_run"):
# ביצוע הסוכן מתועד אוטומטית
pass
ה-מחברת הדוגמה בפרק זה תדגים כיצד להדר את סוכן MAF שלך.
יצירת קטעים ידנית: בעוד שספקיות הדרכה מספקות בסיס טוב, לעתים יש צורך בפרטים או מידע מותאם. ניתן ליצור קטעים ידנית כדי להוסיף לוגיקת יישום מותאמת. חשוב גם שניתן להעשיר קטעים שנוצרו באופן אוטומטי או ידני עם מאפיינים מותאמים (המכונים גם תגים או מטא-דטה). מאפיינים אלו יכולים לכלול נתוני עסק ספציפיים, חישובים ביניים או כל הקשר שיכול לסייע באיתור תקלות או אנליזה, כגון user_id, session_id או model_version.
דוגמה ליצירת מעקבים וקטעים ידנית עם Langfuse Python SDK:
from langfuse import get_client
langfuse = get_client()
span = langfuse.start_span(name="my-span")
span.end()
קיימות מספקת לנו מדדים, אך הערכה היא תהליך ניתוח נתונים אלה (וביצוע מבחנים) כדי לקבוע עד כמה סוכן AI מתפקד טוב וכיצד ניתן לשפרו. במילים אחרות, לאחר שיש לך את המעקבים והמדדים, כיצד תשתמש בהם כדי לשפוט את הסוכן ולקבל החלטות?
הערכת שגרה חשובה כי סוכני AI הם לעתים לא דטרמיניסטיים ויכולים להתפתח (דרך עדכונים או סטיות בתפקוד המודל) – ללא הערכה, לא תדע אם ה”סוכן החכם” באמת עושה את עבודתו טוב או אם התדרדר.
ישנן שתי קטגוריות של הערכות לסוכני AI: הערכה מקוונת ו-הערכה לא מקוונת. שתיהן חשובות ומשלימות זו את זו. בדרך כלל מתחילים מהערכה לא מקוונת, שכן זו הצעד המינימלי הדרוש לפני פריסת כל סוכן.

הערכה זו כוללת בדיקת הסוכן בסביבה מבוקרת, בדרך כלל באמצעות מערכי נתונים לבחינה, לא שאילתות משתמש חיות. משתמשים במערכים מדויקים שבהם יודעים מה פלט צפוי או התנהגות נכונה, ואז מפעילים את הסוכן עליהם.
לדוגמה, אם בניתם סוכן לפתירת בעיות מילוליות מתמטיות, ייתכן שיש לכם מערך מבחן של 100 בעיות עם תשובות ידועות. הערכה לא מקוונת נעשית בדרך כלל במהלך הפיתוח (ויכולה להיות חלק מצינורות CI/CD) כדי לבדוק שיפורים או למנוע הידרדרות. היתרון הוא שהיא ניתנת לחיבור מחדש ואתם מקבלים מדדי דיוק ברורים כי יש אמת קרקעית. אפשר גם לסמלץ שאלות משתמש ולמדוד את תגובות הסוכן מול תשובות אידיאליות או להשתמש במדדים אוטומטיים כפי שתואר למעלה.
האתגר המרכזי בהערכת לא מקוונת הוא להבטיח שמערך המבחן נרחב ועדכני – הסוכן עשוי להצליח היטב על מערך קבוע אך להיתקל בשאלות שונות בפרודקשן. לכן כדאי לעדכן מערכי מבחן עם מקרי קצה ודוגמאות המשקפות תרחישים אמיתיים. שילוב של מערכי “בדיקת עשן” קטנים וסטים גדולים יותר להערכה רחבה הוא שימושי: מערכים קטנים לבדיקות מהירות וסטים גדולים למדדים רחבים.

זו הערכה של הסוכן בסביבה חיה, בזמן שימוש אמיתי בפרודקשן. הערכה מקוונת כוללת ניטור ביצועי הסוכן על אינטראקציות משתמש אמיתיות וניתוח תוצאות באופן רציף.
לדוגמה, אפשר לעקוב אחר שיעורי הצלחה, ציוני שביעות רצון משתמש או מדדים אחרים בתעבורה חיה. היתרון של הערכה מקוונת הוא שהיא לתפוס דברים שאולי לא צפיתם בהם בסביבה מבוקרת – אפשר להבחין בהסטת מודל לאורך זמן (אם יעילות הסוכן יורדת כאשר דפוסי הקלט משתנים) ולתפוס שאילתות או מצבים לא צפויים שלא היו בנתוני המבחן. היא מספקת תמונה אמיתית כיצד הסוכן מתנהג בשטח.
הערכה מקוונת כוללת לעיתים איסוף משוב משתמש מפורש ומרומז, וייתכן ביצוע מבחני צל או מבחני A/B (שם גרסה חדשה של הסוכן פועלת במקביל להשוואה לגרסה הישנה). האתגר הוא שקשה לקבל תוויות אמינות לאינטראקציות חיות – יתכן וצריך להסתמך על משוב משתמש או מדדים משלמים (כמו האם המשתמש לחץ על התוצאה).
הערכות מקוונות ולא מקוונות אינן סותרות, הן משלימות זו את זו. תובנות מניטור מקוון (למשל, סוגי שאילתות משתמש חדשים בהם הסוכן מתפקד גרוע) משמשות להרחבת ושיפור מערכי מבחן לא מקוונים. לעומת זאת, סוכנים שיוצאים טוב במבחני לא מקוונים ניתנים לפריסה ומעקב בקונפידנס גבוהה יותר במקוון.
למעשה, צוותים רבים מקיימים מעגל:
להעריך לא מקוון -> לפרוס -> לנטר מקוון -> לאסוף מקרי כשל חדשים -> להוסיף למערך לא מקוון -> לדייק את הסוכן -> לחזור על התהליך.
כשתפרסו סוכני AI לפרודקשן, תיתקלו באתגרים שונים. הנה כמה בעיות נפוצות ופתרונות אפשריים:
| בעיה | פתרון פוטנציאלי |
|---|---|
| סוכן AI לא מבצע משימות בעקביות | - לחדד את הפרומפט שניתן לסוכן; להיות ברורים במטרות. - לזהות היכן חלוקת המשימות לתת-משימות והטיפול בהם על ידי סוכנים מרובים יכולה לעזור. |
| סוכן AI נכנס ללולאות רצופות | - להבטיח שיש תנאי סיום ברורים כך שהסוכן יודע מתי להפסיק את התהליך. - למשימות מורכבות הדורשות חשיבה ותכנון, להשתמש במודל גדול יותר המתמחה במשימות חשיבתיות. |
| קריאות לכלי של סוכן AI אינן מתפקדות טוב | - לבדוק ולאמת את פלט הכלי מחוץ למערכת הסוכן. - לחדד את הפרמטרים, הפרומטים ושמות הכלים. |
| מערכת Multi-Agent אינה מתפקדת בעקביות | - לחדד את הפרומטים הנתונים לכל סוכן כדי לוודא שהם ספציפיים ומובחנים זה מזה. - לבנות מערכת היררכית הכוללת “routing” או סוכן בקרה כדי לקבוע איזה סוכן הוא המתאים. |
רבים מהבעיות האלו אפשר לזהות ביתר יעילות עם מערכות קיימות במקום. המעקבים והמדדים שדיברנו עליהם קודם עוזרים לזהות במדויק היכן בזרימת העבודה יש בעיות, מה שהופך איתור תקלות ואופטימיזציה ליעילים בהרבה.
הנה כמה אסטרטגיות לניהול עלויות פריסת סוכני AI בייצור:
שימוש במודלים קטנים יותר: מודלים קטנים של שפה (SLMs) יכולים לבצע עבודה טובה במקרים מסוימים של שימוש סוכני ויקטינו עלויות משמעותית. כפי שהוזכר קודם, בניית מערכת הערכה לקביעת והשוואת ביצועים מול מודלים גדולים יותר היא הדרך הטובה ביותר להבין עד כמה SLM יתפקד היטב במקרה השימוש שלכם. שקלו להשתמש ב-SLM למשימות פשוטות יותר כמו סיווג כוונות או חילוץ פרמטרים, תוך שמירת מודלים גדולים למשימות חשיבה מורכבות.
שימוש במודל מיתוג: אסטרטגיה דומה היא להשתמש במגוון מודלים וגדלים. ניתן להשתמש ב-LLM/SLM או בפונקציה ללא שרת לניתוב בקשות בהתאם למורכבות למודלים המתאימים ביותר. זה גם יעזור להפחית עלויות וגם להבטיח ביצועים במשימות הנכונות. לדוגמה, ניתוב שאלות פשוטות למודלים קטנים ומהירים, ולהשתמש במודלים גדולים ויקרים רק למשימות חשיבה מורכבות.
שמירת תוצאות במטמון: זיהוי בקשות ומשימות נפוצות ומתן תגובות להן לפני שהן עוברות במערכת הסוכנית שלך היא דרך טובה להפחית את נפח הבקשות הדומות. ניתן אפילו ליישם תהליך לזיהוי רמת הדמיון בין בקשה לבקשות השמורות במטמון באמצעות מודלים בסיסיים יותר של AI. אסטרטגיה זו יכולה להפחית משמעותית עלויות עבור שאלות נפוצות או זרימות עבודה שכיחות.
בפנקס הדוגמא של החלק הזה, נראה דוגמאות לאופן שבו נוכל להשתמש בכלי נציפות כדי לנטר ולהעריך את הסוכן שלנו.
הצטרפו לדיסקורד Microsoft Foundry כדי לפגוש לומדים אחרים, להשתתף בשעות משרד ולקבל מענה לשאלותיך על סוכני AI.
הצהרת ביצוע:
מסמך זה תורגם באמצעות שירות תרגום בינה מלאכותית Co-op Translator. על אף שאנו שואפים לדיוק, יש לקחת בחשבון כי תרגומים אוטומטיים עלולים להכיל שגיאות או אי-דיוקים. יש להעדיף את המסמך המקורי בשפת המקור כמקור הסמכותי. למידע קריטי מומלץ להיעזר בתרגום מקצועי על ידי אדם. אנו לא נישא באחריות לכל אי-הבנה או פרשנות שגויה הנובעים משימוש בתרגום זה.