Як ми вигадали і розробили ШІ-інструмент для співбесід

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

Вітаю! Мене звати Андрій, я CTO в компанії Impressit. Сьогодні розкажу вам, як ми з командою вигадали та розробили ШІ-інструмент, що допомагає проводити співбесіди та формулювати фідбек після них.

Як народжувалась ідея інструменту

Я ніколи не любив проводити співбесіди. Хоча ні, не так. Самі інтерв’ю з кандидатами мені подобаються, завжди цікаво говорити із колегами-розробниками. А от написання відгуків після співбесід... Тому коли ШІ-інструменти почали десятками з’являтись на ринку, я почав роздумувати про те, як штучний інтелект міг би допомогти мені (та багатьом іншим залученим у рекрутменті людям) спростити процес надання фідбеку після співбесіди.

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

Ми хотіли, щоб наш інструмент не лише транскрибував запис і створював нотатки мітингу; він також мав би, аналізуючи дані з записаних розмов та усіх доступних ресурсів, обирати релевантну інформацію, за запитом користувача та у потрібному форматі.

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

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

Ми розуміли, що ці опенсорсні ШІ-моделі не справлялись би з ними на достатньо високому рівні, без додаткового Fine Tuning, який ми не могли собі дозволити, через обмеження в ресурсах і необхідність швидше провалідувати ідею. Зупинитись вирішили на GPT (на той момент, останньою версією був GPT-3.5 Turbo).

Обравши GPT-3.5 Turbo, ми стикнулись із першим викликом — обмеження цієї версії моделі. GPT-3.5 Turbo вміє опрацьовувати 16 385 токенів (включаючи 4000 токенів як результат обробки). Якщо взяти годинний діалог у нормальному темпі — це приблизно 20 000–25 000 токенів.

Мітинги та співбесіди, для яких розроблявся наш інструмент, тривали орієнтовно годину. Довелось розбивати діалог на дві частини — закидати в обробку першу частину, отримувати результат, закидати в обробку другу частину, отримувати результат, а згодом їх об’єднувати. Загалом, навіть така схема працювала непогано, але ми прагнули кращого.

GPT-4 та стадія MVP

За кілька днів до релізу MVP-версії Asistme.ai з’явилась новина про те, що GPT-4 став доступним у платній версії, яку можна використовувати через API. Одна з доступних версій GPT-4 може опрацьовувати до 128 000 токенів, що для нас дорівнює практично п’яти-шести годинам розмови.

По-перше, якість результатів, які продукує Asistme.ai, стала відчутно кращою. По-друге, у GPT-4 з’явилась можливість отримувати відповідь у JSON-форматі, вказавши це на рівні конфігурації.

Так, реліз GPT-4 дійсно дав Asistme.ai всі необхідні інструменти для розвитку. Завдяки GPT-4 наш інструмент працює значно краще, ніж раніше, коли нам доводилося робити додаткові маніпуляції з даними для якісної обробки. Мінусом є лише вартість — на сьогодні GPT-4 у 20 разів дорожчий за GPT-3.5 Turbo.

Процес розробки Asistme.ai

Робота над цим проєктом побудована на підході accelerated product development (APD). APD — це радше глобальний підхід, що об’єднує певні процеси менеджменту, сфокусованих на швидку й ефективну розробку людей і ефективний технічний підхід, аніж просто окреме технічне рішення.

Раніше цей підхід ми використовували для швидкого запуску клієнтських продуктів. В основі нашої версії APD лежать вже готові рішення ready-to-use, які закривають більшість (повторюваних) задач. Ще декілька років тому ми побачили можливість в тому, щоб упорядкувати самодостатні «модулі».

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

Щобільше, перевагою нашого підходу стало й те, що використовуваний код є ready-to-scale: на його основі можна будувати значно складніші рішення, які витримують серйозніші навантаження, досить просто монолітна модульна система може трансформуватись в рішення з повноцінною мікросервісною архітектурою. Тобто це гарний, перевірений фундамент для масштабних проєктів, які, до того ж можна переводити на будь-яку іншу архітектуру або просто скейлити за потреби.

Ще одним плюсом підходу APD є оптимізація процесів, завдяки чому ми можемо залучати значно меншу кількість ролей на проєкті. А це значно спрощує менеджмент. На практиці я самостійно поєднав задачі проєктного менеджера, бізнес-аналітика та скрам-майстра.

