Hybrid Search — שילוב Vector Search ו-Keyword Search

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

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

מישהו מחפש במערכת ידע ארגונית את "שגיאת קוד E-4471", ומקבל בחזרה חמישה קטעים על "טיפול בתקלות מערכת" - רלוונטיים ברוח כללית, אבל אף אחד מהם לא מכיל את הקוד המדויק שהמשתמש חיפש. זו הבעיה הקלאסית של Vector Search טהור: הוא מצטיין בתפיסת דמיון סמנטי, אבל "E-4471" נשחק ל-Embedding כללי שלא בהכרח מבדיל אותו מקודי שגיאה אחרים - מבחינת המשמעות הסמנטית, "E-4471" ו-"E-8823" יכולים להיראות דומים מאוד. מהצד השני, חיפוש מילות מפתח קלאסי (כמו BM25) היה מוצא בדיוק את המסמך עם הקוד המדויק - אבל היה מפספס לגמרי שאלה מנוסחת אחרת כמו "המערכת קורסת אחרי עדכון, מה עושים". Hybrid Search משלב את שתי הגישות כדי לתפוס גם דמיון סמנטי וגם התאמה מדויקת.

המחיר של לוותר על אחת השיטות - שתי דוגמאות מנוגדות

שווה להמחיש את הבעיה עם שתי דוגמאות קצה מנוגדות. תרחיש ראשון: משתמש מחפש "SKU-88213" - קוד מוצר מדויק. חיפוש וקטורי טהור עלול להחזיר מוצרים "דומים סמנטית" (אותה קטגוריה, מחיר דומה) בלי שהמוצר המדויק המבוקש בכלל יופיע בתוצאות, כי הקוד המספרי לא נושא משמעות סמנטית של ממש עבור מודל ה-Embedding. תרחיש שני, הפוך: משתמש שואל "מה קורה אם המוצר מגיע שבור?" - חיפוש מילות מפתח טהור עלול להחמיץ לגמרי מסמך שמנוסח "מדיניות פיצוי במקרה של נזק בהובלה", כי אין חפיפה מילולית ישירה בין "שבור" ל"נזק", למרות שהמשמעות זהה. בשני המקרים, שיטת החיפוש ה"לא נכונה" לא רק פחות טובה - היא נכשלת לחלוטין. זה הבסיס לטענה שHybrid Search הוא לא שיפור שולי אלא תיקון לפער מבני אמיתי בין שתי הגישות.

שתי שיטות חיפוש, שתי חוזקות שונות מהותית

חיפוש מבוסס Embeddings ממיר טקסט לוקטור במרחב רב-ממדי, ומודד קרבה בין וקטורים (בדרך כלל Cosine similarity). זה נותן לו יכולת "להבין" שסינונימים, ניסוחים שונים, ואפילו שפות שונות יכולים להתכוון לאותו דבר - זו בדיוק הסיבה שהוא הבסיס של RAG מודרני. אבל הוא נחלש כשמדובר בזיהוי מדויק של מזהים ייחודיים, מספרי מוצר, שמות פרטיים נדירים, או ראשי תיבות - כל אלה נוטים "להיטמע" (embed) בצורה שלא שומרת על ייחודיותם התחבירית המדויקת.

חיפוש BM25 (Best Matching 25) הוא אלגוריתם סטטיסטי קלאסי שמדרג מסמכים לפי שכיחות מילות המפתח בהם, עם משקל למילים נדירות (idf - inverse document frequency) ונרמול לאורך מסמך. הוא לא "מבין" משמעות, אבל הוא מדויק להפליא במציאת התאמות מילוליות - בדיוק המקום שבו Vector Search נחלש.

איך בפועל מאחדים את שני הציונים

האתגר הטכני המרכזי הוא שהציונים משתי השיטות לא ניתנים להשוואה ישירה: ציון Cosine similarity נע בטווח שונה לחלוטין מציון BM25, ואין דרך פשוטה "לנרמל" ביניהם בצורה הוגנת. הפתרון הנפוץ והחזק ביותר בפועל הוא Reciprocal Rank Fusion (RRF) - במקום לאחד ציונים, מאחדים דירוגים (rank). לכל מסמך יש דירוג נפרד בכל אחת משתי רשימות התוצאות (הווקטורית ומילות המפתח), והציון המשולב מחושב לפי הנוסחה הפשוטה 1/(k + rank), כשמסמכים שמופיעים גבוה בשתי הרשימות מקבלים ציון משולב גבוה במיוחד.

דוגמה לחישוב RRF

