Всем доброго времени суток! Первую неделю нового сезона с вами Женя Чёрный, мультстек архитектор и в свободное время энтрепренер.

Под мультистэк я подразумеваю работу с open-source стэком (в основном Java) и Microsoft-based.

Применение AI, в частности ML, а ещё конкретнее DNN в различных отраслях и продуктов это один из моих самых горячих интересов

Для затравочки опросик.
"В своей работе я использую.."

Пока получается достаточное предсказуемое распределение ответов. Почему Microsoft в аутсайдерах по вашему мнению?

Сразу оговорюсь: аудиенция Backendsecret не репрезентативная, основная масса респондентов уровень "продвинутые+"

И используют продвинутые технологии и стэки

Но Microsoft гораздо лучше адаптирован к разработчику среднего уровня

Таких разработчиков большинство, и это факт с который надо принимать как данность

Предвзятость к Microsoft не лучший советчик в выборе и построении адекватного техрешения ;)

@backendsecret И сразу вопрос из зала. Вот для MS мы знаем дефолтный стек: EF+MVC+IoC (на выбор)+Automapper + мелоч… twitter.com/i/web/status/9…

Хотелось бы подвести итог под дискуссией о Microsoft стеке: в отшлифованных стандартных техрешениях MS-стек это совершенно валидный выбор

Есть выбранные стандартные решения для всех необходимых фишек, IDE поддержка для всех этих фишек и широкий выбор разработчиков

Для менее стандартных решений и новых технологий Java более очевидный выбор.

Ещё более инновационные решения могут лучше решаться с помощью non-mainstream стеков (Python, Go, Rust, R, Erlang, Scala и т.д.)

Всегда была интересна география фоловеров @backendsecret. Отмечаемся:
"Я живу и работаю в..."

Если кто не видел эпического выступления Гарри "Watman" Бернхардта на CodeMash 2012: destroyallsoftware.com/talks/wat

Хотелось бы дать перспективу, в которой я рассматриваю MS-стек в моей текущей позиции

Компания поддерживает on-going development 80-ти продуктов в одной экосистеме. Тех стек: Java, .NET, .NET Core, PHP..

MySQL, SQL Server, Postgres, Mongo

И это только по верхам. Требуется построить микросервисную экосистему в мульти-стек окружениии. Нужны критерии для решений, на чем писать

.. какой микросервис, для каких задач эффективнее тот или иной стек, также беря в расчёт доступность и расценки разных ресурсов.

Для разработки .NET микросервисов в гибридном окружение рекомендую Steeltoe.io от Pivatal

Steeltoe предлагает коннекторы к Eureka, Zulu, Config Server и Hystrix из нетфликсовского Java стека

Так что можно можно оркестрировать ВСЕ микросервисы одним Java-based тулсетом.

Нетфликсовская админка тоже прекрасно работает в таком окружении

Есть ли у кого негативный опыт по использованию CentOS 7 в production? Поделитесь "подводными камнями"

Одно из важных преимуществ микросервисной архитектуры это возможность использования многоязыковой экосистемы.

Кто чем пользуется для оркестрации в таком гибридном ландшафте?

Микросервисы для меня:

Я так понимаю респонденты с зашкаленым бульшетометром спят )

Те, кто попробовал и разачаровался: хотелось бы начать с вас. В чем объективная проблема с микросервисами по вашему мнению?

Те, кто попробовал и разачаровался: хотелось бы начать с вас. В чем объективная проблема с микросервисами по вашему мнению?

Когда стек фрагментирован, у тебя по сути даже нет выбора, подумай об этом

А теперь неожиданный наброс: я считаю, что фрагментрованый стек это хорошо.

Подведу некую черту: у любого прогресса есть обратная сторона. Есть выбор: бороться с трудностями или не делать прогресса

Я выбираю трудности и прогресс, поскольку старыми архитектурами решается все меньше и меньше современных задач.

Ок, следующая тема: SQL или NoSQL?

Если выбран ответ "Другое мнение, плз озвучьте его"

Я рад, что большинство ответов пока на 3-й опции

Несмотря на то, что я большой пропонент NoSQL, хотелось бы спросить ответивших #2: вы реально считаете, что ВСЕ задачи лучше решаются NoSQL?

Отлично, подводим итоги!
Большинство респондентов придерживаются верной стратегии: каждой задаче свой QL (ДБ, persistence layer)

