בחירה והתאמה של מודל embedding עבור RAG

מדוע בחירת מודל embedding עבור RAG קובעת את איכות התשובות

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

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

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

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

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

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

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

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

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

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

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

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

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

מדידות "לפני" ו"אחרי" אנחנו מתעדים בדוח יחד עם המתודולוגיה — אפשר לחזור עליהן על נתונים חדשים ולהשתכנע שהרווח אינו חד-פעמי.

השוואת גישות: embedding מוכן, אימון נוסף, היברידי

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

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

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

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

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

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

1. ביקורת קורפוס המסמכים. סופרים נפח, פורמטים, שיעור סריקות וטבלאות, כפילויות, גרסאות מיושנות. בפלט — מפת מקורות וכללי חלוקת הטקסט לקטעים.
2. סימון שאלות בדיקה להערכת החיפוש. 50–100 שאלות אמיתיות של עובדים עם תשובת ייחוס והפניה למסמך המקור. הסט לא משתנה בהמשך — אחרת המדידות אינן ברות השוואה.
3. השוואת מודלים על הקורפוס שלנו. מריצים את המועמדים על סט אחד ובודקים את שיעור הפגיעות של המקור הנדרש בחמישייה הראשונה, בנפרד — איכות בשאילתות קצרות ולא מדויקות.
4. הגדרת האינדוקס. גודל הקטע וחפיפה, מטא-נתונים (גרסה, מחלקה, תוקף), שילוב חיפוש וקטורי ומדויק, לוח זמנים לאינדוקס מחדש בעת עדכון מסמכים.
5. כיול סף "אין תשובה". מתאימים באיזו קרבה המערכת עונה, ובאיזו היא מודיעה בכנות שאין נתונים. זה מסיר המצאות בטוחות על פערים בקורפוס.
6. קבלת איכות החיפוש. מתעדים מדדי יעד ומריצים סט בקרה. פער — סיבה לחזור לחלוקה או למודל, ולא לשכתב את השאלות.
7. מסירה לתפעול. תצורה, נוהל אינדוקס מחדש, בקרת שיעור כשלים, הפרדת הרשאות והכשרת צוות הלקוח.

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

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

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

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

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

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

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

מה שינינו בקו החיפוש

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

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

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

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

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

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

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

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

מסמכים במספר שפות — אינדקס אחד או כמה?

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

מה לעשות עם טבלאות וסריקות?

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

באיזו תדירות לבצע אינדוקס מחדש של הקורפוס?

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

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

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

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

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

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

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