RAG 2.0 — הדור הבא של Retrieval-Augmented Generation

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

Retrieval פשוט של 'שלוף 5 קטעים דומים והזרק לפרומפט' לא שורד בפרודקשן. מדריך לארכיטקטורת RAG בשלה: Hybrid Search, Reranking, Query rewriting ואבחון כשלים.

הגרסה הראשונה של כמעט כל מערכת RAG נראית זהה: לוקחים מסמכים, מחלקים לקטעים (Chunks), הופכים כל קטע ל-Embedding, שומרים ב-Vector Database, ובזמן שאילתה שולפים את 5 הקטעים הכי "דומים" ומזריקים אותם לפרומפט. זה עובד יפה בדמו. בפרודקשן, אחרי כמה שבועות, מתחילות להצטבר תלונות: "המערכת ענתה לא נכון על שאלה שהתשובה לה בטח נמצאת במסמכים", "התשובה חלקית", "המערכת התעלמה ממידע עדכני יותר". הבעיה כמעט תמיד לא במודל השפה עצמו, אלא בשכבת ה-Retrieval שמזינה אותו. RAG 2.0 הוא השם שניתן לאוסף השיפורים הארכיטקטוניים שהופכים Retrieval נאיבי למערכת שבאמת מוצאת את המידע הנכון - לא רק "משהו שדומה סטטיסטית".

אבחון כשל: מהיכן להתחיל כשתשובה יוצאת שגויה

כשמערכת RAG בפרודקשן מחזירה תשובה שגויה, הצעד הראשון הוא לא "לשפר את הפרומפט" אלא לבודד באיזה שלב בדיוק הצינור נכשל - הכשל יכול להיות בכל אחד מכמה מקומות, וכל אחד דורש תיקון שונה לגמרי. אם הקטע הנכון בכלל לא נמצא בין המועמדים שנשלפו, הבעיה בשלב ה-Retrieval (שכתוב שאילתה, חיפוש, או Chunking גרוע שקטע את המידע). אם הקטע הנכון נמצא בין המועמדים אבל לא הגיע לפרומפט הסופי, הבעיה בשלב הדירוג (Reranking או Top-K). ואם הקטע הנכון כן הגיע לפרומפט אבל המודל בכל זאת ענה לא נכון, הבעיה בשלב היצירה עצמה - אולי המודל התעלם מהמידע, או שהקטעים הסותרים בפרומפט בלבלו אותו. אבחון מדויק כזה, שדורש לוג מפורט של כל שלב בצינור בנפרד, הוא בדיוק מה שהופך תיקון RAG מניחוש חוזר ונשנה לתהליך הנדסי שיטתי - נקודה שמתקשרת ישירות לחשיבות של Observability ברמת כל שלב, לא רק ברמת התשובה הסופית.

למה RAG נאיבי נכשל

Retrieval מבוסס Vector Search בלבד סובל מכמה מגבלות מובנות. ראשית, דמיון וקטורי (Cosine similarity) לוכד קִרבה סמנטית כללית, אבל לא בהכרח את מה שרלוונטי לשאלה הספציפית - שאלה עם מספר מוצר מדויק או מונח טכני נדיר עלולה "להפסיד" לקטעים שדומים ברוח הכללית אבל לא מכילים את המילה המדויקת. שנית, חלוקה גסה למסמכים (Chunking) בלי מחשבה יוצרת קטעים שקוטעים משפטים או מנתקים הקשר חיוני. שלישית, שליפת "Top-K" קבוע (למשל תמיד 5 קטעים) לא מתאימה לכל שאלה - שאלה מורכבת עשויה לדרוש הקשר רחב יותר, שאלה ממוקדת עשויה להיפגע מ"רעש" של קטעים לא רלוונטיים שמוזרקים סתם כי הם היו במקום החמישי.

ציטוט מקורות - לא רק תכונת UI

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

שכבת ה-Retrieval הבשלה: מה משתנה

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

• Query rewriting / expansion - לפני החיפוש עצמו, שאלת המשתמש הגולמית (שלעיתים קצרה, עמומה, או תלוית הקשר שיחה) עוברת שכתוב או הרחבה - ראו Query Expansion - כדי להפוך אותה לשאילתת חיפוש טובה יותר.
• Hybrid Search - שילוב בין חיפוש וקטורי (סמנטי) לבין חיפוש מילות מפתח קלאסי (כמו BM25), כדי לתפוס גם דמיון סמנטי וגם התאמות מדויקות של מונחים, מספרים ושמות - ראו Hybrid Search.
• Reranking - שליפה ראשונית רחבה (למשל 30-50 מועמדים), ואז מודל ייעודי שמדרג אותם מחדש לפי רלוונטיות אמיתית לשאלה, ורק אז בוחרים את הכמות הסופית להזרקה - ראו Reranking.
• Chunking חכם - חלוקת מסמכים לפי גבולות סמנטיים טבעיים (סעיפים, נושאים) ולא לפי מספר תווים קבוע - ראו Semantic Chunking.
• Top-K דינמי - כמות הקטעים שמוזרקים לפרומפט משתנה לפי מורכבות השאלה ולפי ציוני הרלוונטיות בפועל, לא קבועה מראש.