NoSQL выплыл не как полная замена SQL, а как инструмент для решения задач плохо решаемых (или не решаемых) с SQL

SQL - самый информационно емкий из существующих ЯП. SQL рулил и будет пока рулить в большинстве задач.

NoSQL нужен для решения определенных типов задач.
Вот где он хорош:

1. Big Data.. но реально Big Data. Базы даже в 10-ки TB могут прекрасно держаться на SQL

2. Задачи с неструктурированной или полуструктурированный датой (например JSON). Хотя PgSQL прекрасно справляется с этой задачей сегодня

3. Full Text Search индексы

Это топ-3, но список не полон.
С каждым днём список проблем требующих NoSQL растет, но остальные задачи до сих пор рулят с SQL

Любую задачу можно решить чистым SQL или чистым NoSQL (примеров достаточно), но неправильно выбраная ДБ на порядок увеличивает разработку

Важный момент: NoSQL насчитывает десятки разных архитектур, каждая как правило решает узкую задачу. Неверно выбранная NoSQL ничего не даст.

Ок, смежная тема: есть такие, кто уже поигрался руками с Cloud Spanner?

Для тех кто не знаком: это недавно релизнутая гугловая BigData DB с полной поддержкой SQL

Ок, смежная тема: есть такие, кто уже поигрался руками с Cloud Spanner?

Хотелось бы потрогать тему Big Data:

Конечная цель биг даты всегда была машинным обучением

Время итогов: в большинстве задач Big Data не нужна и не надо Ее насильно засовывать

Big Data нужна, когда есть МНОГО данных. Правило левой руки: 0.5 петабайта.

Случаи когда размеры данных растут в арифметической и тем более геометрической прогрессии (и точно передут 0.5PB) - претенденты на биг дату.

Важно отметить, что кол-во задач где бигдата нужна очень небольшое. Но оно растёт.

Классические случаи для бигдаты: сбор телеметрии с IoT, CCTV видеофутадж, сбор всех инфраструктурных логов, сбор click data в вебе..

Один из ярких и красивых примеров: военный самолёт за час полёта собирает 5ТВ данных. Во флите несколько сотен самолётов

Петабайт данных накидывается меньше чем за час. Со всей моей любовью к Postgres - он не тянет :-$

Зачем же все эти данные нужны? Практически без исключения - для аналитики и машинного обучения.

Одно из свойств машинного обучения, это то что больше данных - это лучший результат

Правда увеличение объема данных в 2 раза даёт улучшение на маленькие проценты, но часто оно того стоит

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

А потом дать возможность ML инженерам играться с данными и строить модели пост-фактум. Чаще оказывается, что нужные данные не собрали :-)

Согласен, click data не верный термин. Click view data - термин более широкий и охватывающий эту категорию

Пару заключений по поллу о бигдате: противники бигдаты скорее всего почувствовали на себе бигдатлвый хайп, когда ВЕЗДЕ хотели её втащить

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

Для тех кто "хочет, но не дают": играйтесь сами, чтобы освоить и быть готовыми! Но не тащите её туда, где она не нужна!

Если у кого были сомнения, что закон Мура все ещё работает: goo.gl/eVgU4s.
TL;DR - скоро засунут мощный сервер в размер телефона

Эти углеродные нанотрубы известны достаточно давно, но были шоустоперы с массовым производством

Опустимся с высоких материй в повседневные реалии: как писать хороший код? Что такое хороший и "чистый код"?

К сожалению, когда нет кода, нет системы, но её функция НЕ выполняется

Пока мне очень нравится тенденция ответов. Из этого можно сделать вывод, что с практикой "Clean Code" бол-во знакомо.

Накинем слегка в сторону холивора? Для меня TDD:

Пока сражён наповал.. Реальный TDD не практикует НИКТО?

Люблю BDD, хотя конечно тесты написаные анналистом это утопия. Но я ожидаю от него вменяемое DoD - тесты сам напишу :-)

The later you test, the more it costs to write tests.

The longer a bug lives, the more expensive it is to fix.

Every line of code without tests will be significantly more difficult to debug or rewrite.

TDD done half way, half hearted, and half assed is a big reason some don't respect it.

Одна из самых больших ошибок в TDD - это забивание на шаг #3: прошёл тест - РЕФАКТОРЬ, пока код не станет понятен первокласснику и аналитику

