
Всем привет! Меня зовут Руслан Дюсаев, и я занимаюсь машинным обучением в команде Спамообороны Яндекс Почты. Помимо технологий антиспама, мы с коллегами разрабатываем ML‑фичи в сервисах Яндекс 360.
В статье расскажу, как мы делали Нейрофильтр с YandexGPT 5 в Почте. Он работает на базе двух моделей. Первая, созданная на основе CatBoost, определяет важность каждого письма, чтобы сделать выборку из главных сообщений. А вторая, построенная на базе YandexGPT, выделяет ключевые тезисы из них и выводит краткое резюме. Подробнее о технологиях отбора и суммаризации говорим в этой статье.
Нейрофильтр в Почте
Почта среднестатистического человека выглядит примерно так: сотни, а то и тысячи новых писем каждую неделю. Их так много, что просто нет времени или лень их читать. Подавляющее большинство писем — это сообщения, которые наши пользователи игнорируют или удаляют.
Вместе с этим Почта — значимый инструмент коммуникации в повседневной жизни. То есть важные письма там есть, их много, и мы, как пользователи, не хотели бы их пропускать. Это была одна из болей пользователей, которую нужно было решить.
Так мы и придумали решение, которое не только определит важные письма, но ещё и суммаризирует их.

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

Кажется, с критериями всё просто? Есть проверенные временем технологии, они работают. При решении этой задачи мы интуитивно решили, что письма от банков с уведомлением о нарушении ПДД и требованием оплатить штраф будут важными, а рекламные рассылки от маркетплейсов и рекламные предложения могут оказаться менее релевантными. Однако на практике всё оказалось не так однозначно.
Модель изучила обезличенные действия пользователей и обнаружила, что примерно треть получателей посадочных талонов и половина получателей билетов на события (например, на концерт или спектакль) просто игнорируют такие письма. Есть и другой случай: письма от маркетплейсов с просьбой оставить отзыв о покупке могут казаться не очень важными, но есть пользователи, которые регулярно читают такие письма, кликают по ссылкам и оставляют отзывы.
Пользователи могут по‑разному реагировать на одни и те же письма.. Поэтому учитывать только контент письма недостаточно — мы должны настроить модели так, чтобы они ориентировались на персональные пользовательские особенности и паттерны поведения. Модель должна понимать индивидуальные предпочтения и привычки каждого.
Факторы
Теперь перейдём к данным, которые мы используем для решения этой задачи. У нас в команде Спамообороны есть эвристики, которые можно переиспользовать для решения задачи с определением важности письма. Об устройстве Спамообороны мои коллеги рассказывали в этой статье.
Итак, чем же мы располагаем?
Правила. Это бинарные признаки, которые мы извлекаем из писем, у нас их больше 10 000. Они могут включать, например, факт того, что письмо пришло от Gmail, наличие определённых элементов в теме письма (сабджект) и так далее.
Счётчики. Мы ведём учёт по общему потоку входящих писем. Это включает в себя данные о количестве писем с определённым сабджектом или аттачем, поступивших за последние сутки.
User Embeddings. У нас есть модель, которая строит векторы для пользователя фиксированной размерности. Эти векторы можно переиспользовать в различных задачах.
User Features. Эти данные включают в себя информацию о пользователе и его активности в почтовом ящике (например, вчера получил X писем, прочитал Y, удалил N).
Текстовые части письма. Основная информация содержится в тексте письма, и модели нужно уметь эффективно работать с этим текстом и обрабатывать его. Модель работает только с обезличенными метаданными (например, факт открытия письма), а текст письма обрабатывается внутри защищённого контура без возможности извлечения исходного содержания. В этом закрытом контуре мы учим модель оценивать, какова вероятность, что письмо с таким текстом будет прочитано, удалено, проигнорировано и т. д.
Архитектура DSSM для работы с текстом

