RAG מחבר מודל שפה למקורות שהארגון בוחר. במקום להסתמך רק על הידע הכללי של המודל, המערכת מאתרת קטעים רלוונטיים ומבססת עליהם את התשובה. האמינות מגיעה מהשרשרת כולה - לא מעצם השימוש ב‑Vector Database.
כהנחת ייסוד, בניית RAG אינה משימה של מה בכך. כפי שניתן לראות ברחבי האינטרנט, יש המון שיקולים שצריך לקחת בחשבון כאשר בונים את צינור ה-RAG בארגון. איזה סוג מסמכים קיימים? מה האורך שלהם? האם הם בעיקר טקסט או שיש בהם הרבה סרטוטים? איך יודעים שה-AI לא ממציא מקור או פסקה ממסמך? או שהוא בכלל שולף את הפסקאות הנכונות?
בניית צינור RAG בצורה נכונה ויסודית היא משימת דאטה בראש ובראשונה, ולאחר מכן גם משימת תכנות והנדסה. צריך להתייחס אליה בכובד ראש. אם מישהו אומר לכם שהוא יכול להקים לכם צינור RAG לארגון בשבוע, קחו את זה עם גרגר של מלח.
התחילו במקורות
מסמך ישן וסותר ייצור תשובה ישנה וסותרת. לפני Embeddings, הגדירו אילו מקורות מוסמכים, מי מעדכן אותם ומה עושים כאשר שני מקורות אינם מסכימים.
מטא-דאטה כגון מחלקה, תאריך, סוג מסמך ותחולת נוהל מאפשר לסנן מידע לפני החיפוש הסמנטי, וברוב המקרים יכול להקל על המודל ולהגדיל את אחוזי הדיוק.
בפועל, הרבה מהעבודה תהיה לסדר ולארגן את המידע הארגוני. צריך להבין אילו מסמכים עדיין רלוונטיים, איזה מקור גובר במקרה של סתירה ומי אחראי לעדכן את המידע. בלי ההחלטות האלה, גם המודל הטוב ביותר יקבל חומר לא אמין ויחזיר תשובה שנשמעת משכנעת.
חלוקה נכונה לקטעים
Chunk קטן מדי מאבד הקשר. Chunk גדול מדי מביא איתו המון רעש. החלוקה צריכה להתאים למבנה התוכן: סעיף, נוהל, שאלה ותשובה, פרק חוזה או יחידת מוצר.
כדאי לשמור כותרות והיררכיה לצד הטקסט כדי שהמערכת תדע מאיפה הגיע כל קטע. אם חותכים את המסמך בלי לשמור את המבנה שלו, קשה להבין אחר כך למה המודל קיבל דווקא את הקטע הזה ואיך הוא קשור לשאר המידע.
חיפוש הוא יותר מדמיון סמנטי
חיפוש היברידי משלב התאמה סמנטית עם מילות מפתח וסינון. לאחר האחזור אפשר לבצע Reranking כדי לבחור את הקטעים הטובים ביותר לפני שהם נכנסים להקשר של המודל. כשבוחרים רכיבי חיפוש ואחזור, כדאי לבדוק גם את מפת כלי הקוד הפתוח ל-AI ואת מחיר התחזוקה שלהם.
לא כל שאלה צריכה להיפתר באמצעות חיפוש סמנטי. לפעמים המידע נמצא בשדה מדויק, בטווח תאריכים, בשם לקוח או בסוג מסמך מסוים. לכן צריך להחליט מראש איזה מידע מחפשים, באיזה אופן מחפשים אותו ומה עושים כאשר יש כמה מקורות אפשריים.
המערכת צריכה גם לדעת מתי לא נמצא בסיס מספק. תשובת “אין לי מקור אמין” עדיפה על ניסוח משכנע שאינו נתמך. המטרה אינה לגרום למערכת לענות בכל מחיר, אלא לבנות תהליך שאפשר לסמוך עליו גם כאשר המידע חסר.
הרשאות חייבות לפעול לפני התשובה
משתמש לא צריך לקבל מידע שאין לו הרשאה לראות רק מפני שהמודל מצא אותו. סינון הרשאות צריך להתבצע בשכבת האחזור, לא כהוראה טקסטואלית למודל.
זו לא רק שאלה של פרומפט. צריך לדעת מי המשתמש, לאילו מקורות יש לו גישה ומה קורה כאשר ההרשאות משתנות. אם המידע כבר נכנס להקשר של המודל, מאוחר מדי לנסות לבקש ממנו להסתיר אותו.
במערכות רגישות מומלץ לתעד אילו מקורות שימשו בכל תשובה, תוך הימנעות מלוגים שמעתיקים תוכן סודי שלא לצורך. תיעוד כזה מאפשר להבין מאיפה התשובה הגיעה ולבדוק מה השתנה כאשר התשובה לא נכונה.
ציטוטים הם חלק מהממשק
תשובה אמינה מציגה מקור, כותרת ותאריך ומאפשרת לפתוח את ההקשר. משתמש צריך לדעת מה עובדה מהמקור ומה סיכום שנוצר על ידי המודל.
אם המשתמש לא יכול לבדוק את המקור בעצמו, קשה לבנות אמון במערכת. גם תשובה נכונה לא תמיד תספיק אם אין דרך להבין על איזה מסמך היא התבססה ומתי המידע עודכן.
איך בודקים RAG
בנו סט שאלות אמיתי הכולל שאלות פשוטות, ניסוחים חלופיים, מידע שלא קיים ומקרים עם מקורות סותרים. בדקו אחזור בנפרד מהניסוח. האם הקטע הנכון נמצא? האם התשובה נשארה נאמנה אליו? האם המערכת יודעת לומר שאין לה מספיק מידע?
מדדים אוטומטיים עוזרים, אך סקירה של אנשי תחום חיונית. הם מזהים תשובה שנשמעת נכונה אך מפספסת נוהל, חריג או משמעות עסקית. במקרים רבים, הבעיה לא תהיה שהמודל לא יודע עברית או לא מבין את השאלה. הבעיה תהיה שהמידע שנשלף לא היה המקור הנכון.
כדאי לבדוק גם מקרי קצה: מסמך שהוחלף, הרשאה שהוסרה, שתי גרסאות שסותרות זו את זו ושאלה שהתשובה אליה פשוט לא נמצאת במאגר. אלה המקרים שיגידו לכם אם בניתם מערכת שאפשר להפעיל בארגון או רק דמו שנראה טוב.
RAG מוצלח אינו “Chat with your PDF”. הוא מערכת מידע עם בעלות, הרשאות, איכות מקורות, הערכה ותצפיתיות. רק אחרי שכל אלה עובדים אפשר להוסיף שכבת שיחה נוחה.
בצורה הזו נוכל לפתח ולהטמיע פתרון RAG רק כאשר הארגון מוכן אליו באמת, עם מידע אמין ומאורגן, הרשאות, רגולציות וחלוקת תפקידים מסודרת.