--- title: "Проверяемые ответы AI по документам компании" metaTitle: "Проверяемые ответы AI по документам" description: "Как делать проверяемые ответы по документам компании: ссылки на источник, права доступа и явное сообщение, когда нужных данных нет." date: 2026-09-23 tags: [agentic-ai, knowledge-base] cover: cover.webp coverAlt: "Нарисованная девушка и коллега сверяют документ с экраном в офисном архиве" draft: false updated: 2026-09-23 --- Если сотрудник спрашивает AI-агента про регламент и получает уверенный ответ без единой ссылки на файл - это не помощник, а генератор правдоподобного текста. Проверяемый ответ устроен иначе: он называет конкретный документ, раздел и дату версии, отделяет прямую цитату от вывода и сообщает, когда источник не найден. Именно такую систему и стоит строить. ## Почему модель не знает, что у вас в папке Языковая модель обучена на большом корпусе текстов, но ваши внутренние регламенты в него не входили. Она не видит папку с документами в реальном времени и не обновляется автоматически, когда вы меняете политику. Один из подходов называется RAG - Retrieval-Augmented Generation, то есть генерация с поиском. Перед тем как модель составляет ответ, система ищет релевантные фрагменты в индексе документов и передаёт их модели вместе с вопросом. В рабочем сценарии модель ограничивают этими фрагментами и проверяют, что ответ действительно опирается на них. Важно понимать: RAG сам по себе не гарантирует корректных ссылок и понятного происхождения ответа. Для этого отдельно проектируют поиск, цитирование и проверку соответствия фрагменту. Если в документе ошибка, модель может её повторить. Поэтому ссылка делает ответ проверяемым, но не доказывает его правильность. ## Что нужно решить до запуска Прежде чем включить поиск по базе знаний, нужно разобраться с тремя вещами. Первое - актуальная версия. В папке может лежать несколько файлов с похожими названиями. Если система не знает, какой из них действующий, она может смешать старый регламент с новым, и сотрудник получит противоречивый ответ. Для каждого документа нужно зафиксировать: дата вступления в силу, статус (действующий / архивный / черновик), ответственный. Второе - владелец документа. Это не формальность. Когда агент не находит ответа или находит конфликтующие версии, он должен знать, к кому направить вопрос. Без ответственного человека цепочка обрывается. Третье - права доступа. Не каждый сотрудник должен видеть каждый документ. Это решается до индексации, а не после. ## Права доступа: индекс не должен обходить ограничения Здесь часто возникает скрытая проблема. Допустим, у менеджера по продажам нет доступа к документам HR. Но если агент строит общий индекс по всем файлам, а потом просто не показывает результаты - это ненадёжная защита. Резюме или фрагмент из закрытого документа может просочиться в ответ косвенно. Надёжная архитектура: агент ищет только в тех документах, к которым у конкретного пользователя есть доступ. Индекс либо сегментирован по ролям, либо фильтрация применяется на уровне поиска до передачи фрагментов модели. Проверить это несложно: войдите под учётной записью с ограниченными правами и спросите про закрытый документ напрямую. Агент не должен ни отвечать по нему, ни намекать на его содержание. Отдельный вопрос - изменения в операционных данных. Возможность записи или изменения требует отдельного уровня разрешений. Право читать документ и право инициировать действие по нему - разные вещи. Подробнее о том, как выстроить разграничение прав в базе знаний, мы разбирали в материале [о разрешениях корпоративного AI](/ru/blog/company-brain-permissions/). ## Учебный пример: два регламента обработки заявки Рассмотрим условную ситуацию. Сотрудник спрашивает: «Какой сейчас регламент обработки заявки от клиента?» В папке лежат два файла: - `request-policy-v1.pdf` - архивный, статус не проставлен - `request-policy-v2.pdf` - действующий, вступил в силу позже Если система не различает их статусы, она может найти оба документа как релевантные и либо смешать содержимое, либо ответить по старому. Проблема не в том, что старый файл «лучше проиндексирован» - дело в отсутствии явного статуса и даты вступления в силу в метаданных. Что должна делать система в таком случае: 1. При индексации проверить метаданные: статус, дата вступления в силу. 2. Архивный документ либо исключить из поиска, либо пометить так, чтобы агент не использовал его как основной источник. 3. В ответе явно указать: «Источник - `request-policy-v2.pdf`, раздел 3.2, действует с [дата из метаданных]». ## Как выглядит хороший ответ и как выглядит плохой Для примера предположим, что действующий учебный регламент содержит строку: «При нестандартной заявке сотрудник передаёт вопрос руководителю отдела». Тогда ответ мог бы выглядеть так: > Источник: «Регламент обработки заявки», версия 2, раздел 3.2. Цитата: «При нестандартной заявке сотрудник передаёт вопрос руководителю отдела». Вывод: эту заявку следует передать руководителю. Срок обработки в приведённом фрагменте не указан; его нужно проверить в полном документе. Здесь источник и версия названы, цитата отделена от вывода, а недостающий срок не выдуман. Это иллюстрация на вымышленном документе, а не выдержка из регламента Majento или клиента. Плохой ответ выглядит иначе: > Заявка обрабатывается в течение двух рабочих дней. Для этого нужно обратиться в отдел обслуживания. Ни файла, ни версии, ни раздела. Непонятно, это актуальный регламент или общее знание модели. Такой ответ нельзя ни проверить, ни оспорить. ## Когда источник не найден - это тоже ответ Один из важных сценариев: агент не находит релевантного документа. Слабая система в этом случае генерирует правдоподобный текст по общим знаниям. Хорошая - явно сообщает: «По вашему вопросу документов в базе не найдено. Рекомендую обратиться к ответственному за этот раздел или проверить, загружен ли нужный регламент». Это не провал системы. Сотрудник знает, что делать дальше, а не уходит с ответом, который никто не сможет верифицировать. О том, как выстроить процесс внедрения AI с учётом таких сценариев, читайте в разделе [об AI-внедрении](/ru/ai-implementation/). ## Критерий приёмки для вашей системы Перед тем как передать агента в работу, проверьте четыре вещи: - Каждый ответ, основанный на найденном документе, содержит название файла и точное место фрагмента, если структура источника позволяет его указать. - Цитата и вывод агента визуально или текстуально разделены. - Запрос от пользователя без доступа к документу не возвращает его содержимое ни прямо, ни косвенно. - На вопрос, по которому документов нет, агент сообщает об этом и называет следующий шаг. Если хотя бы один пункт не выполняется - система ещё не готова к боевому использованию. ## FAQ ### Можно ли полностью доверять ответу, если агент указал источник? Нет. Агент воспроизводит фрагмент из документа, но может выбрать не тот фрагмент, неточно его интерпретировать или пропустить важный контекст из соседнего раздела. Указание источника - это возможность проверить, а не гарантия правильности. Критичные ответы проверяйте вручную. ### Как часто нужно обновлять индекс? Зависит от того, как часто меняются документы. Обновление индекса следует привязать к изменению и публикации документа, а не полагаться только на редкий запуск по расписанию. Иначе система может ответить по устаревшей версии, даже если дата в ответе выглядит убедительно. ### Что делать с документами в разработке или на согласовании? Черновики и документы на согласовании лучше исключить из индекса или хранить в отдельном пространстве с явно ограниченным доступом. Агент не должен отвечать по черновику как по действующему регламенту. ### Нужен ли отдельный агент для каждого отдела? Не обязательно. Достаточно правильно сегментировать права доступа: один агент может обслуживать всю компанию, но каждый пользователь видит только то, что ему разрешено. Отдельные агенты имеют смысл, если у отделов принципиально разные сценарии работы с документами. Если хотите разобрать конкретную схему под вашу базу знаний - пишите в Telegram [@shimaoz](https://t.me/shimaoz) или на [hello@majento.ai](mailto:hello@majento.ai). ## Источник Консультации и обучающие курсы Majento.