הזיה נראית בדיוק כמו תשובה נכונה

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

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

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

שלושה סוגי הזיות

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

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

מאיפה ההזיות מגיעות

לפי מחקר שפרסמה OpenAI בספטמבר 2025, יש לזה שתי סיבות עיקריות.

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

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

הנתונים של OpenAI ממחישים את זה היטב. שני מודלים נבחנו על אותן שאלות עובדתיות (מבחן SimpleQA):

	מודל ישן	מודל חדש
ענה “לא יודע”	1%	52%
טעה	75%	26%
צדק	24%	22%

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

יש כאן עוד נקודה, פחות מוכרת. במודל שפה “גולמי”, לפני שלימדו אותו לנהל שיחה, רמת הביטחון די משקפת את הסיכוי שהוא צודק: כשהוא בטוח ב-70%, הוא צודק בערך ב-70% מהמקרים. בדו“ח הטכני של GPT-4 הראתה OpenAI שהאימון שהופך את המודל לעוזר שיחה פוגע משמעותית בהתאמה הזו. במילים אחרות, הטון הבטוח של המערכת לא מלמד הרבה על הסיכוי שהיא צודקת.

למה חיבור למאגר מסמכים לא פותר את הבעיה

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

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

ההזיות כבר יוצאות מהמשרד

המקרה המוכר ביותר הוא Mata v. Avianca מניו יורק, 2023. עורכי דין הגישו כתב טענות עם פסקי דין ש-ChatGPT המציא, וכששאלו את המערכת אם הם אמיתיים, היא ענתה שכן. בית המשפט קנס את עורכי הדין ואת המשרד ב-5,000 דולר. מאז זה הפך לתופעה: מאגר שמנהל החוקר Damien Charlotin מתעד החלטות שיפוטיות שעסקו בתוכן מומצא של AI, ובנובמבר 2026 כבר היו בו יותר מ-2,200 החלטות. גם בישראל נמצאו בעתירה לבג“ץ חמש הפניות לפסקי דין שאינם קיימים, ועשרות הפניות שלא התאימו לתיק או לטענה (בג“ץ 38379-12-24), ובתיקים שבאו אחריו כבר חויבו עורכי דין בהוצאות אישיות.

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

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

הסוג השני הוא מערכת שמדברת ישירות עם לקוחות: צ’טבוט באתר, נציג וירטואלי, מענה אוטומטי במייל. הצ’טבוט של Air Canada הבטיח לנוסע החזר רטרואקטיבי שמדיניות החברה לא אפשרה, והחברה ניסתה לטעון שהצ’טבוט אחראי למה שאמר. הטריבונל דחה את הטענה, וקבע שהחברה אחראית לכל מה שמופיע באתר שלה (Moffatt v. Air Canada).

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

ארבעה כללי עבודה

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

אין נוסחה אחת

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

המאמר נועד להציע כיווני חשיבה, ואינו ייעוץ משפטי.