Объявления на карте авито: Поиск объявления по карте Авито

Как метрики воронки революционизируют успех продаж

Продажи — это искусство, но также и наука. Таким образом, все аспекты функции продаж могут быть измерены. против конкретных целей.

Чтение Подробнее

Производство

Можно ли уменьшить количество брака на производстве?

Когда такая компания, как Bosch, решает проблему, мир слушает. Пришло время учиться.

Чтение Подробнее

Путешествовать

Как ИИ может ускорить исследования

Технологии изменили нашу жизнь, особенно с появлением Интернета.

Чтение Подробнее

Страхование

Прогноз ожидаемых потерь от пожара для страховых полисов

Неопределенность приводит к росту цен на страховые полисы. Прогноз потерь от пожара чрезвычайно изменчив для две причины:

Чтение Подробнее

Человеческие ресурсы

Помогаем ресторанам сосредоточиться на том, что для них важно

Будь моим гостем. Прогнозирование того, сколько посетителей будет у ресторана сегодня.

Чтение Подробнее

Розничная торговля

Помощь менеджерам в прогнозировании их продаж с помощью ИИ

ПРОГНОЗ ПРОДАЖ МАГАЗИНА ROSSMANN. «Для меня также важно не сдаваться слишком рано».
Кортик Россманн

Чтение Подробнее

Розничная торговля

Как узнать, когда и что спросит клиент?

Прогнозирование продаж продукции для крупной корпоративной сети

Чтение Подробнее

Интернет Сервис

Использование пользовательских изображений для классификации ресторанов

Превращение изображений в слова с помощью Yelp. Назначение нескольких меток изображениям ресторана с помощью ИИ.

Чтение Подробнее

Маркетинг

Категоризация долгоживущего контента в Интернете

Раскрытие скрытых драгоценных камней. Создание классификатора для категоризации веб-страниц для StumbleUpon.

Чтение Подробнее

Страхование

Подверженность страхователя взаимным рискам Liberty

Компания Liberty Mutual Insurance, входящая в список Fortune 100, предлагает широкий спектр страховых продуктов.

Чтение Подробнее

Маркетинг

Можно ли предсказать успех рекламы?

Разместить объявление непросто, но все мы знаем, что это очень важно при продаже чего-либо.

Чтение Подробнее

Маркетинг

Категоризация долгоживущего контента в Интернете

Раскрытие скрытых драгоценных камней. Создание классификатора для категоризации веб-страниц для StumbleUpon.

Чтение Подробнее

Розничная торговля

Помощь менеджерам в прогнозировании их продаж с помощью ИИ

ПРОГНОЗ ПРОДАЖ МАГАЗИНА ROSSMANN. «Для меня также важно не сдаваться слишком рано».
Кортик Россманн

Чтение Подробнее

Розничная торговля

Как узнать, когда и что спросит клиент?

Прогнозирование продаж продукции для крупной корпоративной сети

Чтение Подробнее

Электронная коммерция

Как ИИ предсказывает потребности сотрудника

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

Чтение Подробнее

Производство

Можно ли уменьшить количество брака на производстве?

Когда такая компания, как Bosch, решает проблему, мир слушает. Пришло время учиться.

Чтение Подробнее

гостеприимство

Можно ли предсказать успех ресторана?

Tab Food Investments управляет ресторанами быстрого обслуживания в основном в Турции и Китае с 1995 года.

Чтение Подробнее

Человеческие ресурсы

Помогаем ресторанам сосредоточиться на том, что для них важно

Будь моим гостем. Прогнозирование того, сколько посетителей будет у ресторана сегодня.

Чтение Подробнее

Страхование

Прогноз ожидаемых потерь от пожара для страховых полисов

Неопределенность приводит к росту цен на страховые полисы. Прогноз потерь от пожара чрезвычайно изменчив для две причины:

Чтение Подробнее

Страхование

Подверженность страхователя взаимным рискам Liberty

Компания Liberty Mutual Insurance, входящая в список Fortune 100, предлагает широкий спектр страховых продуктов.

Чтение Подробнее

Интернет Сервис

Использование пользовательских изображений для классификации ресторанов

