RAG для корпоративных документов: договоры, wiki, тикеты и права

Раздел

RAG и базы знаний

Сложность

сложная

Обновлено

2026-06-02

Короткий ответ

RAG для корпоративных документов стоит запускать не как “загрузим все файлы в векторную базу”, а как управляемый контур знаний: какие договоры, wiki-страницы и тикеты можно читать, кто за них отвечает, какие права действуют до retrieval, как показываются citations и как удаляются устаревшие документы. Иначе система быстро начнет уверенно отвечать по архивам, черновикам и закрытым материалам.

Безопасный первый релиз: один домен документов, 50-200 утвержденных источников, владелец корпуса, access groups, freshness SLA, eval-набор и запрет ответа без источника. AWS описывает RAG как способ добавлять внешний контекст к запросу модели: Understanding Retrieval Augmented Generation. Microsoft отдельно подчеркивает задачи security governance, citations и multi-source access в RAG-контуре Azure AI Search: Retrieval-augmented generation in Azure AI Search.

Эта статья не заменяет страницы про RAG базу знаний и RAG для Confluence, Notion и SharePoint. Она закрывает отдельный reader job: как начать именно с корпоративных документов разных типов, не открывая агенту весь файловый контур компании.

Что входит в корпоративный корпус

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

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

Inventory до индексации

Начните с inventory. Для каждого source нужна карточка, а не просто путь к папке.

document_source:
  name: support_contract_faq
  system: confluence
  domain: support_and_contracts
  owner: support_ops
  access_groups:
    - support_l2
    - legal_reviewers
  document_status: approved_only
  freshness_sla_hours: 48
  exclude:
    - drafts
    - archived_pages
    - personal_customer_data
    - price_promises

Минимальные поля: source system, URL, owner, updated_at, access group, статус документа, тип документа, язык, версия продукта и дата review. Без этих полей RAG не сможет отфильтровать права, показать citation, найти устаревший источник и объяснить ошибку владельцу.

Права до retrieval

Права нужно применять до поиска и до передачи текста модели. Нельзя сначала найти закрытый документ, передать его в LLM и надеяться, что prompt не раскроет лишнее.

user identity
  -> allowed source groups
  -> retrieval только по разрешенным chunks
  -> answer with citations
  -> audit event

Microsoft Graph Search API описывает поиск в контексте пользователя и результатов, ограниченных доступом: Microsoft Graph Search API overview. Для Confluence в пилоте проверьте не только search endpoint, но и space permissions, page restrictions и то, какие страницы реально доступны пользователю: Confluence Cloud REST API search.

Опасные проверки до запуска:

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

Если источник нельзя показать пользователю, его нельзя использовать в ответе этому пользователю.

Договоры и юридические документы

Для договоров RAG должен быть ассистентом по поиску и объяснению playbook, а не заменой юриста. Хороший сценарий: найти утвержденный clause, показать риск, сослаться на внутренний комментарий и передать спорный пункт на review. Плохой сценарий: автоматически принять правку контрагента или обещать юридическую позицию.

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

Wiki и тикеты

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

Практический путь:

1. Собрать частые темы из тикетов.
2. Написать или обновить wiki-статьи под эти темы.
3. Назначить владельцев и review cycle.
4. Индексировать approved статьи, а не весь поток тикетов.
5. Использовать тикеты в eval-наборе как реальные вопросы.

Так RAG отвечает по утвержденной базе знаний, а не по случайной переписке.

Freshness и удаление

Устаревший документ после запуска RAG становится активным источником ошибки. Поэтому freshness SLA и delete behavior нужны до первого production-деплоя.

Не обещайте “всегда актуальные ответы”, если в компании нет процесса обновления документов. Корректная формулировка: “ответы основаны на утвержденных источниках с таким-то сроком свежести”.

Eval-набор и приемка

Проверяйте retrieval отдельно от генерации. Если правильный источник не попал в top results, prompt не исправит архитектуру.

{
  "question": "можно ли закрыть заявку без подтверждения клиента",
  "user_group": "support_l1",
  "expected_source": "confluence://support/runbooks/close-ticket",
  "must_not_use": ["tickets://raw/customer-angry-thread"],
  "expected_behavior": "answer_with_citation_or_escalate",
  "critical_errors": ["no_citation", "uses_forbidden_source", "auto_closure_allowed"]
}

Для первого пилота достаточно 80-120 вопросов: типовые, пограничные, с опечатками, по закрытым документам, по устаревшим процессам и по отсутствующим ответам. Смотрите source hit rate, refusal quality, access correctness, freshness correctness и долю ответов, которые reviewer переписал.

Чеклист

• Выбран один домен документов, а не весь файловый контур.
• У каждого source есть owner, updated_at, статус и access group.
• Права применяются до retrieval.
• Сервисный токен не открывает пользователю лишние документы.
• Договоры и юридические документы работают только как search/review assist.
• Тикеты очищены или используются как eval-вопросы, а не как сырой источник.
• Ответ без citation запрещен.
• Устаревший source удаляется из индекса или вызывает отказ.
• Есть eval-набор с разрешенными и запрещенными источниками.
• Есть rollback: отключить source, вернуть индекс или остановить ответы.

FAQ

Можно ли просто загрузить все документы в vector database?

Технически можно, но для бизнеса это плохой старт. Без owner, прав, статуса и freshness вы получите быстрые ответы по старым или закрытым документам.

Что важнее на старте: модель или права?

Права и source inventory. Модель не должна видеть документ, который пользователь не имеет права открыть.

Нужно ли индексировать тикеты поддержки?

Сырые тикеты лучше использовать как источник вопросов для eval и как сигнал, какие approved статьи написать. В индекс должны идти очищенные runbooks и статьи базы знаний.

Как понять, что пилот готов к расширению?

Когда ответы с citation проходят review, запрещенные источники не используются, stale documents не отвечают, а владельцы документов реально исправляют ошибки.

Что читать дальше?

Начните с RAG базы знаний, затем проверьте поиск по документам с ИИ, RAG для Confluence, Notion и SharePoint и оценку качества RAG.