Зачем обогащать базу знаний данными из внешних систем и как это сделать эффективно

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

Еще один плюс — возможность собрать в едином контуре данные, которые обычно существуют отдельно друг от друга. Регламенты, документы, новости, обращения клиентов, аналитика и внутренние инструкции могут дополнять друг друга. Так сотрудникам проще увидеть общую картину и быстрее найти нужный ответ — через обычный поиск или с помощью ИИ.

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

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

Во многих компаниях важные документы создаются и дорабатываются в системах электронного документооборота: регламенты, инструкции, политики, стандарты, шаблоны, положения и процедуры.

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

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

Еще один сценарий — работа с внешней аудиторией: клиентами, партнерами и подрядчиками. Давать им доступ к внутренней системе электронного документооборота небезопасно и неудобно. Вместо этого компания может публиковать утвержденные материалы на внешнем портале, в мобильном приложении или чат-боте, которые получают информацию из базы знаний.

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

Не мешает продумать и менее очевидные сценарии - когда происходит появление новой редакции существующего документа (например, того же регламента), то важно в базе знаний формировать именно новую версию документа, а не создавать отдельную сущность. А если документы “утрачивают силу”, то и этот факт должен находить отражение в базе знаний.

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

К таким источникам относятся:

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

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

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

Такие сигналы возникают, когда:

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

В такой модели база знаний занимает роль инструмента для развития контента. Она позволяет фиксировать вопросы, на которые пока нет ответа, видеть повторяющиеся проблемы и своевременно дополнять информационную базу, к которой подключены разные системы: сервис-деск, боты, мобильные приложения и так далее.

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

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

Важно определиться:

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

Отдельно нужно продумать, как связать объекты в разных системах. Интеграция должна «понимать», какой документ из системы-источника соответствует конкретной статье, карточке или другому материалу в базе знаний. Чтобы при следующем обновлении система видела связь и обновляла существующий материал, а не создавала дубликат.

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

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

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

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

Еще один сценарий — загрузка файлов и документов в базу знаний. Материалы могут поступать через API в виде PDF-файлов или передаваться из OCR-систем, которые сканируют и распознают бумажные документы.

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

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

После этого информация передается в базу знаний по интеграционному сценарию. В системе создается карточка с заранее согласованными полями, к которой прикладывается распознанный документ — например, в формате PDF/A. Формируется упорядоченная структура, которая прекрасно дополняет содержимое базы знаний, делая его наиболее полным и доступным как сотрудникам, так и ИИ.

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

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

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

Кроме того, речевая аналитика помогает развивать сотрудников. В таких системах есть функционал оценки профиля компетенций оператора, который помогает выявлять сильные стороны и области, которые требуют дополнительного обучения. Например, если сотрудник регулярно испытывает сложности с обработкой возражений или объяснением условий продукта, ему можно рекомендовать конкретные обучающие материалы из базы знаний.

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

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

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

Еще один сценарий — сбор обратной связи по ответам чат-бота или FAQ-страниц на сайте и в мобильном приложении. Если оценка полезности ответа падает ниже установленного уровня или пользователи часто переходят к оператору после просмотра материала, система может передать в базу знаний сигнал о необходимости пересмотреть контент. Редактор или владелец процесса проверяет материал, уточняет формулировки, добавляет недостающую информацию или обновляет сценарий ответа.

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

Необходимо выстроить правила поступления и обработки информации:

Благодаря такому подходу, данные из сторонних систем не будут просто занимать место в базе знаний, а станут действительно ценным информационным ресурсом, который поможет сотрудникам и клиентам быстрее находить ответы, а компании — видеть пробелы в контенте и системно развивать его.