Превращение изображений в слова с помощью Yelp. Назначение нескольких меток изображениям ресторана с помощью ИИ.

Чтение Подробнее

Программное обеспечение

Как метрики воронки революционизируют успех продаж

Продажи — это искусство, но также и наука. Таким образом, все аспекты функции продаж могут быть измерены. против конкретных целей.

Чтение Подробнее

Путешествовать

Как ИИ может ускорить исследования

Технологии изменили нашу жизнь, особенно с появлением Интернета.

Чтение Подробнее

Почему мы перешли с Python на Go в системе рекомендаций Авито | Василий Копытов | АвитоТех | март 2023 г.

Привет! Меня зовут Василий Копытов, я руковожу группой разработки рекомендаций Авито. Мы занимаемся системами, предоставляющими пользователю персонализированную рекламу на сайте и в приложениях. На примере нашего основного сервиса я покажу, когда переходить с Python на Go, а когда оставить все как есть. В конце я дам несколько советов по оптимизации сервисов Python.

Любой, кто заходит на главную страницу сайта или приложения, видит персонализированную ленту объявлений — рекомендации. Нагрузка на наш основной рекомендательный сервис, отвечающий за генерацию бесконечной ленты объявлений на главной странице, составляет около 200 000 запросов в минуту. Общий трафик до 500 000 запросов в минуту на рекомендации.

Сервис выбирает наиболее подходящие объявления из 130 миллионов активных объявлений (товаров) для каждого пользователя. Рекомендации генерируются на основе каждого действия человека за последний месяц.

Представительство работает по следующему алгоритму:

1. Сервис обращается к хранилищу истории пользователя и извлекает из него агрегированную историю действий и интересов.

Интересы — это набор категорий и подкатегорий рекламы, которую человек недавно просматривал. Например, детская одежда, домашние животные или товары для дома.

2. Затем передается история и интересы как набор параметров, воздействие на модели машинного обучения первого уровня.

Модели машинного обучения первого уровня являются базовыми службами. Сейчас у нас есть 4 таких модели. Они предсказывают элементы, используя различные алгоритмы машинного обучения. На выходе каждого сервиса получаем список id (рекомендуемых).

3. Мы фильтруем идентификатор на основе истории пользователя. У нас получается около 3000 элементов на пользователя.

4. И самое интересное, что представление внутри использует модель машинного обучения второго уровня, основанную на CatBoost, для ранжирования рекламы из моделей машинного обучения первого уровня в реальном времени.

5. Из данных готовим характеристики. Это параметры ранжирования рекомендаций. Для этого мы используем id элемента для получения данных в хранилище (осколочная база данных 1 ТБ, Redis). Данные товара — название, цена и еще около 50 полей.

6. Служба передает функции и элементы в модель машинного обучения второго уровня на основе библиотеки CatBoost. Результатом является ранжированная лента объявлений.

7. Далее представление выполняет бизнес-логику. Например, подбирает в ленте те объявления, за премиум размещение которых взимается плата (boost VAS).

8. Кешируем и отдаем сгенерированный фид рекомендации пользователю, в нем около 3000 объявлений.

Представительство как услуга очень загружено в Авито. Он обрабатывает 200 000 запросов в минуту. Сервис стал таким не сразу: мы постоянно вносили что-то новое и улучшали качество рекомендаций. В какой-то момент он начал потреблять почти столько же ресурсов, сколько и весь остальной монолит Авито. Нам стало сложно выкатывать сервис в дневное время, в часы пик, из-за нехватки ресурсов в кластере — в это время большинство разработчиков развертывали свои сервисы.

Вместе с ростом потребления ресурсов росло и время отклика службы. Во время пиковых нагрузок пользователи могли ждать свои рекомендации до 1,6 секунды — это в 8 раз больше, чем за последние 2 года. Все это могло заблокировать дальнейшее развитие и совершенствование рекомендаций.

Причины этого достаточно очевидны:

1. Высокая нагрузка, связанная с вводом-выводом. В представлении каждый запрос состоит примерно из 20 сопрограмм — блоков кода, которые выполняются асинхронно при обработке сетевых запросов.
2. Нагрузка на ЦП от вычислений в реальном времени по ML-модели, которые полностью заняты ЦП, пока происходит ранжирование рекламы.
3. GIL — представление изначально было написано на однопоточном Python. В этом языке программирования невозможно совместить рабочие нагрузки, связанные с вводом-выводом и с привязкой к ЦП, чтобы служба эффективно использовала ресурсы.

Позвольте мне рассказать вам, что помогло нам справиться с нашими нагрузками в Python.

1. ProcessPoolExecutor

ProcessPoolExecutor создает пул воркеров из процессорных ядер. Каждый воркер — это отдельный процесс, работающий на отдельном ядре. Вы можете передать нагрузку, связанную с ЦП, на рабочий процесс, чтобы он не замедлял другие процессы.

В представлении мы изначально использовали ProcessPoolExecutor для разделения рабочих нагрузок, связанных с процессором и вводом-выводом. В дополнение к основному процессу Python, который обслуживает запросы и ходит по сети (с привязкой к IO), мы выделили три воркера для ML-модели (с привязкой к CPU).

У нас есть асинхронная служба на aiohttp, которая обслуживает запросы и успешно обрабатывает нагрузку, связанную с вводом-выводом. ProcessPoolExecutor создает пул рабочих процессов. Рабочую нагрузку, связанную с ЦП, можно передать такому рабочему процессу, чтобы он не замедлял основной процесс службы и не влиял на задержку всей службы.

Выигрыш времени от использования ProcessPoolExecutor составляет около 35%. Для эксперимента мы решили сделать код синхронным и отключили ProcessPoolExecutor. То есть рабочие нагрузки, связанные с вводом-выводом и процессором, начали выполняться в одном процессе.

Как это выглядит в коде:

 async def process_request(user_id): 
 # Задача ввода-вывода 
 async with session.post( 
 feature_service_url, 
 json= {'user_id': user_id}, 
 ) as resp: 
 functions = await resp.json() 
 return features 
 

У нас есть асинхронный обработчик, который обрабатывает запрос. Для тех, кто не знаком с синтаксисом асинхронного ожидания, это ключевые слова, обозначающие точки переключения сопрограммы.

То есть на седьмой строке кода одна сопрограмма уходит в сон и отдает выполнение другой сопрограмме, которая уже получила данные, тем самым экономя процессорное время. Таким образом Python реализует совместную многозадачность.

 def предсказание (функции) 
 preprocessed_features = процессор.препроцесс (представленный) 
 return model.infer(preprocessed_features) 
 async def process_request(user_id): 
 # задача ввода-вывода 
 асинхронно с session.post( 
 feature_service_url, 
 json ={'user_id': user_id}, 
 ) as resp: 
 features = awat resp.json() 
 
 # блокировка CPUtask 
 return predict(features) 
 

Внезапно нам нужно выполнить загрузку с привязкой к ЦП из ML-модели. И так на предсказать функцию наша сопрограмма заблокирует процесс python. Чтобы все сервисные запросы не стояли в очереди и время ответа сервиса не увеличивалось, как мы видели ранее.

 исполнитель = concurrent.futures.ProcessPoolExecutor(man_workers=N) 
 по определению предсказать(функции): 
 preprocessed_features = processing.preprocess(features) 
 return model.infer(preprocessed_features) 
 
 async def process_request(user_id): 
 # задача ввода/вывода 
 async with session. post( 
 feature_service_url, 
 json={'user_id': user_id}, 
 ) as resp: 
 features = await resp.json() 
 
 # Неблокирующая задача ЦП 
 return await loop.run_in_executor(executor, predict(features)) 
 

Здесь ProcessPoolExecutor вступает со своим собственным пул рабочих, который решает эту проблему. В строке 1 мы создаем пул. В конце блока кода мы берем рабочего оттуда и перемещаем задачу, связанную с процессором, на отдельное ядро. Таким образом, функция прогнозирования будет выполняться асинхронно по отношению к родительскому процессу, а не блокировать его. Приятно то, что все это будет завернуто в обычный синтаксис async-await, а задачи, привязанные к процессору, будут выполняться асинхронно, как и задачи, связанные с вводом-выводом, но под капотом будет дополнительная магия с процессами.

