Reranking במערכות RAG — איך בוחרים את המסמכים הכי רלוונטיים

מאת צוות מדיה דיל · 09.08.2026 · AI · 9 דק׳

שליפה ראשונית מחזירה 40 מועמדים סבירים; רק חלק קטן מהם באמת רלוונטי לשאלה. מדריך ל-Reranking: למה זה שלב נפרד, איך מודלי Cross-encoder עובדים, ומחיר ה-latency.

שליפה ראשונית ב-RAG, גם כשהיא משלבת Vector Search ומילות מפתח, נועדה להיות רחבה ומהירה - להביא 30-50 מועמדים סבירים ממאגר של אלפי או מיליוני קטעים, בזמן שהוא שברי שנייה. המחיר של המהירות הזו הוא דיוק: מתוך 40 המועמדים, אולי רק 3-4 באמת עונים על מה שנשאל, והשאר "דומים מספיק" כדי לעבור את הסף הראשוני אבל לא באמת רלוונטיים. אם מזריקים את כל 40 המועמדים לפרומפט, המודל מוצף ברעש; אם בוחרים "Top 5" לפי ציון השליפה הגולמי, לפעמים מפספסים את הקטע הכי חשוב כי הוא נחת במקום השישי. Reranking הוא השלב שפותר בדיוק את זה: לוקח את המועמדים מהשליפה הראשונית ומדרג אותם מחדש בדיוק גבוה משמעותית, לפני שרק ה"אמיתיים" מוזרקים לפרומפט.

מדידה: כמה בדיוק Reranking משפר תוצאות

הדרך הנכונה להעריך את התרומה של Reranking היא השוואה ישירה - הרצת אותו סט שאילתות בדיקה פעם עם שלב הדירוג מחדש ופעם בלעדיו, ומדידת מדדי Retrieval סטנדרטיים כמו NDCG (Normalized Discounted Cumulative Gain, שמודד לא רק אם התוצאה הנכונה נמצאת אלא גם באיזה מיקום היא מדורגת) או Precision@K. בפרויקטים רבים, השיפור ב-NDCG ממעבר מ-Hybrid Search בלבד להוספת שלב Reranking הוא ההבדל הבודד הגדול ביותר שניתן להשיג בכל הצינור - גדול יותר מכל שיפור אחר בבחירת מודל Embedding או כיוונון פרמטרי חיפוש. זו הסיבה שכשמנסים לתעדף עבודה על צינור RAG קיים עם משאבים מוגבלים, הוספת שלב Reranking שעדיין לא קיים היא לרוב ההשקעה עם ה-ROI הגבוה ביותר.

למה לא פשוט לשפר את השליפה הראשונית עצמה

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

• Bi-encoder (המנגנון שמאחורי Vector Search רגיל) - מקודד את השאלה ואת כל המסמכים בנפרד, לוקטורים קבועים מראש. בזמן שאילתה, רק השאלה צריכה קידוד חדש - השוואה מול וקטורי המסמכים (שכבר מחושבים ומאונדקסים) היא פעולה מתמטית מהירה מאוד, שניתן להריץ על מיליוני מסמכים בזמן סביר.
• Cross-encoder (המנגנון שמאחורי Reranker) - מקבל את השאלה ואת המסמך יחד, כזוג, ומעבד אותם במשותף דרך המודל כדי לחשב ציון רלוונטיות ישיר. זה נותן דיוק גבוה משמעותית כי המודל "רואה" את האינטראקציה בין השאלה למסמך הספציפי, ולא משווה ייצוגים מנותקים. אבל בדיוק בגלל זה אי אפשר לחשב מראש - כל זוג שאלה-מסמך דורש הרצת מודל חדשה, מה שהופך אותו לאיטי מכדי להריץ על מיליוני מסמכים.

הפתרון המעשי הוא צינור דו-שלבי: Bi-encoder (בשילוב מילות מפתח) לשלב הראשון המהיר על המאגר המלא, Cross-encoder לשלב השני המדויק על קבוצה מצומצמת של מועמדים בלבד.

המחשה של הצינור הדו-שלבי

שאילתה --> Hybrid Search (Bi-encoder + BM25) --> 40 מועמדים
                                                       |
                                                       v
                                          Cross-encoder Reranker
                                          (מריץ 40 זוגות שאלה-מסמך)
                                                       |
                                                       v
                                       Top 5 לפי ציון רלוונטיות אמיתי
                                                       |
                                                       v
                                              הזרקה לפרומפט

מחיר ה-Latency - ולמה זה כמעט תמיד משתלם

הרצת Cross-encoder על 40 מועמדים מוסיפה זמן עיבוד ממשי - בדרך כלל עשרות עד מאות מילישניות, תלוי בגודל המודל ובכמות המועמדים. זו תוספת אמיתית ל-Latency הכולל של הבקשה. אבל ברוב המקרים היא משתלמת, כי השיפור בדיוק - ובעיקר בהימנעות ממענה שגוי או חלקי - שווה יותר מכמה עשרות מילישניות. הדרך המעשית לצמצם את העלות היא לצמצם את מספר המועמדים שמגיעים לשלב ה-Reranking (למשל 20-30 במקום 100), ולבחור מודל Reranker בגודל מתאים לדרישת ה-latency של המוצר - יש היום מודלי Reranker קטנים ומהירים במיוחד שנועדו בדיוק לתפקיד הזה.

בחירת מודל Reranking: לא כל המודלים שווים