pic.twitter.com/65a6yKvvSz

pic.twitter.com/doAkZRuiVX

pic.twitter.com/EfopkzGW5I

pic.twitter.com/jEywfpltrf

Итоги полла о TDD. Юнитесты практикует большинство, но только 1/8 из них делает test-first.

Присутствие юнитестов в бол-ве проектов вдохновляет, однако сообщество очень далеко от адаптации TDD.. очень

Поэтому обращусь к аудитории, практикующей код-тест без TDD (читайте в реплаях)

1. Писать тест после кода на 50%-200% более трудоемко

2. Код написанный после теста имеет сильную тенденцию быть короче

3. Тесты написанные после кода имеют значительную тенденцию к низкому покрытию

4. Код написанные после теста имеет тенденцию к меньшему кол-ву дефектов

5. Отладка кода через запуск юнитеста (вместо поднятия всей системы для каждой итерации) занимает на порядок меньше времени

6. Перейти на TDD психологически трудно (и это основной фактор нашей плохой статистики). Пробуйте, не сдавайтесь, плз!

7. Перейдя на TDD вы почувствуете уверенность в своём коде, более высокую производительность, меньше дефектов и чувство профессионализма.

Что ты скажешь о враче, который на такое согласится? Ага, безответственная скотина.

Инженер тот же врач: он должен гарантировать качественные результаты, а не показывать, что он быстро наклеил пластырь

Потом больной умирает от гангрены, но зато мы быстро наклеили пластырь.

Короче, я бы сказал, что у меня возьмёт 11 дней "вылечить" бизнес требование. Пластырь клеить не согласен.

Инженер не должен быть yes-меном на побегушках у sales. Инженер принимает ответственные решения. Неправильные решения могут стоить миллионов

@igor_maslik Нет, тесты это не панацея. Это прививка от оспы, ветрянки и менингита. От рака и даже перелома конечно не спасёт

Нашёл интересный paper, показывающий незначительную разницу между TDD или TLD: goo.gl/gKg2RB

А вот блог cleancoder-а, где Боб Мартин, разбирает как был построен эксперемент: goo.gl/CXheL7.
Весело, мне понравилось! :-)

Вопрос: когда пишется маленький чанк кода, потом пишется тест на него и потом рефакторинг, это ближе к TDD или TLD?

Посколько TLD практика выглядит для меня так: написали всю СТОРЮ, закинули на тест энв.. А завтра или в следующем спринте пишем тесты.

И то если не лень и начальство наезжает, что тестов нет.

Если все те, кто не TDD-ит пишут тесты подобным образом - я воспряну духом :-)

Попробую пересмотреть все эффекты TDD и понять если Short Iteration TLD (термин сам придумал) достигает того же результата...

Наметился TDD/TLD консенсус.
Короткие итерации "тест-код-тест" дают больше эффекта, любая выбранная техника с длинными итерациями.

По сути в контексте TDD длинные итерации это нонсенс и противоречит методологии. Что только подтверждает закономерность.

Разработчик, практикующий TLD с короткими код-тест циклами может достичь эффекта близкого к TDD.

TDD по определению навязывает короткие код-тест циклы.

При придерживании практики коротких код-тест циклов, выбор между TDD/TLD становится больше делом вкуса, чем холивором.

Дискуссия затянулось дольше чем хотелось бы. Будем менять тему. Есть заинтересованные в или практикующие ML (Machine learning)?

Artificial Intelligence и Machine Learning

Вопрос для практикующих ML. Пользую:

Да, не врут, когда говорят, что TF самый популярный FW для ML. А кто нибудь игрался с чем-нибудь кроме TF?

Интересно, выбравшие #4: троллят или взаправду так считают? Можете прокомментировать?

Одно из косвенных преимуществ TF - возможность запускать трейнинги в Google Gloud ML, который бежит на гугловых TPU.

На TPU-ном кластере по словам Гугла можно получить 300 teraflops

Для сравнения NVIDIA Titan XP (который стоит в районе 1.5К) выдаёт 12 терафлопс

Единственная неприятность: Cloud ML требует Python 2.7. Приходится прикручивать six и тому подобные шняги

Кто на чем гоняет трейнинги:

Для простых неглубоких сеток норм.

Но конволюшка с 5-ю слоями - уже час-два на трейнинг

