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

Усі статті, обговорення, новини про AI — в одному місці. Підписуйтеся на DOU | 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 ідею того, що це — асистент, який економить час та кошти нашої команди. Зрештою, останнє слово все одно завжди залишатиметься за людиною. Експертиза та досвід кожного спеціаліста все ж мають значно більшу вагу.

👍ПодобаєтьсяСподобалось1
До обраногоВ обраному1
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Шановна редакція, взагалі, статтья — сутто рекламного характеру і не несе будь-якої користі ком’юніті, що прямо протиречить правилам публікації:

Які статті ми НЕ публікуємо:
Рекламний та піарний контент (зокрема, прихований 🙃).

Приблизно пів року тому донька попросила мене написати скрипт, який перетворює голос в текст з якістю GPT-3.5 та вище. Не довго думаючи, я створив такий скрипт на Python (40 рядків коду) і підключив до нього свій акаунт в OpenAI. Скрипт працює в консолі — запускаєш команду в якій вказуєш шлях до файлу запису, чекаєш пару хвилин і в результаті створюється текстовий файл з транскрибуванням. Він працює швидко та ефективно: швидкість обробки — приблизно 2-3 хвилини за годину запису, а вартість обробки приблизно 0,15 центів за годину запису.
Хотілося б дізнатися, чому у вас вартість обробки становить 3 долари за годину, що в 20 разів вище моєї вартості, якщо можливо напишіть свої кости, може я щось не врахував?

скрипт можна переглянути тут: github.com/...​van/voice-to-text-chatGPT

Тут в мене є декілька відповідей:
1. Для самої транскрипції ми використовуємо окрему модель, яка спеціально натренована для роботи з транскрипцією. До неї ми додали додаткові можливості, такі як Speaker Diarization, що дало нам змогу досить якісно розпізнавати спікерів на дзвінках і формувати результат у вигляді діалогу.
2. GPT-3.5 і вище не є моделями які можуть робити транскрипцію, у вашому коді я бачу що ви використовуєте модель яка також є доступною в рамка АРІ від Open AI
3. Нажаль ми не дуже встигаємо оновити наш лендінг і ціна там не дуже актуальна. Ми згодом актуалізуємо всю інформацію на нашому сайті.
4. Ціна транскрипції у нас $0.1 / minute, що є в межах середньої ціни на ринку. Ми зараз працюємо над винесенням функціоналу транскрипції окремо від АІ аналізу, і згодом така функція буде доступна

Дякую за відповідь. Якщо дозволяє ваша бізнес-модель, то можна залучити більше клієнтів з різними потребами та бюджетами і трохи кастомізувати ваш функціонал для забезпечення більшої гнучкості цін. Наприклад, деякі користувачі (студенти, журналісти, інтерв’юери, викладачі, дослідники) можуть бажати просто транскрибувати голосовий файл і самостійно його відредагувати. Вони готові платити мінімальну ціну, наприклад, $0.01 за хвилину. Інші користувачі можуть потребувати повного пакету послуг, включаючи Speaker Diarization та AI аналіз, і готові платити $0.1 за хвилину. Наприклад, мій скрипт добре підходить для інтерв’ю з мінімальною кількістю учасників, для цього він й був створений.
Також цікаво, чи є у вас якісь еталонні семпли, які можна було б використовувати для тренувань та тестування?

Це ж було вже!©

Взагалі то, кожен раз як бачу наші вітчизнянні інтеграції продуктів машинного навчання у процеси чи продукти, перше, шо ріже очі, це відсутність будь якого розуміння етики AI (у нас про неї навіть не чули). Ну то таке, розвинеться академічна освіта, з’явиться більше наших рідних спеціалістів, розробників продуктів, воно прийде. Кому все ж таки цікаво — link.springer.com/...​0.1007/S10551-022-05049-6

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

В цілому про скрінінг з використанням AI тулзовін багато матеріалів, і дослідники не дуже впевнені, що воно корисно. Просто так брати ШІ та «натягувати» туди, де нема спочатку достатнього об’єму даних та відпрацьованої статистики, це не дуже розумний підхід. Он сучасна медицина побудована на коректному аналізі великих даних, і всеодно дуже багато проблем саме з автоматизацією з використанням ШІ інструментів, тому що воно не так просто, а наявні інструменти не ідеальні. А тут LLM інтегрували (чи просто заговорили про це), і вже ШІ-поверед.

Це все є в тімсі...

Самі інтерв’ю з кандидатами мені подобаються, завжди цікаво говорити із колегами-розробниками.
А от написання відгуків після співбесід...

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

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

А що буде якщо кандидат відмовляється від запису? Кандидати, що не плюють на кібербезпеку та приватність — не потрібні конторі?
Що там по GDPR і тд?

Та і взагалі спроби використання «автоматизації процесу співбесід» (або отакі, або тести, набори літкод задач) — це величезний червоний прапорець відносно контори.

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

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

не токстіть не для того це робиться.

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

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

Якщо що, то я вже багато років проводжу співбесіди і у мене для вас новина — адекватні досвідчені наймаючі менеджери не читають той фідбек далі ніж саммарі з оцінкою «брати/не брати». Недосвідчені іноді пробують самі порівнювати фідбеки, але швидко щось йде не так, коли виявляється співбесіди проводило більше ніж 1 інтерв’юер. Ще звісно є токсичні або формалізовані контори, які думають що сильно автоматизований процес найму працює, але там зазвичай чомусь проблеми з утриманням персоналу і відносинами в колективі :)

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

