На заре Интернета были «разработчики», которые отвечали за написание «кода». После того, как эти коды будут написаны, они будут переданы «операционному» персоналу, и вы знаете, на самом деле, веб-сайты, которые предприятия используют для зарабатывания денег, в то время находились в ведении этого эксплуатационного и обслуживающего персонала, такие как система администраторы, сотрудники центров обработки данных, администраторы баз данных (чуть не забыл, что они все еще существуют, администраторы баз данных, привет!). В то время управление выпуском веб-сайта подчинялось очень строгим правилам, процесс тестирования был болезненным, а выпуск любого нового контента должен был пройти утомительный процесс.
Помните тест Джоэла? Да, подсчитано, что те, кто слышал об этом, - инженеры-«старики» в возрасте от тридцати до сорока лет.
Если вы ответили «нет» ни на один из вопросов теста, это означает, что что-то не так с культурой вашей команды.
Используете ли вы систему контроля версий?Многие инженеры часто беспокоятся о том, что они могут (или взломали) чужой код. Например, весь код теряется из-за сбоя жесткого диска.
Могу ли я начать строительство одним щелчком мыши?У инженеров всегда есть больше или меньше времени на строительство. Чем больше шагов необходимо выполнить, тем выше вероятность ошибок, но чем меньше билдов генерируется, тем медленнее будет тестироваться новый код.
Делать ежедневные сборки?Если сборка пойдет не так, это может занять некоторое время, чтобы это заметить. (Теперь, когда все начали непрерывную интеграцию, это не ново!)
Есть ли база ошибок?Электронные письма, стикеры, телефонные звонки от разгневанных клиентов и «деловых» партнеров... Всегда есть ошибки, о которых забывают. Есть также много ошибок, которые должным образом не задокументированы или даже не воспроизведены.
Исправляете ли вы ошибки перед написанием нового кода?Технический долг замедляет выпуск новых функций. Если весь проект рефакторинга кодовой базы передается небольшой команде, на его завершение может уйти год.
Есть ли расписание, которое всегда актуально?Конкретная дата не имеет значения, и она будет завершена, когда это будет необходимо. Когда вы делаете случайные оценки, вы должны учитывать такие вопросы.
Определены ли конкретные характеристики?Инженеры думают вместо продакт-менеджеров, но что будет, когда это будет сделано? "Это совсем не то, что я хочу! Можно ли реализовать другую функцию?"
Могут ли программисты получить спокойную рабочую среду?Пошли пить кофе! Эй, что именно мне делать с чем-то? Боже, ты читал это письмо от отдела кадров? Некоторые инженеры спросили компанию, могут ли они заплатить за свои гарнитуры, и HR им отказали.
Вы уже используете лучшие инструменты на рынке?Инженеры, которые любят жаловаться, часто не очень эффективны.
У вас есть тестеры?Количество ошибок, как правило, выше.
Писал ли новый рекрутер код во время собеседования?Иногда в команде есть люди, чьи резюме пестрят модными ключевыми словами, но они даже не могут выучить новый язык программирования для решения конкретной задачи на работе.
Будет ли юзабилити-тестирование?Инженеры разрабатывают функцию, но через несколько месяцев выясняют, что пользователям она совсем не нравится. Это приводит к классической «проблеме простоты использования».
У всех этих проблем есть одна общая черта: они замедляют работу инженерной команды. Скорость, с которой доступное программное обеспечение выпускается для пользователей, медленнее, скорость обратной связи с пользователями медленнее, скорость инноваций продукта медленнее, а скорость, с которой предприятия создают ценность для клиентов, медленнее.
Конкуренты, которые смогут быстрее создать ценность для пользователей, в конечном итоге превзойдут себя. Это все, вероятно, потому, что вы не используете систему сборки.
На первый взгляд проблема может показаться тривиальной. Эти проблемы со временем стали оказывать все большее влияние. Что касается технического прогресса, мы склонны иметь интуитивное линейное представление о развитии, например, думая, что темпы развития сегодня могут предсказать темпы развития в будущем. Если доставка программного обеспечения со временем замедляется в геометрической прогрессии, мы недооцениваем, насколько медленнее будет доставка в будущем из-за такого линейного подхода.
Для более качественного контента, пожалуйста, обратите внимание на паблик WeChat "AI Frontline", (ID: ai-front)
Так родилось agile-сообщество, основанное на концепции «Velocity». Это диагностический показатель того, насколько быстро команда может выпустить сложный код на основе существующей кодовой базы. В конце каждого спринта добавляются Story Points для измерения скорости команды. Если скорость снижена, значит, команда медленнее публикует сложные «истории», поэтому можно считать, что имеет место неверная ориентация. Примите меры сейчас!
Проблема в том, что скорость зависит от многих вещей. Трудно понять, что делать, чтобы подтолкнуть его в правильном направлении. Нет сомнения, что решение этой проблемы потребует времени, и все, казалось бы, простые и быстрые решения (например, расширение команды) не могут решить основную проблему.
И это не только обязанность инженеров создавать продукты. Руководители проектов, UX-команды, дизайнеры — все несут ответственность! Трудно использовать такую метрику, как «достаточно ли мы быстры», чтобы измерить каждый аспект процесса создания продукта в общих чертах. Velocity не полностью охватывает все это, и мы все еще можем создавать продукты, которые людям не нужны.
Затем появился бережливый стартап.
Методология бережливого стартапа
Есть идея для продукта? Сделайте предположения > Создайте минимально жизнеспособный продукт (MVP) > Проверьте свои предположения. Выполните весь процесс (то есть одну итерацию) как можно быстрее.
Люди, ответственные за создание продукта, наконец-то видят признаки. Скорость важна. Важна скорость итерации.
Быстрая итерация = успех. Особенно это касается области машинного обучения.
Наш технический директор Прашаст, который разработал несколько инструментов, используемых Google для создания производственных систем машинного обучения, считает, что любая конфигурация машинного обучения должна обеспечивать быструю итерацию, и объясняет это следующим образом:
Вы не можете просто «заниматься машинным обучением» и думать, что все заработает волшебным образом. Менталитет «тренируйся и забывай» означает, что модель быстро устареет. Продукты меняются, пользователи меняются, поведение меняется. На самом деле, непрерывные экспериментальные исследования и усовершенствования — это долгий путь. Сначала вам нужно попробовать простые вещи, а затем попробовать разные функции модели. Данные не всегда чистые, нужно экспериментировать с разными моделями, а потом проводить A/B-тестирование. Ошибки неизбежны в производственной среде, и для правильной работы могут потребоваться месяцы постоянной настройки.
Как только вы начнете, вам нужно думать об этом как о программном проекте. Нужно построить, протестировать, развернуть, повторить. Результаты уточняются с каждым циклом итерации. Чем больше итераций вы сможете выполнить, тем быстрее будет усовершенствована ваша среда машинного обучения.
Чтобы проверить это утверждение, мы поговорили с командой специалистов по обработке и анализу данных о том, как они используют методы машинного обучения. Как вы могли догадаться, эта команда охватывает широкий спектр областей, а чрезвычайно сложные команды обрабатывают петабайты данных, каждый день выдавая миллиарды прогнозов, которые используются другими командами для обучения собственной модели.
Конечно, зрелые команды готовы к быстрым итерациям. Примером может служить внутренняя платформа машинного обучения Uber.
Однако этим командам не всегда нравится это делать, и кажется, что вся команда проходит через кривую просветления.
О чем это говорит: Большие данные похожи на подростковые пощечины: все говорят, никто не знает, что делать, все думают, что все делают то же самое, и все утверждают, что это делают они…
То же самое относится и к машинному обучению!
В связи с этим практики различных организаций можно разделить на два типа. Один тип использовал подход «бережливый ИИ», другой — подход «я читал статью, в которой говорилось, что нам нужно создать собственную стратегию ИИ».
Большинство команд проходят эту кривую инициации, потому что создание культуры ИИ — это путешествие. Команды должны начать с простых вещей, которые могут быть реализованы быстро, чтобы продемонстрировать ценность и дальнейшее развитие. В большинстве случаев начать работу над ИИ означает отступить от кривой. Команды могут тратить много времени на обработку всех данных, очистку и переосмысление инфраструктуры данных просто потому, что эти факторы тормозят работу ИИ.
Команды, которые прыгают прямо в середину кривой, думая: «Теперь, когда у нас есть стратегия ИИ, давайте просто создадим платформу машинного обучения», обычно терпят неудачу. Эта практика увеличивает разрыв между командой продукта (включая специалистов по данным!) и советом директоров. Неудивительно, что специалисты по данным разочарованы, и многие компании начинают испытывать проблемы с холодным запуском ИИ.
Хотите создать культуру ИИ? Затем тщательно пройдите каждый шаг кривой и повторите все быстрее.
Некоторые из способов, которыми команды ИИ могут ускорить итерацию, включают:
Чистые, правильно маркированные и достаточно непротиворечивые данные.
Механизм обучения и развертывания модели в один клик.
Наука о данных самообслуживания. Уменьшите инженерную зависимость итерации от самой модели, например, попробуйте новые функции, создайте новые модели и автоматически оптимизируйте гиперпараметры.
Предоставляет масштабируемую высокопроизводительную систему для доступа к данным, манипулирования данными, обучения модели кластеризации, развертывания модели и экспериментирования, запросов онлайн-прогнозирования и оценки кандидатов.
Операторы инфраструктуры рассматривают специалистов по обработке и анализу данных как «граждан первого класса», которые используют их работу.
Среда машинного обучения разработки, идентичная рабочей среде машинного обучения.
Тест Джоэла, который мы используем для измерения культуры команды ИИ, выглядит следующим образом:
Версируйте конвейер данных и сделайте его воспроизводимым.
Убедитесь, что конвейер можно (пере)создать одним щелчком мыши.
Развертывание в рабочей среде с минимальной инженерной помощью.
Успешная система машинного обучения — это долгая игра, в которую можно играть, только играя по правилам игры.
Непрерывное улучшение. Экспериментирование и повторение — это рабочая этика.
Поэтому мы разработали Blurr (https://github.com/productml/blurr). Объединение данных, их обработка, очистка и смешивание для нужд машинного обучения недостаточно, чтобы сделать это один раз. Это основа любой работы с ИИ, и постоянное совершенствование на его основе имеет решающее значение для любой успешной культуры ИИ. Blurr предоставляет высокоуровневый язык на основе YAML для ученых/инженеров, занимающихся данными, для определения преобразований данных. То, на что ушло бы 2 дня с кодом Spark, можно сделать за 5 минут с помощью Blurr.
Blurr имеет открытый исходный код, потому что мы считаем, что подход с открытым исходным кодом может способствовать инновациям во всех областях ИИ. Разработка технологии даже доступна для всех, а наши еженедельные спринты публикуются на GitHub для всеобщего обозрения.
Рынок инструментов DevOps существует для того, чтобы мы могли быстрее выпускать программное обеспечение.
Наше видение — создать рынок для MLOps, который поможет командам быстрее выпускать продукты машинного обучения, и Blurr — наш первый шаг к этой цели. Потому что самая большая проблема на данный момент — это именно итерация самих данных.
- У нас культура, основанная на данных. ИИ исходит из данных, поэтому у нас есть культура ИИ!
- Нет, на самом деле не было.
«Управление данными» может только устранить человеческую предвзятость при принятии решений. Время загрузки приложения — это плохо? Эта новая модель лучше оригинала? Посмотрите на данные, прежде чем говорить!
Культура искусственного интеллекта — это культура, основанная на алгоритмах, в которой люди создают машины, способные принимать решения в производственной среде, и развертывают алгоритмы для достижения того, чего пытаются достичь люди (улучшение кликабельности рекламы, коэффициента конверсии, вовлеченности и т. д.).
Культура ИИ может быть хорошо адаптирована к вероятностным суждениям. Рекомендация этого продукта на 60 % более привлекательна для клиентов, чем рекомендация этого продукта; в 40 % случаев ситуация не становится лучше. Звучит как отличный вывод, не так ли? Тогда начинайте и продолжайте совершенствоваться!
Культура ИИ предполагает непрерывные эксперименты и итерации. Все остальные части организации должны его поддерживать.
Люди сложны. Когда мы сами можем принимать только случайные решения, даже с учетом распознавания образов и когнитивных искажений, мы ожидаем от машин детерминированного поведения. Люди управляют бизнесом и разыгрывают трюки, и эти ситуации могут сильно разочаровывать нас при построении культуры ИИ.
Это заставляет меня задаться вопросом, что люди (и изобретенные людьми социальные структуры, такие как корпорации) будут делать, столкнувшись со сверхразумными машинами. Добро пожаловать в 2029 год!
Blurr выпустил предварительную версию для разработчиков, вы можете посетить GitHub, чтобы узнать больше и поставить звезду проекту!
Прочитайте оригинальный английский текст:
https://hackernoon.com/how-to-build-ai-culture-go-through-the-curve-of-enlightenment-21c239c1d5a7