RAG בפרודקשן: 6 לקחים קריטיים לביטוח ובריאות

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

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

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

1) מתחילים מבעיה עסקית אמיתית — לא ממצגת

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

בביטוח, “מענה לשאלות עובדים” זה לא יוזקייס. יוזקייס טוב נשמע כמו:

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

בבריאות, אותו עיקרון:

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

מדד הצלחה שאפשר להגן עליו

כדי לייצר ROI אמיתי, אני אוהב להגדיר יעד מספרי כבר בשלב האפיון:

• זמן ממוצע למציאת מידע: מ-6 דקות ל-2 דקות
• שיעור “העברה למומחה” (handoff): ירידה מ-40% ל-25%
• שיעור תשובות עם ציטוט מסמך מקור: יעד של 90%+

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

2) הכנת דאטה תיקח יותר זמן ממה שמתכננים — וזה בסדר

הנקודה המרכזית: איכות השליפה נקבעת בעיקר ע״י איכות הקורפוס, לא ע״י בחירת מודל השפה.

ארגונים רבים זורקים מסמכים גולמיים ל־Vector DB ומקווים ש־cosine similarity “יסדר”. בביטוח ובריאות זה כמעט תמיד נכשל בגלל:

• מסמכים סרוקים (OCR חלקי)
• טבלאות, נספחים והערות שוליים קריטיות
• גרסאות מרובות (טיוטות, עדכונים, תוספות)
• שפה מעורבת (עברית/אנגלית), קיצורים וטרמינולוגיה מקצועית

מה בונים במקום “זריקה לוקטור”

Pipeline בסיסי שמחזיק בפרודקשן כולל:

1. ניקוי והעשרה: OCR איכותי למסמכים סרוקים, נרמול כותרות, הסרת כפילויות.
2. מטא-דאטה קשיחה: תאריך תוקף, סוג מסמך, מחלקה/ענף, גרסה, בעלים.
3. בדיקות אוטומטיות: מסמכים בלי תאריך? בלי מזהה גרסה? נכנסים להסגר.
4. Versioning: אפשרות לדעת איזו גרסה נשלפה ומתי עודכנה.

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

3) Chunking טוב שומר רעיון שלם — לא גודל קבוע

הנקודה המרכזית: Chunking מוצלח שומר הקשר. Chunking נאיבי מייצר “שברי משפטים” שמבלבלים את השליפה.

בביטוח, משפט אחד יכול לשנות כיסוי:

“הכיסוי אינו חל במקרה של…”

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

Chunking סמנטי שעובד בארגונים

במקום לחתוך לפי 800 טוקנים או “כל פסקה”, עובדים לפי מבנה רעיוני:

• פיצול רקורסיבי לפי כותרות: מסמך → פרק → סעיף → תת־סעיף → פסקה.
• כל Chunk = טענה אחת: “חריגים”, “הגדרות”, “תהליך אישור”, “מסמכים נדרשים”.
• שימור עוגני מקור: מזהה סעיף/עמוד/כותרת כדי להציג למשתמש ציטוטים מדויקים.

בארגוני ביטוח אני ממליץ להוסיף גם “Chunking לפי ישויות”: פוליסה/כיסוי/חריג/סכום/תקופה — ואז להצליב עם מטא-דאטה כדי לצמצם רעש.

4) דאטה מתיישן. Embeddings מתיישנים. ואז האמון נעלם

הנקודה המרכזית: RAG שלא מתעדכן באופן שיטתי הופך למכונת “אמת היסטורית”.

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

אם המסמכים מתעדכנים אבל ה־Vector DB לא, המערכת תשלוף קטעים נכונים… לשנה שעברה.

אסטרטגיית עדכון פרקטית

מה שעובד בפרודקשן:

• טריגרים לרה־אמבדינג: עדכון גרסה של נהלים, שינוי רגולטורי, או שחרור “Policy Pack” רבעוני.
• Embedding Versioning: כל וקטור מקושר ל־document_version ול־embedding_run_id.
• Roll-forward/Rollback: היכולת להחליף אינדקס בלי להשבית שירות.

