פיתוח מערכת RAG (Retrieval-Augmented Generation)

פיתוח מערכת RAG: היכן נשבר חיפוש התשובות

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

אנו מנתחים ארבע נקודות כשל שמופיעות כמעט בכל פרויקט.

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

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

מה משתנה לאחר ההפעלה: מהירות וסוגי כשלים

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

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

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

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

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

אפשרויות ארכיטקטורה: השוואת גישות לחיפוש

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

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

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

שלבי היישום: מביקורת המאגר ועד למסירה

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

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

מה אנו מוסרים לידיים: אינדקס, סכמות, נהלים

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

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

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

מקרה בוחן: תשובות לפי נהלים במקום חיפוש ידני

מאגר הידע הפנימי של חברת החזקות תעשייתית «Северный контур» — כ-4,000 מסמכים: נהלים, צווים, הוראות בטיחות בעבודה, תבניות חוזים. העובדים חיפשו לפי מילות מפתח ושמות קבצים, לכן תשובה לשאלה טיפוסית ארכה 15-25 דקות, ומקרים שנויים במחלוקת בכל זאת עברו לעורך דין או למשאבי אנוש. במאגר עם זאת היו מהדורות מיושנות, והן נמצאו באותה מידה כמו המהדורות הבתוקף.

מה שינו

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

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

מה השתנה

שיעור השאלות שנסגרו ללא הסלמה עלה מ-38% ל-79%, החציון של זמן עד לתשובה — מ-20 דקות ל-40 שניות. דיוק הפגיעה בסעיף הנדרש במדגם בקרה — 9 מתוך 10 פניות. הטעויות שנותרו נופלות על מצבים שבהם נהלים סותרים זה את זה: מקרים כאלה המערכת מסמנת כקונפליקט ואינה בוחרת צד במקום האדם.

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

במה שונה חיפוש RAG מכיוונון עדין של המודל?

כיוונון עדין משנה את משקולות המודל: נתונים פרטיים נמצאים בתוכו, ומכאן нельзя ни לשלוף אותם, ни לעדכן בנפרד. RAG משאיר את הידע בחוץ — באינדקס המסמכים שלכם, והמודל מקבל בכל שאילתה רק קטעים רלוונטיים. מכאן נובעים כל ההבדלים המעשיים בין הגישות.

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

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

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

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

ספקות טכניים: איכות, עדכונים, הרשאות

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

לעובדים יש הרשאות גישה שונות — האם המערכת תתחשב בכך?

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

האם אפשר לא להוציא נתונים מחוץ לפרימטר?

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

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

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

האם נצטרך לבנות מחדש את המערכות הקיימות?

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

נדון במשימה ונחזור עם תוכנית והערכה

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

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

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

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