Query transformation מועיל כשהוא פותר כשל retrieval מסוים. הוא הופך לתיאטרון יקר ברגע שמוסיפים אותו רק כי דיאגרמת הארכיטקטורה הרגישה בודדה.
לא כל שאלת retrieval צריכה rewrite
יש מחלקות כשל שונות. השאלה משתמשת במונח אחד, המסמכים במונח אחר. יש שתי כוונות מעורבות וצריך decomposition. חסרה הפשטה כללית יותר ו-step-back עוזר. צריך HyDE כדי לייצר מרחב חיפוש טוב יותר. צריך fusion של כמה ניסוחים.
אם לא ברור איזו מחלקת כשל קיימת, כל transformation layer תיראה אותו דבר. עוד latency, יותר תנועה, לא בהכרח יותר evidence.
Query rewrite
Rewrite עוזר כשהפער מילוני. המשתמש שואל במונח אחד, המסמכים כתובים במונח אחר, metadata או titles בנויים סביב vocabulary שונה.
שימושי. וגם השכבה שהכי קל להעמיס יתר על המידה. אם rewrite רץ על כל שאלה בלי אבחנה, הוא הופך לעוד מס על המערכת.
Decomposition
Decomposition מתאים כשבשאלה יש כמה תתי-שאלות שונות, וכל אחת צריכה retrieval נפרד. כשצריך ראיות משני אזורים שונים בקורפוס. כשהשאלה מערבבת condition ו-exception. כשתשובה אחת רציפה הייתה דוחפת יותר מדי context לחלון אחד.
Decomposition מוסיף retrieval passes. אם איכות הקורפוס עדיין חלשה, מקבלים יותר תוצאות חלשות, לא יותר ודאות.
Step-back prompting
Step-back עוזר כשצריך למסגר את השאלה ברמה מושגית יותר. השאלה צרה מדי או תלויה בניסוח מקרי. המסמכים מאורגנים סביב כלל כללי יותר. retrieval גולמי נתקע בפרטים הלא נכונים.
גם כאן, אם ה-document structure חלש, השלב הנוסף רק מכסה על הבעיה לזמן קצר.
HyDE
HyDE שימושי כשמרחב החיפוש דל או sparse, וצריך לייצר היפותזה טקסטואלית טובה יותר ל-retrieval.
פחות מתאים כשיש titles ומטא-דאטה טובים, כשהבעיה האמיתית היא ranking, כשה-latency budget לא סובל עוד generation step. HyDE הוא כלי. לא ברירת מחדל.
Query fusion
Fusion עוזר כשיש כמה ניסוחים סבירים של אותה שאלה, וכל אחד פותח מסמכים אחרים. עובד כשכל ניסוח מחלץ signal שונה, כשאפשר לשלב את התוצאות בצורה מבוקרת, וכשיש reranking שמסוגל לנקות את הרעש.
עובד פחות טוב כשאין דרך ברורה למזג את התוצאות, או כשהקורפוס קטן מספיק שהשכבה רק מסרבלת.
איך בוחרים
ההחלטה הפרקטית.
- בעיית vocabulary -> rewrite
- כמה תתי-שאלות נפרדות -> decomposition
- framing צר מדי -> step-back
- corpus sparse -> HyDE
- כמה ניסוחים טובים -> fusion
לפני כל זה, השאלות שצריכות לעלות.
- האם titles ו-metadata של המסמכים סבירים?
- האם chunking נורמלי?
- האם reranking חסר?
- האם חלון ה-context הסופי קטן וברור?
אם התשובות בעייתיות, transformation הוא לא המקום להתחיל בו.
Query transformation הוא לא מנוע עומק כללי. הוא טיפול נקודתי בסימפטום retrieval ספציפי. כשהוא נבחר נכון, מורגש. כשנבחר סתם כך, הוא מוסיף latency ומקשה להבין מה המערכת באמת הייתה צריכה.