Почему пилот проходит легко, а внедрение – нет
С генеративным искусственным интеллектом сложился характерный сценарий. Компания выбирает большую языковую модель (LLM), подключает ее к выгрузке документов и за пару недель собирает демонстрационный прототип. Он производит впечатление на руководство: помощник отвечает связно, ссылается на документы, экономит время. Проект получает бюджет – и на этом останавливается.
Дело в том, что на демонстрации показывали работу модели, но в промышленной эксплуатации всплывает много вопросов. Кто отвечает за то, чтобы документ в базе был актуальным? Что делать, когда два регламента противоречат друг другу? Как объяснить системе, что этот раздел видит только служба безопасности? Как подключить к тому же контенту чат-бот на сайте, не заводя для него отдельную базу?
Корректность ответа лежит не только на языковой модели, но и – даже в большей степени – на исходном контенте. Это и есть причина, по которой систему управления знаниями и ИИ-слой имеет смысл рассматривать не как два продукта, а как одну архитектуру: первая отвечает за то, что система знает, второй – за то, как она это отдает. Причем отдает сразу двум аудиториям – сотрудникам и ботам.
База знаний: чем отличается от простого хранилища файлов
Система управления знаниями (в англоязычной практике – KMS, Knowledge Management System) – это среда, где корпоративный контент хранится, структурируется, поддерживается в актуальном состоянии и выдается сотруднику с учетом его прав доступа. Задачам и преимуществам таких систем у нас посвящен отдельный материал; здесь – только те свойства, на которые дальше опирается ИИ-слой.
Главное отличие от файлового хранилища: хранилище отвечает на вопрос «где лежит документ», система управления знаниями – «какой ответ верный прямо сейчас». Для этого контент размечается по онтологии (схеме категорий и связей), делится на тематические разделы с разными правами доступа, версионируется и поддерживается редакторами. Один регламент может существовать в разных формах – например, полным документом для инженера и пошаговым скриптом для оператора – и это будут не две расходящиеся версии, а один источник.
Запомним эти четыре свойства:
-
структура
-
права доступа
-
актуальность
-
разные формы подачи.
На них опирается все остальное.
Как устроен ИИ-портал
ИИ-портал – это общекорпоративная платформа, где рабочий контент хранится вместе со встроенными инструментами генеративного искусственного интеллекта. Проще говоря, это единая точка доступа к ИИ-инструментам для всех сотрудников компании, а не отдельный чат-бот, созданный под задачи конкретного отдела.
Языковая модель – «мозг», который умеет формулировать, но ничего не знает о вашей компании. ИИ-портал – прослойка между моделью и контентом: она решает, что показать модели, кому можно показать результат и в каком виде.
Вот из чего складывается такая прослойка:
-
Встроенный поиск с дополненной генерацией (технология RAG) – извлекает релевантные фрагменты из базы знаний и передает их модели как контекст. Как эта схема работает в суфлере оператора и в агентном чат-боте, мы разбирали отдельно.
-
Коннектор к языковым моделям – позволяет подключать разные модели, локальные или облачные, в зависимости от задач и требований безопасности.
-
ИИ-помощник – внутренний диалоговый ассистент, работающий строго по документам компании и дающий ссылки на источники.
-
Суммаризатор – автоматически делает краткую выжимку из документа, в том числе из офисных форматов.
-
Автоклассификатор – предлагает редактору категорию для нового материала, сопоставляя его содержание с профилем категорий в классификаторе.
-
Программный интерфейс (API) и ИИ-агенты – возможность отдавать сервисы помощника внешним системам и собирать агентов под узкие задачи.
Суммаризатор и автоклассификатор работают не на конечного пользователя, а на редактора. Наполнение и поддержание базы – самая трудозатратная часть любого проекта, и ИИ здесь окупается раньше, чем в клиентских сценариях.
Что меняется, когда ИИ наслаивается на базу знаний
Система «обучается» самостоятельно. Расхожее представление, будто ИИ нужно «переобучать» под компанию, к этой схеме не относится: модель каждый раз получает свежий фрагмент из базы. Отредактировали регламент во вторник – со вторника помощник отвечает по новой редакции. Команда инженеров по машинному обучению для этого не нужна.
Права доступа учитываются на уровне поиска. Помощник не процитирует сотруднику документ, к которому у того нет доступа: документ просто не попадет в выборку. Для банков, госсектора и медицины это условие входа, а не приятное дополнение.
Форма ответа зависит от того, кто спрашивает. Промпт – это текстовая инструкция, задающая модели роль, тон и правила ответа. Ее можно менять как для всей базы, так и для отдельных разделов. Так из одной платформы получается несколько специализированных ИИ-консультантов: один отвечает языком инструкции для инженера, другой – короткими формулировками, которые оператор зачитает клиенту.
Качество ответов корректируется без программирования. Если помощник ответил неверно, чаще всего чинить нужно статью в базе, а не модель. Это меняет состав проектной команды: вместо дорогих специалистов по искусственному интеллекту нужны редакторы и методологи – и меняет то, кому в компании принадлежит результат.
Единая база для сотрудников и ИИ-помощников
Суфлер подсказывает оператору, а агентный бот отвечает клиенту – но откуда оба берут контент?
Зачастую, база для операторов существует отдельно, сценарии чат-бота – отдельно, так же как и регламенты самообслуживания на сайте. Три источника, три команды сопровождения и три расходящихся набора ответов, причем расхождение накапливается незаметно и может обнаружиться уже в жалобе клиента.
Альтернатива: свести все в одну базу с актуальными документами, к которой можно обращаться через единый программный интерфейс, тот самый ИИ-портал. Тогда чат-бот на сайте, голосовой помощник, виджет внутри системы управления клиентами и внутренний портал сотрудника опираются на одну и ту же информацию. Редактор правит статью один раз – правка одновременно доезжает до клиента в чате и до оператора на линии.
Что это дает на практике:
-
клиент и сотрудник получают согласованный ответ независимо от канала;
-
исчезает дублирующая работа по поддержанию отдельной «базы для бота»;
-
новый канал подключается как еще один потребитель того же контента, а не как проект с нуля;
-
статистика вопросов из всех каналов стекается в одно место и показывает, каких материалов в базе не хватает.
Например, банк АЭБ внедрил базу знаний InKnowledge вместе с голосовым помощником BSS и за счет этого снизил нагрузку на операторов, повысив скорость и качество обслуживания. Логика та же – знания живут в одном месте, а каналы к ним подключаются.
Конкретные эффекты, подтвержденные практикой
Что дает наведение порядка в знаниях
В Локо-Банке после пилота в подразделении, обслуживающем малый и средний бизнес, время удержания клиента на паузе сократилось на 53% (замер по группе опытных сотрудников), число ошибок – на 68%, среднее время обработки обращения – на 9%. При этом 93% сотрудников отметили, что работать стало удобнее. Система была развернута в закрытом контуре банка.
В компании «Комус» после внедрения на 30% уменьшился отток стажеров с позиции оператора контакт-центра, а полная адаптация сотрудника заняла около месяца. В ФНС скорость и качество обслуживания налогоплательщиков выросли на 30%.
Эти цифры во многом относятся к внедрению корректной и актуальной базы знаний, что подтверждает исходный тезис: большая часть эффекта обязана наведению порядка в контенте, а затем еще больше усиливается ИИ.
Что добавляет ИИ-слой
По внутренней аналитике вендора и отзывам заказчиков, время на поиск информации сокращается примерно втрое, а количество ошибок снижается до 40%. Эти данные стоит считать ориентиром, а верный способ проверить эффект – загрузить собственные документы и посмотреть, как инструменты сработают на реальных данных.
Что решить до старта проекта
Контур размещения. Установка на серверах компании, защищенное облако или гибрид. Для банков, госсектора и промышленности ответ очевиден, а вот для менее жестко регулируемого бизнес это может стать первым вопросом повестки. О том, что стоит за выбором между собственным контуром и облаком, у нас есть отдельный разбор. Для чувствительных данных берут локальную модель, для остального – облачную.
Выбор языковой модели. Привязка к одной модели навсегда – стратегический риск: например, может выйти более совершенная версия, которая будет работать лучше, чем три текущие модели вместе взятые, или поставщик может сменить условия хранения данных или ценовую политику. Одним словом, подходить к выбору модели нужно, внимательно изучив текущие бенчмарки – однако при этом помнить, что саму модель в рамках инструмента не так сложно заменить
Готовность контента. Этот пункт – ключевой для корректной работы ИИ-портала.
Например, если регламенты противоречат друг другу, ИИ может выдавать то один, то другой вариант, вводя в заблуждение и клиентов, и сотрудников. Поэтому проект почти всегда начинается с аудита и переработки материалов, а нередко и с миграции из имеющихся систем.
Вовлечение сотрудников. Система, которой не пользуются, не дает эффекта ни с ИИ, ни без него. Обучение и механизмы поддержания базы в актуальном состоянии – такая же важная часть проекта.
Единая база знаний – инфраструктурное решение, а не точечный эксперимент с искусственным интеллектом. Кто начинает с ИИ-помощника поверх разрозненных документов, может получить быстрый демонстрационный запуск, но и столь же быстрое разочарование впоследствии. Кто сначала наводит порядок в контенте и лишь затем добавляет ИИ-слой – получает систему, повышающую удовлетворенность как сотрудников, так и клиентов.
