Фильтрация, очистка и векторизация email-переписки для RAG

Почему индексация email ломается на больших объёмах переписки

На объёме в десятки тысяч писем индексация email ломается не на модели, а на подготовке данных: доля мусора в индексе растёт быстрее, чем объём полезного текста. Поиск по смыслу начинает возвращать формально похожие фрагменты, которые не отвечают на вопрос. Разбираем, где именно рассыпается подготовка переписки и что с этим делают.

Первый источник — дубли писем. В цепочке каждое сообщение тянет историю предыдущих, ответы уходят с полным цитированием, пересылки дублируют вложения. Один и тот же абзац попадает в индекс пять-десять раз, и шум в выдаче растёт не потому, что модель слабая, а потому что один смысл представлен десятком почти одинаковых фрагментов.

Второй — служебный трафик: уведомления, автоответы, приглашения в календарь, дисклеймеры и подписи. В объёме переписки они занимают заметную долю символов, но не несут смысла; при векторизации они подтягивают близкие по форме запросы и размывают качество поиска по переписке.

Третий — вложения и структура. Сканы счетов, договоры, таблицы вне текстового слоя выпадают из индекса, а заголовки письма — участники, даты, папки, тема — не попадают в фильтры. Без них нельзя ограничить срез по подрядчику или периоду, и выдача смешивает рабочие обсуждения с рассылками.

Отдельно страдает нарезка: фиксированное окно режет смысл на границах цитат, и перекрытие приходится подбирать под конкретную переписку. Всё это вместе и даёт размытую выдачу по смыслу — дальше разбираем, как конвейер чистят на каждом шаге.

Что меняется после очистки и векторизации переписки

Пока в индекс попадает письмо целиком — с подписью, служебным уведомлением о конфиденциальности, историей ответов и вложенными цитатами, — поиск находит много, но не то. Доля релевантных фрагментов в верхушке выдачи держится около случайной, а время отклика растёт пропорционально числу обработанных символов, а не числу смыслов. Векторизация по смысловым блокам эту зависимость разрывает: в индекс уходят только содержательные абзацы.

После очистки переписки на один вопрос приходится один-два точных фрагмента вместо десятка почти одинаковых. Ответ собирается по первоисточнику — с автором, датой и темой письма, поэтому любое утверждение системы можно проверить в исходе. Полнота выдачи при этом не страдает: отсекается шум, а не смысл, и редкие формулировки не выпадают из результатов.

Сокращение хранилища — следствие той же очистки. Повторяющиеся цепочки сворачиваются до уникальных реплик, заголовки и подписи хранятся один раз, вложения индексируются отдельно от текста. Векторный индекс на Elasticsearch в таком виде перестраивается инкрементально: новое письмо становится доступно поиску за минуты, а не за ночной прогон по всей базе.

Вместе с объёмом уходит целый класс ошибок: система больше не отвечает цитатой из подписи, не склеивает переписку разных людей с одинаковой темой письма и не выдаёт устаревшую редакцию документа как действующую. На выходе — предсказуемая доля попаданий в топ и время ответа, которое не зависит от того, насколько давно заведён ящик.

Режимы обработки переписки: поток, пакет и гибридная схема

Режим обновления индекса — это развилка, которую редко выбирают раз и навсегда: у схем разные требования к свежести ответа, нагрузке на почтовый сервер и объёму хранения. Ниже — три рабочие альтернативы, между которыми чаще всего выбирают.

Во всех трёх вариантах письмо сначала приводится к чистому виду: отделяется тело от служебных заголовков, вырезаются подписи и цитаты предыдущих ответов, вложения описываются отдельным текстом. От качества этого шага зависит, попадёт в индекс смысл или дубли одной и той же цепочки писем.

Сравнение режимов

Границы между схемами подвижны: потоковый режим часто дополняют ночной сверкой, а пакетную пересборку — очередью для свежих писем. Выбор зависит от того, насколько быстро ответ должен учитывать вчерашнюю переписку и готовы ли вы отдавать нагрузку на ящик по расписанию.

Этапы внедрения: от аудита ящиков до передачи регламентов

