В ручном режиме контролировать все коммуникации — задача трудоемкая и, кроме того, малоэффективная. И мы решили ее автоматизировать. Для этого пришлось обучить нашу Виртуальную АТС новым трюкам. Технологию Text-to-speech мы внедрили давно, теперь же взялись за обратный процесс.

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

Наверное, так и будет до некоторой степени. Уже сегодня степень автоматизации достигла такого уровня, который еще 10 лет назад казался фантастикой. Все так… Но, как известно, «мелочи» могут привнести множество сюрпризов. Одной из таких мелочей является тот факт, что львиная доля всех данных, которые можно и нужно было бы использовать в задачах борьбы с мошенничеством, прогнозированием рынков представляют собой текстовые данные. Количество ежедневно порождаемых письменных, видео и других данных составляет миллиарды строк, анализ которых с помощью операторов практически бесполезен. Кто-то может, поспорить, что все не так и большинство данных представляют собой обычные таблицы, которые хорошо обрабатываются статистическими методами. И, казалось бы, он будет прав. Банки из TOP-30 рапортуют о широком использовании BigData.

Прежде всего, я хотел бы поблагодарить всех, кто дал свои критические комментарии по первой версии статьи. Мне показалось, что написать версию два, а не просто оставить все как есть, было бы правильной идеей.
 
Конечно же, искусственный интеллект уже существует!  Если посмотреть заголовки статей в популярных СМИ, названия и слоганы различных научных конференций на эту тему – безусловно это так. Нельзя не поверить, особенно когда очень этого хочется наконец-то оказаться в XXI веке — «настоящем», как это описывалось во всех научно-фантастических романах. Но так ли это? А если нет, то что существует на самом деле. В попытке разобраться в мифах и реалиях была написана эта статья.
 
Первоначально хотелось начать как-то так: «впервые упоминание термина «Искусственный интеллект» появилось у Д. Мккарти в 1956 году на конференции в Дартмундском университете, основоположниками ИИ следует считать У.Мак-Каллока, У.Питса, Ф.Розенблата» и т.д. Однако, это уже слишком поздно и не совсем отвечает целям статьи, да и википедия опередила с таким началом.

Анализируя последние «победы» ИИ, а также критические статьи неизбежно приходишь к выводу, что все крутится вокруг нескольких общих особенностей. Одна часть статей критикует невозможность прохождения тестов, а другая полна патетики о «невероятных победах».  При этом игнорируется тот факт, что победы были достигнуты в узкоспециализированных задачах, где основным преимуществом машины была скорость переборов по базе фактов и «умении» видеть закономерности там, где человек просто-напросто быстро устает это делать. Блестящие примеры кластерного анализа в том или ином виде и формирование базы шаблонов-фактов. Всё это следствия, причины же в большинстве случаев или не анализируются совсем, или рассматриваются поверхностно.

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

Поскольку как аналитики мы вынуждены давать определения постоянно, неплохо было вспомнить эти правила.

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

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

Конструкция

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

1. Состав и взаимное расположение частей какого-либо сооружения, механизма.
2. Само сооружение или механизм с таким устройством.

Попробуем перевести их на формальный язык.

Поскольку состав – это множество, то первое понятие переводится так: конструкция — это множество объектов, связанных между собой связями. При этом, судя по определению, объекты должны быть рукотворным и неживыми. То есть, нельзя представить Землю в виде конструкции, если не предположить, что ее сделали инопланетяне. Нельзя представить ДНК в виде конструкции, если только эта ДНК не создана кем-то. То есть, в определение конструкции надо добавить, что объекты рукотворные. Например, множество объектов: {фюзеляж, крылья, хвост} состоит из рукотворных объектов, и, потому, может называться конструкцией. Конструкцией под названием самолет. Замечу, что в данном контексте самолет – это не объект, а множество объектов {фюзеляж, крылья, хвост}. Можно назвать это множество самолет(к).

