Мэгги: Сага о детском переводчике, стартапе по искусственному интеллекту

Резюме TL;DR

• Я встретил одноклассника на парковке и связался с ним из-за потерянной 10-долларовой купюры. Чего я не знал, так это того, что мой одноклассник построил модель, которая переводит детский плач, и искал соучредителя. Благодаря Венчурной лаборатории доктора Питера Шермана мы смогли встретиться как деловые партнеры, найти место для работы и запустить нашу компанию.
• За несколько недель я построил сервер на основе модели и приложения для Android, которое родители могли использовать для перевода плача своего ребенка. Но задержка была ужасной — никто не хочет ждать, пока заработает сервер, или загружать аудиофайлы, держа плачущего ребенка на руках.
• Итак, мы решили поместить модель в приложение, но она была слишком велика, чтобы поместиться. Это означало уменьшение его размера за счет квантования без заметного снижения точности и выяснения того, как генерировать входные данные, необходимые модели, на устройстве, не вызывая сбоя приложения. Мы бы не справились без Пита Уордена , который дал нам бесценные советы по TensorFlow, Android и стартапам.
• Но теперь, когда модель была на устройстве, она была вне нашей досягаемости. Как мы измеряем его эффективность? Как выглядит успех? Я построил вокруг модели слой регистрации, мониторинга и отзывов пользователей, чтобы собрать всю информацию, необходимую для оценки производительности. Эти данные создали маховик; каждый перевод создавал новые помеченные обучающие данные — теперь мы увеличивали наш набор данных с минимальными усилиями.
• Когда приложение заработало и за ним следили, у нас возникла дилемма: показать один или несколько переводов? Инстинкт подсказывает, что нужно показать наиболее точный перевод — в конце концов, именно он, скорее всего, окажется правильным. Но что, если достоверность перевода составляет только 70%? А как насчет 60% или 50%? Это была тонкая проблема, которая помогла нам увидеть, как люди на самом деле используют приложение, и обнаружить убийственную функцию.
• Оказывается, очень сложно найти свой телефон и открыть приложение, пока ребенок плачет у вас на руках. Итак, мы сделали радионяню Homer с помощью умной колонки Google Home — переводы вручную.
• Однако умного динамика оказалось недостаточно, чтобы спасти нас. У нас кончились деньги и пар, жизненные обстоятельства вынудили нас вернуться домой, а наш малыш-переводчик был отложен на полку.

Предисловие

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

Что такое Мэгги?

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

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

У нас был один класс — «Обучение инженерному обслуживанию», где весь класс работал над сертификацией LEED для одного из зданий кампуса. Я помню его как беспечного парня, который приехал в класс на лонгборде. Наше первое общение произошло за пределами класса, на темной парковке продуктового магазина, где я увидел, как он собирался покататься на своем внедорожном велосипеде. Он припарковался рядом с моей машиной, и мы разговорились. Потом я заметил рядом с ним какую-то скомканную бумажку, поднял ее, заметил, что это деньги, и сказал ему, что он уронил свои деньги. Он сказал, что это не его, но я сказал ему оставить это себе. Мы не знали, сколько это было; на стоянке было слишком темно. 1, 10 или 100 долларов. Я сказал ему, что надеюсь, что это будет 100 долларов. Это было 10 долларов. Но это первое общение создало между нами такое доверие, что через несколько недель, когда мы оба работали в Venture Lab — инкубаторе стартапов в Калифорнийском университете в Мерседе, — он попросил меня создать приложение для развертывания его детского переводчика. Без Венчурной лаборатории мы бы никогда не подумали о сотрудничестве. Я, конечно, не стал рассказывать случайным одноклассникам, что создаю приложения для Android, и он не хвастался своей детской моделью перевода. В личных третьих пространствах есть магнетическая магия, которую не следует недооценивать.

У меня есть модель, и она работает. Что теперь?

Несмотря на построение работающей модели. Крис не мог понять, как его развернуть. Это было в начале 2017 года, и курсов или руководств, демонстрирующих это, было не так много. Его наставник в TensorFlow рекомендовал развертывание на Android, но изучение мобильной разработки было слишком далеким мостом. Я знал Android и установил несколько приложений в Play Store, но даже для меня это было натяжкой. Итак, я сделал простую вещь.

