הטמעת HyDE עבור RAG: יצירת מסמכים היפותטיים מקצה לקצה

למה HyDE עבור RAG נתקע באיכות השאילתה

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

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

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

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

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

האפקט של יצירת מסמכים היפותטיים

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

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

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

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

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

מצבי HyDE RAG: מה ומתי ליישם

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

איך לבחור מצב

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

את הבנייה שכתבנו מחדש לפי ניסוחים אמיתיים של עובדים, את ההשערה קיצרנו לפסקה אחת כדי שרעש לא יסיט את התוצאות, הוספנו מסנן לפי פרק במאגר וסף קרבה — מתחתיו החיפוש מחזיר ביושר תוצאה ריקה במקום מקטעים אקראיים. הבסיס של השיטה — Precise Zero-Shot Dense Retrieval without Relevance Labels.

מה השתנה

דיוק התשובות בשאילתות נדירות עלה מ-54% ל-81%, אישור מהמקור הופיע ב-9 מתוך 10 תשובות. שיעור הסירובים "אין נתונים במאגר" ירד פי שלושה, ושיעור התשובות שסומנו על ידי עובדים כשימושיות — מ-61% ל-88%. זמן הכנת התשובה גדל בשברירי שנייה, ולכן את ההשערה מייצר מודל קל עם מטמון לפי שאילתה מנורמלת.

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

במה HyDE שונה מניסוח מחדש של שאילתה

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

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

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

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

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

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

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

מגבלות הגישה וספקות טכניים

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

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

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

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

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

בכמה גדל העומס על המחולל?

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

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

כדי שההערכה תהיה עניינית ולא "לפי תחושה", אנחנו צריכים מעט: הרכב ונפח הקורפוס, שפות ופורמטים של מקורות, איך החיפוש בנוי сейчас ואילו שאילתות המשתמשים מחשיבים ככושלות.

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

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

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

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