בואו נטוס גבוה. אני רוצה לפתור לכם בעיה אחת מעצבנת: אתם שואלים את ה-AI שאלה על המסמך הפרטי שלכם — חוזה, מדריך פנימי של החברה, PDF של 80 עמודים — והוא פשוט ממציא תשובה. בטון בטוח. עם פרטים שנשמעים אמיתיים לגמרי. ופשוט שגויים. התופעה הזו נקראת hallucination (הזיה) — מצב שבו מודל שפה מייצר טקסט שנשמע משכנע אבל אין לו שום בסיס במציאות. הפתרון לזה נקרא RAG, וזו אחת הטכניקות הכי שימושיות שתלמדו השנה. בואו נבין אותה מאפס.
הדרכות
RAG בעברית פשוטה: איך לתת ל-AI לקרוא את המסמכים שלכם
למה לרוב אסור לאמן את המודל על המסמכים שלכם — ואיך חיפוש לפי משמעות נותן ל-AI לקרוא בדיוק את הדף הנכון בדיוק לפני שהוא עונה.
מאת Yuval Avidaniקריאה בת 4 דק׳
RAG זה ראשי תיבות של Retrieval-Augmented Generation — "יצירה מועשרת באחזור". בעברית פשוטה: במקום לתת ל-AI לענות מהזיכרון, אתם נותנים לו לקרוא את הקטעים הרלוונטיים מהמסמכים שלכם רגע לפני שהוא עונה.
למה בכלל צריך את זה? מה נשבר בלי RAG? מודל שפה כמו זה שמריץ צ'אטבוט אומן על כמות עצומה של טקסט מהאינטרנט, אבל הוא נעצר בנקודת זמן מסוימת — וזה נקרא knowledge cutoff (תאריך ניתוק הידע). הוא לא ראה את החוזה שחתמתם עליו אתמול, את הוויקי הפנימי של החברה, את ה-PDF שהורדתם הבוקר. אז כששואלים אותו "מה מדיניות ההחזרים שלנו?", הוא לא יודע — אבל במקום להגיד "אין לי מושג", הוא ינחש על סמך מדיניות החזרים כללית שראה אי-פעם. זה ה-hallucination. RAG פותר את זה בצורה אלגנטית: לא מאמנים מחדש את המודל (יקר, איטי, מסובך) — פשוט מצרפים את המידע הנכון לשאלה לפני שהמודל עונה.
האינטואיציה לפני כל פורמליזם. דמיינו סטודנט מבריק במבחן. הוא חכם נורא, אבל הוא לא יודע את החומר הספציפי של הקורס שלכם. עכשיו דמיינו שזה מבחן "עם חומר פתוח" — לפני כל שאלה, עוזר ההוראה שולף עבורו בדיוק את שני העמודים הרלוונטיים מהספר ומניח אותם מולו. עכשיו הסטודנט עונה מצוין, כי הוא קורא את התשובה מהמקור במקום לנחש מהזיכרון. המודל הוא הסטודנט המבריק; מנגנון ה-Retrieval הוא עוזר ההוראה ששולף את העמודים הנכונים; המסמכים שלכם הם הספר. זהו. כל השאר זה רק טכניקה של איך שולפים את העמודים הנכונים.
עכשיו בואו נפרק את הצינור (pipeline) לשלבים — כל שלב ולמה הוא קיים.
הבעיה הראשונה: מסמך של 80 עמודים גדול מדי בשביל לדחוף אותו שלם לכל שאלה. אז קודם מחתכים אותו לקטעים קטנים — תהליך שנקרא chunking (חיתוך לנתחים). נתח טיפוסי הוא פסקה או שתיים, נניח 300–500 מילים. למה לחתוך ולא לזרוק את הכל פנימה? כי שליחת טקסט למודל עולה כסף וזמן (כל מילה נספרת כ-token, יחידת טקסט שהמודל מודד בה), וגם כי כשנותנים למודל יותר מדי טקסט לא-רלוונטי הוא מתבלבל. רוצים לתת לו רק את הנתחים שבאמת קשורים לשאלה.
הבעיה השנייה: איך המחשב יודע אילו נתחים קשורים לשאלה? חיפוש מילים מדויקות לא מספיק — אם שאלתם "כמה ימים יש להחזיר מוצר?" והמסמך כתוב "מדיניות ההחזרות: 14 יום", אין אף מילה משותפת מלבד "מוצר". פה נכנס הרעיון הכי חשוב: embedding (הטמעה). embedding הוא תרגום של קטע טקסט לרשימת מספרים שמייצגת את המשמעות שלו, כך שטקסטים בעלי משמעות דומה מקבלים רשימות מספרים קרובות זו לזו. חשבו על מפה: שני בתי-קפה קרובים בעיר יקבלו קואורדינטות דומות. אותו דבר כאן — "החזרת מוצר" ו"מדיניות החזרות" יקבלו "קואורדינטות משמעות" קרובות, גם בלי מילים משותפות. מודל מיוחד שנקרא embedding model עושה את התרגום הזה.
הבעיה השלישית: איפה שומרים את כל רשימות-המספרים האלה ואיך מחפשים בהן מהר? בשביל זה יש vector database (מסד נתונים וקטורי) — מאגר שבנוי במיוחד למצוא במהירות את הרשומות שהמספרים שלהן הכי קרובים למספרים של השאלה. הקרבה הזו נקראת לרוב cosine similarity (דמיון קוסינוס) — מדד שאומר כמה שני וקטורי-משמעות מצביעים לאותו כיוון; ככל שהזווית ביניהם קטנה, המשמעות דומה יותר. כשמשתמש שואל שאלה, מטמיעים גם אותה לאותם מספרים, ושולפים את ה-3–5 נתחים הכי קרובים. השלב הזה נקרא retrieval (אחזור) — ה-R של RAG.
השלב האחרון: לוקחים את הנתחים ששלפנו ומדביקים אותם לתוך ה-prompt (פרומפט — הטקסט המלא שאתם שולחים למודל כשאלה, כולל ההוראות וההקשר), יחד עם השאלה המקורית, ושולחים למודל בהוראה ברורה — "ענה רק על סמך הקטעים הבאים". זה ה-augmented generation — היצירה המועשרת. המודל קורא מהמקור ועונה, בדיוק כמו הסטודנט במבחן הפתוח.
דוגמה קונקרטית שאפשר לדמיין בראש. יש לכם מדריך עובדים. נתח אחד אומר: "ימי חופשה נצברים בקצב 1.5 ימים לחודש". משתמש שואל: "כמה חופשה אני צובר בשנה?". המערכת מטמיעה את השאלה, מוצאת שהנתח על הצבירה הוא הכי קרוב במשמעות, שולפת אותו, ומרכיבה פרומפט שאומר למודל: "בהינתן הקטע: 'ימי חופשה נצברים בקצב 1.5 ימים לחודש' — כמה ימי חופשה נצברים בשנה?". המודל עכשיו לא צריך לנחש — הוא קורא 1.5, מכפיל ב-12, ועונה 18 יום. עם citation (ציטוט מקור) שמצביע על המשפט המדויק. זה ההבדל בין תשובה אמינה לבין ניחוש.
הסוד הגדול: RAG לא הופך את המודל לחכם יותר — הוא הופך אותו לממוקד יותר. הוא לא נותן ידע חדש למוח, הוא נותן את הדף הנכון בזמן הנכון.
מתי זה הכלי הנכון ומתי לא? אם השאלה היא על ידע פרטי, מתעדכן, או ספציפי-מדי-לאינטרנט — RAG מנצח. אם אתם רוצים לשנות את הסגנון או ההתנהגות של המודל (שיכתוב תמיד בטון מסוים, שיֵדע לבצע משימה חדשה לגמרי) — RAG לא יעזור, שם צריך fine-tuning (כיוונון עדין, אימון נוסף של המודל). בלבול בין השניים הוא הטעות הכי נפוצה של מתחילים.
עכשיו אתם מבינים את כל הצינור: chunking חותך, embedding נותן משמעות, vector database מאחסן ומחפש, retrieval שולף את הרלוונטי, ו-generation עונה מהמקור. כל אחד מהשלבים פותר בעיה אחת ברורה. תתחילו עם 10 מסמכים, embedding model אחד, ומסד וקטורי קטן — ותראו את ה-AI מפסיק לשקר ומתחיל לצטט. בואו נטוס.
אמ;לק
5 הדברים שצריך לדעת
במקום לשנות את המודל, נותנים לו לקרוא את הקטע הרלוונטי בדיוק לפני שהוא עונה.
רוצים טון או פורמט קבוע — fine-tuning; רוצים עובדות עדכניות ומדויקות — RAG.
השאלה והמסמכים הופכים לווקטורים, והמערכת שולפת את הקטעים הקרובים ביותר במשמעות.
המודל עונה רק על סמך הקטעים שנשלפו, ואפשר להציג למשתמש מאיזה מסמך הגיעה התשובה.
RAG טוב רק כמו הקטעים שהוא שולף — רוב העבודה היא בחיתוך, ניקוי ודיוק החיפוש, לא בבחירת המודל.
פניות תקשורת
לראיונות, שיתופי פעולה והרצאות — נשמח לדבר.