Токсичність — це пасивна агресія. Про «адекватних менеджерів» — я ж вам кажу масс рекрутинг, напевно просто вам довіряють вже але не надали повноважень всеодно, або якщо чесно їм швидше за усе пофіг. На звіті від спеціалістів написано — accept, ну і берем з гори приказали розширити філіал на 50 людей, просто нема часу заморочуватись. Потім тим свіже найнятим людям, призначують з гори начальників і піде конкретна така плинність кадрів. Але, вимоги головного офісу були виконані вчасно і усі довольні, крім головного офісу, який починає міряти бюджет на хайрінг і випадає в осадок. Після чого відкривають власні курси, ретельно відбирають студентів в універах, щоб не брати людей просто з вулиці і потім звільняти бо набрали не тих і не туди.
В цілому же я скажу так — що на співбесіді по суті в більшості випадків міряются комунікативні навички, а також базова підготовка з проходження співбесід. Часто люди які добре програмують — таких навичок реально не мають.

Токсичність — це пасивна агресія.

Не все що вам неподобається або ви нездатні переварити є токсичністю і ПА.
По виділеній цитаті ви не зможете прикрутити ні те ні інше.
А те що я не використав образливих слів які були доцільні в цьому випадку — це називається ввічливість :)

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

Знову не ясно що ви включаєте в поняття «масс рекрутинг» і як воно на щось впливає.
Ті кому пофіг будуть дивитись на фінальну оцінку і максимус саммарі, ті кому не пофіг ... вейт фор іт ...так само. Остаточне рішення буде прийняте на 1-2-1 спілкуванні з кандидатом.

Даний інструмент чудово підійде для контор, що не розглядають працівників як людей. При тому я кажу не просто про галерне — ресурс, а про потогонки та «кузні кадрів». Чи треба такі контори працівникам?

Та і взагалі спроби використання «автоматизації процесу співбесід» (або отакі, або тести, набори літкод задач) — це величезний червоний прапорець відносно контори

Смішно. На нормальні компанії йде нормальний наплив кандидатів, і їх вручну фільтрувати просто нерентабельно.

Смішно. На нормальні компанії йде нормальний наплив кандидатів, і їх вручну фільтрувати просто нерентабельно.

Давайте сміятись разом:
— нормальні компанії — це які? ФААНГ — це нормальні компанії? Як вони справлялись з напливом 10+ років тому?
— нормальний наплив — це скільки кандидатів на позицію?
— нерентабельно — це які втрати?

У мене для вас новина: рентабельність великого напливу вирішується за рахунок початкової фільтрації резюме, до співбесіди люди не доходять. Та і ті ж ФААНГи в цільових регіонах відбирали вручну, а на всіляких «хайрінг івентах» давали тестове, яке просто відмовлялася робити велика кількість кандидатів і так зменшували наплив. Але і «нормальність» позицій для Х1Б чуваків і для локалів була різна

А навіщо скриншоти взагалі? )))

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

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

Навіщо взагалі ваш сервіс, навіщо сплачувати вартість ChatGPT 4.0a токенів + ваш фіі, якщо можно шляхом того ж ChatGPT написани враппер навколо API під свої потреби десь за день?

Перша версія сервісу — MVP була реалізована трошки більше ніж за тиждень, та включала в себе базовий функціонал User managemnt-у (Реєстрація, Вхід, Налаштування профайлу) та основну функцію — опраювання та аналіз рекрутинг мітингів. Далі було багато роботи по оптимізації існуючих промптів та написання нових, проведено багато роботи для надання можливості додавати декількох користувачів до одного середовища(Воркспейсу) організувавши їх в групи, та надавши їм потрібні повноваження.

Ви як інженер мабуть змогли б відносно швидко зробити для себе швидке рішення використовуючи наявні інструмменти та сервіси, проте нашим сервісом користуються не тільки інженери, а й люди без технічних навичок, яким побудувати подібне рішення було б значно складніше. Додатково можу сказати, що робота з промтами також є досить специфічною, особливо якщо мова йде про автоматизацію складних бізнес процесів, де потріно уважно і досить детально описати всі свої очікування від АІ. Наш продукт не є примітивним врапером над GPT, але є самодостатньою екосистемою з багатьма додатковими можливостями — Дуже якістна транскипція аудіо/відео з підтримкою 100+ мов та розпізнаванням мовців, Організація середовища для роботи різних корпоративних відділень(Recruitment, HR, Sales, etc.), Швидкий доступ до результату обробки та транскипції для менеджерів. Також, за потреби ми кастомно розробляємо промпти для індиідуальних потреб наших користувачів.

Перша версія сервісу — MVP була реалізована трошки більше ніж за тиждень

Я так і написав:

можно шляхом того ж ChatGPT написани враппер навколо API під свої потреби десь за день

з кабінетом десь за тиждеть — це нормально.

Ви як інженер мабуть змогли б відносно швидко зробити для себе швидке рішення використовуючи наявні інструмменти та сервіси

Я, як керівник, перш за все буду думати, що для мене краще: кожен місяць сплачувати за декілька аккаунтів моїх тіммейтів вашому сервісу або разово розгорнути промт навколо ChatGPT для всієї організації?

Наш продукт не є примітивним врапером над GPT, але є самодостатньою екосистемою

Ядро якої — примітивний враппер над GPT.

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

Ми ж про GPT 4.0a говоримо, чи ще про 3.5?

а скриншоті ви бачите загальні нотатки

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

непонятно, что вообще этот помощник делает.

Приваблює інвесторські грошенята на хвилі хайпу.

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

Підписатись на коментарі