דלג לתוכן הראשי
AI Engineering הזיות (Hallucinations)
רמה: מתחיל-מתקדם עודכן: אוגוסט 2026

הזיות AI — Hallucinations

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

למה זה קורה — והמסקנה שנגזרת

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

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

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

המסגרת

אל תשאל "איך אמנע". תשאל "איך אדע". כל טכניקה בעמוד הזה נשפטת לפי האם היא מייצרת אות שאפשר לפעול לפיו.

ארבעה סוגים, ארבעה פתרונות שונים

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

  1. עובדה מומצאת. מספר, תאריך, תכונה של מוצר שלא קיימת. הפתרון: grounding — לספק את העובדות בהקשר במקום לסמוך על הידע הפנימי.
  2. מקור מומצא. מאמר, פסק דין, סעיף חוק, קישור. נראה מושלם ואינו קיים. הפתרון: אימות מכני — לבדוק בקוד שהמקור קיים, ולא לבקש מהמודל לוודא.
  3. סתירה להקשר. המידע הנכון נשלח למודל, והוא ענה משהו אחר. הפתרון: ציטוט חובה — לדרוש שכל טענה תצוטט מהמקור.
  4. הכללה מופרזת. ההקשר אמר משהו צר, והתשובה הרחיבה אותו לכלל. הפתרון: הנחיה מפורשת לא לחרוג ממה שכתוב, ובדיקה ידנית — זה הסוג היחיד שקשה לתפוס אוטומטית.

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

איפה הסיכון הכי גבוה

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

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

Grounding: מה הוא פותר ואיפה הוא מחמיר

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

מה שהיא פותרת: עובדות על התחום שלך. מחירים, מדיניות, נהלים, מה שכתוב במסמך שלך. המודל כבר לא צריך לזכור — הוא צריך לקרוא.

ומה שהיא לא פותרת: שני דברים שקל לפספס.

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

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

עברית: למה זה גרוע יותר כאן

זה החלק שאף מדריך זר לא יכסה, והוא משנה את מידת הזהירות שנדרשת.

כמות העברית שעליה אומנו המודלים קטנה בסדרי גודל מהאנגלית, ועל נושאים מקומיים היא קטנה עוד יותר. ככל שהנושא ישראלי יותר, כך גדל הסיכוי להמצאה בטוחה:

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

ובכיוון ההפוך: בנושא ישראלי מובהק, אף שפה לא תציל אותך. שם התשובה היחידה היא grounding ממקור אמיתי — ואם אין לך מקור כזה, ההחלטה הנכונה היא לא לבנות את הפיצ׳ר ולא לבנות אותו בזהירות.

ההנחיה שמשנה הכי הרבה

מכל הטכניקות, זו הזולה ביותר והכי מוזנחת: לתת למודל רשות מפורשת לא לדעת.

מודלים מכוונים להיות מועילים. "אין לי מידע על זה" הוא המשך בעל סבירות נמוכה — הוא כמעט לא מופיע בנתוני האימון כתשובה לשאלה ישירה. בלי הנחיה שמאשרת אותו במפורש, המודל יעדיף להשלים.

ענה רק על סמך הקטעים המצורפים.

אם התשובה לא נמצאת בהם — כתוב בדיוק:
"לא מצאתי מידע על זה במסמכים."

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

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

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

פלט מובנה כשכבת הגנה

טכניקה שנתפסת כעניין של פורמט והיא בעצם מנגנון נגד המצאה.

כשהתשובה היא טקסט חופשי, "לא יודע" דורש מהמודל לנסח סירוב. כשהתשובה היא סכימה עם שדות שיכולים להיות null, אי-ידיעה היא ערך חוקי במבנה — וזה הרבה יותר קל לו מאשר לכתוב משפט שמודה בכישלון.

{
  "supplier_name": string | null,
  "amount":        number | null,
  "date":          "YYYY-MM-DD" | null,
  "source_quote":  string | null   // הטקסט המדויק שממנו נלקח
}

// חוק: אם שדה לא מופיע במקור — null.
// אסור לחשב, אסור להסיק, אסור לנחש.

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

אימות בקוד — החלק שהופך דמו למערכת

כל מה שנכתב עד כאן מקטין את השיעור. מה שמוריד את הנזק הוא בדיקה מכנית של הפלט לפני שהוא מגיע למישהו.

העיקרון: כל דבר שאפשר לבדוק בקוד — תבדוק בקוד, ולא תשאל את המודל.

