איך להעריך סוכני AI: מערכי בדיקה, מדרגים ובדיקות רגרסיה

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

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

מה פירוש הדבר להעריך סוכן AI?

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

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

ואם תשנו את הנחיית המערכת שלו כדי לתקן את הבעיה הזו, איך תדעו שלא יצרתם בעיה אחרת?

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

עם זאת, הערכת סוכן יכולה לבחון כמה היבטים של ריצה:

• איכות התוצאה הסופית
• המידע שהסוכן השתמש בו
• הכלים שהוא הפעיל
• האם הוא פעל לפי הכללים שמסדירים את התנהגותו

מדדים נפוצים להערכת סוכני AI

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

הנה רשימת המדדים הבסיסיים להערכת סוכני AI:

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

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

שלב 1: הגדירו איך נראית ריצה מוצלחת של סוכן

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

כך כדאי לגשת לזה, לדברי אנדריי חומוטוב, מדען הנתונים הבכיר שלנו:

„התחילו בשתי שאלות: „מה ייחשב כביצוע העבודה?” ו-„מה יהפוך ריצה שנראית מוצלחת לבלתי קבילה?”

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

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

„אני צופה שבחינת מסלול הביצוע תהפוך לחלק סטנדרטי בחבילות הערכה של סוכנים, ולא למשהו שאנחנו עושים רק כשתוצאה נראית חשודה”, הוא מוסיף.

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

שלב 2. בנו מערך בדיקות ממשימות וכשלים אמיתיים

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

המל חוסיין, מהנדס ML ב-Parlance Lab, ושרייה שנקר, חוקרת מערכות ML והערכות AI יישומי, ממליצים להתחיל בניתוח שגיאות, טכניקה שמקורה בלמידת מכונה ובמדעי הנתונים. התהליך מתחיל בניתוח איכותני של עקבות הביצוע של הסוכן — רשומות שמציגות את הקלט של המשתמש, את הקריאות לכלים, את המידע שאוחזר ואת הפלט של הסוכן.

1. סקרו עקבות בודדות והוסיפו הערות לשגיאות (קידוד פתוח). בקשו ממומחה תחום לבחון ריצות של הסוכן ולכתוב תצפיות קצרות על מה שהשתבש. התמקדו בשגיאה המשמעותית הראשונה.
2. קבצו תצפיות לדפוסי כשל (קידוד צירי). כשיש לכם מספיק הערות, השתמשו ב-LLM כדי להציע קטגוריות לשגיאות דומות. אלה יכולות לכלול המלצות על חלקים לא תואמים, אחזור לא מדויק של נתוני מלאי והעברות כושלות לגורם אנושי.
3. ספרו את המופעים. שייכו כל תצפית לקטגוריה, ואז השתמשו בגיליון אלקטרוני או בטבלת ציר כדי לחשב באיזו תדירות מופיע כל דפוס כשל.
4. קבעו סדרי עדיפויות לטיפול, תוך התחשבות גם בתדירות וגם בחומרה.
5. הפכו כשלים חשובים למקרי בדיקה. שמרו את הקלט הרלוונטי, את תנאי הפתיחה, את התוצאה הצפויה ואת קריטריוני הדירוג, כדי שאפשר יהיה לבדוק את הסוכן שוב מול אותו תרחיש.

כמה עקבות כדאי לבחון? בערך 100, אבל אין מספר קסם. עצרו מוקדם ברגע שאתם מגיעים לרוויה תאורטית: הנקודה שבה סקירת עקבות נוספות מפסיקה לחשוף דפוסי כשל חדשים ומשמעותיים.

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

השימוש במדדי ייחוס בהערכת סוכני AI

מעבר ליצירת מקרי בדיקה משלכם, אפשר להשתמש באוספים קיימים של משימות הערכה סטנדרטיות, המכונים מדדי ייחוס (benchmarks), כדי להעריך את היכולות של הסוכן.