Серьёзная конволюшка с десятками слоёв по несколько дней трейнится на Титане, а на i7 это недели или месяцы.

Кстати, утверждают, что на AMD трейнинг быстрее чем на Intel - если уж GPU нет

А, полезный совет: Google ML даёт сейчас $300 кредита на трейнинги. Один ML unit стоит $0.40 в час, чтобы получить GPU надо 2 ML юнита

О, появился кто-то Теслой К80! Завидую белой завистью! В личном пользовании или корпоративная?

Или Гугловская?

Чем занимаюсь в ML..

Ок, в слушателях есть пару человек, которые наверняка могут многому меня поучить в ML. Но рискну завести более глубокую дискуссию

Если гоню - вы меня одергивайте :-)

Вкину сразу для интересующихся: самый популярный источник знаний по ML это курсеровский курс Andrew Ng от Stanford

Coursera.org, ищите Stanford Machine Learning

Курс отличный, Эндрю бесподобен. Очень рекомендую.

Следующий шаг - новая пачка из 5-ти курсов от Эндрю. Идите на deeplearning.ai - оттуда ссылки на конкретные курсы.

Или просто ищите Deep Learning в Coursera

Refactoring is an exercise in kindness, testing an exercise in honesty #AgileAfrica

Едем дальше: DNN - или Deep Neural Network. Network - потому что это по сути граф вычислительных нодов.

Neural - потому что концепт вдохновлён работой нейронов человеческого мозга (хотя аналогия достаточно отдалённая, нейрон сложнее)

Deep - потому что строится много лейеров один над другим. Математически - функция от функции от функции... и т.д.

Важно отметить: DNN это область supervised learning, то есть те задачи, когда при тренировке мы говорим алгоритму какие ответы правильные.

DNN долго и нудно обучается, но потом делает предсказания сама только на основе входных данных без нашего участия

Что интересно, концепт DNN придуман ещё в прошлом веке, но тогда это было непрактично поскольку вычислительно сверх тяжело

Но закон Мура работает, и в 2000-х исследователи получили возможность проверить, что эти штуки умеют.

Оказалось, что умеют многое. Практически все известные на тот момент AI задачи решались лучше с DNN, хотя медленнее

Вышло несколько исследований, теоретически доказывающих, что чем глубже DNN, тем больше его возможности

Стали строить более глубокие и широкие сетки, но возникло несколько проблем: они хреново работают с двух-трех-мерными данными и..

После добавления большего код-ва уровней DNN перестаёт работать: предсказания или всегда "да" или всегда "нет", короче никуда не годится

Первую проблему решил Андрей Карпатый (профессор Стенфорда, ныне Tesla AI). В 2012 году он предложил Convolutional Networks

Convolutional Networks побили всех и вся в image recognition задачах.

В 2015 году Сергей Иоффе и компания решили вторую проблему: они предложили способ нормализации данных между уровнями - Batch Norm

В том же году группа исследователей с труднопроизносимыми азиатскими именами предложили концепт Residual Network

Residual Network помогает предотвращать явление затухания сигнала путём перекидывания остаточного сигнала с предыдущих уровней наверх

Также в период 2007-2015 появилось много разработок Recurrent Neural Networks, которые хороши для данных изменяющихся во времени

RNN-в по сути ввели свойства памяти в нейронные сети. Более отточенный концепт это LTSM (long-short-term-memory neurons)

RNN бесподобно работают в Natural Language Recognition.
Очень прикольный пост о RNN от Карпатого - karpathy.github.io/2015/05/21/rnn…

Короче, благодаря прорывам последних 5-лет исследователей понесло, стали экспериментировать со сложными очень глубокими архитектурами DNN

Цифр точных не дам, но за последние 2 года (2016-2017) кол-во исследований (и многих из ни успешных) умножилось.

Стали акцентироваться больше на специфических задачах и выявлять более не менее стандартные архитектуры.

Например: Stacked Hourglass Architecture (arxiv.org/abs/1603.06937) последовательность сегментов конв-уровней в форме песочных часов

А потом берётся несколько таких песочных часов и ставятся друг за другом. Как результат- очередные рекорды в бенчмарках

Это было давно... в 2016. В 2017 выходит уже с десяток исследований, которые развивают, улучшают и оптимизируются эту архитектуру.

