Vector Databases — ארכיטקטורה, Indexing ו-Similarity Search

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

מדריך ארכיטקטורה ל-Vector Databases: איך אינדקסים כמו HNSW ו-IVF מאפשרים חיפוש דמיון מהיר על מיליוני וקטורים, ואילו טרייד-אופים בין דיוק, מהירות וזיכרון קובעים בחירת מנוע.

מאגר של עשרה מיליון מסמכים, כל אחד מיוצג כווקטור בממד 1536. שאלה נכנסת, והופכת גם היא לווקטור. איך מוצאים, תוך פחות ממאה מילישניות, את מאה הווקטורים הקרובים ביותר מבין עשרת המיליון - בלי לבדוק אחד-אחד? זו בדיוק הבעיה שמנועי Vector Database נבנו לפתור. חיפוש דמיון "כוחני" (Brute-force) - השוואת השאילתה מול כל וקטור במאגר - עובד מצוין על אלפי רשומות, אבל קורס בקנה מידה גדול יותר: הזמן גדל ליניארית עם גודל המאגר, וברגע שמדובר במיליוני רשומות, כל שאילתה בודדת הופכת לבלתי-סבירה מבחינת latency. הפתרון הוא Approximate Nearest Neighbor (ANN) - אלגוריתמים שמוותרים על דיוק מוחלט תמורת מהירות של סדרי גודל, ומהווים את הליבה של כל Vector Database מודרני.

למה חיפוש מדויק לא scale-בילי

הבעיה המתמטית מוכרת בשם "קללת הממדיות" (Curse of Dimensionality): ככל שממד הווקטור עולה, אינטואיציות גיאומטריות שעובדות טוב בשני או שלושה ממדים מתחילות להתפרק. במרחב רב-ממדי, כמעט כל שתי נקודות אקראיות נמצאות במרחק "בינוני" דומה זו מזו - ההבדלים בין "קרוב מאוד" ל"רחוק מאוד" נעשים פחות ופחות בולטים ככל שהממד עולה, מה שהופך מבני נתונים קלאסיים לחיפוש מרחבי (כמו KD-trees, שעובדים מצוין בשני-שלושה ממדים) ללא יעילים לחלוטין בממדים גבוהים כמו 1536.

לכן, כל מנוע Vector Database רציני בנוי סביב מבנה נתונים ייעודי שמוותר על ודאות מוחלטת - הוא לא מבטיח למצוא את השכנים הקרובים ביותר האמיתיים, אלא נותן ערבות סטטיסטית גבוהה (למשל 95%-99% Recall) למצוא אותם, בתמורה לזמן חיפוש שהוא לוגריתמי או תת-ליניארי, לא ליניארי, ביחס לגודל המאגר. הפער בין 99% Recall ל-100% נראה קטן על הנייר, אבל ההבדל בזמן ריצה יכול להיות פי עשרות עד מאות - זו העסקה המרכזית שכל Vector Database מציע.

HNSW - האלגוריתם השולט כיום

Hierarchical Navigable Small World (HNSW) הוא כיום אלגוריתם ה-ANN הנפוץ ביותר במנועי Vector Database מובילים. הרעיון המרכזי: בניית גרף רב-שכבתי שבו כל וקטור מחובר לכמה שכנים "קרובים" בגרף. השכבה העליונה דלילה מאוד - מעט צמתים עם קפיצות "רחוקות" בין אזורי המרחב; השכבות התחתונות צפופות יותר, עם קישורים "מקומיים" מדויקים יותר. חיפוש מתחיל מלמעלה, קופץ במהירות לאזור הכללי הנכון במרחב, ואז "יורד" שכבה אחר שכבה ומעדן את החיפוש עד לתוצאה המדויקת ביותר בשכבה התחתונה.

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

שני הפרמטרים שקובעים את ההתנהגות