אבל מדדי ייחוס אינם חסינים מטעויות. ביקורות של SWE-bench, סקירות מדדי הייחוס של Epoch AI ותשובות נכונות שנדחו בתחילה ב-TheoPhysEval ממחישות כיצד משימות או תשובות צפויות פגומות עלולות לעוות את תוצאות ההערכה.

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

שלב 3. הריצו את הסוכן בסביבת בדיקה הניתנת לשחזור

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

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

הגדלה

כדי להגדיר סביבת בדיקה הניתנת לשחזור, בצעו את השלבים הבאים:

1. שמרו קלטים מייצגים. אחסנו אירועים אמיתיים או מקרי בדיקה באותו מבנה שהאפליקציה שלכם מקבלת בסביבת הפרודקשן. בתרחיש שלנו, תשמרו כקובץ JSON בקשת תחזוקה שמכילה את מזהה המכונה, את חלק החילוף הנדרש ואת תאריך התחזוקה, יחד עם תמונת מצב של נתוני המלאי והחלקים המאושרים.
2. הריצו את תהליך העבודה. העבירו כל קלט דרך הסוכן, כולל שלבי האחזור, הקריאות לכלים ויצירת התגובה.
3. תעדו את התוצאה ואת עקבות הביצוע. שמרו את הפלט הסופי ואת פעולות הביניים הרלוונטיות (כמו חיפושים במלאי), כדי שתוכלו לראות לא רק אם הסוכן נכשל, אלא גם היכן.
4. חזרו על מקרים בהתאם לחומרת הכשל, לתדירותו ולקושי לתקן את הבעיה. אפליקציות LLM הן לא דטרמיניסטיות (הן יכולות להפיק תוצאות שונות מקלטים זהים), ולכן ריצה מוצלחת אחת אינה מבטיחה שגם הבאה תצליח. דווחו על שיעור הניסיונות המוצלחים ובחנו את הכשלים.

לשם כך, חומוטוב ממליץ למדוד pass@1 (באיזו תדירות הסוכן מצליח בניסיון יחיד) ו-pass@k (ההסתברות להצליח לפחות פעם אחת במספר מוגדר של ניסיונות). אם אתם מדווחים על pass@k, ציינו את מספר הניסיונות, כי הפקת תשובה נכונה אחת מתוך כמה אינה אומרת שהסוכן יודע איזו מהן לבחור.

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

שלב 4. בחרו את המדרג המתאים לכל בדיקה

מדרג (grader, שלעיתים קרובות נקרא גם מעריך או evaluator) הוא מנגנון — קטע קוד, LLM שמונחה על ידי מחוון דירוג, או סוקר אנושי — שבודק את הפלט או הפעולה של הסוכן מול קריטריון מוגדר. מדרג מחזיר שיפוט של עובר/נכשל והסבר שמצביע על הראיות הרלוונטיות.

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

סוג המדרג המתאים תלוי במה שאתם מנסים לאמת. כך משתוות שלוש הגישות זו לזו:

לפעמים היבטים שונים של אותה ריצה דורשים שיטות הערכה שונות, ולכן ייתכן שתצטרכו לשלב בין מדרגים.

איך משלבים בין מדרגים?

שואלים: „האם אפשר לאמת את התוצאה מול כלל ידוע או ערך צפוי, או שנדרש שיקול דעת דמוי־אנושי?”

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

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

כיילו את מדרג ה-LLM מול שיפוטים אנושיים.

בעיקרו של דבר, כיול מחייב מומחה תחום שיעריך ריצות אמיתיות של הסוכן. לאחר מכן המומחה משווה את השיפוטים שלו לאלה של ה-LLM ומשפר את מחוון הדירוג על סמך אי־ההסכמות.

הנה תהליך כיול מדרג בן חמישה שלבים:

1. אספו דוגמאות של קלטים, פלטים ועקבות רלוונטיות של הסוכן.
2. בקשו ממומחה תחום להעריך באופן עצמאי אם כל דוגמה עומדת בקריטריון ההערכה.
3. הריצו את מדרג ה-LLM על הדוגמאות האלה.
4. השוו בין השיפוטים של האדם לאלה של המודל.
5. בדקו את אי־ההסכמות ושפרו את המחוון של המדרג לפני שתבדקו אותו על דוגמאות חדשות.

