כיצד לבדוק סוכני AI עמוקים לפני הפריסה לייצור
בדיקת התנהגות סוכני AI לפני פריסה לסביבת ייצור היא אחת הבעיות הקשות ביותר בתחום. AWS ו-LangChain פרסמו מדריך מעשי המשלב חמישה תבניות הערכה לסוכנים עמוקים, תוך שימוש ב-LangSmith ו-Amazon Bedrock, ומדגים כיצד לעבור מבדיקות פיתוח למעקב שוטף בסביבת ייצור.
בדיקת סוכני AI: מדוע הגישה המסורתית לא מספיקה
סוכני AI מציבים אתגר ייחודי: הם אינם דטרמיניסטיים, פועלים בשלבים מרובים, וטעות בשלב מוקדם יכולה להשפיע על כל שרשרת הביצוע. בניגוד לבדיקת קריאה בודדת ל-LLM, הערכת סוכן מחייבת חשיבה שונה לגמרי.
רוצה להישאר מעודכן ב-AI?
הירשם לדיוור השבועי שלנו וקבל עדכונים, המלצות על כלים, חדשות ודוחות מיוחדים
AWS ו-LangChain פרסמו מדריך טכני מפורט המשלב ניסיון מעשי מפיתוח ארבעה יישומים על בסיס ארכיטקטורת סוכנים עמוקים. המדריך בנוי סביב סוכן text-to-SQL הפועל על Amazon Bedrock עם מודל Amazon Nova 2 Lite.
שלושת מקורות הקושי בהערכת סוכנים
יש שלושה גורמים מרכזיים המבדילים הערכת סוכנים מהערכת LLM רגיל:
אי-דטרמיניזם - אותה משימה עשויה להצליח ב-90% מהמקרים ולכשול ב-10% הנותרים. ציון בינארי יחיד אינו מספר את הסיפור האמיתי. שתי מטריקות עוזרות: pass@k מודד את ההסתברות להצלחה אחת לפחות מתוך k ניסיונות, ו-pass^k מודד את ההסתברות שכל k הניסיונות יצליחו.
התפשטות שגיאות - בסוכן רב-שלבי, טעות בשלב השלישי מתגלגלת לכל השלבים הבאים. סוכן שמזהה שגוי את ה-schema בתחילת הריצה יבנה JOIN שגוי ויגיע לתוצאה לא נכונה.
פתרונות יצירתיים - מודלים מתקדמים מוצאים לפעמים גישות חוקיות שמעצבי הבדיקות לא צפו מראש.
חמישה תבניות הערכה מרכזיות
המדריך מגדיר חמישה תבניות שאפשר ליישם על כל סוכן:
תבנית 1 - לוגיקת בדיקה מותאמת אישית לכל נקודת נתונים: לא כל שאלה נבדקת באותה שיטה. שאלה עם תשובה מספרית מדויקת ("כמה לקוחות מקנדה?") נבדקת עם grader קודי פשוט. שאלה אנליטית מורכבת דורשת LLM-as-judge.
תבנית 2 - בדיקות צעד בודד: אלו הן בדיקות יחידה של סוכנים. האם הסוכן קרא לכלי הנכון בתגובה הראשונה? בדיקות אלו מהירות, ממוקדות, ויעילות בצריכת טוקנים.
תבנית 3 - ריצה מלאה מקצה לקצה: בדיקת כל המסלול - ממשימת הכניסה ועד לתשובה הסופית. חשוב לבדוק שכלים מסוימים הופיעו במסלול, אך לא לדרוש סדר ריצה מדויק.
תבנית 4 - שיחות רב-תורניות: בדיקת תרחישים שבהם שאלת המשך מתבססת על תשובה קודמת. הפתרון הוא לוגיקה מותנית בקוד הבדיקה - אם תור ראשון כשל, הבדיקה נכשלת מוקדם.
תבנית 5 - בדיקות בטיחות ומצב: ודא שהסוכן לא מבצע פקודות DML (INSERT, UPDATE, DELETE) על בסיס הנתונים, ושהתשובות מהותיות ולא ריקות.
שלושה סוגי graders: מתי להשתמש בכל אחד
הגישה המעשית משלבת שלושה סוגים:
graders קוד - דטרמיניסטיים, מהירים וזולים. מתאימים לכל מקרה שאפשר לבטא בקוד: בדיקת קיום כלי, string matching, ספירת טוקנים.
graders מבוססי LLM - גמישים, מתאימים לתשובות פתוחות שהפורמט שלהן משתנה. דורשים כיול מול שופטים אנושיים.
שופטים אנושיים - הסטנדרט הגבוה ביותר לאיכות סובייקטיבית, אך יקרים ואיטיים. השימוש בהם צריך להיות ממוקד: כיול graders אוטומטיים ובדיקות ספוט תקופתיות.
מעבר מפיתוח לייצור: מה משתנה
כל הבדיקות שתוארו עד כאן הן offline - הן רצות לפני פריסה, על מערכי נתונים מוגדרים. בייצור המצב שונה: אין reference outputs, משתמשים שואלים שאלות שלא ציפיתם להן, ובסיס הנתונים משתנה.
LangSmith תומך ב-online evaluators שרצים אוטומטית על traces מייצור, ללא פריסת קוד נוסף. שלושה סוגים מרכזיים:
בדיקת בטיחות SQL - פונקציה דטרמיניסטית שסורקת כל trace ומוודאת שלא בוצעו פקודות DML. אחוז הדגימה: 100%.
איכות תשובה עם LLM-as-judge - מדרג כל trace על ממדים של נכונות, בהירות והשלמיות. אחוז הדגימה מומלץ: 50%, לשליטה בעלויות.
ציון איכות מורכב - ממוצע משוקלל של כל הציונים: בטיחות (משקל 0.4), נכונות (0.3), בהירות ושלמיות (0.15 כל אחד). מאפשר הגדרת alerting כאשר האיכות יורדת מתחת לסף.
המשמעות לצוותי פיתוח בישראל
חברות ישראליות רבות שבונות סוכני AI - בין אם ב-fintech, ב-cybersecurity או בפתרונות ארגוניים - עומדות בדיוק בפני האתגר הזה: איך לדעת שהסוכן עובד כמו שצריך לפני שהוא פוגש לקוחות אמיתיים. המסגרת שמציגים AWS ו-LangChain נותנת תשובה מובנית לשאלה הזו.
הקוד המלא זמין במאגר לדוגמה של AWS, ומחייב חשבון AWS עם גישה ל-Amazon Bedrock, חשבון LangSmith, ו-Python 3.12 ומעלה.