תחשבו על עובד חדש ומבריק שמעולם לא פתח את התיקיות של העסק. הוא יכול לענות על כל שאלה כללית, אבל על ׳מה תנאי הביטול שלנו׳ הוא ינחש. RAG הוא הרגע שבו מישהו פותח לו את התיקייה הנכונה ומצביע על העמוד.
← לכל המדריכיםRAG
RAG בעברית פשוטה: איך מודל עונה מתוך המסמכים שלכם
מודל שפה לא מכיר את המסמכים של העסק שלכם. RAG הוא הדרך להביא לו את הקטע הנכון בדיוק ברגע שהוא צריך אותו.
המדריך הזה מבוסס על התיעוד של Anthropic, OpenAI ו-Google בנושא הטמעות, אחזור וציטוטים, ועל מערכות כאלה שבניתי ותיקנתי לעסקים. הוא מיועד לבעל עסק ששמע ׳צ׳אט עם המסמכים׳ ורוצה להבין מה בדיוק קונים, למי שכבר משתמש בכלי כזה ומקבל תשובות לא מדויקות, ולמי שבונה את זה בעצמו ורוצה לדעת איפה זה נשבר.
להתחיל לקרוא ↓01 · הבעיהלמי שרק מתחיל למי שכבר משתמש לטכניים מקור רשמי: Google Cloud, What is Retrieval-Augmented Generation ↗
המודל לא קרא את המסמכים שלכם
מודל שפה יודע מה שהיה בנתוני האימון שלו, ושום דבר מעבר לזה. מחירון, נוהל, חוזה, התשובות שאתם נותנים ללקוחות כל יום: כל זה לא נמצא אצלו. כששואלים אותו על זה, הוא משלים מהדמיון, ובביטחון מלא.
Google מנסחים את זה בעמוד ההסבר שלהם על RAG: מודלים מוגבלים למה שאומנו עליו, ולכן התשובות יוצאות לא מעודכנות ולפעמים לא נכונות. הפתרון הוא להביא למודל את המידע ברגע השאלה, במקום לקוות שהוא זוכר.
הדרך הפשוטה היא להדביק את המסמך בשיחה. זה עובד מצוין עד שיש יותר מדי מסמכים, או שהם משתנים כל שבוע. הדרך השנייה היא RAG, ומשם מגיעים רוב הכלים שמוכרים לכם ׳צ׳אט עם המסמכים׳.
כשמדביקים מסמך לשיחה, המודל רואה אותו רק באותה שיחה. כלי RAG שומר את המסמכים בצד, ובכל שאלה שולף מהם את החלקים שנראים רלוונטיים ומצרף אותם לפרומפט מאחורי הקלעים. אתם רואים רק את התשובה.
RAG לא משנה את המודל. המשקולות נשארות כמו שהן, ומה שמשתנה הוא ההקשר: לפני כל קריאה ל-API מריצים חיפוש על מאגר מסמכים, ומכניסים את התוצאות להודעת המשתמש או ל-system prompt. כל מה שידוע על חלון ההקשר ועל כתיבת פרומפטים תקף גם כאן.
02 · הרעיון
מה RAG עושה בפועל
RAG הם ראשי תיבות של Retrieval-Augmented Generation: יצירה שנעזרת באחזור. בכל שאלה המערכת קודם מחפשת במסמכים שלכם, בוחרת כמה קטעים שמתאימים לשאלה, ורק אז מבקשת מהמודל לענות מתוכם. המודל עונה על סמך מה שהובא לו, ומצביע על המקור.
שאלה←חיפוש במסמכים←קטעים רלוונטיים←פרומפט←תשובה עם מקור
ההבדל בין זה לבין חיפוש רגיל הוא בשלב האחרון. חיפוש מחזיר לכם עשרה מסמכים ואתם קוראים. RAG מחזיר למודל את הקטעים, והמודל מנסח מהם תשובה אחת. ההבדל בין זה לבין שיחה רגילה עם מודל הוא בשלב הראשון: המודל מפסיק לנחש, כי המידע הוצמד לשאלה.
שני החלקים תלויים זה בזה. אם החיפוש הביא קטע לא נכון, המודל ינסח בביטחון תשובה לא נכונה. אם הביא את הנכון והמודל התעלם ממנו, אותו דבר. רוב הכשלים יושבים באחד משני המקומות האלה.
מקור רשמי: Anthropic, Contextual Retrieval (a primer on RAG) ↗03 · הצינורלמי שרק מתחיל למי שכבר משתמש לטכניים מקור רשמי: OpenAI, Retrieval: vector stores and chunking ↗
חמישה שלבים: חיתוך, הטמעה, אחסון, אחזור, תשובה
מסמך נחתך לקטעים. כל קטע מתורגם לרשימת מספרים שמייצגת את המשמעות שלו, ונשמר במאגר. כששאלה מגיעה, גם היא מתורגמת למספרים, והמערכת מחפשת את הקטעים הקרובים ביותר אליה. אותם קטעים נכנסים לפרומפט, והמודל עונה.
- חיתוך: כל מסמך מפורק לקטעים. ב-OpenAI ברירת המחדל היא קטעים של 800 טוקנים עם חפיפה של 400 בין קטע לקטע, כדי שמשפט שנחתך באמצע יופיע בשלמותו לפחות באחד מהם
- הטמעה: כל קטע עובר במודל הטמעה שמחזיר וקטור, רשימה ארוכה של מספרים. OpenAI מגדירים את זה כך: המרחק בין שני וקטורים מודד עד כמה הטקסטים קרובים במשמעות
- אחסון: הווקטורים נשמרים במאגר וקטורי, יחד עם הטקסט המקורי ופרטים כמו שם הקובץ והתאריך
- אחזור: השאלה עוברת באותו מודל הטמעה, והמערכת מחזירה את הקטעים שהווקטור שלהם הכי קרוב לשאלה. בדרך כלל בין חמישה לעשרים
- תשובה: הקטעים נכנסים לפרומפט עם הנחיה לענות רק מתוכם, ולציין מאיזה קטע כל טענה הגיעה
אתם לא צריכים לבנות את זה. כל כלי ׳צ׳אט עם המסמכים׳ עושה את חמשת השלבים מאחורי הקלעים. מה ששווה לזכור: איכות התשובה נקבעת בשלבים הראשונים, כשהמסמכים נחתכים, הרבה לפני שהמודל אומר מילה.
כשמעלים מסמכים לכלי כזה, שווה לדעת שהוא מחפש לפי משמעות. מילים מדויקות הן שיקול משני. שאלה עם מונח פנימי שלכם, למשל שם של חבילה או מספר דגם, יכולה להחזיר קטע מטעה כי המשמעות הכללית דומה. חיפוש היברידי, שמשלב גם מילות מפתח, פותר את זה ברוב הכלים.
Anthropic לא מציעים מודל הטמעה משלהם ומפנים לספקים כמו Voyage AI. בהטמעה לאחזור מסמנים מה שאילתה ומה מסמך (input_type), כי המודל מייצג אותם אחרת. ב-OpenAI מאגר וקטורי מטפל בחיתוך ובהטמעה לבד, ואפשר לכוון גודל קטע בין 100 ל-4096 טוקנים, סף ציון מינימלי, ומשקל בין דמיון סמנטי לחפיפה מילולית.
04 · למה זה נכשל
מקור רשמי: Anthropic, Contextual Retrieval ↗
ארבע סיבות שהתשובה יוצאת לא נכונה
קטע שנחתך בלי הקשר, מסמך ישן שנשאר במאגר, חיפוש שהחזיר קטע לא נכון, ומודל שענה מהזיכרון במקום מהקטעים. ארבעה כשלים שמכסים את רוב המקרים שראיתי. לכל אחד יש סימן מזהה ותיקון משלו.
Anthropic מדגימים את הכשל הראשון בדוגמה פשוטה: קטע שאומר ׳ההכנסות גדלו ב-3% לעומת הרבעון הקודם׳. בלי ההקשר, אף אחד לא יודע איזו חברה ואיזה רבעון, ולכן החיפוש לא ימצא אותו כשישאלו עליו. הפתרון שלהם, Contextual Retrieval, מוסיף לכל קטע משפט הסבר לפני ההטמעה. בניסויים שלהם זה הוריד את שיעור הכשל של האחזור ב-35%, ובשילוב עם חיפוש מילות מפתח ב-49%.
| מה רואים | מה כנראה קרה | מה עושים |
|---|---|---|
| התשובה נכונה חלקית, חסר פרט שנמצא במסמך | הקטע נחתך באמצע, או שההקשר (מי, מתי) נשאר בקטע אחר | קטעים גדולים יותר עם חפיפה, או משפט הקשר בראש כל קטע |
| התשובה מתאימה לגרסה הישנה של הנוהל | המסמך הישן עדיין במאגר, לצד החדש | מוחקים את הישן מהמאגר עצמו. מחיקה מהתיקייה לא מספיקה. מוסיפים תאריך לכל קטע |
| התשובה מדברת על נושא קרוב, אבל לא על מה ששאלתם | החיפוש החזיר קטעים דומים במשמעות במקום הקטע הנכון | חיפוש היברידי עם מילות מפתח, דירוג מחדש, ובדיקה מה בכלל אוחזר |
| התשובה יפה ואין לה זכר במסמכים | המודל התעלם מהקטעים וענה מהידע הכללי שלו | הנחיה מפורשת לענות רק מהמקורות, ולהגיד ׳לא מצאתי׳ כשאין |
05 · מוצריםלמי שרק מתחיל למי שכבר משתמש לטכניים מקור רשמי: OpenAI, File search tool ↗
מה עושים מוצרי ׳צ׳אט עם המסמכים׳
אותו צינור, ארוז. מעלים קבצים, הכלי חותך ומטמיע לבד, ובכל שאלה שולף ומצרף. שלושת הספקים הגדולים מציעים את זה כשירות מנוהל, עם ציטוטים שמראים מאיזה קובץ הגיעה כל טענה. ההבדלים הם בשליטה שנותנים לכם על החיתוך ועל הדירוג.
ב-OpenAI זה נקרא File search: מעלים קבצים למאגר וקטורי, והמודל מחפש בהם לפי משמעות ולפי מילות מפתח. התשובה חוזרת עם הפניות לשם הקובץ. ב-Google זה File Search, והתשובה כוללת שם קובץ ומספר עמוד. ב-Claude, Project שהמסמכים שלו מתקרבים לגבול חלון ההקשר עובר אוטומטית למצב RAG.
הציטוטים הם החלק שהכי שווה לבדוק כשבוחרים כלי. Anthropic מתארים את התכונה כך: הציטוט מחזיר את הקטע המדויק שתומך בכל טענה, כדי שאפשר יהיה לאמת. מסמכי טקסט ו-PDF נחתכים למשפטים לצורך הציטוט. PDF סרוק בלי טקסט שאפשר לחלץ לא ניתן לציטוט, וזו נקודה שנופלים בה עם חוזים ישנים.
כשמדגימים לכם כלי כזה, תשאלו שאלה שאתם יודעים את התשובה עליה, ותבקשו לראות מאיפה התשובה הגיעה. אם הכלי לא יודע להראות מקור, קשה לסמוך עליו ביום שלא תדעו את התשובה.
תנו לקבצים שמות שמתארים את התוכן, ותמחקו גרסאות ישנות לפני שמעלים חדשות. Anthropic ממליצים על שמות קבצים תיאוריים ב-Projects, וזה נכון לכל כלי: השם משתתף בחיפוש.
ב-OpenAI אפשר להגביל את מספר התוצאות (max_num_results), לסנן לפי מאפייני הקובץ, ולקבל בחזרה את תוצאות החיפוש עצמן לצורך ניפוי. ב-Google קובעים גודל קטע וחפיפה. ב-Claude, Citations עובדים גם על קטעים ממאגר משלכם: כל קטע נשלח כמסמך נפרד, והמודל מצטט אותו.
06 · מתי לא צריך
מקור רשמי: Anthropic Help, Retrieval augmented generation (RAG) for projects ↗
מתי מספיק Project או חיפוש טוב
אם כל המסמכים שלכם נכנסים לשיחה אחת, לא צריך RAG. Anthropic כותבים את זה במפורש: מאגר של פחות מ-200 אלף טוקנים, בערך 500 עמודים, אפשר פשוט להכניס לפרומפט. לעסק קטן, Project עם הקבצים או חיפוש רגיל מכסים את רוב הצרכים.
RAG הוא תשתית. יש בו מאגר לתחזק, מסמכים לעדכן, ובדיקות להריץ. כל שכבה כזאת היא עוד מקום שנשבר. לפני שבונים, שווה לשאול מה בדיוק הבעיה: מסמכים שמשתנים כל יום, כמות שלא נכנסת לשיחה, או צורך במקור לכל טענה. אם אף אחד מהשלושה לא מתקיים, פתרון פשוט יותר יעבוד.
| המצב שלכם | מה מספיק | מתי לעבור ל-RAG |
|---|---|---|
| עד כמה עשרות עמודים שמשתנים לעיתים רחוקות | Project ב-Claude או כלי דומה, עם הקבצים מועלים | כשהקבצים כבר לא נכנסים והכלי מתחיל לדלג על חלקים |
| מאות עמודים, צריך למצוא מסמך ולקרוא בעצמכם | חיפוש טוב במערכת המסמכים הקיימת | כשהשאלות דורשות שילוב של כמה מסמכים לתשובה אחת |
| אלפי עמודים, מתעדכנים כל שבוע, צוות שלם שואל | שירות RAG מנוהל של אחד הספקים | כבר שם. השאלה היא מנוהל או משלכם |
| מידע רגיש שאסור שיצא מהארגון | חיפוש פנימי, או מודל שרץ אצלכם | רק אחרי שבדקתם איפה המאגר הווקטורי יושב ומי ניגש אליו |
07 · בדיקה
איך בודקים שזה עובד
שאלה אחת לא מספיקה. בונים רשימה של 20 עד 30 שאלות אמיתיות עם התשובה הנכונה ואיפה היא כתובה, ומריצים אותה אחרי כל שינוי. בודקים שני דברים בנפרד: האם הקטע הנכון אוחזר, והאם התשובה נאמנה לו.
ההפרדה הזאת חשובה כי התיקון שונה. אם הקטע הנכון לא אוחזר, הבעיה בחיתוך, בהטמעה או בחיפוש, והמודל לא אשם. אם אוחזר והתשובה עדיין לא נכונה, הבעיה בפרומפט או במודל. Anthropic מודדים את החלק הראשון כאחוז השאלות שהקטע הרלוונטי שלהן לא הופיע בין עשרים התוצאות הראשונות. אותו מדד עובד גם בגיליון.
- תאספו 20 עד 30 שאלות שהלקוחות או העובדים שואלים באמת, כולל שאלות בניסוח מוזר
- לכל שאלה תכתבו את התשובה הנכונה, ואת שם המסמך והקטע שבו היא כתובה
- תריצו את השאלות דרך הכלי, ותסמנו לכל אחת: הקטע הנכון אוחזר? התשובה נאמנה לקטע?
- תשמרו את הגיליון. אחרי כל שינוי בחיתוך, במסמכים או בפרומפט, מריצים שוב ומשווים
פרומפט לבניית סט שאלות בדיקה
מקור רשמי: Google AI, File Search (Gemini API) ↗הדבקתי למטה מסמך מתוך מאגר הידע של [השלם את המידע כאן: סוג העסק והתחום]. תכתוב 10 שאלות שלקוח או עובד היו שואלים באמת, ושהתשובה עליהן נמצאת במסמך. לכל שאלה תחזיר בטבלה: השאלה, התשובה הנכונה במשפט אחד, וציטוט מדויק של המשפט במסמך שממנו התשובה. תכלול לפחות שתי שאלות בניסוח יומיומי ולא מדויק, ושאלה אחת שהתשובה עליה לא נמצאת במסמך, ותסמן אותה כך. [השלם את המידע כאן: הדביקו את המסמך]
08 · מחר בבוקרלמי שרק מתחיל למי שכבר משתמש לטכניים
מה עושים עם זה מחר בבוקר
תבחרו מסמך אחד שכולם שואלים עליו. תעלו אותו ל-Project או לכלי שיש לכם, ותשאלו חמש שאלות שאתם יודעים את התשובה עליהן. אם הכלי עונה נכון ומראה מקור, יש לכם התחלה. אם לא, עכשיו אתם יודעים איפה לחפש את הסיבה.
- תעשו רשימה של המסמכים שהעובדים שואלים עליהם הכי הרבה, ותבדקו כמה עמודים זה בסך הכל
- תמחקו גרסאות ישנות לפני שמעלים משהו לכלי כלשהו
- תפתחו גיליון עם עשר שאלות ותשובות. זה הבסיס לכל בדיקה שתעשו מכאן והלאה
תרגיל אחד: אותה שאלה פעמיים, פעם למודל בלי המסמך ופעם עם המסמך מודבק בשיחה. ההבדל בתשובה הוא כל הרעיון של RAG, בקטן.
אם כבר יש לכם כלי כזה והתשובות לא מדויקות, תתחילו מהמאגר. הפרומפט אחר כך. אילו קבצים נמצאים שם, מתי עודכנו, ואם יש כפילויות. ברוב המקרים שראיתי, שם היה המקור לבעיה.
תתחילו מהשירות המנוהל של הספק שאתם כבר עובדים איתו, עם ברירות המחדל, ותריצו את סט הבדיקה. רק אם המספרים לא טובים, תיגעו בגודל הקטעים, בחיפוש היברידי ובדירוג מחדש. ותשמרו את הטקסט המקורי ליד כל וקטור, אחרת אין ציטוטים.
לפני שמעליםמה שעולה למאגר וקטורי נשאר שם, אצל הספק, עד שמוחקים. חוזים, פרטי לקוחות, מידע רפואי או פיננסי: לפני שמעלים, בודקים את תנאי השימוש של הכלי ומי בארגון יכול לשאול אותו שאלות. כלי שעונה לכולם על הכל הוא גם כלי שחושף לכולם את הכל.
שאלות שחוזרות
שאלות שאני שומע על זה
RAG זה אותו דבר כמו לאמן את המודל על המסמכים שלנו?
לא. אימון (fine-tuning) משנה את המודל עצמו, יקר, ולא מתעדכן כשמסמך משתנה. RAG משאיר את המודל כמו שהוא ומביא לו את המידע בכל שאלה. לרוב העסקים RAG, או Project פשוט, מספיקים.
כמה מסמכים צריך כדי שזה יהיה שווה?
השאלה הפוכה. עד כמה מאות עמודים אפשר פשוט להכניס לשיחה או ל-Project. RAG נהיה נחוץ כשהכמות לא נכנסת, כשהמסמכים משתנים כל הזמן, או כשצריך מקור מדויק לכל טענה.
הכלים האלה עובדים בעברית?
מודלי ההטמעה של הספקים הגדולים הם רב-לשוניים, אבל שווה לבדוק על המסמכים שלכם: עשר שאלות בעברית, כולל כאלה עם מונחים פנימיים, ולראות אם הקטע הנכון חוזר. חיפוש היברידי עם מילות מפתח עוזר במיוחד לשמות ולמספרי דגם.
מקורות רשמיים
- Anthropic, Embeddings
- Anthropic, Contextual Retrieval
- Anthropic, Citations
- Anthropic Help, What are projects
- Anthropic Help, Retrieval augmented generation (RAG) for projects
- OpenAI, Vector embeddings
- OpenAI, Retrieval
- OpenAI, File search tool
- Google Cloud, What is Retrieval-Augmented Generation
- Google AI, Embeddings (Gemini API)
- Google AI, File Search (Gemini API)