סינון, ניקוי ווקטוריזציה של התכתבות אימייל עבור RAG

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

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

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

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

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

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

מה משתנה לאחר ניקוי ווקטוריזציה של ההתכתבות

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

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

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

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

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

מצבי עיבוד התכתבות: זרימה, אצווה וסכימה היברידית

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

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

השוואת מצבים

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

שלבי הטמעה: מביקורת תיבות ועד מסירת נהלים

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

1. ביקורת תיבות דואר. מיפוי מלאי של המקורות: כמה תיבות ותיקיות, אילו פורמטים של קבצים מצורפים, אילו קידודים ושפות, שיעור התפוצות השירותיות וההתראות האוטומטיות. בתוצאה — רשימה של מה שנכנס לעיבוד ורשימה מפורשת של חריגים.
2. סכימת הצינור. מתאמים את רצף הפעולות: חילוץ גוף ההודעה, חיתוך ציטוטים וחתימות, הדבקת כפילויות משרשורים, נרמול קידודים, חלוקה לקטעים סמנטיים ובניית אינדקס וקטורי. הסכימה נקלטת לפני כתיבת הקוד — תיקונים בשלב זה זולים יותר מעבודה מחדש לאחר עיבוד מלא.
3. פיילוט על מדגם בקרה. מריצים כמה מאות הודעות שסומנו ידנית כ"בעלות תוכן" ו"רעש". קריטריון הקבלה — שיעור הקטעים שחולצו נכון והיעדר נתונים שירותיים באינדקס.
4. עיבוד מלא במנות. עוברים על התיבות עם תיעוד שגיאות; הודעות שהניתוח שלהן נכשל נכנסות אוטומטית לתור חוזר, ולא הולכות לאיבוד.
5. בדיקת איכות החיפוש. מערכת שאלות עם תשובות ייחוס: בודקים אם ההודעה הנדרשת נמצאת בתוצאות הראשונות והאם המערכת מפנה למקור הראשוני.
6. קבלת התוצאה ומסירת נהלים. הדגמה על השאילתות שלכם, הוראות למשתמשים, כללי גישה וסדר עדכון האינדקס בהתכתבות חדשה.

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

מה הצוות מוסר לידיים: סכימות, מילונים ונהלים

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

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

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

מקרה בוחן: כיצד התכתבות של מחלקת מכירות הפכה למקור ידע

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

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

מדדים לפני ואחרי

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

מה השתנה בעבודה

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

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

במה שונה אינדוקס אימייל מחיפוש פשוט בתיבה?

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

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

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

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

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

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

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

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

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

כיצד מעובדים קבצים מצורפים וציטוטים מקוננים?

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

האם החיפוש לא יהפוך לערוץ דליפה?

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

באיזו תדירות מתעדכן האינדקס?

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

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

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

מה נדרש מצד הלקוח:

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

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