חומוטוב מדגיש גם את החשיבות של בדיקת העקביות של מדרג ה-LLM בנפרד:

„תנו לו את אותה ריצה שמורה ואת אותם קבצים בדיוק כמה פעמים, בלי להריץ את הסוכן מחדש. כך אפשר להפריד בין שונות בעבודת הסוכן לבין שונות בדירוג.”

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

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

שלב 5. השוו בין גרסאות והריצו בדיקות רגרסיה

נניח שניתוח השגיאות מגלה שסוכן המלאי שלכם ממליץ לעיתים קרובות על חלקי חילוף שאינם מאושרים. אתם משנים את הנחיית המערכת שלו כך שתחייב בדיקת תאימות מפורשת. המקרה שנכשל במקור עובר עכשיו. אבל איך תדעו שהשינוי לא השפיע על משימות אחרות?

כאן נכנסות לתמונה בדיקות רגרסיה.

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

1. שחזרו את הכשל המקורי באמצעות קלט שמור ממערך הבדיקות.
2. בצעו שינוי ממוקד בהנחיה, במודל או בתהליך העבודה.
3. הריצו מחדש את הבדיקה שנכשלה כדי לבדוק אם הבעיה נפתרה.
4. הריצו את שאר הבדיקות כדי לוודא שהשינוי לא פגע בהתנהגות שעבדה בהצלחה בעבר.
5. בדקו את התוצאות וחקרו כל כשל חדש.

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

שלב 6: ניטור ביצועי סוכן ה-AI בסביבת הייצור

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

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

התהליך הוא איטרטיבי וכולל ארבע פעילויות משלימות:

• הריצו שופטי LLM מכוילים על עקבות ביצוע מסביבת הייצור. דגמו אינטראקציות אמיתיות של הסוכן והחילו עליהן את המעריכים שכבר תיקפתם מול שיפוט אנושי.
• עקבו אחר שיעורי הכשל לאורך זמן. השתמשו בקטגוריות הכשל שהוגדרו במהלך ניתוח השגיאות כדי לכמת בעיות חוזרות.
• המשיכו לסקור עקבות ביצוע באופן ידני. מדרגים אוטומטיים מזהים רק את הבעיות שהם תוכננו לזהות. בדקו ידנית דגימות של אינטראקציות אמיתיות של הסוכן כדי לחשוף שגיאות חדשות או בקשות משתמש חריגות.
• השתמשו בבדיקות A/B כדי למדוד תוצאות עסקיות (רק כשהדבר מתאים). השוו בין פרומפטים, מודלים או תהליכי עבודה שונים באמצעות מדדים כמו השלמת משימות, שביעות רצון משתמשים וזמן עד לפתרון. התהליך עוזר לקבוע אם שינוי משפר את חוויית המוצר בפועל, מעבר להצלחה בבדיקות בודדות.

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

תפיסות שגויות נפוצות בהערכת סוכני AI

• הערכות הן פשוט בדיקות יחידה. ממש לא; בדיקות יחידה הן בדיקות אוטומטיות קטנות שמהוות רק חלק אחד מההערכה. הערכות כוללות גם ניתוח שגיאות איכותני, שיפוט אנושי, ניטור סביבת הייצור וניסויים למדידת איכות האפליקציה.
• פלטפורמת הערכה יכולה לעשות הכול בשבילכם. כלים מוכנים מהמדף יכולים להפוך חלק מהבדיקות לאוטומטיות, אבל הם לא יכולים לקבוע אילו מצבי כשל (סוגי שגיאות או התנהגויות לא רצויות של הסוכן) חשובים למוצר שלכם.
• אפשר לתת ל-LLM להעריך הכול. זוהי טעות גדולה. ניתוח שגיאות בהובלה אנושית וכיול המדרגים נותרים חיוניים, מכיוון שלמודלי LLM חסר ההקשר העסקי הדרוש כדי לגלות כל בעיה.
• בדיקות A/B או פשוט שימוש בסוכן מחליפים הערכות. לא נכון. בדיקות A/B יכולות להראות איזו גרסה מניבה ביצועים טובים יותר לפי מדדים נבחרים, אבל הן לא יכולות, בפני עצמן, להסביר את מקור הבעיות.

