Ускоряем исследования с помощью конкурсов как их готовить и выигрывать / Иван...Ontico
Мы в Авито часто сталкиваемся с ситуацией, когда нужно быстро придумать алгоритм, решающий некоторую бизнес задачу на основе анализа больших объёмов данных. Придумать какой-то алгоритм не сложно, но каждый раз возникает вопрос — а вдруг можно решить эту же задачу в разы более качественно. Исследования можно вести годами, но это рискованно — лучшего решения может и не быть, и будет затрачено много времени.
На помощь приходят конкурсы по анализу данных. Мы устраивали конкурсы на построение алгоритмов, работающих с совершенно различными типами и объемами данных:
+ Выявление запрещенных объявлений.
+ Прогнозирование вероятности клика на рекламное объявление.
+ Обнаружение телефонов на изображениях.
+ Прогнозирование инкрементального эффекта от скидочных акций.
Какие-то были более удачными, какие-то — менее. Расскажем про основные этапы подготовки задач к конкурсу, а также про основные трюки, используемые для победы в таких конкурсах
Бигдата — как добывать золото из данных / Александр Сербул (1С-Битрикс)Ontico
Расскажем о самых распространенных технологиях и алгоритмах добычи критичной для бизнеса информации из больших массивов данных. Отдельно коснемся темы рекомендательных сервисов и их эффективного применения.
План:
1) Откуда брать данные, тренды и концепции.
2) Основные алгоритмы и технологии их применения для обработки массивов данных: MapReduce, Spark.
3) Методика создания рекомендательного сервиса — этапы от концепции до работающей системы.
Golang в действии: Как нам удается писать highload приложение на (не?)подходя...Daniel Podolsky
Последние 2 года язык Go является моим - нашим - основным средством заработка на хлеб. Хватает, в общем-то, и на хлеб, и на масло, а иногда и на красную икру.
Не покривив душой, я могу сказать, что мы относимся к языку Go и его создателям с симпатией и уважением.
Однако, при всем нашем уважении, заявить, что Go предназначен для "тяжелых" проектов, я, не покривив душой, не могу.
Во-первых, Go молодой язык, для которого еще не известны паттерны и - что важнее - антипаттерны. Тем, кто пишет на Go тяжелое приложение сегодня, приходится тратить существенное время на тесты и оптимизации
Во-вторых, выразительные средства Go довольно скудны, что приводит к появлению в коде ужасающего количества boilerplate, за которым эффективно прячется бизнес-логика. Программу на Go бывает трудно охватить взглядом и поместить ее модель себе в голову просто из-за количества строк, которые надо для этого прочесть.
В-третьих, у Go есть проблемы с эффективностью кода. У Go плохой оптимизатор. У Go плохо с "заточкой" под железо - вспомним хотя бы историю с патчем CloudFlare для TLS. Патч ведь так и не попал в основную ветку...
Возникает вопрос - почему же, не по наслышке зная о вышеперечисленных проблемах, мы пишем наш реально тяжелый проект именно на Go?
Ответ прост: Go не идеален, но под наши задачи он подходит лучше всего.
Раньше мы строили разные тяжелые бекенды на perl, python, java, groovy и даже lua+nginx. Нам есть, с чем сравнивать.
Во-первых, Go достаточно быстр. Во всяком случае, он быстрее perl и python на нашем профиле нагрузки.
Во-вторых, и это важнее, Go предоставляет вполне достаточные средства контроля за потреблением как RAM, так и CPU. Например, регулярные выражения Go не такие гибкие, как pcre, и, по моим наблюдениям, медленнее, чем pcre. Но! регулярные выражения в Go всегда отрабатывают за предсказуемое время!
В-третьих, создатели языка не врут нам - они, действительно, постарались сделать язык, на котором человекочитаемую программу написать проще, чем нечитаемую. И у них - с некоторомы оговорками - получилось! Даже пресловутый boilerplate не способен этому помешать.
Наконец, Go просто сумел нам понравиться, чего уже давно не случалось с языками программирования.
Итак, на основании опыта, полученного при создании пилотной версии проекта inCaller.org я расскажу о том, как мы писали на Go тяжелое приложение.
Миллионы одновременных персистентных websocket соединений, десятки тысяч коннектов по ssl в секунду, сотни тысяч в секунду обновлений записей в БД.
Я расскажу об антипаттернах, нами обнаруженных, о методике тестирования производительности, анализа проблем и способах с проблемами справиться.
Доклад рассчитан на backend-программистов, как на языке Go, так и на других.
Ускоряем исследования с помощью конкурсов как их готовить и выигрывать / Иван...Ontico
Мы в Авито часто сталкиваемся с ситуацией, когда нужно быстро придумать алгоритм, решающий некоторую бизнес задачу на основе анализа больших объёмов данных. Придумать какой-то алгоритм не сложно, но каждый раз возникает вопрос — а вдруг можно решить эту же задачу в разы более качественно. Исследования можно вести годами, но это рискованно — лучшего решения может и не быть, и будет затрачено много времени.
На помощь приходят конкурсы по анализу данных. Мы устраивали конкурсы на построение алгоритмов, работающих с совершенно различными типами и объемами данных:
+ Выявление запрещенных объявлений.
+ Прогнозирование вероятности клика на рекламное объявление.
+ Обнаружение телефонов на изображениях.
+ Прогнозирование инкрементального эффекта от скидочных акций.
Какие-то были более удачными, какие-то — менее. Расскажем про основные этапы подготовки задач к конкурсу, а также про основные трюки, используемые для победы в таких конкурсах
Бигдата — как добывать золото из данных / Александр Сербул (1С-Битрикс)Ontico
Расскажем о самых распространенных технологиях и алгоритмах добычи критичной для бизнеса информации из больших массивов данных. Отдельно коснемся темы рекомендательных сервисов и их эффективного применения.
План:
1) Откуда брать данные, тренды и концепции.
2) Основные алгоритмы и технологии их применения для обработки массивов данных: MapReduce, Spark.
3) Методика создания рекомендательного сервиса — этапы от концепции до работающей системы.
Golang в действии: Как нам удается писать highload приложение на (не?)подходя...Daniel Podolsky
Последние 2 года язык Go является моим - нашим - основным средством заработка на хлеб. Хватает, в общем-то, и на хлеб, и на масло, а иногда и на красную икру.
Не покривив душой, я могу сказать, что мы относимся к языку Go и его создателям с симпатией и уважением.
Однако, при всем нашем уважении, заявить, что Go предназначен для "тяжелых" проектов, я, не покривив душой, не могу.
Во-первых, Go молодой язык, для которого еще не известны паттерны и - что важнее - антипаттерны. Тем, кто пишет на Go тяжелое приложение сегодня, приходится тратить существенное время на тесты и оптимизации
Во-вторых, выразительные средства Go довольно скудны, что приводит к появлению в коде ужасающего количества boilerplate, за которым эффективно прячется бизнес-логика. Программу на Go бывает трудно охватить взглядом и поместить ее модель себе в голову просто из-за количества строк, которые надо для этого прочесть.
В-третьих, у Go есть проблемы с эффективностью кода. У Go плохой оптимизатор. У Go плохо с "заточкой" под железо - вспомним хотя бы историю с патчем CloudFlare для TLS. Патч ведь так и не попал в основную ветку...
Возникает вопрос - почему же, не по наслышке зная о вышеперечисленных проблемах, мы пишем наш реально тяжелый проект именно на Go?
Ответ прост: Go не идеален, но под наши задачи он подходит лучше всего.
Раньше мы строили разные тяжелые бекенды на perl, python, java, groovy и даже lua+nginx. Нам есть, с чем сравнивать.
Во-первых, Go достаточно быстр. Во всяком случае, он быстрее perl и python на нашем профиле нагрузки.
Во-вторых, и это важнее, Go предоставляет вполне достаточные средства контроля за потреблением как RAM, так и CPU. Например, регулярные выражения Go не такие гибкие, как pcre, и, по моим наблюдениям, медленнее, чем pcre. Но! регулярные выражения в Go всегда отрабатывают за предсказуемое время!
В-третьих, создатели языка не врут нам - они, действительно, постарались сделать язык, на котором человекочитаемую программу написать проще, чем нечитаемую. И у них - с некоторомы оговорками - получилось! Даже пресловутый boilerplate не способен этому помешать.
Наконец, Go просто сумел нам понравиться, чего уже давно не случалось с языками программирования.
Итак, на основании опыта, полученного при создании пилотной версии проекта inCaller.org я расскажу о том, как мы писали на Go тяжелое приложение.
Миллионы одновременных персистентных websocket соединений, десятки тысяч коннектов по ssl в секунду, сотни тысяч в секунду обновлений записей в БД.
Я расскажу об антипаттернах, нами обнаруженных, о методике тестирования производительности, анализа проблем и способах с проблемами справиться.
Доклад рассчитан на backend-программистов, как на языке Go, так и на других.
Мы разработали automated testing dojo специально для тестировщиков - автоматизаторов. Теперь и у вас есть возможность провести время с фаном, продемонстрировать свой инструментарий из чемоданчика, которым каждый день пользуетесь.
Как поддерживать и развивать пачку "похожих" проектов. Кластер или конгломера...Ontico
Когда в зоне ответственности находятся несколько "похожих" по реализации и/или функционалу технических решений (сайтов, систем, проектов), волей-неволей возникает желание их унифицировать. Плюсы от такого подхода очевидны: это и экономия ресурсов разработки/тестирования/администрирования, и удобство поддержки, и полноценное общее владение кодом для всей команды разработки. Очевидно, что подобная реформа потребует значительных ресурсов и времени, но мы верим, что это "один раз", и принимаемся отстраивать сложную архитектурную конструкцию, призванную удовлетворить требования всех "объединяемых" продуктов.
Если эти продукты не подвержены изменениям, то рано или поздно все закончится хорошо, и у нас получится чудо-фреймворк. Но обычно все совсем не так. Пока мы прорабатываем классы и строим безупречные схемы взаимосвязей, мир меняется: меняются требования к продукту, новые вызовы рынка и видение менеджмента влекут за собой постоянные изменения функционала. То что было сделано вчера уже не соответствует тому, что хотят сегодня.
Это похоже на возведение песочного замка у самой кромки прибоя. В результате трудный путь превращается в изнуряющее топтание на месте, а имеющееся техническое наследие потихоньку ветшает, разрастается казуальным кодом и забирает все больше сил на поддержку.
Но проблема даже не в этом. Основная проблема в том, что мы видим причину неудач в ошибках проектирования или в несговорчивости менеджмента, не желающего пойти на уступки относительно реализации того или иного функционала. Все проще: я убежден, что ошибка была допущена при выборе пути! Но я не призываю смириться и "тащить" на себе кучу сто раз продублированного кода. Истина, как всегда, где-то посередине.
Мы не будем больше собирать все проекты в один кластер, мы попробуем построить конгломерат!
* оценим перспективы унификации и рассмотрим альтернативы;
* рассмотрим типовые препятствия, и откуда они берутся;
* поговорим о сути изменений, и какие они бывают;
* познакомимся с реальностью на основе моего личного опыта;
* обсудим, что есть "похожесть" проектов и что с этим делать.
Сколько денег теряет компания, не работая с негативом?Комплето
Онлайн-конференция. Электронный маркетинг для B2B. Системный подход. КЕЙСЫ в B2B. 27 апреля 2015.
Видеозапись смотрите тут:
http://www.youtube.com/watch?v=tt-aO8zY6Rs
Роман Цветков
Интернет-маркетолог маркетинговой группы “Комплето”
Кейс1: Сколько денег теряет компания, не работая с негативом.
Кейс2: Как за 3 месяца загрузить производство на год вперед: кейс монобрендового продукта.
Кейс1: Сколько денег теряет компания, не работая с негативом.
Осознание необходимости работы с негативом: большинство компаний не имеют представления, сколько негативных отзывов есть на них в сети.
Как негатив влияет на финансовое состояние компании в цифрах
Создание ретроспективного анализа отзывов
Построение бизнес-процессов работы с негативом
Кейс2: Как за 3 месяца загрузить производство на год вперед: кейс монобрендового продукта.
Работа с несформировананным спросом.
Подстройка под целевую аудиторию
Уникальное торговое предложение: находим вместе с клиентом.
Интересные SEO решения
Ищем аудиторию
Ilya Tumenko, Founder, War&World
Survival guide for independent developers after Indieapocalypse and the funeral of the GreenLight: What Ideas worth the betting on? What markets you should pay attention for? Where to get the money? Or to get everything else, without a penny? And why you should already stop thinking yourself as indie.
Python, Django и корпоративные информационные системыPyNSK
Софт для автоматизации бизнеса составляет значительную часть всего существующего на планете программного обеспечения. Рассмотрим требования к нему и особенности его разработки. Оценим, насколько Python для этого подходит, и облегчают ли фреймворки жизнь в кровавом энтерпрайзе.
Докладчик: Анатолий Щербаков
Видео: https://youtu.be/G_ks3sO1Mbs
Теория ограничений в работе и жизни. Как стать системным мыслителем и решать ...Netpeak
Презентация с непрофильного образовательного ивента Netpeak.
Докладчик: Кутас Иван - Deputy Head of SEO, Product Development, Netpeak.
Запись выступления: https://youtu.be/Gg3zXySEpGE
Машинное обучение в электронной коммерции — практика использования и подводны...Ontico
HighLoad++ 2017
Зал «Найроби+Касабланка», 7 ноября, 16:00
Тезисы:
http://www.highload.ru/2017/abstracts/2851.html
Анализ, проектирование, разработка и эксплуатация моделей предиктивной аналитики в Битрикс24.
В докладе расскажем, как мы создали несколько хайлоад-моделей для предсказания платных клиентов, потенциальной прибыли клиентов и клиентов, вероятно покидающих сервис. Поделимся опытом выбора алгоритмов, библиотек, тонкой настройки моделей в Spark MLib, фильтрации и обработки бигдаты на кластерах Spark в Amazon Web Services и всем тем, что необходимо для доведения "предиктивных" моделей до работающего при высоких нагрузках сервиса.
Самое важное в докладе - опыт доведения алгоритмов до прикладного бизнес-применения, тонкости и техники выжимания из данных самой ценной информации.
Мы разработали automated testing dojo специально для тестировщиков - автоматизаторов. Теперь и у вас есть возможность провести время с фаном, продемонстрировать свой инструментарий из чемоданчика, которым каждый день пользуетесь.
Как поддерживать и развивать пачку "похожих" проектов. Кластер или конгломера...Ontico
Когда в зоне ответственности находятся несколько "похожих" по реализации и/или функционалу технических решений (сайтов, систем, проектов), волей-неволей возникает желание их унифицировать. Плюсы от такого подхода очевидны: это и экономия ресурсов разработки/тестирования/администрирования, и удобство поддержки, и полноценное общее владение кодом для всей команды разработки. Очевидно, что подобная реформа потребует значительных ресурсов и времени, но мы верим, что это "один раз", и принимаемся отстраивать сложную архитектурную конструкцию, призванную удовлетворить требования всех "объединяемых" продуктов.
Если эти продукты не подвержены изменениям, то рано или поздно все закончится хорошо, и у нас получится чудо-фреймворк. Но обычно все совсем не так. Пока мы прорабатываем классы и строим безупречные схемы взаимосвязей, мир меняется: меняются требования к продукту, новые вызовы рынка и видение менеджмента влекут за собой постоянные изменения функционала. То что было сделано вчера уже не соответствует тому, что хотят сегодня.
Это похоже на возведение песочного замка у самой кромки прибоя. В результате трудный путь превращается в изнуряющее топтание на месте, а имеющееся техническое наследие потихоньку ветшает, разрастается казуальным кодом и забирает все больше сил на поддержку.
Но проблема даже не в этом. Основная проблема в том, что мы видим причину неудач в ошибках проектирования или в несговорчивости менеджмента, не желающего пойти на уступки относительно реализации того или иного функционала. Все проще: я убежден, что ошибка была допущена при выборе пути! Но я не призываю смириться и "тащить" на себе кучу сто раз продублированного кода. Истина, как всегда, где-то посередине.
Мы не будем больше собирать все проекты в один кластер, мы попробуем построить конгломерат!
* оценим перспективы унификации и рассмотрим альтернативы;
* рассмотрим типовые препятствия, и откуда они берутся;
* поговорим о сути изменений, и какие они бывают;
* познакомимся с реальностью на основе моего личного опыта;
* обсудим, что есть "похожесть" проектов и что с этим делать.
Сколько денег теряет компания, не работая с негативом?Комплето
Онлайн-конференция. Электронный маркетинг для B2B. Системный подход. КЕЙСЫ в B2B. 27 апреля 2015.
Видеозапись смотрите тут:
http://www.youtube.com/watch?v=tt-aO8zY6Rs
Роман Цветков
Интернет-маркетолог маркетинговой группы “Комплето”
Кейс1: Сколько денег теряет компания, не работая с негативом.
Кейс2: Как за 3 месяца загрузить производство на год вперед: кейс монобрендового продукта.
Кейс1: Сколько денег теряет компания, не работая с негативом.
Осознание необходимости работы с негативом: большинство компаний не имеют представления, сколько негативных отзывов есть на них в сети.
Как негатив влияет на финансовое состояние компании в цифрах
Создание ретроспективного анализа отзывов
Построение бизнес-процессов работы с негативом
Кейс2: Как за 3 месяца загрузить производство на год вперед: кейс монобрендового продукта.
Работа с несформировананным спросом.
Подстройка под целевую аудиторию
Уникальное торговое предложение: находим вместе с клиентом.
Интересные SEO решения
Ищем аудиторию
Ilya Tumenko, Founder, War&World
Survival guide for independent developers after Indieapocalypse and the funeral of the GreenLight: What Ideas worth the betting on? What markets you should pay attention for? Where to get the money? Or to get everything else, without a penny? And why you should already stop thinking yourself as indie.
Python, Django и корпоративные информационные системыPyNSK
Софт для автоматизации бизнеса составляет значительную часть всего существующего на планете программного обеспечения. Рассмотрим требования к нему и особенности его разработки. Оценим, насколько Python для этого подходит, и облегчают ли фреймворки жизнь в кровавом энтерпрайзе.
Докладчик: Анатолий Щербаков
Видео: https://youtu.be/G_ks3sO1Mbs
Теория ограничений в работе и жизни. Как стать системным мыслителем и решать ...Netpeak
Презентация с непрофильного образовательного ивента Netpeak.
Докладчик: Кутас Иван - Deputy Head of SEO, Product Development, Netpeak.
Запись выступления: https://youtu.be/Gg3zXySEpGE
Машинное обучение в электронной коммерции — практика использования и подводны...Ontico
HighLoad++ 2017
Зал «Найроби+Касабланка», 7 ноября, 16:00
Тезисы:
http://www.highload.ru/2017/abstracts/2851.html
Анализ, проектирование, разработка и эксплуатация моделей предиктивной аналитики в Битрикс24.
В докладе расскажем, как мы создали несколько хайлоад-моделей для предсказания платных клиентов, потенциальной прибыли клиентов и клиентов, вероятно покидающих сервис. Поделимся опытом выбора алгоритмов, библиотек, тонкой настройки моделей в Spark MLib, фильтрации и обработки бигдаты на кластерах Spark в Amazon Web Services и всем тем, что необходимо для доведения "предиктивных" моделей до работающего при высоких нагрузках сервиса.
Самое важное в докладе - опыт доведения алгоритмов до прикладного бизнес-применения, тонкости и техники выжимания из данных самой ценной информации.
Опыт разработки SEO софта на примере FastTrust и ComparseRАлександр Алаев
Рассказываю про свой непростой опыт разработки десктопных программ на примере FastTurst и ComparseR. Всем, кто собирается заняться разработкой инди приложения или сервиса рекомендую.
Денис Тучин, Проверка гипотез Kanban Method с помощью имитационной моделиScrumTrek
Используя имитационную модель на докладе мы проверим, что лучше работает:
Что делать если команда не сбалансирована
Может ли сбалансированная команда работать без ограничения WIP
Как подобрать оптимальные ограничения WIP
Помогает ли приоритезация бизнесу
Денис Тучин - Проверка гипотез Kanban Method с помощью имитационной моделиDenis Tuchin
Видео: https://www.youtube.com/watch?v=79Joxx6gTeU
Используя имитационную модель на докладе мы проверим, что лучше работает:
- Что делать если команда не сбалансирована
- Может ли сбалансированная команда работать без ограничения WIP
- Как подобрать оптимальные ограничения WIP
- Помогает ли приоритезация бизнесу
2. План рассказа
● Часть 1. Пять миров
в которой мы вспомним, что машинленинг бывает разный.
● Часть 2. Алхимия
в которой мы вытащим пару древних артефактов,
оставшихся с времен, когда люди относились к жизни проще.
● Часть 3. Нормально делай - нормально будет
в которой мы поговорим про машинленинг курильщика.
● Часть 4. Аутсорсь это
в которой мы напомним, что сколько волка не корми, ишак выносливее.
● Часть 5, заключительная
...И немедленно выпил.
4. Пять миров ML
● Ученые
● Спортсмены
● Стартапы
● Продуктовые компании
● АСУ
Все знают, что такое АСУ?
Сидит в комнатах, заставленных серверами. Совмещают сисадминство с ERP-
разработкой. К 35 уходят или становятся важнейшим бизнес-активом
(иногда попадают в рай и становятся начальниками отдела или тех директорами)
5. Пять миров ML - 2
Ресурсы Мультипликатор Ответственность
Ученые + 0 0
Спортсмены + 0 0
Стартапы ++ +++ +
Продуктовые +++ ++ +++
АСУ + + +++
Ответственность — как у инженеров Гугла, ресурсов как у спортсмена.
Большинство красивых рассказов и статей про ученых, спортсменов,
продуктовиков.
Конкурентные преимущества доставляют АСУ шники, т. к.:
- Ученые светят всем поровну
- Продуктовики и стартаперы меняют ландшафт для всех
- АСУшники работают только на компанию
- Можно бежать медленнее, чем медведь, но быстрее, чем конкурент.
7. Алхимия
● Ali Rahimi, NIPS 2017:
Machine Learning has become Alchemy
https://www.youtube.com/watch?v=Qi1Yry33TQE
● Yann LeCun:
I fundamentally disagree with the message.
The main message was, in essence, that the current practice in machine learning is
akin to "alchemy" (his word).
It's insulting, yes. But never mind that: It's wrong!
…..
Criticizing an entire community (and an incredibly successful one at that) for
practicing "alchemy", simply because our current theoretical tools haven't caught up
with our practice is dangerous.
https://www.facebook.com/yann.lecun/posts/10154938130592143
8. Что это за Али
● Test of Time" award за работы 2007-2008
о случайных фичах.
Random Features for Large-Scale Kernel Machines
И в более общем виде
Weighted Sums of Random Kitchen Sinks
10. Ведро с болтами -2
● Ali Rahimi + Benjamin Recht, 2007
● Из хулиганских побуждений
● Хотели показать, что на достаточно большом
количестве случайных фич качество будет
почти как у SVM.
● Качество оказалось лучше.
● «обучение» значительно быстрее.
11. О чем спор-то?
● Али говорит, что современные глубокие сети
— то же самое ведро с болтами. Любая
достаточно большая куча гладких функций
подойдет.
● Ян несогласный ;-)
12. Не такой глубокий пример
● The Robust Beauty of Improper Linear Models in Decision Making
● Estimating Coefficients in Linear Models: It Don't Make No Nevermind
● Устойчивая красота неприличных моделей
13. Неглубокий пример-2
● Стандартизируем (делим на sd, например)
● «По причине отсутствия данных для
определения значений β1...βm мы поступим
волюнтаристски: назначим им значения +1
(влияет положительно), -1 (влияет
отрицательно) и 0 (не влияет).»
● Оно работает. Без обучения. Хуже чем RF.
Немного хуже LR. Но без обучения совсем.
14. Алхимическая мораль
● Это магия. Проще относитесь к жизни
● Ищите артефакты, которые отзываются на
вашу магию, и используйте их
● Пробуйте разное, побольше
● Черная магия сеток
● Зеленая магия деревьев
● Фиолетовая магия гауссовских процессов и
вероятностных графов.
15. Поле боя
Бизнес «на земле»
Оптовая торговля.
Производство.
Не-IT услуги для бизнеса.
Издательство.
Агентство недвижимости.
Сеть кафе, автосервисов, автомоек.
Небольшая транспортная компания.
16. Все будет классно
● 1000 товаров
● 20000 клиентов
● B2B
● Менеджеры подбирают пары, звонят,
продают.
● В 99% случаев их отправляют в сад
● Очень успешный бизнес
17. Все будет классно - 2
● Поможем продавать больше.
● Давайте будем подбирать пары клиент-
товар, по которым велика вероятность
продажи.
● Давайте отсортируем эти пары по
вероятности и дадим менеджерам
● Обычно по клиенту рекомендуют товар.
● Или по товару — клиента.
18. Идея!
● F (товар, купец) вероятность сделки
● Считаем 20 000 000 вариантов, исключаем уже
сделанные предложения, динамически
рассчитываем, дообучаемся после каждого клика
● Фильтруем по менеджерам, регионам,
отраслям….
● Сколько у вас RAM? 8 Gb, и на нем еще CRM + 2
вспомогательных БД + сервер MQ + десяток
микросервисов.
21. Ну и ладно
● В соответствии с бизнес-правилами выкинем
маловероятные сочетания клиент-товар
● Выкинем те, что уже предлагались в
ближайшие полгода
● Посчитаем вероятность, оставим те, у
которых P > 0.9
● Рассчитываем прогноз раз в час, обучаемся
ночью раз в сутки, когда сервер не загружен
22. Магия внедрения
● Ищем лояльного нам продавца
● Даем ему список пар (в html)
● Расспрашиваем, где очевидная чушь
● Исправляем
● Когда другие продавцы начнут просить —
идем сдаваться начальству и впиливаем это
в CRM.
23. Глаз да глаз
● Обучаемся на 90% данных, на 10% считаем
тест, записываем в базу
● По итогам дня считаем logloss
-1/N (y * log(p) + (1-y) * log(1-p))
● Расспрашиваем продавцов
● Подкручиваем фичи
● Посматриваем на графики теста и итогов дня
● Ассерт+алерт на резкое падение качества
24. Гига-метрика
● По какому проценту успешных сделок у нас
был прогноз > 0.9
● Бесполезна для обучения, тестирования,
● Очень, очень полезна при внедрении
● Высокая с самого начала, т. к.
самосбывающееся пророчество.
26. У кого процессор толще
● Microsoft
● Google
● Amazon
● IBM
● …
Больше данных, больше серверов, больше
инженеров, больше денег.
27. Для всего есть API
● Распознавание и классификация картинок
● Распознавание голоса
● Прогноз временных рядов
● Поиск аномалий
● Классификаторы и регрессии
● Анализ текстовых документов
● Для чего еще нет — скоро будет
28. Работа с возражениями
● Да, стоит денег, но на пробу можно взять
немножко, и если заработает — денег дадут.
● Не стартап, не важна IP
● Не продуктовка, не важен контроль над
инфраструктурой
● Важно внедрить как можно быстрее, пока
это еще дает конкурентные преимущества
29. И немедленно выпил!
● Все уже украдено разжевано до нас
https://developer.ibm.com/code/patterns/
30. И немедленно выпил!
● Брать и немедленно делать
● Скоро каждый 1С-разработчик сможет это
сделать двумя строками кода.
Успей до него, делай прямо сейчас.
● Трех человекодней достаточно (почти) для любого
ML-прототипа.
● В любой непонятной ситуации
читайте Rules of ML от Гугла.