Про современные подходы к кластеризации текста с помощью больших языковых моделей

На семинаре VK Lab старший программист-разработчик департамента AI VK Антон Земеров разобрал три разных подхода к кластеризации текста на основе LLM. Вы узнаете, какие проблемы они решают и в каких ситуациях их лучше всего использовать.

Опираемся на эти статьи и рекомендуем с ними познакомиться:
— Goal-Driven Explainable Clustering via Language Descriptions: vk.cc/cvqcx0
— ClusterLLM: Large Language Models as a Guide for Text Clustering: vk.cc/cvqcz7
— Large Language Models Enable Few-Shot Clustering: vk.cc/cvqcAH

Смотреть семинар здесь.

Вредные LLM‑советы для непослушных NLP‑разработчиков и их продактов

Ваня Самсонов, руководитель группы прикладных исследований ИИ, и Дима Парпулов, руководитель команды машинного обучения, поделились опытом разработки продуктов c LLM. В итоге получился микс из болей продактов, исповеди разработчиков, юмора, упоротых рифм и советов Капитана Очевидности.

О чем поговорили:
• обоснование собственного претрейна и его развития;
• основные проблемы при переходе на свой претрейн;
• адаптация open source под русскоязычную реальность;
• почему лучше выпустить с ошибками на старте, чем не выпустить вообще;
• как синтетика заменяет армию AI-тренеров.

Видео ищите здесь.

P.s. а всех, кто зарегался на митап команды Mail.ru сегодня, очень ждём!

Два часа до старта Data Fest🥳

В 12:00 встречаемся офлайн и онлайн! Трансляция главного зала без смс и регистрации (Recsys и Speech) по ссылке 👉 тут 💃

Привет! Завтра (30 мая) в 17:00 команда Одноклассников зовёт на свою регулярную ридинг группу. Будем разбирать статью разработчика команды прикладных исследований ОК Андрея Аргаткина DenseAttention: No-Compromise Exact All NxN Interactions Algorithm with O(N) Space and Time Complexity.

Андрей расскажет о том, как убрать из стандартного трансформерного блока несколько компонентов, не потеряв в качестве, но выиграв в скорости (даже у flash attention!)

Увидимся в зуме!

Записи прошедших ридинг клубов можете найти в канале.

Врываемся в июнь с новостями — теперь каждый месяц этот канал будет вести одна из наших ML-команд🥳

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

Привет!
Меня зовут Илья Алтухов, и я руковожу группой экспериментальных технологий в AI VK.

Сейчас нас в команде 7 человек, выпускники ШАД, МФТИ и ФКН. Мы занимаемся R&D для рекомендательных систем.

Наша цель — смотреть за горизонт и находить новые технологии, а потом затаскивать их в продукт вместе с командами, отвечающими за ML инфраструктуру, рекомендации и поиск. Мы всегда смотрим, как наши разработки можно переиспользовать и где применить среди всех продуктов VK, а затем масштабируем.

Одно из наших направлений — разработка мультимодальных моделей. У нас есть разные типы контента: длинные видео, короткие клипы, статьи. Мы разрабатываем модель, которая будет делать векторные представления контента в едином пространстве. Затем эти представления внедряем в продукт для улучшения рекомендаций, модерации, поиска и тд.

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

Stay tuned! 😎

Претрейн контентного видео-энкодера

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

Для моделирования кадров есть уже существующие подходы, например: 1D ConvNets и RNN над эмбеддингами кадров, 3D ConvNets над самими кадрами. Если рассмотреть эти подходы в контексте обобщающей способности для получения контентных эмбеддингов и вычислительной стоимости, то:

— 1D ConvNets - имеют слабую обобщающую способность и низкую вычислительную стоимость
— RNN - имеют слабую обобщающую способность и высокую вычислительную стоимость
— 3D ConvNets - имеют сильную обобщающую способность и высокую вычислительную стоимость

Оптимальным решением является трансформерная архитектура, но она, как и любая другая, обладает рядом особенностей - для обеспечения наилучшей сходимости необходима процедура претрейна. Одним из классических методов претрейна трансформеров является MLM, но в случае видео он не применим из-за недискретной природы данных (кадров).

