Інтелектуальний HR-асистент: чат-бот на базі LLM

Чому AI-чат-бот для HR буксує на пілотному запуску

Пілотний запуск асистента зазвичай виглядає переконливо: на підготовлених питаннях AI-чат-бот для HR відповідає складно й швидко.

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

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

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

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

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

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

Третя — якість ніхто не вимірює. Зворотний зв’язок вигляду «відповідь корисна / не корисна» не показує, на якій частці звернень асистент помилився, а де просто промовчав.

Без набору еталонних питань і розбору реальних діалогів пілот нічим полагодити й нічим захистити перед керівництвом.

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

Вимірюваний ефект: час відповіді, навантаження, якість даних

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

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

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

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

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

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

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

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

Режими роботи асистента: база знань, генерація, гібрид

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

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

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

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

Етапи впровадження: від аудиту процесів до передачі в підтримку

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

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

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

3. Налаштування на базі знань. Регламенти розбиваємо на фрагменти й прив’язуємо до тем, задаємо правило: відповідати лише за підтвердженими джерелами, за низької впевненості — не здогадуватися.

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

5. Пілотна група співробітників. 20–30 осіб із різних підрозділів працюють з асистентом у звичайному режимі. За журналом діалогів видно, які формулювання не розпізнаються і де зростає навантаження на людей.

6. Доопрацювання та передача в підтримку. Правимо формулювання, додаємо сценарії, уточнюємо пороги передачі людині. HR-команда отримує панель з історією діалогів і регламент оновлення бази знань — далі супровід іде за ним.

Що передаємо на руки: конфігурації, регламенти, документація

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

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

• Конфігурація асистента: системні інструкції, дерево сценаріїв, пороги впевненості, нижче яких відповідь користувачу не віддається, — з історією змін і відкатом на попередню версію.
• Схема інтеграцій: які системи пов’язані (кадровий облік, календар, база знань), у який бік ідуть дані, де точки відмови і як обробляється недоступність зовнішнього сервісу.
• Матриця прав доступу: ролі співробітника, керівника, HR-спеціаліста й адміністратора, до яких даних і дій кожна допущена, які поля маскуються у відповіді.
• Регламент ескалації: умови передачі діалогу людині, черга й строки реакції, хто розбирає невдалі відповіді та як вони потрапляють у доопрацювання.
• Описи сценаріїв: перелік тем, які асистент закриває сам, межі компетенції та заготовки відповідей на межові питання.
• Інструкції для підтримки: як знайти історію діалогу, відтворити збійну відповідь, вимкнути окремий сценарій і повернути попередню конфігурацію.
• Політика роботи з даними: що зберігається, скільки зберігається, як видаляється за запитом співробітника, — цього достатньо для внутрішнього аудиту та перевірок.

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

Кейс кадрової служби: метрики до і після впровадження

Замовник — виробнича компанія з майданчиками в кількох регіонах: близько 4 000 співробітників, кадрова служба з дев’яти осіб.

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

Метрики до і після

Асистента Кадровый помощник підключили до внутрішньої бази регламентів і шаблонів документів, спірні теми залишили за живим спеціалістом. Заміри знімали на тому самому потоці звернень через квартал після запуску.

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

Що залишилося поза межами проєкту

• Асистент готує проєкти документів, але не підписує й не проводить накази.
• Питання про оплату конкретного співробітника, стягнення та звільнення йдуть напряму спеціалісту.
• Рідкісні теми закриті частково: відповідь без опори на регламент позначається як неперевірена.
• Обмін із зовнішнім кадровим порталом залишився зоною відповідальності замовника.

Що робити, якщо у вас уже працює свій чат-бот

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

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

Як є залишаються інтеграції: доступ до HR-системи, календаря, тикетниці, корпоративного месенджера на кшталт Microsoft Teams, права та ролі співробітників. Вебхуки, сервісні облікові записи й розмежування доступу зберігаються — змінюється лише той, хто формує відповідь.

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

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

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

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

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

Асистент не отримує доступ до всієї кадрової системи. Ми заводимо окремий сервісний акаунт із правами лише на читання потрібних полів і обмежуємо його даними одного підрозділу: запит про графік відпусток не витягне відомостей про компенсації суміжних команд.

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

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

Як ви контролюєте якість відповідей?

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

Що буде, якщо асистент помилиться?

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

Обговоримо задачу й повернемося з оцінкою та планом робіт

Щоб оцінка AI-чат-бота для HR була предметною, а не «плюс-мінус», розбір задачі йде одним маршрутом: дивимося сценарії звернень, джерела даних і обмеження за доступами, а потім повертаємося письмовим документом, де зафіксовано оцінку, склад пілоту й критерії приймання.

Нижче — що корисно надіслати на старті; якщо чогось немає, відсутнє уточнюємо на дзвінку з профільними інженерами.

• Список реальних питань співробітників до HR — від частих («скільки днів відпустки залишилося») до рідкісних і спірних.
• Регламенти, положення та інструкції, за якими асистент має відповідати: що повніший корпус, то нижча частка відповідей «не знаю».
• Перелік систем-джерел — кадрова система, HR-портал, файлове сховище — і хто відповідає за доступ до кожного.
• Вимоги до розмежування прав: які теми бачить рядовий співробітник, які — лише HR і керівник підрозділу.
• Обмеження щодо персональних даних і внутрішніх документів: що асистент не повинен показувати й записувати в логи.
• Метрики приймання: наприклад, частка відповідей без передачі живому спеціалісту та точність на еталонному наборі питань.
• Контактна особа з боку замовника, яка підтверджує сценарії та приймає пілот.

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