?

Log in

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

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

Ссылки по глубокому обучению и напоминание о нейроэволюции [28 Dec 2015|02:27am]
Никак не могу привыкнуть, что ML это не markup language, а machine learning. AutoML -- это автоматизация подбора алгоритмов для машинного обучения (http://www.automl.org/, http://papers.nips.cc/paper/5872-efficient-and-robust-automated-machine-learning, https://competitions.codalab.org/competitions/2321 -- в последнем хорош специфический для машинных обученцев термин Tweakathon), OpenML -- это открытые наборы данных, постановки задач и скрипты в онлайне для машинного обучения (http://www.openml.org/). Ах, ещё есть и язык ML, поэтому такие как http://mosml.org/ вообще не про маркап и не про обучение.

Ещё один набор ссылок по машинному обучению хорош тем, что в нём есть ссылки на странички 100 знаменитостей, мир должен знать своих героев: https://github.com/ChristosChristofidis/awesome-deep-learning

Как-то я пропустил ноябрьские заметки лекций Kyunghyun Cho -- Natural Language Understanding with Distributed Representation: http://arxiv.org/abs/1511.07916 (там 124 страницы, почти книжка). Он кстати, читал эти лекции без слайдов, с мелом и доской: http://www.kyunghyuncho.me/home/blog/lecturenotefornlpwithdistributedreponarxivnow

Недавний (8 декабря 2015) прорыв в переводе дальних пар языков (типа английский-китайский, сразу на 6 пунктов BLEU) -- http://arxiv.org/abs/1512.02433. Всего-то делов: поменяли цель обучения с maximum likelihood estimation на minimal risk training (minimize the expected loss on the training data). И там ведь уже вполне серьёзные BLEU -- 40.75 на одном из датасетов (поглядите на оригинальную статью про BLEU, там сравнения с человечьим переводом: http://www.aclweb.org/anthology/P02-1040.pdf, 40.75 это лучше, чем у человека по этой метрике). После этой работы Сергей Шегурин написал: "Практика показывает, что современные нейросетки на любой конкретной метрике достигают лучшего, чем люди, результата, то есть мы просто не совсем правильно формулируем им задачку, а решают-то они её превосходно" (https://www.facebook.com/groups/nevronet/permalink/579214648911527/), а ещё он предложил менять метрики на более точно отражающие человеческие понятия о качественном переводе. Я думаю, что результаты смены метрик понятны: их станет много, и хороший по одним метрикам перевод будет отвратительным по другим.

Ещё одна попытка обойти жёсткость описания сеток с dataflow (то есть пойти против линии Torch-Theano-TensorFlow): порождение сети в динамике, Chainer -- они себя называют "вторым поколением фреймворков", ни больше ни меньше: http://chainer.org/ (больше информации в http://www.slideshare.net/beam2d/presentations, и не вся она там по-японски). "Ещё одна попытка" -- это после MXnet (http://mxnet.rtfd.org/). Они так и докладывались оба на NIPS 15 в одной секции "систем", Chainer и MXnet -- http://learningsys.org/papers.html. А вот ещё одна попытка: вообще строить сетку интерактивно, прямо по ходу её тренинга -- dreaml, http://learningsys.org/papers/LearningSys_2015_paper_26.pdf. Там data frames (a data frame data structure intended for rapid and efficient incremental modification) и reactive data transformations, из functional reactive programming. Как всегда, начинается война между "правильными системами" и "популярными" с заранее понятным результатом.

Фантастические презентации по управлению из RNN сложными движениями (пока там нарисованные роботы, тем не менее): http://research.microsoft.com/apps/video/default.aspx?id=259609&l=i, http://www.technologyreview.com/news/544521/a-master-algorithm-lets-robots-teach-themselves-to-perform-complex-tasks/. Удивительно, как их раньше не замечали: ведь тамошние видео были опубликованы аж в 2012 году (https://youtu.be/mhr_jtQrhVA особо хорош, но и остальные не хуже: https://www.youtube.com/channel/UCqOSEIlvMNZ3_udEdLxRegg). Это UC Berkeley Robotics, http://www.eecs.berkeley.edu/~igor.mordatch/

При этом deep learning отнюдь не единственное направление. Вот, например, "нейроэволюция" с не менее чудесными результатами: https://www.reddit.com/r/IAmA/comments/3xqcrk/im_ken_stanley_artificial_intelligence_professor/ -- It's the exact opposite of the big computation/big data trend now in deep learning: it's tiny computation but with really surprising results. It tells us something about encoding, about objectives (or their lack thereof), and about what's possible with the right kind of evolutionary setup. In short, its important not because it's results are better or worse than something, but because they taught us so much. И там тоже много про роботов. И про дружбу и жвачку с deep learning: It is interesting to consider the merger of the power of both approaches, whereby you have depth and big data in one case, but divergence and quality diversity in another. Or architectures evolved through neuroevolution but optimized through deep learning. There are so many possible synergies here that it's too bad these communities are not historically in better contact.

Вот нейроэволюционный MarI/O (вирусное видео, больше 2млн. просмотров) -- https://youtu.be/qv6UVOQ0F44. Сначала в видеоигры начали играть нейроэволюционщики, и только потом DeepMind.
10 comments|post comment

lytdybr [28 Dec 2015|03:20pm]
Это у нас дома пирожок дня:
то нету силы есть работа
то нет работы сила есть
то есть и сила и работа
а нужен косинус угла
© broad


Тестирование системы в целом зло, оно и дорого, и не достигает запланированных результатов: http://www.infoq.com/news/2015/12/end-to-end-testing. Там много чего ещё интересного. Например, You discuss that creating a fragile system that prioritises low mean time between failures (MTBF) over mean time to recovery (MTTR) can lead to risk in regards to exposure to 'Black Swan' events. How can developers and operators convince management of the reality (and inherent risk) of this issue? -- и далее объясняется, как.

Как запасать энергию в воздухе по стоимости ниже батарей, и сколько миллионов долларов и лет стоит разработать для этого компрессор -- http://www.technologyreview.com/qa/544611/the-energy-startup-conundrum/. На рынке электроэнергии скоро будет очень весело, накопители-то подтягиваются.

Иллюзии на социальных сетях: как ошибиться в мнении большинства (это ведь легко!) -- http://arxiv.org/abs/1506.03022. Individuals often lack global knowledge of the behaviors of others and must estimate them from the observations of their friends' behaviors. In some cases, the structure of the underlying social network can dramatically skew an individual's local observations, making a behavior appear far more common locally than it is globally. "Majority illusion" may facilitate the spread of social contagions in networks and also explain why systematic biases in social perceptions, for example, of risky behavior, arise.

А вот официальное подтверждение правильности бесцельного существования: http://www.amazon.com/Why-Greatness-Cannot-Planned-Objective/dp/3319155237. Постановка чётких целей в сложных ситуациях -- зло, сфокусированность на достижении целевых показателей любой ценой -- меднолобый фанатизм, хорошего из этого ничего не выйдет.

Ух, почти все табы браузера позакрывал. Практически рекорд этого года. Хотя в pdf-ридере этих табов уже зашкаливает, но что с этим делать -- не понимаю. И вообще, нужно чистить свой списочек GTD -- там ведь залежи каких-то старых хотелок, на экран список уже не помещается. Нужно сосредоточиться, и отважно наступить на горло всем этим собственным песням, всё равно ведь руки до них не дойдут. Бесцельность, так бесцельность. Всё по науке!
1 comment|post comment

Системный моделер из стены и липучек [28 Dec 2015|04:57pm]
User story mapping -- http://jpattonassociates.com/user-story-mapping/. Основная заявленная идея тут упорядочить пользовательские задачи (activities) во времени, из историй сделать эпопею. Если внимательно приглядеться, то время оказывается логическим -- привет, вид жизненного цикла (то бишь практики) по горизонтали с разбивкой на эпические/тематические подпрактики по вертикали.

Тем самым user story mapping оказывается про принципиальную схему взаимодействия пользователя с системой, функциональный анализ -- "как оно работает, как получается польза". Поэтому user story map так сильно отличается от product backlog, который появляется исключительно в попытке модульного синтеза -- "как это реализовать, из каких кусков сделано".

Поразглядывайте примеры для user story map в google image. Очень поучительно.

И сразу становится понятным, почему user story mapping хорошо сочетается с domain-driven design (DDD) -- http://blog.eriksen.com.br/en/mapping-domain-knowledge.

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

Одно системное мышление, тысяча применений.

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

Вот что пишет автор подхода user story map (http://jpattonassociates.com/the-new-backlog/): "I hate that word “epic.” I haven’t written Beowulf here. There’s no hero with a magic weapon slaying a monster. It’s just my user “managing email” – a relatively basic thing from my user’s perspective. At least the terms “activity” and “user task” give me some idea of what kinds of stories they are. That said, I’m not fond of the term “user story” either, but I’ve come to accept it. It beats the crap out of requirement.

Куда ведёт в этой цитате ссылочка со слова requirements? К его же статье Requirements considered harmful, где от слова requirements с его кажущейся неизменяемостью и окончательностью он уходит к слову decision, что можно было бы изменять и объяснять. Но кончается всё опять-таки не словом desicion, а теми самыми "нарративами" и "эпопеями" (epic) в user stories -- описаниями. Требования всего-то описания системы как чёрного ящика, со стороны её работы в составе использующей системы. И, конечно, описания могут меняться по мере продвижения в понимании, почему бы и нет.

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

UPDATE: пара интересных реплик на этот пост появилась в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10206161610733298
13 comments|post comment

navigation
[ viewing | December 28th, 2015 ]
[ go | previous day|next day ]