אינדוקס מסמכים עבור RAG (PDF, DOCX, HTML, Markdown)

אינדוקס מסמכים ב-RAG: היכן אובדת איכות התשובות

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

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

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

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

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

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

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

מה נותן אינדוקס מנוהל: אפקט במדדים מדידים

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

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

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

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

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

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

השוואת מצבי הכנה: PDF, DOCX, HTML ו-Markdown

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

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

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

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

סדר ההטמעה: מביקורת הקורפוס ועד למסירה

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

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

תצורות, סכמות ניתוח ותקנוני עדכון

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

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

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

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

מה היה לפני בנייה מחדש

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

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

מה שינו

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

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

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

• שיעור התשובות לפי הפרק המעודכן — מ-60 ל-94%;
• זמן חיפוש המקטע הנדרש — מ-10 ל-1.5 שניות;
• פניות עם טיפול ידני — מ-20 ל-4%;
• מסמכים עם טבלאות שנותחו כראוי — מ-55 ל-97%.

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

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

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

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

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

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

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

ספקות טכניים נפוצים לפני תחילת הפרויקט

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

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

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

האם אפשר לעדכן את הבסיס בלי בנייה מחדש מלאה?

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

איך הרשאות גישה נכנסות לתוצאות החיפוש?

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

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

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

איך לוודא שהחיפוש מוצא את הנדרש?

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

נדבר על המשימה: מה יידרש להערכת היקף העבודה

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

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

• הרכב הקורפוס: כמה קבצים ופרקים, היכן הם נמצאים — מאגר קבצים, פורטל פנימי, ארכיון דואר, בסיס ידע.
• פורמטים ואיכותם: PDF עם סריקות ללא שכבת טקסט, DOCX עם עקיבות שינויים, HTML, Markdown במאגר קוד. סריקות משנות את היקף העבודה — הן דורשות שלב זיהוי נפרד.
• דינמיקה: כמה מסמכים נוספים בחודש, האם יש מהדורות מיושנות שאסור להציג בתשובות.
• שאלות נפוצות של משתמשים: 20–30 ניסוחים אמיתיים. לפיהן אנו אוספים סט בדיקה ולפני ההטמעה רואים אילו נתונים חסרים בקורפוס.
• סכמת הרשאות הגישה הנוכחית: אילו קבוצות רואות מה. ממנה תלויה ההפרדה ברמת המקטעים ואיך נכנסים לאינדקס מסמכים עם מגבלות.
• נקודות החזרת תשובה: פורטל פנימי, מסנג'ר, עמדת נציג — מכך תלוי פורמט התוצאה וההפניות למקור.
• מגבלות: היכן אסורים שירותים חיצוניים, האם נדרשים יומני פניות ושמירת היסטוריית שאילתות.

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