מסד נתונים וקטורי עונה על שאלה אחת, מהר מאוד
תנו לו רשימת מספרים והוא מחזיר את הרשימות השמורות הקרובות אליה ביותר. זה כל הממשק.
הרשימות הן embeddings. מודל embedding הופך קטע טקסט, תיאור מוצר או תמונה למאות עד אלפי מספרים, הממוקמים כך שמשמעויות דומות נופלות קרוב זו לזו, ומהם embeddings ב-AI מסביר איך זה עובד. מסד נתונים וקטורי הוא המקום שבו הרשימות האלה חיות כשיש הרבה מהן. הוא שומר כל אחת עם מזהה ומטא-דאטה, בונה עליהן אינדקס, ועונה על חיפוש שכנים קרובים ביותר: "הנה וקטור שאילתה, תנו לי את עשרת הקרובים ביותר".
החלק הקשה הוא המילה מהר. השוואת שאילתה מול מיליון וקטורים שמורים בני 1,536 מספרים כל אחד היא 1.5 מיליארד כפלים, ולעשות זאת בכל הקשה על מקלדת פשוט לא מתרחב. לכן מסדי נתונים וקטוריים משתמשים באינדקסים של שכנים קרובים ביותר בקירוב, הנפוץ שבהם HNSW, מבנה גרף ממאמר מ-2016 של Malkov ו-Yashunin שבודק כמה מאות מועמדים במקום את כל המיליון ומחזיר את התשובה הנכונה כמעט תמיד. ה"כמעט" הזה הוא העסקה: מעט דיוק תמורת האצה של פי אלף.
מסד הנתונים הקיים שלכם מתאים מילים; מסד נתונים וקטורי מתאים משמעות
מסד נתונים רלציוני מוצא שורות שהערכים שלהן תואמים: WHERE customer_id = 4127. אינדקס טקסט מלא מוצא מסמכים המכילים מילים: refund AND policy. מסד נתונים וקטורי מוצא פריטים שהמשמעות שלהם קרובה: השאילתה "איך אני מקבל את הכסף שלי בחזרה" מחזירה את הקטע שכותרתו "החזרות וזיכויים" למרות ששני הביטויים לא חולקים אף מילה.
| מסד נתונים רלציוני | חיפוש טקסט מלא | מסד נתונים וקטורי | |
|---|---|---|---|
| שואל | אילו שורות תואמות לערך הזה? | אילו מסמכים מכילים את המילים האלה? | אילו פריטים משמעותם קרובה לזה? |
| אינדקס | עץ B על עמודות | אינדקס הפוך על מונחים | גרף או אשכולות על וקטורים (HNSW, IVF) |
| מדויק? | כן | כן | בדרך כלל בקירוב |
| טוב ב | מזהים, תאריכים, סכומים, joins | שמות, קודים, ביטויים מדויקים | מילים נרדפות, ניסוח מחדש, שפות שונות, תמונות |
| חלש ב | משמעות | משמעות | מחרוזות מדויקות, ספירה, סינון לפי ערך |
| דוגמאות | Postgres, MySQL, SQLite | Elasticsearch, Lucene | Pinecone, Weaviate, Qdrant, Milvus, Chroma, pgvector |
השורה האחרונה מראה עד כמה מטושטשת הקטגוריה. pgvector מוסיף עמודות וקטור ואינדקס HNSW ל-Postgres רגיל, ו-Elasticsearch נושא שדה וקטורי מאז גרסה 7.0 ב-2019 וחיפוש HNSW מאז 8.0 ב-2022. "מסד נתונים וקטורי" הוא לעיתים קרובות יכולת בתוך מסד נתונים שכבר מריצים ולא מוצר חדש, והמוצרים העצמאיים מתחרים על קנה מידה וליטוש תפעולי, לא על עשיית משהו ש-Postgres לא יכול.
צ'אט עם המסמכים שלכם הוא חיפוש וקטורי עם מודל בקצה
יצירה מוגברת באחזור, שמהו RAG סוקר, כוללת שלב חיפוש ושלב כתיבה. מסד הנתונים הוקטורי הוא שלב החיפוש.
- מפצלים כל מסמך לקטעים של כמה מאות עד אלף טוקנים.
- עושים embedding לכל קטע ושומרים את הוקטורים, עם טקסט הקטע ומקורו, במסד הנתונים הוקטורי.
- כשמגיעה שאלה, עושים לה embedding ומבקשים מהמסד את הקטעים הקרובים ביותר.
- מוסרים את הקטעים האלה למודל השפה יחד עם השאלה, ונותנים לו לכתוב את התשובה.
שלבים 1 ו-2 קורים פעם אחת, כשמוסיפים את המסמכים. שלבים 3 ו-4 קורים בכל שאלה. מודל השפה אף פעם לא רואה את כל האוסף; הוא רואה את חמשת או עשרת הקטעים שהמסד בחר. לכן התשובה טובה רק כמו החיפוש: אם הוקטור הקרוב ביותר הוא הקטע הלא נכון, המודל עונה בביטחון על השאלה הלא נכונה, מה שמהי הזיה של AI מתייג כפספוס אחזור ולא כהמצאה.
מתי צריך אחד, ומתי עדיף לשלוח את הקובץ בשלמותו
ההחלטה קשורה לגודל. מודל יכול להתחשב רק בחלון ההקשר שלו בבת אחת, ומשלמים על כל טוקן בתוכו בכל תור. מסד נתונים וקטורי קיים כדי להציב רק את הפרוסה הרלוונטית מול המודל. עבור מסמך אחד שנכנס בשלמותו, אחזור הוא שלב שאפשר לדלג עליו; עבור אוסף שלא נכנס, זו האפשרות היחידה.
נתמחר את שני העיצובים על דוח בן 300,000 טוקנים, כמה מאות עמודים, עם עשר שאלות, כשמאחזרים חמישה קטעים של 1,000 טוקנים לכל שאלה. שליחת הקובץ המלא בכל פעם היא 3 מיליון טוקני קלט. אחזור חמישה קטעים של 1,000 טוקנים לשאלה הוא 50,000. לפי תעריפי הקלט הרשמיים במדד עלות מודלי AI, שנשלף מ-OpenRouter ב-2026-08-20, הפער הוא פי 60 בכל מודל. מטמון פרומפט, במקום שבו הספק מציע אותו, מחייב קריאה חוזרת של אותו קובץ במחיר של עשירית עד חצי מהמחיר הרשמי, מה שמצמצם את הפער לכ-פי 6 עד פי 30. האחזור עדיין מנצח, אבל בפער קטן יותר.
עיצוב הקובץ המלא קונה משהו בעד הכסף הזה כשהקובץ נכנס בתקציב: חוזה בן 60 עמודים, כ-40,000 טוקנים, מאפשר למודל לענות על שאלות שדורשות את כל המסמך בבת אחת, כמו "האם משהו כאן סותר את סעיף 14", דבר שאחזור לא יכול לשאול כי הוא אף פעם לא רואה את סעיף 14 ואת הסתירה באותו אצווה. הכלל שנובע מכך: מסמך אחד, או כמה בודדים, נכנס בשלמותו; ספרייה עוברת דרך מסד נתונים וקטורי. בין השניים, כדאי לפצל את ההעלאה לפי נושא כדי שהמודל יקבל את הקטע שהוא צריך.
Whizi שולח את הטקסט עצמו, עד תור בן 40,000 טוקנים
Whizi לא מריץ מסד נתונים וקטורי עבור הצ'אט שלכם. כשמצרפים קובץ, נתיב העלאת מסמכים מחלץ את הטקסט ושולח אותו למודל כטקסט פרומפט, עד תקציב שטוח של 40,000 טוקנים לתור; העלאה ארוכה יותר נחתכת, עם הודעת toast וסימון בתוך ההודעה שאומר זאת. קבצי פרויקט עובדים באותו אופן: תכונת הפרויקטים מצמידה עד 10 קבצים ובונה מחדש את הטקסט שלהם לתוך הפרומפט בכל הודעה, בהגבלה של 32,000 תווים לקובץ ו-120,000 לכל בלוק הפרויקט.
המגבלות הן קצה העיצוב. קובץ מוצמד מעבר ל-32,000 תווים נחתך, קובץ מצורף מעבר לתקציב התור של 40,000 טוקנים נחתך, ופרויקט הוא תיקייה, לא ספרייה ניתנת לחיפוש. העסקה מכוונת: עבור חוזה או מאמר שנכנס בתקציב התור, שהטקסט נוכח עדיף על שהוא ייחפש, והבדיקה שחשובה, לבקש מהמודל לצטט את הקטע שבו השתמש, עובדת כי הקטע שם. עבור אלף מסמכים, מסד נתונים וקטורי הוא הכלי הנכון ואפליקציית צ'אט היא הכלי הלא נכון.
שתי הרגלים נובעים מהמנגנון. ציינו את שם הקובץ בשאלה שלכם כשכמה קבצים מצורפים, כי אחרת המודל בוחר בשקט. ובכל תשובה שתפעלו לפיה, בקשו את הציטוט. מערכת אחזור עלולה להחזיר את הקטע הלא נכון; מערכת קובץ מלא עלולה לענות מהזיכרון במקום מהקובץ. הציטוט תופס את שניהם.
- שלחו מסמך אחד בשלמותו; שימו אוסף מאחורי מסד נתונים וקטורי
- פצלו העלאה ארוכה לפי נושא כדי שהמודל יקבל את הקטע שהשאלה צריכה
- בקשו מהמודל לצטט את הקטע שבו השתמש לפני שסומכים על התשובה
- השתמשו בחיפוש טקסט רגיל למזהים, קודים וביטויים מדויקים; חיפוש וקטורי מתאים משמעות, לא תווים
- התייחסו לפספוס אחזור כבעיית חיפוש: עשו embedding מחדש עם מודל טוב יותר או קטעים קטנים יותר לפני שמאשימים את מודל הכתיבה
שאלות נפוצות
מהו מסד נתונים וקטורי במילים פשוטות?
מאגר לרשימות המספרים שמודל AI משתמש בהן כדי לייצג משמעות, בנוי כדי למצוא התאמות קרובות מהר. נותנים לו את ה-embedding של שאלה והוא מחזיר את ה-embeddings, והטקסט שמאחוריהם, שמשמעותם דומה. זהו חצי החיפוש של צ'אט עם המסמכים שלכם בכל פעם שהאוסף גדול מכדי לשלוח בשלמותו.
האם אני צריך מסד נתונים וקטורי כדי להשתמש ב-AI עם המסמכים שלי?
רק אם המסמכים לא נכנסים לחלון ההקשר של המודל. דוח או חוזה בודד אפשר לשלוח למודל בשלמותו, וזה מה ש-Whizi עושה עם קבצים מצורפים וקבצי פרויקט מוצמדים. ספרייה של אלפי מסמכים דורשת אחזור, ואחזור דורש אינדקס וקטורי, בין אם במוצר ייעודי ובין אם בתוסף Postgres כמו pgvector.
מה ההבדל בין מסד נתונים וקטורי למסד נתונים רגיל?
מסד נתונים רגיל מתאים ערכים: המזהה הזה, התאריך הזה, המילה המדויקת הזו. מסד נתונים וקטורי מתאים משמעות, ומחזיר את הפריטים השמורים שה-embeddings שלהם קרובים ביותר לשאילתה. הוא בדרך כלל בקירוב, ומשתמש באינדקס כמו HNSW שבודק כמה מאות מועמדים במקום כל פריט, והוא חלש בהתאמה המדויקת שמסד נתונים רגיל טוב בה.
אילו מסדי נתונים וקטוריים נפוצים ביותר?
Pinecone, Weaviate, Qdrant, Milvus ו-Chroma הם המוצרים העצמאיים הנפוצים, ו-pgvector מוסיף את אותה יכולת ל-Postgres. גם Elasticsearch ו-OpenSearch מציעים חיפוש וקטורי. הבחירה בדרך כלל תפעולית, לגבי קנה מידה ואירוח, כי כולם מיישמים את אותו רעיון של שכנים קרובים ביותר בקירוב.
כמה חוסך אחזור בהשוואה לשליחת הקובץ המלא?
עשר שאלות על דוח בן 300,000 טוקנים עולות $6.00 ב-Claude Sonnet 5 אם הקובץ נשלח בכל תור, ו-$0.10 אם מאחזרים חמישה קטעים של 1,000 טוקנים במקום זאת, לפי תעריפי OpenRouter הרשמיים שנשלפו ב-2026-08-20. ב-GPT-5.6 Luna אותו זוג הוא $0.60 מול $0.01. היחס הוא פי 60 בכל מודל כי שני העיצובים משלמים אותו תעריף לכל טוקן.
