פיתוח RAG עם מסד נתונים וקטורי Milvus — ניסיון ומקרי בוחן

RAG Milvus: מדוע חיפוש במסמכים מניב תשובות לא רלוונטיות

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

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

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

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

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

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

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

מה משתנה לאחר ההטמעה: דיוק, מהירות, יציבות החיפוש

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

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

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

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

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

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

אפשרויות בניית חיפוש במאגר ידע: השוואת גישות

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

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

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

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

כיצד אנו מובילים את ההטמעה: שלבי עבודה הנדסית

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

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

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

מה אנו מוסרים ללקוח: תצורות, תרשימים ונהלים

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

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

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

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

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

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

מה שינינו

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

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

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

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

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

במה שונה RAG Milvus מחיפוש רגיל לפי מילות מפתח?

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

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

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

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

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

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

ספקות טכניים: מגבלות, סיכונים ובקרת איכות

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

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

כיצד מובחנות הרשאות גישה לסעיפים?

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

באיזו תדירות מתעדכן האינדקס?

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

מה עם מסמכי המקור ומה קורה לאחר המסירה?

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

נדון במשימה: הרכב העבודה ומה נדרש מכם

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

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

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