Создание масштабных моделей ИИ для OTA

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

При построении с нуля каждой организации потребуется определенная автоматизация для повышения эффективности повседневных бизнес-операций. В конце концов, машинное обучение / искусственный интеллект появятся на сцене, чтобы помочь повысить производительность участников, чтобы организация могла расти в бизнес-операциях и выполнять свою миссию по глобальному расширению услуг. С этой проблемой также сталкивается tiket.com, где ИИ предоставляет потрясающие возможности, основанные на данных, которые помогают сократить трудоемкие и стрессовые задачи. Благодаря более точным прогнозам и более разумным рекомендациям, предоставляемым в качестве результатов повседневных задач, эти системы искусственного интеллекта зарекомендовали себя как отличные инструменты для занятых профессионалов, которые могут быть более эффективными и действенными в оказании большего влияния на бизнес в организациях.

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

Вдохновленные несколькими существующими статьями (например, [1], [2] и [3]), мы отметили несколько важных моментов в соответствии с нашим опытом работы с OTA, такими как tiket.com.

Многие аспекты включены в создание надежной модели для масштабного производства. К ним относятся действия, интенсивно выполняемые как учеными данных (DS), так и инженерами по машинному обучению (MLE) от начала до конца. На этапе Proof of Concept (PoC) эксперимент DS часто выполняется с использованием выбранного временного интервала данных для целей EDA — Exploratory Data Analysis [4]. Затем выполняются действия по подготовке данных, обучению модели, тестированию и оценке. В результате модель в конечном итоге становится конечным результатом процесса выбора модели в конвейере DS. Тем не менее, это не останавливаться на достигнутом. Следовательно, модель должна быть легкодоступной в качестве услуги для поддержки принятия решений человеком или предоставления рекомендаций пользователям платформы. В tiket.com многие из наших сервисов искусственного интеллекта обеспечивают умную обратную связь с нашими пользователями (как внутреннюю для повышения производительности персонала, так и внешнюю для наших ценных клиентов).

Масштабируемая подготовка данных

Как и в большинстве случаев, с которыми сталкиваются специалисты по данным, подготовка данных может занимать до 80% их времени, чтобы создать эффективную модель ИИ для производственных целей.

Согласно интервью и экспертным оценкам, специалисты по обработке и анализу данных тратят от 50 до 80 процентов своего времени на рутинную работу по сбору и подготовке неуправляемых цифровых данных, прежде чем их можно будет изучить для получения полезных самородков. —Стив Лор, 2014 [5]

Качество и целостность данных

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

Действительно ли данные достаточно репрезентативны?
Достаточно ли у нас строк данных для обучения модели?

Хотя мы сосредоточены на подготовке данных, существует потенциальный риск распространенной ловушки, с которой мы можем столкнуться. Предположение о правильном количестве точек данных (особенно для проблемы DS, требующей расширения данных) должно выполняться для обучения модели.

Давайте подумаем о сценарии поиска отеля на tiket.com, где нам нужно обеспечить наиболее оптимальное отображение отелей для наших клиентов в соответствии с их внутренними предпочтениями на основе исторических поисков и покупок отелей.

Случай использования подготовки данных. Для всех функций, которые мы подготовили для обучения, нам необходимо выполнить вставку данных (функций и меток) в облачную базу данных BigQuery. Затем следующий рабочий процесс возьмет все данные из БД для обучения модели. Каждый пользовательский запрос в поиске отелей для определенного направления потребует хранения в БД идеальных кандидатов и меток отелей. Следовательно, наша операция вставки данных (после очистки и предварительной обработки данных) будет расширена в соответствии с количеством доступных отелей, включая их идеальные ранги и метки. Представьте, что целевая функция задана для 30 лучших отелей, где отель с оплатой/нажатием на поиск пользователя должен быть помещен вверху в упорядоченном списке. Требование к пространству для хранения всех этих данных для обучения технически значительно возрастет. Таким образом, сложность вашего пространства можно обозначить как O(n.l.m), где n — количество поисковых запросов пользователей по ключевым словам, l — это местоположение/пункт назначения для заданного пользовательского поиска (n), а m — количество кандидатов (гостиниц), доступных в местоположении l. Пары sessiondate и user_id однозначно идентифицируют здесь каждый пользовательский поиск.