Для решения проблемы недискретности кадров мы решили использовать SOTA подход претрейна из домена акустических моделей: BEST-RQ. Данный подход решает такую особенность входных данных путем отображения их в финитное пространство, используя квантизатор. Для претрейна мы собрали свой датасет, который состоит из 200 млн. видео суммарной длительностью 6 млн. часов и содержащих 20 млрд. токенов (кадров). Из каждого видео кадры сэмплировались 1 кадр/сек. Эмбеддинги кадров были посчитаны с помощью EfficientNet-B0. Рассчет кадров происходил в системе YTSaurus на GPU-MAP операциях, весь обсчет занял 4 дня с использованием 500 Nvidia 1080Ti.
Евгений Астафуров из нашей команды про это решение подробно рассказал на DataFest 2024.

Этот подход показал свою эффектиность и мы уже в стадии разработки новой улучшенной версии, о которой расскажем в одном из следующих постов.

Айтемный эмбеддер

Мы разрабатываем модель, которая будет создавать векторные представления (эмбеддинги) для айтемов. Сложность состоит в том, что любой айтем содежит много разнородной информации. Например, у видео есть следующие составляющие: видео кадры, произносимый текст, музыка на фоне, текст на самом видео, название, описание, и тд. В итоге мы хотим создать единый эмбеддинг для айтема, который в себе будет содержать всю эту информацию.

Для решения этой задачи существуют разные подходы:
1. Использовать эмбеддинги из предобученных моделей. В этом случае мы получим не удовлетворительное качество из-за сдвига домена и того, что изначально модель обучалась на другую задачу.
2. Использовать supervised подходы при наличии разметки. Но сложность состоит в ограниченности размеченных данных.
3. Использовать unsupervised подходы. В таких подходах требуется много данных и существует сложность в постановке задачи.

Мы используем unsupervised подход, используя текхники contrastive learning. Суть заключается в использовании метода Noise Contrastive Estimation [раз, два] за счет максимации взаимной информации между разными составляющими айтема.
Например, в случае видео мы максимизируем информацию между выходом с видео энкодера, результатом ASR и названием видео. В результате такого обучения — эмбеддинги разных составляющих находятся в общем пространстве. Таким образом, для формирования итогового эмбеддинга айтема мы взвешенно складываем эмбеддинги разных модальностей.

В результате эти эмбеддинги используются для улучшения качества рекомендаций, поиска и модерации. В рекомендациях мы используем эти эмбеддинги в разных задачах. Например, строим ANN индекс для поиска айтемов похожих на позитивы или делаем пользовательских шаг ALS и дальше используем dot-product между пользовательским и айтемным эмбеддингами как фичу в ранжировании.
А про то, как мы используем эмбеддинги в поиске — расскажем в одном из следующих постов.

Работа с командой

В этом году я выступал на DataFest 2024 с докладом “Дюжина инструментов работы с командой”. За последние 9 лет работы тимлидом в командах и компаниях разного размера я всегда задавался вопросами: как найти и нанять нужных людей? как сделать так, чтобы люди росли? как повысить эффективность команды? Для ответа на эти вопросы я много читал и экспериментировал: что-то срабатывало, а что-то нет. В результате я решил создать набор практичных советов. О нескольких из них я вкратце расскажу здесь.

1. Звёздная карта
Звёздная карта (или матрица компетенций) — это таблица, в которой по столбцам указаны члены команды, по строкам — компетенции, необходимые для достижения командных целей, а в ячейках — уровень экспертизы. Создав такую матрицу для своей команды, вы сможете выявить сильные и слабые компетенции, а также точки роста. Слабые компетенции — это те, в которых вам нужно начать активно развиваться или нанимать людей, обладающих этими компетенциями, иначе цели не будут достигнуты. Точки роста — это области, в которых стоит развивать отдельных членов команды, имеющих слабую компетенцию, связывая их с теми, у кого эта компетенция сильна.

