מתי וקטור DB מיותר: RAG מהיר לביטוח ובריאות

24.54 מילישניות מול 0.47 מילישניות נשמע כמו החלטה ברורה—אבל זו בדיוק המלכודת. בבדיקת ביצועים טיפוסית, חיפוש “נאיבי” על אמבדינגים (סריקה מלאה) לקח בממוצע 24.54ms לשאילתה, בעוד שאינדקס ANN מסוג HNSW הוריד את זמן השאילתה ל-0.47ms. הבעיה? בניית האינדקס לקחה בערך 277 שניות. המשמעות: צריך בערך 11,510 שאילתות כדי שההשקעה באינדוקס “תחזיר את עצמה” בזמן.

רוב הצוותים שמקימים מערכת RAG נופלים לאוטומט: “יש embeddings, לכן צריך Vector DB”. בפועל, בהרבה תרחישים—במיוחד כאלה קצרים, פר-משתמש, או בזמן אמת—וקטור DB מוסיף עיכוב, עלות ותפעול, בלי לתת ערך אמיתי.

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

השאלה הנכונה: האם האינדוקס בכלל משתלם?

התשובה הישירה: וקטור DB משתלם כשיש קורפוס גדול ומתמשך והרבה שאילתות חוזרות. הוא פחות משתלם כשהנתונים “נזרקים” אחרי דקות.

וקטור DB לא רק “שומר וקטורים”. הוא בדרך כלל:

• בונה אינדקס ANN (למשל HNSW) כדי להאיץ חיפוש דמיון.
• משלם מחיר זמן/CPU/זיכרון לבנייה ולעדכון האינדקס.
• מוסיף שכבת תפעול: קלסטר, ניטור, גיבוי, הרשאות, ניהול סכמות/מטא-דאטה.

כשיש לכם מיליוני מסמכים וזרם שאילתות גדול לאורך זמן, האינדקס הוא השקעה מצוינת. אבל כשמדובר בסט קטן של מסמכים פר-משתמש—האינדקס הוא בעיקר “מס” שאתם משלמים לפני שהמשתמש מקבל תשובה ראשונה.

משפט שאפשר לתלות ליד הלוח: אינדוקס הוא חוב זמנים שמחזירים רק אם יש מספיק שאילתות.

תרחישים קצרים-חיים (Ephemeral): דווקא כאן פשטות מנצחת

התשובה הישירה: אם הקונטקסט נבנה “כאן ועכשיו” ונעלם תוך דקות, חיפוש ללא אינדקס או אחסון Key-Value לרוב יעבדו טוב יותר.

בואו נתרגם את התרחיש המקורי לעולמות שלנו:

דוגמה בביטוח: תביעה שנכנסת עם מסמכי PDF ותמונות

מבוטח מעלה מסמכים: דו"ח שמאי, צילומי נזק, התכתבויות. אתם מפצלים לקטעים, מייצרים embeddings, ומאפשרים:

• שאלות של נציג שירות במשך שיחה אחת
• בדיקת עקביות מול פוליסה
• טריגרים לזיהוי חריגות/הונאה

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

דוגמה בבריאות/ביוטק: סיכום אשפוז או הפניה דחופה

רופא/אחות מעלים סיכום אשפוז או תוצאות בדיקה ומבקשים:

• תקציר קליני
• איתור תרופות/אלרגיות במסמך
• התאמה לפרוטוקול

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

בתרחישים כאלה, אתם רוצים שני דברים:

1. Time-to-first-answer קצר (הזמן עד התשובה הראשונה)
2. מורכבות תפעולית מינימלית

וקטור DB נוטה לשפר את (1) רק אחרי שמשלמים מחיר משמעותי, ולפעמים פוגע ב-(2) מהיום הראשון.

המספרים שמכריעים: נקודת האיזון (Break-even)

התשובה הישירה: נקודת האיזון בין סריקה מלאה לבין אינדקס נמדדת לרוב באלפי שאילתות—לא בעשרות.

במדידה שהוצגה במאמר המקורי (סטנדרט נפוץ של embeddings במימד 1,536, 50,000 וקטורים, Top-5):

• סריקה מלאה (KNN בלי אינדקס): ~24.54ms לשאילתה
• בניית אינדקס HNSW: ~277 שניות
• שאילתה עם אינדקס: ~0.47ms

הפער לשאילתה הוא בערך 24.07ms. כדי לכסות 277 שניות, צריך בערך:

• 277,000ms / 24.07ms ≈ 11,510 שאילתות

עכשיו תשאלו את עצמכם בכנות:

• כמה שאילתות יש בפועל “לסט מסמכים של משתמש אחד”?
• 30?
• 120?
• 400?

אם התשובה רחוקה מאלפים—אתם כנראה משלמים מחיר אינדוקס בלי לקבל החזר.

כלל אצבע פרקטי לצוותי מוצר ו-Data

אני משתמש בשלוש שאלות כדי להחליט:

