Одна из основных задач для любой компании, основанной на данных, - как согласовать долгосрочную, менее гибкую разработку науки о данных с быстрой итерацией и циклами обучения в гибкой разработке программного обеспечения.
Традиционная разработка программного обеспечения может быть разбита на небольшие предсказуемые компоненты, которые можно тестировать и повторять быстро и модульно. Эта «гибкая» методология не применима напрямую в работе по развитию науки о данных, поскольку данные труднее получить, эксперименты с данными проходят медленнее и сложнее разбить части модели на модули. Наука о данных по своей сути в значительной степени ориентирована на исследования. Следовательно, существует внутреннее противоречие между углублением исследований и гибкостью.
В BrainQ мы разрабатываем набор инструментов искусственного интеллекта для определения спектральных паттернов мозговых волн и создаем персонализированные процедуры электромагнитного лечения, направленные на улучшение восстановления нервной системы при травмах спинного мозга и пациентах с инсультом. Традиционно такой процесс требует клинических испытаний и нескольких месяцев на выполнение с очень длинным циклом обратной связи. Как стартап на ранней стадии, мы не можем ждать так долго, чтобы скорректировать наши алгоритмы и стратегию продукта.
Медицинская компания, работающая на основе данных, как наша, преследует две цели: максимизировать эффективность и скорость работы нашей группы по анализу данных и быстро проверить как можно больше гипотез, не основанных на клинических испытаниях. Мы должны строго придерживаться того, какие эксперименты мы проводим и как; отсюда и потребность в новом типе гибкого и динамичного процесса.
В нашем стремлении разработать собственный процесс agile data science мы обнаружили несколько особенно сложных областей, а именно: A) сортировка приоритетных областей, B) количественная оценка команды / проекта data science, C) корректировка курса. Чтобы решить эти проблемы, мы разработали процесс, в результате которого наша команда по анализу данных смогла планировать будущие эксперименты в течение дня после получения первых данных (что для нас очень важно!).
А) Определение приоритетных направлений
Как стартап, управляемый данными, выбирает, какие области должны быть приоритетными для команды по анализу данных с ограниченными ресурсами?
Для определения приоритетных областей необходимо собрать следующую информацию для каждого предлагаемого эксперимента:
- Гипотеза: каждый предлагаемый эксперимент должен начинаться с четкой письменной гипотезы, которая служит конкретной цели продукта / бизнеса. Например, при выполнении классификации данных ЭЭГ для пациентов с инсультом гипотеза может заключаться в том, что применение определенной архитектуры CNN может повысить точность классификации на количественно измеримую величину.
- Ценностное предложение: какое ценностное предложение (ориентированное на клиента) связано с этой гипотезой? У вас всегда должен быть хороший ответ на вопрос: «Если предположить, что гипотеза верна, почему клиент заботится?»
- Необходимые ресурсы: разные эксперименты потребуют разного времени от команды специалистов по анализу данных. Вопросы, на которые нужно ответить: «Сколько ресурсов необходимо для А) доказательства / опровержения гипотезы и Б) в случае успеха, развертывания функции / модели в соответствующем масштабе?»
В «списке желаний» неизбежно будет больше экспериментов, чем может выполнить команда специалистов по анализу данных (и компания может позволить себе инвестировать в них), но если в каждом предложенном эксперименте будут записаны эти три вещи, процесс расстановки приоритетов станет намного проще. .
Хотя это может показаться очевидным, тщательное оформление их в письменной форме помогает командам по анализу данных быть более гибкими, ограничивая объем, помогая команде сосредоточиться и составляя отчет об обосновании и результатах экспериментов, а также документируя, почему другие эксперименты не проводились. преследовали.
Б) Количественная оценка команды / проекта по анализу данных
После того, как команда установила приоритеты и согласовала наиболее важные области, каков процесс сравнения команды с внутренними целями, особенно до завершения экспериментов?
Как и в случае гибкой разработки программного обеспечения, команды должны стремиться к маленьким шагам, когда успехи измеряются в соответствии с планом на еженедельной основе и могут быть сделаны поворотные действия. Эти короткие циклы обучения необходимы, поскольку постоянно поступают новые данные, которые подтверждают или опровергают первоначальные предположения, сделанные во время начала эксперимента. Объединение новых данных с исходными предположениями и масштабами экспериментов - это больше искусство, чем наука. Цель здесь - избежать «неубедительного» результата - худшего из возможных результатов дорогостоящих экспериментов.
Мы обнаружили, что можем лучше оценивать работу нашей группы по анализу данных, когда максимально модулируем компоненты экспериментов. Например, один из факторов, который может повлиять на измерение ЭЭГ, - это расположение датчика на голове. Если у кого-то густые волосы, в сигнатуре ЭЭГ могут быть артефакты по сравнению с тем, у кого нет волос. Сегментирование экспериментов на основе подобных факторов помогает нам понять основные причины и оценить, почему модель ведет себя именно так.
В) Корректировка курса
Поскольку стартапы постоянно принимают решения на основе ограниченной информации, одним из наиболее важных навыков команды Agile Data Science является способность корректировать курс на основе новой информации в режиме реального времени. Для компании, ориентированной на данные, раннее обнаружение того, что не работает, не менее важно, чем обнаружение того, что работает. На карту поставлено большее - если некоторые из ранних фундаментальных предположений ошибочны, вы хотите узнать об этом как можно раньше, чтобы не тратить зря время, отвечая на неправильные вопросы. Если гипотеза не верна, мы делаем все возможное, чтобы быстро понять, почему, и как можно скорее исправить или «развернуть» курс.
Что касается BrainQ, мы обнаружили, что информация, которая заставляет нас корректировать курс, обычно разделена на три категории:
- Продукт: Получили ли мы какую-либо новую информацию, которая меняет наши предположения о требованиях к продукту? Этот тип информации может поступать в результате взаимодействия с конечным потребителем / пользователем, обычно принадлежащим PM.
- Достоверность данных: есть ли какие-либо сигналы, которые могут заставить нас поверить в то, что в стратегии сбора данных есть изъян? Этот тип информации может быть получен при попытке повторить тест на данном пациенте и невозможности воспроизвести результаты.
- Алгоритм: если предположить, что данные «верны» (без смещения / артефактов), достаточно ли надежен алгоритм для получения желаемой информации, например, точности классификации? Насколько хрупкая модель?
В высококонкурентном и быстро меняющемся пространстве стартапов организация не имеет права сидеть и ждать обратной связи. Если вы не будете постоянно проверять и не повторять свой подход, скорее всего, вы не выживете. Гибкая методология позволяет стартапам сохранять гибкость и скорость при выходе на рынок, даже если они внедряют машинное обучение / науку о данных в свои продукты и компании.
О BrainQ
Миссия BrainQ - помочь парализованным людям после нервной травмы снова встать на ноги, восстанавливая их способность выполнять повседневные дела. BrainQ в настоящее время проводит клинические испытания в ведущих больницах Израиля.
Компания разрабатывает медицинское устройство, которое использует инструменты искусственного интеллекта для определения спектральных паттернов высокого разрешения в мозговых волнах пациента, наблюдаемых с помощью датчиков электроэнцефалограммы (ЭЭГ). Затем эти шаблоны преобразуются в индивидуальный протокол электромагнитного лечения, направленный на обеспечение целевой нейропластичности и ускорение выздоровления пациента.
BrainQ участвовал в первом классе Google Developers Launchpad Studio, посвященном приложениям машинного обучения в здравоохранении и биотехнологиях.