Для обучения DSSM мы используем архитектуру, которую предложили авторы статьи от Microsoft, изначально она предназначалась для мэтчинга запросов и документов. Мы адаптировали её под наши задачи.
В качестве query мы подаём текстовые части письма:
Захешированный текст письма
Захешированную тему письма
Имя отправителя
В качестве документной части мы подаём экшены, которые пользователь мог бы совершить с письмом.
Далее это всё проходит через ряд преобразований и полносвязные слои, и на выходе мы получаем два эмбеддинга:
Эмбеддинг запроса
Эмбеддинг документа
Затем мы измеряем семантическую близость между этими двумя эмбеддингами.
Обучение DSSM

Для обучения DSSM мы используем контрастивный лосс. Вот как это работает:
На входе мы подаём модели пары запрос‑документ (батч), где каждый запрос соответствует одному документу.
На выходе из модели формируется матрица размера N × N, где N — количество пар в текущем батче. В этой матрице в ячейке (i, j) содержится скор модели, который отражает соответствие i‑го запроса и j‑го документа.
Таким образом, мы не только учим модель распознавать правильные мэтчи, но и показываем огромное количество не соответствующих друг другу запросов и документов.
Обучение CatBoost
У нас есть большое количество признаков, но загружать их все в CatBoost не стоит. Мы провели feature selection и отобрали 1000 наиболее значимых признаков. После этого начали обучение модели.
В Яндексе настроена специальная инфраструктура для удобного обучения CatBoost, и в качестве приятного побочного эффекта у нас появилась таблица важности факторов с точки зрения самой модели. Если мы посмотрим на эту таблицу, особенно на топ-30 фич по версии CatBoost, то увидим, что в ней преобладают признаки с префиксом User Factors.

Это говорит нам о том, что для модели гораздо важнее учитывать особенности поведения пользователя, чем сам контент письма.
Однако следует отметить, что признаки от DSSM и User Embedded также присутствуют, хоть и в меньшем количестве.
Метрики: оценка качества

Мы значительно улучшили F‑меру, на которую и ориентировались в процессе работы. Это стало возможным благодаря тому, что нам удалось существенно повысить recall, не снижая сильно precision.
Хотя метрика 0,85 может показаться не очень высокой, мы считаем, что достигли определённого потолка, обусловленного шумом в пользовательских данных, на которые мы ориентировались.
Мы проверили эту гипотезу. Фичу тестировали на обезличенных данных B2C‑пользователей, у которых действия, как мы предполагаем, имеют значительный шум: например, половина читает уведомления от маркетплейсов, а половина — нет, и здесь сложно выявить паттерн. Есть много эмоциональных непредсказуемых действий. Когда тот же пайплайн применили к данным менее шумных B2B‑пользователей (то есть тех, которые используют Почту скорее в рабочих задачах), скор достиг значения выше 0,9.
Общая архитектура
Теперь немного о целом архитектурном решении задачи определения важности. У нас есть две ключевые сущности:
Письмо
Пользователь

Модель черпает информацию из обеих сущностей, а также мы имеем неоднородные данные: правила, счётчики и эмбеддинги пользователей. Мы обучили ряд DSSM, которые преобразуют текстовые данные в числовые признаки, чтобы можно было эффективно работать с ними в модели.
Теперь мы можем спокойно подавать все эти данные в CatBoost и ожидать ответа: является ли письмо важным или нет.
В Яндекс Почте есть такой атрибут, как звёздочка. Этот атрибут напрямую связан с моделью определения важности. Если звёздочка в интерфейсе горит, значит, модель определила письмо как важное; если не горит, значит, модель сочла его неважным. Пользователь также может влиять на эту звёздочку, устанавливая её или убирая самостоятельно. Такие действия мы воспринимаем как жалобы на работу модели.

