?

Log in

No account? Create an account
Лабораторный журнал -- Day [entries|friends|calendar]
Anatoly Levenchuk

[ website | Лабораторный журнал ]
[ userinfo | livejournal userinfo ]
[ calendar | livejournal calendar ]

Полиция алгоритмической мысли [14 Dec 2017|12:58am]
Вскоре мы можем увидеть полицию алгоритмической мысли города Нью-Йорка: https://techcrunch.com/2017/12/12/new-york-city-moves-to-establish-algorithm-monitoring-task-force/ (This bill would require the creation of a task force that provides recommendations on how information on agency automated decision systems may be shared with the public and how agencies may address instances where people are harmed by agency automated decision systems -- http://legistar.council.nyc.gov/LegislationDetail.aspx?ID=3137815&GUID=437A6A6D-62E1-47E2-9C42-461253F9C6D0).

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



Так что bias это ещё и тема для исследований в machine learning. Там каждый раз нужно теперь обсуждать: то ли bias из-за того, что плохо собирали данные, то ли и впрямь есть какие-то зависимости, то ли зависимости есть, но мы не имеем права их использовать для принятия решений.

Коммунизм можно было создать только с новыми людьми, у которых все буржуазные bias устранены. Хотели как-то таких людей воспитать по-быстрому. Насколько по-быстрому? Это просто продолжение истории про Моисея, который 40 лет водил свой народ по пустыне, чтобы выросло новое поколение, не знавшее рабства. Так сказать, избавлялись от культурных bias рабства, стереотипов рабского мышления. Теперь хотят воспитывать новые алгоритмы, которые должны воплощать в себе культуру нового человека из нового общества. Нужно не честное машинное обучение по текущему состоянию культуры, а предписанное идеологическими установками машинное обучение: и полиция проследит, чтобы машины думали как предписано, а не "как все". И отведёт на исправление ситуации не 40 лет, алгоритмы не нужно так долго водить по пустыне.

Ну что, людей не удаётся научить свободу любить, так научат алгоритмы -- пусть они любят свободу, предписанным методом. Полиция алгоритмической мысли за этим проследит.

UPDATE: обсуждение в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10211833039715478
2 comments|post comment

Нужны ли специальные языки программирования для machine learning? [14 Dec 2017|03:52pm]
В статье про машинное обучение и языки программирования подробно разбирается вопрос "are new ML-tailored languages required, and if so, why? More importantly, what might the ideal ML language of the future look like?" -- https://julialang.org/blog/2017/12/ml&pl.

Эпиграф там замечательный: Any sufficiently complicated machine learning system contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of a programming language.

Конечно, There are few domains as demanding about language-level design issues as machine learning. But it’s not unprecedented, and in areas like formal reasoning and verification or cluster computing, new, tailor-made languages have proved an effective solution. Similarly, we expect to see new or existing languages customised for the kind of numerical, differentiable, parallelisable and even probabilistic computations needed in ML.