Я поместил модель на сервер и сделал к ней вызовы API. Выполнить модель на сервере Flask оказалось на удивление легко: импортируйте TensorFlow, загрузите модель с локального диска (я даже не думал о развертывании модели таким образом, чтобы ее можно было легко редактировать позже), и направьте запросы на это. Но были некоторые ошибки:

• Запрос необходимо было преобразовать во входные данные, ожидаемые моделью, и мы не создавали общий пакет для выполнения этой работы. Поскольку Крис обучал модель, а я создавал сервер, это стало источником ошибок.
• Первый запрос всегда был медленным; мы размещали сервер на AppEngine, и я оставил количество простаивающих серверов равным нулю (по умолчанию), потому что я никогда не работал с сервером, который требовал такой длительной настройки. Зачем тратить деньги на простаивающие серверы, если запуск новых серверов занимает всего секунду? Загрузка и запуск модели заняли много времени, поэтому нам приходилось держать наши серверы в режиме ожидания 24 часа в сутки, 7 дней в неделю. Вы не знаете, когда ребенок начнет плакать, а это означает, что счет за хостинг будет выше.
• Этот медленный старт сделал интеграционное тестирование большой головной болью, до такой степени, что я вернулся к ручному тестированию. Ждать несколько минут, пока пройдут тесты, было невыносимо. Быстрее было разогнать сервер с помощью горячей перезагрузки и вручную тестировать перед каждым коммитом.
• Развертывание и контроль версий были непростыми. Первоначально я развернул модель с помощью репозитория, потому что мне нужна была какая-то форма контроля версий, но быстро понял, что при этом приходится жертвовать простотой развертывания. Каждое обновление модели требовало развертывания сервера и перезапуска всего кластера, что занимало время, поскольку серверам приходилось загружать новую модель.

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

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

Куда поставить модель?

Мы потратили много времени на обсуждение того, где разместить модель. Нам нужна была скорость и надежность телефона, но нам хотелось безопасности и простоты развертывания сервера. Изначально размещение модели на сервере было привлекательным:

• Его было легко обновить и развернуть.
• Это не ограничивало количество пользователей — в то время только определенные версии Android поддерживали библиотеки вывода TensorFlow, поэтому размещение модели на телефоне означало меньшее количество пользователей.
• Он предлагал больше возможностей — API сервера могли использовать интеллектуальные колонки, веб-сайты и радионяни.
• Не нужно было беспокоиться о том, что кто-то украдет модель.

Но минусы продолжали накапливаться:

• Это было медленно; загрузка записей, их расшифровка и последующий запуск модели заняли много времени.
• Риск сбоя сделал приложение менее привлекательным — нашим пользователям требовалась 100% доступность; Самое привлекательное в приложении было то, что оно было рядом с вами, когда вашего супруга, родителей и т. д. не было — оно было рядом с вами, когда вы были наедине с загадочно плачущим ребенком.
• Это было дорого; машины, необходимые для выполнения всей этой работы, были дорогими для стартапа, которому нужно было использовать кредиты Google Cloud для оплаты всего.

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

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

Сказки с края

Установка модели на телефон сопровождалась горой технических сложностей. Некоторых из них сейчас не существует, но большинство существует. Мы были на острие. TensorFlow для Android едва вышел — публичный релиз состоялся в феврале 2017 года, а я писал приложение в марте. Но благодаря настойчивости и огромной помощи Пита Уордена из TensorFlow нам удалось заставить модель работать в приложении.

Первой проблемой было получение модели в пакете APK. В то время Android имел ограничение на размер APK-файла в 50 МБ и функцию расширения, которая позволяла приложениям увеличиваться в размерах за счет загрузки компонентов после установки. Однако я посчитал эту функцию расширения небезопасной, поскольку она подразумевала размещение модели на сервере. Итак, мы решили квантовать приложение — метод, который предполагает снижение точности всех входных и выходных данных каждого слоя.

