Автоматизация поиска по корпоративным знаниям

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

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

Нужного ответа сразу нет.

Сотрудник идёт в почту и ищет переписку по словам «возврат», «исключение», «согласование». Затем просматривает рабочие чаты, спрашивает коллег и получает несколько разных ответов.

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

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

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

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

Типовой процесс выглядит так:

В результате знания компании остаются разрозненными, а опытные сотрудники постоянно отвлекаются на повторяющиеся вопросы.

Сначала система подключается к разрешённым источникам корпоративных знаний: папкам с документами, PDF, Word, Excel, внутренним базам, глоссариям и другим хранилищам.

Python-script получает документы, извлекает текст и сохраняет дополнительную информацию: название файла, раздел, дату, источник, версию и другие метаданные.

Большие документы разбиваются на небольшие смысловые фрагменты. Для каждого фрагмента embedding-model создаёт числовое представление смысла текста, после чего данные сохраняются в PostgreSQL + pgvector.

В результате система умеет искать не только по точному совпадению слов.

Например, сотрудник спрашивает:

Как оформить возврат корпоративному клиенту, если счёт уже оплачен?

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

vector-search находит фрагменты, близкие по смыслу к вопросу пользователя.

Найденный контекст передаётся в text-LLM-model, который формирует понятный ответ только на основе найденных корпоративных материалов.

Вместе с ответом система может показать источники:

• Регламент возвратов.pdf — раздел 4.2
• Финансовые правила.docx — раздел 7
• Глоссарий CRM — термин: Refund

Это принципиально отличает корпоративную базу знаний от обычного чат-бота. Модель не должна просто «что-то знать». Она получает конкретные внутренние документы компании и формирует ответ на их основе.

Поиск, который раньше занимал минуты или даже часы, может занимать несколько секунд.

Допустим, в компании работают отдел продаж, служба поддержки и бухгалтерия.

Сотрудники регулярно задают вопросы:

• Какие документы нужны для нового клиента?
• Какой срок оплаты предусмотрен для этого типа договора?
• Что делать, если клиент просрочил оплату?
• Можно ли изменить заказ после выставления счёта?
• Как оформить возврат?
• Как правильно создать такую сделку в CRM?
• Какая версия инструкции сейчас актуальна?

Сегодня ответы могут находиться в десятках разных файлов.

После внедрения корпоративной базы знаний сотрудник просто пишет:

Что делать, если клиент хочет изменить заказ после оплаты?

Система за несколько секунд находит подходящие правила и отвечает:

1. Проверьте статус заказа в CRM.
2. Если отгрузка ещё не началась, создайте запрос на изменение.
3. Изменение стоимости требует повторного согласования.
4. После согласования обновите заказ в ERP.

Источники:

• Регламент обработки заказов, раздел 8.3
• Инструкция CRM, раздел 5.1

Человеку не нужно знать, где физически находятся эти документы.

Корпоративная база знаний не должна быть статичной.

Например:

То же самое может происходить по расписанию:

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

Для корпоративной базы знаний особенно важно не потерять связь между ответом и исходным документом.

Для каждого фрагмента можно хранить:

• Источник
• Название документа
• Раздел
• Дата
• Версия
• Дата последнего обновления
• Владелец документа
• Уровень доступа

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

Она может сообщить:

Это значительно безопаснее, чем уверенно генерировать ответ при недостаточных данных.

В реальной корпоративной системе не все знания должны быть доступны всем сотрудникам.

Поэтому pipeline может учитывать права пользователя:

Например:

• Sales → инструкции отдела продаж
• Finance → финансовые документы
• HR → кадровые правила
• Management → управленческая документация

Один и тот же поисковый интерфейс может работать с разными наборами информации в зависимости от прав доступа.

• корпоративные инструкции;
• регламенты и процедуры;
• техническая документация;
• продуктовая база знаний;
• обучение новых сотрудников;
• внутренний Help Desk;
• база ответов службы поддержки;
• юридические и договорные документы;
• инструкции CRM и ERP;
• документация IT-службы;
• внутренние стандарты;
• базы терминов и глоссарии;
• проектная документация;
• накопленные решения типовых проблем.

После создания базы знаний тот же pipeline можно развивать дальше.

Например:

Или:

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

То есть корпоративная база знаний может стать универсальным интерфейсом между сотрудником и внутренними системами компании.