Еще в прошлом году у нас выступал Артем Попов, тимлид команды VK Performance Advertising. Делимся с вами расшифровкой эфира и записью.
Меня зовут Артем, я – руководитель performance advertising в ВК. Наша команда занимается тем, что, с одной стороны, делает рекламу в ВК эффективнее, выгоднее для рекламодателей, интереснее для пользователей. Это большая продуктовая цель.
С другой стороны, технически, мы – команда ML-инженеров, довольно обычных разработчиков, которые много времени занимаются задачами, связанными с data science и ML. Сегодня я хочу поговорить про эти две темы, потому что обе они мне интересны, я о них люблю поговорить. Я очень рассчитываю на то, что у нас будет живое общение; если кто-то смотрит трансляцию, будет интереснее, если вы будете писать вопросы.
В целом, я хочу разделить нашу беседу на два блока. В первом я расскажу о разных задачах, которые встречаются в рекламе в пересечении с data science. То есть, почему реклама может быть интересной областью для ML-специалиста, для специалиста в области data science. С другой стороны, я хочу поделиться своим опытом перехода в инженерный ML-проект, тем, чему я учился те четыре года, которые занимался ML в рамках инженерной истории. И рассказать про то, какие вещи встречаются в больших компаниях, но про которые не рассказывают на разных курсах; какие есть скиллы, которым тяжело научиться, когда ты учишься data science или ML в рамках университета или онлайн-образования. Постараюсь уделить каждой теме по полчаса.
Сначала расскажу про рекламу, рекламные технологии, computational advertising как поле для исследований, научной и инженерной деятельности – то есть, область знаний; какие задачи там бывают, и почему прикольно ими заниматься, когда есть NLP и прочие хайповые штуки, а про рекламу не так часто говорят.
Общая задача звучит так: у нас есть набор рекламодателей. Ими могут быть любые пользователи, которые хотят продвинуть знание о своем продукте, своем бизнесе. У них у всех есть свои собственные, различные цели. Кто-то желает просто показать свою рекламу как можно большему количеству человек; например, у условной «Кока-колы» задача — сделать так, чтобы все знали про их бренд, чтобы все помнили, что такой напиток есть, что сейчас новый год, и нет другой альтернативы, кроме этого напитка, если вы идете в магазин. Другой хороший пример — Fairy: сколько вы знаете других моющих средств, кроме него? Это все – brand awareness; крупные рекламодатели ставят цель – сделать так, чтобы у всех в голове осталось знание о том, что существует определенный продукт.
Есть другие цели. Например, более прикладные, так называемые performance-цели. Это когда рекламодатель хочет, чтобы вы перешли за рекламой и сделали какое-то действие. Например, зашли на сайт и оставили заявку на кредит. Или купили что-то в интернет-магазине. И так далее.
В целом, задача рекламы – приносить новых пользователей какому-то бизнесу (так называемых лидов) и делать так, чтобы эти пользователи делали что-то полезное для рекламодателя и приносили прибыль его бизнесу.
У нас есть площадка – место, где мы позволяем показывать рекламу. В случае с ВК это лента; в случае какого-то другого сайта это может быть, например, баннер. Цель площадки – заработать денег на рекламе, она продает внимание пользователей за деньги. Благодаря этому ВК остается бесплатным проектом; можно было бы придумать другие модели монетизации, но рекламная модель хорошо работает для подобного сервиса.
Пользователи обычно не хотят видеть рекламу: они пришли на сервис не для этого. Но получается, что рекламный контракт работает именно так: пользователь платит своим вниманием за пользование сервисом. Поэтому наша цель как рекламной сети – сделать так, чтобы пользователи не бесились, реклама их не отталкивала и не отпугивала.
Было бы совсем шикарно, если бы реклама оказывалась полезна для пользователя – то есть, продвигаемые бизнесы и записи оказались так же интересны пользователю, как обычный контент. Это вообще идеально.
У нас есть три силы: пользователь, рекламодатель и площадка. Мы должны наладить между ними такое взаимодействие, чтобы каждая из них выполняла свои цели. Представьте: вы заходите на сервис ВК, открываете ленту – и видите то место, куда мы вставляем рекламу. Есть много рекламодателей, которые претендуют на этот ресурс и хотят, чтобы показали именно их рекламу – но как выбрать ту рекламу, которую нужно показать в каждый конкретный момент каждому пользователю?
Стандартный способ, который активно используется в рекламе – это онлайн-аукцион. Возможно, вы видели различные варианты аукциона в реальной жизни или на Ebay, например: это может быть ситуация, когда каждый может сделать ставку. Один пользователь говорит — я ставлю 10 рублей, приходит другой – ставит 20, третий – 100, и так далее. Но аукционы рода «кто больше заплатил, тот и выиграл» непрактично проводить в интернет-среде, поэтому используются аукционы закрытого типа. В таком случае каждый из участников делает ставку молча. Образно говоря, все бумажки со ставками складываются в котел, а потом кто-то приходит, разбирает их, находит бумажку с самым большим числом и говорит – ты победил.
Допустим, есть два рекламодателя – например, Nike и Coca-Cola. Один из них готов заплатить за каждый показ 5 копеек, а другой – 10. Второй выигрывает, и дальнейшее развитие истории зависит от типа аукциона. В рекламе встречается два основных типа: аукцион первой и второй цены. В аукционе первой цены победитель платит ту цену, которую он назвал. Например, Coca-Cola говорит: «Я заплачу 10 копеек», не видя ставок других пользователей; аукцион говорит – ОК, 10 копеек. Nike говорит: «5 копеек», Coca-Cola выигрывает и платит 10 копеек.
Однако есть еще аукцион второй цены: в этом случае победитель должен заплатить ровно столько денег, сколько нужно, чтобы победить все остальные ставки. В нашем случае может использоваться шаг в 1 копейку, например. Представьте ситуацию: приходят те же Coca-Cola и Nike. Coca-Cola говорит: «Я готов заплатить 100 рублей за показ», а Nike говорит: «Я готов заплатить 1 копейку». И Coca-Cola будет очень обидно узнать о том, что она могла бы победить, заплатив 2 копейки вместо 100 рублей. Аукцион второй цены считается более честным по отношению ко всем участникам.
Исходя из этого, для рекламодателя очень важным считается определенной свойство: всегда выставлять на аукционах честную максимальную цену, которую ты готов платить за показ. Это необходимо для выстраивания любой грамотной стратегии торговли.
В аукционе первой цены нужно придумывать хитрую стратегию, думать – вот, такие-то рекламодатели могут поставить столько-то, но в аукционах второй цены этого делать не надо. Каждый ставит ту ставку, которую готов заплатить по максимуму. Если ты победил – ты платишь ровно столько или меньше; если нет – значит, ты не готов был платить больше. Это великолепное свойство такого типа аукционов, которое распространилось из теории на повсеместное использование в рекламных системах.
Однако, не тут-то было. Казалось бы, с точки зрения теории, аукцион второй цены очень хорош, и его свойства позволяют ему быть очень практичным. Но на деле, когда мы сталкиваемся с реальными системами, оказывается, что есть несколько моментов, обеспечивающих популярность аукционов первой цены – почему-то люди предпочитают использовать именно их, а не аукционы второй цены. Один из двух главных моментов, про которые хочется сказать – это то, что аукцион второй цены непрозрачен. То есть, когда рекламный аукцион устраивает какая-то площадка, о которой вы ничего не знаете – вы просто участвуете как рекламодатель – она говорит вам, что ваша ставка в (допустим) 10 копеек выиграла, и вы должны заплатить вторую цену – пусть это будет 9 копеек. Эта вторая цена непрозрачна; непонятно, откуда она взялась. В целом, площадка может легко обманывать рекламодателя, делая так называемые фейковые ставки. Есть и честные механизмы дополнительных ставок – например, “reverse price”: вы заявляете, что конкретный аукцион нельзя продать дешевле, чем за 9 копеек, и появляется такая честная ставка. Но прозрачность очень важна, и ее отсутствие отталкивает рекламодателей. Когда вы не знаете, что происходит под капотом рекламной системы, снова приходится придумывать какие-то стратегии: нельзя просто брать и использовать подход с установкой только тех цен, которые вы готовы заплатить.
Второй момент – это то, что аукцион второй цены хорош в идеальной обстановке, когда одновременно происходит только один аукцион. В реальной рекламной системе их происходят миллионы в секунду, условно. В таких условиях уже нужно придумывать стратегии, и идея о том, что у рекламодателя всегда есть простая и готовая стратегия для идеальной торговли на аукционе, ломается.
Хочется рассказать о моментах, возникающих на фоне задач дизайна аукционов – как можно дизайнить их интереснее, полезнее и так далее. Я хочу упомянуть два пункта. Во-первых, в аукционе вроде бы все должно происходить, исходя из максимальной ценности, максимального количества денег, которые заработает рекламная сеть, продавая место; однако на деле ценность, которая продается в аукционе, может для площадки выражаться по-разному – не только в сумме, которую готов заплатить рекламодатель. Например, нам очень важно, чтобы пользователей не бесила наша реклама – желательно, чтобы она была полезна для них. В рамках задачи дизайна аукциона приходится придумывать дополнительные метрики для ранжирования рекламы. Получается ряд метрик: ожидаемая прибыль, вероятность негативной реакции пользователя и так далее.
Второй вариант задачи – это «нежадный» аукцион. В этом случае мы понимаем, что мы, как рекламная сеть, могли бы заработать больше, если бы мы не продавали всегда рекламное место победителю, а распределяли их между всеми рекламодателями так, чтобы по максимуму потратить все их рекламные бюджеты, при этом оставляя какую-то честность в рамках аукциона. То есть, если у нас есть несколько рекламодателей, и один из них богаче остальных и постоянно выкупает аукционы, то, возможно, следует не отдавать ему всегда ставку победителя. Такая «задача о рюкзаке» — может быть, вы помните такие из курсов по программированию или алгоритмам структуры данных, если у вас была такая история. Это очень прикольная задача, ею очень интересно заниматься, и по ней есть научные статьи.
В ВК мы еще только подбираемся к этой задаче; задач у нас очень много, и еще одна большая часть задач, которые есть в рекламе, уже стоит ближе к ML. Из-за того, что мы должны выполнять различные цели рекламодателей, нам нужно предсказывать, с какой вероятностью пользователь совершит то или иное действие, чтобы использовать это знание в формировании стратегии ставок на аукционе.
То есть, рекламодатель говорит: я хочу как можно больше покупок в моем магазине, потрать мой бюджет максимально хорошо. Мы, как рекламная площадка, думаем, как выделять тех пользователей, которые с высокой вероятностью купят что-то в магазине. Возникает типичная ML-задача. Бинарная классификация: ‘1’ – пользователь перешел по рекламе и что-то сделал хорошее (купил), ‘0’ – пользователь проигнорировал рекламу. Нам надо, исходя из этой задачи, построить бинарную классификацию, где на выходе мы используем вероятность полезного события как кусочек дальнейших вычислений того, какую ставку мы будем использовать на аукционе. Задача звучит очень банально в терминах ML – вроде бы, бери и делай. Но в реальной жизни у такой задачи бывает множество сложностей, и я расскажу о нескольких. Главная из них – это то, что реклама обычно является высоконагруженным проектом. Как по данным, так и по нагрузке. Нужно очень быстро отвечать на запрос. Окно, допустим, в 100 миллисекунд – и нужно успеть ответить. Исходя из этого, на нас накладываются определенные ограничения – конкретно, на то, как – инженерно — могут работать те модели, которые мы используем для предсказания рекламы. Можно придумать много прикольных штук, сделать сложные нейросети, которые через несколько слоев выделяют нелинейные взаимодействия между фичами, но в жизни требуется, чтобы это все работало очень быстро.
Обучается это на больших объемах данных. Задача получается высокомасштабная, с терабайтными датасетами. Исходя из этого, обычно приходится заниматься такими вещами, как распределенные вычисления, распределенное обучение модели, думать о том, какие модели вообще использовать. В рекламе традиционно используются линейные модели, типа логистических регрессий или градиентного бустинга; иногда переходят на более крутые штуки, вроде factorization machines. То есть, выбор моделей велик, но обычно используются довольно простые – из-за большой нагрузки.
Другой, близкий к ML момент: у нас используются данные, которые экстремально несбалансированы по фидбеку. На 10000 нулей приходится одна единица. Как в этих условиях обучать машины ML – это хороший вопрос. Приходится использовать разные трюки; основной – это именно формулировка задачи: не пытаться предсказывать, будет ли клик (покупка) или нет, например, а использовать подходы, связанные с вероятностями, сглаживать по максимуму данные, у которых низкая кардинальность, и так далее. Многое можно придумать, но сложность в том, что в задаче редко происходят позитивные события.
Когда вы переходите по рекламе и что-то покупаете, вы не всегда делаете это сразу. То есть, очень часто целевые события, которых хотят рекламодатели, происходят с большой задержкой. Это может быть не только покупка – например, это может быть регистрация в игре и прокачка персонажа до 10 уровня, или одобрение заявки на кредит. Такие вещи могут происходить через несколько дней. И, когда нам нужно обучать модели, которые, по объявлению, прямо сейчас должны сказать, что пользователь что-то сделает, но, по факту, позитивный фидбек мы получаем только через несколько дней после того, как что-то произошло, и это создает дополнительные проблемы. Чтобы разбираться с этими проблемами, есть несколько разнообразных решений, которые придумали в науке и в практике. Такая забавная сложность.
Еще один момент: когда пользователь видит рекламы определенных продуктов, он может соприкасаться с ними из различных маркетинговых каналов. Например, вы вышли на улицу – увидели рекламный щит «Такси ВКонтакте»; стали листать ленту – там тоже реклама «Такси ВКонтакте», зашли в другой сервис – и там тоже реклама «Такси ВКонтакте», от рекламного сервиса Яндекса или Google. Вы говорите – да я понял уже, ставите приложение. И после этого Яндексу, ВК, Google, рекламному щиту нужно разобраться, чье участие в этом процессе – в полезном для рекламодателя действии – составляет сколько процентов.
Этот процесс называется «атрибуция» — вопрос распределения того, какой контакт с рекламодателем настолько сильно повлиял на ваше решение сделать целевое действие. Обычно используются простые модели – например, «last click attribution»: последняя реклама, на которую вы кликнули, получает все призы. Но тогда оказывается, что заниматься первым «холодным контактом» — показом рекламы пользователю, не знакомому с продуктом – невыгодно. Исходя из этого, есть много разнообразных моделей ML (в том числе), которые позволяют лучше распределить профит с показов. Там используются, в том числе, фишки типа attention, некоторые более интересные штуки из нейронных сетей. Прикольная задача. И ее цель, по итогу – торговаться на аукционе лучше, правильнее, корректнее и так далее.
Чем лучше вы понимаете, кто повлиял на итоговое решение о покупке, тем лучше вы понимаете, сколько в каждый момент поставить. По итогу вся индустрия идет к пониманию того, что работать с предсказанием вероятности того, что вы что-то купите, менее эффективно, чем работать с идеей степени влияния на решение о покупке. Возможно, вы и так уже были готовы купить настольную игру, на сайт которой вы зашли. Но интернет-реклама начинает вас догонять. Может быть, этой рекламы бы и не было, если бы все изначально решили, что вы и так купите эту игру, и дополнительная реклама не нужна – вы уже сделали свое решение. Я вспоминаю термин «incrementality testing», и все это еще связано с такой областью ML, как «causal inference». То есть, мы переходим от задачи предсказания вероятности совершения целевого действия на предсказание влияния – то есть, разницы вероятности того, что вы купите, увидев рекламу, минус того, что вы и так уже купили. Это тоже очень прикольный переход, переход на новую идею о том, как работать, как предсказывать какие-то события.
В целом, в рекламе очень много задач, и почти все они следуют из исходного желания выполнить задачу рекламодателя. Цель «Я хочу как можно больше покупок в моем магазине» превращается в последовательность ставок на аукционе, потому что все рекламодатели рубятся на аукционе за показы. Это стратегия. И нам нужно сделать максимально классный переход от исходной цели к последовательности ставок. Из этого следует желание понимать поведение пользователей, извлекать коммерческие интересы, автоматически таргетировать рекламу, собирать креативы – это то, как реклама выглядит – и так далее.
Если кому-то интересно узнать про это поподробнее – у меня есть выступление на митапе, там я подробно рассказываю о том, что data scientist-у делать в рекламе, и почему работа над ней может быть интересной. Для меня это оказалось открытием. Изначально, когда я только пришел в индустрию, я думал – ну, реклама, что интересного. Прошел первый, второй, третий год – и я осознал, сколько здесь классных задач, и как этим интересно заниматься с точки зрения инженера.
Теперь я перейду к ML in production. Вот вы прошли курсы по машинному обучению, или проучились в университете. Вы – отличный специалист по Kegel, допустим, и офигенно щелкаете задачи по анализу данных на соревнованиях. Вы приходите в реальную компанию, где итеративно, последовательно развивается большой продукт. И здесь происходит некоторый слом. Оказывается, что у вас просто нет многих скиллов, которыми хотелось бы владеть на тот момент, когда вы приходите в индустрию. Вас никто этому не учил и не объяснял, как это работает в реальности; какие в индустрии сложности, как это не похоже на решение задач с четкой формулировкой. Если в области программирования про это еще рассказывают довольно много, то в области data science – недостаточно.
С какими трудностями сталкиваются новички в продуктовых командах, которые долгое время работают над одним и тем же продуктом – например, делают рекламу в ВК эффективной? Под «новичками» я имею в виду себя, в том числе; я четыре года этим занимаюсь и до сих пор чувствую себя нубом. Это очень сложная вещь, и в ней интересно разбираться.
Первый момент, про который хочется сказать – это желание приступить к имеющейся задаче сразу с каким-то крутым прогрессивным методом, который можно найти в науке; желание придумать космолет, который сразу все сделает классно. В реальной жизни, в области продуктовой разработки, data science – это место, где мы очень слабо можем предсказывать, какой метод в итоге сработает. Очень тяжело работать с изначальными продуктовыми требованиями, потому что вы не знаете путь решения проблемы.
У вас есть формулировка задачи: например, сделать систему автоматической модерации, которая должна решать какие-то изначальные проблемы. Можно побежать и найти какую-то супер-топовую статью, в которой задача решается идеально, накрутить трансформеров. А можно сделать простую эвристику, которая будет смотреть на то, сколько раз мы одобряли данного рекламодателя ранее, брать долю этого числа, сравнивать с 70%, например, и говорить: этот часто раньше одобрялся. Такая штука может сразу очень сильно помочь бизнесу, принести полезную информацию. А сложная система делается долго, и не факт, что она окупится. В data science надо очень быстро приходить к такой идее: вы постоянно работаете в режиме гипотез, не знаете, что сработает, и для того, чтобы сокращать риски и как можно быстрее доносить ценность итоговому пользователю и бизнесу, нужно заниматься задачами от простого решения к сложному. Зачастую – заниматься, начиная с эвристик, без всякого ML – для него может и не быть данных. Это может коробить data scientist-а, которому интересно крутить нейронные модели. Но без этого не получить изначальный baseline – шажочек, от которого можно отталкиваться. Можно очень долго заниматься тем, что вообще не сработает.
Самая сложная вещь и необычность работы в индустрии – это то, что после того, как вы сделали модель, выкатили ее в production, ее жизнь только начинается. Ее нужно активно поддерживать и менять. С моделью, пока она живет, происходит большое количество разнообразных изменений. Во-первых, есть такая вещь как training serving skew.
По-простому: если модель работает в production на определенных данных, или множестве генеральных совокупностей задач, которые ваша модель должна решать – а обучалась она на других данных, полученных другими способами – то в этом месте часто происходят ошибки, и модель начинает плохо работать. В идеале, нужно выстраивать систему, в которой модели при аналитике и при первоначальной подготовке обучаются на тех же самых данных, на которых они будут работать в production.
Во-вторых, в любой момент может какой-то признак, или сама модель, начать работать неправильно, неадекватно. У вас есть хранилище, в котором хранятся признаки; что-то поменялось, вместо нулей начали литься null, вместо «-1» стали возвращаться другие значения; или кто-то умножил эти значения на 100, потому что думал, что это проценты, а не доли. И ваша модель резко начинает работать неправильно. Вам нужно эти изменения как-то замечать. Самое прикольное качество ML-модели – это молчаливая ошибка; она никогда не скажет, что что-то пошло не по плану – она всегда выдаст какой-то результат, в зависимости от того, что вы ей дали. Garbage in, garbage out. За этим надо как-то следить. Исходя из этого, есть гигантское количество моментов, которые нужно отслеживать во время работы модели в production. Нужно выстраивать систему мониторинга, следить, чтобы распределение признаков сильно не менялось, и так далее. Надо понимать, что модель может в любой момент выдать полную дичь, и как-то жить в этих условиях. Что, если эти результаты напрямую снимают деньги с наших пользователей – делают ставки на аукционе рекламы, или торгуются на бирже, или еще что-то? Есть большое количество способов того, что с этим делать, но про это в первую очередь важно думать.
Как, исходя из этого, меняется жизнь data scientist-а, который приходит в среду, где надо итеративно развивать модели? Как мне кажется, нужно в первую очередь быть хорошим инженером, а уже во вторую – хорошим researcher-ом. Потому что твой код и твои выводы, инсайты, которые ты получаешь в ходе исследования и анализа, твои модели – все, что является продуктом твоей работы data scientist-а – будет использоваться не 2, и не 10 раз. Много людей будет смотреть на то, как выстроены эксперименты, как получены результаты, почему, где, как что работает, и как это используется в production. Поэтому то, чего по максимуму не хватает в людях, которые приходят в индустрию с нуля – например, из университета, увлекшись темой data science, или аналитики, или ML – это инженерные скиллы. В первую очередь data scientist – это подвид разработчика. Он тоже работает с кодом, он тоже работает с чем-то, что работает потом в production в изменяемой среде, что используют люди. Твой код будут читать. Тебе нужно будет придумывать эффективные, хорошо поддерживаемые и тестируемые решения. Это та часть, которой большому количеству кандидатов не хватает. Поэтому, если вы – начинающий человек в data science, уделите большое внимание скиллам разработчика. Тому, как писать эффективный, понятный, хорошо поддерживаемый код; инженерным решениям для того, чтобы эффективно выстраивать процессы обмена данными. Это все вам сильно поможет в карьере.
Второй совет и вторая штука, которая отличает крутых data scientist-ов от тех, которым тяжело работать – это погружение в продуктовый контекст и в инженерную часть окружения вашей модели. Допустим, вы разрабатываете модель, и вам, как data scientist-у, легко сказать: «Мое дело – разрабатывать модель, все остальное – за пределами моей ответственности. Я обучаю модельки, это мое дело. Встроит их бэкэндер, подготовит данные дата-инженер, оттестирует тестировщик, продукт-менеджер решит, как применять». Но огромное количество выводов и способов того, как сделать модель круче и ценнее, находится за пределами процесса разработки самой модели. Пример: если вы ранжируете поисковую выдачу, то вы ранжируете документы, поступающие извне; есть какой-то отбор кандидатов. Если вы знаете, как этот отбор работает, то вы можете легко понять, что узкое место в работе – это не то, что модель плохо работает, а то, что на вход подаются неправильные, неинтересные, неполные документы. С другой стороны, если вы знаете, что в вашем продукте ваша модель может, при определенных обстоятельствах, работать не так, как хотелось бы, но сделать эту работу лучше очень сложно, то можно поменять продукт под модель. Можно сказать: теперь продукт устроен по-другому, теперь не пользователь вызывает модель, а модель вызывает какой-то автоматический инструмент, который координирует несколько параметров, за которыми пользователь не может следить. Идея в том, что можно менять продукт под модель, а не наоборот. Если вы погружены в эти области, то вы, как data scientist и ML-инженер, можете приносить колоссальную прибыль и пользу вашему продукту и вашим пользователям.
Возвращаясь к вопросу о том, что ML – это сфера предположений. Мы никогда не знаем, как конкретно прийти к классно работающему продукту, нам приходится пробовать разные пути к финальному решению. Поэтому нужно немного по-другому выстраивать workflow работы. Зачастую людям, особенно инженерам в начальные периоды развития карьеры, кажется, что всякие менеджерские фишки – SCRUM, Agile – это все фигня, и они не работают. Хотя зачастую они действительно не работают, потому что используются в неправильном контексте. Например, если вы когда-нибудь попадете в data science-команду, работающую по SCRUM, вам станет тяжело и больно. Внезапно окажется, что рисерч стал тяжело прогнозируемым, и вы не будете знать, как вы придете к результату, а тут – двухнедельные итерации, еще что-то, в общем, менеджмент генерирует ненужную фигню. Рабочие процессы, в рамках которых вы работаете, должны помогать вам, а не мешать. То есть, когда в data science берут и прикладывают методы из обычной софтверной разработки, это не всегда получается эффективно.
Поэтому я хочу отдельно сказать: если вы работаете data scientist-ом, и вам приходится взаимодействовать с разными людьми – заказчиками, коллегами, кооперироваться по работе – то вам хорошо бы озаботиться пониманием того, как лучше выстроить процесс совместной работы, самоорганизованную деятельность команды. Хороший способ понять, как это делать – я бы рекомендовал обратиться в сообщество, которое называется LeanDS. Там собрались такие люди, которым интересно понять, как лучше выстраивать процессы работы над ML-задачами в условиях продуктовой разработки. Оттуда можно узнать много прикольных штук, которые люди уже придумали, и разные специалисты используют в разных компаниях. И из того, что я бы посоветовал, в первую очередь надо перейти к подходу, когда вы все задачи формулируете через продуктовые гипотезы. Когда вы не знаете, что принесет результат, но прикидываете: я думаю, что такая-то штука поможет настолько-то продвинуть пользовательские задачи, прокачать метрики, и за такое-то время это можно проверить. С такими гипотезами гораздо проще работать. Исходя из такого непонятного флоу работы, где очень тяжело прогнозировать, сколько времени займет ваша задача, когда вы придете к результату, и каким способом, на мой взгляд, очень хорошо работает Kanban. Я не буду долго про это рассказывать, просто посоветую: попробуйте посмотреть на сообщество LeanDS. Посмотрите их материалы. Я думаю, всем, кто работает в data science и сталкивается с процессами, которые перекочевали из обычной разработки, будет интересно понять, что можно делать по-другому и как использовать процессы в свою пользу.
В качестве итога расскажу, чего не хватает ребятам, которые на старте карьеры приходят заниматься задачами data science, и как вы можете стать круче как специалист и повысить шансы на получение работы в том месте, которое вам будет нравиться.
Во-первых, как я уже говорил, инженерные навыки для data scientist’а очень важны. Не менее, чем навыки, связанные с ML, анализом данных, теорией вероятности и так далее. В первую очередь желаю вам быть крутым инженером, во вторую – рисерчером. Второе: очень многим не хватает четкого скилла переформулирования бизнес-задачи в data science-задачу. Это отдельный скилл. Это ситуация, когда нужно понять, чего конкретно от вас хочет заказчик – ну, назовем так человека, который хочет, чтобы что-то круто работало. Возвращаясь к примеру с автомодерацией: чего конкретно он хочет? Ведь задачу автомодерации можно поставить очень по-разному, с разными конкретными вещами, которые мы хотим сделать лучше в нашей системе. Исходя и задачи, по-разному формулируется data science-задача; исходя из data science-задачи, по-разному формулируются оптимизируемые метрики, способ подбора датасета, оценки качества и так далее. Этот скилл очень ценен для всех data scientist-ов. Допустим, заказчик говорит, что у него модераторы не справляются с потоком обработки задач на проверку того, хороша ли реклама или ее нужно забанить с определенной тематикой. Потом вы узнаете, что есть множество разных причин бана, и при модерации надо четко их описывать, чтобы рекламодатель мог исправить рекламу. Исходя из этого, вы решаете, что надо делать какую-то многоклассовую классификацию, которая будет генерировать текст объяснения причины, и задача будет очень сложной. Но подождите – может быть, задачу можно переформулировать по-другому. И оказывается, что можно концентрироваться не на том, чтобы отклонять рекламу, а на том, чтобы выбирать нужную рекламу. Если реклама хорошая – ее можно просто пропускать, если плохая – ее можно отдавать живым модераторам, и никакого объяснения не нужно генерировать. Исходя из этого, вы понимаете: если нужно сконцентрироваться на том, что хорошее, что можно пропускать, то надо понять, как управлять этим делом – этим потоком объявлений, который будет проходить через вашу систему. Вы понимаете: ага, исходя из этой задачи, я могу выбрать ROC AUC как подходящую мне метрику, она хорошо описывает зависимость между точностью работы модели и количеством объявлений, которое будет автоматически проходить через нашу систему. И так далее. То есть, исходя из этого диалога условного заказчика и вас, как специалиста, вы можете сильно упростить свою задачу, хорошо понимая, как переформулировать бизнес-задачу в data science-задачу.
Я хотел бы рассказать об еще одной штуке, которая очень помогает. Это понимание того, какие конкретно сигналы передаются в модель, которую вы разрабатываете, в виде признаков, и как она их обрабатывает. Это скилл, который напрямую относится к компетенции команды ML-разработчиков. Почему-то очень многие кандидаты, по моему опыту, исповедуют подход «ML все съест» — положил все в градиентный бустинг, и так сойдет. Я утрирую, но, в целом, очень классно, когда вы четко понимаете, что признак, который вы используете, несет в себе ровно ту информацию, которую вы передали, а не ту информацию, которую вы планировали передать.
Например, вы решили, что хорошим показателем того, что пользователь реагирует на рекламу, будет соотношение кликов и показов. То есть, берем количество увиденной рекламы за все время и количество кликов на рекламу, делим одно на другое и получаем показатель пользователя. В одном случае он говорит, что пользователь любит кликать на рекламу, в другом – что он вообще не кликает. И передаем это число в нашу модель – градиентный бустинг или линейную регрессию. Потом может возникнуть мысль: у модели же нет способа отличить тех пользователей, по которым у нас много статистики, от тех, кого мало. Единица в показателе может означать не то, что пользователь всегда кликает на рекламу, а то, что у него был всего один показ. Возникает вопрос: как представить эту фичу в таком виде, чтобы модель отличала большое количество статистики от малого? Первое, что приходит в голову – положить в модель количество показов объявления. Можно просто положить количество показов, но зависимость нашей уверенности в статистике от количества показов рекламы у пользователя – нелинейная. Получается, что нужно класть не просто показы, а квадрат или логарифм показов. Потом оказывается, что, если у нас линейная модель, то эти две фичи никак друг с другом не взаимодействуют. Нельзя будет делать схемы вида «если у пользователя такое-то количество статистики, то мы верим ей на столько-то, используем фичу с таким-то весом». Такие связи линейная регрессия не умеет строить, но градиентный бустинг умеет. Или можно переформулировать фичу. Можно вместо сырой статистики сглаживать ее, использовать подходы из байесианских переходов, добавить какое-то априорное знание того, как пользователи кликают в среднем, и с помощью определенной формулы их смешать. И так далее. Получается, что очень важно понимать, какой конкретно сигнал вы передаете в качестве признака.
И второе – очень важно знать, как этот признак будет использоваться в модели. В линейной регрессии он будет использоваться по одному, в градиентном бустинге – по-другому, а, если это нейронная сеть, то она работает с другим видом данных, и как там работает контекст.
Необязательно знать, как конкретно работает модель, но нужно интуитивное понимание того, что возможно, а что – нет. Это классный скилл для ML-специалиста. Если вы спросите меня, как работает какой-нибудь конкретный алгоритм в градиентном бустинге, то мне будет тяжело объяснить в деталях, но на пальцах у меня это получится. И в большинстве практических ситуаций этого достаточно, чтобы эффективно пользоваться инструментом.
Под конец хочется посоветовать всем использовать в реальной жизни, в продуктах такой итеративный подход, когда вы двигаетесь от простого к сложному. Начинаете с простых гипотез, которые быстро проверяются, и потихоньку приходите к тем самым сложным, интересным научным статьям. А тогда бейслайн уже готов, и можно уже статью написать для KDD, например.
Я хочу сказать еще – может быть, мне помогут; у меня есть два выступления на митапах. Одно посвящено тому, какие data science-задачи можно делать в рекламе (и вообще, почему data science-специалистам рекламные технологии могут быть интересны как плацдарм для применения своих скиллов с интересными инженерными вызовами). А второй – рассказ про ловушки, в которые мы попадали как команда ML-разработчиков системы, про то, как мы из них выбирались, и то, как вам не попадать в те же ловушки, в которые попадали мы из-за отсутствия накопленного опыта. Хочется этим опытом поделиться. Я думаю, тут можно много полезных вещей для себя выяснить.
И еще — до этого я говорил про сообщество LeanDS, посвященное data science-процессам, управлению проектами data science в ML. Тоже очень советую посмотреть на их материалы, ребята делают очень крутые штуки.
Случалось ли строить полную модель воронки продаж?
На самом деле, нам не случалось этим заниматься. Но здесь очень важно, чтобы внешний рекламодатель все очень хорошо настраивал. Поэтому воронками продаж хорошо заниматься, когда вы – data scientist со стороны рекламодателя. Допустим, вы работаете в крупной компании, которая работает с большим количеством маркетинговых каналов, и пытаетесь построить аналитику, которая позволит вам хорошо понять, как конкретно разные маркетинговые каналы работают, как хорошо выстраиваются воронки продаж и так далее. Нам же, со стороны ВК как системы для рекламодателей, при работе с такими штуками очень важно, чтобы у рекламодателя все было хорошо настроено. Чтобы рекламные пиксели всегда отдавали правильную информацию о том, как пользователь зашел на сайт, добавил что-то в корзину и купил. И дальше мы должны использовать эту информацию для того, чтобы делать рекламные стратегии лучше и эффективнее. Хочется этим позаниматься; мы практически этим не занимались, потому что настройка таких систем зачастую тяжело дается для рекламодателя. Наверно, проще заниматься этим, когда есть полный контроль.
И такой вопрос: как связать сущности (задать признаки) при построении модели?
Например, посетитель сайта → клиент
Наверно, хорошо просто исходить из какой-то предыдущей активности пользователя. В целом, это делается разными способами; я могу рассказать про один, который используется при построении рекламных систем, называется он look-alike. Возможно, вы про него слышали. Это ситуация, когда мы говорим: вот пользователи, которые посетили наш сайт, и вот те, которые что-то купили. Давайте посмотрим на то, какие пользователи наиболее похожи на тех, которые что-то купили, и меньше похожи на тех, кто ничего не сделал. Когда мы обучаем такую модель, где «1» — это те, кто купил, «0» — те, что ничего не сделал, а условно «0.5» — это те, кто зашли на сайт, мы можем научиться ранжировать всех пользователей нашей системы по похожести на потенциального клиента. Мы можем использовать это знание в нашей модели и рассказывать клиенту о том, какие признаки, с точки зрения модели, отделяют клиентов от простых посетителей.
Автор: galimova_ruvds
