Synthetic Knowledge Distillation — הפיכת מסמכים רבים לבסיס ידע ממוקד

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

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

צוות תמיכה טכנית בחברת SaaS צבר במשך שנים 4,000 טיקטים סגורים, 300 מסמכי תיעוד, ו-150 שרשורי Slack פנימיים — כולם מלאים בידע חשוב, אבל מפוזרים, סותרים חלקית, וחוזרים על עצמם. הזנת כל זה כמו שהוא ל-Vector Database נתנה תוצאות בינוניות: אותה שאלה החזירה חמישה chunks כמעט זהים מחמישה טיקטים שונים, אחד מהם מכיל מידע שגוי שתוקן בטיקט מאוחר יותר, ואף chunk בודד לא נתן תשובה מלאה כי הידע היה מפוזר בין כמה מקורות. הפתרון לא היה "יותר chunks" אלא פחות — תהליך זיקוק (distillation) שממיר את הים הגולמי הזה לבסיס ידע קומפקטי, מאורגן ומאומת.

למה יותר מסמכים לא שווה יותר ידע

יש כשל אינטואיטיבי נפוץ: ככל שיש יותר מסמכי מקור ב-Vector Database, המערכת "יודעת יותר". בפועל ההפך קרוב יותר לאמת ברוב היישומים המעשיים. קורפוס גדול ומלא כפילויות מייצר שלוש בעיות מובהקות: דילול איתות — אם אותה עובדה מופיעה ב-10 מסמכים בניסוחים שונים במקצת, top-k retrieval עלול להחזיר 8 גרסאות של אותה עובדה במקום לכסות 8 עובדות שונות; סתירות פנימיות — מסמכים ישנים וחדשים סותרים זה את זה בלי סימון מפורש מי הגרסה הנכונה; ועלות — אינדוקס וחיפוש בקורפוס גדול יקרים יותר, גם כשרוב התוכן מיותר. Distillation פותר את שלושתם על ידי הפיכת מקורות רבים לבסיס עובדות (facts) מצומצם, מאוחד וללא כפילות, שכל אחת מהן מתויגת חזרה למקורות שתמכו בה.

תהליך הזיקוק: Map-Reduce על עובדות, לא על טקסט

הטעות הנפוצה בניסיון "לסכם" קורפוס גדול היא הרצת סיכום היררכי רגיל (map-reduce summarization) שמייצר פסקאות תמציתיות — אבל פסקה תמציתית מאבדת בדיוק את הפירוט שהופך מסמך מקור לשימושי לצורך ציטוט. הגישה שעובדת טוב יותר היא זיקוק ברמת עובדה אטומית: במקום לסכם מסמך לפסקה, מחלצים ממנו רשימת טענות בודדות, כל אחת עצמאית ומדויקת ("טיימאאוט ברירת המחדל של ה-API הוא 30 שניות, עודכן מ-10 שניות בגרסה 4.2"), עם מקור מדויק לכל אחת. בשלב הבא מריצים דה-דופליקציה על העובדות עצמן — לא על המסמכים — באמצעות חיפוש דמיון סמנטי בין העובדות: עובדות דומות מאוד מתמזגות לעובדה אחת, כשמקורות ה-provenance של כולן נשמרים יחד. עובדות סותרות (שני מקורות טוענים ערכים שונים לאותו dimension) מסומנות במפורש כמחלוקת, לא נבחרות אוטומטית אחת על חשבון השנייה — הבחירה איזו נכונה יותר צריכה להישאר בידי בן אדם או להיפתר לפי טריות (freshness), כמפורט במדריך Knowledge Freshness.

שמירת עקיבות למקור המקורי

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

מבחינה מעשית, בסיס ידע מזוקק היטב הוא לרוב קטן פי 5-20 מהקורפוס הגולמי, מה שהופך אותו למתאים במיוחד לשילוב קומפקטי בזיכרון שיחה מבוסס-גרף, כמתואר בהרחבה במדריך GraphRAG, או לשילוב מלא בפרומפט המערכת (system prompt) בלי retrieval כלל, עבור תחומים שבהם בסיס הידע יציב יחסית ולא ענק.

Pipeline מעשי: מה קורה מסמך אחרי מסמך

תהליך זיקוק בפרודקשן בנוי בדרך כלל כשרשרת שלבים ברורה: (1) chunking — חלוקת המסמך הגולמי ליחידות שניתן לעבד; (2) extraction — קריאת LLM שמחלצת מכל chunk רשימת טענות אטומיות במבנה JSON, כל אחת עם ציטוט מדויק מהמקור; (3) clustering — קיבוץ טענות דומות מכלל הקורפוס באמצעות embeddings, כדי לזהות מועמדים למיזוג; (4) merge/conflict detection — קריאת LLM נוספת שבודקת בתוך כל אשכול אם הטענות זהות במשמעות (ואז ממזגת) או סותרות (ואז מסמנת מחלוקת); ו-(5) validation — בדיקה אקראית או שיטתית על ידי בן אדם על מדגם מהעובדות שהופקו, כדי לתפוס טעויות חילוץ שיטתיות לפני שהן מגיעות לייצור. השלב האחרון הזה קריטי ולעיתים קרובות מדולג — אבל בלעדיו, שגיאת חילוץ קטנה (מספר שהובן לא נכון, יחידת מידה שהתבלבלה) יכולה להתרבות על פני מאות עובדות מזוקקות בלי שאף אחד ישים לב.

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

נקודה חשובה נוספת בתכנון ה-pipeline היא הטיפול במסמכים חדשים שמצטרפים לקורפוס אחרי הריצה הראשונית. הרצה מלאה מחדש של כל שלבי הזיקוק בכל פעם שנוסף מסמך אחד היא בזבזנית ולא מדרגית (scalable). הגישה הנכונה היא זיקוק אינקרמנטלי: מסמך חדש עובר extraction בנפרד, והעובדות שהופקו ממנו נבדקות מול בסיס הידע הקיים רק בשלב ה-clustering וה-merge — כלומר, במקום להשוות כל עובדה חדשה מול כל עובדה קיימת (יקר ומתכלה בקנה מידה), משתמשים בחיפוש דמיון מהיר (approximate nearest neighbor) כדי לאתר רק את המועמדים הרלוונטיים למיזוג, ורק אותם בודקים בקריאת LLM מלאה.

מתי לזקק ומתי להשאיר גולמי

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

תגיות: Knowledge Distillation · Deduplication · Provenance · Knowledge Base · RAG · Fact Extraction

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