כיוונון עדין של מודל Embedding לדומיין של הלקוח

אימון נוסף של מודל embedding: כשהחיפוש לא מבין את הדומיין

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

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

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

בשאילתות תחומיות, חיפוש לקסיקלי לפי הופעת המילה עוקף לעיתים קרובות את החיפוש הסמנטי — סימן מובהק לכך שייצוג המונחים אינו תואם את הקורפוס שלכם.

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

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

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

מה משתנה באיכות החיפוש לאחר התאמה תחומית

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

ההתאמה מזיזה את המרחב הווקטורי לכיוון שפת בסיס הידע: שיעור התוצאות הרלוונטיות בשלוש הראשונות על סט ייחוס עולה מ-40–55% ל-85–90%, והמיקום הממוצע של המסמך הנדרש הראשון מתקצר בערך בחצי.

ההשפעה ניכרת ביותר במילים נרדפות, בתעתיק ובקיצורים פנימיים. «GO», «KP», «SF», ראשי תיבות של מחלקות ושמות של מערכות פנימיות — עבור המודל הכללי הם כמעט בלתי ניתנים להבחנה משגיאות כתיב, ועבור המודל המותאם הם עוגנים סמנטיים יציבים.

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

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

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

דרכי התאמה של החיפוש: השוואת גישות

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

אנו הולכים מלמטה למעלה: תחילה כללים וכיוונון האינדקס הווקטורי, לאחר מכן חיפוש היברידי, ורק לאחר מדידת התקרה — אימון נוסף. אותו סט שאילתות מורץ בכל שלב, ולכן בהשוואה של גישות לחיפוש רואים איזה רובד הניב שיפור, ואיזה אפשר להחזיר אחורה בלי לאבד איכות.

כיצד מתבצע אימון נוסף של המודל על נתונים תחומיים

האימון הנוסף מתחיל לא בהרצת האימון, אלא במלאי של מה שהמודל כבר עושה רע. אחרת מתקבלת מערכת שמשיבה טוב יותר על דוגמאות מוכנות וטועה באותה מידה בשאילתות אמיתיות.

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

2. תיוג זוגות תחומיים. אוספים זוגות «שאילתה — מסמך רלוונטי» ומוסיפים שלילות מורכבות: קרובות בנושא אך לא מתאימות. את התיוג מבצעים בעלי ידע בתחום, ומקרים שנויים במחלוקת נבחנים לפי כלל נפרד.

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

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

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

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

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

מה אנו מוסרים בתפוקה: הגדרות, תכניות, נהלים

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

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

מפתחות וסיסמאות אינם נמסרים כקבצים נפרדים: ההרשאות מונפקות לחשבונות שלכם, ואנחנו מסירים את שלנו לאחר הקבלה.

מקרה בוחן: דיוק החיפוש בבסיס ידע פנימי לפני ואחרי

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

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

מה נמדד לפני העבודה

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

מה שינינו ומה התוצאה

האימון הנוסף של מודל embedding התבצע על זוגות «שאילתה — קטע רלוונטי» שתויגו על ידי בעלי ידע בדומיין. לאינדקס הווקטורי ב-OpenSearch הוספנו חיפוש לפי מילות מפתח, דירוג מחדש ומסנן לפי הרשאות גישה.

הפגיעות בשלוש הראשונות עלו מ-47% ל-86%, הנזכרות בעשר הראשונות — מ-71% ל-94%, והמיקום הממוצע של המסמך הנכון עבר מהשישי לשני.

את השיפור בדקנו על מדגם מוחזק: הפער לעומת מדדי האימון — בטווח של 2 נקודות אחוז. קיים היפוך חזרה: משקלי המודל וגרסת האינדקס מוחלפים בהגדרה אחת, בלי בנייה מחדש ובלי השבתה.

מה לעשות אם החיפוש כבר פועל על פתרון מוכן

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

אימון נוסף של מודל embedding סוגר בדיוק את הרובד הזה — לוגיקת הדירוג, הממשק והתרחישים המוכרים נשארים במקומם.

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

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

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

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

ספקות טכניים: כמה נתונים צריך וכיצד לבדוק

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

האם המודל לא יירד באיכותו בשאילתות כלליות?

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

כיצד לבדוק איכות בלי סט ייחוס?

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

באיזו תדירות לאמן את המודל מחדש?

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

נדון במשימה: מהיכן להתחיל ומה נדרש מכם

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

מה כדאי להכין לשיחה הראשונה:

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

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

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