אימות פלט ובדיקת אדם

רווחים:

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

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

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

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

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

שכבות של אימות: צעד אחר צעד

1. אימות סכימה. בדקו עם המכונה שהפלט תואם את המבנה הצפוי: האם קיימים השדות, האם הסוגים שלהם נכונים, האם השדות הנדרשים ממולאים?
2. אימות כלל/לוגיקה עסקית. האם הערכים תואמים את הכללים העסקיים? (כמות > 0, התאריך אינו בעתיד, קוד המוצר שייך לקטלוג.)
3. הפניה/בקרת מקור. אם המודל מייצר טענה, האם ניתן לקשר אותו למקור? (האם הציטוט של RAG אכן נמצא במסמך?)
4. אימות עם המודל השני (LLM-as-judge). מודל עצמאי מעריך את הפלט כ"נכון/לא שלם/מסוכן".
5. סף אמון והתמצאות. אם הדגם או המאמת מדווחים על ביטחון נמוך, הפלט לא עובר אוטומטית; מופנה לבני אדם.
6. שליטה אנושית. תוצאה בעלת עוצמה גבוהה או בטיחותית נמוכה תלויה באישור המומחה.

ארבע תבניות הניתנות להעתקה

סכימה + "המציא את זה אם אתה לא יודע" ביחד:

החזר את התגובה בסכימת JSON הבאה בלבד: כתוב "נמוך". לעולם אל תכתוב הערכה כאילו היא מדויקת.

אימות עם הדגם השני (הנחיית שופט):

אתה מאמת עצמאי. להלן טקסט <מקור> ו<תביעה>. בדוק אם כל מספר ותאריך בתביעה מופיעים מילה במילה במקור. עבור כל אחד, אמור: "מאומת | לא במקור | סותר את המקור". אם אפילו אחד מהם הוא 'נעדר/מתנגש', סמן את התוצאה כ"ביקורת אנושית נדרשת".<source>{{ text }}</source><claim>{{ model_output }}</claim>

כלל ניתוב סף אמון:

כלל ניתוב:- emin_misin = "גבוה" וכמות < 10,000 TL -> עיבוד אוטומטי- emin_misin = "בינוני" או כמות 10,000-100,000 TL -> אימות דגם שני- emin_misin = "נמוך" או כמות > 100,000 TL נדרש -> אישור אנושי

כרטיס סיכום ביקורת אנושית (מזרז את הבדיקה):

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

הנחיה חלשה / הנחיה חזקה

גישה גרועה

גישה חזקה

"הפחת סכום מהחשבונית" (טקסט חופשי)

סכימת JSON קפדנית + null + שדה אמון

כתיבת הפלט ישירות למערכת התשלומים

סכימה → כלל → אישור אנושי (במידת הצורך)

רק אומר לדוגמנית "תהיה בטוח"

אימות מספר/תאריך עם הדגם השני

עיבוד כל פלט בביטחון שווה

ניתוב המבוסס על השפעה ואמון

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

שלושה מיני מארזים

מקרה 1 - התוכנית לבדה לא הספיקה. אוטומציה חשבונאית חילצה את הסכום מהחשבוניות כ-JSON. התוכנית הייתה נכונה, אבל המודל הפיק "125,000" במקום "1,250.00" בחשבונית (הסטה עשרונית). התוכנית לא הצליחה לתפוס זאת; אימות כלל ("הסכום חייב להיות בקנה אחד עם סך פריטי החשבונית ב-1% ±") נתפס ונמנעה רישום שגוי של 112,500 TL.

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

מקרה 3 - ניתוב הפחית את העומס ב-70%. מערכת תביעות ביטוח אישרה אוטומטית תביעות בסכומים נמוכים ובאבטחה גבוהה ושלחה למומחה רק את אלו מעל הסף/הנמוך. מתוך 3,200 הדרישות היומיות, רק 950 נפלו בידי בני אדם; מומחים הקדישו את זמנם ל-30% המסוכנים באמת, כאשר זמן העסקה הממוצע יורד מ-4 שעות ל-40 דקות.

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

הפיכת השליטה האנושית למשמעותית

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

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

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

לסיכום

• הפלט פגום בשלוש דרכים: צורה, תוכן וכוונת זדון; מערכת מוצקה עוצרת את שלושתם בדלת.
• שכבות: אימות סכימה, לוגיקה של כללים/עסקים, בקרת מקור, מודל שני (LLM-as-judge), וניתוב סף אמון.
• אדם-in-the-loop צריך להיות חובה עבור תפוקות בעלות השפעה גבוהה ובטיחותית נמוכה.
• סקירה אנושית חייבת להיות בעלת משמעות: לסוקר חייב להיות הקשר, גישה למשאבים וסמכות לומר "לא".
• הן בטיחות והן יעילות מושגות על ידי הפניית המסוכנים רק לבני אדם, לא לכל פלט.

משימת יישום

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

רשימת בדיקה

• [ ] אני מגדיר סכמה קפדנית לפלט ומאמת אותה עם המכונה.
• [ ] הוספתי לפחות אימות עסק/כללים אחד (לוגיקת ערך).
• [ ] אני יכול לקשר את הקביעות למקור ולבדוק אותן.
• [ ] מודל שני או אימות אנושי זמין עבור השפעה גבוהה/תוצאות בטיחות נמוכות.
• [ ] כלל ניתוב מוגדר על סמך אמון והשפעה.
• [ ] המבקר מסופק בהקשר, מקור וסמכות לדחות.