Практики проєктування від архітектора: AI&ML в сфері продажів

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

Усім привіт. Мене звати Максим Москвичов, я — Head of Architecture Design Office (ADO) у Yalantis. Сьогодні розповім вам про архітектурні прийоми і практики на прикладі проєкту зі штучним інтелектом і машинним навчанням. Про цей проєкт я розповідав під час мітапу Yalantis AI&ML edition, де був запрошеним спікером. Ділюсь деталями з вами.

Мета проєкту — розробити чат-бот з використанням методів машинного навчання. Почавши з технічного завдання, ми зосередилися на розробленні ефективної архітектури для цього чат-бота. З цієї статті ви дізнаєтесь про практики, які ми використовували під час проєктування та про ресурси, що можуть стати у пригоді для досліджень у галузі AI&ML і не тільки.

Ідея проєкту

Ідея створення чат-бота прийшла з відділу продажів компанії для підвищення конверсії лідів з нашого сайту. Yalantis займається розробкою програмного забезпечення вже 15 років, компанія здобула великий досвід. Наразі на нашому сайті компанії опубліковано понад 500 кейсів.

Однак, шукаючи відповідні послуги, клієнти можуть пропустити релевантні статті й подумати, що компанія не має необхідної експертизи. Чи може нам допомогти потужність платформи OpenAI? Так.

За допомогою штучного інтелекту та машинного навчання, ми зможемо покращити взаємодію з нашими клієнтами та забезпечити швидкий доступ до потрібної інформації.
Перш ніж починати розробку, ми провели докладний аналіз наших вебданих та зворотного зв’язку від клієнтів:

• на першому етапі комунікації більшість клієнтів просять надати актуальні кейси, попри те, що вони вже опубліковані на сайті;
• близько 1000 унікальних відвідувань на день;
• лише 0,5% відвідувачів сайту виходять на зв’язок.

Кроки, які виконує архітектор

Перше, що треба зробити — Architecture Vision (візії архітектури). Це переформулювання вимог замовника, щоб зрозуміти бізнес-цілі, варіанти використання та обмеження проєкту. Ці архітектурні драйвери ми розробляємо разом із замовником.

• Business goals

BG-1: скоротити час конверсії лідів на етапі Prospect stage на 50%.
BG-2: підвищити ефективність роботи відділу продажів шляхом створення зручної бази кейсів.

*the Prospect stage — це час від початку зацікавленості відповідного ліда компанією до фактичної розмови про конкретний проєкт. Під час цього робиться дослідження компанії на наявність потрібної замовнику експертизи. Саме цей проміжок часу важливо скоротити.

• Use cases

Зроблені на підставі business goals.
Use cases може бути й більше, але виписувати треба ті, які будуть прямо впливати на архітектуру проєкту.

UC-1: клієнти використовують чат-бот на корпоративному сайті для пошуку відповідних кейсів, щоб дізнатися більше про Yalantis.
UC-2: відділ продажів використовує чат-бот у Slack, щоб знайти відповідні кейси за ключовими словами.

• Constraints (обмеження)

Це чинники, які впливають на архітектуру проєкту, але не прописані в бізнес-цілях. Архітектор має врахувати ці обмеження під час розробки архітектури.

СТ-1: бюджет і терміни. Система має бути розроблена одним інженером упродовж двох місяців.

Далі в нас є драйвери, які формуються вже без замовника. Це Architecture Concerns, тобто те, про що не прописано в бізнес-цілях, але ми маємо про це памʼятати; те, що впливає або на візібіліті рішення (без цього рішення не буде працювати) або на його якість (наприклад, зробити сторінку з моніторингом).

Для цього проєкту ми виділили 4 concerns:

CN-1: треба натренувати бот даними з нашої компанії. Без цього бот буде давати загальні відповіді, що не є релевантними для нашої компанії.
CN-2: дані мають бути верифіковані та доповнені sales-командою, щоби бот відповідав голосом бренду.
CN-3: OpenAI має відому слабку сторону у генерації посилань.

Після ідентифікації консьорна CN-3 ми провели proof of concept, щоби переконатися, що OpenAI може генерувати потрібні нам відповіді, але справді виникла проблема якості коректних посилань. Це призвело до четвертого concern — верифікації посилань, які генерує чат-бот.

CN-4: нам потрібно верифікувати лінки, які бот згенерував.

Ці аспекти архітектури є ключовими драйверами для нашого проєкту. Вони визначають ті напрямки, які ми маємо врахувати під час розробки архітектури чат-боту.

Business Architecture

Якщо проєкт простий, бізнес-архітектуру можна малювати відразу, якщо ні — покроково.

Бізнес-архітектура — це важлива складова процесу проєктування, оскільки вона дає змогу краще зрозуміти всі системи, що використовуються в проєкті. Тут мають бути відображені актори та системи, які ми самі будемо розробляти, та готові системи, які ми беремо з SaaS чи Open Source.