2. 1-to-1
Самими 1-to-1 уже никого не удивишь. Поэтому я хочу подчеркнуть, как их можно улучшить.
(1) С новыми сотрудниками проводите их не реже 1 раза в неделю первые 1.5 месяца — это качественно улучшит их адаптацию.
(2) Сделайте 1-to-1 регулярными и обязательными. Частая отмена, переносы и нерегулярность обесценивают их, и теряется контакт.
(3) Записывайте всё, что вы обсуждаете и о чём договариваетесь, а на каждом следующем 1-to-1 пересматривайте ранее созданные договорённости. Важно, чтобы 1-to-1 не превратились в бесполезные разговоры.
(4) Руководителям важно говорить о своих ожиданиях. Желательно на каждом 1-to-1 говорить, что вы ждёте от своего подчинённого в следующем периоде, насколько он сейчас соответствует вашим ожиданиям и что он может сделать, чтобы их превзойти.

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

На выступлении я подробнее раскрыл эти вопросы и дал еще 9 других советов. Пишите в комментариях, насколько для вас это полезно и делитесь своим опытом ⤵️

Новая встреча ридинг группы ОК уже завтра🔥

(Врываемся в эфир, пока команда готовит новый полезный контент)

27 июня в 16:00 пройдет очередная ридинг группа ОК.

Андрей Кузнецов, ML-директор OK, расскажет про паттерны проектирования агентов, основанных на больших моделях.
Подготовиться можно по статье: Agent design pattern catalogue: a collection of architectural patterns for foundation model based agents.

Подключиться к зуму можно тут📍

Идентификатор конференции: 776 7298 2668
Код доступа: dsrg

P.S. Записи прошедших ридинг клубов можете найти в канале.
Бронируйте время в календарях и подключайтесь завтра!

Эмбеддинги в поиске

В этом посте расскажем, как для задачи улучшения поиска мы применяли наши наработки с Айтемным Эмбеддером, о которых уже говорили выше.
Базовая схема поисковой системы состоит из двух основных компонентов:
(1) retriever - отбирает сотни или тысячи кандидатов из всего корпуса документов,
(2) ranker - ранжирует документы по релевантности для заданного поискового запроса от пользователя. Для улучшения качества ранжирования мы разрабатываем новые фичи на основе нейронных сетей, которые понимают смысл контента и поискового запроса.

Верхнеуровнево наше решение больше всего похоже на подход Dual-Tower Models (DSSM-like) [раз, два]. В общем случае двухбашенные модели включают две нейронные сети: одну для представления запросов, другую — для представления айтемов. Эти модели обучаются таким образом, чтобы векторы запросов и документов были близки друг к другу для релевантных пар. Такой подход хорошо масштабируется и подходит для любых модальностей, однако не может учитывать сложные взаимосвязи между парами query-item и требователен к качеству данных.

В нашем подходе используются 3 башни: для запроса, текстовой (названия и описания) и визуальной информации видео. Используя метод Noise Contrastive Estimation, мы максимизируем взаимную информацию между этими тремя сущностями. В результате такого обучения эмбеддинги поискового запроса и айтемов (у названия+описания свой эмбеддинг, у видео свой) находятся в одном пространстве, а косинусное расстояние между ними является сильной фичей для задачи ранжирования.

Arxiv digest

Привет! Завершаем посты нашей команды дайджестом свежих статей.

1. Modeling User Retention through Generative Flow Networks [link]
Статья от Kuaishou про то, как использовали Genertive Flow Networks реализовали подход GFN4Retention для моделирования ретеншена пользователей. На онлайне в АБ-эксперименте удалось вырастить next-day retention на +0.069%.

2. Survey for Landing Generative AI in Social and E-commerce Recsys – the Industry Perspectives [link]
Большой обзор на использование GenAI для рекомендаций.

3. Amplify Graph Learning for Recommendation via Sparsity Completion [link]
Предложили метод AGL-SC, в котором с помощью матричной факторизации заполняют пропущенные связи в графе взаимодействий.

4. RAVEN: Multitask Retrieval Augmented Vision-Language Learning [link]
Статья от AWS, в которой улучшают VLM (Vision Language Model) с помощью RAG (Retrieval-Augmented Generation).

5. Efficient Document Ranking with Learnable Late Interactions [link]
Статья от Google, описали модель LITE (learnable late-interaction model) с обучаемым поздним связыванием для решения задачи релевантности query-document на основе двухбашенной архитектуры. По сравнению с dot-product nDCG вырос на 0.02-0.08, на разных датасетах и превзошел ColBERT.

