Verifier Models — שימוש במודל נוסף לבדיקת התוצאה

מאת צוות מדיה דיל · 09.08.2026 · AI · 11 דק׳

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

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

מה זה Verifier Model ולמה צריך מודל שני

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

ארכיטקטורות Verifier — מודל קטן, כלל, או דטרמיניסטי

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

• בדיקה דטרמיניסטית — schema validation, הרצת טסטים, בדיקת כללי עסק מפורשים. זול, מהיר, לגמרי אמין — אבל מוגבל לקריטריונים שאפשר לנסח כללית באופן פורמלי.
• מודל קטן וממוקד (classifier) — מודל מאומן ספציפית למשימת ההערכה (למשל: "האם התשובה מבוססת על ההקשר שסופק"). זול ומהיר יחסית ל-LLM גדול, ומתאים למשימת אימות צרה וחוזרת.
• LLM נפרד, אולי חזק יותר מה-generator — מתאים כשהערכה דורשת reasoning מורכב, לא רק סיווג. יקר יותר, אבל גמיש לקריטריונים שקשה לנסח פורמלית.
• Grounding check מול מקור — השוואת כל טענה בתשובה בחזרה למקור המידע (מסמך, מסד נתונים) — מיוחד לתפיסת hallucinations, לא רק שגיאות פורמט.

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

Generator-Verifier Pattern

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

const draft = await generator.run(task);
const verdict = await verifier.check({
  output: draft,
  criteria: task.acceptance_criteria,
  // בכוונה בלי context מלא של ה-generator
});
if (verdict.pass) {
  return draft;
} else {
  return retry(task, verdict.issues); // או escalate ל-human-in-the-loop
}

כשה-verifier דוחה תוצאה, יש שתי אפשרויות המשך: retry אצל ה-generator עם הבעיות שזוהו (דומה ל-Agent Reflection), או העברה לבדיקה אנושית אם זו כבר הפעם השנייה-שלישית שנכשלה — ראו Human-in-the-Loop.

מדידת אמון (Confidence) והחלטת קבלה/דחייה

לא כל verifier מחזיר "עובר/נכשל" בינארי — לעיתים הוא מחזיר ציון ביטחון (confidence score). כאן נדרשת החלטת ארכיטקטורה: איפה קובעים את הסף (threshold) שמעליו התוצאה מתקבלת אוטומטית, ומתחתיו עוברת ל-escalation? סף גבוה מדי דוחה יותר מדי תוצאות תקינות (over-rejection, מייקר תפעולית ומעצבן משתמשים). סף נמוך מדי מעביר תוצאות בעייתיות (under-rejection, מסוכן). קביעת הסף הנכון דורשת מדגם מתויג ומדידת trade-off אמיתי בין precision ל-recall — לא ניחוש, וקשור ישירות ל-LLM Evals.

Trade-offs — עלות כפולה מול איכות

verifier מוסיף קריאת מודל (או יותר) לכל תוצאה — עלות ו-latency נוספים. בהיקף גדול (אלפי-מיליוני בקשות), זה יכול להכפיל את עלות התפעול. השאלה הנכונה היא לא "האם זה שווה" באופן כללי אלא "מה עלות הטעות שלא נתפסה מול עלות הבדיקה". במערכות עם השלכות עסקיות/משפטיות/בריאותיות משמעותיות — עלות הבדיקה זניחה מול עלות טעות שמגיעה ללקוח. במערכות עם סיכון נמוך (הצעת תוכן פנימי, טיוטה ראשונית) — verifier יקר עלול להיות overkill, ובדיקה דטרמיניסטית קלה מספיקה.

דוגמה מהשטח

מערכת שמייצרת סיכומי שיחות שירות לקוחות לצורך תיעוד. ה-generator מפיק סיכום; verifier נפרד (מודל קטן וזול) בודק grounding — שכל פרט בסיכום מופיע בפועל בתמלול השיחה המקורית, לא הומצא. תוצאה עם ציון grounding נמוך מסומנת אוטומטית ל-review אנושי, בעוד תוצאות עם ציון גבוה עוברות ישירות לתיעוד. הפרדה כזו מאפשרת אוטומציה ברוב המקרים תוך שמירת רשת ביטחון למקרים החריגים, בלי שצריך בן אדם לקרוא כל סיכום.

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

• לתת ל-verifier לראות את כל ה-context של ה-generator — מגדיל את הסיכוי שהוא "יתיישר" עם אותה הטיה במקום לבדוק באופן עצמאי.
• להשתמש תמיד ב-LLM יקר לבדיקה כשבדיקה דטרמיניסטית זולה הייתה תופסת את רוב הטעויות.
• לא לכייל את סף הקבלה (threshold) על מדגם אמיתי — קביעה שרירותית של סף מובילה ל-over/under-rejection לא מבוקר.
• אין נתיב escalation ברור לתוצאות שנדחו — verifier בלי מנגנון המשך הופך לצוואר בקבוק שתקוע.