В нашем случае мы преобразовали все числа с плавающей запятой в целые числа, что существенно уменьшило размер модели и сделало ее быстрее, но и снизило точность. Крис прошел несколько итераций модели с разными схемами квантования и, наконец, остановился на целочисленном квантовании, несмотря на снижение точности. Это было полезно, пока модель работала лучше, чем молодые родители. Бонус: это решило проблему с обновлением — загрузка сотен МБ данных при каждом обновлении модели была крутой, если использовать лимитное подключение к Интернету, но с несколькими МБ можно было справиться (сейчас мне это кажется глупым, поскольку люди сегодня регулярно загружают ГБ видеоконтента на свои телефоны). ).

Затем последовал длинный шлейф мелких проблем. Самым большим из них было то, что библиотеки БПФ, которые поддерживались различными версиями Java, поставляемыми с Android, не создавали ту же спектрограмму, на которой обучалась модель. Мы обучили модель с помощью библиотеки БПФ C++, и она создала спектрограммы разных цветов и размеров. Будучи секретными инструментами, версии C++ и Java были написаны непрозрачно и их было трудно модифицировать. Еще одно быстрое решение: мы решили переобучить модель с помощью спектрограмм Java FFT. Это означало преобразование всех аудиофайлов в спектрограммы, а затем запуск процесса обучения, который занял несколько дней на старом Macbook моего друга. Но проблема была решена, и я мог в это время сосредоточиться на чем-то другом.

Но приложение продолжало зависать и вылетать. Оказывается, загружать запись в память и затем создавать в ней спектрограмму было плохой идеей. Приложение потребляло много ресурсов телефона. Решением было сохранить на диск и транслировать. Сохранить на диск было легко; потоковая часть была сложной, потому что, как только звук покидал память, на диске с ним могло случиться что угодно. Другая программа может прочитать и изменить его; его можно удалить, он может не сохраниться и т. д.… Такие крайние случаи обычно не существуют в Интернете — у вас есть изолированный канал с вашим пользователем, но не на устройствах. Удостовериться, что для этого достаточно места, и очистить его после установки приложения оказалось неожиданной проблемой. Как я позже узнал, было бы необоснованным предположением полагать, что если в телефоне было достаточно памяти для установки вашего приложения, то на нем было бы достаточно памяти и для его запуска.

Наконец, противником было само устройство — телефоны Android оснащены самыми разными процессорами, объемами памяти и, что наиболее важно, микрофонами. Проблему с процессором и памятью можно решить, установив последнюю версию Android и надеясь на лучшее; худшим сценарием было бы медленное приложение — в Android невозможно напрямую установить требования к ресурсам. Настоящая проблема заключалась в учете различных качеств микрофонов: Android позволяет вам требовать микрофоны на устройствах, на которых установлено ваше приложение, но не тип микрофона.

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

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

Один или много?

Модель взяла спектрограммы и несколько других фрагментов информации, чтобы классифицировать звуки, которые издавал ребенок: голодный, некомфортный, страдающий от боли, сонный и газированный, таковы были переводы. Он вернул список всех возможных категорий, где каждая категория имела процентное значение, показывающее, насколько уверена модель в этом конкретном переводе. Все проценты в сумме дают 100 — если бы самый точный перевод был на уровне 90 %, то точность остальных пяти категорий составила бы в сумме 10 %.

Вначале мы столкнулись с вопросом: отображать ли все переводы (в порядке убывания точности) или только один. Я решил показать только один, потому что не хотел смущать людей большим количеством переводов, и его было проще создать (лень — краеугольный камень Agile). Однако мы столкнулись с проблемами с нашей первой группой пользователей.

Когда модель была достоверной (более 80%), предложение срабатывало — жалоб от родителей не поступало. Но не всегда это было так уверенно. Когда точность перевода была ниже 80%, тогда он был таким же хорошим, как родительский или угадывающий. Это противоречит цели приложения; он должен предлагать более точный перевод, чем панические попытки нового родителя успокоить своего ребенка. И это так, неудивительно, что второй и третий переводы оказались точными. Мы выяснили это посредством личных интервью: личные интервью немасштабируемы и отнимают много времени, но чрезвычайно насыщены информацией; если вы можете делать это ежедневно, делайте это. Ребенок плакал, и приложение с низкой достоверностью показывало неправильный перевод, но мы пробовали другие переводы (мы видели их в журналах), и они работали.

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

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