מקרה קצה קריטי: כשהתשובה לא נמצאת במאגר בכלל

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

Query Rewriting - הצעד הראשון שמשנה הכל

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

ארכיטקטורת צינור טיפוסית

1. שאלת משתמש  -->  Query Rewriter (LLM קטן)
2. שאילתה משוכתבת  -->  Hybrid Search (Vector + BM25)
                          |
                          v
3. 30-50 מועמדים  -->  Reranker Model
                          |
                          v
4. Top-N סופי (משתנה)  -->  הזרקה לפרומפט + מקורות
5. תשובה + ציטוט מקורות  -->  משתמש

ניהול חלון ההקשר: כמות לא שווה איכות

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

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

מעבר לטקסט פשוט: כשהמידע לא שטוח

RAG נאיבי מניח שכל הידע יושב בקטעי טקסט בלתי-קשורים. במציאות, הרבה ידע ארגוני הוא קשרי במהותו - מוצר שייך לקטגוריה, קטגוריה כפופה למדיניות, מדיניות תלויה בתאריך. עבור סוגי מידע כאלה, Vector Search לבדו מפספס קשרים חשובים בין ישויות, וזה בדיוק המקום שבו נכנס GraphRAG - שילוב של גרף ידע מבני עם Retrieval סמנטי. במקביל, כשהמקורות הם מסמכים עם תמונות, טבלאות או PDF סרוקים, נדרשת גישת RAG מולטימודלי ייעודית.

עדכניות ואינדוקס מתמשך

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

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

מדידה - איך יודעים שהשיפור אמיתי

שיפור בארכיטקטורת Retrieval בלי מדידה הוא ניחוש. מערכת RAG בשלה נמדדת בשני צירים: Retrieval quality - האם הקטעים הנכונים באמת נשלפים (נמדד עם Precision/Recall מול סט שאלות ותשובות ידוע), ו-Generation quality - האם התשובה הסופית נכונה ומבוססת על המקורות שנשלפו (Faithfulness/Groundedness). שני הצירים האלה הם בדיוק מה ש-Evals ייעודיים ל-RAG בודקים, ובלי מדד קבוע קשה להבחין אם שינוי בצינור באמת שיפר משהו או רק "הרגיש" יותר טוב על כמה דוגמאות ידניות.

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

• הזרקת יותר מדי הקשר "ליתר ביטחון" - קטעים לא רלוונטיים בפרומפט לא רק מבזבזים טוקנים, הם גם מבלבלים את המודל ומורידים דיוק (תופעה מתועדת של "lost in the middle").
• התעלמות מעדכניות - מערכת RAG בלי מנגנון re-indexing שוטף ממשיכה לענות לפי מידע ישן גם אחרי שהמקור עודכן.
• אין ציטוט מקורות - בלי להחזיר למשתמש (או למערכת) אילו מסמכים בדיוק שימשו לתשובה, אי אפשר לאמת נכונות ואי אפשר לתקן כשל בקלות.
• מדידה על שאלות קלות בלבד - סט בדיקה שמכיל רק שאלות "קלות" יוצר תחושת ביטחון שגויה; חובה לכלול שאלות עמומות, רב-חלקיות, ושאלות שהתשובה להן לא נמצאת במאגר בכלל (כדי לבדוק שהמערכת יודעת "להגיד לא יודע").

שאלות נפוצות

האם RAG 2.0 זה מוצר או ארכיטקטורה?

זו ארכיטקטורה - אוסף עקרונות ורכיבים (Hybrid Search, Reranking, Query rewriting) שיחד יוצרים צינור Retrieval אמין. אין "מוצר אחד" שמיישם את כולם אוטומטית.

האם צריך את כל הרכיבים כדי שRAG יעבוד טוב?

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

מה ההבדל בין RAG לבין Fine-tuning?

RAG מספק למודל מידע עדכני בזמן השאילתה בלי לשנות את המודל עצמו; Fine-tuning משנה את המשקלים של המודל. הם פותרים בעיות שונות ולעיתים משלימים זה את זה.

איך מטפלים במקרה שהמידע לא נמצא במאגר בכלל?

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

כמה זמן לוקח לבנות מערכת RAG 2.0 מלאה?

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

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

תגיות: RAG · Retrieval-Augmented Generation · Hybrid Search · Reranking · Vector Search · Embeddings

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