В последнее время большие языковые модели (Large Language Models, LLM) стали невероятно популярными — кажется, их обсуждают везде, от школьных коридоров до Сената США. Сфера LLM растёт бурными темпами, привлекая внимание не только специалистов в области машинного обучения, но и обычных пользователей. Кто-то высказывает массу опасений насчет их дальнейшего развития, а кто-то и вовсе предлагает бомбить дата-центры — и даже в Белом Доме обсуждают будущее моделей. Но неужели текстом можно кому-то навредить? А что если такая модель приобрела бы агентность, смогла создать себе физическую оболочку и полностью ей управлять? Ну, это какая-то фантастика из (не)далёкого будущего, а про агентов нашего времени я расскажу в этой статье. И не переживайте — знание машинного обучения вам не понадобится!
Machine Learning Engineer
Realtime-матчинг: находим матчи за считанные минуты вместо 24 часов
Задача матчинга в последнее время набирает всё большую популярность и используется во многих сферах: банки матчат транзакции, маркетплейсы – товары, а Google и другие IT-гиганты проводят соревнования по решению таких задач на Kaggle.
Для маркетплейса матчинг – очень важный процесс, который решает сразу несколько задач:
1. При поисковом ранжировании из множества товаров показывать сначала самые выгодные предложения.
2. Объединять множество товаров в одну сущность и показывать предложения одного и того же товара от разных селлеров.
3. Понимать, как предложения селлеров выглядят относительно друг друга, и поощрять их дополнительными бонусами.
Сегодня мы поговорим не только о решении этой задачи, но и о способах её реализации: offline (batch) vs online (realtime). Также обсудим, как и зачем переходить от первого ко второму.
Векторное представление товаров Prod2Vec: как мы улучшили матчинг и избавились от кучи эмбеддингов
На странице любого товара на Ozon есть картинки, заголовок, описание и дополнительные атрибуты. Всю эту информацию мы хотим извлекать и обрабатывать для решения разных задач. И особенно она важна для команды матчинга.
Чтобы извлекать признаки из товара, мы строим его векторные представления (эмбеддинги), используя различные текстовые модели (fastText, трансформеры) для описаний и заголовков и целый набор архитектур свёрточных сетей (ResNet, Effnet, NFNet) — для картинок. Далее эти векторы используются для генерации фичей и товарного сопоставления.
На Ozon ежедневно появляются миллионы обновлений — и считать эмбеддинги для всех моделей становится проблематично. А что, если вместо этого (где каждый вектор описывает отдельную часть товара) мы получим один вектор для всего товара сразу? Звучит неплохо, только как бы это грамотно реализовать…
Information
- Rating
- Does not participate
- Date of birth
- Registered
- Activity