Retrieval ללא Embeddings — מתי אפשר לוותר על Vector Database

מאת צוות מדיה דיל · 12.08.2026 · AI Retrieval · 5 דק׳

לא כל מערכת RAG צריכה Vector Database. מדריך על מקרים שבהם BM25, PostgreSQL Full-Text Search או שאילתת SQL פשוטה נותנים תוצאה טובה יותר, מהירה יותר וזולה יותר.

צוות פיתוח שבנה מערכת תמיכה פנימית עבור חברת ביטוח פנה אלינו אחרי שלושה חודשים של עבודה על Pipeline של RAG מבוסס Embeddings, כדי לגלות שהמשתמשים בעיקר מחפשים לפי מספרי פוליסה, קודי שגיאה וסעיפי תקנון מדויקים. Vector Database מפואר עם Pinecone לא עזר להם למצוא "סעיף 4.2.1" — הוא החזיר סעיפים "דומים סמנטית" שלא היו הסעיף המבוקש. הבעיה לא הייתה בכלי אלא בהנחת היסוד: שכל בעיית חיפוש היא בעיה של דמיון סמנטי. לפעמים היא בעיה של התאמה מדויקת, ואז embeddings הם הכלי הלא נכון לעבודה.

מתי חיפוש לקסיקלי מנצח חיפוש סמנטי

Embeddings מצטיינים כשהשאלה והתשובה מנוסחות במילים שונות אך משמעות דומה — "איך מבטלים מנוי" מול "תהליך סיום התקשרות". אבל כשהמשתמש מחפש מזהה מדויק — SKU, מספר תעודת זהות, קוד שגיאה כמו ECONNREFUSED, או ציטוט מילולי מחוזה — חיפוש וקטורי דווקא מזיק. מודל Embedding ממפה את הטקסט למרחב וקטורי לפי משמעות סמנטית, לא לפי זהות מחרוזתית, ולכן שני קודי שגיאה שונים לחלוטין יכולים לקבל ציון דמיון גבוה כי הם "מדברים על אותו נושא". BM25 (המימוש הסטנדרטי מאחורי Elasticsearch ו-OpenSearch) או PostgreSQL Full-Text Search עם tsvector ו-ts_rank פותרים את זה הפוך: הם מדרגים מסמכים לפי תדירות מונחים מדויקים (term frequency) ונדירותם בקורפוס (inverse document frequency), ותומכים בהתאמה מדויקת של ביטויים באמצעות phrase search.

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

עלות התחזוקה הנסתרת של Vector Database

הקמת Vector Database נראית פשוטה — ריצה של pip install, יצירת Index, וזהו. אבל מי שהפעיל את זה בפרודקשן יודע שהעלות האמיתית מגיעה אחר כך: כל שינוי במודל ה-Embedding (שדרוג מ-text-embedding-3-small ל-text-embedding-3-large, למשל) דורש re-embedding מלא של כל הקורפוס, כי וקטורים ממודלים שונים אינם ניתנים להשוואה זה עם זה. עבור קורפוס של מיליוני מסמכים, זו עבודת batch שיכולה לקחת ימים ולעלות אלפי דולרים — ולקרות שוב בכל פעם שספק ה-Embedding משנה גרסה. חיפוש לקסיקלי, לעומת זאת, לא תלוי במודל חיצוני בכלל: ה-Index נבנה ישירות מהטקסט, אין drift, ואין תלות ב-API חיצוני שיכול להשתנות מתחתיך.

יש גם עניין של סקייל תשתיתי. ANN Index (כמו HNSW) דורש זיכרון RAM משמעותי כדי לשמור ביצועים סבירים, וזיכרון הוא המשאב היקר ביותר בענן. עבור קורפוס בגודל בינוני — עד כמה עשרות אלפי מסמכים — מנוע Full-Text Search רגיל על PostgreSQL רץ מצוין על מכונה שכבר קיימת בסטאק שלכם, בלי תשתית נוספת, בלי ספק חיצוני נוסף, ובלי עלות שכפול נתונים. הרחבנו על השיקולים האלה במדריך על ארכיטקטורת Vector Database, אבל השורה התחתונה היא שהעלות הזו מוצדקת רק כשבאמת יש צורך בחיפוש סמנטי.

