Искусственный интеллект. Можно по-разному оценивать его влияние на мировые тренды в IT, можно относиться к нему скептически, можно боготворить. Однако совершенно точно нельзя его игнорировать. С этим согласятся более 500 человек, посетивших конференцию AI-MEN в Бизнес-Инкубаторе ПВТ 2 июня. Участников встретило множество компаний и стендов, были организованы meet- и work-зоны, а в двух залах спикеры делились своими знаниями и наработками.

Открыл конференцию генеральный директор BelHard Group Игорь Мамоненко. Он сразу отметил, что AI — не просто high-tech, а суперхайтек, и работа с ИИ — самая высокооплачиваемая и перспективная специальность в мире. Работа с искусственным интеллектом — в здравоохранении, в банковской, страховой и торговой деятельности — это, по сути, подключение некоего умного существа, которое подсказывает, как вести бизнес лучшим образом. Лидером, конечно, является США, но у Беларуси есть возможность их догнать. Наша страна занимает достойное место и в мире, и в Европе, и мы можем претендовать на финансирование со стороны Евросоюза в сфере разработки AI.

В первую очередь, эти деньги направлены на развитие науки, но у нас уже около 70 стартапов работают с использованием искусственного интеллекта, и число их растёт. Каждый второй стартап, связанный с искусственным интеллектом, получает финансирование (в отличие от обычных стартапов, где реально на деньги может претендовать только один из десяти). Сфера AI, как отметил Игорь Мамоненко, сейчас суперприбыльна и суперпопулярна. У сотрудника ПВТ, занимающегося искусственным интеллектом, зарплата сразу на полторы тысячи долларов выше средней. Также он подчеркнул, что подтягиваются и курсы, долгосрочные и краткосрочные, но в этой сфере необходимо фундаментальное знание.

 

Перспективы развития искусственного интеллекта в Республике Беларусь

Именно об этом фундаментальном знании говорил Владимир Голенков, доктор технических наук, профессор, заведующий кафедрой ИИТ БГУИР. В Беларуси сейчас сформировались уникальные обстоятельства, позволяющие серьёзно смотреть на перспективы в области ИИ. Уже более 20 лет существует специальность «Искусственный интеллект» в БГУИР, в БГУ, а также в Брестском государственном техническом университете на кафедре интеллектуальных информационных технологий. Сообщество небольшое, и, в отличие от России, где образовалась трещина между бизнесом и наукой, у нас такого разрыва нет.

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

При этом многие считают, что могут рассуждать об ИИ, его сущности и понятии, и поэтому возникает путаница. Однако даже среди учёных могут быть разногласия и разночтения. Поэтому спикер в качестве ликбеза привёл такое определение: ИИ — это научная дисциплина, объектом исследования которой являются интеллектуальные системы, компьютерные системы следующего поколения. С этим понятием связаны интеллектуальные задачи — задачи, решаемые в условиях нефакторов, неполноты и нечёткости. Но решать их надо, правда, непонятно как, «делай так, не знаю, как, но делай». Классов таких задач огромное количество: рассуждения, доказательства теорем, распознавание. И эти задачи решают интеллектуальные системы. Но суть их не в решении, а в обучаемости, умении быстро обучаться. Расширение знаний и навыков системы вполне может достигнуть тех масштабов, что и позволит ей решать задачи. Эта самая обучаемость обеспечивается несколькими факторами: гибкость, стратифицированность, рефлексивность и гибридность. Гибкость — это способность системы быстро меняться и менять самоё себя, с учётом новых обстоятельств. Стратифицированность связана с тем, что изменения какой-то части системы учитывались только в рамках этой части, чтобы последствия не учитывались везде.

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

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

 

ML в оценке навыков сотрудников и распределении задач

Затрагивая тему искусственного интеллекта, нельзя оставить в стороне и машинное обучение. О возникновении идеи его применении на практике рассказал Lead Software Engineer компании Zensoft Андрей Рыхальский. В начале всего лежал просто инженерный интерес, «надо это попробовать».

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

