שליפה גנרטיבית סוף-סוף לומדת לשחק בשני הצדדים

הבעיה: שליפה דו-צדדית תקועה בצד אחד

שליפה (retrieval) היא השלב הראשון בכל מערכת חיפוש או פרסום מודרנית, היא בוחרת קבוצת מועמדים מתוך מיליוני פריטים לפני שהראנקינג והמכרז נכנסים לפעולה. בשנים האחרונות חוקרים דוחפים LLMs לתוך התהליך: הרחבת שאילתות, סינתזת נתונים, אימון עם משוב שליפה. אבל כמעט תמיד הצד הגנרטיבי נשאר בצד השאילתה בלבד; ההתאמה הסופית עדיין מועברת לראנקר נפרד. המאמר החדש CoGR, שעלה כפרה-פרינט (arXiv:2609.00638), מציע לשבור את הא-סימטריה הזו.

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

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

אימון בשני שלבים: SFT ואז GRPO מתואם

הצינור מורכב משני שלבים. קודם fine-tuning מפוקח שמיישר את מרחב מילות המפתח של שני הצדדים. אחר כך נכנס co-evolving RL: בכל סבב צד אחד מתעדכן ב-GRPO מול האינדקס הקפוא של הצד השני, ואז מתחלפים. פונקציית התגמול זהה, F1 של שליפת שאילתה-לפריט, אבל הצד של הפריטים מקבל תגמול שולי קונטרה-פקטואלי: השינוי ב-F1 של הצד השני שנגרם ממילות המפתח שלו. זה מכריח את שני המחוללים להתכנס לאותו מרחב סמנטי בלי להתפוצץ.

תוצאות: שיפור דו-ספרתי על WANDS

על עשרה בסיסי השוואה, דלילים, צפופים וגנרטיביים, CoGR לוקח את המקום הראשון גם בדאטה פנימי של מרקטפלייס אפליקציות וגם בבנצ'מרק הפומבי WANDS. השיפור מול הבסיס החזק ביותר עומד על 10.9% בדאטה הפנימי ו-36.1% ב-WANDS, שניהם ב-F1. הניתוח הנוסף מראה אבולוציה משותפת יציבה והתכנסות הדרגתית של מרחבי מילות המפתח לאורך האימון. המספרים מרשימים, אבל מדובר בפרה-פרינט בלי ביקורת עמיתים, בלי קוד פתוח ובלי משקלים להורדה, אז קחו את ה-F1 בערבון מוגבל עד שמישהו ישחזר.

מה שחסר: אין קוד פתוח, אין מודל להורדה

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