Если кто-то серьезно хочет следить за новостями в этом мире: arxiv.org. Сюда публикуются все последние академические работы

И это лучший источник свежей информации, для тех кто прошёл все курсы Coursera и ищет куда идти дальше

Блиц опрос:

Также рекомендую YouTube channel Stanford School of Engineering.

Личный патент, как знать, что ты придумал что-то прорывное в AI: если после генерирования идеи появилась Сарра Конер - ты на верном пути :-)

Ещё по учебно-вспомогательному материалу:
Подкаст Machine Learning Guide:
overcast.fm/+JTij3pXTo Очень хорошо пойдёт параллельно Курсере

Подкаст Twiml&AI - отличные еженедельные интервью по разным суботраслям AI:
overcast.fm/+Gooh7TQ5Y

Неплохой ютуб канал от Siraj Ravel - youtu.be/JuLCL3wCEAk хороший практический опыт на Python с TensorFlow.

Хотя иногда его темп выносит мне мозг

Хорошо, теперь можно в глубину. Если есть вопросы, мысли вслух, затруднения - пишите, попытаюсь адресовать

А пока ещё пару забросов насчёт последних событий в исследованиях

В 2017 году вышло очень много работ по Reinforcement Learning.
Проблема: для того чтобы обучить систему, надо много данных. Очень много

Если данных мало, система будет "предвзята". Но собрать больше данных это долго и соответственно финансово тяжело

Reinforcement Learning это все ещё supervised learning, но вместо ответа на каждый пример мы только говорим какая конечная цель

Промежуточные действия система пытается найти сама.
Deep Mind купленный Гуглом пару лет назад преуспел в этом подходе

Для информации: Deep Mind даёт DNNу учится играть в игры Атари, имея только изображение с консоли и доступ к клавиатуре.

Deep Mind обыграл чемпиона мира в китайские шашки Go. Это игра, у которой после каждого хода открывается бесконечное кол-во новых вариантов

Её невозможно просчитать как шахматы: нужна человеческая интуиция. Reinforcement Learning справился с этой задачей

Очень интересный стартап, который придумал новую парадигму языка программирования для AI - bons.ai

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

Ещё одна свежая тема: GAN - Generative Adversarial Networks.
Или Генерирующие Состязательные Сети

GAN принцип: давай системе настоящие данные и искусственно сгенерированные. Цель две - научиться различать настоящие данные от фейковых

Вторая цель - научить генератор вырабатывать искусственные данные, которые неотличимы от настоящих.

Очень прикольная тема, рай для хакеров и головная боль для специалистов по безопасности

Что характерно, это лежит в области unsupervised learning- мы не говорим системе где правильный ответ заранее.

В сочетании с RNN можно генерировать текст, картинки, звук неотличимые от настоящих. Facebook очень сильно на них акцентируется

Вспомнил ещё один факт по поводу Reinforcement Learning: по моему с прошлого года с помощью RL AI обучается быстрее чем человек

А тот же Андрей Карпатый показал, что с 2015 года сис-мы распознованием изображения работают лучше, чем человек.

Он дал своим коллегам задачу - научится распознавать породы собак по картинкам. После 2-х недель люди делали это с 95% эффективности

А DNN на пару процентов лучше..

И с тех пор (2 года) показатели улучшились. Не удивлюсь, если к кому то уже пришла Сарра Конер )

Но начнём с простых и однозначных вещей. Как мы передаём инпут? Для всего, что не имеет пространственной структуры: всегда вектор

Для картинок - матрица. Хотя с вектором тоже будет работать, но не добьёшься высокой аккуратности предсказаний

Для NLP (и здесь присутствуют товарищи с опытом NLP, могут поправить) мы используем word embedding

Word embedding - идея в том, что чем ближе слова расположены в тексте, тем ближе они семантически.

Каждое слово представлено многомерным вектором, где каждой измерение это какой то семантический концепт.

Интересно идея использования похожей техники не для NLP, но пока интересных результатов не видел.

Опять таки, теоретически можно попробовать матричный инпут для дата анализа, но здесь пока тоже нету интересных прорывов

Едем дальше. Для картинок и сигналов данные неплохо поварьировать. Сдвинули картинку, покрутили, добавили зелени.

Это процесс так называемой дата аугментации - искусственно разнообразим наш дата сет

В случае дата анализа данные надо нормализовать - иначе оптимайзер может не работать вообще. Как бы сдвинуть в центр координат

