RAG בפועל: המידע שלכם לא "מאמן" את המודל, ולמה זו דווקא בשורה טובה

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

מה זה בכלל "אימון" (Training)

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

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

מה RAG עושה באמת

RAG הם ראשי תיבות של Retrieval-Augmented Generation, ומילת המפתח היא Retrieval, כלומר שליפה. המסמכים שלכם מחולקים לקטעים, כל קטע הופך ל-Embedding (טביעת אצבע מספרית של המשמעות שלו), והטביעות נשמרות במסד נתונים וקטורי כמו Qdrant. המודל עצמו לא נגעו בו.

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

למה זו בשורה טובה לעסק שלכם

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

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

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

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

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

אז מתי Fine-Tuning כן הכלי הנכון?

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

מה חשוב בדרך לפרודקשן

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

הסטאק שאני באמת משתמש בו בפרודקשן

סטאק ברירת המחדל שלי למערכות RAG עסקיות: Qdrant כמסד נתונים וקטורי (מהיר, מנוהל או בהתקנה עצמית, עם סינון מטא-דאטה נוח), Embeddings של OpenAI או Cohere לפי תמהיל השפות, LangChain או LangGraph לאורקסטרציה כשהזרימות נהיות מותנות, ו-LangSmith או מדדים מלוגים למדידת איכות השליפה. אחסון בדרך כלל על AWS: Lambda או ECS לתהליך, S3 למסמכי מקור, ומסד וקטורי צמוד לעומס.

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

דוגמה עובדת: עוזר התמיכה

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

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

הטעויות שמטביעות פרויקטי RAG

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

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

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

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

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

RAG על המערכות שכבר יש לכם

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

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