// k הוא קבוע (בדרך כלל 60), rank מתחיל מ-1
score(doc) = 1/(k + rank_vector) + 1/(k + rank_keyword)

// מסמך שמופיע במקום 2 בחיפוש הווקטורי ומקום 1 בחיפוש מילות המפתח:
score = 1/(60+2) + 1/(60+1) = 0.0161 + 0.0164 = 0.0325
// מסמך שמופיע רק במקום 1 בחיפוש הווקטורי (ולא ברשימת ה-keyword כלל):
score = 1/(60+1) = 0.0164
// המסמך הראשון "זוכה" כי הוא הופיע חזק בשתי השיטות

היתרון של RRF הוא שהוא לא דורש כיול (tuning) עדין של משקלים יחסיים בין השיטות - הוא עמיד יחסית "מהקופסה". חלק ממערכות הפרודקשן כן מוסיפים משקל מפורש (למשל 0.7 לווקטורי, 0.3 למילות מפתח) כשיש להם נתונים אמפיריים שמראים העדפה ברורה לכיוון אחד, אבל זה דורש כיול זהיר ומדידה מתמשכת כדי לא "לשבור" את האיזון עבור סוגי שאילתות אחרים.

כיול משקלים בין השיטות - מעבר ל-RRF ברירת מחדל

גם כשמשתמשים ב-RRF כבסיס, יש מקום לכיול עדין נוסף בהתאם לאופי התוכן והשאלות. מערכת שמשרתת בעיקר שאילתות עם מזהים מדויקים (תמיכה טכנית עם קודי שגיאה, למשל) עשויה להרוויח ממתן משקל גבוה יותר לתוצאות ה-BM25 בנוסחת האיחוד; מערכת שמשרתת בעיקר שאלות מושגיות ("איך עובד תהליך X") עשויה להרוויח ממשקל גבוה יותר לתוצאות הווקטוריות. הדרך הנכונה לכייל את זה היא לא ניחוש - היא בניית סט שאילתות מייצג עם תשובות ידועות (Ground truth), הרצת כמה קונפיגורציות משקל, ומדידת Precision/Recall בפועל על כל אחת. כיול כזה, כמו כל שינוי בצינור RAG, צריך לעבור דרך תשתית Evals ולא להתבסס על בדיקה ידנית של כמה דוגמאות.

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

מתי חיפוש מילות מפתח קריטי, לא רק "נחמד"

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

Hybrid Search כשלב אחד בצינור, לא הכל

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

מה קורה כששתי השיטות "חלוקות" לגמרי

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

Hybrid Search כשלב הכנה ל-Reranking

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

אתגרי מימוש בפועל

ברמת התשתית, לא כל Vector Database תומך ב-Hybrid Search built-in - חלקן דורשות אינדקס טקסט מלא (Full-text index) נפרד לצד אינדקס הווקטורים, ואז לוגיקת האיחוד רצה ברמת האפליקציה. פתרונות כמו pgvector על גבי PostgreSQL יכולים לנצל את מנועי חיפוש הטקסט המובנים של Postgres (tsvector) לצד אינדקס הווקטורים, מה שהופך אותם לבחירה נוחה למי שכבר עובד עם Postgres. חשוב גם לוודא שהאינדקס הטקסטואלי מותאם לשפה הרלוונטית - Stemming ו-tokenization בעברית, למשל, שונים משמעותית מאנגלית, ובחירת תצורה לא נכונה פוגעת קשות באיכות ההתאמה.

Hybrid Search במערכות רב-לשוניות

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

שאלות נפוצות

האם Hybrid Search תמיד עדיף על Vector Search לבד?

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

מה זה RRF ולמה לא פשוט לממוצע ציונים?

Reciprocal Rank Fusion מאחד לפי דירוג במקום לפי ציון גולמי, כי ציוני Cosine similarity ו-BM25 נמצאים בסקאלות שונות לחלוטין שלא ניתן להשוות ביניהן בצורה ישירה והוגנת.

האם Hybrid Search מוסיף latency משמעותי?

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

איך יודעים אם צריך Hybrid Search במערכת שלי?

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

איך זה מתקשר ל-Semantic Chunking?

שתי הטכניקות משלימות זו את זו: Semantic Chunking קובע איך מחלקים מסמכים לקטעים; Hybrid Search קובע איך מוצאים את הקטעים הרלוונטיים מבין כל הקטעים שכבר קיימים.

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

תגיות: Hybrid Search · Vector Search · BM25 · RRF · Embeddings · RAG · Full-text Search

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