И сделать так, чтобы разброс по осям был в одной размерности

Дальше у нас есть куча параметров: начиная с Learning rate и заканчивая padding для конволюх. С эти немного сложнее.

Как правило learning rate оптимайзера - самая важная штука. Его подбираем очень скрупулёзно.

Есть лекция в новом курсе Andrew Ng по оптимизации гиперпараметров, а также лекции 6 и 7 в Стенфордском курсе на ютюбе

Дальше: функция активации. Их много, но считается, что для DNN на все можно забить и оставить так называемый ReLU

ReLU практически это наполовину линейная функция, посему работает очень быстро. А также нет изчезновения градиентов.

Но я пока интуитивно вставляю также leaking ReLU: max(0.01x, x), хотя реже.

Дальше самая интересная и сложная часть, которую и имел ввиду @ruxeg в своём вопросе.

Какие лейеры, в каком порядке, какой ширины и как глубоко?

Как я уже говорил, теоретически, чем глубже сетка, тем она умнее (могу поискать ссылку на arxiv с исследованием)

Но глубокие сетки начинают на практике терять кач-во и жрут не по детски память и машинные такты

Для того, чтобы сетка не тупила, пользуем batch norm и residual unit.

Batch norm это сути та же нормализация, но не на входе, а между скрытыми уровнями сетки.

Residual Unit - это клевая штука. Это когда сигнал понимается наверх через наши лейеры, и параллельно напрямую с нижних лейеров.

Благодаря этим техникам подняли код-во уровней в нейронках с 20 до 152.

Здесь подводный камень - если вычисления не влазять в память GPU - п-ц ослику

Есть обходы, но не совсем тривиальные. Для реферанса смотрите AlexNet - они на соревновании ImageNet разбивали все на 2 GPU

По поводу размера кернела для конволюх: большие кернелы работают хреново. 3х3 и 5х5 оптимальный выбор

Несколько конв лейеров один за одним решают ту же пробему, что и большой кернел, но эффективнее.

Как показывает практика вставлять fully connected лейеры между конволюциями - вообще ничего не даёт. Один fully connected в конце.

Однако 2-4 коволюции подряд (между maxpool-ми) это интуитивно хорошо, чтобы увеличить "поле восприятия"

Дальше в лес - толще партизаны и вокруг зона активных исследований последнего года

Слава б-ну есть 30 тысяч AI исследователей по всему миру и они перебирают много вариантов.

И начинают находить, какие архитектуры хорошо решают определённые задачи.

Зачастую находят какую-то модель сегмента нейронки и начинают её стакать вертикально.

Это тенденция начата ещё года с 2012, но сейчас она чётче выражена. Смотрите VGG, AlexNet, GoogleNet и Stacked Hourglass как примеры подхода

Хотя я находил совершенно тупо структ-ные модели, которые хорошо работают: например Convolutional Pose Machine - arxiv.org/abs/1602.00134

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

Я думаю, что след. Пару лет начнут выделять стандартные сегменты нейронок и объяснять чего и как они достигают

А мы как инженеры будем их свинчивать одну с другой, для решения наших задач.

У меня уже пару недель вертится идея ассиметричной сетки, где сигнал делится и проходит через разного вида сегменты, а потом складывается.

Похоже на residual unit, но второй сигнал поднимается не напрямую с нижнего уровня, а через друго вида лейеры.

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

Несмотря на то, что мы находимся в периоде активного исследования и ничего не понимаем в Матрице..

.. существующие инструменты УЖЕ решают огромное кол-во инженерных задач.

Сейчас период, когда AI становится электричеством 21-го века.

Самая большая проблема - ничтожно мало инженеров, которые могут оперировать AI, несмотря на огромное кол-во исследователей

Тот кто сейчас заскакивает на коня - с большой вероятностью обеспечивает себя высоко-оплачиваемой и сверх-интересной работой

Что характерно, очень многие сдвиги в ML вдохновляются новейшими исследованиями мозга.

Да и не только новейшими. Например идея конвнетов - это аналогия работы нашего визуал кортекса.

Почитываю слегка нейронаучные работы (хотя понимаю в них только abstract секцию;-)), чтобы получить интуицию для аналогии в ANN

Человеческий кортекс состоит из 7 лейеров, которые очень четко разделены.