שני פרמטרים מרכזיים שולטים על ה-trade-off בין דיוק, מהירות ושימוש בזיכרון: M קובע כמה קשרים יש לכל צומת בגרף - ערך גבוה יותר משפר דיוק (Recall) אבל מגדיל את גודל האינדקס וזמן הבנייה. ef_construction קובע כמה מועמדים נבדקים בזמן בניית הגרף עצמו - ערך גבוה יותר נותן גרף איכותי יותר אבל מאט את שלב האינדוקס. יש גם פרמטר מקביל בזמן שאילתה, ef_search, שקובע כמה מועמדים נבדקים בכל חיפוש בודד - כאן הטרייד-אוף הוא ישיר בין דיוק לזמן תגובה, וניתן לכייל אותו דינמית לפי צורך.

IVF - הגישה החלופית לזיכרון מוגבל

Inverted File Index (IVF) היא גישה שונה: במקום גרף, המרחב מחולק מראש לאשכולות (clusters) באמצעות אלגוריתם כמו k-means, וכל וקטור משויך לאשכול הקרוב ביותר לו. בזמן חיפוש, המערכת מזהה תחילה לאילו אשכולות השאילתה קרובה ביותר, ואז מחפשת רק בתוך הווקטורים ששייכים לאשכולות האלה - במקום בכל המאגר.

היתרון המרכזי של IVF על פני HNSW הוא צריכת זיכרון נמוכה משמעותית - הגרף של HNSW דורש שמירת קשרים רבים לכל צומת, בעוד IVF שומר בעיקר מבנה שטוח יחסית. החיסרון: דיוק בדרך כלל נמוך יותר בעומק שווה, במיוחד כשווקטורים "גבוליים" נמצאים קרוב לגבול בין שני אשכולות ונופלים בטעות לאשכול הלא נכון בשלב הבנייה. פתרון ביניים נפוץ הוא IVF-PQ, ששילוב עם Product Quantization - דחיסה של הווקטורים עצמם כדי לחסוך עוד יותר זיכרון, במחיר של ירידה נוספת בדיוק.

Product Quantization - דחיסת וקטורים בפרודקשן

כשמאגר גדל למאות מיליוני וקטורים, אפילו אינדקס יעיל כמו HNSW יכול לדרוש כמות זיכרון RAM שלא מעשית לאחסן במלואה. Product Quantization (PQ) פותרת את זה על ידי חלוקת כל וקטור לתת-קטעים קטנים, וייצוג כל תת-קטע לא כערך מדויק אלא כאינדקס למילון "קודים" מוגדר מראש - בדומה לדחיסה עם-הפסד (lossy compression) בתמונות. התוצאה: ירידה משמעותית בשטח האחסון (לעיתים פי 8 עד 32), במחיר ירידה מסוימת בדיוק החיפוש.

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

Filtering - כשצריך חיפוש דמיון וגם תנאי מדויק ביחד

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

יש שתי גישות מרכזיות: Pre-filtering - סינון המועמדים לפי התנאי לפני החיפוש הווקטורי, שעובד טוב כשהתנאי מצמצם מאוד את המאגר, אבל עלול "לשבור" את יעילות מבנה הגרף אם מריצים אותו בצורה נאיבית. Post-filtering - הרצת חיפוש דמיון רגיל ואז סינון התוצאות לפי התנאי, שפשוט יותר אבל מסוכן: אם התנאי מצמצם דרסטית ורוב התוצאות הראשוניות לא עוברות אותו, ייתכן שיחזרו פחות תוצאות ממה שביקשו, או אפילו אפס תוצאות, למרות שקיימות תוצאות רלוונטיות במאגר. מנועי Vector Database מתקדמים תומכים ב-Hybrid filtering שמשלב את שני העקרונות בתוך אלגוריתם החיפוש עצמו, לא כשלב נפרד לפניו או אחריו.

בחירת מנוע - Managed מול Self-hosted מול הרחבה על מסד קיים