Сколько объектов может быть в конструкции? В определении нет ответа на этот вопрос. Но мы можем предположить, что их конечное число, большее одного, потому что в определении говорится о связях. Итого получилось: рукотворное множество объектов, созданное человеком, объекты объединены связями, множество конечное, количество элементов больше одного.

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

Термины

Начнем с термина «есть часть». В быту мы встречаем следующие высказывания: слоны – есть часть млекопитающих. Речь идет о том, что множество слонов есть подмножество множества млекопитающих. В этой статье термин «есть часть» будет употребляться в другом смысле. Мы будем употреблять этот термин только в отношении конкретных объектов. Например, конкретная ветка дерева – есть часть конкретного дерева. При этом не надо думать, что речь идет о любой ветке дерева, как тогда, когда мы даем определение понятию: ветка дерева – есть часть дерева. В терминах матлогики это утверждение читается так: для любой ветки дерева найдется такое дерево, что данная ветка есть часть этого дерева. Такое утверждение относится уже не к конкретному объекту, а к понятию, определяющему объекты. Если в статье понадобиться сказать так, я скажу явно. В противном случае я буду говорить о конкретных объектах.

Следующий термин «включает в себя». Если я говорю, что дерево включает в себя ветку, то это значит, что конкретная ветка – это часть конкретного дерева. И речь по-прежнему идет о конкретных объектах, а не о множествах или понятиях.

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

Когда Брендан Эйх создал самую первую версию JavaScript для Netscape Navigator 2.0 всего за десять дней, вряд ли он ожидал, в какой степени Slack Desktop App будет использовать его изобретение. Мы используем только кодовую базу JavaScript для многопоточного десктопного приложения, которое постоянно взаимодействует с нативным кодом и работает под Windows, macOS и Linux.

Управлять большими кодовыми базами JavaScript непросто. Всякий раз, когда мы мимоходом передаём объекты из JavaScript браузера Chrome в Objective-C, чтобы просто получить обратный вызов через другой поток на Node.js, нужна гарантия, что все кусочки складываются вместе. В десктопном мире маленькая ошибка может привести к сбою приложения. С этой целью мы внедрили TypeScript (статически типизированное надмножество JavaScript) и быстро поняли, как жить без волнений и с любовью к компилятору. И не только мы: опрос разработчиков на Stack Overflow показывает, что TypeScript является третьей самой любимой технологией программирования. Учитывая, насколько быстро статическая проверка типов набирает ход, мы хотим поделиться нашим опытом и методиками.

Перевод поста Стивена Вольфрама (Stephen Wolfram) "How Should We Talk to AIs?".
Выражаю огромную благодарность Полине Сологуб за помощь в переводе и подготовке публикации

---

Содержание

— Вычисления — это сила
— Язык вычислительного мышления
— Понимание ИИ
— Что будет делать ИИ?
— Постановка целей для ИИ
— Разговор одного ИИ с другим
— Сбор информации: обзор миллиарда лет
— А что, если бы каждый мог писать код?
— Действительно ли это будет работать?
— Скажу больше

---

Еще совсем недавно идея иметь компьютер, который может отвечать на вопросы на английском языке, казалась научной фантастикой. Но когда мы в 2009 году выпустили Wolfram|Alpha, одним из самых больших сюрпризов (по крайней мере, для меня!) стало то, что мы сумели сделать наш продукт реально работающим. И теперь люди ежедневно задают личным помощникам несметное количество вопросов — на обычном разговорном языке.



Все это достаточно неплохо работает (хотя мы всегда стараемся сделать лучше!). Но как насчет более сложных вещей? Как общаться с искусственным интеллектом?

Я долго думал об этом, пытаясь совместить философию, лингвистику, неврологию, информатику и другие области знания. И я понял, что ответ всегда был перед моим носом, и лежал он в той сфере, которой я занимался последние 30 лет: Wolfram Language.

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