У дельфина их 5. У собаки - 4. У земноводных - 3.

Это наводит на мысль, что больше слоёв кортекса дают возможность оперировать более абстрактными сущностями

Важно: один слой кортекса это НЕ один уровень нейронной сети. Это вся сеть, которой мы оперируем сегодня

Обычно даже сложные задачи решаются одной сеткой, когда на выходе есть оптимизатор, который делает "обратное пропагандирование"

Это "обратное проп-ние" и есть обучение. Но в человеческом кортексе есть много уровней!

А что, если результаты нескольких сетей передаются в одну верхнюю, без того что есть одна общая функция оптимизации?

Например: одна конволюционная сеть для визуального инпута, одна для звукового, одна для тактильного.

И следующая стека получает все три инпута и учится на нем выполнять более абстрактные задачи, имея свой оптимайзер.

И не исключено, что этих сеток на втором уровне много и каждый решает свою задачу?

А этих уровней можно сделать много! Упс, извините, мне Сарра Конар звонит ;-)

Это конечно спекуляция, воображение и во многом безосновательный треп, но захватывает. Не исключено, что лет через 5 так и будет работать

Страшно пока никому не стало? Если честно, мне порой страшно. Поэтому был создан типа интернациональный комитет по контролю использования AI

Я читал, что они добиваются запрещения использования AI в любых типах вооружения.

Блиц опрос: послушал и теперь..

Мне бы спокойней спалось, если бы все страны подписались на такой конвенции

Очень рад, что вызвал интерес. Очень нужны ML инженеры!

Чисто в рамках любопытства и развития вербальной коммуникации хотелось бы понять, почему дискуссия для некоторых звучит бредом?

Ретейл: предсказание спроса, чтобы оптимизировать инвентори, рекомендация оптимальной цены, рекомендация продуктов, релевантность поиска

Предсказание трафика для автомаштабирования контейнеров, рекомендация промошенов, оптимизация лайаута сайта по click data

Обнаружение краж, прогнозирование спроса на новые продукты, обнаружение аномалий продаж, сегментирование клиентской базы

Финансы: предсказание рисков, автоматическое распознавание чеков, оценка риска ссуд, анализ юридических документов

Девопс: предсказание сбоев, автомаштобирование (уже упоминал), оптимизация топологии, обнаружение сукюрити атак

Дай область - подумаю над примерами

А решение принятое DNN практически невозможно объяснить человеческим языком!

Поэтому используют более простые "shallow" модели такие как Hidden Markov и Decision Trees. Ничего общего с DNN, но тоже интересно

Похожий подход, только глубже, ассиметричней + резидул юнит в параллель к ним

Не исключаю, что получится полный бред... я все же не ресерчер

Результаты GoogleNet и ResNet вдохновляют на положительный результат

Если есть мысли - пиши в личку

Во-вторых, мы часто плохо представляем, что происходит в DNN, т.е. хуже контролируем, по сравнен с обычным кодом

Если через 30-лет такая штука (только на порядки быстрее и больше) решает что-то, что нам не нравиться - дай б-г у нас есть доступ к руб-ику

И третье: смотрел TED с одним из профессоров Стенфорда (тоже участник конвенции, которую я послал)

По его сказал, сценарий восстания машин не реален раньше чем через 30 лет

Но предлагает на это не полагаться: в 30-х годах в США авторитетные исследователи писали, что нужно ещё 30 лет чтобы расщепить атом

А через неделю другой менее авторитетной группе это удалось.

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

Не говоря о том, что в Израиле есть боевые дроны управляемые AI. А чего стоит дать им самим гашетку нажать? Пока они только летают сами..

Ладно, никого не пугаю, апокалипсиса не предвидится: просто копание в AI наводит на мысли о таких сценариях.

Наше дело маленькое - JSON-ны парсить и в БД записывать :)

Господа, для меня это неделя было очень интересной и увлекательной, надеюсь что вас тоже позабавил!

Мы поговорили о реинкарнации Microsoft, микросервисах, контейнерах, биг дате, чистом коде, тестах и искусственном интеллекте

Область моих интересов этими темами не ограничена, поэтому всегда рад интересным и продуктивным дискуссиям и новым знакомствам.

Если не трудно, поставьте оценочку, фитбек всегда интересен:

С Вами был Евгений Чёрный, всем отличных выходных, удачной недели и творческих успехов!