RAG מתקדם: המדריך הטכני לשליפה מבוססת הקשר במערכות AI

מאת צוות מדיה דיל · 29.08.2026 · AI · 7 דק׳ קריאה

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

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

Chunking: איך מפרקים מסמכים נכון

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

Embeddings ומאגרי וקטורים

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

Hybrid Search: וקטורי וגם מבוסס מילות מפתח

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

Re-ranking: סינון שני לפני שהמידע מגיע למודל

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

RAG בפרודקשן: מה שקל לפספס

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

מדידת איכות שליפה לאורך זמן

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

עדכון המאגר בזמן אמת

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

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

בחירת גודל Chunk: הפשרה בין דיוק להקשר

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

טיפול בטבלאות, תמונות ומסמכים לא טקסטואליים

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

הרשאות וסינון ברמת מסמך בזמן שליפה, לא רק בזמן תצוגה

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

עדכון הדרגתי (incremental) מול בנייה מחדש של כל האינדקס

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

מדדים כמותיים להערכת איכות שליפה

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

בדיקת עומס למערכת RAG לפני עלייה לפרודקשן

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

שילוב RAG עם קריאה לכלים (function calling) בסוכן AI

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

בחירת מודל Embeddings: גודל הווקטור משפיע גם על עלות וגם על דיוק

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

התמודדות עם שאלות מחוץ לתחום הידע של המאגר

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

שאלות נפוצות

מה ההבדל בין RAG לבין פשוט להגדיל את חלון ההקשר של המודל ולהכניס הכול?

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

כמה מסמכים צריך במאגר כדי ש-RAG יהיה שימושי?

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

איך בוחרים בין מאגר וקטורים מנוהל בענן לבין אירוח עצמי?

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

מה עושים כשהמודל ממציא מידע (הזיה) למרות שקיבל הקשר נכון?

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

האם RAG עובד עם מסמכים בעברית באותה איכות כמו באנגלית?

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

תגיות: RAG · Retrieval Augmented Generation · Vector Search · Embeddings · Chunking · Re-ranking

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