Мы о многом рассказали в первой части. Теперь с синтаксисом покончено, давайте наконец перейдём к самому интересному: изучению преимуществ и недостатков использования статических типов.

Преимущество № 1: Вы можете заблаговременно находить баги и ошибки

Статическая проверка типов позволяет проверять, что определённый нами инвариант принимает значение true, даже не запуская программу. И если имеется какое-то нарушение этих инвариантов, оно будет обнаружено перед запуском программы, а не во время её работы.

Вы никогда не задумывались, почему тексты классических русских писателей так ценятся, а сами писатели считаются мастерами слова? Дело явно не только в сюжетах произведений, не только в том, о чём написано, но и в том, как написано. Но при быстром чтении по диагонали осознать это трудно. Кроме того, текст какого-нибудь значимого романа нам просто не с чем сравнить: почему, собственно, так прекрасно, что в этом месте появилось именно это слово, и чем это лучше какого-то другого? В какой-то мере реальное словоупотребление могло бы контрастно оттенить потенциальное, которое можно найти в черновиках писателя. Писатель не сразу вдохновенно пишет свой текст от начала до конца, он мучается, выбирает между вариантами, те, что кажутся ему недостаточно выразительными, он вычеркивает и ищет новые. Но черновики есть не для всех текстов, они отрывочны и читать их сложно. Однако можно провести такой эксперимент: заменить все поддающиеся замене слова на похожие, и читать классический текст параллельно с тем, которого никогда не было, но который мог бы возникнуть в какой-то параллельной вселенной. Попутно мы можем попытаться ответить на вопрос, почему это слово в этом контексте лучше, чем другое, похожее на него, но всё-таки другое.

А сейчас всё это (кроме собственно чтения) можно сделать автоматически.

Как разработчик JavaScript вы можете целый день программировать, но не встретить ни одного статического типа. Так зачем думать об их изучении?

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

Заинтересованы? Тогда вам повезло — именно об этом наша серия статей.

Во-первых, определение

Проще всего понять статические типы — это противопоставить их динамическим. Язык со статическими типами называют языком со статической типизацией. С другой стороны, язык с динамическими типами называют языком с динамической типизацией.

Модели Word2Vec

Как было упомянуто в первой части публикации, модели получаются из classes — представления результата текста word2vec виде ассоциативно-семантических классов путем сглаживания распределений.

Идея сглаживания в следующем.

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

Существует огромное количество алгоритмов кластеризации. Основная идея большинства из них – объединить одинаковые последовательности в один класс или кластер на основе сходства. Как правило, выбор алгоритма определяется поставленной задачей. Что касается текстовых данных, то здесь сравниваемыми составляющими служат последовательности слов и их атрибутов (например, вес слова в тексте, тип именованной сущности, тональность и пр.). Таким образом, тексты изначально преобразуются в вектора, с которыми производят разного типа манипуляции. При этом, как правило, возникает ряд проблем, связанных с: выбором первичных кластеров, зависимостью качества кластеризации от длины текста, определением общего количества кластеров и т.п. Но наиболее сложной проблемой является отсутствие связи между близкими по смыслу текстами, в которых используется разная лексика. В таких случаях объединение должно происходить не только на основе сходства, а еще и на основе семантической смежности или ассоциативности.

В продолжение статьи «Сравнение технологических подходов к решению задач по извлечению данных» рассмотрим технологии, наиболее часто упоминающиеся в связи с понятием «искусственный интеллект» в контексте поисковых задач. На habrahabr.ru опубликовано множество статей на эту тему, например, об использовании нейросетей в поиске Яндкса, в которой говорится что «Фактически, формулу ранжирования пишет машина (получалось около 300 мегабайт)», о глубоком обучении, о вероятностном программировании и т.д.

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

