Citation Architecture — כיצד מבטיחים שלכל טענה יהיה מקור אמיתי

מאת צוות מדיה דיל · 12.08.2026 · AI Retrieval · 5 דק׳

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

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

שרשרת ציטוט: מ-chunk ועד משפט

ארכיטקטורת ציטוט אמינה דורשת מעקב provenance ברמת דיוק גבוהה בהרבה מ"המסמך הזה נשלף". הרמה הראשונה היא chunk-level attribution — כל קטע טקסט שנשלף שומר מזהה ייחודי, מספר עמוד, ומיקום מדויק במסמך המקור. הרמה השנייה, המדויקת יותר, היא sentence-level attribution — כשמודל השפה מייצר תשובה, כל משפט בתשובה מקושר לא רק ל-chunk אלא לטווח תווים ספציפי בתוכו שממנו הוא נגזר. ברוב היישומים המעשיים, הדרך הטובה ביותר להשיג את זה היא generation מובנה (structured output) שבו מבקשים מהמודל להחזיר לא טקסט חופשי אלא רשימת אובייקטים {claim, source_chunk_id, source_span}, ורק אז מרנדרים אותם לטקסט קריא עם הפניות. זה שונה מהותית מלבקש "תוסיף ציטוטים" בסוף התשובה — גישה שמייצרת בדיוק את בעיית הציטוט הלא-נאמן שתיארנו, כי המודל מנסה "להתאים" ציטוט אחורה לטענה שכבר ניסח, במקום לבסס כל טענה קדימה על המקור.

אימות אוטומטי: NLI כשומר סף

גם עם generation מובנה, מודלים עדיין טועים. הרכיב שסוגר את הפער הוא שכבת אימות שרצה אחרי הייצור ולפני החזרת התשובה למשתמש: עבור כל זוג (טענה, מקור מצוטט), מריצים בדיקת Natural Language Inference (NLI) — מודל ייעודי (או קריאת LLM נפרדת עם פרומפט ממוקד) ששואל "האם המקור הזה תומך בטענה הזו, סותר אותה, או לא קשור?". טענות שמסומנות כ"לא נתמכות" (not entailed) לא מוצגות למשתמש עם רמת ביטחון גבוהה — הן מסומנות, מוסרות, או שהמערכת מבצעת סבב retrieval נוסף כדי למצוא מקור טוב יותר. זו בדיוק אותה טכניקת reranking שמשמשת לדירוג רלוונטיות בשלב השליפה, כמתואר במדריך Reranking ב-RAG, רק שכאן היא מופעלת בכיוון ההפוך — לא לדרג מסמכים לפי רלוונטיות לשאילתה, אלא לבדוק אם משפט ספציפי נתמך על ידי מקור ספציפי.

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

מה קורה כשאין מקור טוב

מערכת citation architecture בשלה צריכה להתמודד בכנות עם המקרה שבו retrieval פשוט לא מצא מקור שתומך בטענה שהמשתמש רוצה תשובה עליה. ברירת המחדל הנכונה היא לא "לייצר תשובה בלי ציטוט" (שחוזרת לבעיית ההזיה) אלא להחזיר תשובה מפורשת שאין מקור זמין, ואם אפשר — להציע לבצע חיפוש נוסף או להרחיב את מקורות המידע. זה דורש שהפרומפט למודל יאפשר במפורש את התשובה "אין לי מספיק מידע מבוסס-מקור לענות על זה", ושהאפליקציה תתמוך ב-state הזה בממשק המשתמש במקום לצפות שהתשובה תמיד תהיה מלאה. גישה עקבית לזה מחייבת גם קישור לדיון הרחב יותר על תכנון שאילתות מרובות-מקורות במדריך Query Planning, כי לפעמים "אין מקור" פירושו רק שהמקור נמצא במקום אחר שעדיין לא נבדק.

עיצוב ממשק: איך מציגים ציטוט שאפשר לבדוק

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

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

מדידת שיעור ציטוט תקין כמדד מוצר

ארגונים רציניים בתחום הזה לא מסתפקים בבדיקה איכותית מדי פעם אלא מגדירים מדד כמותי קבוע: Citation Accuracy Rate — האחוז מתוך כלל הטענות שנבדקו (על ידי NLI אוטומטי או דגימה אנושית) שבו הציטוט אכן תומך בטענה. מדד כזה, שנמדד באופן שוטף על מדגם מתעבורת הייצור, הופך את איכות הציטוט למשהו שאפשר לעקוב אחריו לאורך זמן ולזהות רגרסיה — למשל אחרי שינוי במודל, בפרומפט, או בשכבת ה-chunking שמזינה את ה-retrieval. בלי מדד כזה, ירידה באיכות הציטוט יכולה להימשך שבועות בלי שאף אחד ישים לב, כי אין שגיאה גלויה שמפעילה התראה — בדיוק כמו בעיות עדכניות שקטות שנשארות בלתי מזוהות עד שהן צוברות נזק ממשי.

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

ציטוט ומידע תלוי-זמן

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

תגיות: Citation · Provenance · NLI · RAG · Hallucination · Structured Output

← חזרה לבלוג · צור קשר