הזיות AI בפרודקשן: איך מזהים, מונעים ומתמודדים

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

הזיות AI הן לא באג שמתקנים פעם אחת ונגמר. הן תופעה מבנית של מודלי שפה - הם מנבאים את המילה הבאה הכי סבירה, לא שולפים עובדה ממאגר אמת. גם GPT-5.1 וגם Claude Opus 4.5 עדיין ממציאים ציטוטים, תאריכים ומספרי חוק כשאין להם עיגון (grounding) למקור אמיתי. השאלה המעשית היא לא "איך מבטלים הזיות" אלא איך בונים מערכת שמצמצמת אותן, תופסת את מה שנשאר, ונותנת למשתמש דרך בטוחה לצאת כשהמודל לא בטוח.

למה מודלים ממציאים דברים - בקצרה

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

• ידע חסר או מיושן - המודל מתאמן עד תאריך מסוים (cutoff) ולא יודע על אירועים אחריו.
• ידע ספציפי מדי - מספרי הזמנה, מדיניות פנימית של חברה, נתונים פרטיים - דברים שלא היו בדאטת האימון בכלל.
• לחץ להשלים תבנית - כששואלים "מה סעיף 7 בחוזה?" המודל נוטה להשלים תשובה בפורמט של סעיף חוזה, גם אם אין לו מושג מה כתוב שם באמת.

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

Grounding: לתת למודל את העובדות במקום לבקש שיזכור אותן

הכלי המרכזי הוא RAG (Retrieval-Augmented Generation) - שליפת מידע רלוונטי ממאגר מהימן והזרקתו לפרומפט לפני שהמודל עונה. במקום לשאול "מה מדיניות ההחזרות שלנו?" ולתת למודל לנחש, אתה שולף את המסמך הרלוונטי ואומר לו "ענה על סמך הטקסט הבא בלבד".

הרחבתי על זה במדריך RAG לעסקים קטנים - מ-PDF לעוזר AI, אבל שלוש נקודות קריטיות ספציפיות להזיות:

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

System prompt לדוגמה למניעת הזיות ב-RAG:

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

אימות (verification): שכבה שנייה אחרי היצירה

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

LLM-as-judge

מודל שני (יכול להיות זול יותר, כמו Haiku 4.5 או GPT-5.1 mini) בודק: "האם התשובה הזו נתמכת במלואה על ידי המקורות שסופקו?" זה מוסיף עלות וזמן תגובה (בדרך כלל 300-800ms נוספות), אבל תופס טעויות גסות לפני שהמשתמש רואה אותן. ראו evaluating LLM apps להעמקה בבניית pipeline כזה.

אימות מבוסס entailment

בדיקה תכנותית (לא LLM) שכל משפט עובדתי בתשובה "נגזר" (entailed) מהמקור. זול יותר מ-LLM judge אבל דורש infrastructure ייעודי - פחות מתאים לרוב העסקים הקטנים.

Structured output עם ציון ביטחון

מכריחים את המודל להחזיר JSON עם שדה confidence ושדה source_ids לכל טענה, ומסננים תוצאות עם ביטחון נמוך. פירטתי על זה במדריך Structured Outputs - זה גם מקל על אימות אוטומטי כי אתה יכול לבדוק תכנותית שכל source_id קיים באמת במאגר.

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

ציטוט מקורות (citations) - למה זה משנה יותר מדיוק גולמי

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

איך מיישמים את זה בפועל

1. בזמן ה-retrieval, שמרו מזהה ייחודי לכל chunk (למשל doc_id + chunk_index).
2. בפרומפט, בקשו מהמודל להוסיף [מקור: doc_id] אחרי כל משפט עובדתי.
3. בצד השרת, וודאו שה-doc_id שהמודל ציטט אכן קיים ואכן נשלף בפועל - זה תופס מקרה נפוץ שבו המודל ממציא מספר מקור שנשמע אמין.
4. בממשק, הפכו את הציטוט ללינק או tooltip שמראה את הטקסט המקורי - זה בונה אמון ומאפשר למשתמש לבדוק בעצמו.