О самом процессе ML рассказал Machine Learning Engineer компании Zensoft Роман Нагибов. Навыки сотрудников были разбиты по категориям (к примеру, Development), каждая из которых включала в себя теги (скажем, Backend и Frontend), которые, в свою очередь, представляли собой группу атомарных навыков — экспертиз (таких как MySQL, Scala или Freemarker). Они были необходимы для оценки навыков сотрудника. В качестве обучающей выборки анализировались данные по уже завершённым задачам, из которых извлекались такие поля: заголовок, описание, экспертиза, запланированное и реально затраченное время на задачу, а также исполнитель. Первоначально техлид ставил априорные отметки каждому сотруднику по каждой из экспертиз. После этого результат выполнения каждой из задач анализировался, а навыки сотрудника по соответствующим экспертизам при необходимости корректировались. При этом учитывались такие факторы, как сложность задачи относительно уровня соответствующих экспертиз исполнителя, успешность выполнения задачи, завершение её в запланированный срок. Помимо этого также анализировалось, как другие разработчики справлялись со схожими задачами. Схожесть определялась по текстовым описаниям — заголовкам — при помощи методов обработки естественного языка (NLP).

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

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

Когда же задача переходит в разряд выполненных, данные по ней собираются и добавляются в обучающую выборку, при необходимости корректируется оценка экспертиз её исполнителя. Алгоритм рассчитывает не только показатель от 0 до 100% (названный нами вероятностью успеха), предсказывающий, насколько быстро и качественно сотрудник справится с задачей, но и показывает причины, по которым тот или иной кандидат подходит для задачи лучше других. На основании вероятности успеха, а также детальных причин, менеджер проекта принимает решение о назначении задачи тому или иному исполнителю — таким образом последнее слово всегда остаётся за человеком.

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

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

 

Интеграционные тесты для моделей машинного обучения

Тему машинного обучения продолжил Алексей Гапоник, AI Tribe в WorkFusion. Компания использует ML для автоматизации бизнес-процессов клиентов.

При работе с автоматизацией реальных бизнес-процессов задача становится гораздо сложнее, чем просто натренировать и проверить модель. Рассмотрим пример: предположим, у клиента есть некоторая система А, где хранятся отсканированные документы (например, выставленные счета). Из документов этой системы клиенту необходимо извлекать некоторые данные и переносить в систему Б (например, номер счёта, сумму, валюту и т.д.). На данный момент этим занимаются сотрудники, которые вручную из системы А «вбивают» в систему Б данные. Для автоматизации такого процесса необходимо решить сразу несколько проблем.

Сперва надо как-то достать документы из системы А. Эта система может быть написана давно, не иметь API для сторонних систем, и единственный способ с ней взаимодействовать – через UI, нажимая кнопки и щелкая мышкой. Подход к решению такой задачи — Robotic Process Automation (RPA) — набор инструментов, позволяющий программно воспроизводить взаимодействие пользователя с системой. Этим же способом можно и вносить данные в систему Б.

Следующая задача — преобразовать отсканированные документы в текст. Решение: OCR-системы, которых существует достаточно много (как коммерческих, так и бесплатных). Далее необходимо сформировать обучающую выборку – набор документов, содержащих правильные ответы. Для этого подключаем сотрудников клиента, которые переносили данные, даём им инструменты для разметки правильных ответов в документах, которые сохраняем в хранилище.

Следующим пунктом идёт определение признаков (features) – данных, на которых мы будем обучать модель. Для разных процессов (для разных видов документов) это могут быть совершенно разные признаки. Тут вступают в работу специалисты по данным (Data Scientist-ы). Они анализируют документы, пытаются определить релевантные признаки (feature engineering), экспериментируют с ними (feature selection) и в конце получают модель и результаты для данного конкретного набора документов. Предположим, что модель в 90% случаев даёт верный результат и в 10% ошибается. С точки зрения бизнеса вопрос: что же делать с этими 10%? Их нельзя выкинуть и нельзя внести неправильные данные в систему Б. Эту задачу решает процесс Human-in-the-loop (HITL) — «человек-в-цикле».