Работа идёт итерациями: каждый шаг заканчивается артефактом и критерием, по которому заказчик принимает результат. Ниже — шесть этапов, которые мы проходим при индексации почтовой переписки, с указанием того, что именно проверяется на выходе.

1. Аудит почтовых ящиков. Инвентаризация источников: сколько ящиков и папок, какие форматы вложений, какие кодировки и языки, доля служебных рассылок и автоматических уведомлений. На выходе — перечень того, что попадает в обработку, и явный список исключений.
2. Схема конвейера. Согласуем последовательность операций: извлечение тела письма, срез цитат и подписей, склейка дублей из тредов, нормализация кодировок, разбиение на смысловые фрагменты и построение векторного индекса. Схема фиксируется до написания кода — правки на этой стадии дешевле переделки после полной обработки.
3. Пилот на контрольной выборке. Прогоняем несколько сотен писем вручную размеченных как «содержательные» и «шум». Критерий приёмки — доля корректно извлечённых фрагментов и отсутствие служебных данных в индексе.
4. Полная обработка партиями. Идём по ящикам с журналированием ошибок; письма, на которых разбор упал, автоматически попадают в повторную очередь, а не теряются.
5. Проверка качества поиска. Набор вопросов с эталонными ответами: смотрим, находится ли нужное письмо в первых результатах и указывает ли система на исходный источник.
6. Приёмка результата и передача регламентов. Демонстрация на ваших запросах, инструкции для пользователей, правила доступа и порядок обновления индекса при новой переписке.

Ключевые точки контроля — аудит, пилот и приёмка: именно там видно, что качество соответствует договорённостям, а не «в целом работает».

Что команда передаёт на руки: схемы, словари и регламенты

Передаём не только работающий поиск по почтовой переписке, но и весь комплект решений вокруг него — чтобы команда сопровождала систему без нас. По каждому артефакту видно, какое решение принято, почему именно оно и как его менять, не теряя качество выдачи.

• Правила фильтрации. Что не попадает в индекс: служебные рассылки, автоответы, дубликаты, письма без текстового тела. С порогами по числу получателей, признаками массовой отправки и списком исключений.
• Словари очистки. Как снимаются цитаты предыдущих писем, подписи, дисклеймеры и служебные заголовки — с таблицей исключений, чтобы не вырезать полезный контекст.
• Схема разбиения и векторизации. Размер фрагмента, перекрытие, привязка к ветке переписки — от неё зависит, вернёт поиск само письмо или цитату из него.
• Политики доступа. Роли и области видимости, что маскируется до индексации, как письмо удаляется из индекса по запросу и как это подтверждается журналом.
• Документация по конвейеру. Карта этапов от забора почты до ответа модели, точки логирования, метрики и поведение при сбоях и повторной обработке.
• Регламент обновления. Как часто пересобираются словари и индекс, кто принимает изменения и как вернуться к предыдущей конфигурации.
• Набор контрольных проверок. Вопросы с ожидаемыми источниками, прогон после каждой правки — деградация видна до выката.

Всё это передаётся в репозиторий заказчика с историей изменений: правку правил фильтрации или словаря можно проследить и откатить, не привлекая нас повторно.

Кейс: как переписка отдела продаж стала источником знаний

Заказчик — дистрибьютор с отделом продаж в несколько десятков менеджеров: переписка с клиентами велась годами, но новые сотрудники снова и снова задавали вопросы, ответы на которые уже лежали в почте. Мы подключились к ящикам Microsoft 365 и собрали переписку в единую базу знаний, где искать можно обычным вопросом на русском языке.

Основная работа шла не в самой индексации, а в очистке: из сообщений убирали цитаты предыдущих ответов, подписи, юридические приписки и автоматические рассылки, а ветку склеивали в один документ — иначе ответ терял контекст вопроса и поиск возвращал обрывки. Служебные копии и вложения в базу не попадали: они добавляли объём, но не знания.

Метрики до и после

Замеры снимали на одних и тех же 200 вопросах менеджеров: до запуска и через месяц работы с базой.

Что изменилось в работе

Повторное использование писем стало обычной практикой: менеджер находит готовую формулировку предложения или разбор возражения за минуту вместо того, чтобы писать заново. Стажёры перестали занимать наставников одними и теми же вопросами, а руководитель видит, какие темы клиенты поднимают чаще всего.

