בסיס ידע ל-RAG הוא לא "להעלות את כל הדרייב לוקטור דיטאבייס". זו שכבת הנדסה בת ארבעה חלקים: מקורות מסודרים, חיתוך נכון של המסמכים, אחזור היברידי עם דירוג מחדש, ושכבת הרשאות. לפי דיווחי ספקים מ-2026, בין 70% ל-80% מפרויקטי ה-RAG הארגוניים לא מגיעים לפרודקשן כלל, ורוב הכשלים נובעים משכבת הקליטה והאחזור, לא מהמודל. המדריך הזה מפרק את ארבע השכבות ומציע תוכנית 90 יום.
למה רוב פרויקטי ה-RAG נופלים לפני הפרודקשן
הדפוס חוזר על עצמו: צוות מרים פיילוט בשבועיים, ההדגמה מרשימה, ואז המערכת פוגשת את המציאות הארגונית ומתפרקת. מחקר של MLOps Community מ-2026 שניתח 143 פריסות RAG ארגוניות מצא ש-73% חוו לפחות כשל קריטי אחד ברבעון הראשון לפרודקשן, ו-41% מהכשלים האלה לא זוהו כלל על ידי חבילות ההערכה הסטנדרטיות.
הסיבה כמעט אף פעם אינה בחירת המודל. ההערכה הרווחת בתעשייה היא ש-80% מכשלי ה-RAG מקורם בשכבת הקליטה והחיתוך של המסמכים. במילים אחרות: אם המערכת מחזירה תשובה שגויה, ברוב המקרים המודל קיבל את הקטע הלא נכון מלכתחילה. ההבחנה הזו חשובה כי היא משנה לאן הולך התקציב: לא לשדרוג מודל, אלא להנדסת אחזור.
המסקנה התקציבית: ב-2026 RAG הוא לא בעיית מודל אלא בעיית הנדסת אחזור. שיפור של איכות החיתוך והדירוג מייצר קפיצת דיוק גדולה יותר מאשר מעבר למודל יקר יותר, ובעלות תפעולית נמוכה בהרבה. אם אתם מודדים מודל יחידה של פרויקט AI, זה ההבדל בין עלות משתנה שגדלה עם השימוש לבין השקעה חד-פעמית בתשתית.
ארבע השכבות של בסיס ידע ארגוני
| שכבה | מה היא עושה | הכשל הנפוץ |
|---|---|---|
| מקורות ומטא-דאטה | איזה מסמכים נכנסים, מי הבעלים, מתי עודכנו לאחרונה | הכנסת הכל בבת אחת, כולל גרסאות ישנות וטיוטות |
| חיתוך (Chunking) | פירוק המסמך לקטעים שהמודל יקבל כהקשר | חיתוך אחיד לכל סוגי המסמכים, שובר טבלאות וסעיפים |
| אחזור ודירוג | מציאת הקטעים הרלוונטיים והחזרת הטובים ביותר | הסתמכות על חיפוש וקטורי בלבד, בלי מילות מפתח |
| הרשאות | מוודא שמשתמש רואה רק מה שמותר לו לראות | הרשאות נבדקות בממשק ולא באחזור עצמו |
איך חותכים את המסמכים נכון
החיתוך הוא ההחלטה שמשפיעה הכי הרבה על הדיוק, והוא גם ההחלטה שהכי הרבה צוותים מקבלים בברירת מחדל. שלוש משפחות שיטות רלוונטיות ב-2026:
| שיטה | מתי מתאימה | גודל קטע מומלץ |
|---|---|---|
| חיתוך רקורסיבי בגודל קבוע | טקסט רץ, מסמכי מדיניות, תיאורי תהליך | 256-512 טוקנים לשאלות עובדתיות |
| חיתוך סמנטי | מסמכים טכניים, מפרטים, תיעוד מוצר | 512-1024 טוקנים למשימות ניתוח |
| חיתוך מאוחר (Late Chunking) | מסמכים ארוכים שההקשר בהם חוצה סעיפים | המסמך כולו נטמע תחילה, ואז מפוצל |
כלל אצבע מעשי: קטע צריך להכיל תשובה שלמה לשאלה אחת. אם עובד היה מדפיס את הקטע ומקבל אותו על השולחן, האם הוא יכול לענות ממנו בלי לחפש עוד? אם לא, הקטע קצר מדי. אם הקטע מכיל שלושה נושאים שונים, הוא ארוך מדי והחיפוש הווקטורי יתקשה למקד אותו.
שתי טעויות שחוזרות: שבירת טבלאות באמצע, מה שהופך נתונים מספריים לרעש, ואיבוד הכותרת ההיררכית. הפתרון לשנייה זול: מוסיפים לכל קטע שורת הקשר עם שם המסמך, הפרק והתאריך.
אחזור היברידי ודירוג מחדש
חיפוש וקטורי לבדו מפספס בדיוק את מה שארגונים שואלים עליו: מספרי קטלוג, שמות לקוחות, קודי תקלה, סעיפי חוזה. אלה מחרוזות מדויקות שהטמעה סמנטית "מטשטשת". לכן אחזור היברידי, שמשלב הטמעות צפופות עם התאמת מילות מפתח בסגנון BM25, ממשיך להכות חיפוש וקטורי בלבד כמעט בכל סוגי המסמכים הארגוניים.
המבנה שהפך לנקודת פתיחה מקובלת: מאחזרים 20 מועמדים, מדרגים אותם מחדש עם מודל reranker, ומעבירים למודל את חמשת הטובים. הדירוג מחדש הוא השלב שהכי משתלם ביחס למאמץ, כי הוא מתקן טעויות אחזור בלי לגעת בשכבת החיתוך.
הרשאות: השכבה שכולם דוחים לסוף
זו הנקודה שבה פיילוטים מתים. בפיילוט כולם רואים הכל, ואז מגיע הרגע שבו צריך שנציג תמיכה לא יראה מסמכי שכר. אם ההרשאות נאכפות רק בממשק, האחזור עדיין קורא את המסמך והמודל עדיין עלול לצטט ממנו. האכיפה חייבת לקרות בשלב האחזור, כפילטר על המטא-דאטה, לפני שהקטעים בכלל מגיעים למודל.
מעשית: כל קטע נושא את מזהי הקבוצות שמורשות לראותו, והשאילתה מסננת לפיהם. זה גם מה שהופך את המערכת לניתנת לביקורת, כי אפשר להראות בדיוק אילו מסמכים נכנסו לכל תשובה.
איך מודדים שהמערכת עובדת
כ-70% מהצוותים שמריצים RAG בפרודקשן אין להם מדידה שיטתית של איכות האחזור. זו הסיבה שכשלים לא מזוהים. מסגרת המדידה המקובלת היא "משולש ה-RAG", שלושה צירים שאפשר להריץ אוטומטית על סט שאלות קבוע:
| ציר | השאלה שהוא בודק | מה עושים כשהוא נמוך |
|---|---|---|
| רלוונטיות הקשר | האם האחזור מצא את המסמכים הנכונים? | מתקנים חיתוך, מוסיפים אחזור היברידי |
| ביסוס (Groundedness) | האם התשובה נשענת באמת על המסמכים שהוחזרו? | מהדקים את הפרומפט, מחייבים ציטוט מקור |
| רלוונטיות התשובה | האם התשובה עונה על מה שנשאל? | מפרקים שאלות מרובות שלבים |
נקודת תורפה ידועה: 71% ממערכות ה-RAG בפרודקשן נכשלות בשאלות מרובות שלבים, כאלה שדורשות לחבר מידע משני מסמכים שונים. אם השימוש המרכזי שלכם הוא כזה, בנו את סט הבדיקה סביבו מההתחלה ולא סביב שאלות עובדתיות פשוטות שתמיד עוברות.
מה שמפריד צוותים שמשגרים: סט הערכה מתועד, ממוספר בגרסאות ורץ אוטומטית בכל לילה. בלעדיו כל שינוי בחיתוך או בפרומפט הוא הימור, ואי אפשר לדעת אם שיפרתם או שברתם.
תוכנית 90 יום
ימים 1-30: בוחרים תרחיש שימוש אחד עם קהל מוגדר. ממפים 50-200 מסמכים רלוונטיים בלבד, מנקים גרסאות ישנות, ומגדירים לכל מסמך בעלים ותאריך עדכון. במקביל כותבים 40 שאלות אמת שהצוות באמת שואל, עם תשובות מאושרות. זה סט ההערכה.
ימים 31-60: בונים את הצינור: חיתוך, הטמעה, אחזור היברידי, דירוג מחדש, פילטר הרשאות. מריצים את סט ההערכה ומתעדים ציון בסיס בשלושת הצירים. משפרים חיתוך ודירוג עד שרלוונטיות ההקשר מתייצבת.
ימים 61-90: פותחים לקבוצת פיילוט אמיתית, מוסיפים לוג של כל שאלה עם הקטעים שהוחזרו, ומוסיפים כפתור משוב. השאלות שנכשלות הופכות לתוספות לסט ההערכה. רק אחרי שהמדדים יציבים שבועיים ברציפות מרחיבים למקורות נוספים.
אם אתם בונים את זה בפעם הראשונה, כדאי לקרוא גם איך מודדים נראות במנועי תשובות AI, כי אותה משמעת מדידה חלה גם על הצד החיצוני. וכשמגיעים לשלב ההטמעה הארגונית, שירות הטמעת הבינה המלאכותית שלנו מתחיל בדיוק מהמיפוי הזה.
שאלות נפוצות
כמה מסמכים צריך כדי להתחיל RAG ארגוני?
הרבה פחות ממה שנדמה. תרחיש שימוש אחד מכוסה היטב על ידי 50 עד 200 מסמכים נקיים ומעודכנים. הכנסת עשרות אלפי מסמכים בהתחלה מורידה את הדיוק, כי גרסאות ישנות וטיוטות מתחרות על אותו מקום באחזור.
מה גודל הקטע (chunk) המומלץ?
בין 256 ל-512 טוקנים לשאלות עובדתיות, ובין 512 ל-1024 טוקנים למשימות ניתוח. הכלל המעשי: קטע צריך להכיל תשובה שלמה לשאלה אחת, בלי לשבור טבלאות ובלי לאבד את כותרת הפרק.
למה חיפוש וקטורי לבדו לא מספיק?
כי הוא מטשטש מחרוזות מדויקות כמו מספרי קטלוג, קודי תקלה ושמות לקוחות. אחזור היברידי, שמשלב הטמעות עם התאמת מילות מפתח בסגנון BM25, נותן תוצאות טובות יותר כמעט בכל סוגי המסמכים הארגוניים.
איך מוודאים שמשתמש לא רואה מסמך שאסור לו?
אוכפים את ההרשאות בשלב האחזור ולא בממשק. כל קטע נושא את מזהי הקבוצות שמורשות לראותו, והשאילתה מסננת לפיהם לפני שהקטעים מגיעים למודל.
כמה זמן לוקח להגיע לפרודקשן?
תרחיש שימוש ממוקד אחד ניתן להביא לפיילוט אמיתי בכ-90 יום: חודש למיפוי מקורות ובניית סט הערכה, חודש לבניית הצינור ושיפורו, וחודש לפיילוט עם משוב אמיתי.
