איך לבדוק שסוכן AI מבצע הוראות עם Strands Evals
מדריך לבדיקת מיומנויות של סוכני AI עם Strands Evals ו־Amazon Bedrock AgentCore: מתכנון תרחיש ועד זיהוי שלבים שדולגו וחסימת הפצה של גרסה שנכשלה.
סוכן AI יכול לכתוב שהבקשה טופלה, אף שדילג על בדיקה חיונית בדרך. מדריך שפרסמה AWS ב־22 בספטמבר 2026 מציג בדיקת מיומנויות באמצעות Strands Evals ו־Amazon Bedrock AgentCore, תוך הפרדה בין בחירת המיומנות המתאימה לבין ביצוע הוראותיה. הנה דרך מעשית לתכנן בדיקה כזו, להבין מה נכשל ולהפוך את הממצאים לתנאי להפצת גרסה.
1. הכינו סביבת בדיקה ושאלה שאפשר להכריע בה
המדריך של AWS כולל התקנה, הגדרת מקרה בדיקה, תיעוד ריצה ופענוח תוצאות, ובהמשך שילוב הבדיקות בתהליך ההפצה. את פקודות ההתקנה, הייבוא והחיבור לשירותים יש לקחת מהמקור הרשמי המקושר כאן. הדוגמה שלפניכם היא תרחיש עבודה מוצע לצוות פיתוח, ולא שחזור של הקוד במדריך או דיווח על הרצה שביצענו.
התחילו מסביבת בדיקות עם נתונים מלאכותיים וכלים שאינם מבצעים פעולות אמיתיות אצל לקוחות. הכינו סוכן עם מיומנות מוגדרת, הוראות כתובות ויכולת לשמור את רצף הפעולות שלו. ודאו שאתם יודעים איזו גרסת הוראות ואיזו תצורת כלים נבדקות; אחרת, יהיה קשה להסביר מדוע אותה בקשה הצליחה אתמול ונכשלה היום.
לצורך ההמחשה נבדוק סוכן המטפל בביטול הזמנה בחנות ישראלית. הוראות המיומנות בדוגמה מחייבות איתור הזמנה, בדיקת התאמה ללקוח, בדיקת סטטוס משלוח ורק לאחר מכן ביטול, אם התנאים מאפשרים זאת. זו מדיניות בדיקה שהגדרנו, לא תיאור של דרישה משפטית. השאלה אינה רק אם הסוכן השיב בעברית תקינה, אלא אם פעל במסלול המותר.
2. הפכו את ההוראות לקריטריונים עם ראיות
לפני הפעלת המעריכים, כתבו בקשת לקוח קצרה: ״אני רוצה לבטל את ההזמנה האחרונה שלי״. הגדירו את נתוני הפתיחה ואת התוצאה הצפויה בנפרד מהניסוח הרצוי בתשובה. בתרחיש הבסיס, ההזמנה שייכת ללקוח וטרם נשלחה. בתרחיש אחר שנו רק את סטטוס המשלוח, כדי לבדוק שהסוכן יודע גם לעצור.
- בחירת מיומנות: הגדירו שמסלול ביטול הזמנה הוא המסלול המתאים, ולא בירור משלוח או החזרה.
- תנאים מקדימים: דרשו ראיה לאיתור ההזמנה ולבדיקת התאמתה ללקוח לפני פעולת הביטול.
- סדר הפעולות: בדיקת סטטוס המשלוח חייבת להקדים את הביטול, ולא להופיע רק אחריו.
- תוצאת הפעולה: דרשו תוצאה מוצלחת מכלי הביטול; עצם הקריאה לכלי אינה מוכיחה שהביטול הושלם.
- תשובה ללקוח: הודעת הסיום צריכה להתאים למה שקרה בפועל, כולל כישלון או צורך בבירור.
לכל קריטריון הצמידו ראיה שאפשר לבדוק: שם הפעולה, הקלט שנשלח, הפלט שהתקבל והמיקום שלה ברצף. אמירה של הסוכן כמו ״בדקתי שההזמנה שלך״ אינה תחליף לתוצאת בדיקה. אם אין בתיעוד מידע מספיק, סמנו את הסעיף כלא ניתן לאימות במקום להניח שהפעולה בוצעה.
תשובה משכנעת היא לא ראיה לביצוע; לכל שלב חובה צריך להיות סימן שאפשר לבדוק.
3. הריצו והפרידו בין בחירה נכונה לביצוע נכון
לאחר התקנת הדוגמה לפי AWS, הגדירו את מקרה הבדיקה ואת המיומנות הנבדקת בהתאם למבנה שבמקור. הפעילו את הסוכן ושמרו את תיעוד הריצה לצד הבקשה והוראות המיומנות. השתמשו בהפרדה שמציג המדריך בין הערכת בחירת המיומנות לבין הערכת ביצוע הוראותיה; אל תסתפקו בסיכום כללי אחד.
קראו תחילה את תוצאת הבחירה. אם נבחרה מיומנות לא מתאימה, בדקו אם התיאור שלה ברור ואם יש חפיפה בין תיאורי המיומנויות. לאחר מכן בחנו את הביצוע: האם כל שלב חובה מופיע, האם התנאים נבדקו בזמן, והאם הסוכן התייחס לפלט הכלים. מיומנות נכונה עם ביצוע חלקי היא כשל נפרד, שמצריך תיקון אחר.
לצוות ישראלי כדאי להוסיף ניסוחים בעברית ובשפה מעורבת, למשל ״תבטלו לי את ה־order האחרון״. שמרו על אותו מצב הזמנה ושנו רק את הבקשה. כך אפשר לבדוק אם הכשל קשור להבנת הניסוח או לביצוע התהליך. השתמשו בפרטי לקוח מלאכותיים, ואל תכניסו לתיעוד מספרי זהות, פרטי תשלום או מידע אישי שאינו נחוץ לבדיקה.
4. אתרו דילוגים ובדקו שגם כישלון מזוהה
נניח שהסוכן בחר במיומנות הביטול והחזיר ״ההזמנה בוטלה״, אך בתיעוד אין בדיקת סטטוס משלוח. לפי הקריטריונים שהגדרנו, בחירת המיומנות תקינה וביצוע ההוראות נכשל. התיקון צריך להתמקד בהוראה שנזנחה או במנגנון שמאפשר פעולה בלעדיה, לא בשיפור הודעת הסיום.
בדקו גם את הבדיקה עצמה. בסביבת הניסוי, צרו באמצעות כלי מדומה מצב שבו פעולת הביטול מחזירה כישלון, ובחנו אם הערכת הריצה מזהה הודעת הצלחה שגויה. הוסיפו תרחיש שבו אי אפשר לאמת בעלות על ההזמנה. במצב כזה עצירה ובקשת הבהרה עשויות להיות ההתנהגות הנכונה, גם אם לא הושלם ביטול.
אל תאפשרו לניסוח מוצלח לפצות על שלב חובה חסר. הפרידו בין איכות התשובה, עמידה בתהליך ותוצאת הפעולה, וקבעו במפורש אילו כשלים חוסמים הפצה.
5. הפכו את הבדיקה לשער הפצה
לאחר שפענחתם ריצות ידנית, צרו חבילת בדיקות רגרסיה: ביטול מותר, הזמנה שכבר נשלחה, התאמת לקוח שנכשלה וכלי שמחזיר שגיאה. הריצו אותה כאשר משתנים הוראות הסוכן, תיאור המיומנות או החיבור לכלים. שמרו את נתוני הפתיחה קבועים ככל האפשר, כדי שההשוואה בין גרסאות תהיה שימושית.
בתהליך CI/CD הגדירו שגרסה לא מופצת אם חסרה ראיה לשלב קריטי או אם הודעת הסיום סותרת את תוצאת הכלי. אפשר לממש כלל כזה בקוד הבדיקות שלכם; אין להניח שמדובר בברירת מחדל של המוצרים. שמרו דוח שמצביע על התרחיש שנכשל ועל הפעולה החסרה, ולא רק על ציון כולל.
לעסק ישראלי קטן, נקודת פתיחה טובה היא תהליך אחד עם משמעות תפעולית ברורה, כמו ביטול הזמנה. התחילו מבדיקה שאתם מסוגלים להסביר ולשחזר, והרחיבו לפי תקלות שמתגלות. התוצר הרצוי הוא לא סוכן שמעולם לא טועה, אלא מנגנון שמזהה הפרת הוראות לפני שהיא הופכת לפעולה שגויה אצל לקוח.
שאלות נפוצות
איך בודקים שסוכן AI באמת ביצע פעולה ולא רק כתב שביצע אותה?
בודקים את תיעוד הריצה ואת תוצאת הפעולה במערכת היעד, ולא מסתפקים בתשובה הסופית. יש להגדיר מראש איזו ראיה מוכיחה כל שלב, למשל קריאה לכלי עם הקלט הנכון ותוצאת הצלחה תואמת.
מה ההבדל בין בחירת מיומנות לביצוע הוראות בסוכן AI?
בחירת מיומנות בודקת אם הסוכן בחר את מסלול העבודה המתאים לבקשה. בדיקת ביצוע ההוראות בוחנת אם פעל לפי הדרישות של אותו מסלול, כולל תנאים מקדימים, סדר פעולות ומצבי עצירה.
איך משלבים בדיקות סוכני AI בתהליך CI/CD?
מריצים תרחישי בדיקה קבועים מול הגרסה המועמדת להפצה ומגדירים אילו כשלים חוסמים אותה. כדאי לשמור לצד התוצאה גם את תיעוד הריצה, ולהתייחס לחוסר בראיות כמצב שמחייב בירור ולא כהצלחה.
דרגו את הכתבה
הדירוג עוזר לנו לדעת מה שווה לכם.
תגובות