RAG בייצור: מה משתנה אחרי הדמו

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

בקצרה

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

1. קליטה: מה נכנס לאינדקס

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

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

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

2. שליפה: מה יוצא מהאינדקס

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

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

3. עדכניות: כשמסמכים משתנים

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

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

4. הרשאות: לפני השליפה, לא בפרומפט

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

5. הערכה: איך יודעים שזה עדיין עובד

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

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

6. ציטוט וסירוב

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

7. אבטחה: הוראות שמוסתרות במסמכים

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

8. Observability: כל שלב בנפרד

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

שאלות נפוצות

מהן הפרקטיקות המומלצות ל-RAG בייצור?

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

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

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

איך מעריכים מערכת RAG?

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

איפה ההרשאות צריכות להיות ב-RAG?

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

מפעילים RAG בייצור?

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

דברו איתי

קשור: בחירת ארכיטקטורת RAG, Observability ל-AI בייצור, אבטחת AI