פייפליין אמבדינגים: היכן נשברת אינדוקסציית הנתונים
פיגור האינדקס אחרי המקור הוא הכשל הנפוץ ביותר בהתחלה. מסמך מתעדכן במאגר הידע, אבל חיפוש לפי משמעות עדיין מחזיר את הגרסה הקודמת או לא מוצא את הרשומה כלל: האינדקסר רץ לפי לוח זמנים ולא יודע שנוסף משהו חדש. המשתמש מקבל תשובה על סמך קטע מיושן ומאבד אמון במערכת לפני שאנחנו מספיקים להוציא איטרציה שנייה.
צוואר הבקבוק השני של חיפוש לפי משמעות הוא וקטורים לא עקביים. אם חלק מהקורפוס אינדוקס במודל אחד, ומנה חדשה במודל אחר, או שהצ'אנקים נחתכו לפי חוקים אחרים, הקרבה במרחב הווקטורי מפסיקה לשקף משמעות: מסמך רלוונטי קיים במאגר, אבל לא נכנס לתוצאות.
השגיאה שקטה, איכות התשובות יורדת בהדרגה, וכמעט בלתי אפשרי למצוא את הסיבה בלוגים של השאילתות — הפער נראה רק על מדגם מתויג.
ואז מתערב הנפח. חישוב מחדש מלא של וקטורים בעת החלפת מודל או סכימת צ'אנקים נמשך שעות, והתור לאינדוקסציה גדל מהר יותר מקצב הטיפול בו. אינדוקסציית הנתונים הופכת לתהליך לילה נפרד, שכל טריות החיפוש תלויה בו, וכל עיכוב במקור גורר אותה אחריו.
כל זה לא נרפא ב"מודל חזק יותר", אלא בהרכבה של פייפליין אמבדינגים כקו הנדסי נפרד: מי ומתי מריץ חישוב מחדש של וקטורים, איך עושים גרסאות לצ'אנקים ולמודל, ומה מאשר שהאינדקס הדביק את המקור. בואו נפרק איך זה נסגר.
מה משתנה אחרי הטמעה: דיוק התוצאות ומהירות העדכון
לפני ההטמעה החיפוש התבסס על התאמת מילים: המשתמש כתב "איך מחזירים כסף", ובמאגר היה כתוב "החזר כספי" — והתוצאות נשארו ריקות.
אחרי הגדרת פייפליין אמבדינגים, השאילתה והמסמכים מושווים לפי משמעות, ולכן שיעור התשובות הרלוונטיות בחלק העליון של התוצאות עולה באופן מדיד: אותו מחשבים על סט שאילתות בקרה מתויג, ולא מעריכים בעין.
השינוי השני הוא זמן עדכון האינדקס. בעבר עריכות בקטלוג או במאגר הידע הפכו לניתנות לחיפוש רק אחרי בנייה מחדש מלאה, כלומר בעיכוב של עד יממה; כעת מחושבים מחדש רק הקטעים שהשתנו, ורשומה חדשה נכנסת לתוצאות תוך דקות.
עבור צוותים שעורכים תוכן מדי יום, זה מסיר סוג שלם של פניות מסוג "החיפוש לא מצא כלום, למרות שהמאמר קיים כבר מזמן".
בנפרד נסגרת קבוצת כשלים שבדרך כלל מייחסים ל"חיפוש מוזר": כפילויות בראש התוצאות, גרסאות מיושנות של מסמכים, כשלים בשאילתות ארוכות ומנוסחות מחדש. כל אחד מהתרחישים האלה נבדק על מדגם בקרה לפני עלייה לאוויר — רגרסיה נראית בדוח, ולא בתלונות משתמשים.
כשנפח הנתונים גדל, התוצאות לא מתחילות להידרדר: האינדקס מתרחב בבלוקים, והווקטורים מחושבים פעם אחת ונעשה בהם שימוש חוזר באינדוקסציה מחדש. הוספת מקורות ושפות חדשים לא משנה את התנהגות החיפוש — האיכות והמהירות נשארות כשהיו בנפח ההתחלתי.
פייפליין אמבדינגים: השוואת מצבי אינדוקסציה
מצב האינדוקסציה נבחר לא לפי גודל הקורפוס, אלא לפי תדירות השינויים והדרישה לטריות התוצאות. בנייה מחדש מלאה נותנת תמונת מצב עקבית, אבל העלות שלה גדלה לינארית עם הנפח, וחלון ההתיישנות שווה למרווח בין ההרצות. עדכון אינקרמנטלי מחשב מחדש רק מסמכים שהשתנו, אבל תלוי לחלוטין באמינות זיהוי השינויים בצד המקור.
אינדוקסציה זורמת מסירה את העיכוב, אבל מסבכת את בקרת האיכות: מסמך שעודכן חלקית נכנס לאינדקס לפני שהכתיבה במקור הסתיימה. סכימה היברידית מפרידה בין שכבות — נתונים "חמים" זורמים בזרם, ונתוני עזר נבנים מחדש באצוות.
מדידות ענפיות סקירה מוערת של גישות לחיפוש וקטורי מראות שתצורות היברידיות עמידות יותר במקומות שבהם 1 עד 10% מהמסמכים משתנים ביממה.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| בנייה מחדש מלאה של האינדקס | קורפוס יציב, עדכונים פעם ביממה או פחות, נדרשת עקביות תמונת מצב | זמן החישוב גדל לינארית עם הנפח, חלון ההתיישנות שווה למרווח בין ההרצות |
| עדכון אינקרמנטלי | עריכות נקודתיות קבועות, חשוב לתת דין וחשבון על כל שינוי | דורש ניהול גרסאות למסמכים ותגיות שינוי אמינות, האינדקס הולך ומתפצל |
| אינדוקסציה זורמת | טריות קריטית, אירועים מגיעים ברצף | חזרה אחורה ובקרת איכות מורכבות יותר, מסמכים שנכתבו חלקית יוצרים רעש בתוצאות |
| סכימה היברידית | נתונים מגוונים: זרם "חם" ושכבת עזר נפחית | מורכבות תפעול גבוהה יותר, נדרשים קווי ניטור נפרדים וחוקי חזרה אחורה משלהם |
הקריטריון לבחירה הוא שיעור הרשומות המתעדכנות במחזור וחלון ההתיישנות המותר. כל עוד פחות מאחוז מהקורפוס משתנה, בנייה מחדש באצוות מספיקה; בזרם אירועים רציף משלבים בין המצבים, ולא בוחרים אחד.
שלבי הטמעה: מביקורת נתונים ועד מסירה לתמיכה
סדר העבודות בנוי כך שאיכות התוצאות תהיה ניתנת לבדיקה בכל שלב, ולא תתברר רק אחרי ההרצה. קודם כל מתעדים מה בכלל קיים במקורות, אחר כך מרכיבים את קו האינדוקסציה, ורק לאחר מדידות מוסרים את הפתרון לתפעול.
- ביקורת מקורות נתונים. עוברים על כל מערכות המקור: מסמכים, מסדי נתונים, מאגרי קבצים. בודקים נפח, כפילויות, קידודים, רשומות פגומות — בפלט מתקבלת מפת מקורות עם רשימה של מה שצריך לנקות לפני האינדוקסציה.
- סכימת עדכון. קובעים מה משתנה ובאיזו תדירות: אינדוקסציה מחדש מלאה לפי לוח זמנים או נקודתית לפי אירוע. כאן גם מגדירים כללי מחיקה — קטעים מיושנים לא אמורים להישאר באינדקס.
- הרכבת הקו. מממשים פירוק מסמכים, חלוקה לקטעים, חישוב אמבדינגים וכתיבה לאינדקס. גודל הקטע והחפיפה נבחרים לפי אופי הטקסטים: מזה תלוי אם התשובה הנדרשת נכנסת להקשר בשלמותה.
- בדיקה על מדגם בקרה. אוספים סט שאלות אמיתיות עם תשובות ייחוס וקטעים שחייבים להימצא. ההרצה מראה היכן אובדת הרלוונטיות — בחלוקה, בנרמול או בפילטרים על התוצאות.
- מדידת איכות התוצאות. מחשבים את שיעור השאילתות שבהן הקטע הנדרש נכנס לתוצאות הראשונות, ואת שיעור התשובות עם הסתמכות על המקור. את המדדים מתעדים לפני ואחרי כל עריכה, כדי לראות את התרומה שלה בנפרד.
- קבלת הפתרון. מוסרים קונפיגורציות, סכימת עדכון, סט שאלות בקרה ותקנון לבנייה מחדש של האינדקס. מסכמים על סף איכות שמתחתיו מופעל בירור סיבות.
מה נשאר אצלכם: קונפיגורציות, סכימות אינדוקסציה, תקנונים
אנחנו מוסרים את הפתרון לא כ"שירות עובד אצלנו", אלא כערכה שלפיה הצוות שלכם משנה מקורות בעצמו, מבצע אינדוקסציה מחדש לקורפוס ומרים את הקו מחדש אחרי תקלה. הכול נמצא במאגר שלכם ובמערכת ניהול גרסאות — עם היסטוריית עריכות, ולא כארכיון בשיחה.
- קונפיגורציות של הקו: קבצים דקלרטיביים לפי שלבים — פירוק מקורות, חיתוך לקטעים, חישוב אמבדינגים, כתיבה לאינדקס; חיבור מקור חדש או החלפת מודל הם שינוי פרמטר, ולא כתיבה מחדש של קוד.
- סכימת זרמי נתונים: מאין מגיעים מסמכים, היכן נשמרים חפצי ביניים, איך מעובדים דלתות, אילו שדות הם חובה — לפיה מוצאים תוך דקות את השלב שבו הולכות לאיבוד רשומות.
- תקנון עדכון האינדקס: אינדוקסציה מחדש לפי לוח זמנים ולפי אירוע שינוי מסמך, חלון ההרצה, סדר הטיפול ברשומות מחוקות, כדי שהאינדקס לא יתפצל מהמקור.
- תיאור שדות ומטא-נתונים: מה נכנס לוקטור, מה נשאר בפילטרים (תאריכים, מדור, בעלים), אילו שדות משתתפים בסינון בהתחשב בהרשאות גישה.
- הוראות הפעלה מחדש: נקודות חידוש, חזרתיות השלבים, איך מפעילים מחדש שלב אחד בלי מעבר מלא על הקורפוס — תקלה באמצע לא אמורה לעלות יממת השבתה.
- צ'ק-ליסט לבירור תקלות: סיבות אופייניות לתוצאות ריקות, לקטע מיושן, לאי-התאמה בממד הווקטור — ובאילו יומנים להסתכל בכל מקרה.
- תרחישי קבלה ומדדים: סט שאילתות ייחוס, שלמות ודיוק התוצאות, השוואה לפני ואחרי עריכות.
לפני המסירה המהנדסים שלכם מריצים את התרחישים האלה בעצמם: מעדכנים את האינדקס, מחזירים קונפיגורציה אחורה, ומשחזרים את הקו אחרי תקלה מדומה.
מקרה בוחן: דיוק החיפוש עלה אחרי בנייה מחדש של האינדקס
הלקוח — שירות תמיכה טכנית עם מאגר תיעוד של כמה אלפי קבצים. לפני העיבוד מחדש האינדקס נבנה מחדש במלואו: קו האמבדינגים הריץ מחדש את כל המסמכים, אף שהעריכה נגעה לכמה פסקאות בקובץ אחד.
העדכון ארך שעות, והחיפוש אחרי עריכות טריות החזיר גרסאות מיושנות — המומחים הפסיקו לסמוך על התוצאות וחזרו לחיפוש ידני בקבצים.
שינינו את סכימת האינדוקסציה: חילקנו מסמכים לקטעים עם חפיפה, הצמדנו להם מזהים יציבים, והתחלנו לחשב מחדש וקטורים רק עבור הקטעים שנגעו בהם, ואת השאר לעשות בשימוש חוזר.
לבקרת איכות אספנו מראש סט קבוע של שאילתות עם תשובות ייחוס — לפיו חישבנו את שיעור הפגיעות בתוצאה הצפויה, ולא הערכנו את התוצאות בעין.
מדדים לפני ואחרי
- שיעור הפגיעות בתוצאה הצפויה בחמישייה הראשונה של התוצאות: 0.41 → 0.86.
- זמן עדכון האינדקס אחרי עריכות: 6 שעות → 12 דקות.
- נפח העיבוד החוזר בעריכה אופיינית: 100% → 7%.
בנפרד וידאנו שהעלייה בדיוק לא הושגה על חשבון השלמות: גם בשאילתות מחוץ לתיוג שיעור התשובות הרלוונטיות עלה, והתוצאות הריקות פחתו כמעט פי שלושה. כנקודת ייחוס בכיול שימשו סטים פתוחים להערכת חיפוש, ובהם MS MARCO.
במה חישוב מחדש מלא של וקטורים שונה מאינקרמנטלי?
חישוב מחדש מלא מריץ את כל הקורפוס דרך המודל ומחליף את האינדקס הווקטורי באופן אטומי. התוצאה דטרמיניסטית: אין באינדקס אי-התאמות עם המקור, ואיכות התוצאות לא תלויה בהיסטוריית ההרצות הקודמות. המחיר — זמן פרופורציונלי לנפח הנתונים ועומס שיא על המקורות.
חישוב מחדש אינקרמנטלי מזיז רק קטעים שהשתנו: הקו משווה האש של תוכן או תגית עדכון, מחשב מחדש את הצ'אנקים שנגעו בהם ומתקן את האינדקס נקודתית. טריות התוצאות נמדדת בדקות, והקריאה מהמקור מוגבלת לדלתא. מחיקות והעברות צריך לטפל בהן במפורש, אחרת האינדקס צובר רשומות שכבר אין במקור.
שינויים חלקיים הם מצב אופייני של תוכן חי: עריכות פסקאות, מסמכים חדשים, החלפת סטטוסים. חישוב מחדש אינקרמנטלי כאן הוא צפוי, כל עוד לא משתנה מודל האמבדינגים עצמו או שיטת החיתוך לצ'אנקים.
אז וקטורים ישנים וחדשים נופלים למרחבים שונים, התוצאות הופכות לבלתי ניתנות להשוואה — ונדרש חישוב מחדש מלא.
העומס על המקורות הוא המגביל השני. חישוב מחדש מלא קורא את כל הקורפוס ונוגע במסד העבודה או בשירותים חיצוניים; אינקרמנטלי קורא רק את הדלתא ונכנס לחלון של פעילות נמוכה. בפועל מציבים היברידי: אינקרמנט קבוע לטריות בתוספת חישוב מחדש מלא תקופתי כבקרה שתופסת אירועים שהוחמצו.
את המצב בוחרים לפי תדירות העריכות, יציבות המודל והפיגור המותר של התוצאות — ומקבעים בקונפיגורציה, כדי שההתנהגות תהיה ניתנת לשחזור ולא תלויה בהרצות ידניות.
שאלות טכניות: סחיפת נתונים, כפילויות, התיישנות
סחיפת נתונים מתבטאת בלי אף שגיאה ביומנים: שאילתות שלפני חודש פגעו במטרה מתחילות למשוך חומרים סמוכים במשמעות, ושיעור התשובות הרלוונטיות יורד בשקט. הסיבה היא שאוצר המילים של המשתמשים זז, בעוד האינדקס הווקטורי נשאר באותו חתך. לכן את תחזוקת האינדקס אנחנו בונים כמחזור בנייה מחדש קבוע, ולא ככיול חד-פעמי אחרי ההרצה.
מה עושים אם מבנה הנתונים ישתנה אחרי ההרצה?
הסכימה מנוהלת בגרסאות: לכל בנייה יש מניפסט עם הרכב השדות והחוקים להבאתם לווקטור. שדה חדש או החלפת סוג לא שוברים את התוצאות הנוכחיות — הבנייה מחדש מתבצעת לאינדקס נפרד, והמעבר מתבצע רק אחרי הרצה על מדגם בקרה של שאילתות.
איך אתם מסננים כפילויות באינדקס?
כפילויות נתפסות בשני מעברים: בכניסה — לפי מפתח מנורמל וטביעת תוכן, ביציאה — לפי קרבת וקטורים מעל הסף. רשומות דומות לא נמחקות בשקט, אלא מקושרות לקבוצה: בתוצאות נשארת אחת, והשאר זמינות כמקור.
מה קורה עם רשומות מיושנות?
לכל רשומה יש תוקף עדכניות ותאריך אישור אחרון. בזמן בנייה מחדש, רשומות שפג תוקפן עוברות לארכיון: הן מפסיקות להיכנס לתשובות, אבל נשארות במאגר, כדי שבירור תקלה לא יאבד הקשר.
איך אתם שולטים באיכות התוצאות?
על מדגם בקרה אנחנו מחשבים את שיעור הפגיעות במסמך היעד ואת המיקום של התוצאה הרלוונטית הראשונה. המדדים נלקחים לפני ואחרי כל בנייה מחדש — בירידה מעל הסף, גרסת האינדקס החדשה לא עולה לאוויר ועוברת לבירור.
הבדיקות האלה סוגרות סחיפת נתונים, כפילויות והתיישנות במחזור אחד: פייפליין האינדוקסציה עובר באופן קבוע על הקורפוס, והשינויים נכנסים לתוצאות רק דרך מעבר מבוקר.נדבר על המשימה: נרכיב סכימת אינדוקסציה ונעריך את היקף העבודה
לשיחה הראשונה לא צריך אפיון טכני מוכן — מספיק טיוטה. כדאי לראות ייצוא מהמקור, דוגמאות לשאילתות משתמשים אמיתיות ואיך החיפוש בנוי כיום: לפי הנתונים האלה כבר רואים היכן אובדת הרלוונטיות ובאיזה נפח הקו יתחיל להידרדר. בהמשך בירור הנתונים מתנהל לפי צ'ק-ליסט:
- מקורות ופורמטים: מה אנחנו מאנדקסים — טקסטים, מסמכים, קטלוג, היסטוריית פניות — ובאיזו תדירות הם מתעדכנים.
- מגבלות: שפות, אורך רשומה, שדות שאסור למסור לאינדקס — נתונים אישיים, חומרים חסויים.
- החיפוש הנוכחי: מילות מפתח, שירות חיצוני או תיוג ידני — ובמה הוא לא מספק בפועל.
- התנהגות מצופה: מה החיפוש צריך למצוא, לפי אילו שאילתות וכמה מדויק להיות.
- נפח ודינמיקה: כמה מסמכים יש כיום, כמה יופיעו בחודשים הקרובים, באיזו מהירות מגיעים חדשים.
- דוגמאות בקרה: כמה עשרות שאילתות עם תוצאות צפויות, שלפיהן רואים אם נעשה טוב יותר.
אחרי בירור הנתונים נחזור עם סכימת אינדוקסציה, הערכת היקף העבודה ותוכנית עבודה לפי שלבים — הכנת נתונים, יצירת אמבדינגים, אחסון וקטורים, שכבת חיפוש ומדדי איכות. את ההערכה מחשבים לפי בלוקים בנפרד, כדי שתחילת הפרויקט תתחיל מהחלק שנותן תוצאה מהר יותר. תארו את המשימה — נחזור עם הערכה ותוכנית.