Искусственный интеллект, вызовы и риски – глазами инженера

    Добрый день, коллеги. Сегодня хочется трезво посмотреть глазами инженера на так популярные сейчас искусственный интеллект и Deep learning, упорядочить, выстроить факты и выработать выигрышную стратегию – как с этим … взлететь, пролететь и не упасть кому-нибудь на голову? Потому-что, когда дело от лабораторных моделей на python/matplotlib/numpy или lua доходит до высоконагруженного production в клиентском сервисе, когда ошибка в исходных данных сводит на нет все усилия – становится не то, что весело, а даже начинается нумерологический средневековый экстаз и инженеры начинают сутки напролет танцевать, в надежде излечиться от новомодной чумы )


    Танцующие инженеры, тщетно надеющиеся исцелиться

    Современная разработка


    Полезно для начала вспомнить, как в принципе устроена современная разработка программного обеспечения. За основу, как правило, берутся классические, хорошо изученные в «прошлом веке» алгоритмы: поиск, сортировка и т.д и т.п. Любимые всеми СУБД – хороший пример бородатых, тщательно проверенных и изученных классических алгоритмов (да простят нас Кодд и Дейт за такую попсу).

    К алгоритмам добавляются согласованные сообществом инженеров (хотя нередко ни с кем не согласованные, продвинутые злой силой) – стандарты: сеть (DNS, TCP/IP), форматы файлов, сервисы операционной системы (POSIX) и т.п.

    Ну и, конечно, языки. В последние годы, к сожалению, в этой области началась какая-то унылая ерундистика: добавляют-убирают автоматические геттеры и сеттеры и автоматически вводят-выводят типы (как будто это прямо так важно важно), размазывают идеи функционального программирования из «Алисы в Стране чудес» и Haskel на Scala, пытаются частично скрыть дыры С++ в Rust, создают C для гуманитариев в виде Go, в очередной раз придумывают javascript «с нуля» (ECMAScript 6) и всем сердцем продолжают верить в красоту модели акторов и забивают совершенно разные гвозди с помощью Erlang. Вся эта движуха, не без основания, подогревается идеей будущего многопоточного программирования на многоядерных процессорах и GPU, возможно в кластерах, с помощью акторов, immutable-данных, функционального ЗОЖ и неявных извращений в виде currying и рекурсивного построения бинарного дерева. Но, очевидно, близкого прорыва пока ну совсем не видно – логика столкнулась с физикой и все стало упираться в ограничение человеческого мозга, тупость компиляторов в решении более-менее интересных задач и способность людей, ну извините, ошибаться и без злого умысла плодить тонны багов. И все с новой силой звучит высказывание Эдсгера Дейкстры, что серьезное программирование – для умных, как не крути и никакие чудо-юдо технологии тут не помогут. Хотя может и правда нам помогут футуристичные квантовые компьютеры, ну надо же во что-то верить?

    В общем, чтобы с языками не запутаться и код не закровоточил багами, есть известное средство – писать … «правильно». Но чтобы понять значение «правильно», нужно прочитать много книг, перелопатить сотни тысяч строк кода в режиме «завтра в 10:00 должно работать и радовать клиентов» и выпить немало чашек крепкого кофе и разбить немало клавиатур о головы коллег. Но это правило – работает. Всегда.


    Мир глазами инженера

    Что касается библиотек, то никто, разумеется, не пишет сейчас все с «нуля». Это глупо и дорого. Но, используя «чужие» библиотеки всегда остается риск, что их писали немного «неправильно», а повлиять на это в данный момент почти никак нельзя, а сверху еще и маслица подливают: «бери готовое, вот они взяли и у них работает». Так все, конечно, и делают и используют Linux (операционка, но, по сути, такая же «библиотека» доступа к «железу»), nginx, apache, mysql, php, стандартные библиотеки коллекций (java, c++ STL). Библиотеки, к сожалению, сильно отличаются друг от друга, как по скорости, так и по степени документированности и числу «неисправленных ошибок» — поэтому успеха достигают команды, обладающие определенным чутьем и отличающие надежные «крысиные шкурки» от хорошо пропиаренных, но мало полезных, непрозрачных и/или неадекватных при чуть нестандартной нагрузке решений.

    Таким образом, теоретически и, приложив определенные усилия, практически можно создать адекватное программное обеспечение в сжатые сроки с сильно ограниченными ресурсами, используя математически проверенные алгоритмы и библиотеки достаточной, но не критичной степени испорченности, на доказавшем свою «нормальность» языке/ах программирования. Примеров успеха – не то, чтобы много много, но они есть ;-)


    Примеров успехов – не то, чтобы много много, но они есть

    Машинное обучение


    В этой области, в основном, речь идет об обучаемых алгоритмах. Когда бизнес, скажем, накопил некую «бигдату» и хочет ее монетизировать и вытащить полезный, помогающий клиентам и/или повышающий производительность труда алгоритм. Аналитически в лоб задачу эту бывает крайне сложно или невозможно решить, требуются эксперто-годы, учет множества факторов, вызов Ктулху – и, кажется, что можно поступить проще и «наглее»: протащить глубокую нейронную сеть «мордой» по данным и тыкать ее в них то тех пор, пока ошибка станет ниже определенного уровня (помним, что обычно проверяют два типа ошибок – ошибка обучения и ошибка генерализации на тестовом наборе данных). Ходит поверье, что при наличии миллиона и более примеров – глубокая нейронка способна начать работать на уровне не хуже человека, а если примеров больше – есть надежда научить ее превосходить человека. А если примеров меньше – нейронка тоже может приносить свою посильную пользу, помогая, но не заменяя человека.


    Полезная нейронка внутри R2D2

    Звучит красиво и практично – вот есть данные, «большие данные»: фас, нейронка, учись и помогай человечеству. Но, как известно, дьявол скрывается в мелочах.

    Порог входа в разработку и машинное обучение/Deep learning


    Ни для кого не секрет, что технологии разработки делятся на категории по уровню вхождения. В самых простых и доступных технологиях людей всегда значительно больше, часто с совсем непрофильным образованием и в такой обстановке нередко создается много неправильных, недолго живущих и воюющих друг с другом библиотек – в эту нишу хорошо ложиться JavaScript и Node.js. Понятно, что если копать вглубь, то появляется множество неочевидных деталей, появляются настоящие Гуру с большой буквы – но войти в эту область в шортах и сачком для бабочек за выходные вполне реально.


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

    В «среднюю» по уровню вхождения категорию можно отнести динамические языки программирования типа: PHP, Python, Ruby, Lua. Тут все уже намного сложнее – более развитые концепции ООП, частично реализованные возможности функционального программирования, иногда доступна примитивная многопоточность, более выражена модульность и средства создания больших программ, доступны системные функции, частично реализованы стандартные типы данных и алгоритмы. За недельку, без напряжения, разобраться и начать создавать полезный код – вполне реально, даже без профильного образования.


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

    В «высшую» по уровню вхождения категорию обычно относят хорошо зарекомендовавшие себя промышленные языки типа C++, Java, C# и уже вроде бы начавшие наступать им на пятки Scala, bash и VisualBasic (последние два — шутка). Тут уже мы встретим очень развитые промышленные инструменты управления сложностью, качественные библиотеки типовых структур данных и алгоритмов, мощные возможности по созданию доменных диалектов, огромное количество качественной документации, дополнительные развитые библиотеки для отладки, профилирования и великолепные визуальные среды разработки. Войти и работать в этой категории проще всего, имея профильное образование или большую любовь к программированию и несколько лет месяцев интенсивного опыта и хорошее знание алгоритмов и структур данных – т.к. работа ведется нередко на довольно низком уровне и знания тонкостей операционной системы, сетевых протоколов – часто тут важны.


    Промышленные языки программирования требуют изнурительной подготовки и нередко не прощают ошибок

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

    А вот с машинным обучением немного… иначе. Аналитиками часто просто рождаются. Процесс обучения напоминает изучение игры на музыкальном инструменте – 2-3 года сольфеджио, 2-3 года гаммы гонять до посинения, 3 года в оркестре, 5 лет резать трупы в морге и тонны пота. Научить человека азам математики и статистики, математическому анализу, линейной алгебре, дифференциальному исчислению, теории вероятностей – за месяцы просто невозможно, нужны годы и … и не все потянут и пройдут на следующий курс. Многие сойдут с дистанции на другие кафедры. Быть ученым – не для всех, как бы не хотелось.


    Стажировка аналитиков

    А может, пронесет? Все в это верят по началу: за выходные разберусь! Но к сожалению, для того, чтобы понять, как работает самая элементарная в машинном обучении «логистическая регрессия», являющаяся своего рода «hello world» в программировании, требуется хорошо понимать как минимум пару разделов высшей математики: теорию вероятности и линейную алгебру. А для понимания логики «стохастического градиентного спуска» нужно также знать хотя бы в базовом виде дифференциальное исчисление.

    Сырые полу-лабораторные фреймворки


    Драйва добавляет высокая влажность. Имеющиеся на рынке популярные фреймворки для Deep learning – сырые до такой степени, что утром на клавиатуре появляется самая настоящая плесень.


    Популярные фреймворки для машинного обучения. Они не пропали, они просто еще очень сырые

    Понятно почему. Парад «универсальных» фреймворков начался лишь в прошлом, 2015 году. Deep learning уверенно пошел вверх в третий раз только в 2006 году, после многих десятилетий неуверенности и застоя. GPU совсем недавно внезапно оказались в нужное время в нужном месте.

    К сожалению, TensorFlow совсем еще медленный и странноватый в production, Torch7 страдает отсутствием нормальной документации и языком Lua, deeplearning4j пытается понравится GPU, а кандидаты типа Theano на python непонятно как эффективно эксплуатировать в production без тяжелых наркотиков. Да, ходят легенды, что обучение нейронной сети это одно, а ее эксплуатация это сооовсем другое и этим должны заниматься совсем другие люди и технологии – но реальность считает деньги и это, согласитесь, страшно неудобно, дорого и не очень разумно. Наиболее универсальным и нацеленным на решение конкретных бизнес задач в сжатые сроки на «нормальном» промышленном языке является похоже пока только deeplearning4j – но от тоже находится в фазе активного роста и созревания со всеми вытекающими.

    Как выбрать архитектуру нейронной сети для решения бизнес-задачи?


    Читать научные публикации на птичьем диалекте с откровенным матаном без мата могут единицы, поэтому для большинства инженеров скорее всего наиболее прикладной и полезный способ изучения возможностей архитектуры – это копание в исходниках фреймворков, в большинстве случаем на “проклятом” студенческом python и изучение многочисленных примерчиков, которых в разных фреймворках становится все больше и больше и это не может не радовать.

    Поэтому общий рецепт – выберите наиболее походящую решаемой задаче архитектуру в виде примера в коде, реализуйте ее 1 в 1 в удобном для эксплуатации фреймворке, закажите молебен и может вам повезет! Что значит «может повезет»? А все очень просто. Вы столкнетесь со следующим спектром инженерных рисков:


    Аналитик, ведущий разработчик и руководитель проекта готовятся к молебну «О сведении нейронки». Говорят, скоро докажут теорему о влиянии молебнов на поведение градиентного спуска в условиях многочисленных плато, седловин и локальных минимумов

    1) Архитектура нейронки хорошо работает с данными исследователя, но с вашими данными может работать совсем «иначе» или работать совсем наоборот.
    2) В вашем фреймворке может не оказаться всего спектра элементарных кубиков: автоматического дифференцирования, алгоритма обновления с тонкой подстройкой (updater), расширенных средств регуляризации (dropout и других), нужной функции ошибки (loss), определенной операции над данными (векторное произведение) и т.п. Вы можете заменить их аналогами, но это привнесет риски.
    3) Иногда, правда редко, хочется потянуть в production Matlab или R ;-) Тут один совет – сразу к врачу.
    4) Скорее всего, вам потребуется подстроить нейронную сеть под дополнительные бизнес-требования, которые появились позже и совершенно не укладываются в идеальный мир математики. Например – значительно снизить уровень ложно-позитивных срабатываний, увеличить Recall, понизить время обучения, адаптировать модель к гораздо большему набору данных, добавить и учитывать новую информацию. И тут, как правило, понадобиться очень глубоко вникать в архитектуру нейронки и крутить скрытые винтики – а крутить на удачу, это путь к срыву сроков релиза и ночным кошмарам. И без профессора можно просидеть с отверткой с растерянным выражением лица и месяц и два и полгода.


    Что же делать, что крутить? Разработчик на C++ пытается понять отличие softmax от softsign

    Здравствуйте тензоры!


    Для инженера тензор – это просто многомерный массив, позволяющий совершать над собой различные операции и жертвоприношения. Но к работе с тензорами – нужно привыкать ;-) Первые недели даже от трехмерных тензоров голова побаливает, не говоря уже о гораздо более «глубоких» тензорах для рекуррентных и сверточных сетей. Можно убить кучу времени на эти низкоуровневые манипуляции, отладку циферок в тензорах и поиск ошибок в одном значении из 40 000. Обязательно учитывайте этот риск – тензоры только кажутся простыми.


    Будьте осторожны! Попытки представить структуру 4 и более мерных тензоров приводит к агрессивному косоглазию

    Особенности работы с GPU


    Может быть в начале неочевидно, но обычно быстрее обучать нейронку и получать ее ответы тогда, когда все необходимые данные (тензоры) загружены в память GPU. А память этих драгоценных и так обожаемых геймерами устройств – ограничена и обычно гораздо меньше памяти сервера. Приходится городить костыли – вводить промежуточное кэширование тензоров в ОЗУ, частичную генерацию тензоров во время прохождения по набору данных (ибо все могут и не поместиться) и так далее. Поэтому – учитываем и этот немаловажный инженерный риск, влияющий на трудоемкость. Сроки можно смело умножать на 3.


    Видеокарта. На ней, оказывается, можно не только играть!

    Нейронная сеть в production


    Допустим, вам сильно «повезло», вы хорошенько потрудились и довели лабораторный прототип до production качества, подняли веб-сервер, загружаете обученную нейронку в память сервера или сразу в память GPU и адекватно быстро отдаете ответ. Но … данные меняются и за ними нужно менять/дообучать модель. Вам необходимо постоянно следить за качеством работы нейронки, измерять ее точность и ряд других параметров, зависящих от конкретной бизнес-задачи и тщательно продумать процедуру ее обновления и до/переучивания. Поверьте, мороки тут значительно больше, чем с классической СУБД, которую нужно лишь раз в 5 лет оптимизировать и раз в 10 лет убирать паутину с материнской платы :-)

    А еще ходят легенды, что нейронную сеть можно просто … дообучить и не нужно будет ее заново переучивать на всем объеме данных. На самом деле — нельзя, но всем очень очень нужно и иногда… везет. Если данных достаточно мало и нужно постараться запомнить их как можно больше (не снижая ошибку на тестовом наборе данных, разумеется) – то просто так «дообучить» не «переучивая» без риска что-то важное забыть уже не получится. Нет никакой гарантии, что стохастический градиентный спуск (SGD) запомнив новое, не забудет важное старое ;-) А если данных много (миллионы фотографий например) и требований запомнить именно этот конкретный пример нет — сработает (но молебен не помешает).

    Разработчик, тестировщик и суицид


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

    1) У вас все стало плохо и неточно, потому что просто взяла и поменялась к черту информация, скрытая в исходном наборе данных
    2) У вас ошибка в архитектуре нейронной сети и она проявилась только что из-за изменения исходных данных. Будьте добры, надевайте каску и изучайте градиенты и веса каждого слоя: нет ли затухания градиента, нет ли «взрыва» градиента, насколько равномерно распределяются веса и не нужно ли подкрутить регуляризацию, нет ли проблем в функции ошибки на выходе (loss), нет ли затухания потока информации/градиента в пограничных режимах сигмоидов и других специфических функциях активации и т.д. и т.п. – головная боль обеспечена надолго и всерьез и каска только для красоты.
    3) Вам повезло и вы нашли ошибку в фреймворке нейронной сети … за неделю до релиза.

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


    Настойка из паранойи, выдержка – 5 лет

    Выводы


    Мы открыто и честно обозначили ключевые факты и риски, связанные с внедрением и использованием глубоких нейронных сетей в высоконагруженных сервисах – с точки зрения инженера. Выводы – пока не делаем. Видно, что работы много, работа эта не простая, но страшно интересная и успех приходит только к профессионалам, умеющим объединять знания и людей из разных областей и владеющих вкусом к синергии. Очевидно, что нужно не просто прекрасно программировать и чувствовать систему кончиками пальцев, но и либо понимать, либо активно привлекать к подобным проектам экспертов в области математики и создавать коллегам позитивные, творческие условия – чтобы приходило побольше интересных и эффективных идей и способов их лаконичной и быстрой реализации. А иначе … придется месяцами сидеть с отверткой перед рухнувшим «Гравицапом», крутить наугад винтики, жечь спички и с завистью смотреть на блистающие в небе своей мощью и красотой искусственного интеллекта решения конкурентов. Желаю всем инженерной удачи, сходящийся нейронных сетей, уверенности, энергии и как можно меньше трудноуловимых ошибок! Ку! ;-)

    1С-Битрикс
    119,72
    Компания
    Поделиться публикацией

    Комментарии 31

      +4
      Ну. Все не так плохо же. Если есть пару лет опыта в похожих делах, то в большинстве случаев более-менее интуитивно понятно почему сетка не работает. И в продакшне часто есть рабочий сети. Не так долго развернуть.
      Самый жёсткий момент: очень мало кто из руководителей проектов понимает, что их проект может не взлететь. При этом не по вине программиста. И не из за раздолбайства спорта. И не из-за рынка. А из за того что по их данным может просто не заработать: низкое качество, много шумов, и. Т. Д. Никто не признает возможность существования неконтролируемого риска.
        0
        Очень верно подмечено!
          –1
          И в продакшне часто есть рабочий сети


          Рабочего жаль.

          низкое качество, много шумов, и. Т. Д.


          Все это и есть входные данные для разработки, а не для продуктизации
            +4
            Да там не только рабочий, там ещё и суппорт в спорт превратился. Мобильник не верил в такие слова. А проверить при выходе из вагона не успевал.
            Все это и есть входные данные для разработки, а не для продуктизации

            Сейчас, зачастую, это две общих вещи. Вы не можете набрать одну базу данных на одном устройстве для опытов, а потом вторую — для внедрения. Зачастую сбор данных — на порядки сложнее и дороже, чем их анализ и создание сетки которая их анализирует. Когда вы вложились и получили хреновую базу — тут уже мало что можно сделать. Можно по ней обучиться, тогда даже как-то работать будет. А можно полностью пересобрать базу изменив условия. Тогда есть шанс, что она будте нормальной.
            Но часто нельзя понять нормлаьная база или нет, пока не прогнать по ней несколько алгоритмов обучения.
              +1
              Это да, мало того реальные данные не дают под соусом секретности/приватности.
          +4
          Слов много, по существу — мало.
            +2
            Не, ну можно матанчиком было поругаться, матрички помножить, но зачем людей пугать? Хочется чтобы начали делать, пошли вперед, был драйв, желание, энергия! А там и матанчик подоспеет и сигмоиды и гиперболические тангенсы уже не будут так пугать.
              0
              Кого вы тут собрались испугать «матричками» и матаном? На эту статью обратят внимания восновном те у кого образование включало отнюдь не только матан и «матрички». Видно что автор сам в этой теме делает первые шаги.
                +1
                Да, я инженер-электромеханик. Но приходится интенсивно учиться последние 15 лет :-)
                  –6
                  Теперь понятно.
                    0
                    Приятно умничать, да? Вот поэтому и пост написан, много кто умничает, а когда до продакшена доходит, начинается :-)
            +5
            Основная проблема при использовании глубоких сеток — это не качество их работы, а потребность изменять под них саму парадигму работы.

            Например, мы сделали сетку, которая правильно работает в 90% случаев. Это круто. Мы не можем без боли воткнуть её в существующие бизнес процессы, потому что для существующих процессов — 90% — слишком мало. Надо 100%. Соответственно, обучатор сетей заслуженно гордится своими результатами, а потребители — плюются от низкого качества. И решения в той парадигме — нет. Меняйте парадигму.

            Допустим, у нас классическая задача классификации чего-то там на несколько классов. Сейчас эту задачу решают люди вручную, и сортируют картинки/звуки/ватэвер. Заменить людей сеткой — нельзя. 10% ошибок — слишком много. Но можно перестроить алгоритм работы людей так, что-бы они подтверждали классификацию сети вместо того, что-бы классифицировать самим. Это — смена парадигмы. Сеть оптимизирует работу ассесоров, сокращает их количество, и мы всё равно оставляем окончательное решение за человеком.
              +1
              Смотри, но есть же задачи, где глубокие сетки уже работают быстрее и точнее человека? Распознавание образов когда требуется очень быстрое. Т.е. заменить иногда людей можно. Но чтобы обучить такую сеть, требуется миллионы примеров, а это уже проблема нередко, как их разметить эффективно?
                +1
                хорошо, что к дип лернингу не имеет никакого отношения
                  +1
                  Размечать людями и то не усё…
                  … но это уже детали, ИМХО основная проблема глубоких, в отношении к ним как к чёрным ящикам исполненной магией ботанов, лет двадцать-тридцать тому, такое-же отношение было к сетям обычным, и так-же практики набивали шишки, а теоретики популярно объясняли почему, но их никто не слушал.
                  Соблазн глубоких в том, что можно не вникая в тему получить «не слишком стрёмные» результаты, и наивно надеяться дуриком проскочить, а дальше одно из трёх, либо повезёт, либо «повезёт», либо задача принципиально не решаема :-)

                  Я сам из инженеров, но темой увлёкся давно и имел возможность «баловаться», те решать синтетические задачи ради науки, изобретать велосипеды, а во взрослой жизни так увы не бывает, от инженера хотят результат, а не опыты…
                    +1
                    Увы, даже при наличии огромного датасета, в большинстве задач superhuman performance или даже human performance не наблюдается (кроме самых мелких, конечно).
                    Поэтому надо разбираться подробнее:
                    Быстрее и точнее среднего человека? (И неподготовленного к задаче?) Или лучшего и натренированного?
                    Из «точнее лучшего человека» — наверное только распознавание дорожных знаков в низком качестве в лабораторных условиях и другие подобные задачи, а также не-нейросетевые методы (в т.ч. Jeopardy — IBM Watson for Jeopardy, которая не нейросеть).
                    Паритет в распознавании цифр, в шахматах и в го.
                    Из «быстрее среднего человека, но не точнее» — да, много чего можно придумать, особенно когда удаётся уменьшить сложность задачи.
                    Но большинство практических задач типа «распознавание картинок», «распознавание речи», «классификация текста», «понимание смысла текста», «распознавание эмоциональной окраски», «вождение машины без использования лидара» — всё ещё лишь на уровне среднего тренированного человека или ниже.

                    Ссылки:
                    Wiki: Progress_in_artificial_intelligence,
                    https://xkcd.com/1002/ (games),
                    http://rodrigob.github.io/are_we_there_yet/build/ (images),
                    https://github.com/syhw/wer_are_we (speech)
                      0
                      Спасибо! Познавательно очень.
                        +2
                        обычно выделяют какой-то массив, который автоматизируется на 99,99% (т.е. сильно точнее человека может работать), а остальное оставляют на рост и ручную обработку. Сокращение объема человеческой работы в 2-10 раз все же существенно.
                          +1
                          Согласен, что нейросетки достигли определенного прогресса в распознавание образов и речи (те же образы, только спектральные). Но в лингвистике увы и ах (за исключением простых задач, типа классификации текста). Ибо главная задача нейросети — минимизировать ошибку распознавания образа. Но в лингвистике образ семантический, который можно передать тысячами способами словесных цепочек. Технологии, позволяющие вынимать смысловой образ из текста, пока в зачаточной стадии развития (я не беру в рассмотрение тяжелые и туманные LSA или LDA). Поэтому я не спешу быть в тренде и переводить целиком систему на нейросети. Скорее использовать локально, для оптимизации промежуточных результатов.
                            +1
                            Текущий прогресс речи и образов во многом обусловлен наличием больших датасетов. Чем больше датасет и сетка — тем выше качество. Нужны именно оба, а детали устройства сетки иногда даже не так важны (на многих подзадачах может быть разница всего в 5% между RNN, LSTM и CNN, например).
                            Так что, может, с технологиями NLP всё и норм, но мы это проверить не можем — с датасетами огромная проблема!
                            Например, вполне возможно что качество синтаксически-семантического парсинга можно до человееского уровня довести увеличением датасета (частично SyntaxNet Parsey McParseFace именно это и подтвердил!). На прагматических конструкциях и эмфатическом общении тоже неплохой прогресс (и рескоринг результатов БД, и seq2seq применяется).
                            Даже может быть, что мы бы и мышление и человеческое решение задач более-менее повторили, если бы умели у человека эффективно снимать информацию с мозга.
                              +1
                              Тогда какой смысл в неросетках, если я те же результаты получаю стандартными стат. методами, обучаясь на небольших датасетах?
                              Не уверен, что человеческое мышление можно повторить, поскольку оно не логично, а скорее мифо-логично. Да и зависит от состояния паралимбической области мозга в данный момент времени, т.е. определяется эмоциональным состоянием, а логикой обучения.

                              По поводу больших датасетов: ИМХО внедрение новейших технологий гуглом ухудшило поиск — теперь сложно получить ответ на специфический запрос, выходящий за пределы парадигмы. Поэтому дело не только в данных, но и «гибкости» решения.
                                +2
                                >Тогда какой смысл в неросетках, если я те же результаты получаю стандартными стат. методами, обучаясь на небольших датасетах?
                                На простых задачах — никакого. А в более сложных задачах нейросети дают автоматический feature engineering и при этом позволяют получить более хорошие результаты, чем у других методов.
                                >Не уверен, что человеческое мышление можно повторить, поскольку оно не логично, а скорее мифо-логично.
                                У мышления есть разные компоненты. Какие-то было бы неплохо повотрить. Вы смотрели на Dynamic Memory Networks и датасет bAbI?
                                https://research.facebook.com/research/babi/
                                >Да и зависит от состояния паралимбической области мозга в данный момент времени, т.е. определяется эмоциональным состоянием, а логикой обучения.
                                Сделать байесову связь на эмоциональное состояние — никакой проблемы, а само эмоциональное состояние можно легко эмулировать. Но зачем? Вы хотите, чтобы микроволновка могла на вас обидеться и отказаться работать?
                                >По поводу больших датасетов: ИМХО внедрение новейших технологий гуглом ухудшило поиск — теперь сложно получить ответ на специфический запрос, выходящий за пределы парадигмы. Поэтому дело не только в данных, но и «гибкости» решения.
                                Безусловно.
                                  +1
                                  Вы хотите, чтобы микроволновка могла на вас обидеться и отказаться работать?

                                  Если мы говорим о полноценном ИИ, то да. А если как о частичной замене человека — то зачем эмитировать мышление? Большинство машинных задач, причем даже и семантических, не имеют к мышлению никакого отношения.
                                  P.S. Я говорил не о эмуляции эмоций, а порождении языка «на эмоциях» (в ключе генеративной грамматики и пр., только еще глубже :). Это немножко сложнее, чем Байес.
                                    0
                                    >Если мы говорим о полноценном ИИ, то да. А если как о частичной замене человека — то зачем имитировать мышление?
                                    Чтобы решать ИИ-полные задачи, типа компьютера-программиста, вдумчивого собеседника, или для задачи хорошего понимания текста? Но вообще, я говорил не об имитации, а о повторении мышления. Компьютер должен уметь думать, значит, это мышление. Компьютер умеет решать человеческие задачи не хуже человека — значит, умеет повторять мышление человека.
                                    >Большинство машинных задач, причем даже и семантических, не имеют к мышлению никакого отношения.
                                    Считаете, что мышление возникает начиная с какой-то сложности задач? Но разве задача 17*16= не требует от человека мышления? Как и задача вида: «Жевачка, 5 букв, вторая у»?
                                    >P.S. Я говорил не о эмуляции эмоций, а порождении языка «на эмоциях» (в ключе генеративной грамматики и пр., только еще глубже :). Это немножко сложнее, чем Байес.
                                    Я бы с вами поспорил, но боюсь, это долгий и отдельный разговор. Если кратко, то моделирование языка — это ещё и моделирование описываемой сцены и рассказчика. А в модель рассказчика входит его эмоциональная модель. Если вы про это, то да, оно сложнее, чем байес — но только потому, что моделирование сцены сложнее, чем байес. Эмоциональную модель же вполне можно сделать достаточно простую, никто разницы и не заметит.
                              +1
                              Отличный комментарий. Полностью согласен и присоеденяюсь.
                            +1
                            Есть проблема валидации и устойчивости. Беда сеток в том, что на определённом классе образов они дают стабильно некорректные результаты. Соответственно, надо доказать, что таких образов в работе будет ниже определённого порога, или утверждать что-то об общем качестве сети — нельзя. Это — проблема валидации.

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

                            Вот и получается, что:

                            1. Сейчас сетка работает, но не факт, что будет работать завтра.
                            2. В среднем сетка работает неплохо, но на на некоторых (заранее неизвестных) классах образов валится.

                          +5
                          хорошая юморная параноидальная статья
                            0
                            Иногда кажется, что глубокие нейронки без тяжелых наркотиков трудно тренеровать. Но это только кажется :-) Терпение и труд все перетрут.
                            +2
                            > Тут уже мы встретим очень развитые промышленные инструменты управления сложностью, качественные библиотеки типовых структур данных и алгоритмов, мощные возможности по созданию доменных диалектов, огромное количество качественной документации, дополнительные развитые библиотеки для отладки, профилирования и великолепные визуальные среды разработки

                            Да да, а в динамических языках мы конечно же ничего из этого не встретим, потому что каждый уважающий себя человек переходит сразу же на промышленные языки как научится кодить хоть немного!
                              +1
                              А все почему?
                              Использование машинного обучения вообще и нейросетей в частности это в первую очередь научная задача и только во вторую инженерная.
                              И никакими средствами научность из проблемы убрать нельзя.
                              Соответственно получаем другие подходы и причитающиеся к этому риски.
                                0
                                Согласен полностью!

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

                              Самое читаемое