🔗 Работа над ML-проектами полна сюрпризов. Вот чек-лист вопросов, которые стоит задать себе ещё на берегу
Привет, я Даня Яковлев, руководитель разработки поиска Маркета. Я хочу помочь вам избежать авантюрных идей, которые в теории звучат хорошо, а на деле превращаются в тыкву по ходу проекта! Итак, начнём.
↔️ Какую задачу мы решаем на самом деле?
Расплывчатые цели редко приводят к хорошему результату. Например, как-то к нам пришли с запросом: сделайте выдачу релевантнее, пользователи жалуются, что им сложно искать товары. На деле оказалось, что трудности возникают не из-за релевантности (с ней как раз всё в порядке), а из-за слабой персонализации. Поэтому любые цели стоит сперва почелленджить, чтобы докопаться до сути. Вполне может оказаться, что задача на самом деле стоит другая, и понять это нужно как можно раньше.
↔️ Что будет критерием успеха?
Измеримые метрики — наше всё. Когда мы начинали заниматься персонализацией поиска, у нас не было способа оценить выдачу. Субъективные впечатления не сочетались с бизнес-метриками. Когда мы поднаторели в этой игре, то стали оптимизировать retention, повторные покупки и так далее. И дела сразу пошли в гору!
↔️ Какой у нас бейзлайн? Точно ли тут нужен ML?
Иногда простые эвристики могут дать результат не хуже сложных моделей. А их внедрение кратно дешевле и быстрее. Далеко не все ленты смогут одолеть простую советскую фичу «показать историю пользователя».
↔️ Как и на чём мы будем обучаться?
Когда мы запускали на Маркете fashion, у нас не было данных для этого среза поиска. Мы сформировали два подхода к решению этой проблемы. Во-первых, можно было обучить ранжирование по внешним источникам. Во-вторых, просто запуститься и отсортировать товары в выдаче по текстовым эвристикам и популярности, что намного проще. И уже дальше копить информацию, чтобы потом обучать по ней модели. Второй подход одержал верх. Хотя данных и было меньше, они оказались чистыми и попадали ровно в нужную задачу. Качество оказалось важнее количества!
↔️ Какие проблемы могут возникнуть в проде?
Важно не забывать про масштаб. Несколько лет назад мы внедряли новый класс нейронок в наш высоконагруженный поиск. На бумаге во время ресёрча всё было отлично. Но непосредственно при внедрении мы столкнулись с проблемами: не хватало GPU для инференса и памяти под полученные большие эмбеддинги. Пришлось делать шаг назад и начинать сначала с моделями поменьше.
Мы ловили и более сложные проблемы. Например, у нас есть классификатор категории запросов. После того как мы его обучили, он честно работал. Но со временем качество стало медленно деградировать. Оказалось, что категории на Маркете изредка меняются. Мы добавили регулярное переобучение, и всё стало хорошо.
↔️ Достаточно ли гибкое решение, которое мы выбрали?
Почти всегда в проектах возникают фичи за рамками первоначального плана. Нужно учитывать эти риски при проектировании.
Типичный кейс: приходит жалоба на то, что более дорогой товар в выдаче выше, чем дешёвый. С ним же приходит и решение скорить выше более дешёвые товары. Это даже может сработать без серьёзных поломок поиска — но вскоре к вам придут с предложением бустить товары с высоким рейтингом. После нескольких итераций ваша поисковая система начинает разваливаться из-за жадной оптимизации.
Правильным решением было бы все эти параметры складывать в ML-ранжирование, которое оптимизирует полезные действия пользователей, а не додумывать самим, что хорошо, а что плохо.
Подписывайтесь:
💬
@Yandex4ML📹
@YandexML