6. Hyperbolic Knowledge Transfer in Cross-Domain Recommendation System [link]
Статья от Baidu Inc., предлагают новый метод Hyperboloic Contrastive Learning (HCTS). Основная идея в том, что переводят эмбеддинги разных доменов из евклидова пространства в гиперболическое многообразие и поверх этого делают contrastive learning. Таким образом, решают проблему разреженности и длинного хвоста в распределении данных.

7. Meta-experiments: Improving experimentation through experimentation [link]
Статья от Booking, говорят о важности проводить АБ-тесты над самими АБ-тестами для улучшения АБ-тестов. 🤷‍♂️

8. Robust Interaction-based Relevance Modeling for Online
E-Commerce and LLM-based Retrieval [link]
Статья от alibaba, сделали оптимизации (за счет динамической длины представлений) для ускорения инференса и предлагают метод обучения Contrastive Adversarial Training (CAT), в котором к BCE (Binary Cross Entropy) еще накидывают адверсариальный шум и обучают с дропаутом токенов (сближают эмбеддинги при разных вариантах дропаутов).

9. Effects of Using Synthetic Data on Deep Recommender Models’ Performance [link]
Статья от Huawei про то, как с помощью синтетических данных исправить несбалансированность данных для задачи рекомендаций. На оффлайне показали рост AUC.
________

С вами была группа экспериментальных технологий 😎
Спасибо за ваши реакции и вовлечённость.
А мы передаем эстафету новой команде, о которой вы узнаете совсем скоро в новых постах!

Всем привет! На связи ML-команда Mail.ru. Меня зовут Дима Меркушов, я руковожу нашей командой и предлагаю провести этот месяц вместе с нами в хабе AI VK 😎

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

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

Наша North Star цель — улучшать user-experience и положительно влиять на метрики сервисов, при этом сохраняя наш модельный стек на актуальном sota-уровне.
В этой серии постов более подробно поговорим о том, как это проецируется на такие стримы, как классический NLP и LLM, CV, MLE и старый-добрый табличный ML. А ещё обязательно расскажем, в чём именно проявляется специфика продуктовой составляющей нашей команды.

Рады знакомству! 🤝
Пишите в комментариях, про какие из наших сервисов и технологий вам бы хотелось узнать больше – мы расставим акценты и подробно раскроем каждую тему.

Сегодня расскажем о персональном эмбеддинге пользователя, и как мы его строили. 

Какую проблему решали? В рассылках скапливается огромное число писем, среди которых легко пропустить интересное письмо. Персональный эмбеддинг пользователя призван решить эту проблему и подсветить такие письма. Но область применимости этого эмбеддинга намного шире)

Обучение модели начинается с выбора метрик. Из очевидных: классификация читаемых рассылок, uniformity. Но не стали останавливаться на классике и завели: 
 • sex/age классификация
 • sameUser - эмбеддинги принадлежат одному пользователю или разным
 • sensitivity к прочтениям – как меняется эмбеддинг пользователя, если изменить метку у письма или группы писем.

Как учили модель эмбеддинга пользователя? На вход трансформеру подаём последовательность векторов, состоящих из эмбеддинга письма и метки 1/0 (прочитано / не прочитано). Учим на контрастив лосс: прочитанное письмо должно быть близко к эмбеддингу пользователя, непрочитанное – наоборот.
Далее подбираем порог для близости эмбеддингов и на потоке считаем косинусное расстояние между эмбеддингом письма и эмбеддингом пользователя.

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

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

Discovery в ML

Меня зовут Настя Чумик, я продакт в команде сервисов Календарь, Заметки. Сегодня я расскажу, как в большинстве продуктовых команд Mail.ru происходит процесс Дискавери в ML.

Обычно мы либо исследуем конкурентную среду/ перенимаем опыт, либо генерим идеальные решения с чистого листа. Как правило для всех фичей, где есть какая-то «магия», может быть применим ML, и я сразу думаю, какие задачи он на самом деле может помочь нам решить. Как только идея зафиксирована – ловлю коллег из ML-команды в офисе (мы любим оффлайн) или захожу к ним в личку, спрашиваю про наши возможности. Сейчас пилотируем процесс AIFirst, в рамках которого ребята из ML становятся неотъемлемой частью продуктовой команды уже на этапе генерации идей.