בשוק קיימים כמה סוגי מודלי Reranking, וההבדלים ביניהם משפיעים ישירות על ה-Trade-off בין דיוק ל-latency. יש מודלי Cross-encoder "מלאים" שנותנים את הדיוק הגבוה ביותר אבל איטיים יחסית, ומודלים קלים יותר (לעיתים מבוססי אדריכלות מעט שונה, כמו ColBERT, שמשלבת חלק מהיתרונות של Bi-encoder ו-Cross-encoder) שנותנים פשרה טובה בין השניים - דיוק גבוה משמעותית מ-Bi-encoder טהור, אבל מהירים בהרבה מ-Cross-encoder מלא. הבחירה בין הסוגים תלויה בדרישת ה-latency הספציפית של המוצר: מערכת תמיכה שיחתית שדורשת תגובה כמעט מיידית עשויה להעדיף מודל קליל, בעוד מערכת חיפוש מסמכים ללא לחץ זמן אמת יכולה להרשות לעצמה מודל כבד ומדויק יותר.

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

Reranking ותקציב זמן אמת - כיוונון עדין

במערכות שדורשות תגובה כמעט מיידית (למשל צ'אטבוט שיחתי), תוספת Latency אפילו של 100-200 מילישניות מ-Reranking יכולה להיות מורגשת. הפתרון המעשי הוא לא לוותר על Reranking אלא לכייל את גודלו: הרצת Cross-encoder על 15-20 מועמדים בלבד במקום 50, שימוש במודל Reranking קליל שנועד במפורש למקרי שימוש רגישי latency, והרצת שלב הדירוג במקביל לפעולות אחרות שהמערכת ממילא מבצעת (כמו רישום לוגים או הכנת תשובת ביניים), כדי שהעלות שלו "תיבלע" בזמן שממילא נדרש למשימות אחרות. הכיוונון הזה הוא דוגמה טובה לכך שרוב ההחלטות בבניית RAG הן לא בינאריות ("להשתמש או לא") אלא עניין של דרגת עוצמה - כמה מועמדים, איזה גודל מודל, כמה זמן להשקיע בכל שלב.

Reranking מעבר לדמיון טקסטואלי

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

שילוב עם Query Expansion ו-Chunking

שווה לזכור ש-Reranking הוא לא פתרון קסם שמתקן צינור לקוי במקומות אחרים. אם השאלה המקורית עמומה מדי, גם ה-Reranker הכי טוב לא יוכל למצוא מועמד רלוונטי שלא הגיע בכלל לשלב השליפה - זו הסיבה שQuery Expansion ושכתוב שאילתה חשובים לפני השליפה הראשונית. באופן דומה, אם הקטעים (Chunks) עצמם מנוסחים בצורה גרועה - קוטעים משפט באמצע או מנתקים הקשר - גם דירוג מדויק לא יעזור, כי המידע הרלוונטי פשוט לא שלם בתוך הקטע. ראו Semantic Chunking לטיפול בבעיה הזו מהשורש.

Reranking כשכבת בטיחות נוספת, לא רק דיוק

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

טעויות נפוצות

• הרצת Reranker על יותר מדי מועמדים - זה הורג latency בלי תועלת מקבילה. אם השליפה הראשונית איכותית, 20-30 מועמדים כבר מכסים כמעט תמיד את כל התוצאות הרלוונטיות.
• שימוש באותו Reranker לכל סוגי התוכן - Reranker שאומן על תוכן כללי לא בהכרח מתפקד טוב על דומיין טכני מאוד מיוחד (משפטי, רפואי) בלי כיול נוסף.
• אין מדידה של תרומת ה-Reranking בפועל - בלי A/B testing מול צינור בלי Reranking, קשה לכמת את השיפור בפועל ולהצדיק את תוספת העלות וה-latency.

שילוב Reranking עם מטא-דאטה עסקי

מודל Reranking מדרג לפי רלוונטיות טקסטואלית-סמנטית, אבל לרוב יש גם אותות עסקיים שכדאי לשלב לדירוג הסופי - למשל עדיפות למסמכים עדכניים יותר, למקורות "רשמיים" מוסמכים על פני תוכן קהילתי, או לתוצאות שכבר הוכיחו את עצמן כמועילות במדדי משוב משתמשים קודמים. הגישה המעשית היא לרוב שילוב דו-שלבי: קודם ציון הרלוונטיות הטהור מה-Reranker, ואז נוסחת דירוג משולבת שמשקללת את הציון הזה יחד עם אותות עסקיים נוספים (למשל final_score = 0.8 * rerank_score + 0.2 * recency_boost). חשוב לשמור את השכבה העסקית נפרדת ומוסברת (לא "לתת ל-Reranker לנחש" מה חשוב עסקית) כדי שיהיה אפשר לכייל אותה בנפרד ולהבין למה תוצאה מסוימת דורגה כפי שדורגה.

מקרה מבחן: מסמכים משפטיים ארוכים

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

שאלות נפוצות

האם Reranking חובה בכל מערכת RAG?

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

מה ההבדל בין Reranking ל-Hybrid Search?

Hybrid Search קובע אילו מועמדים בכלל נשלפים מהמאגר המלא; Reranking מדרג מחדש את המועמדים שכבר נשלפו, בדיוק גבוה יותר.

האם אפשר להריץ Reranker משלנו, או חייבים שירות חיצוני?

יש מודלי Reranking בקוד פתוח שאפשר להריץ עצמאית, וגם שירותי API ייעודיים. הבחירה תלויה בדרישות latency, פרטיות ותקציב.

האם Reranking מתאים גם ל-GraphRAG?

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

איך בוחרים כמה מועמדים לשלוח ל-Reranker?

יש לאזן בין כיסוי (מספיק מועמדים כדי לא לפספס תוצאה רלוונטית) לבין latency (לא יותר מדי, כי כל מועמד נוסף מוסיף זמן עיבוד). 20-50 הוא טווח נפוץ בפרודקשן.

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

תגיות: Reranking · Cross-encoder · RAG · Vector Search · Retrieval · Bi-encoder

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