הטמעת מערכת בדיקת עובדות עבור תשובות AI

Fact-checking AI: היכן נשברת מהימנות התשובות

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

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

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

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

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

מה נותנת בדיקת עובדות: אפקטים מדידים של הטמעה

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

• שיעור התשובות הלא מהימנות. על מדגם ביקורת של כמה מאות שאלות הוא יורד מ-10-20% ל-2-4%: כל טענה בתשובה או מאושרת על ידי קטע מהבסיס, או מסומנת כהנחה ומנוסחת מחדש.
• שיעור הטענות עם מקור מאושר. רמת היעד — 90% ומעלה: לכל עובדה בתשובה יש הפניה למסמך או לפרק מסוים, והיא נראית בממשק. השאר — לא «הזיות», אלא פערים בנתונים המסומנים במפורש.
• בירור תשובות שנויות במחלוקת. לתור נפרד נכנסים 3-6% מהתשובות — אלו שבהן הבדיקה לא הצליחה לאשר את העובדה או שציון הביטחון נמוך מהסף. הבירור מתבצע לפי יומן עם הקשר שמור, וזמן התגובה הממוצע — שעות, לא ימים.
• איכות בסיס הידע. הבדיקה מאירה אילו קטעים בבסיס מפריכים את התשובות לעיתים הקרובות ביותר: תקנונים מיושנים, כפילויות, קטעי טבלאות. לאחר הניקוי שיעור התשובות הדורשות תיקון ידני יורד פי כמה — זה כבר טיפול בסיבה, ולא בתוצאה.
• מהירות וצפיות של שחרורים. ההערכה על סט מתויג (RAGAS ומדדים דומים לנאמנות למקור) משולבת במסלול העלייה לאוויר: רגרסיה נראית לפני השחרור, ועדכון של המודל או הבסיס לא עובר אם שיעור התשובות המאושרות ירד.

שיטות לבדיקת עובדות: השוואה בין גישות טכניות

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

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

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

שלבי הטמעת מערכת בדיקת העובדות

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

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

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

מה מוסרים יחד עם הפתרון: קונפיגורציות ונהלים

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

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

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

מקרה בוחן: כיצד הפחתנו את שיעור התשובות הלא מהימנות בחצי

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

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

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

את המהימנות מחשבים על סט רגרסיה מאותן שאלות שנויות במחלוקת, ואת התיוג עושים ידנית — RAGAS נותן מדדים של קישור להקשר, אבל ההחלטה «מהימן או לא» נשארת בידי האדם.

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

במה נבדלת בדיקת עובדות AI בזמן אמת מבדיקה בדיעבד?

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

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

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

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

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

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

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

שאלות טכניות נפוצות על מערכת בדיקת העובדות

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

האם זמן התשובה יגדל?

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

האם היא תתחבר לעוזר קיים?

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

כיצד למדוד את התוצאה?

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

מה אם הבדיקה מפריעה?

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

נדון במשימה שלכם: ממה נתחיל את בדיקת העובדות

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

בשיחה הראשונה מחדדים את נתוני הקלט:

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

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