Поиск по базе знаний с ИИ: какие материалы подготовить

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

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

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

Какие документы взять в первую версию?

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

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

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

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

Как привести документы в порядок?

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

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

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

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

Как разбить материалы на фрагменты?

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

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

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

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

Какие метаданные и доступы сохранить?

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

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

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

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

Как проверить базу до подключения помощника?

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

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

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

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

Источники

• Develop a RAG Solution on Azure — Preparation Phase — Microsoft
• Develop a RAG Solution on Azure — Chunking Phase — Microsoft
• RAG Prompt Engineering — Microsoft
• Document-Level Access Control — Microsoft