ProcessPoolExecutor позволил нам снизить накладные расходы от модели ML в реальном времени, но и с ним в какой-то момент стало плохо. Первое, с чего мы начали, было самым очевидным — профилированием и выявлением узких мест.

Даже если служба написана опытными программистами, ее можно улучшить. Чтобы понять, какие части кода медленные, а какие быстрые, мы профилировали сервис с помощью профилировщика py-spy.

Профилировщик строит диаграмму, на которой горизонтальные полосы показывают, сколько процессорного времени тратится впустую на участок кода. Первое, что вы видите, это 3 полосы справа. Это всего лишь наши дочерние процессы для оценки функций модели ML.

На графике пламени мы увидели некоторые интересные детали:

• 7% процессорного времени тратится на сериализацию данных между процессами. Сериализация — это преобразование данных в байты. В Python этот процесс называется pickle , а обратный — unpickle .
• 3% времени уходит на оверхед ProcessPoolExecutor — подготовка пула воркеров и распределение нагрузки между ними.
• 6,7% времени тратится на сериализацию данных для сетевых запросов в json.loads и json.dumps.

В дополнение к процентному распределению, мы хотели знать конкретное время, затрачиваемое на выполнение различных частей кода. Для этого мы снова отключили ProcessPoolExecutor, запустили модель ML для ранжирования синхронно.

Но проблема остается — конкретный кусок кода стало быстрее, но сам сервис стал медленнее.

Поэкспериментировав, мы выяснили:

• Накладные расходы ProcessPoolExecutor составляют около 100 миллисекунд.
• Запросы, связанные с вводом-выводом, от сопрограмм ждут 80 миллисекунд, то есть сопрограмма засыпает, и цикл событий снова обращается к ней через 80 мс, чтобы возобновить ее выполнение. В Representation есть три большие группы IO-bound запросов — всего на IO-wait тратится 240 миллисекунд.

Именно тогда мы впервые подумали о переходе на Go, так как он имеет более эффективную модель планирования подпрограмм из коробки.

Одним из больших изменений, которые мы пытались сделать, было удаление модели машинного обучения в отдельную службу повторного ранжирования. То есть мы сохранили наш сервис представления только с сетевыми запросами, а скоринг ML-модели был на отдельном сервисе rec-ranker, куда мы передавали все необходимые данные и возвращали скоринг для ранжирования. Казалось, что мы немного уменьшим латентность и масштабируем обе части по отдельности.

Эксперимент показал, что мы экономим время на работе модели, но получаем задержку в 270 миллисекунд при передаче данных по сети и json.loads/json.dumps. Нам нужно передать около 4 Мб на запрос, а для очень активных пользователей до 12 Мб данных для модели ML. После масштабирования rec-ranker реплики стали ненамного меньше старого представления, а время отклика не изменилось. Для нашего случая разбиение на сервисы оказалось неудачным решением, поэтому мы вернулись к предыдущей реализации Representation.

В службе Представление данные передаются между процессами посредством pickle/unpickle. Вместо этого процессы, которые совместно используют данные, могут указывать на общую область памяти. Это экономит время сериализации.

Максимальная оценка состоит в том, что мы могли бы выиграть около 70 миллисекунд на сериализацию с таким же сокращением времени для объема выполнения запроса, поскольку загрузка процессора блокировала основной процесс Python, который обрабатывал запросы от пользователей. Такой вывод мы сделали по профилю: pickle/unpickle занимает всего 7% процессорного времени, от разделяемой памяти особого профита не будет.

Мы решили сначала протестировать работоспособность Go на части сервиса. Для эксперимента мы выбрали самую ресурсоемкую задачу в сервисе — подготовку фич.

Возможности в сервисе рекомендаций — данные о товаре и действия пользователя. Например, название объявления, цена, информация о показах и кликах. Существует около 60 параметров, влияющих на результат модели машинного обучения. То есть мы готовим все эти данные для 3000 элементов и отправляем их в модель, и она дает нам оценку для каждого элемента, которую мы используем для ранжирования фида.

