avlasov (avlasov) wrote,
avlasov
avlasov

Category:

Инженерность в DataScience

Когда я пишу что инженерность в ML слабо развита, это не значит что ее нет вообще. Точнее будет сказать, что в DataScience (некая объемлющая дисциплина, включающая в себя Ml, Statistics и проч), вполне себе сформировалась инженерность (конструктивность в решении соответствующих задач), но скорее применительно к несколько иного рода задачам, нежели когда речь идет об инженерии ML.

Тут надо уточнить, что я под инженерией ML имею в виду прежде всего ту сферу, которую можно назвать Автоматизация 2.0: т.е. мы так же автоматизируем какие-то процессы, строим аппаратно-софтовый комплекс, который решает какие-то задачи, снижает участие человека и т.д. и т.п., но уже с применением инструментария ML. Который дает нам возможность решать те задачи, которые раньше были недоступны (невозможно было формализовать и закодировть процесс их решения, либо это слишком сложно). В этом смысле, инженерия МЛ выглядит как удачный термин, ибо есть разновидность и развитие софтверной инженерии (Andrej Karpathy вообще говорит о Software 2.0, хотя я лично придерживаюсь совсем другого направления, а именно, что ML дополняет, а вовсе не заменяет традиционное - ручное - конструирование софта).

Т.е. ML в целом можно рассматривать и как более амбициозную область - попытки создать ИИ равный человеческому, и даже превосходящий оный. Но когда мы говорим о конструктивной методике, мы подразумеваем, что она будет работать на ограниченном круге задач, и я веду речь прежде всего о "слабом ИИ", о решении конкретных задач, часто довольно простых по форме (например, отнести какой-то объект к фиксированному набору классов, в случае классификации).

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

Сделав эти оговорки, посмотрим, что есть такого в DataScience, что можно было бы использовать в инженерии ML. Я бы тут выделил для простоты три направления (их может быть больше, просто я не в курсе): статистическое моделирование, байесовский подход и оптимизационный подход. Названия достаточно условные.

Рассмотрим статистическое моделирование в общих чертах. Модель описывает формально взаимосвязь между переменными. Тут могут быть как наблюдаемые, так и скрытые (латентные) переменные. В статистике/ML часто используются вероятностные модели (либо бывает несложно прикрутить вероятностную интерпретацию), хотя не обязательно (SVM, perceptron). Есть куча математического инструментария, чтобы эти взаимосвязи описывать, и таким образом моделировать данные. Так что сам по себе модельный подход очень инженерен: декомпозируем то что есть на "неделимые" составлющие, описываем их переменными, описываем взаимосвязи. При этом взаимосвязи между переменными параметризованы - т.е. есть некие специальные параметры, которые в ML часто называют весами, которые можно варьировать и таким образом задавать разнообразные зависимости между переменными.
Далее, у нас обычно возникают две задачи: надо как-то оценить эти параметры модели и делать инференс, например делать прогнозы с использованием модели (оценки параметров модели - это тоже инференс, но иногда инференс - статистический вывод - используют в узком смысле). Отмечу, что в ML обычно инференс происходит достаточно однообразно, т.е. мы подставляем веса в функциональную форму и получаем функцию, с помощью которой можно делать предсказания чего нам надобно. Но в целом модели дают более широкие возможности, нежели просто функции. В частности можно оценивать точность прогноза и тому подобное.
Для оценки параметров во frequentist статистике разработана куча принципов: MLE, MAP, GMM, EM и тому подбное (я перечислил те, с которыми знаком, понятия не имею сколько ускользнуло от моего внимания). Конечно же, есть и байесовская работа с параметрами, но это мы рассмотрим отдельно.
Упомянутые выше принципы обычно приводят к оптимизационной задаче (серии оных), ибо M выше - это Maximum/Maximization, за исключением GMM (Generalized Method of Moments), но в котором тоже обычно речь идет об оптимизации. Решение оптимизационных задач тоже разберем отдельно.
Промежуточный итог: традиционное статистическое моделирование очень даже конструктивно. И я бы сказал оно более удобно для конструирования нежели аналогичный подход, ассоциированный с ML - Risk Minimization. Впрочем, различие тут условно - понятно, что ML и Statistics постоянно обмениваются приемами, так что в настоящее время достаточно трудно провести между ними черту. Тем не менее, ML больше свойственно игнорировать все эти модельные тонкости, скорее отмечая, что то или иное построение можно обосновать/рассмотреть в рамках MLE/MAP и т.д.
В этом смысле, Perceptron/SVM ближе к ML, нежели к статистике, ибо им не приписывают вероятностную интерпретацию (если постараться, то можно приписать, но я не встречал такого в литературе), т.е. их нельзя оценивать в рамках MLE/MAP подходов. Но вот в Risk Minimization они прекрасно вписываются.
В то же время, Perceptron/SVM называют statistic models, просто они не probabilistic models. Просто у меня статистика четко ассоциируется с вероятностями, посему кагбэ для меня Perceptron/SVM выглядят немного странно в рамках статистики. Но это, понятное дело, особой роли не играет.

Итого, вероятностное моделирование и соответствующие подходы к оценке параметров (вкупе с методами математической оптимизации и итеративного решения уравнений), дают прекрасный framework для инжерного подхода к решению ML задач. На мой взгляд, гораздо более удобный нежели подход, который обычно освещается в ML - Empirical/Structural/etc Risk Minimization. Хотя такой подход хорошо подходит для обычных данных (условно IID), но если данные имеют более хитрую структуру (реляционные, временные), то в рамках ML становится непонятно, что с ними делать, кроме как попробовать игнорировать эту проблему. А вот в рамках статистики с этим вполне себе работают.

Мне думается, что причины этого явления в том, что в рамках ML, практишенеры пытались упростить себе жизнь и не связывать себя всякими дополнительными обоснованиями и корректностями моделирования. Что позволяло им работать с более широким набором методов и решать задачи бОльшего размера. Как кто-то писал ML - это статистика минус тестирование гипотез. Тестирование гипотез на данных большого размера можно замучаться делать.

Однако, многие ML прктишенеры не игнорируют полностью традиционную статистику, и вобщем-то даже, в более-менее сложных ML работах вероятностные модели и статистические принципы широко используются. Хотя в популярном ML курсе на Coursera Andrew Ng, про вероятности речь заходит крайне редко, но уже в Lecture Notes к аналогичному Стэнфордскому курсу, теорвер/статистика вполне присутствуют.

Поэтому тут напрашивается второе объяснение - чтобы говорить о статистическом/вероятностном моделировании, надо заметно более высокий уровень подготовки слушателей. А ML на первых порах можно без теорвера и статистики вещать.

Далее надо будет рассмотреть байесовский подход и математическую оптимизацию. А также более детально рассмотреть почему статистическое моделирование очень полезно в рамках инженерии ML.
Subscribe

  • StatMod и ML

    Рассмотрим, чем полезен StatMod в плане инженерии ML и почему "преподаваемый" ML тут проигрывает. Под "преподаваемым" ML я имею в…

  • Основные вопросы в инженерии МЛ

    По своему опыту я выделяю следующие основные вопросы/проблемы, которые возникают при решении практических МЛ задач. Какую задачу мы решаем? Ту ли…

  • Инженерность в ML

    Последнее время занимаюсь некоторой деятельностью, которую я условно называю "инженерия МЛ". Ибо на практике (при решении…

  • Post a new comment

    Error

    default userpic

    Your reply will be screened

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 4 comments