מה זה RAG? הסבר פשוט + כמה משרות פתוחות בישראל

RAG, ראשי תיבות של Retrieval Augmented Generation, הוא שיטה שבה לפני שמודל שפה עונה, המערכת מאתרת מסמכים רלוונטיים ממאגר ומצרפת אותם לשאלה. כך התשובה נשענת על מידע ארגוני אמיתי ולא על מה שהמודל "זוכר". בלוח HiTakeJob פתוחות כרגע 8 משרות שמזכירות LangChain, 8 שמזכירות Elasticsearch ו-365 שמזכירות Python.

איזו בעיה זה פותר

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

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

איך זה עובד - שלב אחר שלב

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

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

מה זה אמבדינג וחיפוש וקטורי?

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

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

מה משתבש במערכות RAG

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

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

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

שתי רמות נמדדות בנפרד, וזו טעות נפוצה לערבב ביניהן:

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

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

איך מחלקים מסמכים לקטעים

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

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

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

מתי RAG הוא הפתרון הנכון - ומתי לא

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

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

מה צריך לדעת כדי לבנות מערכת כזו

תחום	מה נדרש	משרות פעילות
תכנות	Python לצינור האחזור והשילוב	315
חיפוש	מנוע חיפוש או מסד עם חיפוש וקטורי	Elasticsearch 8
מסגרות עבודה	LangChain או שווה ערך	8
הנדסת נתונים	צינור לעדכון המאגר	33
תשתית	פריסה, קאשינג, ניטור עלות	Kubernetes 110

אפשר לראות משרות רלוונטיות במשרות Python ובמשרות Elasticsearch.

שאלות נפוצות

RAG עדיף על כוונון עדין?

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

איך מתמודדים עם עברית ב-RAG?

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

כמה מסמכים צריך כדי שזה ישתלם?

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

מה עושים כשהמערכת עונה תשובה שגויה?

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

כמה קטעים כדאי להעביר למודל בכל שאלה?

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

האם RAG מבטל לגמרי המצאות?

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