def verify(answer, context):
    problems = []

    # 1. הציטוט באמת קיים בהקשר
    if answer.get("source_quote"):
        if answer["source_quote"] not in context:
            problems.append("ציטוט שלא נמצא במקור")

    # 2. מספרים שמופיעים בתשובה מופיעים גם בהקשר
    for n in numbers_in(answer["text"]):
        if n not in numbers_in(context):
            problems.append("מספר שאינו במקור: %s" % n)

    # 3. חשבון פנימי מסתדר
    if all(k in answer for k in ("subtotal", "vat", "total")):
        if abs(answer["subtotal"] + answer["vat"]
               - answer["total"]) > 0.05:
            problems.append("סכומים לא מסתדרים")

    return problems

הבדיקה הראשונה חזקה יותר ממה שנראה — היא תופסת סתירה להקשר, שזה בדיוק הסוג ש-RAG לא פותר. השנייה תופסת מספרים מומצאים. והשלישית משתמשת ביתירות שקיימת ממילא במסמך.

ובמקרה של מקורות: תבדוק שהקישור נפתח. שורת קוד אחת שמונעת את הכשל המביך ביותר בקטגוריה. מה שנכשל באימות לא נזרק — הוא הולך לתור בדיקה אנושי, כפי שמפורט במדריך המולטימודלי.

מה לא עובד, למרות שאומרים

ארבע עצות שחוזרות בכל דיון ושאף אחת מהן לא עושה את מה שמייחסים לה.

הכלל שמאחד את ארבעתן: אי אפשר לפתור את זה בתוך המודל. מה שעובד הוא מידע חיצוני שנכנס (grounding) ובדיקה חיצונית שיוצאת (אימות). כל השאר הוא שוליים.

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

בסוכנים זה מתנהג אחרת

כשהמודל לא רק עונה אלא פועל — קורא לכלים, מבצע צעדים, מחליט מה הלאה — ההזיות משנות אופי, ולרעה.

שלושה דפוסים שספציפיים לסוכנים:

מה שעוזר, ושונה ממה שעובד בשאלה-תשובה:

שכבות הגנה, לפי סדר

אף שכבה לא מספיקה לבד, והסדר משנה — כי כל אחת יקרה יותר מקודמתה:

  1. Grounding. לספק את העובדות בהקשר. הזול והמשפיע ביותר.
  2. רשות לא לדעת. שורה בפרומפט.
  3. סכימה עם null וציטוט. כמעט בחינם, ומאפשר את השכבה הבאה.
  4. אימות בקוד. עולה זמן פיתוח, לא עולה בזמן ריצה.
  5. סף על ציון השליפה. כשאין מקור טוב — לא לענות. פירוט בReranking.
  6. מודל שבודק מודל. עולה קריאה נוספת, ותופס מה שקוד לא יכול. שווה רק אחרי שהחמש הראשונות קיימות.
  7. אדם בלולאה. על מה שנפל, ועל כל דבר שנוגע בכסף או בבריאות.

רוב הצוותים קופצים לשש. חמש הראשונות מחזירות את רוב התועלת ועולות הרבה פחות. עוד על השכבה הזאת בGuardrails.

למדוד, אחרת אתה מנחש

אי אפשר לשפר מה שלא נמדד, ו"התשובות נראות טובות" מתפוגג ברגע שמישהו משנה פרומפט.

מה שצריך זה ערכה קטנה, וההרכב שלה חשוב יותר מהגודל:

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

איך נראה תחקיר של הזיה

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

מה שצריך להיות מתועד כדי שתחקיר ייקח חמש דקות:

  1. השאלה המדויקת כפי שנשלחה, אחרי כל שכתוב שעשית לה.
  2. הקטעים שנשלפו — כולל הציונים שלהם, לא רק המזהים.
  3. ההקשר המלא שנשלח למודל, אחרי הרכבה.
  4. מזהה המודל וגרסת הפרומפט.
  5. הפלט הגולמי, לפני כל עיבוד.

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

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

מה להראות למשתמש

חלק מההגנה אינו טכני אלא בממשק, והוא זול במיוחד.

ומה עם המשתמש שמאמין לתשובה

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

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

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

מתי לא להשתמש בכלל

טעויות שחוזרות

הצעד הבא

הטכניקה מספר 1 היא grounding. למד RAG לעומק, והוסף בקרה עם guardrails ו-evals.

RAG Guardrails כל המסלול