Конференція AI-MEN 2018: штучний інтелект, машинне навчання і Software 2.0

1. Перспективи розвитку штучного інтелекту в Республіці Білорусь
2. ML в оцінці навичок співробітників і розподілі завдань
3. Інтеграційні тести для моделей машинного навчання
4. Про строгому і нестрогому підході до розуміння природної мови при вирішенні задачі доступу до даних
5. Software 2.0 - технології та програми

Штучний інтелект. Можна по-різному оцінювати його вплив на світові тренди в 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 .