Как устроена работа с ответами по базе знаний
База знаний — это набор материалов, на которые компания опирается при ответах сотрудникам, клиентам или партнёрам. В неё могут входить регламенты, инструкции, описания услуг, договорные условия, внутренние памятки, ответы на частые вопросы и архив разобранных ситуаций.
Само наличие такой базы ещё не означает, что нужный ответ легко получить. Сотруднику приходится понять вопрос, подобрать подходящие документы, проверить их актуальность, собрать вывод и изложить его понятным языком. Если информации не хватает или источники противоречат друг другу, начинается переписка с коллегами.
Здесь и появляется ручная нагрузка. Один и тот же вопрос может звучать по-разному, а готовый ответ редко лежит в одном документе. Например, менеджеру нужно одновременно учесть условия тарифа, порядок подключения и исключение для конкретной категории клиентов. Поиск по названию файла в такой ситуации помогает слабо.
ИИ-агент для базы знаний — это система, которая получает запрос, находит связанные с ним материалы, формирует ответ по заданным правилам и выполняет предусмотренное следующее действие. Таким действием может быть запрос недостающих сведений, создание черновика письма, добавление ссылки на источник или передача сложного случая ответственному сотруднику.
В этом и состоит практический смысл подхода: человек формулирует вопрос обычными словами, а система помогает пройти путь от запроса до обоснованного ответа. Более общее объяснение принципа есть в статье Что такое ИИ-агент для бизнеса.
Важно, что база знаний остаётся источником, а агент становится рабочим слоем над ней. Он не превращает разрозненные документы в достоверную систему сам по себе. Если в материалах устаревшие условия, несколько версий одного регламента или отсутствуют важные исключения, это неизбежно отразится на ответах.
Чем ИИ-агент отличается от привычных способов работы
Самый простой подход — ручной поиск. Сотрудник открывает папки, корпоративный портал или таблицу со ссылками, читает материалы и готовит ответ. Такой способ гибок: опытный специалист замечает контекст и нестандартные детали. Но скорость и качество сильно зависят от знания базы, а похожая работа повторяется много раз.
Следующий вариант — поиск по ключевым словам. Он быстро находит документы, в которых встречается нужная фраза, но не всегда понимает смысл запроса. Клиент может спросить о возврате оплаты, а внутренний документ называться «Порядок расторжения и взаиморасчётов». Формального совпадения мало, хотя по смыслу это нужный источник.
Чат-бот обычно работает по заранее описанным сценариям: показывает меню, распознаёт типовой вопрос или выдаёт подготовленный ответ. Это удобно для стабильных и предсказуемых обращений. Когда запрос требует собрать сведения из нескольких материалов, учесть параметры ситуации и выбрать дальнейший маршрут, жёсткого сценария может не хватить.
Обычная автоматизация хорошо выполняет однозначные команды: получила статус заказа, подставила его в шаблон, отправила сообщение. Ей нужны заранее известные условия и ожидаемый формат данных. Она не предназначена для свободного анализа текста.
ИИ-агент объединяет смысловой поиск и последовательность действий. Он может определить тему обращения, подобрать фрагменты документов, собрать черновик и проверить, хватает ли информации. Если ответ зависит от номера договора или категории клиента, агент сначала запросит этот параметр. Если правила требуют согласования, направит подготовленный материал нужному специалисту.
Поэтому создание ИИ-агента имеет смысл рассматривать не как установку «умного чата», а как настройку конкретного рабочего маршрута. Чем понятнее начало, допустимые действия и результат этого маршрута, тем проще оценить его пользу.
Какие задачи можно передать агенту, а какие оставить человеку
Лучше всего агенту подходят повторяющиеся запросы, ответы на которые уже содержатся в утверждённых материалах. Он может классифицировать обращение, искать нужные положения, составлять краткую выжимку, приводить текст к принятому стилю и прикладывать ссылки на использованные источники.
Полезен он и как помощник сотрудника. Вместо готового сообщения клиенту система делает черновик: показывает предлагаемый ответ, найденные основания и возможные пробелы. Специалист проверяет текст и отправляет его после редактирования. Такой режим особенно уместен в начале, когда ещё важно увидеть реальные ошибки и неоднозначные случаи.
Можно поручить агенту уточняющие действия. Если в запросе не указаны продукт, регион, тип договора или другой обязательный параметр, он не пытается угадать, а просит дополнить информацию. Ещё одна подходящая задача — маршрутизация: определить тему и передать обращение тому, кто отвечает за неё.
Плохо подходят ситуации, в которых источника нет, решение зависит от переговоров или ошибка создаёт серьёзные правовые, финансовые либо репутационные последствия. Агент не должен самостоятельно обещать компенсацию, менять условия договора, трактовать спорную норму или принимать исключение из правил, если компания явно не разрешила такое действие.
Решение за человеком также стоит сохранять, когда документы расходятся, запрос касается конфликта, сумма или последствия превышают установленный порог, а уверенность системы недостаточна. Сам порог задаёт компания: не абстрактно «опасный случай», а конкретные признаки, после которых ответ отправляется на проверку.
Контроль полезно встраивать прямо в процесс. Агент показывает источники, отмечает недостающие сведения и не скрывает, что не нашёл надёжного основания. Так сотрудник проверяет не только красивую формулировку, но и то, откуда взялся вывод. Риск обычно возникает не из-за самого текста, а из-за ответа без достаточного основания или действия за пределами полномочий.
Какие данные, правила и интеграции нужны системе
Основа системы — подготовленные источники. У каждого документа желательно определить владельца, дату обновления, область применения и статус: черновик это или утверждённая версия. Дубликаты и устаревшие материалы лучше убрать из рабочего контура, иначе агент будет находить взаимоисключающие указания.
Далее нужен смысловой поиск. Он подбирает не только буквальные совпадения, но и фрагменты, близкие к вопросу по содержанию. Найденные фрагменты передаются языковой модели — компоненту, который собирает из них связный ответ. Обычно в ответе сохраняют ссылки или названия документов, чтобы происхождение информации можно было проверить.
Отдельный слой — правила. В них фиксируют, на какие темы агент отвечает, какие сведения обязан запросить, когда использует шаблон, а когда передаёт обращение человеку. Там же задают требования к форме: например, не добавлять неподтверждённые предположения, не раскрывать внутренние материалы и прямо сообщать, если ответа в базе нет.
Интеграции связывают этот механизм с рабочими каналами. Источником запроса может быть корпоративный чат, служба поддержки, CRM или внутренний портал. Обратно система может вернуть черновик, создать задачу, заполнить карточку обращения либо отправить запрос на согласование. Нужны только те подключения, которые поддерживают выбранный процесс: собирать сразу все системы компании нет практического смысла.
Для контроля пригодится журнал работы. В нём сохраняются запрос, найденные источники, подготовленный ответ, дальнейшее действие и правка сотрудника. Такой журнал помогает разбирать ошибки и улучшать правила без догадок. При работе с персональными или закрытыми данными дополнительно определяют права доступа: кто может задавать вопросы, какие документы ему доступны и что разрешено записывать в историю.
Как проверить идею на небольшом пилоте
Для пилота лучше выбрать один поток вопросов с понятными границами. Подойдут обращения по конкретной услуге, внутренние вопросы о стандартной процедуре или помощь операторам по одной категории запросов. Если смешать продажи, поддержку, договорную работу и внутренние регламенты, причины ошибок будет трудно отделить друг от друга.
Хороший кандидат встречается регулярно, занимает заметное время и имеет проверяемый правильный ответ. При этом материалы уже существуют, а ответственный специалист способен оценить качество. Дополнительные ориентиры я разбираю в статье Как выбрать процесс для первого AI-пилота.
До запуска стоит собрать набор реальных обезличенных вопросов. В нём нужны не только простые примеры, но и неполные формулировки, близкие по смыслу темы, редкие исключения и случаи без ответа в базе. Затем для каждого примера фиксируют ожидаемое поведение: ответить, уточнить данные или передать человеку.
Результат полезно оценивать по нескольким признакам: верно ли определена тема, найдены ли подходящие источники, подтверждается ли ими вывод, не добавлены ли вымышленные детали и правильно ли выбран следующий шаг. Отдельно смотрят, сколько черновиков специалист принял без изменений, сколько исправил и сколько отклонил. Это не универсальные нормативы, а наблюдения внутри конкретного пилота.
Скорость ответа сама по себе мало что доказывает. Быстрый, но неподтверждённый текст лишь ускоряет появление ошибки. Гораздо важнее увидеть, сокращается ли повторяющийся поиск, остаётся ли результат проверяемым и корректно ли система останавливается на неоднозначных случаях.
Первый практический шаг простой: взять двадцать–тридцать недавних вопросов из одного процесса, убрать персональные данные и попросить ответственного сотрудника разметить для каждого правильный источник и ожидаемое действие. Если значительная часть примеров опирается на доступные документы и проверяется по ясным правилам, идею можно переводить в ограниченный пилот.