Исходя из статистики, собранной в процессе тренировки, мы можем построить правило для отбора ответов модели на основе возвращаемого моделью confidence score. Ответы модели, имеющие недостаточный score, отправляются людям (экспертам) для проверки и корректировки. Эксперты могут что-то поправить и добавить, если ответ неправильный. Ответы людей отправляются в конечную систему. Кроме того, эти же ответы добавляются в обучающую выборку, на которой модель можно будет перетренировать для получения лучших результатов. Итого, после решения всех указанных задач скорость обработки документов увеличилась, т.к. людям нужно обрабатывать лишь малую часть документов. Клиент доволен, и хочет продолжать автоматизировать новые бизнес-процессы: «Отлично, мне нужно автоматизировать ещё 99 процессов». И для каждого процесса нам нужна команда Data Scientist-ов, чтобы подобрать признаки именно для этого набора документов. Кроме того, оказывается, что для большинства из этих процессов клиент просто не может предоставить доступ к документам, потому что они содержат важную финансовую или персональную информацию, и не могут быть переданы другим сторонам.

Что делать в таких условиях: Data Scientist-ов катастрофически не хватает, доступа к документам нет? Решение простое: нужна система, которая позволила бы минимизировать или вообще исключить участие людей в процессе feature engineering и feature selection. Именно такое решение и реализовано в системе AutoML. Эта система позволяет автоматически подбирать конфигурацию модели (из набора существующих компонент), которая для конкретного набора данных клиента даст достаточно хорошие результаты (параметры ожидаемого качества модели могут настраиваться). Процесс поиска оптимально конфигурации состоит в том, что AutoML выбирает некоторое множество конфигураций-кандидатов, проводит для них эксперименты с тренировкой и проверкой моделей, собирает результаты, тренирует нейронную сеть для выбора следующей серии «наиболее перспективных» конфигураций для экспериментов и т.д., до тех пор, пока не получится конфигурация с достаточным уровнем качества. Конфигурация с лучшими результатами будет основой для продуктовой модели.

Естественно, процесс этот достаточно сложный и для эффективного выполнения необходим кластер, т.к. на одной машине процесс будет идти очень долго или найденная конфигурация будет недостаточно хорошей (из-за того, что за ограниченное время не удастся провести достаточное количество экспериментов). AutoML должен не только натренировать модель, но и выгрузить данные и артефакты для других систем платформы Smart Process Automations. Кроме того, время процессап тренировки модели тоже должно быть предсказуемым.

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

• Процесс тренировки выполняется успешно. Процесс должен корректно завершаться как с корректными документами, так и с наборами, содержащими поврежденные или пустые документы.
• Тренировка не занимает слишком много времени.
• Все процессы, выполняющиеся на кластере, запущены с корректными параметрами (RAM, CPU и т.д.).
• Качество результатов натренированной модели находится в заданных параметрах.
• Модель при выполнении возвращает все данные, необходимые для других систем (confidence score для HITL и т.д.).
• При выполнении модели время обработки одного документа и общая производительность модели находятся в заданных параметрах.

Для тестирования используется достаточно стандартный набор инструментов и подходов: создан CI-pipeline для Jenkins, который забирает нужные данные (наборы документов и т.д.), запускает Unit-тесты, написанные на Java. Эти тесты запускают процесс тренировки, собирают статистику о процессах, происходящих на кластере, их параметрах (RAM, CPU, время работы и т.д.). После окончания тренировки проверяется, выгружены ли все необходимые данные, необходимые для остальных подсистем, присутствуют ли все необходимые артефакты, все ли процессы на кластере были с правильными параметрами и т.д. Если всё успешно — тест прошёл, если нет — тест «упал», и необходимо разбираться и «чинить» проблему.

Особенности тестирования:

• Для тестирования необходимы достаточно большие наборы файлов (обучающие и контрольные выборки). Их нецелесообразно хранить в исходниках проекта – поэтому они лежат на S3 и скачиваются в момент запуска тестов
• Т.к. для тестирования используется кластер, то цена тестирования важна: для оптимизации расходов на тесты используется эластичный автомасштабируемый кластер: количество нод в кластере варьируется в зависимости от нагрузки. Когда тесты не выполняются, кластер стоит «пустой».
• Также для оптимизации расходов используется подход fail-fast: тесты собраны в пакеты, от более «легких» к «тяжелым». Если есть серьезная проблема в коде, то упадет пакет «легких» тестов, а тяжелые даже не запустятся.

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

 

О строгом и нестрогом подходе к пониманию естественного языка при решении задачи доступа к данным

