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