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