Чат-бот по базе знаний для сотрудников: как устроен, сколько стоит и где ломается

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

Разберем по частям: из чего он состоит, где живет, как устроен доступ и на чем такие проекты чаще всего умирают.

Из чего состоит такой бот

Четыре части, и только одна из них про нейросети.

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

Поиск по смыслу. Главная часть. Он находит нужный кусок текста, даже если человек сформулировал вопрос совсем не теми словами, что написаны в документе. Сотрудник спрашивает про возврат брака, а в инструкции написано рекламация по некондиции - поиск по словам провалится, поиск по смыслу свяжет.

Модель, которая пишет ответ. Она получает найденный кусок и вопрос, и формулирует короткий ответ. Важнейшее ограничение: писать она должна строго из переданного текста. Не из общих знаний о мире, а из вашего документа.

Канал. То, через что сотрудник задает вопрос. Об этом отдельно, потому что тут чаще всего ошибаются.

Почему Telegram, а не портал

Соблазн сделать красивый внутренний портал понятен. На практике он проигрывает мессенджеру по одной причине: в мессенджере люди уже сидят.

Портал требует привычки. Человеку надо вспомнить, что он существует, открыть браузер, войти. В момент, когда у него горит и он стоит у станка или едет к клиенту, он не сделает ни одного из этих действий - он позвонит коллеге. Ровно то, от чего вы уходили.

Бот в Telegram выигрывает потому, что мессенджер уже открыт. Вопрос задается за пятнадцать секунд, ответ приходит туда же. Голосом тоже можно, и на производстве это часто главный сценарий: руки заняты, а спросить надо.

Портал имеет смысл добавить вторым каналом для тех, кто работает за компьютером и хочет читать длинные документы целиком. Но первым каналом лучше делать тот, куда человек и так смотрит двадцать раз в день.

Права доступа: не показ, а поиск

Самая частая архитектурная ошибка - сделать поиск по всему архиву, а потом прятать от сотрудника то, что ему не положено. Это утечка, отложенная во времени: рано или поздно фрагмент закрытого документа окажется в ответе.

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

Практическая схема, которая работает:

• каждый документ при загрузке получает уровень: общий, отдела или закрытый под конкретный список людей;
• документ без пометки по умолчанию считается самым закрытым, а не открытым для всех. Это принцип запрещено, пока не разрешено, и он спасает от человеческой забывчивости;
• руководитель заводит свою команду сам, его люди автоматически видят документы своего участка;
• доступ к чужому открывает только собственник или операционный директор, точечно.

Такая схема позволяет пустить в систему всю компанию и не бояться, что производство увидит зарплатную ведомость.

Пять ошибок, на которых проект умирает

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

Ответ без ссылки на первоисточник. Сотрудник должен видеть, откуда взят ответ, и иметь возможность открыть документ целиком. Без ссылки любой ответ - это слухи, за которые никто не отвечает.

Нет честного не нашел. Если ответа в базе нет, система обязана так и сказать. Модель, которой не запретили, сочинит правдоподобное - и человек по этому сочинению сделает работу. Это худший из возможных исходов, хуже чем отсутствие бота.

Запуск сразу на всю компанию. Первые две недели система ошибается на редких формулировках, это нормально и лечится правками. Но если в этот момент ее увидели триста человек, репутация инструмента уже сложилась.

Нет человека, который правит базу. Кнопка не помогло должна вести не в пустоту, а к конкретному сотруднику, который дополнит документ. Без этого система застывает на том уровне, с которого стартовала.

Как правильно стартовать

Один отдел, один процесс, две недели.

Берете участок, по которому чаще всего задают вопросы. Загружаете только его документы, предварительно оставив по одной живой версии. Пускаете десять человек. Первую неделю смотрите каждый вопрос и каждый ответ, вторую - только те, где люди нажали не помогло.

К концу второй недели вы знаете честную цифру: какой процент вопросов система закрывает сама. Обычно это 70-85 процентов, и это хороший результат. Оставшееся - редкие случаи, которые и человеку приходится обдумывать.

Дальше расширяете на следующий отдел. Так система растет вместе с доверием к ней, а не вопреки.

Что происходит со стоимостью со временем

Неочевидная деталь: правильно устроенный бот со временем дешевеет.

Когда сотрудник получил ответ и подтвердил, что он подошел, связка вопрос - ответ - документ сохраняется. Следующий человек с похожим вопросом получает готовый ответ мгновенно, без обращения к платной модели. На типовых вопросах такой кэш снимает больше половины обращений.

Обратная сторона, о которой надо помнить: когда документ обновили, все сохраненные ответы по нему должны помечаться устаревшими и пересчитываться. Иначе система будет бодро отвечать вчерашними правилами, и это опаснее, чем медленный поиск.

Коротко о главном

Внутренний бот по базе знаний - это поиск по смыслу плюс модель, которой запрещено выходить за пределы ваших документов. Живет он лучше всего в мессенджере, потому что там уже живут люди.

Права должны работать на уровне поиска, а непомеченный документ считаться закрытым. Стартовать надо с одного отдела, а не со всей компании. И до всего этого в документах должен быть наведен порядок: на противоречивом архиве бот делает хаос быстрым, а не устраняет его.