medved

StatMod и ML

Рассмотрим, чем полезен StatMod в плане инженерии ML и почему "преподаваемый" ML тут проигрывает. Под "преподаваемым" ML я имею в виду подход, который воспроизводится обычно на курсах, статьях и проч. Ибо, вообще говоря, тут не может быть принципиальной разницы между ML и (Mathematical) Statistics. Т.е. всякий метод из матстатистики можно привнести в ML.

Я вообще не хочу рассматривать различие между статистикой и МЛ, гораздо существеннее разница между probabilistic и nonprobablistic моделированием. Для простоты будем считать, что ML всегда работает с моделями данных (возможно неявно) - как впрочем и статистика. Но эти модели могут быть вероятностные, а могут быть и невероятностные. И вместо StatMod в заголовке точнее будет написать ProbMod.

Collapse )
medved

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

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

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

Collapse )
medved

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

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

  • Какую задачу мы решаем? Ту ли задачу мы решаем? Может быть мы решаем ту задачу, которую умеем решать, вместо той, что нам действительно нужна.

  • Несоответствие целевой задачи и доступного арсенала алгоритмов МЛ. Как сконвертировать задачу, которую нам нужно решить, к той, которую мы умеем решать?

  • Несоответствие имеющихся типов данных и стандартного набора типов данных МЛ. Как сконвертировать имеющиеся данные в те, которые можно подать на вход алгоритмам МЛ.

  • Где взять размеченные данные в нужных количествах? Как снизить затраты на разметку?

  • Как встроить готовое решение в объемлющую систему?

Это были высокоуровневые вопросы, но можно выделить и типовые вопросы более низкого уровня.

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

  • Как выбрать/сконструировать пространство поиска решения?

  • Как организовать поиск решения в этом пространстве? Например, в случае нестандартной задачи МЛ нужно разработать алгоритм оптимизации целевой функции.

medved

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

Последнее время занимаюсь некоторой деятельностью, которую я условно называю "инженерия МЛ". Ибо на практике (при решении "промышленных" задач), инженерности очень не хватает. И вообще, я обнаружил, что эта тема ниочень развита в литературе.
Под инженерностью/инженерией я понимаю некую методику решения практических задач (пусть и ограниченного круга), некий подход к конструированию таких решений. Если рассмотреть с точки зрения науки, то фундаментальные ученые занимаются общими вопросами, которые на первый взгляд вообще не имеют никакого отношения к жизни простых людей. Прикладные ученые берут эти отвлеченные вопросы и конкретизируют до такой степени, что становится понятно, как это можно применить к решению всеразличных проблем, возникающих "на практике". Ну а инженеры уже берут это знание и решают эти самые проблемы, при этом им еще надобно учитывать ограничения по ресурсам.

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

Collapse )
medved

Психологические основы либеразма

Уже лет наверное под 30 я (и не только) сталкиваюсь с любителями рыночной экономики. В какой-то момент возник вопрос - откуда они берутся? Поначалу оно вобщем-то понятно: народ в СССР в плане рыночной экономики был непуганный почти что совсем. Поэтому не удивляет, что всякие красивые идеи о рынке и проч массово вошли в неопытные мозги наших соотечественников (включая и мои).

Я правда довольно-таки быстро (ну там в течении нескольких лет) стал недоумевать, с хера этот бред кто-то еще хавает? Ну наебали, прогнали всякую хуету, но за несколько лет-то можно было разобраться, что к чему! Дык нет же, это бред продолжает цвести в мозгах дорогих россиян уже который десяток (не знаю просто откуда читать). Поначалу я списывал это на глупость. Но потом выяснилось, что довольно много умных людей этим страдает, и они даже скорее к этому склонны. Тогда я списывал на неопытность, оторванность от жизни. Но кагбэ 30 лет на это трудно списывать. Да и как-то вобщем стало понятно, что либеразмом страдают умные и умудренные опытом деловой активности.

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

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

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

Из серии "Машин Дёрнинг на Удафф.ком"