False Positives ו-False Negatives של Verifier

כמו כל מערכת סיווג, ל-verifier יש שני סוגי טעות אפשריים, וההשלכות שלהם שונות מאוד. False positive — ה-verifier מאשר תוצאה שבעצם פגומה — הוא הסיכון המסוכן יותר, כי הוא נותן תחושת ביטחון כוזבת: התוצאה יוצאת לשימוש כאילו נבדקה ואושרה. False negative — ה-verifier דוחה תוצאה תקינה — פחות מסוכן אבל עדיין עולה כסף (עוד סבב generate) ופוגע בחוויית המשתמש (עיכוב מיותר). בהתאם לתחום, כדאי לכייל את ה-verifier במפורש לכיוון שמתאים לפרופיל הסיכון — בתחומים רגישים, עדיף verifier "מחמיר" עם יותר false negatives על פני verifier "סלחני" עם false positives, גם במחיר של תפוקה נמוכה יותר.

מי בונה את קריטריון האימות

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

Verifier שמתעדכן — התמודדות עם Drift

נקודה שקל לפספס: verifier עצמו יכול "להתיישן" עם הזמן, גם אם הוא נבנה נכון בהתחלה. אם ה-generator משתנה (מודל חדש, prompt מעודכן), סוגי הטעויות שהוא מייצר עלולים להשתנות באופן שה-verifier הקיים לא בהכרח מכוסה עבורו — למשל, אם ה-verifier "אומן" (implicitly, דרך הפרומפט שלו) לתפוס טעויות ספציפיות מהגרסה הישנה, הוא עלול לפספס לגמרי סוג חדש של טעות שהגרסה החדשה מייצרת. הפתרון הוא לא לראות את ה-verifier כרכיב "מוגמר" אחת ולתמיד, אלא לבדוק את ביצועיו מחדש בכל פעם שה-generator משתנה משמעותית, ולתחזק eval set ייעודי לביצועי ה-verifier עצמו — לא רק ל-generator, כמתואר ב-LLM Evals.

Verifier ואחריות משפטית-עסקית

בתחומים רגולטוריים (פיננסים, בריאות, משפט), הוספת verifier היא לא רק שיקול איכות — היא לעיתים דרישה תיעודית ממשית. מנגנון שמדגים ש-כל תוצאה שיוצאת למשתמש עברה בדיקה עצמאית לפני שחרור, עם תיעוד מלא של הקריטריון, התוצאה, ומועד הבדיקה, הוא בסיס חשוב להוכחת בקרת איכות אם מתעוררת שאלה בדיעבד (regulatory audit, תלונת לקוח, בדיקה פנימית). זה מחייב ששכבת ה-verifier לא רק "תחליט" אלא גם תתעד את ההחלטה בצורה שניתנת לשליפה ולביקורת מאוחרת — לא מספיק שהמערכת "עבדה נכון", צריך גם להיות מסוגלים להוכיח את זה בדיעבד. זה מתחבר ישירות לדרישות שמפורטות ב-AI Audit Logs.

Verifier מדורג (Cascade) לחיסכון בעלות

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

הבדל בין Verifier ל-LLM-as-a-Judge

מונח קרוב שכדאי להבחין ממנו: LLM-as-a-Judge הוא מקרה פרטי של verifier, שבו מודל שפה משמש להעריך איכות פלט לפי קריטריונים לרוב סובייקטיביים יותר (רלוונטיות, טון, שלמות) — נפוץ מאוד בהערכת eval sets, כמתואר ב-LLM Evals. verifier במובן הרחב שתואר במדריך הזה יכול לכלול גם את זה, אבל גם בדיקות דטרמיניסטיות שאין בהן שום שיפוט "איכותי" — רק בדיקת תקינות עובדתית או פונקציונלית. ההבחנה חשובה כי היא משפיעה על הבחירה הנכונה: כשהקריטריון ניתן לניסוח אובייקטיבי (עובד/לא עובד), עדיפה בדיקה דטרמיניסטית או classifier ממוקד; כשהקריטריון סובייקטיבי במהותו (איכות כתיבה, טון מותאם), LLM-as-a-Judge הוא הכלי המתאים יותר.

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

שאלות נפוצות

האם verifier חייב להיות מודל AI?

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

מה עדיף — verifier חזק ויקר, או verifier זול שרץ יותר פעמים?

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

איך מודדים את איכות ה-verifier עצמו?

באמצעות מדגם מתויג ידנית — משווים את החלטות ה-verifier מול "אמת" אנושית ומחשבים precision/recall, בדיוק כמו בכל מערכת קלסיפיקציה.

מה קורה כשגם ה-verifier טועה?

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

תגיות: Verifier Models · Generator Verifier Pattern · AI Quality Control · LLM Evals · Confidence Scoring · AI Guardrails

← חזרה לבלוג · צור קשר