Люди почему-то склоняются к числу три. Данные показали, что уверенность модели в других переводах значительно упала после третьего перевода. Если бы первый перевод имел достоверность 70 %, второй имел бы 20 %, третий — 9 %, а остальные — ниже 1 %. Итак, мы отказались от этих переводов. Была небольшая вероятность того, что эти пропущенные переводы были точными, но их включение рисковало сделать приложение повторяющимся. Выбор заключался в том, что 1 из 100 пользователей получит неправильные переводы, или все пользователи увидят бесполезные переводы и подумают, что приложение угадывает. Это был простой выбор.

Конечно, оглядываясь назад, я должен был протестировать это с помощью многорукого бандита — выпустить пять разных версий приложения, по одной на каждый выбор, например, показать один перевод, показать два, показать три и т. д., и медленно мигрировать людей. на ту версию приложения, которая дала наилучшие результаты. Основным показателем успеха будет количество людей, которые нажали зеленую галочку (довольны переводом). Но на таком раннем этапе, я считаю, мы приняли правильное решение, и, что более важно, мы приняли решение правильным образом. Мы были непредвзяты, мы не считали ни одно решение конкретным (здесь нет эго), мы постоянно общались с нашими пользователями и прислушивались к ним, даже если это казалось неправильным.

Обучение на работе

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

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

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

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

Конец

Последним, что мы построили, был Гомер. Проведя десятки личных интервью с пользователями приложения и обзвонив еще больше людей, мы поняли, что искать свой телефон, разблокировать экран, находить наше приложение, открывать его и нажимать кнопку перевода, держа плачущего ребенка, сложно и неудобно. Почему нам потребовалось так много времени, чтобы это осознать? Мы были двумя одинокими бездетными парнями лет двадцати — я не могу вспомнить, когда в последний раз держал на руках ребенка, не говоря уже о том, чтобы успокаивать его плач. Итак, мы решили сделать радионяню с помощью умной колонки. Я заказал комплект у Raspberry Pi и построил собственный динамик Google Home с большой синей кнопкой сверху.

У Криса было отличное видение продажи этой модели компаниям, производящим радионяни, но мы не набирали обороты у этих компаний, так почему бы не создать собственную радионяню с использованием умного динамика? После создания Google Home я создал сценарий bash для запуска переводчика при запуске. Переводчик использовал SDK Google Home для перевода триггерной фразы «ОК, Google, переведи». Переводчик представлял собой скрипт Python, который считывал звук с микрофонов, превращал его в спектрограмму, а затем отправлял на сервер для перевода. Я сохранял гибкость, и это сработало ! Наконец-то у нас появилось наше потрясающее приложение, но оно не спасло компанию.

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

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

Если я чему-то и научился (кроме того, как сложно развертывать модели машинного обучения на Android), так это тому, что вам действительно нужно заботиться о проблеме, которую вы решаете. Вам нужно найти в себе смелость посвятить себя этому делу полный рабочий день, несмотря на финансовые риски и огромные альтернативные издержки. Я ни в коем случае не собирался бросать свою техническую работу, чтобы работать над этим. Мне нравилось помогать молодым родителям и отчаявшимся отцам; эту технологию было интересно изучать и создавать, но как я мог объяснить отцу, почему после окончания учебы я возвращался в нашу тесную квартиру в Секции 8? Как я мог отказаться от шестизначной зарплаты, прожив так долго на пособие по социальному обеспечению?

А как насчет венчурного капитала? Почему вы не попытались собрать деньги? Реальность такова, что венчурные капиталисты берут трубку только в том случае, если они знают вас, школу, в которой вы учились, или компанию, в которой вы работали. Их не волнует, что вы создали — если это не прибыльно, ваши инновации — это второстепенная деталь — венчурные капиталисты в первую очередь инвестируют в основателей и команды, а в последнюю очередь в продукты. Но большинство из них не знают, как выбирать хороших основателей или команды, поэтому они позволяют это делать приемным комиссиям элитных школ или FAANG.