Тему лингвистики осветил Дмитрий Королёв, Head of Machine Learning компании FriendlyData. Сам спикер начинал с анализа текстов. Раньше к NLP было три подхода. Классический представляет собой идею описания строгими формальными правилами грамматики всего языка. Также существовал подход со стандартными алгоритмами Text Mining, вроде SVM. Набирала популярность и своего рода генеративная модель: есть «чёрный ящик», который выдаёт документ-список слов (порядок не важен), где проверялось наличие слов. Модель эта была двухходовой, она, зная заголовок, могла искать ключевые слова темы. Но ведь такой процесс можно и обратить: по ключевым словам искать тему. А затем появились нейронные сети. Ранее это называлось Deep Belief Network, сейчас просто Deep Learning.

Что же изменилось с тех пор? Были придуманы алгоритмы, которые не переобучались, в том числе и «нейронки». То есть это тот случай, когда можно очень долго обучать сеть, и при этом при смене данных не будет осечек. Также появилось новое «железо», способное производить много итераций оптимизации. CPU были слишком медленными для этого, поэтому придумали использовать шейперы с GPU. А затем стало понятно, что GPU можно использовать и без экрана, не для рендеринга, а для чего-то более сложного. И это всё развивается. Но самое интересное — это осознание, что понимать модель человеку необязательно. Это поднимает вопрос, устраивает ли нас «чёрный ящик». По мнению спикера, лучший ответ: «Это зависит», ведь в понимании модели есть свои плюсы. Например, если она сломается (случайно или, что чаще, специально), то без понимания её нельзя будет починить.

Безусловно, есть такие ситуации, когда «чёрный ящик» отлично работает, а есть и другие, в которых лучше понимать модель. К первым можно отнести ситуацию, когда стоимость ошибки невысока, много данных и модели хочется часто обновлять, а также когда точность является критическим параметром, и метрика качества может часто меняться. «Чёрный ящик» будет плох в ситуации, когда цена ошибки слишком высока (например, нейронной сети не стоит доверять управления атомным реактором). Кроме того, может иметь место и «человеческий» фактор (история с Google и нераспознаванием на фотографии людей с определённым цветом кожи). И, конечно, если появится опасность «умной» атаки, то справиться и защитить модель, принцип работы которой не понимаешь, будет невозможно. Такого рода проблема присутствует в системе распознавания лиц. Можно наложить определённый грим или даже наметить черты, по которым система признает вас как гендиректора крупной компании, даже если внешне вы с ним абсолютно непохожи. Поэтому всегда надо иметь возможность «отменить» и иметь дополнительную степень защиты (в этом случае банальный бейджик).

Хотя сам Дмитрий Королёв верит, что в будущем «чёрные ящики» будут использоваться, компания FriendlyData придерживается строго описательного подхода к тому, что можно и что нельзя. Причин сразу несколько: во-первых, до того в компании уже использовался подобный подход; во-вторых, это позволяло чувствовать себя «не как все» на рынке; в-третьих, это позволяло быстро исправлять ошибки, не ломая ничего другого.

Также спикер подчеркнул, что сам он верит в «фичи» на стыке ML и «хардкорного» инжиниринга. Наличие формального описания, пусть и широкого, сильно упрощает замыслы таких «фич» как «спеллчекер» или, например, систему «Имели вы в виду что-то». Запрос с опечаткой не будет работать, но её можно исправить и тогда система всё поймёт. Это что-то вроде Google Suggest, которая подсказывает, какое слово писать дальше. Это довольно важно, ведь она помогает как пользователю, так и самому бизнесу. Также в FriendlyData поняли: даже если им придётся уйти в гибридный подход (или к подходу с «чёрными ящиками»), сделать это можно легко и правильно. Спроектировав плюсы и минусы «чёрных ящиков» и NLP, можно прийти к выводу: если задача по определению имеет вероятностное решения, то всё-таки нужно подобие «чёрного ящика». Ведь бывают ситуации, когда для любой сформулированной метрики машина оказывается лучше человека. Например, это касается распознавания звуков или даже эмоций (в случае, если написан отзыв, а надо определить, какие реально эмоции испытывал человек во время его написания). Но если наш запрос важно понимать строго и если лучше уточнить, чем ошибиться, то строгость, конечно, лучше. Например, при переводе юридического текста, где важны каждая буква и запятая.

 

Software 2.0 — технологии и приложения