Ми використовуємо фреймворк C4 для побудови бізнес-архітектури. Він дозволяє швидко створювати зрозумілі та ефективні діаграми для всіх учасників проєкту.

В системі мають бути всі актори, які працюють з цими системами. Ідеально буде зробити їх опис. Наприклад, у нас мова про те, що клієнт користується чат-ботом на сайті, а sales-команда користується ботом у Slack. Для тренування ми зробили проєкт генератор Training data, який парсить сайт, дивиться case study та генерує питання-відповіді. Ми працюємо з публічними даними; з такими, де немає NDA.

Є дві основні діаграми, які ми створюємо під час проєктування:

Deployment view діаграма особливо корисна під час проєктування системи та для DevOps. Вона відображає, де можуть виникнути проблеми та допомагає зосередитися на потенційних ризиках.

На System Context діаграмі стрілки відображають залежності між системами. Наприклад, лід залежить від роботи сайту (якщо сайт не працює, то немає нових лідів), але сайт не залежить від ліда (сайт може працювати незалежно від наявності лідів).

Ці діаграми (System Context та Deployment view) — обов’язкові компоненти процесу проєктування.

Фреймворк C4 дозволяє нам створювати не тільки ці дві діаграми, але й більше.
Я рекомендую вам ознайомитися з ним детальніше, оскільки він є важливим інструментом для будь-якого архітектора. Залишаю посилання для ознайомлення.

Buy or built

Тобто чи потрібно нам розробляти щось власноруч або ми можемо взяти готове рішення. Далі на слайді я покажу, які готові рішення ми використали для нашого чат-бота:

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

У інших варіантах купляти готове краще, бо менше сапорта коду та менше багів у майбутньому.

Архітектурні підходи

Архітектурний принцип — Decision Log

Цей принцип допомагає нам приймати обґрунтовані рішення і мати аргументи для команди, клієнтів та себе.

Залишаю найпоширеніші питання:

Рекомендації від провідних вендорів у галузі

Technology Radar від Thoughtworks. Thoughtworks — це австралійська компанія архітекторів зі штатом +3000, що надають послуги з консалтингу.

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

Tradeoff Analysis

Цей підхід допомагає виявити потенційні ризики в архітектурному рішенні. Ви можете використовувати таблицю з архітектурними драйверами та рішеннями для аналізу компромісів.

Наприклад, ви можете побачити, які драйвери будуть задоволені вибраним рішенням, а які можуть мати ризики. Це допомагає вам зрозуміти, які компроміси ви приймаєте під час проєктування архітектури.

Аналіз компромісів є ефективним способом виявлення потенційних ризиків і забезпечує повноту врахування всіх чинників.

Кожний рядок в таблиці це архітектурні рішення (AD). Їх ми маємо 4:

Далі йдуть колонки з архітектурними драйверами, які ми обговорювали спочатку: BG, UC, СT, CN.

Наприклад, щоб BG-1 сталася, нам потрібні всі 4 архітектурні рішення. А ось для BG-2 нам достатньо виконати останні дві. Це ми позначаємо літерою S (sensitive).

N — означає (Non-risk). Наприклад, коли якесь архітектурне рішення підтримує драйвер, але й без цього рішення драйвер буде виконуватись (UC-1). Так, клієнт використовує чат-бот на сайті, в який ми не додали тренувальних даних. Чат надасть йому відповідь, але її якість буде бажати кращого.

R — означає ризик. Він стоїть тільки напроти драйверу CT-1.
Є ризик, що sales-менеджери не встигнуть верифікувати тренувальні дані, бо цю задачу важко проестімувати, на відміну від інженерної. І це є потенційний ризик.

T — Tradeoff (архітектурне рішення заважає виконанню архітектурного драйвера).
В нашому випадку, якщо ми будемо рефайнити посилання через гугл, це буде заважати потраплянню в строки. Без верифікування посилань у нас буде менше естімейт. Знов ж таки, система буде працювати, але менш якісно.

Висновок

Проєкт розробки чат-бота з використанням методів штучного інтелекту та машинного навчання є прикладом того, як сучасні технології можуть покращити взаємодію між компанією та її клієнтами.

Ретельне вивчення потреб користувачів та визначення ключових сценаріїв взаємодії допомогли нам розробити чат-бот, який забезпечує релевантні та персоналізовані відповіді на запитання клієнтів.

Отже, ми з вами сьогодні пройшлися по колу TOGAF так, як би це робив архітектор.

TOGAF (The Open Group Architecture Framework) охоплює два основні аспекти, які мають значення для архітектора програмного забезпечення: архітектурний цикл та архітектурний процес. Детальніше читайте на сайті.

Цей проєкт є лише одним прикладом того, як штучний інтелект та машинне навчання можуть змінити спосіб взаємодії між бізнесом і клієнтами. Ми живемо в епоху, коли технології відкривають нові можливості для покращення ефективності та задоволення потреб користувачів. Буду радий вашим коментарям та кейсам з практики!