אב-טיפוס RAG של מפתח סירב לענות על כל שאילתה עם דמיון קוסינוס (cosine similarity) נמוך מ-0.50. הוא עבד ללא תפקוד — עד שהוחלף מודל ה-embedding. המגן (guard) אז אפשר לתשובות שגויות לחלחל בשקט. התקרית מוכיחה שסף דמיון מקובע (hard-coded) יכול לקרוס בין מודלים, סיכון המאיים על כל מערכת המסתמכת על דמיון embedding לבדיקות בטיחות.
מדוע הסף היה חשוב
צינורות (pipelines) של RAG משתמשים לעיתים קרובות במגן דמיון: אם דמיון הקוסינוס בין שאילתה למסמך הקרוב ביותר שלה יורד מתחת למספר שנקבע מראש, המערכת מבטלת את התשובה. המגן מונע מהמודל להזות (hallucinating) כאשר ההקשר שנשלף חלש. בהגדרה המקורית, סף של 0.50 שמר על יושר המערכת — שאילתות שאינן ניתנות למענה קיבלו ציון מתחת לקו, ואלו שניתנות למענה קיבלו ציון מעליו.
כאשר שונה ה-embedding backend, אותו חיתוך של 0.50 כבר לא הפריד בין שתי הקבוצות. ה-pipeline החל להחזיר תגובות בטוחות, אך שגויות, ללא קריסה או שגיאה מפורשת. הכשל נמלט ממדדי הדירוג הסטנדרטיים וניכר רק כאשר אדם הבחין בסחף (drift).
גיאומטריה אינה אוניברסלית
כל מודל embedding ממפה שפה למרחב רב-ממדי עם הגיאומטריה שלו. לכן, ערכי דמיון קוסינוס משמעותם שונה ממודל למודל. ציון של 0.50 יכול לשבת על קצה פער ברור עבור מודל אחד, ועמוק בתוך החפיפה עבור מודל אחר.
- Voyage-3 – קו ה-0.50 נמצא בין שאילתות שאינן ניתנות למענה בעלות ציון נמוך לבין שאילתות ניתנות למענה בעלות ציון גבוה. המגן עובד כמצופה.
- BGE-Small – שאילתות רבות שאינן ניתנות למענה מקבלות ציון מעל 0.50, ולכן המגן לעולם לא מופעל. העלאת הסף ל-0.70 מחזירה את שולי הבטיחות.
- Hashing-64 – הציונים עבור שאילתות ניתנות למענה ושאינן ניתנות למענה מעורבבים בצורה כה הדוקה שאין סף בודד שמפריד ביניהם; המודל חלש מדי מכדי לתמוך במגן דמיון בכלל.
מקרים אלו ממחישים אמת רחבה יותר: סף שייך לצמד ספציפי של מודל-נתונים, ולא לכלל אוניברסלי.
העלות הנסתרת של קבוע
ספי דמיון מופיעים במשימות רבות בהמשך הזרם (downstream):
- semantic caching
- זיהוי כפילויות
- בדיקות רלוונטיות של מסמכים
- entity matching
שימוש בערך קבוע מניח שכל מודלי ה-embedding חולקים את אותה התפלגות ציונים — הנחה מסוכנת. כאשר ההנחה נכשלת, מערכות מייצרות בשקט פלט בעל "ביטחון שגוי", מה ששוחק את אמון המשתמש ומזין החלטות בהמשך הזרם בנתונים כוזבים.
כיול מגנים לכל מודל
הפתרון פשוט: לעולם אל תפיצו קבוע מקובע (hard-coded). התייחסו לסף כאל היפר-פרמטר (hyper-parameter) שיש לכוונן עבור כל מודל embedding חדש.
- אספו סט ולידציה צנוע ומתוייג המכסה הן שאילתות ניתנות למענה והן שאילתות שאינן ניתנות למענה.
- חשבו דמיון קוסינוס עבור כל זוג שאילתה-מסמך באמצעות המודל המיועד.
- שרטטו את שתי ההתפלגויות או חשבו את ה-false-confident rate — שיעור השאילתות שאינן ניתנות למענה החורגות מהסף המועמד.
- בחרו את ערך הדמיון הקטן ביותר ששומר על ה-false-confident rate מתחת לרמת סיכון מקובלת.
מכיוון שהמטרה היא למנוע ביטחון עצמי מופרז, מדדי דירוג מסורתיים כמו mean reciprocal rank (MRR) אינם מספיקים. ה-false-confident rate מודד ישירות את מצב הכשל של המגן.
נקודת מבט נגדית: "חלק מהמודלים עובדים 'מהקופסה'"
זה נכון שמודלים מסוימים מתנהגים היטב, כמו Voyage-3 בדוגמה, במקרה מתאימים למגן של 0.50. זה לא מבטיח יציבות עתידית. עדכוני מודלים, כוונון עדין (fine-tuning), או אפילו שינויים ב-corpus הבסיסי יכולים לשנות את התפלגות הדמיון ולשבור שוב את המגן. הסתמכות על התאמה מקרית בודדת מזמינה פזיזות.
מה לעקוב אחריו בהמשך
-
-
-
שורה תחתונה
סף דמיון אינו מתג בטיחות אוניברסלי; הוא מגן ספציפי למודל שיש לכייל בכל פעם שמשנים את ה-embedding backend או את הנתונים שהוא רואה. התעלמות מעובדה זו מאפשרת למערכות RAG להחליק אל תוך הזיות שקטות, מה שערער את המטרה המהותית של המגן. הדרך האמינה היחידה קדימה היא כיול שיטתי לכל מודל וניטור מתמשך של ה-false-confident rate.