לפני שבודקים תשובה, ממפים את המערכת
מוצר LLM כולל בדרך כלל יותר ממודל. יש system prompt, היסטוריית שיחה, RAG שמביא מסמכים, כלים או APIs שהמודל יכול להפעיל, מסנני בטיחות, הרשאות, UI ולוגים. כשל בכל רכיב יכול להיראות כמו "המודל טעה", אבל דרך החקירה והפתרון שונה.
| רכיב | דוגמאות לכשל | ראיות לחקירה |
|---|---|---|
| Prompt | הוראות סותרות, חוסר בהגדרת גבול או פורמט | גרסת prompt והודעות שנשלחו למודל |
| Retrieval | מסמך לא רלוונטי, מקור ישן או קטע חסר | queries, מסמכים שנשלפו, score וגרסת index |
| Model | עובדה מומצאת, חוסר עקביות או סירוב שגוי | מודל, גרסה, temperature, seed אם קיים ותגובה גולמית |
| Tools | קריאה לכלי הלא נכון או פרמטר מסוכן | tool call, arguments, הרשאה ותוצאת API |
| Application | הקשר שנחתך, session שגוי או מידע שנחשף | trace מקצה לקצה, user ID, tenant ו־request ID |
| UI | מקור שאינו מוצג, אזהרה חסרה או streaming תקוע | אירועי לקוח, DOM, network וצילום מסך |
מגדירים שימוש וסיכון
צ'אט שמציע ניסוח שיווקי אינו דומה למערכת שמסכמת מידע רפואי או מפעילה פעולה בחשבון לקוח. לפני כתיבת test cases מגדירים מי המשתמש, מה ההחלטה שהמערכת משפיעה עליה, מה אסור לה לעשות, מתי היא חייבת לסרב ומתי אדם צריך לאשר.
המדד הנכון אינו "האם התשובה נשמעת חכמה". המדד הוא האם היא עוזרת לבצע את המשימה בגבולות הסיכון שהוגדרו.
אילו ממדים בודקים בתשובת LLM?
- Correctness: האם הטענות נכונות לפי מקור מוסכם.
- Groundedness: האם כל טענה נתמכת בהקשר שסופק.
- Relevance: האם התשובה עונה לשאלה ולא רק נכונה באופן כללי.
- Completeness: האם חסר חלק קריטי למשימה.
- Instruction following: האם המודל שמר על פורמט, שפה והגבלות.
- Safety: האם התשובה נמנעת מנזק, דליפה או פעולה לא מורשית.
- Fairness: האם קלטים שקולים מקבלים יחס עקבי בין קבוצות.
- Style: בהירות, אורך, טון ויכולת המשתמש להבין מגבלה.
- Latency: זמן עד token ראשון וזמן לתשובה מלאה.
- Cost: tokens, קריאות retrieval וכלים לכל משימה מוצלחת.
בונים rubric במקום ציון כללי
Rubric מתאר מהו ציון טוב בכל ממד. לדוגמה, ב־groundedness: ציון 2 כאשר כל הטענות נתמכות במקורות, ציון 1 כאשר יש טענה משנית לא נתמכת, וציון 0 כאשר טענה מרכזית הומצאה. הגדרה כזו מקטינה ויכוח ומאפשרת להשוות גרסאות.
בדיקות דטרמיניסטיות עדיין חשובות
לא כל בדיקה צריכה מודל שופט. אפשר לבדוק בקוד:
- שהתגובה היא JSON תקין ועומדת ב־schema.
- שכל citation מפנה למסמך שהוחזר ב־retrieval.
- שלא מופיעים מספר חשבון, אימייל או מפתח סודי.
- שפעולה כספית דורשת אישור מפורש.
- שזמן התגובה והעלות נמצאים מתחת לסף.
- שהמערכת מסרבת לקטגוריה שהוגדרה מראש.
איך בונים evaluation set שימושי
מתחילים ממשימות אמיתיות ולא מרשימת שאלות כללית. כל רשומה צריכה לכלול קלט, הקשר, תוצאה רצויה, התנהגות אסורה, קטגוריה, רמת סיכון ולעיתים reference answer. הוסיפו גם שפה, סוג משתמש וגרסת מקור.
קטגוריות בסיס
| קטגוריה | דוגמה | מה מודדים |
|---|---|---|
| מסלול רגיל | שאלה נפוצה עם מקור ברור | דיוק, רלוונטיות וסגנון |
| חוסר מידע | שאלה שהמקורות אינם עונים עליה | הכרה במגבלה ואי המצאת תשובה |
| עמימות | שאלה עם שתי פרשנויות | שאלת הבהרה או הצגת ההנחה |
| מקורות סותרים | שני מסמכים עם גרסאות שונות | העדפת מקור, תאריך והצגת הסתירה |
| רב לשוניות | עברית, אנגלית ושילוב מונחים | שמירת משמעות, פורמט ושפה |
| קלט עוין | ניסיון לשנות הוראות או לחשוף מידע | גבולות, הרשאות והתנהגות בטוחה |
| פעולת כלי | בקשה לשלוח, למחוק או לשנות מידע | בחירת כלי, arguments ואישור משתמש |
כמה דוגמאות צריך?
אין מספר קבוע. התחילו ב־30 עד 50 דוגמאות שמכסות שימושים מרכזיים וסיכונים. תייגו אותן כדי לראות באיזו קטגוריה גרסה השתפרה או נסוגה. עם הזמן הוסיפו תקלות אמיתיות מהייצור לאחר הסרת מידע אישי וקבלת הרשאה מתאימה.
שילוב של שלושה סוגי הערכה
חוקים קבועים
Schema, regex, citations, הרשאות, latency ועלות. מהיר, עקבי וקל לחקירה.
LLM as a Judge
מתאים לרלוונטיות, סגנון וקריטריונים שקשה לכתוב כחוק. דורש rubric, כיול, גרסה ובדיקת עקביות.
הערכה אנושית
נדרשת למשימות מורכבות, סיכון גבוה, כיול וחקירת פערים בין מדדים לחוויית משתמש.
כיצד מכיילים מודל שופט?
אוספים דוגמאות עם ציונים אנושיים מוסכמים, מריצים את השופט ומשווים. בודקים אם הוא מעדיף תשובות ארוכות, סגנון מסוים או מודל מאותה משפחה. מגדירים פורמט פלט קשיח ומבקשים נימוק קצר שמפנה לקריטריון, לא נימוק חופשי ארוך.
בדיקות מיוחדות למערכת RAG
ב־RAG יש לפחות שתי שאלות נפרדות: האם נשלף המידע הנכון, והאם התשובה השתמשה בו נכון.
בדיקת retrieval
- האם המסמך הרלוונטי נמצא ב־top k.
- האם metadata filters מונעים מעבר בין לקוחות או הרשאות.
- האם chunk מכיל מספיק הקשר להבנת הטענה.
- האם מסמך חדש גובר על גרסה ישנה.
- האם שאלות בעברית מוצאות מסמכים באנגלית ולהפך, כאשר זו דרישה.
- האם קלט עם שגיאת כתיב או שם חלופי עדיין מחזיר מקור רלוונטי.
בדיקת generation
- כל טענה מהותית נתמכת בקטע שנשלף.
- citation מפנה למקור הנכון ולא רק למסמך כללי.
- המודל אינו משלב מידע מהזיכרון בניגוד למדיניות.
- כאשר המקורות סותרים, התשובה מציגה את הסתירה או בוחרת לפי כלל ברור.
- כאשר אין מקור מספיק, התשובה אומרת זאת ומציעה צעד מתאים.
שינוי מסמך הוא שינוי מוצר
עדכון knowledge base יכול לשנות תשובות בלי שינוי קוד. לכן שומרים גרסת index ומסמכים יחד עם תוצאת evaluation. בודקים הוספה, עדכון, מחיקה, הרשאות ומועד שבו המסמך נהיה זמין לחיפוש.
רגרסיה, שחרור וניטור בייצור
כל שינוי במודל, prompt, temperature, retrieval, tool או guardrail יכול לשפר קטגוריה אחת ולפגוע באחרת. לפני שחרור מריצים את אותו evaluation set מול גרסת בסיס ומשווים pass rate לפי קטגוריה, לא רק ממוצע כללי.
שערי שחרור אפשריים
- אפס כשלים חדשים בקטגוריות קריטיות של הרשאה ודליפת מידע.
- אין ירידה מעבר לסף ב־groundedness וברלוונטיות.
- p95 latency ועלות ממוצעת מתחת לתקציב.
- מדגם אנושי מאשר תרחישים בסיכון גבוה.
- כל שינוי מתועד עם מודל, prompt, index וגרסת כלים.
מה מנטרים בייצור?
שיעור הצלחת משימה, משוב משתמש, סירובים, tool errors, latency, tokens, retrieval misses, דליפות שנחסמו ודוגמאות של תשובות בעייתיות. אין לשמור prompt ותשובה ללא מדיניות פרטיות, צמצום מידע והרשאות. בונים תהליך שממיר תקלה אמיתית לדוגמת regression נקייה.
חקירת כשל
שמרו trace שמחבר user request, גרסת prompt, מסמכים שנשלפו, תגובת מודל, tool calls ופלט למשתמש. בלי השרשרת הזו קשה לדעת אם לתקן prompt, retrieval, הרשאה, model choice או UI.
בדיקות אבטחה הן חלק מהמערכת. המשיכו למדריך Prompt injection ו־red teaming לאנשי QA ולסקירה הרחבה AI בבדיקות תוכנה.
שאלות נפוצות
איך בודקים LLM כשהתשובה משתנה בכל הרצה?
לא מסתמכים רק על השוואת טקסט מדויקת. מגדירים קריטריונים, מדדים ומערך דוגמאות, מריצים מספר פעמים ומשלבים חוקים קבועים, הערכת מודל והערכה אנושית.
מהו evaluation set?
זהו אוסף גרסאות של קלט, הקשר, תוצאה רצויה, מגבלות ותגיות סיכון. משתמשים בו להשוואה בין prompt, מודל, retrieval וגרסאות מערכת.
האם LLM יכול לבדוק LLM אחר?
כן, כ־LLM as a Judge, אבל צריך לכייל אותו מול הערכה אנושית, להגדיר rubric ברור, לשמור גרסה ולבדוק הטיה ועקביות. הוא אינו מקור אמת אוטומטי.
מה ההבדל בין hallucination לתשובה לא רלוונטית?
Hallucination היא טענה שאינה נתמכת במקור או בעובדות. תשובה יכולה להיות נכונה עובדתית אך לא לענות לשאלה. לכן מודדים בנפרד דיוק, grounding ורלוונטיות.