Важно ли это, особо выделять machine learning? Важно, ибо говорим не больше и не меньше, чем о Software 2.0 (https://medium.com/@karpathy/software-2-0-a64152b37c35). Models now demand conditional branching (ok, easy enough to hack in), loops for recurrence (less easy but possible), and even recursion over trees (virtually impossible to deal with). In many areas of ML, including neural networks and probabilistic programming, models are becoming increasingly like programs, including ones that reason about other programs (e.g. program generators and interpreters), and with non-differentiable components like Monte Carlo Tree Search. It’s enormously challenging to build runtimes that provide complete flexibility while achieving top performance, but increasingly the most powerful models and groundbreaking results need both.

В статье перечислено много очевидного и известного про языковые особенности всяческих TensorFlow и Chainer, но в одном месте и с большим количеством ссылок, плюс интересные замечания типа formats like XLA, ONNX and NNVM are becoming ever more sophisticated and will likely take more inspiration from traditional language design,5 perhaps even adding surface syntax to become fully-fledged programming languages. Компиляторные/платформенные стеки (у Алана Кея это были цепочки T-shirts), доходящие снизу до разного ускорительного железа (от суперкомпьютеров до смартфонов) становятся общим местом. Python и C++ поминаются через строчку, работающих с ними жалеют и желают всяческих успехов в борьбе с невзгодами. UPDATE: а ещё появился с тех пор NNEF как компиляторная цель -- https://ailev.livejournal.com/1395131.html

Вывод: Machine learning models have become extremely general information-processing systems that build ever higher-level and more complex abstractions; recurrence, recursion, higher-order models, even stack machines and language interpreters, all implemented as compositions of basic components. ML is a new programming paradigm, albeit a strange one that’s heavily numerical, differentiable and parallel. And as in any engineering field, the tooling available will have a profound impact on the scope and quality of future work.

Понятно, что авторы склоняются к тому, что будут это всё учитывать в Julia -- we in the Julia community feel that it is an excellent substrate for experimenting with these kinds of language-level issues, and will continue to push the boundaries with projects like Knet, Flux, Cassette, CUDAnative, DataFlow.jl, and more.

Я бы читал эту статью ещё и в свете замечания David Abel с декабрьской NIPS 2017 (https://cs.brown.edu/~dabel/blog/posts/misc/nips_2017.pdf): Overall my sense is that the Deep Learning hype has settled to an appropriate level. There’s of course loads of excitement about new methods and applications, but we’re no longer seeing the over saturation of papers tackling the same thing (except perhaps GAN and Deep RL architectures). The Deep Learning work has found its role in the broader context of ML. Теорема бесплатного обеда потихоньку проявляет своё действие, идея "глубокости" проникает отнюдь не только в нейросети, но и в самые разные другие области. Например, deep Gaussian Processes -- a method to integrate out all of the input/outputs of a deep neural network that then translates a neural network into a Gaussian Process. This is the idea of a deep GP. We form our distribution over the functions implemented by the network. Байесовские методы в частности и вероятностное программирование в общем тоже активно перемешиваются с deep learning, но и "сами с усами" -- и там тоже ой-ой сколько спец.языков: http://probabilistic-programming.org/

То есть предметная область оказывается с одной строны, "предметно-ориентированной", а с другой -- просто численными методами, в которых эту "предметную ориентированность" ещё и разглядеть нужно. Скорее уж нужно понимать, как одновременно юзать самые разные пакеты, поддержку самых разных методов, но в одном приложении. То есть отдельные DSL не выживут, выживут встроенные DSL. И кандидатов пока для "встраивания" по факту два: Python и Julia.

Дальше можно
-- поспекулировать о том, что Julia (как и Фортран, как Си) это суперкомпьютерный язык, а Python -- не очень. Питон не может в GPU, в этом его беда.
-- прикинуть, не появится ли вообще что-то совсем новое из языков (почему бы и нет! Какая-нибудь большая толстая фирма заявит, что будет программировать на чём-то новом, и поддержит всей своей массой программистов. Пять лет административной бури и натиска, и новый язык в деле).
-- прикинуть, что там с этими аппаратными вычислениями внизу полного вычислительного стека (например, насколько спецмашинки для deep learning смогут поддержать все эти сложные языковые архитектуры, насколько это по зубам вычислительным более универсальным машинкам типа ускорителей NVIDIA, и что дают автодифференцируемые программы, которые залезают внутрь GPU -- CUDAnative.jl, в спецвычислители для нейросетей автодифференцирование же не залезет. Кстати, автодифференцирование в Julia продолжает развиваться, вот только что опубликовали ReverseDiff, https://github.com/JuliaDiff/ReverseDiff.jl, ReverseDiff is algorithmically more efficient for differentiating functions where the output dimension is less than the input dimension. И там в планах уже поддержка GPU. А уж как совмещать самые разные численные алгоритмы в одном API в тусовке Julia уже определились на базе экосистемы решения дифуров, много мыслей на эту тему можно вычитать в блоге http://www.stochasticlifestyle.com/).
-- поспекулировать, что появляются всё новые и новые классы языков, и все "эффективно компилируемые". Например язык интуицонистской логики http://intuitionistic.org/, combining a very high level of abstraction with compilation to efficient LLVM bytecode. Выживет ли он как stand alone, или придётся такие языки тоже погружать в универсальный язык?

Я б до кучи добавил сюда и неизбежное перемешивание задач машинного обучения и инженерного моделирования. Вот тут я подробно писал про инженерное моделирование, давал много ссылок на смежные проекты: https://ailev.livejournal.com/1366789.html.

А ещё из языка машинного обучения нужно добраться как-то до огромных объёмов данных. Тут тоже жизнь: склеиваются языки работы с базами данных и языки работы с фреймворками машинного обучения -- типа аппаратно ускоренной Kinetica с TensorFlow внутри, всё более усложняющейся in-database analytics в стремительно растущих графовых базах данных -- https://ailev.livejournal.com/1373680.html.

Это я к тому, что отдельный и специальный язык для машинного обучения, язык для инженерного моделирования, язык для доступа к базам данных вряд ли будет существовать. Похоже, stand-alone DSL таки померли. Так что надежда на расширяемые языки, а в них на эффективный number crunching с управлением параллельностью и аппаратно ускоренными операциями с массивами.

И в этом секторе Julia не самый проигрышный на сегодня вариант. Тем более что Stefan Karpinski сказал месяц назад в ответ на удивление, почему черновая версия 0.7 (она же будет 1.0) на одном из классов задач заработала чуть ли не вдвое быстрее, чем версия 0.6 -- I’ve said it before but it bears repeating: we’ve barely scratched the surface of the kinds of optimizations that we can do in Julia (https://discourse.julialang.org/t/fantastic-progress-in-master-branch/6868/5).

Поэтому продолжаем следить за Julia, http://julialang.org/. На вопросы по-русски обычно бодро и быстро отвечают в русскоязычном Julia-чат в телеграме -- https://t.me/JuliaLanguage.

UPDATE: дискуссия в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10211836545043109
25 comments|post comment

navigation
[ viewing | December 14th, 2017 ]
[ go | previous day|next day ]