RAG Poisoning — תקיפת מאגר הידע של AI

מאת צוות מדיה דיל · 09.08.2026 · AI · 8 דק׳

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

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

למה חשוב להבחין בין Poisoning פנימי לחיצוני

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

איך RAG בעצם עובד, ולמה זה יוצר את הפגיעות

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

למה גם מודל "חכם" לא פותר את הבעיה

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

וקטורי תקיפה

• הזרקה דרך מקורות תוכן פתוחים לעריכה - Wiki פנים-ארגוני, מסמכי Confluence, טופסי פידבק לקוחות, או כל מקור שממנו המערכת "שואבת" מסמכים אוטומטית וללא בקרת עורך.
• Chunk-level targeting - תוקף שמבין איך המערכת מפרקת מסמכים לחלקים יכול לנסח תוכן שממוקד בדיוק כך שה-chunk הספציפי שלו יידמה סמנטית לשאילתות נפוצות ("מדיניות החזרים", "הרשאות גישה") ויישלף בעדיפות גבוהה.
• הרעלת מקורות חיצוניים שנטענים אוטומטית - מערכת RAG שמעדכנת את עצמה מדפי אינטרנט או פידים חיצוניים חשופה לכך שהמקור עצמו ישונה על ידי מי ששולט בו.
• Embedding collision - ניסוח תוכן זדוני כך שהוקטור שלו קרוב מתמטית לוקטורים של שאילתות נפוצות, גם אם התוכן הטקסטואלי לא "נראה" קשור במבט ראשון.

מה קורה בפועל אחרי שהזיהום נכנס

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

קשר לבחירת אסטרטגיית שליפה

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

איך בונים pipeline הזנה עמיד

1. בקרת גישה על מקורות ההזנה עצמם

לא כל מי שיכול לערוך מסמך בארגון צריך שהעריכה שלו תזין אוטומטית את מאגר ה-RAG. שכבת אישור (ולו קלה) בין "מסמך נערך" ל"מסמך נכנס למאגר".

2. חתימת מקור ומעקב שושלת (Provenance)

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

3. ניטור אנומליות בתוכן החדש

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

4. Reranking עם משקל אמינות

Reranking לא רק לפי רלוונטיות סמנטית, אלא גם לפי מהימנות המקור - מסמך ממקור לא מאומת מקבל משקל נמוך יותר גם אם הוא "קרוב" סמנטית לשאילתה.

5. גרסאות והיסטוריה למאגר הידע

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

{
  "chunk_id": "kb-4471-c3",
  "source_doc": "refund-policy-v12.md",
  "author": "unverified-external-submission",
  "trust_score": 0.2,
  "requires_review": true,
  "last_modified": "2026-08-07T11:02:00Z"
}

גילוי בדיעבד: מה עושים כשהזיהום כבר קרה

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

Trade-offs

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

קשר לניהול הרשאות שליפה

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

דוגמה מהשטח: מאגר ידע פנימי שמוזן מכרטיסי תמיכה

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

מקרה קרוב ומורכב יותר מופיע במערכות Multimodal RAG, שבהן המאגר כולל גם תמונות, טבלאות סרוקות או קטעי שמע שעברו תמלול. הזיהום שם יכול להיות עדין הרבה יותר - טקסט שמוסתר בתוך תמונה (למשל, כחלק ממסמך סרוק) ולא נראה במבט אנושי מהיר, אבל נקלט על ידי מנוע ה-Document Intelligence שממיר אותו לטקסט לצורך אינדוקס. כל שכבת עיבוד נוספת (OCR, תמלול, extraction) היא הזדמנות תקיפה נוספת שדורשת אותה זהירות כמו הזנת מסמך טקסטואלי רגיל.

קשר לאיכות המידע לעומת אבטחה

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

טעויות נפוצות

• להזין את המאגר אוטומטית מכל מקור זמין בלי שכבת בדיקה, כי "יותר נתונים = יותר טוב".
• להתייחס לתוכן שנשלף מה-RAG כ"עובדה מאומתת" באופן גורף, במקום להציג אותו למודל כמקור מידע שצריך לשקלל.
• לא לעקוב אחר מקור (provenance) של כל chunk - מה שהופך זיהוי וניקוי זיהום למשימה כמעט בלתי אפשרית בדיעבד.
• להתמקד רק באבטחת המודל ולהזניח את אבטחת ה-pipeline שמזין אותו.

שאלות נפוצות

איך מזהים שמאגר RAG כבר "מורעל"?

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

האם GraphRAG פחות פגיע ל-Poisoning מ-RAG רגיל?

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

האם זה קשור ל-Indirect Prompt Injection?

קשור אך שונה - Indirect Injection בדרך כלל פוגע בהרצה בודדת, בעוד RAG Poisoning משפיע על מאגר קבוע שממשיך להשפיע על שאילתות רבות עד שמנקים אותו.

מה תפקיד ה-embeddings בסיכון הזה?

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

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

תגיות: RAG Poisoning · vector database security · knowledge base security · RAG pipeline · data provenance · embeddings security

← חזרה לבלוג · צור קשר