6 לקחים מ‑RAG בפרודקשן: דיוק, אמינות וצמצום הונאות

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

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

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

1) איכות נתונים היא לא “שיפור נחמד”—היא תנאי להפעלה

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

ברוב הארגונים, מאגרי הידע נראים כך: גרסאות שונות של אותו נוהל, קבצי PDF סרוקים עם OCR חלקי, טבלאות אקסל לא עקביות, וקיצורים שמובנים רק לוותיקים. ב‑RAG כל זה מתרגם לבעיה אחת: אי-עקביות בתשובות.

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

מה עובד בפועל:

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

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

2) עיצוב שליפה (Retrieval) חשוב יותר מהפרומפט

התשובה הישירה: הפרומפט יכול לשפר ניסוח; השליפה קובעת אם התשובה נכונה.

הרבה צוותים משקיעים ימים בלשייף הנחיות למודל (“תהיה מדויק… תצטט…”). ואז מגלים שהוא מצטט מסמך לא רלוונטי. זה לא בעיית ניסוח—זו בעיית ריקול ודיוק בשליפה.

עקרונות תכנון שליפה שעובדים בפרודקשן:

היברידי ולא דוגמטי

במקום להסתמך רק על חיפוש סמנטי (וקטורי) או רק על חיפוש מילולי (BM25), לרוב נכון לשלב:

• חיפוש סמנטי לשאלות “איך מטפלים במקרה דומה?”
• חיפוש מילולי/מדויק לסעיפים בפוליסה, קודים, שמות טפסים, מספרי נהלים

חלוקה חכמה לקטעים (Chunking)

Chunk גדול מדי “מערבב” נושאים; קטן מדי מאבד הקשר.

• בביטוח: סעיפי פוליסה + חריגים + דוגמאות. לרוב קטעים של 300–800 טוקנים עם חפיפה.
• בבריאות: הנחיות קליניות עם כותרות ברורות; כדאי לשמר מבנה (כותרת/תת-כותרת/סעיפים).

פילטרים לפי מטא-דאטה

הפרש בין “תשובה טובה” ל”תשובה שאפשר להסתמך עליה” הוא לרוב פילטר:

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

3) הערכה (Evaluation) בלי נתוני אמת היא הצגה

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

ב‑RAG, הערכת “האם המודל נשמע טוב” לא שווה הרבה. צריך למדוד:

מדדי שליפה

• Recall@k: האם המסמך הנכון נכנס ל‑Top‑k?
• Precision@k: כמה מהמסמכים שנשלפו באמת רלוונטיים?

מדדי תשובה

• נאמנות למקור (faithfulness): האם התשובה מבוססת על המסמכים שנשלפו?
• כיסוי (coverage): האם התשובה כוללת את כל התנאים החשובים?
• מדיניות אי-ידיעה: האם המערכת יודעת להגיד “אין לי מספיק מידע”?

סט בדיקות שמייצג פרודקשן

אני מעדיף לבנות “בנק שאלות” ממקורות אמיתיים:

• תיעוד שיחות מוקד
• שאלות חוזרות של שמאים/רופאים
• תקלות עבר בתביעות/ועדות
• מקרים גבוליים (edge cases) שהפילו תהליכים

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

4) תכנון לכשל: כשהמערכת לא בטוחה—היא חייבת לעצור

התשובה הישירה: RAG אמין הוא כזה שמוגדר לו מתי לא לענות.

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

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

במקום להמר, בונים מנגנוני בטיחות:

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

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

5) MLOps ל‑RAG: ניטור, גרסאות ויכולת שחזור

התשובה הישירה: בלי MLOps, אתם לא תדעו מתי המערכת הידרדרה—ואתם גם לא תצליחו לשחזר למה.

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

מה חייב להיות מנוהל בגרסאות:

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

מה מנטרים בפרודקשן (וממש כדאי לוח בקרה):

• זמן שליפה וזמן מענה (latency)
• שיעור “לא יודע”
• שיעור תלונות/תיקונים ידניים
• Drift בסוגי השאלות (למשל עלייה בתביעות רכב בחורף הישראלי עם יותר תאונות)

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

6) אבטחה, פרטיות והרשאות: הבעיה הכי פחות סקסית והכי מסוכנת

התשובה הישירה: אם RAG לא יודע “מי שואל”, הוא ידליף מידע—במוקדם או במאוחר.

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

מה עושים:

• הרשאות בשכבת השליפה (לא רק בממשק): המסמכים שלא מותר לשלוף—לא נכנסים ל‑Top‑k.
• הפרדת אינדקסים לפי יחידות/מוצרים/תיקים רגישים.
• מסוך (redaction) לפרטים מזהים לפני שמסמכים נשלחים למודל.
• רישום פעילות (audit log): מי שאל, מה נשלף, ומה נענה.

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

שאלות נפוצות מהשטח (ואיך לענות עליהן נכון)

“האם RAG פותר הזיות של מודל שפה?”

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

“כמה מסמכים צריך במאגר כדי להתחיל?”

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

“האם זה מתאים גם למוקד שירות?”

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

מה הייתי עושה כבר החודש: תוכנית פעולה קצרה לארגון ביטוח/בריאות

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

1. מגדירים Use Case אחד מדיד: “קיצור זמן טיפול בתביעת אשפוז” או “הפחתת שאלות חוזרות לחיתום”.
2. בונים סט בדיקות של 100–300 שאלות מהמציאות, כולל מקרים גבוליים.
3. מקימים שליפה היברידית עם פילטרים לפי תוקף/מוצר/מחלקה.
4. מוסיפים מדיניות ‘לא יודע’ וספי ביטחון.
5. מנטרים שבועיים: Recall@k, שיעור תיקונים, זמן מענה, ותלונות.

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

שורה תחתונה שאפשר לקחת הלאה: ב‑RAG, פרודקשן הוא מוצר—לא דמו.

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