Query Expansion באמצעות AI — שיפור Retrieval אוטומטי

מאת צוות מדיה דיל · 09.08.2026 · AI · 8 דק׳

שאלה קצרה ועמומה היא חיפוש גרוע. מדריך ל-Query Expansion: איך AI משכתב, מרחיב ומפרק שאלות לפני החיפוש עצמו, ולמה זה משפר Retrieval יותר מכל שינוי אחר.

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

דוגמה מהשטח: תמיכה טכנית עם שאלות עוקבות

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

למה זה השלב עם ה-ROI הגבוה ביותר בצינור RAG

הרבה צוותים משקיעים את מירב המאמץ ההנדסי בשיפור מנוע החיפוש עצמו - Embeddings טובים יותר, Hybrid Search, Reranking - ומזניחים את איכות הקלט למנוע הזה. אבל שאילתת חיפוש גרועה תישאר גרועה גם עם מנוע החיפוש הכי מתקדם - אין מה לשפר, כי אין מספיק אינפורמציה בשאילתה מלכתחילה. שיפור השאילתה עצמה, לפני החיפוש, הוא לרוב ה"תיקון" הכי זול והכי משפיע בכל צינור RAG.

מי צריך להריץ את שכבת עיבוד השאילתה - ולפי איזו לוגיקה

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

ארבע טכניקות מרכזיות

1. שכתוב מבוסס הקשר שיחה (Contextual rewriting)

שאלה כמו "כמה זה עולה?" תלויה לחלוטין במה שנאמר קודם בשיחה. מודל שפה קטן ומהיר עובר על ההקשר האחרון (2-5 תורות שיחה אחרונים) ומייצר שאילתה עצמאית ומלאה - "מה מחיר מנוי הפרימיום החודשי" - שאפשר לשלוח למנוע החיפוש בלי תלות בהקשר קודם.

2. פירוק שאלות מורכבות (Query decomposition)

שאלה כמו "מה ההבדל בין תוכנית A ל-B, ואיזו מהן מתאימה לעסק קטן?" היא בעצם שתי שאלות שזורות. פירוק אוטומטי מפצל אותה לתת-שאילתות נפרדות - "מה כולל תוכנית A", "מה כולל תוכנית B", "מה מומלץ לעסק קטן" - כל אחת נשלפת בנפרד, והתוצאות מאוחדות לפני הזרקה לפרומפט הסופי. זה קריטי כי חיפוש אחד "מטושטש" על כל השאלה המורכבת יחד נוטה להביא תוצאות בינוניות לכל חלק, במקום תוצאות טובות לכל אחד מהחלקים בנפרד.

3. הרחבת מונחים (Term expansion)

משתמש שכותב "לא מצליח להתחבר" אולי מתכוון ל"login נכשל", "אימות זהות", "כניסה למערכת" - מונחים שונים שעשויים להופיע במסמכי המקור. הרחבת שאילתה מוסיפה מונחים נרדפים ורלוונטיים לשאילתת החיפוש, מה שמשפר במיוחד את הרכיב של חיפוש מילות מפתח ב-Hybrid Search.

4. HyDE - Hypothetical Document Embeddings

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

שאלה: "איך מבטלים מנוי?"

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

--> הטקסט הזה (לא השאלה המקורית) הופך ל-Embedding לחיפוש

שאילתות רב-שלביות בשיחות ארוכות

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

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

שילוב Query Expansion עם אישיות ופרופיל משתמש

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

Trade-off מרכזי: Latency מול איכות

כל שכבת עיבוד שאילתה, מכיוון שהיא מריצה קריאת LLM נוספת לפני החיפוש עצמו, מוסיפה latency ממשי לתחילת התהליך. במערכות רגישות זמן תגובה, זה שיקול אמיתי. הפתרון המקובל הוא להשתמש במודל קטן ומהיר מאוד (בהתאם לעקרונות Model Routing) לשלב הזה בלבד - זו משימה ממוקדת יחסית שלא דורשת את המודל החזק ביותר, ולכן אפשר להריץ אותה במהירות ובעלות זניחה יחסית לתועלת שהיא מספקת.

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

מתי הרחבת שאילתה עלולה להזיק

חשוב לא להתייחס ל-Query Expansion כאל שיפור חד-כיווני. הרחבת מונחים אגרסיבית מדי - למשל הוספת יותר מדי מילים נרדפות מרוחקות משמעות - יכולה "לגרור" את החיפוש לכיוונים לא רלוונטיים, בדיוק כמו שרעש בכל אות אחר פוגע באיכות האיתות. דוגמה קונקרטית: הרחבת "בעיה בהתחברות" למונחים כמו "כשל", "תקלה", "שגיאה" עשויה להביא תוצאות רלוונטיות מדי הקשרים אחרים לגמרי במערכת (תקלת חומרה, שגיאת תשלום) שלא קשורים לבעיית ההתחברות המקורית. הפתרון המעשי הוא הגבלת ההרחבה למונחים קרובים משמעותית, ובדיקה אמפירית שההרחבה משפרת ולא פוגעת ב-Precision על סט בדיקה מייצג.

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

עיבוד שאילתה בשפות שונות מהתוכן

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

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

Query Expansion, כמו כל שינוי בצינור RAG, יכול גם להזיק אם הוא מיושם בצורה גרפומנית מדי - הרחבת מונחים אגרסיבית מדי עלולה "לגרור" תוצאות לא רלוונטיות שמתאימות למונח הנרדף אבל לא לכוונה המקורית. לכן חשוב למדוד את השפעת ההרחבה על מדדי Retrieval בפועל (Precision/Recall) דרך Evals ייעודיים, ולא להסתמך רק על תחושה סובייקטיבית מכמה דוגמאות ידניות.

שאלות נפוצות

מה ההבדל בין Query Expansion ל-Query Rewriting?

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

האם HyDE תמיד עדיף על חיפוש רגיל לפי השאלה?

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

האם עיבוד שאילתה מוסיף עלות משמעותית?

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

איך מטפלים בשאלות רב-לשוניות?

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

האם כדאי לשלב פירוק שאלות עם Reranking?

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

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

תגיות: Query Expansion · Query Rewriting · RAG · HyDE · Retrieval · Information Retrieval

← חזרה לבלוג · צור קשר