Итого сначала нужно проверить реальность и оценить сложность.
Если задача реалистичная, она остаётся в беклоге решения, если нет — решение мы в принципе не рассматриваем. Оцениваем через скоринг беклога по оценке влияния, сложности и уверенности. Чтобы оценить влияние – делаем различные качественные (для подтверждения решения проблемы выбранным способом) и количественные исследования – метод напрямую зависит от задачи.

По нашему опыту качество проработки ML в продуктах растет не только за счет экспертизы в SOTA, но и с развитием ML-насмотренности у product-менеджеров. Так, например, мы активно используем удобный инструмент для обкатки идей на основе GPT-моделей на стороне продукта без участия ML-разработчиков.

Итак, магическая задача оценена и высоко приоритизирована в беклоге, мы начинаем этап декомпозиции. Здесь совместно думаем, как максимально упростить решение и проверить гипотезу на минимальных ресурсах/fakedoors. Определяем метрики успешности, сроки и уже после – идём в реализацию. Фактическое влияние на метрики определяем через AБ-тестирование в нашей внутренней системе. Заранее подготавливаем дизайн эксперимента и после его окончания смотрим, достигли ли мы ожидаемых результатов и нет ли каких-то еще неожиданных влияний (негативных или позитивных), о которых мы не подумали.

Более подробно про этапы Дискавери и Деливери ML в продукте можно почитать тут и тут на примере любимой пользователями фичи по добавлению событий из писем.

Сервисы для инференса ML-моделей

Привет! На связи Сергей Савельев из команды Антиспама Почты Mail.ru. Сегодня я расскажу вам про наши решения, связанные с realtime-инференсом ML-моделей.

С увеличением количества математических моделей в задачах Почты появилась необходимость в создании отдельного сервиса, который возьмёт на себя весь сопутствующий функционал — получение запроса, балансировка нагрузки, работа с моделями: подгрузка, обновление, а также непосредственно инференс моделей как на CPU, так и на GPU.
Таким сервисом стал Mlapi - сервис универсального инференса математических моделей. На данный момент поддерживаются модели: torch, fasttext.

Клиенты общаются с сервисом посредством GRPC, но для оптимальной работы с GPU необходимо обеспечить доступ к ресурсу только одному обработчику в единицу времени. С этой целью реализована асинхронная схема работы — заранее создаётся пул обработчиков, привязанных к выделенному ресурсу (GPU/CPU), читающих задания из асинхронной очереди.

Поток GRPC получает запрос от клиента, создаёт задачу на исполнение (а также элемент синхронизации condition variable), вставляет задачу в асинхронную очередь и встаёт на ожидание. Поток-обработчик получает задачу, выполняет инференс нужной модели и через механизм нотификации сообщает GRPC-потоку, что данные готовы. Остаётся вернуть ответ обратно клиенту.

Благодаря такой схеме, сервис обеспечивает отличную отказоустойчивость и эффективно использует ресурсы GPU — количество успешно выполненных запросов превышает 99.999%, обрабатывая при этом более 5 млн. запросов в минуту, cреднее время запроса составляет 5 мсек и эффективно использует ресурсы GPU — средняя загрузка GPU превышает 80%.

В случае работы с более тяжелыми LLM-моделями используется другой сервис инференса — gptcore, реализованный на базе библиотеки llama.cpp.

Так как время выполнения генеративных моделей зависит от размера входящего запроса, сервис реализует взаимодействие с клиентами посредством внешней очереди. Приём запросов осуществляется через очередь redis cluster queue, чем достигается отсутствие необходимости в балансировщике — каждый инстанс сервиса сам получает задание, запускает процесс инференса входящего запроса и по мере получения сгенерированного текста посредством механик Publish/Subscibe (тот же redis) публикует в канал готовые токены.

Оба сервиса написаны на C++, как и другие наши сервисы запускаются в k8s.

Напишите в комментариях: как решается проблема реализации инференса на GPU в ваших сервисах в условиях высокой нагрузки?

