מסד נתונים וקטורי (Vector Database)

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

מאחורי הקלעים, רוב מסדי-הנתונים הווקטוריים מסתמכים על אלגוריתמים לחיפוש-שכנים-קרובים-בקירוב. האלגוריתם הנפוץ ביותר לכך (HNSW — Hierarchical Navigable Small World) פורסם ב-2016, ומאפשר לחפש בין מיליוני וקטורים תוך מילישניות ספורות, במחיר קטן של דיוק מוחלט.

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

כמה חברות בנו מוצר עסקי שלם סביב היכולת הזו — Pinecone, Weaviate, ו-Chroma הן מהמוכרות שבהן, כל אחת עם גישה טכנית מעט שונה לאותה בעיה בסיסית. מסדי-נתונים ותיקים ומוכרים יותר (כמו PostgreSQL) לא נשארו מחוץ למגמה: הם הוסיפו תוספי-הרחבה ייעודיים (כמו pgvector) שמאפשרים חיפוש וקטורי בתוך מסד-נתונים קיים ומוכר, במקום להקים מערכת נפרדת לגמרי לצורך הזה — פתרון נוח לארגונים שכבר משתמשים במסד-הנתונים הזה למטרות אחרות ולא רוצים להוסיף עוד רכיב-תשתית נפרד.

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