1. TTL לקונטקסט: לכמה זמן אני צריך את האמבדינגים? דקות / שעות / חודשים
2. QPS פר קונטקסט: כמה שאילתות באמת יישאלו על אותו סט?
3. גודל סט פר קונטקסט: כמה chunks/וקטורים פר משתמש/בקשה?

כש-TTL קצר, QPS נמוך וגודל סט בינוני—הבחירה הנכונה נוטה להיות בלי Vector DB.

מה לשים במקום Vector DB: שלוש חלופות שעובדות

התשובה הישירה: בהרבה מערכות RAG תפעוליות, אפשר לבחור אחת משלוש חלופות פשוטות—ולקבל מערכת מהירה יותר מקצה לקצה.

1) In-Memory + סריקה מלאה (Naive KNN)

כשאפשר להחזיק את הווקטורים בזיכרון האפליקציה (או בזיכרון של שירות ייעודי), הפתרון הכי פשוט הוא:

• לשמור מערך embeddings
• בכל שאילתה לחשב דמיון מול כולם
• לבחור Top-k

זה נשמע “ברוטלי”, אבל בסטים קטנים-בינוניים זה עובד מצוין—והיתרון הכי גדול הוא שאין שלב “הכנה” כבד.

מתאים במיוחד ל:

• עוזר תביעות בזמן שיחה
• סיכום מסמכים רפואיים בסשן קצר
• ניתוח חריגות נקודתי על תיק בודד

2) Key-Value Store עם TTL (למשל Redis) + חיפוש באפליקציה

כשאתם כן צריכים שיתוף בין שירותים (מיקרו-סרביסים) או שרידות למספר דקות, הגישה הפרקטית היא:

• מפתח: request_id / claim_id / session_id
• ערך: embeddings + מטא-דאטה מינימלי
• TTL קצר: 5–30 דקות (תלוי בתהליך)

ככה מקבלים:

• אחסון מהיר
• ניהול מחזור חיים אוטומטי
• בלי אינדוקס כבד

בביטוח זה יושב מצוין על תרחישי הערכת סיכון בזמן אמת, בדיקת הונאה ראשונית, או שירות לקוחות. בבריאות—על תרחישי טריאז’, סיכומי ביקור, או תמיכה בהחלטה קלינית במקטע זמן קצר.

3) אינדקס “קל” בצד האפליקציה (רק אם צריך)

לפעמים יש לכם סט של 200k–1M וקטורים פר קונטקסט, או מגבלות latency קשות. לפני שקופצים לוקטור DB, אפשר לשקול:

• אינדקס מקומי קצר-חיים (נבנה בזיכרון ונזרק)
• בנייה אסינכרונית אחרי תשובה ראשונה

העיקרון: להקטין את הפגיעה ב-Time-to-first-answer.

מתי כן להשתמש ב-Vector DB (ואסור להתבייש בזה)

התשובה הישירה: כשיש קורפוס משותף גדול, מתמשך, וריבוי שאילתות—Vector DB הוא בחירה נכונה.

הנה מצבים שבהם וקטור DB בדרך כלל כן מצדיק את עצמו:

• מאגר ידע ארגוני קבוע: נהלים, פוליסות, חוזים, מדריכים קליניים
• חיפוש סמנטי בקנה מידה גדול: מיליוני מסמכים, שאילתות מכל הארגון
• ריבוי משתמשים על אותו קורפוס: חיסכון האינדוקס מתחלק על הרבה שאילתות
• צרכים מתקדמים: פילטרים מורכבים, עדכונים מנוהלים, רפליקציה, הרשאות, Multi-tenancy

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

שאלות נפוצות (כמו שמנהלים אוהבים לשאול)

“אם לא Vector DB, זה לא פחות מדויק?”

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

“ומה לגבי פרטיות ורגולציה?”

דווקא כאן TTL קצר ו-Key-Value עם הפרדה לפי session_id יכול להיות יתרון. פחות שאריות מידע, פחות שכבות, פחות נתונים שנשארים “בטעות” לאורך זמן.

“איך זה משתלב עם AI בבריאות אם הדוגמאות ביטוחיות?”

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

מה הייתי עושה מחר בבוקר: צ’ק ליסט החלטה מהיר לצוותים

התשובה הישירה: תחליטו על אחסון אמבדינגים לפי TTL×שאילתות×עלות אינדוקס—לא לפי טרנד.

1. מדדו: כמה זמן לוקח לכם לייצר embeddings, וכמה שאילתות יש בפועל פר סשן.
2. קבעו TTL ברור לקונטקסט (למשל 10 דקות לתביעה בשיחה; 30 דקות לטריאז’).
3. התחילו פשוט:
   • In-memory אם אפשר
   • אחרת Key-Value עם TTL
4. רק אם יש קורפוס מתמשך והרבה שאילתות—עברו ל-Vector DB.
5. בנו KPI אחד שלא מרמים בו: Time-to-first-answer.

הדבר היפה? זו החלטה שאפשר לבדוק מהר. אם אתם רואים שבכל “קונטקסט” יש 80 שאילתות, אין שום סיבה לשלם מחיר של אינדוקס שמחזיר את עצמו רק אחרי אלפים.

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