בדיקת מקורות בתוצרי AI: מה לדרוש לפני מסירת דוח?

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

הסיפור שממחיש את בעיית האחריות

באוקטובר 2025 דיווח The Register על תיקון דוח של Deloitte עבור משרד ממשלתי באוסטרליה לאחר שנמצאו בו אסמכתאות שגויות, ועל גילוי השימוש ב־AI בגרסה המעודכנת. זהו דיווח עיתונאי היסטורי. עמוד הפרסום הרשמי של המשרד מציין תיקון נוסף בפברואר 2026, שהחליף את הגרסה שפורסמה באוקטובר 2025. לכן אין להתייחס לגרסה שנדונה בכתבה כאל הגרסה הנוכחית.

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

בונים מפת טענות ולא רק רשימת מקורות

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

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

מגדירים בדיקת קבלה שאפשר להדגים

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

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

מה אנחנו מתעדים בתהליך הפרסום של Julius?

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

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

מי בודק ומה קורה אחרי תיקון?

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

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

מה לבקש בהצעת פיתוח AI?

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

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