בקצרה
בודקים טענות מול מקורות מתאימים ועדכניים, ומפרידים ידע מהסקה. בתהליכים שפועלים נדרשת גם ראיה ממערכת היעד. הימנעות מהכרעה היא תוצאה נכונה כשאין מידע מספיק.
״בדקתי והכול תקין״ היא אחת התשובות המרגיעות ביותר שמערכת AI יכולה לתת. היא גם אחת התשובות שצריך לבדוק בזהירות. מה נבדק? איזה מקור נפתח? האם הכלי הצליח? והאם המסקנה מתאימה להיקף הבדיקה?
מודל שפה יכול לנסח תשובה ברורה גם כאשר המידע חלקי. לפעמים הוא יודע עובדה, לפעמים הוא מסיק אותה ולפעמים הוא רק משלים דפוס שנשמע סביר. מבחוץ שלוש התשובות עשויות להיראות דומות.
אמינות אינה סגנון כתיבה. היא קשר שניתן לבדוק בין טענה, מקור ופעולה. מערכת טובה צריכה לדעת לא רק לענות, אלא גם להבחין בין מה שראתה, מה שהסיקה ומה שלא הצליחה לאמת.
ארבעה מצבים שאסור לערבב
יש הבדל בין ידע שהמודל מביא מהאימון, מידע שסופק לו בשיחה, מידע שנשלף מכלי ומצב שנבדק במערכת חיצונית.
ידע מהאימון יכול להספיק להסבר כללי, אך אינו הוכחה למצב עדכני. מסמך בשיחה יכול לספק עובדות, אך ייתכן שהוא ישן או לא מוסמך. כלי חיפוש יכול למצוא כתובת, אך לא בהכרח לאמת את תוכנה.
גם קריאת כלי מוצלחת אינה תמיד סוף הבדיקה. שירות יכול לאשר שקיבל בקשה בלי שהפעולה הושלמה. צריך לקרוא את משמעות התוצאה, לא רק את קוד ההצלחה.
לכן כדאי לתכנן את המערכת סביב מצבי ידע מפורשים. ״נמצא מקור״, ״נקרא מקור״, ״הטענה נתמכת״ ו״הפעולה אומתה״ הם שלבים שונים.
מקור אמיתי יכול לתמוך בטענה הלא נכונה
תשובה עם מקורות נראית רצינית יותר. אבל קיומו של מקור אינו מוכיח שהטענה שמופיעה לידו נכונה.
כתבה יכולה לצטט תחזית, והמודל להציג אותה כתוצאה. דף מוצר יכול לתאר יכולת מתוכננת, והתשובה להציג אותה כזמינה. סקר יכול לדווח על ציפייה לחיסכון, והסיכום להפוך אותה לחיסכון שנמדד.
הבדיקה צריכה להיות ברמת הטענה: מה בדיוק המקור אומר, על איזו תקופה, באיזה הקשר ובאיזו רמת ודאות. יש להבחין בין דברי חברה על עצמה לבין מדידה עצמאית.
גם תאריך בתוצאת חיפוש אינו תמיד תאריך הפרסום המקורי. הוא יכול לשקף עדכון או אינדוקס. כאשר התאריך חשוב, בודקים אותו בגוף המקור או במידע הרשמי שלו.
העיקרון הזה חשוב גם במערכות RAG: שליפה טובה מביאה חומר רלוונטי, אבל עדיין נדרשת התאמה בין החומר למסקנה.
נאמנות למקור אינה אמת בעולם
נניח שמסמך ישן מציין מחיר מסוים. מודל שמעתיק אותו במדויק נאמן למסמך, אך התשובה יכולה להיות שגויה אם המחיר השתנה.
לכן יש לפחות שתי שאלות: האם התשובה נתמכת במקור, והאם המקור מתאים לשאלה הנוכחית. שאלה על מדיניות היום דורשת גרסה תקפה, לא רק מסמך שמכיל את המילים הנכונות.
Google DeepMind מפרידה ב־FACTS Benchmark Suite בין ידע פנימי, שימוש בחיפוש, הבנת תמונות וביסוס תשובה על הקשר. ההפרדה מדגימה שאמינות אינה יכולת אחת שנמדדת במבחן יחיד.
הסדרה הוצגה בדצמבר 2025. אין צורך להפוך את ציוני ההשקה שלה לדירוג עדכני של מודלים כדי ללמוד מהמבנה: מודל יכול להצליח יחסית בסוג אחד של בדיקה ולהתקשות באחר.
חיפוש מוצלח אינו בדיקה מוצלחת
חיפוש מחזיר מועמדים. לפעמים התוצאה הראשונה מתאימה, ולפעמים היא כתבה ישנה, עמוד שיווקי או עותק של אותו דיווח.
מערכת שמסכמת רק את התקציר עלולה לפספס תנאי חשוב. גם עמוד שנפתח בקוד HTTP תקין יכול להציג הודעת ״לא נמצא״ או חסימת גישה. צריך לבדוק את התוכן שהתקבל בפועל.
אם המקור חסום, אפשר לחפש מקור חלופי או לצמצם את הטענה למה שניתן לאמת. אין להציג קריאה מלאה שלא התרחשה.
כאשר כמה אתרים חוזרים על אותו מקור ראשוני, הם אינם בהכרח ראיות עצמאיות. עשר כתבות שמצטטות הודעת חברה אחת אינן עשרה ניסויים.
״לא ידוע״ יכול להיות התוצאה המקצועית ביותר
מודל שמרגיש מחויב לתת תשובה מלאה עלול להשלים פערים. מערכת אמינה צריכה לאפשר מצב שבו אין מספיק מידע להכרעה.
אין צורך למלא כל תשובה בהסתייגויות. צריך להצמיד את אי־הוודאות למקום המדויק: הנתון העדכני לא נמצא, המקורות סותרים או שהפעולה לא החזירה אישור.
ניסוח מועיל גם מסביר מה יאפשר להתקדם. במקום ״אולי״ כללי, אפשר לציין שנדרשת גרסת מדיניות בתוקף או תוצאת בדיקה ממערכת היעד.
כיול טוב הוא התאמה בין מידת הביטחון לבין הראיות. הביטחון שהמודל מצהיר עליו אינו הוכחה לכיול. צריך לבדוק כיצד ההצהרות שלו מתאימות לנכונות על פני אוסף מקרים.
בדיקת פעולה דורשת ראיה מסוג אחר
במשימת כתיבה, בודקים את התוכן. במשימת פעולה, צריך לבדוק גם מה השתנה במערכת.
אם סוכן התבקש ליצור קובץ, ראיה יכולה להיות קובץ קיים שנפתח ונבדק. אם התבקש לעדכן רשומה, בודקים את הערך שנשמר. אם התבקש לפרסם עמוד, צריך להבחין בין קובץ מקומי, העלאה לשרת ותצוגה באתר החי.
אין צורך לבצע בכל פעם בדיקה כפולה יקרה. רמת האימות צריכה להתאים להשלכות ולמנגנון שהמערכת מספקת. אבל אי אפשר להחליף ראיה בתיאור של הכוונה.
הדבר מרכזי בניהול סוכנים: ״המשימה הסתיימה״ הוא דיווח, ואילו תוצר שעבר תנאי קבלה הוא בסיס להחלטה.
דוגמה: ״האתר תקין״ היא טענה רחבה מדי
נניח שבודקים עמוד אינטרנט. בקשת HTTP שחזרה עם 200 מוכיחה שהשרת החזיר תשובה מוצלחת ברמת הפרוטוקול. היא אינה מוכיחה שהטקסט קריא, שהתפריט ממורכז או שהכפתור עובד.
צילום מסך יכול להראות תצוגה ברוחב מסוים. הוא אינו מוכיח שכל קישור תקין או שמובייל נראה אותו דבר. בדיקת DOM יכולה לזהות גלישה רוחבית, אך אינה מחליפה תמיד הסתכלות על היררכיה, ניגודיות וריווח.
לכן דוח מדויק מפרט מה נבדק: עמוד מסוים, רוחבים מסוימים ופעולות מסוימות. אם חלק לא נבדק, לא מרחיבים את המסקנה אליו.
זו דוגמה כללית לעיקרון רחב: היקף המסקנה לא צריך להיות גדול מהיקף הראיות.
איך בונים הערכה של תשובות
אוסף בדיקות צריך לכלול שאלות עם תשובה ידועה, שאלות עם מידע חסר, מקורות סותרים ונתונים שהתיישנו. אם בודקים רק שאלות שיש להן תשובה נוחה, לא מודדים את היכולת לעצור.
בתשובות ארוכות כדאי לפרק את הטקסט לטענות שניתנות לבדיקה. תשובה יכולה להיות נכונה ברובה ובכל זאת לכלול פרט מרכזי שגוי.
| ממד | מה בודקים |
|---|---|
| נכונות | האם הטענה עצמה נכונה? |
| ביסוס | האם המקור שנבחר תומך בה? |
| שלמות | האם נענו חלקי השאלה החשובים? |
| עדכניות | האם המידע מתאים לזמן שנשאל? |
| הימנעות | האם המערכת נמנעת מהכרעה כשחסרה ראיה? |
| ביצוע | האם פעולה מדווחת אכן הושלמה? |
אפשר להיעזר במודל שופט, אבל כדאי להשוות מדגם לביקורת אנושית. במספרים, מזהים ומצבי מערכת יש לעיתים בדיקה ישירה ואמינה יותר.
למה תשובות כלליות הן לפעמים סימן לבעיה עמוקה
תשובה גנרית יכולה לנבוע מבקשה עמומה, אבל גם מהיעדר גישה למידע. אם המערכת אינה יכולה לראות את המסמך או להפעיל את הכלי, היא עשויה לענות בהסבר כללי במקום לבצע את העבודה.
הפתרון אינו תמיד Prompt ארוך יותר. קודם בודקים אם קיימים קלט, הרשאה ויכולת מתאימים. לאחר מכן מגדירים תוצר ברור.
גם הוראה כמו ״תהיה מדויק״ אינה מספיקה. צריך להסביר מה נחשב דיוק במשימה: התאמת שדה למקור, הבחנה בין תכנון לביצוע או שימוש בגרסה תקפה.
הטמעת AI בעסק מתחילה בבניית התנאים האלה. בלי מקור אמת ותנאי קבלה, המודל נשאר עם ניסוח במקום עם עבודה.
זיכרון ותיאום יכולים להפיץ טעות
סיכום שיחה עלול להפוך טענה מסויגת לעובדה. תת־סוכן יכול לקבל את הסיכום ולהמשיך ממנו בלי לראות את המקור. כך טעות קטנה עוברת כמה שלבים ונראית מבוססת יותר בכל פעם.
כדי לצמצם זאת, שומרים מקור ותוקף ליד החלטות חשובות. מבדילים בין ממצא מאומת, הנחה והצעה. כאשר מעבירים משימה, מעבירים גם את החסר, לא רק את המסקנה.
כלי שמחזיר נתון אינו מקבל סמכות להורות על המשך העבודה. ההפרדה הזאת מחברת אמינות להגנה מפני Prompt Injection: גם מידע שנראה שימושי צריך להישאר בתפקיד המתאים לו.
השורה התחתונה
הדרך לשפר תשובות AI אינה רק לבקש ניסוח חד יותר. צריך לבנות מסלול שבו הטענות קשורות למקורות, הפעולות קשורות לתוצאות ואי־הוודאות נשארת גלויה במקום שבו היא חשובה.
מערכת אמינה אינה אומרת תמיד ״אני יודע״. היא יודעת להראות מה בדקה, להסביר מה אפשר להסיק ולציין מה עדיין חסר.
זו אינה חולשה של המוצר. זו הדרך להפוך אותו מכלי משכנע לכלי שאפשר לעבוד איתו.
שאלות נפוצות
האם מקורות בתשובה מבטיחים שהיא נכונה?
לא. צריך לבדוק שהמקור תומך בטענה, שהוא מתאים להקשר ושהוא עדכני.
האם כדאי לבקש מהמודל ציון ביטחון?
אפשר, אבל הציון לבדו אינו מדד אמין. יש לבדוק את הקשר בין ביטחון לנכונות על מקרים מייצגים.
האם תשובה קצרה פחות מועדת לטעות?
היא מכילה פחות טענות, אך יכולה להשמיט סייג חשוב. האורך צריך להתאים לשאלה ולראיות, לא להחליף בדיקת איכות.
מה עושים כאשר כלי נכשל?
מדווחים על הכשל, משתמשים בחלופה מתאימה אם קיימת ומצמצמים את המסקנה למה שניתן לאמת. אין לדווח שהפעולה הצליחה על בסיס כוונה בלבד.