מה זה RAG? המדריך המלא ל-Retrieval-Augmented Generation

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

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

RAG (ראשי תיבות של Retrieval-Augmented Generation, ובעברית יצירה מבוססת אחזור) היא

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

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

מה זה RAG: ההגדרה בשפה פשוטה

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

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

קודם כול: מה זה LLM ולמה הוא לא מספיק לבד

כדי להבין את הערך של RAG צריך להבין את הכלי שהוא משדרג.

מה זה LLM

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

שלוש מגבלות שמערכת RAG פותרת

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

• הזיות – כשהמודל לא יודע, הוא עלול להמציא תשובה שנשמעת משכנעת לגמרי.

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

RAG פותר את שלושתן בבת אחת: המידע נשלף בזמן אמת, התשובה מעוגנת במקור שאפשר לבדוק, והמודל עובד על הידע של הארגון בלי שהידע הזה יוצא לאימון של מודל חיצוני.

איך זה עובד: הצינור המלא מהמסמך ועד התשובה

מערכת RAG בנויה משני תהליכים. הראשון רץ מראש (או מדי פעם) ומכין את הידע. השני רץ בכל פעם שמשתמש שואל שאלה.

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

• קליטת מסמכים (Ingestion) – איסוף קבצי PDF, Word, דפי אינטרנט, טבלאות ומערכות כמו Confluence או SharePoint, וחילוץ הטקסט הנקי מהם.

• חלוקה לקטעים (Chunking) – פירוק כל מסמך לקטעים קטנים, בדרך כלל פסקה עד עמוד, כדי שאפשר יהיה לשלוף בדיוק את החלק הרלוונטי.

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

• אחסון ב-Vector Database – הווקטורים נשמרים במסד נתונים וקטורי יחד עם הטקסט המקורי ופרטים נוספים כמו שם המסמך, תאריך והרשאות.

שלב השאלה: שליפה ויצירת תשובה

• הפיכת השאלה לווקטור – גם השאלה של המשתמש עוברת דרך אותו מודל Embeddings.

• שליפה (Retrieval) – המערכת מוצאת את הקטעים שהווקטורים שלהם הכי קרובים לשאלה, בדרך כלל 3 עד 10 קטעים.

• העשרה (Augmentation) – הקטעים שנשלפו נכנסים לפרומפט יחד עם השאלה והוראות כמו: ענה רק על סמך המקורות, וציין מאיפה לקחת.

• יצירה (Generation) – מודל השפה מנסח תשובה שמבוססת על המקורות, ולרוב מצרף הפניה למסמך שממנו נלקח המידע.

Embeddings ו-Vector Database: הלב של המערכת

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

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

• Pinecone – שירות מנוהל בענן, מהיר להקמה ומתאים למי שלא רוצה לנהל תשתית.

• Weaviate ו-Qdrant – מסדי קוד פתוח שאפשר להריץ בענן או על שרתי הארגון.

• pgvector – הרחבה ל-PostgreSQL, שמאפשרת לשמור וקטורים באותו מסד נתונים שכבר קיים בארגון.

• Chroma – פתרון קליל שמתאים במיוחד לפרוטוטייפים ולמידה.

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

Chunking: איפה רוב המערכות נופלות

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

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

• חלוקה לפי מבנה המסמך – לפי כותרות, סעיפים וטבלאות. מתאים מאוד לנהלים, חוזים ותיעוד טכני.

• חלוקה סמנטית – חותכים במקומות שבהם הנושא משתנה. מדויק יותר, ודורש יותר עיבוד.

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

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

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

• חיפוש היברידי – שילוב של חיפוש לפי מילים (כמו BM25) עם חיפוש וקטורי, כך שגם התאמה מדויקת וגם התאמה במשמעות נלקחות בחשבון.

• Reranking – מודל נוסף מדרג מחדש את 20 עד 50 התוצאות הראשונות ומעביר למודל השפה רק את הטובות ביותר.

• סינון לפי מטא-דאטה – למשל רק מסמכים מהשנה האחרונה, או רק מסמכים של מחלקה מסוימת.

• ניסוח מחדש של השאלה (Query Rewriting) – המודל משכתב שאלה קצרה או עמומה לכמה שאילתות מדויקות לפני החיפוש.

RAG מול Fine-Tuning מול Prompt Engineering

שלוש הדרכים לשפר מודל שפה נשמעות דומות, אבל הן פותרות בעיות שונות:

• Prompt Engineering – כתיבת הוראות טובות יותר. זול ומהיר, אבל לא מוסיף למודל ידע חדש.

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

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

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

דוגמאות לשימוש בארגונים

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

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

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

• פיתוח תוכנה – עוזר שמכיר את התיעוד הפנימי, ה-API ותקלות עבר של הצוות.

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

איך יודעים שהמערכת עונה נכון

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

• איכות השליפה – האם הקטע הנכון נמצא בין התוצאות הראשונות? מודדים בעזרת סט שאלות שהתשובה עליהן ידועה (Golden Set).

• איכות התשובה – האם התשובה נאמנה למקורות (Faithfulness), האם היא עונה על השאלה (Relevance), והאם היא מצטטת נכון.

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

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

אתגרים נפוצים, ובמיוחד בעברית

• מסמכים סרוקים – קבצים שהם בעצם תמונה דורשים OCR, ואיכות ה-OCR בעברית משפיעה ישירות על התוצאות.

• עברית ואנגלית באותו משפט – מונחים טכניים באנגלית בתוך טקסט עברי עלולים לשבש חלוקה וחיפוש.

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

• מידע סותר – שתי גרסאות של אותו נוהל. צריך לנהל גרסאות ולתעדף את העדכנית.

• הרשאות – עובד לא אמור לקבל תשובה שמבוססת על מסמך שאסור לו לראות. את ההרשאות בודקים כבר בשלב השליפה, לא בסוף.

השלב הבא: סוכנים שמחליטים מתי לחפש

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

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

פרויקט ראשון: 6 צעדים להקמת מערכת שעונה מתוך המסמכים שלכם

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

• בחרו שאלה עסקית אחת – למשל שאלות של עובדים על נהלי משאבי אנוש. פרויקט ממוקד מצליח הרבה יותר מניסיון לענות על הכול.

• אספו 20 עד 50 מסמכים ונקו אותם – הסירו כפילויות וגרסאות ישנות. מסמך מבולגן ייתן תשובה מבולגנת.

• כתבו סט בדיקה לפני שכותבים קוד – 30 שאלות אמיתיות, ולכל אחת המסמך שבו נמצאת התשובה.

• בנו גרסה פשוטה – חלוקה לפי מבנה המסמך, מודל Embeddings מוכן, מסד וקטורי קליל ומודל שפה דרך API.

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

• הוסיפו ציטוט מקורות והרשאות – לפני שמישהו מחוץ לצוות משתמש במערכת, ודאו שכל תשובה מפנה למקור ושכל משתמש רואה רק את מה שמותר לו.

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

איך לומדים לבנות מערכת RAG

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

בקורס AI למפתחים של נאיה קולג' (AI Engineer) לומדים בדיוק את זה, Hands-On: יסודות LLM ו-Prompt Engineering, בניית צינור RAG מלא כולל Chunking, חיפוש היברידי ו-Reranking, הערכת איכות וניטור, ובהמשך גם בניית AI Agents. מי שמגיעים מהצד העסקי והמוצרי ורוצים להוביל פרויקטים כאלה בארגון ימצאו את המקום שלהם בקורס AI לעסקים (AI Business Solution Professional), שעוסק בין היתר בבניית מאגרי ידע מבוססי RAG ובחיבור סוכנים לכלים ארגוניים.

שאלות נפוצות

מה זה RAG במילה אחת?

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

האם RAG מונע הזיות לגמרי?

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

צריך לדעת לתכנת כדי לבנות מערכת RAG?

לפרוטוטייפ פשוט יש היום כלים שלא דורשים קוד. למערכת ארגונית יציבה, עם הרשאות, מדידה וניטור, צריך ידע ב-Python ובעבודה עם API.

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

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

האם RAG מתאים למסמכים סודיים?

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

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

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

רוצים לבנות מערכות AI אמיתיות? דברו איתנו

בנאיה קולג' כבר הכשרנו יותר מ-7,520 בוגרים ועובדים עם יותר מ-100 חברות בתעשייה. הקורסים שלנו מעשיים ומחוברים לעולם האמיתי, וצוות ההשמה שלנו מלווה את הבוגרים גם בדרך לעבודה הבאה. רוצים לשמוע איזה מסלול AI מתאים לכם? השאירו פרטים באתר או התקשרו אלינו: 03-720-7846.