פרק 100 - דמיון וקטורי עם מירב גרימברג מ-Redis
דמיון וקטורי לא מחליף את הדאטאבייס שלכם. מירב גרימברג מ-Redis מסבירה איך Embeddings, RAG ו-tradeoffs של דיוק ומהירות הופכים דאטה למשמעות בפרודקשן.
צפו בהרצאה · 34:53
הסיפור שמאחורי ההרצאה
- Embedding הוא ייצוג מספרי של משמעות. דמיון וקטורי מודד את הקרבה בין הייצוגים, לא התאמה של מילות מפתח.
- ב-RAG מחפשים קודם כמה מסמכים רלוונטיים, ורק אותם שולחים יחד עם השאלה ל-LLM.
- Vector Database מחזיק גם מסמכים ומטה-דאטה, ולכן אפשר לשלב חיפוש סמנטי עם פילטרים רגילים.
- אין כאן silver bullet: האינדקס מחייב tradeoffs בין דיוק, זיכרון, מהירות הכנסה ומהירות חיפוש.
- כדאי להתחיל ב-Brute Force על דאטה קטן, למדוד, ורק אז לכוון HNSW לפרודקשן.
דמיון וקטורי מתחיל במקום שבו חיפוש רגיל נגמר. אפשר לתייג מוצר לפי צבע, מחיר או מותג. אי אפשר לכתוב מראש את כל הדרכים שבהן משתמש עשוי לחשוב שהוא דומה למשהו אחר. בלייב במיקרוסופט, מירב גרימברג מ-Redis מפרקת את הפער הזה: איך הופכים טקסט, תמונות או וידאו ל-Embeddings, איך מודדים את הקרבה ביניהם, ולמה זה הפך לרכיב מרכזי ב-RAG ובמוצרים שמבוססים על AI. זה לא קסם שמחליף דאטהבייס. זה עוד כלי, עם יתרונות ברורים ועם מחיר שצריך למדוד.
מה זה דמיון וקטורי ולמה מילות מפתח לא מספיקות
Embedding הוא ייצוג נומרי של מידע. מודל Embeddings מקבל raw data - למשל טקסט, תמונה או וידאו - ומחזיר רשימת מספרים. הרשימה הזו אינה תיאור שבני אדם קוראים. היא דרך למקם את המידע כך שפריטים עם משמעות סמנטית דומה יהיו קרובים זה לזה.
מירב משתמשת בדוגמה פשוטה: שיר של נועה קירל ושיר של אנה זק צפויים להיות קרובים יותר זה לזה מאשר לשיר של מרגול. לא כי המערכת סופרת מילים בשירים, אלא כי המודל הפיק לכל אחד ייצוג שניתן להשוות. דמיון וקטורי מודד את הקרבה בין שני הווקטורים ומתרגם אותה להערכה: עד כמה שני פריטי המידע קרובים במשמעות.
הבעיה שחיפוש כזה פותר היא לא שאין מטה-דאטה. הבעיה היא שמטה-דאטה לא מספיק לכל מצב. כששחר זורק לקהל את המילים מראה וכיסא, מיד אפשר להציע תכונות: צבע, גובה, חומר, אולי המילה הראשונה בשם. אבל מספר התכונות האפשריות ממשיך לגדול. חיפוש קלאסי לא יכול לקבל את כל התיוגים שבעולם ולהישאר שימושי. וקטור נותן למערכת שכבה נוספת: חיפוש לפי דמיון, לא רק לפי מה שתוכנן כשנכתב ה-schema.
איפה Vector Similarity פוגש מוצר אמיתי
הדוגמאות בהרצאה מוכרות גם למי שלא כתב שורת קוד סביב AI. זיהוי פנים בתמונות, זיהוי פרח מתוך צילום, clustering של תמונות, זיהוי שימוש חריג באפליקציה ומערכות המלצה של חנויות - כולם יכולים להישען על השוואת וקטורים. בפריט מסחר, למשל, אפשר למצוא מוצרים שדומים למוצר שהמשתמש כבר ראה, בלי לבקש מאיש תוכן להגדיר כל קשר אפשרי ביניהם.
החיבור שמעסיק צוותי פיתוח היום הוא RAG. במקום לשלוח שאלה ל-LLM ולקוות שהוא מכיר את הנהלים, התיעוד והמידע העדכני של הארגון, משתמשים בחיפוש כדי להביא לו הקשר. זה אותו עיקרון של AI שמקבל מידע רלוונטי לפני שהוא עונה, שמופיע גם בהרצאה על MCP Servers ואבטחה בארגון: לא מבקשים מהמודל לנחש את העולם הפנימי שלכם.
RAG לא מאמן מודל מחדש
LLM יכול להיות חזק מאוד ועדיין לא לדעת איך לפתוח טיקט ב-Jira של החברה שלכם. הוא גם לא מתעדכן בכל שינוי פנימי, והעברת כל היסטוריית השיחה וכל תיעוד הארגון בכל בקשה מגדילה latency ועלות טוקנים. מירב מתארת את RAG כתשובה לפער הזה, לא כתחליף למודל.
מכינים מראש את המידע הארגוני: ממירים מסמכים ל-Embeddings ושומרים אותם ב-Vector Database. כשמגיעה שאלה, ממירים גם אותה לווקטור בעזרת אותו מודל שבו השתמשו למסמכים. הדאטאבייס מחזיר, למשל, חמישה מסמכים קרובים. רק הטקסט של המסמכים האלה נשלח עם השאלה המקורית ל-LLM, והוא מייצר תשובה על בסיס הקשר ממוקד יותר.
היתרון אינו רק ידע ארגוני. אימון מודל על מידע חדש דורש הרבה דאטה, משאבים וזמן, וצריך לחזור עליו כשיש שינוי. RAG מאפשר להחליף או לעדכן את המסמכים בדאטאבייס במקום לאמן את המודל מחדש. זה גם לא מבטיח תשובה נכונה אוטומטית. אם בוחרים מודל Embeddings שלא מתאים לסוג הדאטה, או שהמסמכים לא מיוצגים ומחולקים נכון, החיפוש יחזיר הקשר חלש וה-LLM ימשיך לעבוד עם בסיס רע.
מה מקבלים מ-Vector Database
מירב מציגה Vector Database כדאטאבייס שתומך בפעולות CRUD הרגילות, אבל שומר לצד המסמך גם את הווקטור שמייצג אותו. התוספת החשובה היא שאפשר לבצע עליו חיפוש וקטורי, המכונה גם KNN - החזרת K ה-nearest neighbors, כלומר מספר הווקטורים הקרובים ביותר לשאילתה.
זה לא אומר לזרוק את החיפוש המסורתי. במסמך אפשר לשמור גם תאריך, מותג, תוקף או שדות עסקיים אחרים, ולשלב אותם בפילטר עם דמיון וקטורי. חנות יכולה להחזיר מוצרים דומים למוצר שנצפה, אבל לצמצם למותג שהיא רוצה לקדם או למוצרים שתוקפם קרוב. ההחלטה היא לא בין וקטורים ל-schema. היא איך לחבר ביניהם בלי לשקר לעצמכם לגבי הצורך.
ה-tradeoffs שאי אפשר להסתיר מאחורי אינדקס
Vector Database אינו silver bullet. מירב מצביעה על ארבעה tradeoffs: דיוק התוצאות, זיכרון, מהירות ההכנסה של וקטורים ומהירות החיפוש. אי אפשר למקסם את כולם בלי מחיר. הבחירה תלויה במה שהאפליקציה צריכה ולא במה שנשמע הכי מרשים בדמו.
האלגוריתם הבסיסי הוא Brute Force או FLAT. מכניסים וקטורים, וכשמגיעה שאילתה משווים אותה לכל וקטור בדאטאבייס ומחזירים את הקרובים ביותר. זו דרך ישירה ומדויקת, וההכנסה מהירה. אבל החיפוש נהיה יקר כשיש מיליארדי וקטורים. משתמש לא אמור לחכות זמן ארוך לתוצאה רק מפני שהמערכת סרקה הכול.
HNSW, האלגוריתם המקורב שמירב מזכירה, משנה את המחיר. בעת ההכנסה הוא מחבר וקטורים קרובים כך שהחיפוש יכול להתחיל באזור מבטיח במקום לסרוק את כל הדאטאבייס. החיפוש מהיר בהרבה, אבל ההכנסה איטית יותר ויש סיכוי קטן שלא יוחזר הווקטור הכי קרוב בעולם. אפשר לכוון פרמטרים, אבל קודם צריך לדעת מהו דיוק מספיק עבור המוצר שלכם.
איך מתחילים בלי להתאהב בהייפ
ההמלצה המעשית של מירב טובה יותר מלהעתיק קונפיגורציה מהאינטרנט: מתחילים ב-POC עם dataset קטן ו-Brute Force. בודקים מה באמת מתקבל. אחר כך מריצים HNSW על אותו מידע, משווים תוצאות ומכוונים את הפרמטרים לפי הדיוק הנדרש. רק אז עוברים לפרודקשן.
הבחירה במודל חשובה באותה מידה. הוא צריך להתאים לדאטה - טקסט, תמונות, וידאו או משהו אחר - וגם לצורת הייצוג והשאילתה. מירב מזכירה גם שמדדי מרחק כמו cosine ו-Euclidean מוגדרים בדרך כלל לפי המודל שבחרתם. זו לא נוסחה שצריך להמציא בכל פרויקט, אבל זו כן הגדרה שחייבת להתאים לשאר הצינור.
השורה התחתונה
- דמיון וקטורי מחפש משמעות קרובה, לא רק התאמה של מילים או שדות.
- RAG מביא ל-LLM כמה מסמכים רלוונטיים במקום להכריח אותו להכיר את כל הידע הארגוני.
- Vector Database משלים חיפוש מסורתי ואינו מחליף אותו בכל use case.
- דיוק, זיכרון, מהירות indexing ומהירות חיפוש הם tradeoffs, לא הגדרות שאפשר לקבל כולן בחינם.
- התחילו במדידה על דאטה אמיתי. אחר כך בחרו אינדקס ופרמטרים.
לצפייה בהרצאה המלאה: https://www.youtube.com/watch?v=Vh8kz7F5uLE
"אבל וקטור יחיד בעצמו בעולם אין כל כך משמעות כפרט,"
- מירב גרימברג
"לאמן מודל לוקח יותר משאבים."
- מירב גרימברג
"זה שאנחנו לא מחפשים בכל הדאטאבייס,"
- מירב גרימברג
- 02:08 מהו Vector Similarityמירב מגדירה Embeddings כייצוג מספרי של משמעות סמנטית ומסבירה למה וקטורים קרובים מייצגים מידע דומה.
- 06:25 מחיפוש לפי שדות לחיפוש לפי משמעותדוגמת המראה והכיסא מראה למה אי אפשר לתייג כל תכונה אפשרית, ואיך וקטורים משלימים את המטה-דאטה.
- 08:03 זיהוי פנים, המלצות ו-RAGהדיון מחבר דמיון וקטורי לזיהוי תמונות, אנומליות, מנועי המלצה וצ׳אטבוטים ארגוניים.
- 11:17 מה עושה Vector DatabaseRedis מאחסן מסמכים ווקטורים, תומך ב-CRUD ומחזיר את ה-K nearest neighbors הקרובים לשאילתה.
- 14:16 למה LLM צריך RAGLLM אינו מאומן על המידע הארגוני העדכני, והעברת היסטוריה מלאה עולה זמן וטוקנים.
- 17:49 צינור RAG בפועלממירים את השאלה לווקטור באותו מודל, מחזירים מסמכים קרובים, ושולחים אותם עם השאלה ל-LLM.
- 20:01 חיפוש היברידי עם פילטריםחיפוש וקטורי יכול לעבוד לצד תאריכים, מותג, תוקף ושדות מסורתיים אחרים במסמך.
- 22:09 ה-tradeoffs של אינדקס וקטורימירב מפרקת את המתח בין דיוק, זיכרון, מהירות הכנסת וקטורים ומהירות החיפוש.
- 24:12 Brute Force, מרחקים ו-HNSWהאלגוריתם המדויק סורק הכול, בעוד HNSW מקריב מעט דיוק כדי להגיע לחיפוש מהיר בהרבה.
- 30:29 מה חשוב לבדוק בפרודקשןהמלצת הסיום היא להתחיל ב-POC קטן, להשוות תוצאות ולכוון את האינדקס לפי הדיוק שהאפליקציה באמת צריכה.
מה כוסה בהרצאה
שאלות מההרצאה
מה זה דמיון וקטורי?
דמיון וקטורי הוא מדד לקרבה בין שני Embeddings. כל Embedding הוא רשימת מספרים שמודל יוצר עבור טקסט, תמונה או מידע אחר. כשהווקטורים קרובים, המערכת מסיקה שהמידע שהם מייצגים קרוב במשמעות, גם אם לא מופיעות בו אותן מילות מפתח.
מה ההבדל בין Vector Search לחיפוש רגיל?
חיפוש רגיל נשען על שדות, טקסט ומטה-דאטה שהוגדרו מראש. Vector Search מחפש קרבה במשמעות. בהרצאה מירב מדגישה שלא צריך לבחור רק אחד מהם: אפשר למצוא פריטים דומים וקטורית, ובאותה שאילתה לצמצם לפי תאריך, מותג או שדה רגיל אחר.
איך RAG משתמש בוקטורים?
מכינים מראש את מסמכי הארגון כ-Embeddings ושומרים אותם ב-Vector Database. כשמשתמש שואל שאלה, ממירים גם אותה לווקטור באותו מודל, מחזירים כמה מסמכים קרובים, ושולחים את הטקסט שלהם יחד עם השאלה ל-LLM. כך התשובה נשענת על מידע רלוונטי ועדכני בלי לאמן מודל מחדש.
מתי לבחור HNSW במקום Brute Force?
Brute Force משווה את השאילתה לכל הווקטורים ולכן נותן נקודת ייחוס מדויקת, אבל נעשה איטי כשכמות הווקטורים גדלה. HNSW בונה קשרים בין וקטורים בעת ההכנסה ומחפש באזור רלוונטי, ולכן הוא מהיר יותר אך מקורב. מירב ממליצה להתחיל בדאטה קטן עם Brute Force, להשוות, ורק אז לכוון HNSW לפרודקשן.