Если посмотреть на график, то видно, что за время наших новых внедрений мы улучшили этот показатель в три раза, то есть в три раза сократили долю жалоб пользователей на модель.
Также модель начала лучше определять, какие письма пользователь прочитает, а какие будет игнорировать. То же самое касается ответов: модель стала более точно предсказывать, на какие письма пользователь будет отвечать, а на какие нет.
Таким образом, нам удалось обучить модель, которая лучше предсказывает, с каким письмом пользователь хочет взаимодействовать, а с каким — нет.
Давайте научимся решать следующую задачу — суммаризировать письма.
Как суммаризировать письма
Сначала мы попробовали использовать стандартный подход: подобрали промт и использовали его в YandexGPT для генерации саммари.
Сам промт содержал 46 строк, из которых 29 были инструкцией для модели. Мы пробовали различные ухищрения, чтобы заставить модель работать эффективно, даже провели мини‑исследование: за какую премию модель согласится решить нашу задачу.

С согласия сотрудников мы использовали для тестирования анонимизированные логи их взаимодействия с письмами (например, время открытия), но не исходные тексты — и прогнали их через улучшенный промт с использованием YandexGPT.
Первые результаты показали, что стандартный подход требует доработки, поэтому мы пошли по пути итеративного улучшения. Это помогло: в процессе дообучения мы лучше поняли задачу, модель и данные, с которыми работаем.

Итеративный подход промпт-тюнинга существенно помог, но мы все же решили дообучить модель.
Fine-tuning
Дообучение модели на пользовательских данных было невозможно из‑за конфиденциальности. Поэтому мы обратились к нескольким коллегам с просьбой помочь улучшить фичу.

Мы получили данные, которые передали асессорам для доработки суммаризаций, оказавшихся недостаточно качественными. Эти улучшенные данные стали основой для создания обучающего датасета, который мы использовали для дообучения YandexGPT.
У нас была гипотеза, что с задачей может справиться более маленькая модель, поэтому мы решили дистилировать. Для дистилляции мы обратились к специалистам из команды YandexGPT. Коллеги предложили нам простую, но эффективную схему.
Суть в следующем: мы выгружаем ещё больше данных от яндексоидов (которые дали согласия) и прогоняем их через дообученную большую модель YandexGPT. Эта модель генерирует несколько вариантов суммаризации для каждого запроса. Затем мы передаём эти варианты асессорам и просим их выбрать наилучший вариант с их точки зрения. Таким образом, мы собрали датасет для дистилляции и обучили маленькую модель.

В итоге мы сократили время инференса в пять раз и, соответственно, сэкономили кучу железа, которое можно переиспользовать в других проектах.

Оценка качества суммаризаций
YandexGPT FT (Fine‑tuning) значительно улучшила результаты по сравнению с сырой версией модели и даже превзошла ChatGPT. А дистилляция не привела к существенному ухудшению качества модели.

К каким выводам мы пришли, решая эту задачу
Определять важность писем оказалось нетривиальной задачей, так как здесь много нюансов, неоднозначностей и противоречий. Но грамотный и последовательный продуктовый подход помог нам её решить.
Информация о пользователе и его действиях важна не меньше, чем информация о письме.
Погружение в дообучение — это серьёзный шаг, и может быть целесообразно попробовать решить задачу с помощью промптинга. Это позволит сэкономить ресурсы, время и нервы.
Если же вы всё‑таки решите идти по пути дообучения, не забывайте о дистилляции. Это часто не приводит к значительному ухудшению качества, но обеспечивает заметное повышение производительности. Сэкономленные ресурсы можно эффективно использовать в будущем.
И последнее наблюдение: если вам не удалось решить задачу сразу с помощью предобученной модели и вы пробовали множество промтов без успеха, это всё равно полезная работа. Вы познакомились с моделью, пощупали данные, нашли и, возможно, исправили баги. В целом скил промт‑инжиниринга крайне полезен как на этапе дообучения, так и на всех последующих этапах работы с LLM.
Вот так мы научились делать саммари для писем и определять их важность. 80% пользователей, включивших фичу, довольны результатами. А вы уже пробовали Нейрофильтр в Почте?