Звісно, коли мова йде про розробку великих і складних рішень на post-mvp фазах, то ці ролі мають значення і є важливими для ефективного управління командою. В першу чергу через необхідність зрозуміти всі «підводні камені», специфіку продукту, а часто — й особливості індустрії. Проте в нашому випадку весь фокус полягав у тому, щоб максимально швидко заделіверити якісний продукт, без збільшення штату.

В результаті — з нуля до готового рішення (не MVP) пройшло менш ніж п’ять місяців роботи двох інженерів з частковою залученістю.

На цій схемі можна побачити базовий архітектурний підхід технічних рішень в рамках APD:

Зокрема перелічені модулі (вони зображені праворуч), які закривають найтиповіші задачі клієнтів та знадобились і нам: Core, User Management, Security, Notification, Admin, Workspace. Окремо ми винесли все ж таке поняття як Custom module, який передбачає що за потреби під’єднати принципово нове рішення (наприклад, модуль для менеджменту мітингів) — це зробити дуже просто. Зовні це виглядає як монолітна система, але, за потреби, кожен з модулів доступний для редагування.

З лівого боку схеми зображені вхідні точки, якими можуть бути Mobile, Web або Admin portal. Оскільки модулі між собою не комунікують, щоб зв’язати їх, ми використовуємо CORE API. За основну базу даних ми зазвичай використовуємо PostgreSQL, хоча ми досить гнучкі в цьому плані, і завдяки використанню TypeORM-бібліотеки, ми можемо адаптувати практично будь-яку базу даних до наших модулів. Зазвичай ми використовуємо AWS як основний крауд-провайдер та маємо ряд готових terraform-скриптів для сетапу всіх необхідних нам сервісів — IAM, AWS RDS, S3, CloudFront, ECR, ECS, etc.

Як працює Asistme.ai

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

На вкладці Meetings можна побачити взагалі усі проведені мітинги, а також є стрічка пошуку. Згодом будуть додані також фільтри, за допомогою яких можна буде ефективніше проводити пошук. Тут є кнопка для створення нового мітингу, яка відкриває спливне вікно для створення нового мітингу.

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

Отож, після того, як ви натисли на кнопку New meeting, заповнили всю необхідну інформацію та додали медіафайл, Asistme.ai почне процесинг і біля назви мітингу стоятиме жовта позначка Transcribing. Також для цього можна використовувати розширення Asistme.ai для Google Chrome, яке дозволяє записувати мітинг прямо з браузера та автоматично запускає опрацювання мітингу після його завершення.

Усього за кілька хвилин після цього вам потрібно буде перезавантажити сторінку (але зараз ми вже працюємо над автоматичним оновленням статусу) Meetings і вуаля — біля назви мітингу з’явиться зелена позначка Ready та ви зможете побачити результати опрацювання мітингу. Оскільки Asistme.ai вміє розрізняти мовців, то транскрипція вашого мітингу виглядатиме наступним чином:

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

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

Як бачите, у цьому конкретному юзкейсі отримана специфічна інформація допомагає і технічному спеціалісту з боку компанії у написанні відгуку після співбесіди, і рекрутеру під час надання фідбеку для кандидата. Крім цього, згодом цю інформацію можна використовувати й під час наступного перформанс-ревью (якщо кандидат отримає офер від нас), оскільки легко можна буде побачити зростання рівня знань та навичок людини.

Що далі у планах

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

Хоча ми починали розробку Asistme.ai з конкретною метою (спрощення виконання задач у процесі рекрутменту), тепер бачимо великий потенціал цього інструмента. Його місією є оптимізація наших бізнес-процесів та економія часу та коштів як наслідок. Так, ми можемо автоматизувати багато рутинних повсякденних задач, за допомогою нашого інструмента аналізуючи мітинги й на базі отриманої інформації виконуючи специфічні задачі, відштовхуючись від потреб кожного працівника.

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

Завершити хотілось би традиційною для дискусій про ШІ ремаркою, що штучний інтелект — це помічник. Остаточні рішення завжди приймає людина. Є задачі, які цілком спокійно можна довірити штучному інтелекту та бути впевненим на 99% у правильності результатів. Але якщо ми говоримо про серйозні задачі, від яких може залежати успіх бізнесу, чиясь робота чи ще щось доволі серйозне, то всі результати варто перевіряти.

Ми вкладаємо в Asistme.ai ідею того, що це — асистент, який економить час та кошти нашої команди. Зрештою, останнє слово все одно завжди залишатиметься за людиною. Експертиза та досвід кожного спеціаліста все ж мають значно більшу вагу.