פיתוח RAG עם בסיס נתונים וקטורי Weaviate

RAG Weaviate: מדוע החיפוש לא מוצא את התשובה הנדרשת

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

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

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

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

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

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

מה נותן חיפוש מנוהל: מהירות התשובה ושלמות התוצאות

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

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

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

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

מצבי RAG Weaviate: וקטורי, היברידי, עם דירוג מחדש

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

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

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

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

שלבי הטמעה: מביקורת הקורפוס ועד מסירה לתפעול

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

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

ערכת מסירה: קונפיגורציות, סכימות גישה, נהלים

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

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

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

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

נקודת התחלה

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

על מדגם מתויג של פניות אמיתיות שיעור ההתאמות הנכונות למסמך היעד עמד על כ-40%, וחיפוש התשובה ארך 4–6 דקות — חלק מהפניות עד אז כבר עברו לקו השני.

מה שינו

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

חודש אחרי ההשקה, הדיוק בהתאמה למסמך הנדרש עלה מכ-40% ל-85%, וזמן חיפוש התשובה ירד ל-40–50 שניות יחד עם קריאת הקטע שנמצא. שיעור הפניות שהנציג סגר בעצמו, בלי העברה לקו השני, עלה מ-55% ל-80%.

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

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

מה לעשות אם החיפוש כבר עובד על פתרון אחר?

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

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

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

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

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

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

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

מה לעשות עם טבלאות וסריקות במסמכים?

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

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

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

כיצד להפריד הרשאות גישה לנתונים?

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

איך להבין אם הפתרון נעשה טוב יותר או גרוע יותר?

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

נדון במשימה: מה להכין לשיחה הראשונה

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

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

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