Low-code і власна ШІ-платформа: як ми у Київстар змінюємо чат-бот «Зоряну»

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

Привіт! Мене звати Віктор Яцкін, я Product Manager у Kyivstar.Tech, дочірній IT-компанії телеком-оператора «Київстар». У Київстарі один з найбільших контакт-центрів в Україні — щомісяця він обробляє понад 1,5 мільйона звернень. Значну частину цього навантаження сьогодні бере на себе чат-бот «Зоряна». За кілька років він пройшов великий шлях — від Waterfall-проєкту на аутсорсі до власної платформи з ШІ-функціями.

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

Перша ітерація: замовник — новий підрядник

Наприкінці 2021 року в Київстарі відмовились від платформи попереднього вендора для чат-бота підтримки й змінили партнера. Однак підхід до процесу залишився незмінним — це Waterfall-проєкт, у якому на старті прописують сотні вимог до продукту та його контенту. У фокусі були функції, які має виконувати бот, інтеграції, що він повинен підтримувати, а також контент: скільки сценаріїв має бути реалізовано, які послуги можна підключити в боті тощо.

Від самого початку ми спиралися на коробкове рішення від вендора, яке вони конфігурували під наші вимоги. Поки ми поквартально рухалися за заздалегідь погодженим планом, з’явилися нові технології ШІ, зокрема LLM. Ми усвідомили, що напрям, у якому рухалися, вже на той момент не відповідав новій реальності, а платформа загалом виявилася недостатньо гнучкою.

Омніканальність

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

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

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

Друга ітерація: in-house конфігурація чат-бота

У певний момент ми забрали з конфігурації бота частину робіт, які спершу планували передати вендору, в in-house, і почали самостійно підтримувати та розвивати чат-бота. Це дало нам більше гнучкості й пришвидшило процес delivery: ми могли оперативно змінювати пріоритети залежно від бізнес-вимог — без погоджень між усіма сторонами, переоцінок скоупу всього проєкту, його бюджету тощо. Нам вдалося покращити багато речей, але також виявилися нові проблеми, які не дозволяли досягти тієї якості, до якої ми прагнули. Далі — по черзі.

Аналітика даних

Приклад аналізу шляху користувачів до конкретної події в Amplitude

На старті проєкту ми прописали у вимогах підряднику всі необхідні звіти та дашборди для процесів підтримки: дані про аудиторію, якість обслуговування та NPS (індекс споживчої лояльності), ефективність автоматизації, монетизацію самообслуговування в боті. Але коли ми побачили низькі оцінки якості та скарги користувачів, стало зрозуміло: формат звітності був надто обмеженим і не давав відповіді на запитання «чому так?».

Ми не мали можливості зануритися в глибину й переглядати аналітику в різних розрізах: яка була послідовність питань, що робив користувач у попередньому чаті, з якої сторінки сайту він відкрив бота тощо. Ми хотіли зрозуміти, де саме й чому виникає проблема у користувача. Наприклад, чи проблема в самому тексті повідомлення, чи ШІ-класифікатор неправильно розпізнав тему, чи, можливо, бот отримав некоректні дані з бекенду. Або ж банально — в інтерфейсі не видно кнопки. В існуючій системі аналітики ми цього не бачили, а щоб внести зміни, потрібно було створювати новий CR (change request) на вендора, проходити погодження, оцінку, бюджетування тощо. Це було довго й дорого.

Тоді ми паралельно зі звітами вендора вирішили інтегруватись в більш гнучкі industry-standard рішення, такі як Google Analytics чи Amplitude. Вони забезпечують просту інтеграцію для передачі подій із десятками додаткових параметрів, які ми можемо динамічно додавати, а також ширші можливості для аналізу. Це дозволило оперативно створювати звіти по кожному сценарію й досліджувати кореневі проблеми в конкретних точках UX. Ми аналізували реальні поведінкові патерни користувачів і фокусувалися на тому, як усунути критичні бар’єри у взаємодії.

Розширення команди та git-flow

Після переходу до самостійної конфігурації чат-бота зʼясувалося, що вендорська No-Code платформа не підтримує базових можливостей для ефективної командної розробки.

Масштабувати команду й працювати паралельно над різними частинами бота було складно. В цій системі не було інструментів для нормального версіонування і гілок, процесу review, персональних оточень, роботи з mock-даними, порівняння версій та вирішення merge-конфліктів і подібних звичних для розробки софта процесів.

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

Спойлер: тепер у нас всі зміни, навіть в контенті, проходять через git

«Чужий» бекенд

Приклади запитів у чат-боті «Зоряна». Наприклад, щоб повністю закрити запит користувача щодо стану рахунку, дані для відповіді збираються з 5 послідовних API-запитів

