Уродливая математика в машинном обучении или чему нам стоит поучиться у деривативов?
Когда слушаешь доклады на больших ML-конференциях, то часть докладов вызывает восторг, но другая часть на послевкусии вызывает странное чувство. Да, доклад может быть очень крутым, математика блестящей, сложность крышесносной, но что-то как будто бы не так.
На 20ом промпте вышло то, что надо!
Эта статья — развлекательно-философская, все совпадения с реальностью — случайны, персонажи вымышлены, с точкой зрения — можно не соглашаться, но поразмышлять — стоит.
Да при чем здесь вообще деривативы? А просто у деривативов, дженги и машинного обучения — много общего, давайте разбираться.
Кратко о деривативах в качестве вступления
Термин «деривативы» относится к финансовому миру и обознает любой производный инструмент на основе базового актива, а если совсем упростить на пальцах, это договоренность через арбитра что-то сделать в отношении чего-то на каких-то условиях.
Например, у нас есть бананы. Можно просто купить бананы здесь и сейчас по какой-то цене — это будет прямая сделка. Но как только мы начинаем договориваться о сложных условиях покупки бананов, например, желая зафиксировать цену на следующий год при продаже частями или зарезервировать за собой право покупки при снижении цены, это уже будет сложной сделкой.
Базовый актив здесь — бананы, а набор условий поверх — и есть дериватив.
Деривативы могут быть очень сложными. Например, мы хотим купить бананы за цену меньше текущей на 10%, но только в июле и только при условии, что картофель не подорожает, а другие покупатели одновременно не купят помидоры по цене меньше 20% текущих цен. Деривативы могут быть ОЧЕНЬ сложными, и в них заложен запредельный уровень математики.
Монстр-дериватив на основе бананов может выглядеть так!
Математика внутри настолько сложна, что на заре появления деривативов самые крупные банки планеты соревновались за гениальные умы, щедро перебивая любые выставленные цифры зарплат. Индустрию пытались «залить математикой».
Математика же снаружи была настолько изящна, что позволяет маркетингу банков и брокеров упаковывать безумно сложные продукты в очень простые лозунги и продавать их множеству корпоративных клиентов на триллионы денег.
Вера в гениальность очаровывает. Вера в математику — подкупает. Но деривативы — смертельно опасны, потому что никто, кроме авторов и редких исключений, до конца не понимает, что именно в них заложено.
Еще один вариант монстр-дериватива на бананах
Именно по этой причине деривативы безжалостно убивают множество желающих с ними заигрывать, в том числе профильных спецов, таких как старейший банк Англии, который работал 230 лет, а потом на деривативах вслыл пузом кверху.
Ни слова больше, нужна картинка дженги.
Для устойчивости дженги не обязательно должны быть идеальны все блоки
О математике (как обобщении всего, с ней связанного) в ML
Если вы дотянули до этой части — спасибо!
Машинное обучение похоже на деривативы тем, что в индустрии так же есть очарованность «математикой», многие задачи пытаются просто «залить математикой», хотя сам процесс создания технологий не коррелирует напрямую с количеством и мощностью математиков в команде. Как и в деривативах, процесс скорее идентичен построению башни в игре «дженга» — одни блоки кладутся на другие и баланс новых блоков зависит от устойчивости всей предыдущей конструкции.
Причем, аналогия с дженгой гораздо более удачна, нежели с обычной пирамидой или башней, потому что дженга устойчива к неидеальности бытия, то есть все же позволяет совершить некоторое количество ошибок в процессах, в целом сохраняя устойчивость всей системы.
Но чем больше промахов было совершено ближе к низу пирамиды, тем меньше шансов на дальнейшую устойчивость и построение башни ввысь. В технологиях — точно так же, и «нижние блоки» — они не про математику.
Большинство задач, которые мы пытаемся решить машинным обучением, (если оочень огрубить) проходят через несколько одинаковых этапов:
Постановка задачи
Выбор магистрального решения
Сбор датасета
Разметка данных
Построение модели
Да, этапы очень условны, так как задачи бывают у всех разные и много нюансов, часто этапы вообще едва различимы, часто с одного этапа можно возвращаться на другой или безудержно скакать между ними много раз, но я все же попытаюсь описать максимально средний процесс.
Еще одним плюсом сравнения именно с дженгой является то, что в ней нет явных доминирующих блоков, в том смысле, что в ней нельзя особенно усилить какой-то отдельный блок, они равноценны по ширине, но каждый все же следующий зависит от предыдущего и всей конструкции в целом.
Хорошая технология — как дженга, где каждый этап может быть неидеален, но нужен для следующего
Сначала я расписал все этапы последовательно, но гораздо прикольнее их будет перевернуть.
5 — Построение модели
Картинка как иллюстрация к процессу построения модельки
Хардкор! Часто — сильная математика, множество экспериментов, самая мякотка и вишенка на торте технологий. То, о чем часто рассказывают на конфах. Трансформеры, GANы, тензоры, перцептроны, все очень сложно, круто, математично.
Это самая интересная часть. Строить модель — всегда интересно, ну потому что это сложно и азартно. Здесь есть дофаминовый азарт — вытянуть максимум из того, что у нас есть. Просто дайте нам датасет — и мы все сделаем.
Без шуток — строить модели действительно сложно, интересно, азартно и круто.
4 — Разметка данных
Гномы-разметчики на конвейрной ленте задач
Разметка — это присвоение неких признаков вашим данным. Например, выделение на картинке объекта или транскрибация аудио в текст.
Разметка, по моим субъективным ощущениям (я с ней связан напрямую) — самый нелюбимый всеми процесс. Он сильно менее интеллектуальный и от того сильно менее интересный. К сожалению, у некоторых команд есть представление, что разметка это нечто разовое и легкое, «все же понятно» и что можно просто описать в несколько предложений задачу ассесорам и AI-тренерам и сразу получить результат на блюдечке.
В сильных командах понимание того, что разметка важна, уже обычно набито опытом. Весь процесс разметки — максимально итеративный. Сделали — проанализировали — внесли правки — размечаем дальше и так далее и по кругу много-много раз.
В процессе промежуточного анализа будут всплывать граничные, субъективные и просто сложные случаи и для хорошего результата это нужно анализировать и вовремя корректировать задачу разметчикам. Хорошая разметка напрямую зависит от качества собранного датасета, а также от понятной и однозначной инструкции разметчикам.
Если бы все было легко и всем все было бы сразу понятно, то и кассиры бы повально не спрашивали бы паспорт у уже давно совершеннолетних людей ツ
3 — Сбор датасета
Робот собирает датасет с крестьян
Здесь возможны варианты. Возможно, датасет у вас уже есть (если данные от бизнеса), а возможно его придется формировать с нуля, если задача специфичная. От датасета требуется, чтобы он был достаточного размера, вариативен (часто так, но не всегда) и максимально соответствовал поставленной задаче. «Чистку» датасета можно отнести как к процессу сбора, так и к разметке, зависит от задачи.
Датасет должен быть максимально релевантен поставленной задаче. Например, если мы собираемся в нашей технологии убирать шумы из реальной жизни, то набор идеальных студийных записей нам не очень подходит.
2 — Выбор магистрального решения
Как и в ремонте — выбор правильного инструмента очень важен
На этом шаге обычно происходит анализ того, каким способами можно решить поставленную задачу. Здесь очень часто можно свернуть не туда. Потому что кто-то, возможно, уже решил наш класс задач, а мы про это или не знаем или сознательно хотим свой велосипед.
Свой велосипед это хорошо, если он оправдан, и мы точно-точно знаем, почему нам нужен именно он.
Мой любимый пример случился у коллеги на собеседовании в большую всем известную компанию. Head of CV (или как-то так) одной из команд во вступлении к вопросу рассказал, что они в своем маркете на складе распознают штрих-код какой-то навороченной нейронкой, но на встречный вопрос зачем для распознавания статичного штрих-кода вообще нужна нейронка — ответить не смог.
Эта задача настолько давно решена классической математикой, что некоторые ML-инженеры банально родились позже, чем решение распознавания штрих-кода увидело свет. Безусловно, есть ситуации, когда сканировать стоит нейронкой, но такие ситуации надо знать, как и все причины такого решения. Потому что прицепить что-то сложное туда, где можно обойтись простым — это некрасиво. Улучшать что-то сложное, не понимая мотивов и исходной проблемы — некрасиво.
Конечно, я немного утрирую, но этап выбора решения очень важен и обязательно нужно делать минимальный анализ для выбора направления, в котором мы собираемся двигаться. Потому что здесь очень легко направить все усилия не туда и сжечь кучу ресурсов. И да, это не очень актуально для r&d, потому что они как раз-таки могут подвергать сомнениям проверенные решения, работа такая.
1 — Постановка задачи
Точность поставленной задачи
Постановка задачи — фундамент во всех смыслах. Осмыслению задачи часто уделяют не так много времени и глубины, как оно того заслуживает. Под постановкой задачи я подразумеваю детализацию того, что мы хотим сделать. Бывает так, что мы точно (вот прям точно-точно) знаем, что мы хотим решить, а бывает, что задача поставленно максимально абстрактно.
Чем глубже и лучше мы понимаем, что именно мы хотим сделать и в каких условиях, тем больше шансов на конечный успех. К сожалению, на этом этапе, помимо просто здравого смысла, очень важен опыт решения похожих задач или некая технологическая «насмотренность».
Если вы уже сделали пять распознавалок лица для разных случаев, то для новой такой задачи будет очень легко задать заказчику большинство важных вопросов, доуточнив что именно, как и где должно работать. Но если у вас такого опыта нет, то придется мыслить максимально широко. Самое важное, что стоит попытаться понять — для чего и какой ценой мы решаем задачу, для кого и какая цена ошибки.
Приведу пример: пришел заказчик, который хочет создать систему автоматического видео-контроля магазина. Список пожеланий был обширный: контроль как цен, так и сотрудников, правильности выкладки, подсчет посетителей и много чего еще.
Заказчику позволительно не знать, но это совершенно разные классы задач, которые решаются совершенно по разному вплоть до того, что камеры нужно будет вешать по разному, не говоря уж про алгоритмы. Конечно, в рамках одного магазина такое вполне реализуемо сразу, но для тиражного решения нужно очень хорошо подумать стоит ли оно того или в конце будет много разочарований.
Выводы о математике, дженге и деривативах
Важна ли математика в ML? Без вариантов, очень важна. Но математика — это как финальный босс, до него еще нужно дойти, не потратив по дороге все доступное количество жизней (то есть, доверие и весь бюджет).
Математика — красива и великолепна, но направленная не туда — теряет свою красоту. На одной математике и алгоритмах технологии не взлетают. Конечно, это все игры в вероятности — всегда есть шанс, что и голая математика вытянет бездарную подготовку, но такой шанс — не очень велик.
Хорошие технологии — это в большинстве своем хорошо проделанная работа на всех этапах. Необязательно педантично идеальная, но достаточно хорошая, чтобы сохранить равновесие как башня в дженге. И главное — понятная на каждом уровне и в каждой своей предпосылке, потому что зашкаливающия сложность без ее осмысленного понимания на всех этапах — убивает, как и деривативы.
Иногда на каждом из этапов нужно останавливаться и задавать себе вопрос —, а все ли правильно мы сделали до этого? Ведь усложнить — можно всегда, а в конце пути может быть мучительно больно от несбыточных ожиданий и потраченных ресурсов.
Желаю вам всем глубокого целеполагания, правильных процессов, красивой математики и отличных технологий.
Спасибо!
