ИИ по документам компании обычно строят через RAG: система ищет подходящие фрагменты в базе знаний и передаёт их модели вместе с вопросом. Качество ответа зависит от актуальности документов, точности поиска и доступов пользователя. Ссылка на источник помогает проверить ответ, но сама по себе не подтверждает его правильность.
Прежде чем загружать файлы, выберите область работы. Например, инструкции поддержки по одному продукту. В такой базе проще определить владельца правил и понять, почему ассистент ответил неверно. Корпоративный архив из нескольких тысяч файлов потребует отдельной работы по порядку в источниках.
Как вопрос превращается в ответ
В типовом RAG-процессе документы делят на фрагменты, добавляют сведения об источнике и помещают в поисковый индекс. Когда приходит вопрос, система выбирает подходящие фрагменты и передаёт их модели. Такую схему описывает Microsoft в руководстве по проектированию RAG. Microsoft: архитектура RAG.
Из этой схемы следует практическая задача проверки: выяснить, на каком этапе потерялся смысл. Нужный документ мог отсутствовать в базе. Поиск мог выбрать соседнюю инструкцию. Модель могла неверно истолковать правильно найденный пункт. Каждую причину исправляют отдельно.
Начните с паспорта источников
Ниже условная таблица для компании, которая обслуживает оборудование. Названия, сроки и роли приведены для примера.
| Источник | Владелец содержания | Приоритет | Проверка актуальности | Доступ |
|---|---|---|---|---|
| Регламент обслуживания | Руководитель сервиса | Основное правило | После изменения условий | Сервис и поддержка |
| Каталог оборудования | Продуктовый менеджер | Характеристики | При обновлении модели | Все сотрудники |
| Индивидуальные условия клиента | Менеджер договора | Для указанного клиента | После согласованного изменения | Назначенная группа |
| Старые ответы поддержки | Редактор базы | Материал для разбора | До включения каждого ответа | Редакторы |
У каждой записи также нужны идентификатор, версия, дата начала действия, статус и ссылка на оригинал. «Дата загрузки» отражает событие в системе. Для выбора действующего правила нужна дата, относящаяся к содержанию.
Владелец содержания отвечает за смысл документа. Технический администратор отвечает за загрузку и доступность. Если эти роли смешать, разработчик будет вынужден решать, какая инструкция верна, хотя такого полномочия у него может не быть.
Разберите противоречия до индексации
Условный пример: в инструкции поддержки указано, что консультация проводится по записи, а в старой памятке написано «обращайтесь в любое время». Модель может соединить обе формулировки. Поэтому для таких пар заранее задают правило: действующий регламент имеет приоритет; архивный документ исключается из рабочего поиска.
Иногда противоречие реальное: два действующих подразделения дают разные ответы. Тогда владельцы процесса сначала согласуют правило. Для ассистента полезен отдельный сценарий: показать конфликт и передать вопрос ответственному. Самостоятельный выбор удобной версии создаёт ещё один источник ошибок.
OWASP описывает для RAG риски смешения контекстов, конфликтующих источников и доступа к чужим сведениям. Это аргумент в пользу классификации документов и проверки входных данных. OWASP: Vector and Embedding Weaknesses.
Сохраните смысл при делении документа
Размер фрагмента выбирают по структуре материала. Список условий обслуживания может потерять смысл, если исключения окажутся в другом фрагменте. В таблице характеристик заголовки колонок должны оставаться связаны со значениями. Для отсканированных файлов отдельно проверяют распознавание номеров, единиц измерения и сносок.
Возьмите несколько сложных документов и сравните исходник с результатом извлечения. Проверьте отрицания, даты, названия продуктов, продолжение таблиц и текст на изображениях. Ошибка извлечения затем выглядит как ошибка модели, хотя возникла раньше.
На этапе пилота достаточно журналировать, какие фрагменты нашёл поиск и какая версия документа использована. Это позволит воспроизвести спорный ответ без угадывания.
Проверяйте права перед выдачей фрагментов
Внутренняя база может содержать документы с разным кругом читателей. Рекомендуем применять ограничения до передачи содержания модели и сохранять их для ссылок, истории диалога и кеша ответов. Если в документах есть персональные данные, до передачи во внешний ИИ-сервис отдельно проверьте основание обработки, условия поручения, место обработки и необходимость правил трансграничной передачи.
Microsoft документирует фильтрацию поиска по пользователю или группе как один из подходов к доступу на уровне документов. Конкретные встроенные возможности платформы имеют свои ограничения и статус доступности. Microsoft: доступ к документам в Azure AI Search.
При выборе другой системы задайте разработчику тот же проверочный вопрос: «Какие фрагменты получит пользователь, если у него отсутствует доступ к исходному файлу?» Текстовая просьба модели соблюдать секретность не заменяет проверку разрешений в приложении.
Как принять пилотную базу
Подготовьте вопросы четырёх типов: с прямым ответом, с несколькими условиями, без ответа в документах и с ограниченным доступом. Для каждого вопроса запишите ожидаемый смысл, допустимые источники и поведение при нехватке сведений.
Для условного вопроса «Можно ли вызвать мастера на объект?» эталон может содержать город, тип оборудования и необходимость записи. Проверка ищет все эти условия. Короткое «да» без ограничений будет неполным результатом.
Попросите специалиста проверить отдельно найденные материалы и итоговую формулировку. После обновления регламента повторите вопросы, которые затрагивают изменённый пункт. Старый фрагмент должен исчезнуть из рабочего поиска, а ответ должен опираться на новую версию.
Что поддерживать после запуска
У базы должен быть процесс обновления: кто сообщает об изменении, кто подтверждает документ, когда обновляется индекс и кто проверяет контрольные вопросы. Задайте срок реакции на ошибочный ответ и возможность временно отключить спорный источник.
После проекта у команды должны остаться реестр документов, журнал изменений и набор контрольных вопросов. Тогда база знаний остаётся управляемой, даже когда компания выпускает новые продукты или меняет условия обслуживания.
Источники
- Microsoft RAG Design Guide: устройство поиска и подготовки контекста.
- Microsoft Document-level Access: подходы к проверке доступа при поиске.
- OWASP LLM08: риски доступа, конфликтов и качества источников. Паспорт базы и порядок приёмки предложены редакцией.