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

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

Никогда не бывает так просто

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

Во-первых, каждый набор входных данных, отправленный клиентами, имеет свои уникальные характеристики. В нашем классификаторе продуктов часто встречается набор входных данных, используемых для описания одной и той же концепции - например, «Apple iPhone 5 32GB Space Gray 4GB RAM» против «iPhone 5» по сравнению с «бренд: модель Apple: iPhone5». При создании ваша модель вряд ли будет устойчива к этим тонкостям.

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

Виноваты наши звезды

Вы спросите, почему бы вам просто не создать более качественные наборы данных для обучения? Проблема в том, что не существует четкого способа заранее узнать, каков спектр возможностей. Чрезвычайно сложно предсказать каждую ментальную модель, которая может существовать у клиента. Сложно смоделировать все характеристики, которые может иметь набор данных. Учитывая количество задействованных параметров свободы, перестановки делают невозможным создание идеального набора обучающих данных, если он действительно существует.

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

1. Создание основы качества

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

2. Создание эвристической основы

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

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

Например, если команда по контролю качества предлагает переместить все мобильные телефоны с фразой phone case в названии в раздел Mobile Phones ›Accessories категория, инженер может выразить это в виде if (category == CAT_ORIGINAL and KEYWORD in name) then { category = CAT_NEW }. Переменные абстрагируются в электронные таблицы, которые команда QA может впоследствии напрямую заполнить.

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

3. Периодическая переподготовка

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

4. Поддержание качества и эвристика

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

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

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

Эта статья изначально была опубликована в Блоге Semantics3