В будущее заглянул и исполнительный директор Artezio (группа компания ЛАНИТ) Павел Адылин. Он сразу поднял вопрос о том, что, как и с термином «цифровая трансформация», многие говорят об искусственном интеллекте, не имея единого понимания, что это означает. Возможно, что виной этому то, что AI — это самое часто упоминаемое словосочетание в СМИ из темы IT. Во многом это инициировано аналитиками, которые заменили «скучный» термин «машинное обучение» на более красивый. По сути, сейчас ИИ разделяется на три зоны: распознавание образов, работа с естественными языками и машинное обучение, к которому относят все то, что не попало в первые две группы.

ИИ развивается циклически. Сперва ставится задача, кажущаяся невозможной: например, научить систему распознавать лица, и эту задачу относят к ИИ. Постепенно развивается технология, и, в конце концов, происходит прорыв, об этом сперва восторженно говорят, а потом это становится обыденностью — кто сейчас не знает Google Assistant или Siri, и где же здесь интеллект? При том, что раньше эта задача также относилась к ИИ. Кроме того, можно вспомнить AlphaGoZero, которая, играя сама с собой в го, в процессе обучения, нашла такие стратегии, которые современными игроками просто не используются. Задача научить компьютер играть в го еще недавно также считалась неподъемной и, соответственно, тоже относилась к ИИ.

Сам термин Software 2.0 очень тесно связан с понятием ИИ. Этот термин ввёл Андрей Карпатый. Суть Software 1.0 в том, что на каком-то из языков программирования пишутся инструкции для компьютера, а в Software 2.0 уже программируются параметры модели или веса нейронных сетей. При этом стек Software 2.0 не конкурирует и не приходит на смену Software 1.0. Он использует наработки, созданные в рамках Software 1.0, программный код всё равно пишется на тех же языках программирования, используется весь современный классический стек разработки. Но при этом всё больше и больше решений и положений будут содержать в себе элементы нового стека.

Когда видишь весь список алгоритмов и архитектур нейронных сетей, возникает вопрос, как в этом разобраться. Компания Artezio выбрала для себя путь корпоративного обучения. В сотрудничестве с Нижегородским филиалом ВШЭ был разработан курс для сотрудников. Первоначально (в 2015 году) был сделан упор на большие данные, технологии их хранения и обработки, но за три последующих года курс был, по сути, переписан. Это свидетельство той скорости, с которой развивается направление. Цель обучения – подготовить инженеров, которые смогут профессионально разрабатывать и внедрять приложения с ИИ. Каждое занятие посвящается одному из методов машинного обучения и сопровождается практическими домашними заданиями.

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

По информации Gartner, лишь 4% респондентов уже реализовали проекты с технологией ИИ. По другому опросу, около 70% респондентов плохо понимают, что такое искусственный интеллект. С одной стороны, это свидетельствует о большом перспективном рынке. С другой — возникают сложности в работе с клиентами. Спикер условно разделил заказчиков на два типа: «консерваторы» и «энтузиасты». Первые относятся к ИИ как к чему-то из разряда научной фантастики, вторые же читают новости, следят за сферой и считают, что уже сейчас искусственный интеллект может всё. И те, и другие не знают, чего хотят, не имеют метрик для оценки результата, не заботятся о чистоте данных, а также не отличают простых задач от сложных. 

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

С точки зрения методологии имеет смысл придерживаться существующих межотраслевых стандартов, разработанных для Data Mining. Спикер считает наиболее логичной и удобной смешанную бизнес модель: сперва работают аналитики по Time & Material, делается прототип приложения, а после выяснения объёма работ происходит переход на Fix Price. Модель Success Fee, несмотря на свою привлекательность, с точки зрения прибыльности содержит в себе много опасностей из-за малого количества прецедентов внедрения аналогичных проектов и широких возможностей для интерпретации результатов. В заключение докладчик еще раз отметил, что основной проблемой во внедрении Software 2.0 остается наличие и чистота данных, на которых обучаются модели.

Организаторы конференции: Старейший белорусский IT-портал KV.by и Парк высоких технологий. 

Партнеры конференции: WorkFusion, Zensoft, MapBox, BelHard, ИТ-Академия "БелХард", МТС, Invatechs.

Коммьюнити-партнеры: DataTalks, "Открытые данные".

Партнеры кофе-паузы:  Природная вода "Боровая", Кондитерская фабрика "Алвеста", Чай ТМ JafTea.

Генеральный инфопартнер: Onliner.