В качестве основы для наших рассуждений мы можем выбрать любую из приведенных ниже технологий. Ввиду того, что наиболее часто упоминается нейронные сети, их и возьмем. Набрав что-то про нейросети в поисковой строке, мы получим огромную массу статей о «невообразимых» успехах, достигнутых нейронными сетями. Это и сообщения о новых аппаратных решениях, например, и спиновые электронные устройства, и заявления IBM, о том что нейронные сети по анализу слов смогут выявлять психические болезни, и «супергеройское» зрение, и множество других чудес науки. Поэтому, попробуем сделать краткий обзор текущего положения дел.

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


Прошлые статьи вызвали оживленную дискуссию среди тех, кто использует для моделирования предметных областей инструменты ООП: языки ООП, нотацию UML. Несмотря на то, что я постоянно подчеркиваю, что объекты учета, о которых я веду речь, не моделируются средствами UML, и объясняю почему, тем не менее, вопрос об их моделировании методами ООП поднимается снова и снова. Наверно, мне надо еще раз рассказать, чем так плох ООП для моделирования предметных областей.

При написании этой статьи я сделал все возможное, чтобы сделать ее простой для чтения. Однако, в ней содержится очень сложный и нетривиальный вывод — почему методы моделирования операций, которые мы встречаем почти в каждой нотации, не дают нам удовлетворения. Я не видел подобного анализа нигде, даже в книге Криса Партриджа, которую я очень люблю: Business Objects: Re-Engineering for Re-Use. Поэтому я надеюсь, что статья будет легка и полезна одновременно.


Все модели, которые мы строим, должны так или иначе моделировать 4-х мерное пространство-время, потому что именно так мы представляем себе окружающий нас мир. Об этом рассказано в книге Криса Партриджа. Даже то, что кажется, не имеет отношения к 4-пространству, при внимательном рассмотрении оказывается оным. Правда, не всегда существующим в реальности, иногда — это воображаемый нами мир. Всем, кому интересно, как это происходит, рекомендую внимательно прочитать эту книгу. Однако, советую не обращать внимания на определение события в этой книге, — оно дано неверно.

Например, что такое болт? Это 4-х мерный объект, который ограничен в пространстве-времени определенными границами. Для моделирования болта существуют нотации, которые моделируют эти границы. Например, чертеж болта моделирует поверхность, которая ограничивает 3-х мерный объем. Добавив к этому чертежу еще 6 координат, зависящих от времени, мы получим модель поверхности 4-Д пространства — времени, которая моделирует болт.

Однако, что такое операция? Это — тоже 4-х мерный объект, который также, как и болт ограничен определенными границами в пространстве и во времени. Правда, представить себе операцию как 4-объект намного сложнее. Существуют три причины, по которым нам сложно это сделать.

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

В результате обучения человек привыкает к тому, что есть некоторые паттерны, повторяющиеся из раза в раз. Например, если поднять камень и отпустить его, он упадет на землю. И так будет всякий раз, когда повторится этот паттерн. Знание о том, что предмет падает на землю является эмпирическим опытом, не требующим объяснения. Всем, кто живет на Земле, этот факт кажется очевидным, не требует ни объяснения, ни доказательства, то есть, он понятен. Выглядит это знание как:

1. Эмпирический опыт – это множество (класс) ситуаций, которые расцениваются данным субъектом, как похожие друг на друга (субъект ронял предметы). Новые ситуации классифицируются субъектом как похожие на предыдущие и пополняют класс однотипных ситуаций.
2. Паттерн ситуаций (тип ситуаций, или модель ситуаций), который присутствует в сознании у субъекта и в котором записано, что всякий раз, когда случится подобное, тело падает на землю. Паттерн связан с эмпирическим опытом, или с классом ситуаций.

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

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

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

private double fBm(Vector2D v, int y)
{
    double result = 0f;
    double freq = Frequency;

    for (int i = 0; i < Octaves; ++i)
    {
        result += NoiseFn(permutation, v * freq) * Amplitude;
        freq *= Lacunarity;
        Amplitude *= Gain; // <-- Вот тут.
    }

    return result;
}

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

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



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