Same-User: NSP для нетекстовых задач

Для анализа действий пользователя в Почте мы применяем поведенческие эмбэддинги. О том, как устроено их обучение, мы рассказывали на прошлогоднем HighLoad++, а в этом посте хочется углубиться в одну частную деталь и рассказать как мы оценивали эмбэддинг пользователя на extrinsic-задаче Next Sentence Prediction (NSP) или, как мы называем ее в команде, Same-User.

Выборка для Same-User состоит из пар (L, R), где L и R — это поведенческие эмбэддинги, полученные моделью (например, трансформер). Same-User – это задача бинарной классификации. Позитивный класс состоит из пар эмбэддингов одного и того же пользователя, а негативный класс — из пар эмбэддингов разных пользователей. Идея проста: обычно пользователь имеет устойчивые паттерны поведения, поэтому эмбэддинги одного пользователя должны быть более похожи, чем эмбэддинги от разных.

Алгоритм для выборки выглядит так:
1. Берем цепочку действий пользователя X за дату T.
2. Разделяем цепочку на две части.
3. Из двух подцепочек получаем пару эмбэддингов (L, R) — это позитивная пара.
4. Чтобы получить негативные пары, перемешиваем случайным образом L и R.

В самом простом варианте код на PySpark будет повторять шаги 1-4. В пункте 4, случайное формирование пар реализовано за счет предварительного перемешивания всех строк в SparkDataFrame, а затем объединения (join) по специальному столбцу, который получили через функцию MONOTONICALLY_INCREASING_ID().

Отметим, что мы решили «резать» цепочку не ровно посередине, а в случайном месте, иначе классификатор легко переобучается: в позитивном классе обе подцепочки имеют равную длину, а в негативном — разную. Если длина исходной цепочки D, то разрез проходил в интервале [0.35 × D, 0.65 × D]; значения 0.35 и 0.65 необходимо подбирать под ваши данные. Теперь в позитивном и негативных классах подцепочки были разных длин, и можно было смело считать ROCAUC. Получилось 97%. Переобучение уменьшилось, но пристальное изучение данных выявило еще одну проблему. Наш негативный класс оказался «слишком простым» для классификатора: из-за склеивания в пары абсолютно случайных подцепочек почти всегда эти подцепочки были настолько разные, что классификатору ничего не стоило их различить.

Первая идея усложнения такая: после формирования случайных пар оставлять только те, в которых есть хотя бы N общих действий (N=1). Этот подход очень легко реализовать в PySpark, но хочется его как-то обобщить. В итоге мы стали оставлять случайные пары подцепочек, которые «близки» (но не сильно) по расстоянию Левенштейна (LevDist). Смысл такой: ранее в пары складывались очень разные цепочки, и LevDist между ними было близко к 1 (мы нормализовали расстояние максимумом из длин входных цепочек), поэтому мы решили, что необходимо оставлять только те пары, в которых LevDist < MAX_LEV_DIST < 1. В нашем случае мы выбрали MAX_LEV_DIST равным 0.85, но здесь многое зависит от ваших данных.

Для пользователей PySpark есть находка, которую мы сделали, когда задумались как считать расстояние Левенштейна. В PySpark есть встроенная функция LEVENSHTEIN(s1, s2), которая работает в разы быстрее чем самописные UDF на Python. Но есть одна проблема: эта функция умеет считать расстояние только между строками, а у нас цепочки действий. Решено было обойти это ограничение следующим образом: мы назначили каждому уникальному действию в нашем словаре (размер ~1K) уникальный символ из Unicode. Теперь цепочки действий можно было представить в виде строк. После описанного выше отбора пар цепочек мы получили ROCAUC ∈ [0.7, 0.9], в зависимости от модели эмбэддинга.

Выводы, которые полезно учесть:

> Ограничивать минимальный размер исходной цепочки, которую вы будете разрезать. На слишком коротких цепочках задача будет решаться плохо, так как классификатор не может извлечь ничего полезного из последовательности, в которой всего 2 или 3 действия.

> Вместо расстояния Левенштейна мы рассматривали другие меры сходства текстов. В том числе были варианты BLEU и ROUGE, но по итогу для простоты остановились на расстоянии Левенштейна.