Теперь я понимаю, почему тензорный поток имеет большое значение

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

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

Tensorflow может стать убийственным приложением для облака Google

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

ModelOps становится популярной

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

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

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

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

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

Разработчики моделей должны учитывать причинность или GTFO.

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

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

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

Так много о том, что скоро исчезнет. Возникает причинная связь.

У этого есть как минимум два аспекта:

  1. Выбор математических моделей, соответствующих основному процессу; и
  2. Моделирование частей базового процесса для создания полной модели, включающей известные причинно-следственные связи.

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

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

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

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

Unsexy Tech по-прежнему важен

Разрыв в возможностях становится все больше, а организации, пришедшие с опозданием, остаются позади.

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

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

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

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

Я подозреваю, что дешевым вариантом в этой области будут каталоги, привязанные к решениям для оркестровки, как в AWS Glue или Astronomer.io.

Сосредоточьтесь на бизнес-кейсе

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

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

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