הדרך הנפוצה ביותר להילחם ב-hallucinations היא לבקש מהמודל "להיות מדויק יותר". זה בערך כמו לטפל ב-log שבור באמצעות תקווה.
1. צריך להפריד בין סוגי כשל
לא כל תשובה גרועה היא hallucination. יש לפחות כמה מחלקות כשל שונות:
- תשובה שאין לה תמיכה במקורות
- תשובה שנתמכת חלקית אבל מגזימה
- תשובה בפורמט נכון עם עובדה אחת שגויה
- refusal שהיה צריך לקרות ולא קרה
- retrieval חלש שנראה כמו reasoning חלש
אם לא מפרידים ביניהן, בונים מנגנון הגנה כללי מדי שלא תופס שום דבר טוב.
2. grounding מתחיל לפני generation
הרבה שיחות על hallucinations מתמקדות בתשובה. הבעיה מתחילה קודם:
- מסמכים גרועים
- retrieval לא יציב
- context window עמוס מדי
- ranking חלש
- מקור לא מזוהה או לא עדכני
לכן שכבת grounding טובה צריכה לכלול:
- זהות מסמך ברורה
- retrieval צר ומכוון
- reranking כשצריך
- context סופי שאפשר להסביר
- מסלול abstain כשתמיכה דקה מדי
3. abstention הוא feature, לא כישלון
צוותים עדיין נבהלים מ-refusal כאילו הוא פוגע בחוויית המשתמש. בפועל, refusal טוב מציל אמון.
Abstention נחוץ במיוחד כש:
- התמיכה חלקית
- המקורות סותרים
- השאלה מחוץ לטווח
- התשובה עלולה להישמע סמכותית יותר ממה שמותר לה
הטעות היא לראות ב-abstain פגיעה ב-completion rate. הרבה פעמים זה מה שמונע incident.
4. verification לא חייב להיות heavy
לא כל מוצר צריך שרשרת ארוכה של self-critique ו-rewrite.
בדרך כלל מספיקים כמה checks פשוטים:
- האם לכל claim יש עוגן?
- האם יש חלקים בתשובה שלא נתמכים?
- האם היה עדיף לסרב?
- האם הפורמט עומד בחוזה?
- האם יש citation או provenance כשצריך?
ברגע שמנסחים את ה-checks נכון, אפשר לשלב code-based validation, rule-based checks וגריידר מצומצם במקום לעטוף כל תשובה בעוד סיבוב generation.
5. streaming מסבך את הסיפור
Streaming הופך את המוצר לנעים יותר. הוא גם פותח עוד מקום לטעות.
אם מתחילים להזרים מוקדם מדי:
- claim חלש יכול לצאת לפני שנבדק
- markdown חלקי יכול להיראות כאילו המערכת כבר בטוחה בעצמה
- interruption path יכול להשאיר פלט חצי מבושל
לכן במשטחים רגישים כדאי להפריד בין:
- שלב איסוף הראיות
- שלב הבדיקה
- שלב ההצגה
המשתמש לא חייב לראות כל נשיפה פנימית של המודל.
6. evals צריכים לכלול hallucination-specific cases
אי אפשר למדוד hallucinations דרך ציון איכות כללי אחד.
צריך סטים מפורשים שבודקים:
- unsupported claims
- weak support
- contradictory sources
- abstention quality
- citation integrity
- formatting under uncertainty
כאן בדיוק trace review ו-answer review משלימים זה את זה. אחד מראה מה המערכת עשתה. השני מראה מה יצא ממנה בסוף.
7. What not to do
יש כמה פתרונות שנשמעים חכמים אבל כמעט תמיד מאכזבים:
- לדחוף עוד טקסט ל-context בתקווה שהאמת כבר תסתנן פנימה
- לבקש מהמודל שוב ושוב "להיות מדויק"
- להסתמך רק על tone-based human review
- להחליף retrieval בעיבוד לשוני יותר יפה
- להסתיר uncertainty במקום לעצב אותה נכון בממשק
סיכום
Hallucination prevention לא מתחיל בשאלה "איך לגרום למודל לא להמציא". הוא מתחיל בשאלה "איך גורמים למערכת להודות כשאין לה על מה לעמוד".
ברגע שהשאלה הזאת מקבלת תשובה טובה, גם שאר שכבות ההגנה נעשות פשוטות יותר.