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