Из-за ограниченных ресурсов и пропускной способности сети ваш компьютер/экземпляр облака может не справиться со вставкой всех записей, что приведет к сбою загрузки/вставки данных. В худшем случае вы можете вставить записи частично, даже не осознавая этого. Более масштабируемое решение состоит в том, чтобы разделить эту большую задачу на большие куски данных для загрузки/вставки в нашу БД.

Учитывая следующую функцию для выполнения прогрессивной вставки ключевых слов пользовательского поиска, включая их пункт назначения и отели-кандидаты, нам нужно вставить данные (разделенные по дате их сеанса).

def load_chunk(df_chunk, project_name, dataset_name, table_name, first_time):
    # Load client
    client = bigquery.Client(project=project_name)
    
    if first_time: 
        job_config = bigquery.job.LoadJobConfig()
        job_config.write_disposition = bigquery.WriteDisposition.WRITE_TRUNCATE
    else: 
        job_config = bigquery.job.LoadJobConfig()
        job_config.write_disposition = bigquery.WriteDisposition.WRITE_APPEND
    # Define table name, in format dataset.table_name
    table = f'{project_name}.{dataset_name}.{table_name}'
    # Load data to BQ
    job = client.load_table_from_dataframe(df_chunk, table, job_config=job_config)
    # job.result()
     
def load_all_data(df_all_data): 
    unique_sessiondates = df_all_data['sessiondate'].unique().tolist()
    
    print(f'Unique Session Dates: {len(unique_sessiondates)}')
    
    first_time = True
    batch_counter = 0
    for i in range(len(unique_sessiondates)): 
        df_chunk = df[
            df_all_data['sessiondate'] == unique_sessiondates[i]
        ]
        batch_counter += 1
        
        load_chunk(df_chunk, 'tiket-experiment', 'sandbox_datascientist', 'dsexp_withoutfix', first_time)
        
        if first_time: 
            first_time = False

Обратите внимание, что job.result() закомментирован в приведенной выше функции. Из-за асинхронного характера выполнения клиента BigQuery быстрая итерация загрузки данных каждого DataFrame приведет к частичной вставке после завершения вашего скрипта.

-- Note: 1,018,397 out of 1,188,131 inserted 
-- Records are partially inserted. We did a check again after a day.
SELECT COUNT(1) 
FROM `tiket-experiment.sandbox_datascientist.dsexp_withoutfix`;

-- Note: 1,188,131 out of 1,188,131 inserted
-- All records are fully inserted 
-- due to the wait operation via job.result()
SELECT COUNT(1) 
FROM `tiket-experiment.sandbox_datascientist.dsexp_withfix`;

Когда применяется job.result(), клиент BigQuery будет по крайней мере ждать завершения вставки каждой итерации, прежде чем переходить к следующей итерации. Этот небольшой эксперимент был проведен на небольшом количестве поисковых запросов отелей на tiket.com. Из-за проблемы частичной вставки в этой небольшой выборке потеря точек данных будет расти экспоненциально для полного охвата данных. Несмотря на то, что мы прилагаем усилия для масштабирования загрузки данных с помощью загрузки данных по частям, эта проблема с целостностью данных окажет огромное влияние на обучение модели. Другими словами, модель, которую мы строим, может быть недостаточно репрезентативной или даже хуже, если бы мы могли иметь хорошую производительность во время эксперимента, но плохую производительность при работе в производственной среде.

Репрезентативные данные для обучения модели

Хотя количество исторических записей со временем накапливается, количество функций, которые вы создаете на этапе подготовки данных, может значительно возрасти. На этапе PoC временные рамки могут быть ограничены на короткий период. Например, мы готовим данные за октябрь для обучения модели, где ее оценка проводится на данных за ноябрь. Этот сценарий может работать для быстрого анализа, чтобы показать возможности для поддержки бизнес-операций.