אני בעד אוטומציה אגרסיבית: עדיף להוציא עוד קצת חישוב מאשר לאבד אמון של משתמשים.

5) בלי הערכה (Evaluation) — הבעיות יופיעו רק בתלונות

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

ב־RAG צריך להעריך כמה שכבות במקביל:

הערכת שליפה (Retrieval)

• האם נשלפו 3–5 הקטעים הנכונים?
• מה שיעור ה־“miss” בשאילתות קריטיות (לדוגמה: חריגים מרכזיים בפוליסה)?

הערכת תשובה (Generation)

• האם התשובה מעוגנת במקור ומציגה ציטוט/הפניה?
• האם היא מסרבת לענות כשאין מקור ברור?

מדדי מוצר/עסק

• זמן סגירת תביעה (או זמן איתור נוהל)
• מספר פניות חוזרות על אותה שאלה
• שיעור אימוץ לפי צוות/מחלקה

סט בדיקות שמומלץ להתחיל איתו

• 50 שאלות “זהב” (Gold Set) מכל מחלקה
• 20 שאלות “מלוכלכות” (שגיאות כתיב, סלנג מקצועי)
• 10 שאלות “מלכודת” שמנסות להוציא תשובה בלי מקור

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

6) ארכיטקטורה אופנתית כמעט אף פעם לא מתאימה לביטוח/בריאות

הנקודה המרכזית: רוב הארגונים צריכים RAG בסיסי או דו־שלבי. Agentic RAG שמור למקרים נדירים.

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

מה לבחור ומתי

• RAG בסיסי (Monolithic): שאלות ישירות שחוזרות על עצמן (“מה מסמכי החובה לתביעה מסוג X?”).
• RAG דו־שלבי עם שכתוב שאילתה: כשהמשתמש כותב “קרה לי משהו באוטו” והמערכת צריכה להפוך זאת לשאילתת חיפוש מדויקת (“תביעת צד ג׳, נזקי רכוש, מסמכים נדרשים”).
• Agentic RAG: רק כשצריך לבצע תהליך רב־שלבי עם כלים (למשל, לאתר מסמך, להשוות לגרסה קודמת, לייצר טיוטת מכתב, ולפתוח משימה במערכת).

עמדה ברורה שלי: בארגונים עם סיכון תפעולי/רגולטורי, פשטות היא פיצ’ר.

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

“יש לנו מודל עם קונטקסט ענק. אפשר לוותר על Retrieval?”

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

“מה יותר חשוב: מודל טוב או Vector DB טוב?”

ברוב המקרים: הקורפוס, המטא-דאטה וה־chunking. מודל מצוין עם שליפה בינונית ייתן תשובות בינוניות.

“איך שומרים על תאימות רגולטורית?”

ע״י עקיבות: הצגת מקור, גרסאות, לוגים, מדיניות סירוב לענות, והפרדה בין “מידע” לבין “המלצה/החלטה”.

מה עושים מחר בבוקר: צ’ק ליסט לפרויקט RAG בארגון

1. בחרו יוזקייס אחד שמדיד (זמן/איכות/עלות) והגבילו scope.
2. בנו קורפוס נקי עם מטא-דאטה וגרסאות לפני שמחברים מודל.
3. הטמיעו Chunking סמנטי ושימרו עוגני מקור.
4. הגדירו רה־אמבדינג אוטומטי לפי טריגרים עסקיים.
5. הקימו Evaluation שבועי: שליפה + תשובה + מדדי מוצר.
6. התחילו בארכיטקטורה הפשוטה ביותר שמספקת ערך.

החיבור לסדרת “בינה מלאכותית בתחום הבריאות והביוטכנולוגיה” ברור: בין אם מדובר בנוהל קליני או בפוליסת ביטוח — הערך האמיתי של AI נמדד באמינות תפעולית. המודלים מתחלפים כל כמה חודשים; תשתית הדאטה והבקרה נשארת שנים.

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