ИИ-ассистент по базе знаний компании: RAG-поиск по документам

Как устроить ИИ-ассистента по базе знаний?

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

1. Выбрать подразделение, процесс и владельца базы знаний.
2. Составить реестр источников и удалить устаревшие дубли.
3. Зафиксировать права доступа на уровне документов и разделов.
4. Настроить извлечение, разбиение, индекс и поиск.
5. Требовать ссылки на использованные фрагменты.
6. Собрать вопросы с эталонными ответами и отказами.
7. Провести пилот на ограниченной группе сотрудников.
8. Обновлять индекс вместе с изменением документов.

Какие задачи решает ассистент по знаниям?

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

Если системе нужно не только отвечать, но и выбирать действия в CRM, почте или учётной системе, это уже более широкий сценарий внедрения ИИ-агента.

Как работает RAG-поиск по документам?

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

Индексация

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

Поиск и переранжирование

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

Формирование ответа

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

Из каких источников собирать базу знаний?

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

• корпоративная wiki и база инструкций;
• утверждённые PDF, DOCX и презентации;
• карточки продуктов и служебные справочники;
• проверенные ответы поддержки и разборы инцидентов;
• учебные материалы и программы онбординга;
• CRM и другие системы, если поля имеют владельца и права доступа.

Подключение wiki, CRM и хранилищ лучше выполнять через контролируемую интеграцию по API или штатный коннектор.

Как подготовить документы к индексации?

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

1. Составить реестр файлов и систем-источников.
2. Отметить действующие, архивные и черновые версии.
3. Назначить владельца и срок следующего пересмотра.
4. Удалить дубли или задать явный приоритет.
5. Проверить извлечение заголовков, списков и таблиц.
6. Добавить метаданные продукта, отдела и уровня доступа.
7. Разбить длинные материалы по смысловым границам.
8. Проверить найденные фрагменты на реальных вопросах.

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

Как сохранить права доступа сотрудников?

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

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

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

Как проверить качество RAG-ассистента?

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

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

Когда ассистент должен отказаться от ответа?

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

Какую архитектуру выбрать для пилота?

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

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

Как провести пилот ИИ-ассистента?

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

1. 01

   Сценарий

   Выберите отдел, тип вопросов и владельца результата.

2. 02

   Источники

   Подключите ограниченный набор проверенных документов.

3. 03

   Эталоны

   Соберите вопросы, ответы, источники и ожидаемые отказы.

4. 04

   Закрытая группа

   Дайте доступ сотрудникам с разными ролями и задачами.

5. 05

   Разбор ошибок

   Отделите проблемы документов, поиска, ответа и интерфейса.

6. 06

   Решение

   Расширяйте контур только после повторной проверки.

Сценарии для других подразделений можно выбрать по обзору применения ИИ в бизнесе.

Какие ошибки чаще всего ломают базу знаний?

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

Частые вопросы