Оскільки розробку ми починали з підрядником, а згодом поступово перейшли до власної конфігурації бота, частина важливих інтеграцій усе одно залишилася під контролем вендора. Це стосувалося як frontend-частини — інтерфейсу самого бота та функціональності для месенджерів, так і всього backoffice: конфігурації контенту, роботи з ШІ-моделями та датасетами, а також деяких ключових backend-інтеграцій із системами Київстар (наприклад, аутентифікація). Усі ці компоненти були недоступні для змін з боку нашої команди.

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

Через ці обмеження ми втрачали швидкість і гнучкість у розробці. Усередині команди час від часу виникали проблеми з взаєморозумінням: одні спеціалісти відповідали за контент для чат-бота, інші — за сервіси, що забезпечували збір даних. Вони просто спілкувались різними мовами.

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

Приклад low-code сценаріїв на новій платформі

Третя ітерація: в пошуках свободи (in-house розробка)

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

Ми переглянули рішення від гігантів індустрії, які в багатьох аспектах вже стали стандартом — Google, Microsoft. Їхні платформи (Dialogflow, Bot Framework) забезпечують високу гнучкість і відповідають багатьом критеріям. Однак при детальнішому аналізі з’ясувалося, що вони працюють добре тільки у межах власної екосистеми.

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

Чи існує магія LLM?

Одним із перших компонентів, звісно ж, ми почали вбудовувати великі мовні моделі — як пропрієтарні, так і Open Source. Досить швидко стало очевидно, що магія «рішень з коробки» не працює. Навпаки, повне перекладання логіки на LLM створює низку додаткових проблем — зокрема галюцинації та некерованість у складних сценаріях, де потрібно чітко проводити користувача через визначені процеси.

Багато рішень із використанням LLM на ринку продаються з таким value «в один крок завантажити базу знань своїх компаній в агента, і він вам ідеально відповідатиме». Однак це так не працює, принаймні для нас. У нас занадто багато контексту, процесів і систем. У Київстар — величезні обсяги даних, і вони структуровані по-різному. Тому нам все ще необхідно адаптувати нашу базу знань і сценарії чат-бота — класичні підходи до роботи з LLM та RAG у нашому випадку не дають потрібного результату.

Фото з мого виступу на CВОЄ.ІТ 9.05.2025, Мистецький Арсенал, Київ

Саме тому наш продукт зараз не покладається виключно на великі мовні моделі, він гібридний за своєю архітектурою. Ми використовуємо різні AI-рішення в комплексі. Окрім LLM (які ми активно пілотуємо для різних юзкейсів і вбудовуємо у продукт дуже контекстно — лише там, де вони працюють на 99,9% так, як нам потрібно), ми також застосовуємо NLU-класифікатори (Natural Language Understanding). Вони допомагають розпізнати й класифікувати запит, щоб спрямувати його в потрібний сценарій, вже в якому ми контрольовано запускаємо rule-based процес чи підключаємо специфічного LLM-агента. Це своєрідний аналог мультиагентного підходу, але з більшим рівнем керованості.

Приклад NLU

Підсумки — де ми зараз

Інтеграція в бот додаткових опцій, таких як опитування користувачів

У підсумку наша команда вирішила рухатися у напрямку створення власної платформи-ядра, до якої ми поступово додаємо різні компоненти, зокрема з AI/ML, і яку можна налаштовувати під потреби компанії. В її основі — опенсорс-інструменти та гібридна архітектура:

• Rule-based сценарії — для чітких запитів з інтеграціями в треті системи;
• NLU — для класифікації інтенцій;
• LLM/агенти — у випадках, коли потрібна гнучкість, врахування контексту діалогу, більша персоналізація відповідей.

Сьогодні команда є повністю власником процесу: від інтеграції з API месенджерів до аналітики. Ми маємо власну платформу, збудовану навколо Open Source low-code рушія, й готуємо до запуску inhouse-інфраструктуру, адаптовану під масштаб, складність та вимоги бізнесу. І ми поступово впроваджуємо наш гібридний продукт з різними технологіями ШІ, зберігаючи повний контроль над досвідом клієнтів.

І звісно, за чат-ботом завжди стоять живі експерти підтримки, які допоможуть у найскладніших ситуаціях. Для нас чат-бот і ШІ — це інструменти для спрощення та автоматизації рутинних процесів, але не повна заміна людей.

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

Трансформація «Зоряни» стала для нас цікавим викликом і перетворилася із задачі «змінити вендора» на процес зміни підходу до створення продуктів у новому світі AI-transformation. Ми пройшли шлях від залежності від вендорів і обмежених інструментів до повного контролю над платформою та архітектурою, що дає велику гнучкість у розвитку продукту й покращенні досвіду клієнтів. Сьогодні ми поєднуємо rule-based логіку, NLU та LLM у гібридній моделі, яка забезпечує гнучкість і масштабованість без втрати керованості контентом.

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

Попереду — багато роботи та амбітних цілей, але тепер у нас є і гнучка платформа і команда, щоб їх досягти.