מתי Hybrid הוא הפתרון הנכון, לא Either/Or

המסקנה הנכונה כמעט אף פעם לא "לוותר לגמרי על embeddings" אלא לזהות באיזה סוג שאילתה מדובר ולנתב בהתאם. שאילתות עם מזהים מדויקים, מספרים, קודים וביטויים מצוטטים — לחיפוש לקסיקלי. שאילתות פתוחות, ניסוחים חופשיים ושאלות "איך" ו"למה" — לחיפוש סמנטי. מערכת ניתוב פשוטה יכולה לבדוק אם השאילתה מכילה תבניות כמו מספרים ארוכים, קודים באותיות גדולות או מרכאות, ולהעדיף חיפוש לקסיקלי במקרה כזה. פירטנו גישה מלאה לשילוב הזה במדריך Hybrid Search, ובגרסה מורחבת יותר הכוללת גם מקורות מבניים כמו SQL וגרפי ידע במדריך Hybrid Retrieval 2.0.

נקודה חשובה נוספת: גם כשמחליטים כן להשתמש בחיפוש סמנטי, לא תמיד צריך Vector Database ייעודי. PostgreSQL עם תוסף pgvector תומך בחיפוש דמיון קוסינוס ישירות בתוך אותו מסד נתונים שכבר משרת את שאר האפליקציה, כולל שילוב טבעי עם שאילתות SQL רגילות וסינון לפי שדות מבניים. עבור עומסים בינוניים זו לעיתים קרובות אלטרנטיבה עדיפה על שירות Vector DB נפרד, כפי שמפורט במדריך pgvector.

מדידה, לא ניחוש: איך בודקים באמת מה עדיף

ההחלטה בין חיפוש לקסיקלי לסמנטי לא צריכה להתקבל על בסיס אינטואיציה או "כי כולם עושים RAG עם Pinecone". הדרך הנכונה היא לבנות סט הערכה (evaluation set) קטן — 50-100 שאילתות אמיתיות שנאספו מלוגים או מראיונות משתמשים, כל אחת עם רשימת מסמכים "נכונים" שהיא אמורה להחזיר — ולהריץ אותו מול שני המימושים במקביל, תוך מדידת metrics כמו Recall@10 ו-MRR (Mean Reciprocal Rank). בדרך כלל מתגלה תמונה מעורבת: לקבוצת שאילתות אחת (זיהוי מזהים, קודים, ציטוטים) חיפוש לקסיקלי מנצח בפער ניכר; לקבוצה אחרת (שאלות ניסוח חופשי) חיפוש סמנטי עדיף משמעותית. התובנה הזו בעצמה — לא הכרעה גורפת אחת — היא מה שאמור להנחות את החלטת הארכיטקטורה, ולעיתים קרובות מובילה בדיוק לפתרון ההיברידי שמתואר במדריכים שקושרנו אליהם למעלה.

שיקול נוסף שכדאי לבדוק אמפירית הוא זמן תגובה בעומס אמיתי, לא בבדיקה מקומית עם עשר שאילתות. חיפוש לקסיקלי על Postgres עם אינדקס GIN מתפקד לרוב במילישניות בודדות גם תחת עומס, בעוד חיפוש וקטורי על ANN Index גדול עלול להראות latency שמשתנה משמעותית תלוי בפרמטרים כמו ef_search ב-HNSW — פרמטר שמאזן בין דיוק למהירות, ודורש כיול נפרד לכל קורפוס וכל דרישת SLA.

איך מזהים שהמערכת שלכם באמת צריכה Vector Database

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

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

תגיות: BM25 · Full-Text Search · Vector Database · PostgreSQL · Retrieval · Hybrid Search

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