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

Можем ли мы сейчас заняться машинным обучением, пожалуйста?

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

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

Вот некоторые из проблем масштабирования, с которыми нам пришлось столкнуться при обучении отдельных моделей (в произвольном порядке):

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

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

Есть и другие проблемы, связанные с масштабированием, которые нам пришлось решить позже, которые мы сознательно решили зарегистрировать в разделе «приемлемый технический долг на данный момент»:

  • Переключение на потоковую передачу данных, чтобы не использовать сотни ГБ памяти
  • Использование бессерверного обучения (в итоге мы сделали это на платформе GCP AI)
  • Автоматизация расчета показателей по разным частям набора данных (например, получение производительности для каждого клиента)
  • Автоматическое обнаружение утечки данных между обучающим и тестовым набором - у нас был особый случай, когда можно было получить повторяющиеся экземпляры в обоих.

Создание продукта

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

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

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

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

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

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

Заключение

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

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

Связаться

Если вы думаете, что заниматься машинным обучением в больших масштабах - это увлекательно, мы нанимаем! Посмотрите текущие возможности на nplan.io/careers.

Вы также можете связаться с нами на сайтах twitter.com/nplanHQ и twitter.com/nitbix.