פיתוח מערכת בקרת איכות לכוח עבודה של סוכני AI

בקרת איכות של סוכני AI: היכן התהליך נשבר

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

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

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

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

כיצד אנו מודדים התנהגות של סוכנים: מדדים וסטים של אמות מידה

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

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

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

רשימת בדיקה שלפיה הסוכן מאושר למוצר:

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

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

השוואת מצבי בדיקה של סוכנים: הרצות, סימון, היברידי

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

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

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

שלבי הטמעה: מביקורת הבדיקות הקיימות ועד למסירה

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

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

מה נשאר אצלכם: קונפיגורציות, סכמות ותקנוני בדיקות

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

• קונפיגורציות בדיקות — היכן מוגדרים ספים, תנאי עצירת שחרור וכללי השוואת גרסאות של הסוכן. משתנות במקום אחד, מיושמות על כל הזרימות בבת אחת.
• סכמות של זרימות נתונים — המסלול מבקשת המשתמש ועד לפסק הדין של הבודק: היכן נשמרות התשובות, היכן אמת המידה, באיזה שלב מתחבר ניתוח ידני.
• תקנון סימון — מה נחשב לתשובה נכונה, כיצד להכריע במקרים שנויים במחלוקת וכמה בודקים עוברים על אותו מדגם. בלעדיו שיעור ההסכמה בין המסמנים יורד כבר בשבוע השני.
• סטים של אמות מידה — דוגמאות מקובעות עם הערכות מוסכמות. עליהם מושוות גרסאות באופן ניתן לשחזור: רואים מה השתפר ומה הידרדר.
• תיעוד מדדים — כיצד מחושבת כל величина, מאין מגיעים הנתונים ואיזו סטייה נחשבת להפעלה ולא לרעש.
• הוראות לצוות — מה עושה הבודק בעת פער, למי יש זכות לשנות כלל והיכן נרשם החריג.
• יומן אירועים וסדר ניתוח — מקרים שבהם הבדיקה החמיצה שגיאה מנותחים והופכים לכלל חדש או לדוגמה בסט אמות המידה.
• סדר שחרור גרסה חדשה — הרצה על סט אמות מידה, אישור לפי מדדים, סדר חזרה לקונפיגורציה הקודמת.

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

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

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

מה הראו המדידות לפני ההטמעה

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

מה שינינו ומה התקבל

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

שיעור התשובות הנכונות עלה מ-78% ל-94%, והמחלקה "מועד החזרה שגוי" נעלמה לחלוטין — 0 פגיעות מתוך 240 תרחישים ו-0 בזרימת הפניות במהלך החודש הבא. כיסוי ענפי הדיאלוג הובא לשלמות לפי הסימון, והקטיעה בשלב ההבהרה חדלה לחזור.

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

במה הרצת צל נבדלת מבדיקת רגרסיה?

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

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

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

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

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

ספקות טכניים נפוצים לפני תחילת העבודה

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

הגישה לתשתית מוגבלת, סביבת הבדיקות סגורה

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

יש לנו כבר מערך פרוס — לא תשברו אותו?

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

אין סימון — לאסוף אמות מידה מאפס?

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

נדון במשימה שלכם ונחזור עם הערכה ותוכנית

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

כדי שההערכה תהיה עניינית ולא "לפי תחושות", נדרש סט מינימלי של נתוני פתיחה:

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

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