הערכות LLM — Evals

למה evals הם הצעד החשוב ביותר

דמיין ששינית פרומפט כדי לשפר תשובה אחת. איך אתה יודע שלא שברת עשר תשובות אחרות? בפיתוח תוכנה רגיל יש בדיקות (tests). ב-AI Engineering, המקבילה היא Evals — אוסף מקרי-בדיקה שמודדים אוטומטית את איכות הפלט של המערכת.

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

סוגי הערכות

1. מבוססות-כלל (Rule-based / Code)

הכי מהיר וזול. בודקים דברים אובייקטיביים בקוד: האם הפלט JSON תקין? האם הוא מכיל את השדות הנדרשים? האם המספר בטווח? מתאים לפלטים מובנים.

2. מבוססות-התייחסות (Reference-based)

יש לך "תשובה נכונה" ידועה, ומשווים אליה. מתאים למשימות עם תשובה חד-משמעית (סיווג, חילוץ נתונים). מדדים: דיוק (accuracy), precision/recall.

3. LLM-as-Judge

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

4. מבוססות-אדם (Human eval)

הזהב האמיתי, אבל יקר ואיטי. בני אדם מדרגים דגימה. משתמשים בזה כדי לכייל את ה-LLM-judge ולוודא שהוא מסכים עם בני אדם.

בניית eval set — מאיפה מתחילים

1. אסוף מקרים אמיתיים. קח 20-50 קלטים אמיתיים (או ריאליסטיים) שהמערכת אמורה לטפל בהם.
2. כלול מקרי קצה. לא רק "המקרה הרגיל" — גם קלט ריק, שפה מעורבת, ניסיון manipulation, שאלה מחוץ לתחום.
3. הגדר "מה זה טוב" לכל מקרה — תשובה מצופה, או קריטריונים לשיפוט.
4. התחל קטן. 20 מקרים טובים עדיפים על 500 גרועים. תרחיב עם הזמן, בעיקר מכשלים שראית בייצור.

שמור את ה-eval set כקובץ (JSON/CSV) בגיט, כמו קוד. הוא נכס יקר ערך שגדל עם הזמן.

LLM-as-Judge — דוגמת קוד

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

JUDGE_PROMPT = """אתה שופט איכות תשובות של בוט תמיכה.
דרג את התשובה מ-1 עד 5 לפי:
- רלוונטיות לשאלה
- דיוק (בלי מידע שגוי)
- טון מקצועי בעברית
החזר JSON בלבד: {"score": 1-5, "reason": "..."}

שאלה: {question}
תשובת הבוט: {answer}"""

def judge(question, answer, client):
    prompt = JUDGE_PROMPT.format(question=question, answer=answer)
    resp = client.chat.completions.create(
        model="gpt-5.6", temperature=0,
        response_format={"type": "json_object"},
        messages=[{"role": "user", "content": prompt}],
    )
    return json.loads(resp.choices[0].message.content)

# מריצים על כל ה-eval set ומחשבים ממוצע
scores = [judge(c["q"], run_system(c["q"]), client)["score"] for c in eval_set]
print("avg score:", sum(scores) / len(scores))

טיפ קריטי: כייל את השופט מול בני אדם על דגימה. אם הוא מסכים עם בני אדם ב-~85%+, אפשר לסמוך עליו לרוב המקרים.

Regression testing ו-CI

הכוח האמיתי: להריץ את ה-evals אוטומטית בכל שינוי. מחברים אותם ל-CI (למשל GitHub Actions), ואם ציון ממוצע יורד מתחת לסף — ה-build נכשל. כך שינוי שמשפר דבר אחד ושובר אחר נתפס מיד.

# pseudo: eval gate ב-CI
avg = run_evals(eval_set)
THRESHOLD = 4.2
assert avg >= THRESHOLD, f"איכות ירדה: {avg} < {THRESHOLD}"
print(f"Evals passed: {avg}")

זה הופך "אני חושב שזה יותר טוב" ל"המספרים מוכיחים שזה יותר טוב". ראו גם Observability למדידה בייצור (online evals) על תנועה אמיתית.

טעויות נפוצות

• אין eval set בכלל. הטעות הגדולה. גם 20 מקרים משנים הכל.
• רק "מקרים קלים". אם ה-evals לא כוללים מקרי קצה, הם נותנים ביטחון מזויף.
• שופט לא מכויל. LLM-judge בלי בדיקה מול בני אדם עלול לתת ציונים מטעים.
• טמפרטורה גבוהה בשופט. גורם לציונים לא עקביים. תמיד 0.
• מדד בודד. ציון אחד מסתיר בעיות. מדוד כמה ממדים (דיוק, טון, בטיחות) בנפרד.
• לא מעדכנים. כל כשל בייצור צריך להפוך למקרה חדש ב-eval set.