שאלות נפוצות על הערכת סוכני AI

1. מה ההבדל בין הערכת סוכני AI להערכת LLM?

הערכת LLM מודדת עד כמה היטב מודל שפה מבצע משימה נתונה, כמו מענה על שאלה, סיכום מסמך או חילוץ מידע. הערכת סוכני AI בוחנת מערכת שמבצעת באופן עצמאי מספר שלבים כדי להשלים משימה.

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

2. מדדים מרכזיים להערכת סוכני AI

מדדי ההערכה של סוכני AI מתחלקים לשתי קטגוריות עיקריות:

• מדדי ביצועים טכניים: שיעור הצלחה במשימות, נכונות הפעולות, איכות התשובות, אמינות (pass@1 ו-pass@k), זמן השהיה, שימוש בטוקנים ועלות לכל משימה מוצלחת.
• מדדים עסקיים ומדדי חוויית משתמש: שביעות רצון לקוחות (CSAT), שיעור פתרון פניות, שיעור הסלמה, שיעור המרה, זמן השלמת משימה ותוצאות נוספות הספציפיות לתפקיד הסוכן.

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

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

3. מהם הכלים הטובים ביותר להערכת סוכני AI?

אפשרויות נפוצות כוללות:

• מסגרות בדיקה: טענות assert ב-Python ו-pytest שימושיות להרצת מקרי בדיקה שניתנים לשחזור ולבדיקת תנאים מדויקים, למשל אם הסוכן בחר בכלי הנכון או החזיר מזהה רכיב תקין.
• מסגרות להערכת סוכני AI: DeepEval וערכת הכלים agent-eval של Google תומכות בהערכות מורכבות יותר, כולל עקבות ביצוע, מדרגים מבוססי LLM ובדיקות רגרסיה אוטומטיות.
• פלטפורמות הערכה וניטור (observability): LangSmith, Arize Phoenix ו-MLflow עוזרות לצוותים לבחון את התנהגות הסוכן, לנהל מערכי נתונים להערכה, להשוות בין גרסאות של הסוכן ולנטר ביצועים בסביבת הייצור.

4. איך הופכים הערכות של סוכני AI לאוטומטיות?

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

1. צרו מערך נתונים להערכה: אספו משימות משתמש מייצגות, תוצאות צפויות, כשלים ידועים ועקבות ביצוע של הסוכן. כללו מקרי קצה כמו קריאות לכלים שנכשלו, מידע חסר ופעולות לא מורשות.
2. הפכו את הרצת הבדיקות ואת מתן הציונים לאוטומטיים: השתמשו במסגרות כמו pytest או DeepEval כדי להריץ מקרי בדיקה ולהחיל בדיקות מבוססות קוד או מדרגי LLM. אמתו את מדרגי ה-LLM מול שיפוט אנושי לפני שאתם מסתמכים על הציונים שלהם.
3. שלבו הערכות בתהליכי CI/CD: הריצו מחדש באופן אוטומטי בדיקות רגרסיה בכל פעם שמפתחים מעדכנים את הפרומפטים, המודלים, הכלים או תהליך העבודה של הסוכן. השוו את התוצאות לגרסת הבסיס וקבעו ספי איכות שמונעים שחרור גרסאות כאשר בדיקות קריטיות נכשלות.
4. החילו מדרגים מכוילים על עקבות ביצוע שנדגמו מסביבת הייצור, עקבו אחר שיעורי הכשל ומדדי ביצועים נוספים, וחקרו שגיאות חדשות באמצעות סקירה ידנית.