כשמאפיינים פיצ׳ר עם רכיב AI, קריטריון הקבלה מפסיק להיות "בהינתן X המערכת מחזירה Y". קריטריון הקבלה הופך להיות eval: מערך נתונים מתויג, פונקציית ניקוד, וסף שהמערכת חייבת לעבור לפני העלייה לאוויר ובכל פעם מחדש אחרי כל החלפת מודל או שינוי פרומפט. הכלל הפשוט: אם אי אפשר לכתוב את ה-eval, הפיצ׳ר עדיין לא מאופיין. המאמר הזה מפרט את ארבעת המרכיבים של קריטריון קבלה הסתברותי ואיך כותבים אותם בפועל.
מה בדיוק נשבר במסמך האפיון המסורתי
אפיון קלאסי נשען על הנחה אחת: אותו קלט מייצר תמיד אותו פלט. כל מבנה הבדיקות, ההגדרות ותנאי הסיום נגזר ממנה. ברגע שרכיב במערכת הוא מודל שפה, ההנחה קורסת, ואיתה קורסים כל הכלים שנשענו עליה.
הביטוי הכי מוחשי לזה הוא בדיקת הקבלה. "המשתמש לוחץ שלח ומקבל סיכום של הפנייה" היא לא דרישה ניתנת לבדיקה, כי אין לה תשובה נכונה יחידה. שני סיכומים שונים יכולים שניהם להיות מצוינים, ושלישי, שנראה דומה, יכול להיות שגוי לחלוטין. מה שנדרש הוא הגדרה של טווח התנהגות מקובל ולא של תוצאה יחידה.
המבחן שחוסך חודשי פיתוח: לפני שכותבים שורת קוד, נסו לנסח את ה-eval. אם אתם לא מצליחים להגדיר מה נחשב תשובה טובה ואיך מודדים אותה, סימן שהדרישה עדיין מעורפלת. פיצ׳רים שנתקעים בפיילוט כמעט תמיד נכשלים בשלב הזה, לא בשלב המימוש.
ארבעת המרכיבים של קריטריון קבלה לפיצ׳ר AI
| מרכיב | מה הוא מגדיר | דוגמה |
|---|---|---|
| תיאור התנהגות | מה המערכת אמורה לעשות, בניסוח שמכיל שונות | סיכום פנייה שמכיל את הבעיה, את הפעולה שננקטה ואת הסטטוס |
| סף מדידה | ציון מינימלי על מערך בדיקה שמור שלא שימש לפיתוח | 90% מהסיכומים כוללים את שלושת הרכיבים |
| אילוץ בטיחות | מה נחשב פלט לא קביל, בלי קשר לציון | אף סיכום לא מכיל מספר טלפון של לקוח |
| וו לאדם | מה קורה במקרים שהמודל לא פותר | ציון ביטחון נמוך מעביר את הפנייה לתור אנושי |
ההבדל בין המרכיב השני לשלישי מהותי. הסף הוא סטטיסטי ומקבל כישלונות בודדים. האילוץ הוא בינארי ולא מקבל אף חריגה. בלי ההפרדה הזו נוצר מצב שבו פיצ׳ר עובר בדיקה עם 92% הצלחה, ובתוך ה-8% הנותרים מסתתרת דליפת מידע.
איך בונים eval בלי צוות מחקר
ה-eval הוא לא פרויקט. במקרה הטיפוסי הוא שלושה נכסים קטנים שמתחזקים לאורך זמן:
מערך נתונים. 50 עד 150 מקרים אמיתיים מהמערכת הקיימת, כולל המקרים המעצבנים. חשוב שהם יילקחו מהשטח ולא יומצאו, כי מקרים מומצאים תמיד נוחים מדי. לכל מקרה מצרפים את התשובה שמומחה תוכן היה נותן.
פונקציית ניקוד. לא חייבת להיות מתוחכמת. בהרבה מקרים מספיקה בדיקה של נוכחות רכיבים חובה, התאמה למבנה מוגדר, או השוואה למילות מפתח. כשנדרשת שיפוטיות אפשר להשתמש במודל כשופט, ובלבד שמדגמים ידנית חלק מהציונים כדי לוודא שהשופט עצמו לא סוטה.
סף וקו בסיס. מודדים פעם אחת לפני שמשנים משהו. בלי קו בסיס אי אפשר לדעת אם שינוי בפרומפט שיפר או שבר, ורוב הצוותים מגלים את זה מאוחר מדי.
מתי מריצים: ה-eval אינו בדיקה חד-פעמית לפני שחרור. הוא רץ מחדש בכל החלפת מודל, כל עריכת פרומפט וכל שינוי במקור נתונים שמזין את המערכת. זה בדיוק ההבדל בין eval לבין test case, ולכן כדאי לחבר אותו לתהליך הבנייה מהיום הראשון.
שישה פרקים שצריך להוסיף למסמך האפיון
| פרק | מה נכנס בו |
|---|---|
| מפרט התנהגות המודל | מה המודל אמור לעשות, באיזה טון, ומה מחוץ לתחום שלו |
| ספי קבלה | המדדים והציונים המינימליים, כולל על אילו נתונים נמדדים |
| קטלוג מצבי כשל | רשימת הדרכים שבהן הפיצ׳ר יכול להיכשל ומה קורה בכל אחת |
| אילוצי התנהגות | קווים אדומים בינאריים: מה אסור שיופיע בפלט לעולם |
| תוכנית הערכה | מערך הנתונים, שיטת הניקוד ותדירות ההרצה |
| נתונים ופרטיות | איזה מידע נכנס לפרומפט ובאיזו רמת סיווג |
הפרק האחרון מחבר ישירות למדיניות הסיווג הארגונית. אם עוד לא הגדרתם אותה, מודל ארבע הרמות של סיווג מידע הוא נקודת ההתחלה, כי בלעדיו האפיון יגדיר יכולת שאסור להפעיל.
קטלוג מצבי הכשל: הפרק שהכי משתלם לכתוב
במערכת דטרמיניסטית מצב כשל הוא שגיאה. במערכת עם רכיב AI מצב כשל הוא לרוב תשובה שנראית תקינה לחלוטין ואינה נכונה. לכן הקטלוג צריך למנות את הכשלים לפי מה שהמשתמש חווה, לא לפי מה שהמערכת מדווחת.
ארבעה שכיחים במיוחד: תשובה בטוחה ושגויה, שדורשת ציטוט מקור כדי להיות ניתנת לאימות; סירוב לענות על שאלה לגיטימית, שדורש מסלול חלופי; תשובה חלקית שמשמיטה תנאי מהותי; וסחיפה לאורך זמן, כשמקור הנתונים משתנה והפלט מתדרדר בלי שאף אחד שינה שורת קוד. האחרון הוא הסיבה המרכזית לכך שה-eval חייב לרוץ תקופתית ולא רק לפני שחרור.
מה זה עושה ללוח הזמנים ולתקציב
ההשפעה המעשית היא שחלוקת המאמץ משתנה. באפיון קלאסי רוב הזמן הולך להגדרת מסכים וזרימות. בפיצ׳ר AI חלק ניכר מהמאמץ עובר לאיסוף מקרי הבדיקה ולתיוגם, וזו עבודה של מומחה תוכן ולא של מפתח. כדאי לתקצב אותה במפורש, אחרת היא נדחקת ומגיעים לשחרור בלי דרך לדעת אם המערכת עובדת.
שינוי שני: הפיצ׳ר לא "מסתיים". יש לו עלות תחזוקה קבועה של הרצת ה-eval ותחזוקת מערך הבדיקה. כשמחשבים כדאיות, זו עלות שצריכה להיכנס למודל היחידה מראש ולא להתגלות ברבעון השני.
ואם הפיצ׳ר עונה מתוך מסמכי הארגון, האפיון חייב לכלול גם את שכבת האחזור, כי שם נקבע רוב הדיוק בפועל. הפירוט המלא נמצא במדריך בסיס הידע הארגוני. את התהליך המלא, מאפיון ועד שחרור, אנחנו מלווים תחת אפיון מערכות.
שאלות נפוצות
מה זה eval ובמה הוא שונה מבדיקת קבלה רגילה?
eval הוא מערך נתונים מתויג יחד עם פונקציית ניקוד וסף מינימלי. בדיקת קבלה רגילה בודקת פלט יחיד ומחזירה עבר או נכשל, ואילו eval מודד התפלגות של איכות על עשרות מקרים ורץ מחדש בכל שינוי מודל, פרומפט או מקור נתונים.
כמה מקרי בדיקה צריך כדי להתחיל?
בין 50 ל-150 מקרים אמיתיים מהמערכת הקיימת מספיקים לרוב הפיצ׳רים. חשוב שהם ייאספו מהשטח ולא יומצאו, ושייכללו את המקרים הקשים ולא רק את הנוחים.
איך כותבים קריטריון קבלה לפלט שאין לו תשובה נכונה יחידה?
מגדירים ארבעה מרכיבים: תיאור התנהגות שמכיל שונות, סף מדידה על מערך בדיקה שמור, אילוץ בטיחות בינארי שלא מקבל אף חריגה, ומסלול העברה לאדם למקרים שהמודל לא פותר.
למה צריך להפריד בין סף מדידה לאילוץ בטיחות?
כי הסף הוא סטטיסטי ומקבל אחוז כישלונות מסוים, ואילו האילוץ הוא בינארי. בלי ההפרדה פיצ׳ר יכול לעבור בדיקה בציון גבוה בזמן שבתוך אחוז הכישלונות מסתתרת חריגה חמורה כמו חשיפת מידע אישי.
האם אפשר להשתמש במודל כשופט שמנקד את הפלט?
כן, וזו שיטה מקובלת כשנדרשת שיפוטיות. התנאי הוא לדגום ידנית חלק מהציונים ולהשוות אותם לשיפוט אנושי, כדי לוודא שהשופט עצמו לא סוטה עם הזמן.