UX שמצמצם נזק - כי אי אפשר להגיע ל-0%

אין מערכת production שמגיעה ל-0% הזיות. גישה בוגרת מניחה שהזיה תקרה ומעצבת את הממשק כך שהנזק יהיה נמוך.

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

מתי לגרום למודל "לא לענות" (abstention)

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

• אם אין source רלוונטי ב-retrieval - אל תיתן למודל לענות מהידע הכללי שלו. תגובת ברירת מחדל: "אין לי מידע מדויק, מעביר אותך לנציג."
• אם השאלה נוגעת לכסף, בריאות או משפט ספציפי ללקוח - גם עם ציטוט טוב, שקלו הפניה לאדם. הזיה בתחום הזה עולה הרבה יותר מאשר בתחום תוכן שיווקי.
• אם ה-confidence score (structured output) נמוך מסף שקבעתם - למשל 0.6 - תציגו הודעת ביניים במקום תשובה ודאית.

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

Guardrails ברמת המערכת

מעבר לפרומפט ול-RAG, שכבת guardrails נפרדת (למשל דרך llm-guardrails-safety) יכולה לחסום קטגוריות שלמות של תשובות מסוכנות - למשל ייעוץ רפואי ספציפי, הבטחות משפטיות, או מספרים כספיים שלא עברו אימות. זה משלים, לא מחליף, את ה-grounding.

בנוסף, אם המערכת שלכם מבוססת agent עם tool calling (למשל שליפת מידע ממערכת CRM חיצונית), חשוב לוודא שהמודל לא "ממציא" קריאות לכלים שלא קיימים.

מדידה: איך יודעים אם השתפרתם

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

# דוגמה פשוטה ל-eval set לבדיקת הזיות
eval_cases = [
    {
        "question": "מה מדיניות ההחזרות שלכם?",
        "expected_source": "policy_doc_2026.pdf",
        "must_contain": ["14 יום", "קבלה מקורית"],
    },
    {
        "question": "מה מספר הטלפון של המנכ״ל?",
        "expected_behavior": "abstain",  # אין מקור - חובה לסרב
    },
]

def run_eval(model_fn, cases):
    results = []
    for case in cases:
        answer = model_fn(case["question"])
        results.append(check_case(case, answer))
    return results

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

שאלות נפוצות

מה ההבדל בין הזיה לבין טעות רגילה?

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

האם RAG פותר את בעיית ההזיות לגמרי?

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

כמה עולה להוסיף שכבת אימות (verification) למערכת קיימת?

תלוי בשיטה. LLM-as-judge עם מודל זול (למשל Haiku 4.5) מוסיף בדרך כלל כמה אגורות לבקשה ו-300-800ms זמן תגובה. structured output עם בדיקת source_id תכנותית כמעט בחינם מבחינת עלות אבל דורש עבודת פיתוח חד-פעמית. ברוב המקרים ה-ROI מצדיק את ההשקעה תוך חודש-חודשיים.

איך מזהים הזיה לפני שהלקוח מדווח עליה?

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

האם מודלים חדשים יותר (כמו Claude Opus 4.5 או GPT-5.1) הוזים פחות?

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

מה עדיף - להשקיע ב-prompt engineering או ב-RAG טוב יותר?

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

רוצים לבנות את זה נכון מהפעם הראשונה

אם אתם בונים או משדרגים עוזר AI מול לקוחות ורוצים לוודא שהוא לא ממציא תשובות - אפשר לדבר על זה בטופס יצירת קשר או ישירות ב-wa.me/972585802298, לשיחת ייעוץ קצרה של 30 דקות, בלי התחייבות.

מקורות

• Anthropic - Reducing hallucinations
• OpenAI - RAG guide
• Anthropic - Building effective agents