הטמעת Multi-Index RAG: איחוד מספר מקורות

למה Multi-Index RAG: אינדקס אחד לא מסוגל להתמודד עם נתונים הטרוגניים

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

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

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

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

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

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

דיוק התשובות וכיסוי מלא

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

במדידות זה נותן עלייה בשיעור התשובות הנכונות מ-60% ל-85% ובכיסוי — שיעור השאלות שבבסיס הנתונים יש בכלל על מה להסתמך — מ-70% ל-95%. זמן התגובה נשאר בתקציב: המיזוג והדירוג מחדש מוסיפים כ-200 מ"ש כאשר היעד הוא עד שתי שניות.

עמידות בפני כשל של מקורות בודדים

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

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

סכמות Multi-Index RAG: ניתוב, מיזוג, פדרציה

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

ניתוב שאילתות

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

מיזוג תוצאות

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

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

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

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

ביקורת מקורות ומפת נתונים

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

הגדרת חיפוש ובדיקה על שאלות ייחוס

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

חפצי הטמעה: סכמות, קונפיגורציות, נהלים

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

סכמת זרימות נתונים

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

נהלי עדכון וגישה

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

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

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

מצב התחלתי

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

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

מה השתנה לאחר ההטמעה

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

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

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

במה שונה מיזוג תוצאות מחיפוש פדרטיבי?

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

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

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

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

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

ספקות טכניים: איכות, השהיות, עדכון נתונים

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

באיזו מהירות הנתונים מתעדכנים ומה עם התיישנות?

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

כיצד מופרדות הרשאות הגישה למקורות?

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

האם התשתית תעמוד בעלייה בשאילתות?

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

מי תומך בפתרון לאחר ההשקה?

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

נדון במשימה שלכם ונחזור עם הערכה ותוכנית

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

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

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

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