Чому індексація email ламається на великих обсягах листування
На обсязі в десятки тисяч листів індексація email ламається не на моделі, а на підготовці даних: частка сміття в індексі зростає швидше, ніж обсяг корисного тексту. Пошук за змістом починає повертати формально схожі фрагменти, які не відповідають на запитання. Розбираємо, де саме розсипається підготовка листування і що з цим роблять.
Перше джерело — дублікати листів. У ланцюжку кожне повідомлення тягне історію попередніх, відповіді йдуть із повним цитуванням, пересилання дублюють вкладення.
Той самий абзац потрапляє в індекс п'ять-десять разів, і шум у видачі зростає не тому, що модель слабка, а тому що один сенс представлений десятком майже однакових фрагментів.
Друге — службовий трафік: повідомлення, автовідповіді, запрошення в календар, дисклеймери й підписи.
В обсязі листування вони займають помітну частку символів, але не несуть сенсу; під час векторизації вони підтягують близькі за формою запити й розмивають якість пошуку за листуванням.
Третє — вкладення й структура. Скани рахунків, договори, таблиці поза текстовим шаром випадають з індексу, а заголовки листа — учасники, дати, папки, тема — не потрапляють у фільтри.
Без них не можна обмежити зріз за підрядником або періодом, і видача змішує робочі обговорення з розсилками.
Окремо страждає нарізка: фіксоване вікно ріже сенс на межах цитат, і перекриття доводиться підбирати під конкретне листування. Усе це разом і дає розмиту видачу за змістом — далі розбираємо, як конвеєр чистять на кожному кроці.
Що змінюється після очищення й векторизації листування
Поки в індекс потрапляє лист цілком — із підписом, службовим повідомленням про конфіденційність, історією відповідей і вкладеними цитатами, — пошук знаходить багато, але не те.
Частка релевантних фрагментів у верхівці видачі тримається близько випадкової, а час відгуку зростає пропорційно до кількості оброблених символів, а не до кількості сенсів. Векторизація за смисловими блоками цю залежність розриває: в індекс ідуть лише змістовні абзаци.
Після очищення листування на одне запитання припадає один-два точні фрагменти замість десятка майже однакових. Відповідь збирається за першоджерелом — з автором, датою й темою листа, тому будь-яке твердження системи можна перевірити у вихідному листі.
Повнота видачі при цьому не страждає: відсікається шум, а не сенс, і рідкісні формулювання не випадають з результатів.
Скорочення сховища — наслідок того самого очищення. Повторювані ланцюжки згортаються до унікальних реплік, заголовки й підписи зберігаються один раз, вкладення індексуються окремо від тексту.
Векторний індекс на Elasticsearch у такому вигляді перебудовується інкрементально: новий лист стає доступним для пошуку за хвилини, а не за нічний прогін по всій базі.
Разом з обсягом іде цілий клас помилок: система більше не відповідає цитатою з підпису, не склеює листування різних людей з однаковою темою листа і не видає застарілу редакцію документа як чинну.
На виході — передбачувана частка влучань у топ і час відповіді, який не залежить від того, як давно заведено скриньку.
Режими обробки листування: потік, пакет і гібридна схема
Режим оновлення індексу — це розвилка, яку рідко обирають раз і назавжди: у схем різні вимоги до свіжості відповіді, навантаження на поштовий сервер і обсягу зберігання. Нижче — три робочі альтернативи, між якими найчастіше обирають.
У всіх трьох варіантах лист спочатку приводиться до чистого вигляду: відокремлюється тіло від службових заголовків, вирізаються підписи й цитати попередніх відповідей, вкладення описуються окремим текстом. Від якості цього кроку залежить, потрапить в індекс сенс чи дублі того самого ланцюжка листів.
Порівняння режимів
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Потокова обробка | Підтримка й продажі: важливо, щоб відповідь враховувала лист, який надійшов хвилини тому | Видалення й правки в старих ланцюжках потрібно дочищати окремо; складніше гарантувати узгодженість при збої |
| Пакетна перебудова | Ретроспективна аналітика й розбір великих архівів, де потрібен цілісний зріз за період | Вікно застарівання — від кількох годин до доби; пікове навантаження на скриньку й сховище |
| Гібридна схема | Великі скриньки з пересиланнями й вкладеннями: свіжий «хвіст» плюс регулярна звірка | Потрібні правила вирішення конфліктів і контроль розсинхрону між шарами |
Межі між схемами рухливі: потоковий режим часто доповнюють нічною звіркою, а пакетну перебудову — чергою для свіжих листів. Вибір залежить від того, наскільки швидко відповідь має враховувати вчорашнє листування і чи готові ви віддавати навантаження на скриньку за розкладом.
Етапи впровадження: від аудиту скриньок до передачі регламентів
Робота йде ітераціями: кожен крок закінчується артефактом і критерієм, за яким замовник приймає результат. Нижче — шість етапів, які ми проходимо під час індексації поштового листування, із зазначенням того, що саме перевіряється на виході.
- Аудит поштових скриньок. Інвентаризація джерел: скільки скриньок і папок, які формати вкладень, які кодування й мови, частка службових розсилок і автоматичних повідомлень. На виході — перелік того, що потрапляє в обробку, і явний список виключень.
- Схема конвеєра. Узгоджуємо послідовність операцій: вилучення тіла листа, зріз цитат і підписів, склеювання дублікатів із тредів, нормалізація кодувань, розбиття на смислові фрагменти й побудова векторного індексу. Схема фіксується до написання коду — правки на цій стадії дешевші за переробку після повної обробки.
- Пілот на контрольній вибірці. Проганяємо кілька сотень листів, вручну розмічених як «змістовні» і «шум». Критерій приймання — частка коректно вилучених фрагментів і відсутність службових даних в індексі.
- Повна обробка партіями. Ідемо по скриньках із журналюванням помилок; листи, на яких розбір упав, автоматично потрапляють у повторну чергу, а не губляться.
- Перевірка якості пошуку. Набір запитань з еталонними відповідями: дивимося, чи знаходиться потрібний лист у перших результатах і чи вказує система на вихідне джерело.
- Приймання результату й передача регламентів. Демонстрація на ваших запитах, інструкції для користувачів, правила доступу й порядок оновлення індексу при новому листуванні.
Ключові точки контролю — аудит, пілот і приймання: саме там видно, що якість відповідає домовленостям, а не «загалом працює».
Що команда передає на руки: схеми, словники й регламенти
Передаємо не лише робочий пошук за поштовим листуванням, а й весь комплект рішень навколо нього — щоб команда супроводжувала систему без нас. За кожним артефактом видно, яке рішення ухвалено, чому саме воно і як його змінювати, не втрачаючи якість видачі.
- Правила фільтрації. Що не потрапляє в індекс: службові розсилки, автовідповіді, дублікати, листи без текстового тіла. З порогами за кількістю одержувачів, ознаками масового надсилання й списком виключень.
- Словники очищення. Як знімаються цитати попередніх листів, підписи, дисклеймери й службові заголовки — з таблицею виключень, щоб не вирізати корисний контекст.
- Схема розбиття й векторизації. Розмір фрагмента, перекриття, прив'язка до гілки листування — від неї залежить, чи поверне пошук сам лист чи цитату з нього.
- Політики доступу. Ролі й області видимості, що маскується до індексації, як лист видаляється з індексу на запит і як це підтверджується журналом.
- Документація по конвеєру. Карта етапів від забору пошти до відповіді моделі, точки логування, метрики й поведінка при збоях і повторній обробці.
- Регламент оновлення. Як часто перебудовуються словники й індекс, хто ухвалює зміни й як повернутися до попередньої конфігурації.
- Набір контрольних перевірок. Запитання з очікуваними джерелами, прогін після кожної правки — деградація видна до викату.
Усе це передається в репозиторій замовника з історією змін: правку правил фільтрації або словника можна простежити й відкотити, не залучаючи нас повторно.
Кейс: як листування відділу продажів стало джерелом знань
Замовник — дистриб'ютор із відділом продажів на кілька десятків менеджерів: листування з клієнтами велося роками, але нові співробітники знову й знову ставили запитання, відповіді на які вже лежали в пошті.
Ми підключилися до скриньок Microsoft 365 і зібрали листування в єдину базу знань, де шукати можна звичайним запитанням російською мовою.
Основна робота йшла не в самій індексації, а в очищенні: з повідомлень прибирали цитати попередніх відповідей, підписи, юридичні приписки й автоматичні розсилки, а гілку склеювали в один документ — інакше відповідь втрачала контекст запитання і пошук повертав уривки. Службові копії та вкладення до бази не потрапляли: вони додавали обсяг, але не знання.
Метрики до та після
Заміри знімали на тих самих 200 запитаннях менеджерів: до запуску й через місяць роботи з базою.
| Метрика | До | Після |
|---|---|---|
| Частка сміття в пошуковому індексі | близько 60 % | 5–7 % |
| Час на пошук відповіді за попереднім листуванням | 15–25 хвилин | менше хвилини |
| Потрібний лист у топ-3 видачі | кожен третій запит | 9 з 10 |
| Листи, які перевикористовують повторно | одиниці | кожна третя відповідь |
Що змінилося в роботі
Повторне використання листів стало звичною практикою: менеджер знаходить готове формулювання пропозиції або розбір заперечення за хвилину замість того, щоб писати заново.
Стажери перестали займати наставників одними й тими самими запитаннями, а керівник бачить, які теми клієнти піднімають найчастіше.
Знання відділу більше не йде разом зі звільненим співробітником: нові листи потрапляють у базу автоматично, а старі залишаються пов'язаними за темами листування.
Чим відрізняється індексація email від простого пошуку по скриньці?
Клієнтський пошук по скриньці — це повнотекстовий пошук: запит має лексично збігтися зі словоформами в полях листа. Локальний індекс у Exchange і сумісних сховищах віддає відповідь миттєво, поки ви пам'ятаєте точне формулювання.
Далі починається розрив: листування двома мовами, скорочення, довгі ланцюжки відповідей, де той самий текст повторюється в десяти копіях, підписи й юридичні приписки.
Індексація email — це не пошук, а підготовка даних. Лист розбирається на структуру, новий текст відокремлюється від цитованого, гілка листування склеюється в один документ, знімаються дублікати, нормалізуються адреси, дати й імена учасників. Потім текст ріжеться на фрагменти за смисловими межами і тільки після цього потрапляє в індекс.
Повнотекстовий шар при цьому не викидається — він залишається для точних збігів: номер договору, адреса, артикул, прізвище. Пошук за змістом працює поверх очищеного корпусу й знаходить листи, де потрібних слів немає взагалі.
Ефект видно в інженерних величинах: частка службового й цитованого тексту в індексі падає з двох третин до одиниць відсотків, тому хибних влучань у видачі менше, а історія за кілька років укладається в розумний обсяг.
Межа проста: клієнт справляється, поки потрібні точні збіги всередині однієї скриньки; індексація потрібна, коли шукають за змістом, по всьому листуванню й з урахуванням прав доступу.
Технічні сумніви й обмеження, про які варто знати заздалегідь
Обмеження обробки майже завжди спливають на пробному запуску: архів читається наполовину, вкладення губляться, співробітник після переведення в інший відділ продовжує бачити чужі листи.
Жодне з цих питань не блокує проєкт, але кожне змінює обсяг робіт і якість відповідей — тому індексацію email-листування ми починаємо з явної фіксації обмежень, а не з їх виявлення після запуску.
Що робити зі старими форматами листів?
Поштові архіви ранніх версій клієнтів і вивантаження із закритих систем читаються частково: губляться службові поля, частина листів потрапляє в індекс без тіла.
Такі джерела йдуть через окремий конвертер, а нечитабельне позначається — ви бачите частку листування, реально покриту пошуком.
Як обробляються вкладення й вкладені цитати?
Вкладення — окремий шар: таблиці й скани розпізнаються, архіви та виконувані файли відсікаються. Ланцюжки відповідей згортаються в один смисловий блок, інакше та сама фраза потрапляє в індекс п'ять-шість разів і ламає ранжування.
Чи не стане пошук каналом витоку?
Індекс будується з успадкуванням прав джерела: у видачу потрапляють лише листи, доступні співробітнику в поштовій системі. При зміні ролі або звільненні права перераховуються — окремим завданням, а не під час наступної перебудови.
Як часто оновлюється індекс?
Нові листи довантажуються за ніч, змінені гілки перебудовуються раз на тиждень. Повна переіндексація потрібна лише при зміні моделі векторизації або правил очищення: вона забирає ресурси, і на цей час пошук відповідає за старим зрізом — попереджаємо заздалегідь.
Як почати: обговоримо завдання і повернемося з планом
Старт проєкту не потребує рамкового узгодження й окремого етапу підготовки: розбираємо завдання й одразу визначаємо, що має закривати індексація email. Чим точніше описано джерело й реальні сценарії пошуку, тим менше припущень іде в оцінку.
Що потрібно з боку замовника:
- джерело вивантаження: mbox-архів, набір EML-файлів, експорт із поштового сервісу або вивантаження в JSON;
- обсяг і структура: кількість скриньок, порядок кількості листів, частка вкладень і кількість учасників в одній гілці;
- що відсікати: розсилки, службові повідомлення, автоматичні відповіді, дублікати з історії листування;
- вимоги до приватності: які поля маскувати, де зберігається індекс, хто має доступ до тексту листів;
- сценарії пошуку: наприклад, листування за конкретним договором або історія вирішення завдання з вкладеннями;
- контур для роботи: тестова скринька або стенд і обмеження на вивантаження даних.
Далі порядок кроків такий: дивимося зразок вивантаження на кількох сотнях листів, показуємо, як проходять очищення, складання гілок і векторизація, і повертаємося з планом робіт. Зобов'язань на цьому етапі немає — ви отримуєте зрозумілу схему індексації та оцінку обсягу.
