הדרך הנפוצה ביותר להילחם ב-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.