Данные, о которых я задумался до построения модели

ИИ рекомендаций система, что я рассматривал до выбора модели — это данные -

-для проекта Banjang Note специфичные требования к данным и критерии фильтрации , которые я рассмотрел -

1. Почему я не стал сначала выбирать модель

При подготовке системы рекомендаций на основе ИИ многие в первую очередь думают о коллаборативной фильтрации или моделях глубокого обучения. Меня тоже интересовало, какие методы рекомендаций мы могли бы использовать, но в проекте Banjang Note я сначала обратил внимание не на алгоритм, а на данные.

На тот момент у нас ещё не было накоплено ни истории поведения пользователей, ни обучающих данных, необходимых для рекомендаций. Мы могли рассматривать такие характеристики, как профессия, опыт и зарплата, которые сервис мог бы собирать, но у нас не было записей о том, что пользователи выбирали на самом деле и к каким результатам это приводило. В итоге нам не хватало данных, необходимых для обучения модели или сравнения её производительности.

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

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

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

2. Сравнение моделей рекомендаций с точки зрения данных

Для разных методов рекомендаций требуются разные типы информации. Сравнение характеристик профилей, сопоставление моделей поведения пользователей и обучение на реальных запросах или результатах принятия предложений — всё это зависит от источника данных. Поэтому вместо того, чтобы сосредоточиться на общих преимуществах и недостатках алгоритмов, я изучил, какие данные должны быть доступны для их работы в проекте Banjang Note.

Рекомендации на основе атрибутов: наличие информации не обязательно означает наличие предпочтений

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

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

Коллаборативная фильтрация: большого количества пользователей недостаточно

Коллаборативная фильтрация была одним из подходов, которые нам особенно хотелось изучить. Если несколько координаторов проявляют интерес к одним и тем же прорабам или отправляют им запросы, можно попытаться использовать сходство их предпочтений, которое не видно только по профилям. Для этого нужна история, связывающая «какой координатор взаимодействовал с каким прорабом».

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

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

Обучение с учителем: поведение, которое нельзя свести к единственному «правильному ответу»

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

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

Поэтому мы решили не выбирать заранее одну модель обучения с учителем, а отдельно записывать запросы, ответы и итоговые результаты. Это позволит позднее сравнить целевые переменные для предсказания с учётом распределения и объёма доступных данных. Именно поэтому, изучая потенциальные модели, мы в первую очередь сосредоточились на сборе данных.

3. Мы решили не учитывать обязательные требования в оценках рекомендаций

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

Например, кандидат с другой профессией или не соответствующий минимальному требованию к опыту не подходит для рекомендации, как бы хороши ни были его другие характеристики. Если включить такие требования в взвешенную оценку, кандидаты, не соответствующие обязательным условиям, могут занять высокие позиции благодаря хорошим результатам по другим факторам. Это означает, что ограничения сервиса нарушаются ещё до того, как возникает вопрос о качестве рекомендаций.

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

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

Если необходимые сведения отсутствуют и невозможно определить, выполнены ли условия, не следует просто считать, что кандидат прошёл отбор. Порядок проверки и обработки таких исключений — критерий валидации, который необходимо определить отдельно при фактической реализации фильтра. В ходе рассмотрения проекта стало ясно, что обязательные условия предметной области нужно установить до выбора модели.

4. Размышления о модели изменили подход к вопросу «что записывать»

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

Профили и опросы: могут ли эти сведения стать признаками?

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

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

Впечатления, выбор и ответы: не записывайте их как одно и то же поведение

В поведенческих данных особенно важно значение «отсутствия записи». Кандидата могли не запросить, потому что он не подошёл, но возможно и то, что он вообще не появлялся в списке рекомендаций. Также необходимо различать ситуацию, когда сервер сформировал список, и ситуацию, когда кандидат действительно был показан на экране.

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

Например, если пометить случай как «нежелательный, потому что кандидат не запрашивал это», основываясь только на истории прошлых запросов, в обучающие данные могут попасть ошибки. То же относится к случаям, когда руководителя фактически никогда не спрашивали, но их считают «отклонёнными». Чтобы позднее определить отрицательные примеры при обучении модели, нам необходимо как минимум уметь различать наблюдаемое поведение и состояние, которое не наблюдалось.

Состояние на момент рекомендации: значения, изменившиеся позже, нельзя использовать для объяснения прошлого

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

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

5. Что мы решили, а что ещё не решили

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

С другой стороны, мы ещё не решили, как упорядочивать кандидатов, прошедших фильтр. Может подойти рекомендация на основе атрибутов; также мы могли бы рассмотреть коллаборативную фильтрацию, когда накопится достаточно взаимодействий. Когда накопится достаточно фактических случаев запросов и принятия предложений и станет понятно значение меток, можно будет также сравнить методы ранжирования на основе обучения с учителем. Определить подходящий метод сложно, не изучив предварительно фактические данные.

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

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

6. Заключение

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

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

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

Данные без рекомендательной системы сначала - технический выбор, какую модель использовать а что наблюдать и записывать определить было.

Yэон