Чтобы связать код Go для подготовки функций с остальной частью кода службы в Python, мы использовали ctypes.

 def get_predictions( 
 raw_data: bytes, 
 model_ptr: POINTER(c_void_p), 
 size: int, 
) -> list: 
 raw_predictions = lib.GetPredictionsWithModel(
 GoString(raw_data, len(raw_data)), 90r 
 ) 
 прогнозов = [raw_predictions[i] для i в диапазоне (размере)] 
 прогнозов возврата 

Вот как выглядит подготовка функций внутри Python. Модуль lib представляет собой скомпилированный пакет Go с функцией GetPredictionsWithModel. В него мы передаем байты с данными об элементах и ​​указатели на ML-модель. Все функции подготовлены кодом Go.

Результаты были впечатляющими:

• Функции Go считаются в 20–30 раз быстрее;
• весь шаг ранжирования в 3 раза быстрее с учетом дополнительной сериализации данных в байты;
• отклик главной страницы упал на 35%.

Результаты

После всех экспериментов мы сделали четыре вывода:

• Функции Go для 3000 элементов на запрос считаются в 20–30 раз быстрее, что экономит 30% времени.
• ProcessPoolExecutor тратит впустую около 10% времени.
• Три группы запросов, связанных с вводом-выводом, занимают 25% времени пустых ожиданий.
• После перехода на Go мы сэкономим около 65% времени.

Есть модель ML в представлении-го. Естественно кажется, что ML хорош только для Python, но в нашем случае модель ML на CatBoost и у нее есть C-API, который можно вызывать из Go. Этим мы и воспользовались.

Ниже приведен фрагмент кода на Go. Не буду на этом особо останавливаться, отмечу только, что логический вывод дает те же результаты, что и в Python. C — это псевдопакет, предоставляющий Go интерфейс для библиотек C.

 if !C.CalcModelPrediction( 
 model.Handler, 
 C.size_t(nSamples), 
 floatsC, 
 C.size_t(floatFeaturesCount), 
 CatsC, 
 C.size_t(categoryFeaturesCount), 
 (*C.double) (&results[0]), 
 C.size_t(nSamples), 
) { 
 вернуть nil, getError() 
 } 

Проблема в том, что модель машинного обучения все еще обучается на Python. И для того, чтобы он изучал и строил одни и те же функции, важно, чтобы они не расходились.

Мы начали их готовить по коду Go-service. Обучение происходит на отдельных машинах, туда загружается сервисный код в Go, по этому коду готовятся фичи, сохраняются в файл, затем Python-скрипт скачивает этот файл и обучает на них модель. В качестве бонуса обучение также стало в 20–30 раз быстрее.

Representation-go показал отличные результаты:

• Время отклика главной страницы сократилось в 3 раза с 1280 миллисекунд до 450 миллисекунд.
• Потребление ЦП снизилось в 5 раз.
• Потребление ОЗУ снизилось в 21 раз.

Мы разблокировали дальнейшую разработку рекомендаций — мы можем продолжать реализовывать тяжелые функции .

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

1. сервис имеет высокую нагрузку на ЦП
2. в то же время высокая нагрузка на IO
3. вам необходимо отправить большой объем данных по сети на подготовить характеристики.

Если у вас есть только рабочие нагрузки, связанные с вводом-выводом, вам лучше придерживаться Python. Переход на Go не выиграет вам много времени, вы только сэкономите ресурсы, что не так важно для малых и средних рабочих нагрузок.

Если сервис использует обе нагрузки, но не передает по сети столько данных, сколько мы, есть два варианта:

1. Использовать ProcessPoolExecutor. Накладные расходы времени не будут очень большими, а обслуживание не огромным.
2. Поскольку нагрузка по трафику становится слишком высокой, разделите его на 2 службы — службы с привязкой к ЦП и службы с привязкой к IO, чтобы масштабировать их отдельно.

Профилируйте свою службу. Используйте py-spy, как мы, или другой профилировщик Python. Скорее всего, ваш код не имеет огромных неоптимальных областей. Но вам нужно повнимательнее присмотреться ко всем небольшим областям, которые будут значительно улучшены. Возможно, вам не потребуется переписывать весь код.

Запустить py-spy в неблокирующем режиме:

 record -F -o record.