Знание отдела больше не уходит вместе с уволившимся сотрудником: новые письма попадают в базу автоматически, а старые остаются связанными по темам переписки.

Чем отличается индексация email от простого поиска по ящику?

Клиентский поиск по ящику — это полнотекстовый поиск: запрос должен лексически совпасть со словоформами в полях письма. Локальный индекс в Exchange и совместимых хранилищах отдаёт ответ мгновенно, пока вы помните точную формулировку. Дальше начинается разрыв: переписка на двух языках, сокращения, длинные цепочки ответов, где один и тот же текст повторяется в десяти копиях, подписи и юридические приписки.

Индексация email — это не поиск, а подготовка данных. Письмо разбирается на структуру, новый текст отделяется от цитируемого, ветка переписки склеивается в один документ, снимаются дубли, нормализуются адреса, даты и имена участников. Затем текст режется на фрагменты по смысловым границам и только после этого попадает в индекс.

Полнотекстовый слой при этом не выбрасывается — он остаётся для точных совпадений: номер договора, адрес, артикул, фамилия. Поиск по смыслу работает поверх очищенного корпуса и находит письма, где нужных слов нет вовсе.

Эффект виден в инженерных величинах: доля служебного и цитируемого текста в индексе падает с двух третей до единиц процентов, поэтому ложных попаданий в выдаче меньше, а история за несколько лет укладывается в разумный объём. Граница простая: клиент справляется, пока нужны точные совпадения внутри одного ящика; индексация нужна, когда ищут по смыслу, по всей переписке и с учётом прав доступа.

Технические сомнения и ограничения, о которых стоит знать заранее

Ограничения обработки почти всегда всплывают на пробном запуске: архив читается наполовину, вложения теряются, сотрудник после перевода в другой отдел продолжает видеть чужие письма. Ни один из этих вопросов не блокирует проект, но каждый меняет объём работ и качество ответов — поэтому индексацию email-переписки мы начинаем с явной фиксации ограничений, а не с их обнаружения после запуска.

Как обрабатываются вложения и вложенные цитаты?

Вложения — отдельный слой: таблицы и сканы распознаются, архивы и исполняемые файлы отсекаются. Цепочки ответов схлопываются в один смысловой блок, иначе одна и та же фраза попадает в индекс пять-шесть раз и ломает ранжирование.

Не станет ли поиск каналом утечки?

Индекс строится с наследованием прав источника: в выдачу попадают только письма, доступные сотруднику в почтовой системе. При смене роли или увольнении права пересчитываются — отдельным заданием, а не при следующей пересборке.

Как часто обновляется индекс?

Новые письма догружаются за ночь, изменившиеся ветки пересобираются раз в неделю. Полная переиндексация нужна только при смене модели векторизации или правил очистки: она занимает ресурсы, и на это время поиск отвечает по старому срезу — предупреждаем заранее.

Как начать: обсудим задачу и вернёмся с планом

Старт проекта не требует рамочного согласования и отдельного этапа подготовки: разбираем задачу и сразу определяем, что должна закрывать индексация email. Чем точнее описан источник и реальные сценарии поиска, тем меньше допущений уходит в оценку.

Что нужно со стороны заказчика:

• источник выгрузки: mbox-архив, набор EML-файлов, экспорт из почтового сервиса или выгрузка в JSON;
• объём и структура: число ящиков, порядок числа писем, доля вложений и число участников в одной ветке;
• что отсекать: рассылки, служебные уведомления, автоматические ответы, дубли из истории переписки;
• требования к приватности: какие поля маскировать, где хранится индекс, кто имеет доступ к тексту писем;
• сценарии поиска: например, переписка по конкретному договору или история решения задачи с вложениями;
• контур для работы: тестовый ящик или стенд и ограничения на выгрузку данных.

Дальше порядок шагов такой: смотрим образец выгрузки на нескольких сотнях писем, показываем, как проходят очистка, сборка веток и векторизация, и возвращаемся с планом работ. Обязательств на этом этапе нет — вы получаете понятную схему индексации и оценку объёма.