תכנון ארכיטקטורת צינור RAG

מדוע פייפליין RAG עונה באופן לא מדויק על שאלות מורכבות

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

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

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

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

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

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

מה נותנת ארכיטקטורת חיפוש ויצירה מנוהלת

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

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

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

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

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

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

השוואת אפשרויות: חיפוש וקטורי, היברידי וגרפי

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

מה משתנה בשלב ההחזרה

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

שלבי העבודה: מביקורת נתונים ועד מסירה לתמיכה

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

1. ביקורת נתונים. מפרקים את המקורות — נהלים, מאגר פניות, חוזים, מאגר ידע — וסופרים היקף, כפילויות, גרסאות מיושנות ומדורים חסומים. בתוצר מתקבלת מפה: מה מאונדקס, מה מוחרג, ולפי איזה סימן מחלקים הרשאות בין מחלקות.
2. תכנון סכמת החיפוש. קובעים את גודל המקטע הסמנטי, אסטרטגיית החיפוש, סט המסננים והכללים שלפיהם התשובה חייבת להפנות למקור ולא לספר אותו מחדש במילים שלה.
3. כיוונון האינדקס. בונים מסוע אינדוקס: פירוק פורמטים, תיוג במטא-נתונים (מחלקה, תאריך, גרסת המסמך), עדכון תקופתי לפי לוח זמנים במקום טעינה ידנית.
4. בדיקת איכות התשובות. מכינים סט שאלות בקרה, כולל כאלה שאין להן תשובה במאגר. בודקים את שיעור התשובות עם קישור תקין, את שיעור ה«אין בנתונים» הכנות ואת השגיאות בגרסאות מיושנות של מסמכים.
5. פיילוט וכיוונון נוסף. מריצים על צוות אחד: ניסוחי שאילתות אמיתיים שונים מאלה של הבדיקות, ואחריהם מתקנים את הפיצול ואת סף החיתוך.
6. מסירה לתמיכה. מוסרים תיעוד, נוהל אינדוקס מחדש בעת עדכון מקורות, לוח מדדי איכות ונוהל לטיפול בפניות «התשובה שגויה».

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

תיעוד טכני, תרשימים ונהלי עדכון

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

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

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

מקרה בוחן: כיצד הסרנו תשובות בלי עיגון במקורות

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

מה שינינו

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

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

מדדים לפני ואחרי

שיעור התשובות בלי עיגון במקור — 34% → 4%, זמן התשובה הממוצע — 9 → 2.5 שניות, פניות לתמיכה חיה בשאלות טיפוסיות — מינוס 41%. כל תשובה מגיעה עם קישור למסמך מסוים, וניסוחים שנויים במחלוקת עוברים לשיפור המאגר ולא להתכתבות עם התמיכה.

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

במה פייפליין RAG שונה מאימון נוסף של המודל

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

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

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

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

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

שאלות שמהנדסי הלקוח שואלים

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

כיצד מחלקים מסמכים לחלקים כדי שהתשובות לא יאבדו משמעות?

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

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

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

המסמכים משתנים כל יום — כיצד מתעדכן מאגר הידע?

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