Сижу себе, делаю topic modelling починяю примус, внезапно обнаруживаю в результатах такой топик:
'0.145*"fuck" + 0.144*"shit" + 0.134*"ass" + 0.093*"y’all" + 0.059*"damn" + 0.053*"bitch" + 0.035*"hell" + 0.027*"bad" + 0.018*"asian" + 0.013*"fuckin" + 0.011*"got" + 0.011*"hoe" + 0.010*"like" + 0.010*"kick" + 0.010*"bullshit" + 0.009*"nigga" + 0.008*"caus" + 0.006*"real" + 0.006*"gonna" + 0.006*"face"'
medved

Мини-учебнег по распределенным системам/протоколам. Репликация, дублирование и веб-системы

Будем различать дублирование и репликацию. Для устранения SPOF или для увеличения производительности мы можем дублировать устройства и/или процессы, т.е. какие-то типы запросов могут обрабатывать разные дивайсы. Точно также мы можем делать копии данных, как с целью устранения SPOF так и увеличения производительности. Дублирование данных назовем репликацией. Будем различать горизонтальную и вертикальную репликацию. Горизонтальная - это когда мы делаем однородные копии, ну например записываем данные на несколько дисков, или в память нескольких процессов. А вертикальная - это копии данных на разных типах носителей, например, кэш - это копия данных, которые храняться, положим на диске (или в удаленной или в более медленной памяти). Бэкап - тоже пример вертикальной репликации.

Collapse )
medved

Мини-учебнег по распределенным системам/протоколам. Проблемы создания распределенных веб-систем

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

Collapse )
medved

Мини-учебнег по распределенным системам/протоколам. Stateful процессы

Вообще говоря, помимо Stateless+Shared Db+(Mem)Cache нужно рассмотреть более сложную архитектуру, где вместо простого кэша, используется полноценная память и/или сервис для синхронизации. Например, можно для синхронизации использовать ДБ. Это актуально, ибо простое кэширование не всегда приемлимо. Но я все же хотел бы рассматривать эти усложнения попозже, совместно с репликацией и обработкой сбоев.

Пусть у нас теперь процессам будет положено иметь состояние - Stateful схема. Будет использоваться shared DB или нет - это отдельный вопрос, но пусть для начала будет shared db. Stateful сервера позволяют сильно увеличить производительность обработки запросов - ведь можно хранить состояние на сервере, т.е. не надо ходить ни в мемкэш на другом хосте, ни в БД - разумеется, периодически надо будет, имеется в виду, что много запросов можно обслуживать, используя локальную память. Правда, тут желательно, чтобы процессы были многопоточными - ведь если на одном хосте будет много однопоточных процессов, то часть состояния будет дублироваться, что может привести к нежелательному расходу памяти.

Однако, в Stateful архитектуре возникает проблема синхронизации состояния в разных процессах. В принципе, в случае веп-процессов, это часто можно избежать. Рассмотрим сперва виды состояния. Можно грубо разделить состояние на три вида: состояние, актуальное для запроса - request-level, для веб-сессии (последовательности запросов) и для приложения в целом. В распределенной системе еще можно выделить состояние в контексте отдельного процесса и распределенного приложения в целом (единое на все процессы). Бывают и более хитрые контексты - например, может быть контекст для длительных транзакций/воркфлоу и ассоциированное с ним состояние. Но не суть важно.

Collapse )
medved

Мини-учебнег по распределенным системам/протоколам. Stateless+Shared DB+Cache

Дополним Stateless схему кэшированием. Вообще, кэширование применяется везде, есть много их всяких видов, в частности есть целая куча библиотек кэширования. Нужно уточнить о чем идет речь. В данном посте я буду вести речь прежде всего о кэшировании, которое разгружает Shared DB в контексте стейтлесс сервера. Т.е. вообще говоря, это паттерн не только для веп-систем. Хотя есть еще специфические для веба кэши, которые вобщем тоже разгружают веб-сервер, а косвенно и БД. Но пока именно о кэшах типа memcached, ибо это есть популярная схема.

Итак, для упрощения масштабирования http layer'а (или еще из каких соображений) мы сделали web сервера стейтлесс, и все состояние храним в БД. И мы столкнулись с тем, что схема перестала масштабироваться - БД стала боттлнеком. И мы хотим ввести кэширование, чтобы разгрузить БД.

Collapse )