מדוע אינדוקסציה של RAG בבסיסי ידע ארגוניים מניבה תשובות אשפה
אינדוקסציה של RAG בבסיס ידע ארגוני נראית כמו העלאת מסמכים לאחסון וקטורי, אך המודל בונה את התשובה לא מדף שלם, אלא מכמה קטעים שנמצאו. אם הקטע הורכב שלא כהלכה, המודל לא ישתוק — הוא ישלים את התשובה ביסודיות ויציג אותה באותה מידת ביטחון כמו תשובה נכונה.
המקור הראשון לתקלות — סימון לא אחיד. דפים ב-Confluence, Notion ו-SharePoint חיים בבלוקים מקוננים, תיבות טקסט ורשימות משימות; מנתח שטוח מסיר את ההיררכיה, וכותרת הסעיף מתנתקת מגוף התוכן שלה. לתוצאות נכנסים צעדים מהוראה סמוכה, וסדר הפעולות מאבד את משמעותו.
השני — גרסאות והעתקים. הוראה אחת נמצאת בשלושה מקומות ובשתי מהדורות; לאחר חלוקה לקטעים הן כמעט בלתי ניתנות להבחנה לפי הווקטור, והחיפוש במסמכים שולף כל אחת מהן.
טבלאות קרועות מוסיפות משלהן: פרמטרים נשארים בלי כותרות עמודות, וקבצים מצורפים — תרשימים ותקנות בקבצים — כלל לא נכנסים לאינדקס.
בסך הכול זה מניב תשובות לא רלוונטיות כשהחיפוש עובד לכאורה: המודל מקבל פסקאות סמוכות במקום הסעיף הנדרש וממלא את החסר בניחוש. איכות התוצאות יורדת לא בגלל המודל, אלא בגלל מה שהוגש לו.
בהמשך נפרט כיצד זה נסגר: ניתוח מבני של הסימון, חלוקה לבלוקים סמנטיים במקום אורך קבוע, הסרת כפילויות של מהדורות ומעברים נפרדים לטבלאות ולקבצים מצורפים.
מה משתנה אחרי בנייה מחדש מבוקרת של החיפוש בבסיס
הדבר הראשון שמשתנה הוא שהתוצאות מפסיקות להיות תלויות בשאלה אם העובד ניחש נכון את הניסוח. חיפוש היברידי משלב התאמה מדויקת של מילים וקרבה וקטורית, ודירוג מחדש מעלה למעלה קטעים שבהם באמת נמצאת התשובה.
אנו אינדקסים מרחבים של Confluence, Notion ו-SharePoint במעגל RAG אחיד: המקורות נשארים במקומם, ורק שכבת החיפוש משתנה.
שלמות התוצאות והסתמכות על המקור
לפני הבנייה מחדש הדפים היו מאונדקסים בשלמותם: מסמך ארוך התמוסס לווקטור אחד, והפסקה הנדרשת לא נכנסה לטופ. לאחר חיתוך לבלוקים סמנטיים עם חפיפת הקשר, שיעור השאילתות שבהן הקטע הנכון נכנס לחמישייה הראשונה עלה מ-61% ל-93%.
תשובות בלי הסתמכות על מקור פחתו בערך פי ארבעה — אם אין בלוק רלוונטי, המערכת מודיעה על כך ולא משלימה את הניסוח.
מהירות התשובה ועדכניות בסיס הידע
שלמות התוצאות חסרת תועלת אם התשובה מגיעה כעבור חצי דקה: אנשים חוזרים לחיפוש ידני בתיקיות. אנו שומרים על מהירות תגובה צפויה בעומס שיא — תור השאילתות מטופל בשניות בודדות, משום שהתוצאות והדירוג מחדש נשמרים במטמון לפי שאילתה מנורמלת.
עדכון האינדקס מתבצע לפי אירוע: עריכת דף נכנסת לחיפוש תוך דקות, ולא בתוך יממה, וקישורים שבורים לסעיפים ששמם שונה כבר לא צצים.
התוצאה נמדדת לא לפי "נהיה נוח יותר", אלא לפי שיעור התשובות עם מקור מאומת, זמן התגובה תחת עומס והקצב שבו בסיס הידע מדביק את השינויים. בהמשך — כיצד המדדים האלה נראים בבסיס קונקרטי לפני ואחרי.
בנייה מחדש מלאה, אינקרמנטלית והיברידית: מה לבחור
מצב עדכון האינדקס הוא חלק מהתחייבויות השירות, ולא פרט מימוש: ממנו תלוי באיזו מהירות תשובה חדשה מופיעה בחיפוש וכמה עומס עובר למערכות המקור. הבחירה נקבעת לפי שני מדדים — שיעור המסמכים המשתנים ביממה ופער האינדקס המותר מעריכת המקור. בלעדיהם השירות או עונה לפי גרסאות מיושנות, או קורא שוב ושוב את מאגרי המידע בשלמותם.
נשווה שלושה מצבים לפי נפח הנתונים למחזור, רגישות לתדירות העריכות ודרישות הזמינות בזמן הבנייה.
| מצב | מתי מתאים | מגבלות |
|---|---|---|
| בנייה מחדש מלאה | עריכות נדירות בקבוצות, קיים חלון תחזוקה | קורא את כל הקורפוס: בנפח גדול המחזור נמשך שעות |
| בנייה אינקרמנטלית | זרימת עריכות נקודתית ואחידה | יש לעקוב אחר שינויים ומחיקות; בעת שינוי סימון מצטברים פערים |
| אינדקס היברידי | מקורות מעורבים: חלקם משתנים לעתים קרובות, אחרים יציבים | שני מעגלי עדכון, נדרשת בדיקת שלמות וניקוי קטעים מיושנים |
כיצד לבחור מצב לפי זרימת השינויים
מסתכלים על פרופיל העריכות, לא על גודל הבסיס. זרימה אחידה של שברי אחוז מהדפים ביממה נסגרת בבנייה אינקרמנטלית; שינויים מבניים או בסימון מרובים ונדירים — סיבה להפעיל מעת לעת בנייה מלאה ולהחזיק אינדקס היברידי.
את המעבר עושים בלי השבתה: הגרסה החדשה נבנית בצד, מופעלת לאחר בדיקות על שאלות בקרה, והחזרה לאחור — לגרסה הקודמת.
שלבי אינדוקסציה של RAG: מביקורת מקורות ועד קבלה
סדר העבודה זהה לכל קבוצת מקורות. תחילה מתעדים מה באמת נמצא במאגרים ובאיזו תדירות הוא משתנה, ורק אחר כך בונים את האינדקס — אחרת חלק מהמסמכים לא נכנסים לחיפוש, וחלק מהם ממשיכים להתקיים כהעתקים מיושנים.
- ביקורת מקורות. עוברים על מרחבים וסעיפים ב-Confluence, Notion ו-SharePoint: נפח, תדירות עריכות, בעלים, כפילויות. סעיפים סגורים או מוציאים החוצה, או מסמנים ברמת גישה כדי שההרשאות יישמרו גם בתוצאות.
- סכמת חלוקה. חותכים לפי בלוקים סמנטיים — כותרות, טבלאות, צעדי הוראות, ולא לפי חלון קבוע. גודל קטע אחיד לתקנון ולהתכתבות יוצר קטעי משמעות קרועים במעברים.
- מטא-נתוני מסמך. לכל קטע משייכים מקור, סעיף, בעלים, תאריך שינוי ורמת גישה. בלעדיהם לא עובדים מסננים לפי מרחבים ושליפת מסמך מהאינדקס.
- צינור עדכון. מגדירים אינדוקסציה מחדש אינקרמנטלית לפי אירועי שינוי ומחיקה, ומעבר מלא לפי לוח זמנים — ככיסוי לאירועים שהוחמצו.
- בדיקת איכות. אוספים סט בקרה של שאלות עם תשובות ייחוס ובודקים אם הקטע הנדרש נכנס למיקומים הראשונים. פספוסים מנתחים בנפרד: לרוב אלה כפילויות או גרסה מיושנת.
- מסירה לתפעול. מתעדים נוהל אינדוקסציה מחדש, אחראי לאיכות הבסיס וסדר חיבור מקורות חדשים. הקבלה נעשית על הנתונים שלכם, ולא על סט הדגמה.
סכמות חלוקת טקסט, מדיניות גישה ותקנות עדכון
אינדוקסציה אינה הפעלה חד-פעמית, אלא אוסף ארטיפקטים שנשארים במערכת שלכם וממשיכים לחיות חיים עצמאיים. אנו מוסרים אותם יחד עם הבנייה העובדת: לכל סעיף יש לצוות שלכם קובץ או נוהל, ולא הסכמות בעל פה.
- מפת מקורות. אילו מרחבים, סעיפים ומאגרים נכנסים לאינדקס, מי הבעלים של כל אחד, מה הוחרג במכוון ולפי החלטת מי.
- כללי ירושת הרשאות. הרשאות ממערכת המקור מועברות לאינדקס לפי אותה היררכיה: העובד מקבל בתשובה רק את הקטעים הפתוחים לו בויקי או במאגר עצמו.
- תצורות בנייה. סכמות חלוקה לפי סוגי מסמכים — תקנונים, טיקטים, טבלאות, התכתבות — עם גודל קטע וחפיפה לכל סוג.
- נוהל עדכון. תדירות אינדוקסציה מחדש לפי מקורות, טיפול במסמכים שנמחקו או הועברו, התנהגות בעת שינוי הרשאות גישה.
- מדדי איכות. סט שאלות בקרה, שיעור תשובות עם קישור לקטע מאמת, שיעור סירובים כנים "לא יודע", דינמיקה לפי איטרציות.
- הוראות לצוות. כיצד לחבר מקור חדש, כיצד לשלול גישה, מה לעשות אם התשובה סותרת את מסמך המקור.
תמיכה בלעדינו
כל האמור לעיל — תצורות עבודה ונוהלים טקסטואליים, ולא קוד סגור: מקור חדש או מדיניות גישה שהשתנתה מתוקנים בידי המהנדסים שלכם באיטרציה אחת. אנו מתחברים כשמשתנה הקורפוס עצמו של המסמכים — אז בוחנים מחדש את סכמות החלוקה ואת ספי מדדי האיכות.
מקרה בוחן: כיצד צמצמנו את שיעור התשובות הלא רלוונטיות בתמיכה
לפני ההטמעה בסיס הידע חי בשלוש מערכות: תקנונים — ב-Confluence, הערות מוצר — ב-Notion, תבניות מכתבים — ב-SharePoint. החיפוש עבד לפי מילות מפתח, ולכן על השאלה "כיצד להסדיר החזרה" המפעיל קיבל עשרה דפים והחליט בעצמו איזה מהם בתוקף. התשובות נשלחו ללקוחות בלי הסתמכות על מסמך, ופערים צפו כבר בשלב הפנייה החוזרת.
ריכזנו את המקורות באינדקס אחד, חילקנו את המסמכים לקטעים לפי היררכיית הכותרות ושמרנו מטא-נתונים: בעלים של הסעיף, תאריך העריכה האחרונה, סטטוס "בתוקף/ארכיון".
למעגל התשובה הוספנו סף ביטחון — אם אין די עוגן במסמכים, המערכת לא ממציאה, אלא מעבירה את השאלה למפעיל יחד עם הקטעים שנמצאו.
דינמיקת המדדים
| מדד | לפני | אחרי |
|---|---|---|
| תשובות בלי הסתמכות על מסמך | 38% | 6% |
| שיעור תשובות לא רלוונטיות | 31% | 8% |
| זמן הכנת תשובה | 7 דקות | 45 שניות |
| פניות עם בירור חוזר | 44% | 13% |
| תשובות עם קישור למקור | אין | 100% |
משוב מהצוות
המפעילים הפסיקו להשוות ידנית בין שלוש מערכות: קישור למסמך המקור מסיר את המחלוקת בדבר מקור הניסוח. מנהל התמיכה מציין דבר אחר: עובדים חדשים מגיעים לתשובות עצמאיות במהירות רבה יותר, משום שהמערכת מרמזת היכן נמצא הנוהל.
העריכות בבסיס הפכו נקודתיות. לפי הלוגים רואים איזה קטע הניב תשובה שגויה — מתקנים סעיף מסוים, ולא את כל התקנון, ולאחר אינדוקסציה מחדש התיקון נכנס מיד לתשובות.
מה לעשות אם בסיס הידע כבר מאונדקס בידי שירות חיצוני?
תחילה מבררים מה נותר מהשירות החיצוני: פרמטרים של חלוקה לקטעים, הרכב המטא-נתונים, התחשבות בהרשאות גישה. אם זה קיים בייצוא — מעבירים את ההגדרות ומשלימים את החסר; אם נמסרו רק וקטורים מוכנים בלי מבנה, נקי יותר לבצע אינדוקסציה מחדש של המקורות ישירות. אינדקס בלי מטא-נתונים כמעט תמיד מניב תוצאות גרועות יותר.
שני הפסדים נראים מיד. הרשאות: המסמכים אונדקסו תחת חשבון שירות — הירושה אבדה, והתשובה כוללת דפים שאינם נגישים לשואל. כפילויות: הוראה אחת במרחבים שונים של Confluence, בקובץ מצורף ובעותק אישי יוצרת שלושה קטעים דומים ודוחקת את השאר. מטפלים בכך באמצעות הסרת כפילויות לפי גיבוב תוכן וקנוניזציה של קישורים.
הגירה רכה בלי השבתה: האינדקס החדש נבנה לצד הישן, מתמלא בצילום מצב של המקורות ומדביק שינויים. השאילתות עדיין הולכות לישן, ואל החדש עוברת אותה בחירה במצב צל — את האיכות משווים על זרם חי.
המעבר מתבצע לפי דגל, כשהמדדים תואמים; החזרה לאחור באותו דגל, ואת האינדקס הישן מחזיקים ברזרבה כמה שבועות.
את הגישות משווים לפי שלושה תרחישים: העברת הגדרות — מהיר, אך יורש טעויות חלוקה ישנות; הפעלה מקבילה — יקרה יותר במשאבים, אבל בודקת איכות על שאלות אמיתיות; אינדוקסציה מחדש מלאה — הצפויה ביותר, ודורשת חלון למעבר הראשון.
קבלה — שאלות ייחוס עם תשובות ידועות: שיעור הפגיעות של הקטע הנדרש בשלישייה הראשונה ואפס תשובות לפי מסמכים שמחוץ להרשאות המשתמש.
ספקות טכניים: הרשאות גישה, סימון, אובדן הקשר
הספקות בשלב ההערכה הם בדרך כלל אותם ספקות: מי יראה את הקטע, מה לעשות עם טבלאות וקבצים מצורפים, והאם המשמעות תתפרק בחיתוך. כל זה נסגר ברמת צינור האינדוקסציה: לכל קטע יש בעלים ומטא-נתונים, והחיפוש מסנן מועמדים לפיהם לפני שהטקסט מגיע למודל.
כיצד עוברות בירושה הרשאות הגישה לקטעים?
ההרשאות נקראות מהמקור יחד עם התוכן — דף, מרחב, קבוצות, חריגים אישיים — ונשמרות באינדקס לצד הקטע. החיפוש בודק אותן עבור משתמש מסוים לפני ההצגה: חלק שאינו נגיש לא נכנס לבחירה, והמודל אינו רואה אותו. שינוי הרשאות נקלט בסנכרון הבא.
האם טבלאות וקבצים מצורפים יהפכו לעיסה?
טבלאות מנותחות מבנית: השורה וכותרת העמודה נשמרות, אחרת הערך מאבד את משמעותו. קבצים מצורפים — מסמכים, מצגות, PDF — עוברים צינור נפרד ומשויכים לדף האב. לכל קטע נשאר קישור לסעיף המקור, וניתן לבדוק את התשובה במקור.
כיצד לא לאבד הקשר בזמן החיתוך?
הקטעים נחתכים לפי גבולות סמנטיים עם חפיפה, וכותרות הסעיפים והנתיב בעץ הדפים נכתבים למטא-נתונים. למודל לא נשלח קטע בודד, אלא קטע יחד עם ההיררכיה. זה מפחית את שיעור התשובות שבהן משפט שנקרע מהקשרו מפורש שלא כהלכה.
מה עם דפים מיושנים וסתירות?
גרסאות מוסרות כפילויות לפי תוכן, ובמקרה של התנגשות עדיפות ניתנת לקטע עדכני יותר ומאושר בידי הבעלים. מרחבים ארכיוניים וטיוטות מוחרגים מהאינדקס לפי כלל מפורש.
מסמכים בשפות שונות?
מקורות רב-לשוניים מאונדקסים במרחב וקטורי אחיד: השאלה והמסמך מובאים לייצוג משותף, ולכן הרלוונטי נמצא ללא תלות בשפת הדף. התשובה מנוסחת בשפת השאלה.
נדון במשימה: מהיכן נתחיל ומה יידרש מכם
כדי לחזור עם הערכה, ולא עם מילים כלליות, נדרש מאיתנו מינימום של נתוני פתיחה: היכן נמצא הידע, באיזו מהירות הוא משתנה ומי אחראי על ההרשאות. ניתוח המשימה הראשוני הוא שיחה אחת עם מהנדס, שבה אנו בוחנים את מבנה המקורות ומסכמים על תוכנית עבודה. להלן — מה להכין לפגישה הזו.
- ביקורת מקורות. רשימת מרחבים ב-Confluence, מאגרי Notion, ספריות SharePoint, מאגרי קבצים ופורטלים פנימיים — עם ציון מה באמת בשימוש בעבודה ומה נשאר ארכיון ולא ייכנס לאינדקס.
- תדירות עריכות. באיזו מהירות דפים מתיישנים, האם קיים נוהל פרסום, מי עוקב אחר העדכניות והאם יש צורך באינדוקסציה מחדש של הכול או שמספיק תוכן שהשתנה.
- הרשאות וייצוא. חשבון שירות עם הרשאת קריאה, ייצוא דפים בפורמט פתוח או צילום מצב חד-פעמי של הבסיס. אם המערכת סגורה — נדון בבנייה בתוך הרשת שלכם.
- מגבלות נתונים. סעיפים שאסור לאנדקס: כוח אדם, חוזים, נתונים אישיים. את החריגים מכניסים לכללי האיסוף כבר בהתחלה, ולא אחר כך.
- תרחישים צפויים. 5–10 שאלות אמיתיות שהעוזר צריך לענות עליהן — לפיהן רואים אילו סוגי מסמכים קריטיים ואילו אפשר לא לגעת.
- אחראי על הקבלה. אדם אחד מצדכם שמאשר את שלמות התשובות ומכריע במקרים שנויים במחלוקת בשלב ההגדרה.
לאחר הניתוח אנו שולחים תוכנית עבודה: הרכב האינדקס, מצב העדכון, סכמת בדיקת תשובות על סט בדיקה והערכת לוחות זמנים לפי שלבים. תארו את המשימה — נחזור עם הערכה ותוכנית.