Интеллектуальный 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 и руководитель подразделения.
• Ограничения по персональным данным и внутренним документам: что ассистент не должен показывать и записывать в логи.
• Метрики приёмки: например, доля ответов без передачи живому специалисту и точность на эталонном наборе вопросов.
• Контактное лицо со стороны заказчика, которое подтверждает сценарии и принимает пилот.

На выходе вы получаете план работ с этапами и сроками, состав пилота (какие каналы подключаем — чат в корпоративном мессенджере, виджет на портале), схему разграничения доступов и набор проверок, по которым приёмка будет объективной. Опишите задачу и пришлите то, что есть, — вернёмся с оценкой и планом.