יש שלוש משפחות עיקריות של פתרונות: מנועי Vector Database ייעודיים (עם ניהול עצמי או כשירות מנוהל), הרחבות וקטוריות למסדי נתונים קיימים כמו pgvector על PostgreSQL, ופתרונות in-memory קלים לצרכים קטנים יותר. הבחירה תלויה בעיקר בהיקף (scale), בדרישות התפעול, ובשאלה אם כבר קיים מסד נתונים בתשתית שאפשר להרחיב במקום להוסיף עוד רכיב תשתיתי נפרד.

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

מדידת Recall - איך יודעים שהאינדקס בכלל עובד

נקודה שקל להזניח: בלי מדידה מפורשת, אין דרך לדעת אם אינדקס ANN שהוגדר בפרודקשן נותן דיוק סביר או פוגע קשות באיכות התוצאות. הדרך הנכונה למדוד היא לבנות סט שאילתות ייחוס עם תוצאות "אמת" (Ground truth) שחושבו בחיפוש מדויק (Brute-force) על תת-מדגם קטן יחסית של הנתונים, ואז להשוות כמה מהתוצאות שהאינדקס המקורב מחזיר חופפות לתוצאות המדויקות. יחס החפיפה הזה הוא ה-Recall בפועל, ולא הערך התיאורטי שמסמכי המנוע מבטיחים.

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

טעויות נפוצות בתכנון Vector Database

• הזנחת כיול ef_search - שימוש בברירת המחדל בלי לבדוק את הטרייד-אוף בין דיוק למהירות עבור העומס האמיתי, ולגלות רק בפרודקשן שהדיוק נמוך מדי או ה-latency גבוה מדי.
• אי-תכנון ל-Filtering מראש - בניית סכימת אינדקס בלי לחשוב על תנאי הסינון שיידרשו בפועל, מה שגורר בעיות ביצועים חמורות כשמנסים להוסיף filtering בדיעבד.
• הזנחת עדכון אינדקס בזמן אמת - חלק מהאלגוריתמים (במיוחד HNSW) מתפקדים פחות טוב עם מחיקות והוספות תכופות בלי re-indexing תקופתי; מאגר שמשתנה כל הזמן דורש אסטרטגיית תחזוקה מתוכננת.
• בחירת מנוע ייעודי מוקדם מדי - הוספת תשתית מורכבת נפרדת לפני שהוכח בפועל שהיקף הנתונים דורש אותה, כשהרחבה על מסד קיים הייתה מספיקה.

דוגמה מהשטח - כשהזיכרון נגמר בלי אזהרה

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

שאלות נפוצות

מה ההבדל בין ANN לחיפוש מדויק?

ANN מוותר על ודאות מוחלטת שהתוצאה היא באמת השכן הקרוב ביותר, בתמורה למהירות של סדרי גודל. ברוב מקרי השימוש בפרודקשן ה-Recall הגבוה שהוא מספק מספיק לחלוטין.

מתי כדאי לבחור IVF במקום HNSW?

כשזיכרון RAM הוא המגבלה הדוחקת ביותר, או כשהמאגר גדול מאוד וה-budget לצריכת זיכרון מוגבל. HNSW מתאים יותר כשדיוק ומהירות שאילתה קריטיים יותר מחיסכון בזיכרון.

איך Filtering משפיע על ביצועי חיפוש וקטורי?

תלוי בגישה - Post-filtering פשוט אך מסוכן עם תנאים מצמצמים; Pre-filtering ו-Hybrid filtering יעילים יותר אך דורשים תמיכה מובנית במנוע עצמו, לא כל מנוע תומך בהם באותה רמה.

האם pgvector מספיק לפרודקשן בקנה מידה גדול?

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

איך יודעים אם צריך לעבור למנוע Vector Database ייעודי?

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

ארכיטקטורת Vector Database נכונה היא הבדל ישיר בין מערכת חיפוש שמרגישה מיידית לבין אחת שקורסת תחת עומס. מדיה דיל בונה תשתיות פרודקשן ל-AI בקנה מידה - דברו איתנו בוואטסאפ.

תגיות: Vector Database · HNSW · ANN · Embeddings · Similarity Search · pgvector · Vector Search

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