Однако правильное построение модели и анализ должны выполняться должным образом в течение более длительного периода времени, особенно если модель будет использоваться в производстве. Например, в случае со сценарием поиска отеля в tiket.com мы используем все исторические данные (поиск пользователей, клики и оплаченные отели) за период от шести месяцев до одного года. Для этого типа деятельности полученные данные экспоненциальны из-за создания функций и отелей-кандидатов из k для каждого поиска по ключевому слову в определенном месте.

Предположим, что данные для обучения/проверки/тестирования за три месяца извлекут из нашей БД 18 миллионов строк данных (с 600 столбцами/признаками). Этот процесс извлечения данных потерпит неудачу, если у нас не будет достаточного объема памяти для хранения, прежде чем мы даже попытаемся провести обучение, проверку или тестирование. Тогда основными вопросами будут:

«Как нам масштабировать поиск данных, чтобы мы могли продолжить обучение модели? Можем ли мы сделать случайную выборку? Будет ли это достаточно репрезентативно для обучения модели?»

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

Масштабируемое моделирование

Чтобы масштабировать операции моделирования, необходимо учитывать два аспекта:

Масштабирование нашего процесса моделирования за счет добавления или удаления источников данных или добавления/удаления функций. Это часто связано с продолжением ваших проектов по науке о данных в организации, в то время как бизнес-цели и требования постоянно меняются с течением времени.
Масштабирование нашего процесса моделирования с целью более ранней конвергенции и работы с большим объемом обучающих данных. Большой объем данных требует большей ответственности за своевременное обучение модели. Одним из соображений, которое обычно применяют специалисты по данным, является рассмотрение параллелизма при обучении моделей. Некоторые алгоритмы предназначены для легкого распространения на несколько узлов для масштабируемого моделирования. Даже распараллеливание можно применять для перекрестной проверки, настройки гиперпараметров и выбора модели.

Масштабируемое производство и обслуживание моделей

Создание наилучшей модели на основе комплексного процесса оценки — не последняя глава для специалистов по обработке и анализу данных. Фактически, инженеры по машинному обучению будут тесно сотрудничать с учеными, занимающимися данными, чтобы раскрыть весь потенциал моделей ИИ, чтобы их можно было использовать для масштабного производства. Это самый важный этап для большинства специалистов по данным и инженеров по машинному обучению при разработке архитектуры, которая может масштабироваться для реальных производственных сценариев. Следовательно, есть несколько факторов (описанных ниже как вопросы), которые нам необходимо учитывать при внедрении моделей ИИ в качестве услуги:

Имеет ли значение скорость предсказания? Способствует ли модель высокой задержке как части глобального технологического рабочего процесса?
Нужно ли нам предварительно вычислять функции, результаты прогнозирования или рекомендации?
Как модель ИИ масштабируется для многих доменов? Типичный пример в OTA: «Подходят ли пайплайн, архитектура и модель для охвата нескольких стран, поскольку мы подготовили модель только для Индонезии?»
Как мы справляемся с возможным снижением производительности модели? Можем ли мы легко переобучить модель на основе самых последних исторических данных? Как часто мы должны переобучать модель ИИ?
Как мы справляемся с дрейфом концепций? В индустрии туризма изменение данных преобладает, особенно с изменениями в поведении людей, когда мы переходим от пандемии к эпохе эндемии для этих ковидных ситуаций. Один из способов помочь выявить такое отклонение концепции — иметь интегрированный инструмент для мониторинга данных и моделей в производственной среде.
Должны ли мы рассматривать различные эксперименты одновременно в производстве? Обычно эту ситуацию можно разрешить, настроив эксперимент A/B-тестирования или развернув теневые модели.

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

ССЫЛКИ:

Создание масштабных моделей ИИ для OTA

Вопросы по теме