RAG для Confluence, Notion и SharePoint: права, свежесть и citations

Раздел

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

Сложность

средняя

Обновлено

2026-05-20

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

RAG для Confluence, Notion и SharePoint нужно строить как поисковый контур с правами, свежестью и ссылками на источники, а не как выгрузку всех страниц в один индекс. Безопасный первый шаг: выбрать один workspace или space, синхронизировать только разрешенные страницы, сохранить owner и updated_at, показывать citations и регулярно удалять устаревшие материалы.

У каждой системы есть свои ограничения. Confluence Cloud дает search endpoint через REST API: Confluence Cloud REST API search. Notion прямо описывает особенности search endpoint и ситуации, когда недавно расшаренная страница может не сразу появиться в результатах: Notion API search optimizations and limitations. Microsoft Search API указывает, что search requests выполняются в контексте signed-in user и results scoped to access control: Microsoft Search API.

Эта статья продолжает материалы про RAG систему, поиск по документам с ИИ, MCP для корпоративного поиска и оценку качества RAG.

Не индексируйте все сразу

Большая wiki почти всегда содержит дубли, черновики, старые инструкции, личные заметки, страницы без владельца и документы с разными правами. Если отправить все это в RAG, модель будет отвечать быстро, но плохо: смешивать версии, цитировать архив и показывать не тот процесс.

Для пилота выберите узкий корпус.

Если владелец страницы неизвестен, добавьте ее в cleanup-очередь, а не в боевой индекс. RAG усиливает существующую дисциплину базы знаний. Он не чинит хаос в документах.

Права до retrieval

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

user identity
  -> source connector
  -> allowed pages/files only
  -> retrieval
  -> answer with citations
  -> audit event

Для SharePoint полезно начинать с Microsoft Search API, потому что он описывает scoping результатов по access control для пользователя. Для site discovery есть отдельный метод search for SharePoint sites, но он не заменяет проверку прав на файлы и элементы.

В Confluence проверьте space permissions и page restrictions. В Notion проверьте, какие страницы напрямую расшарены с integration и как устроена иерархия. Не делайте service token с доступом ко всему workspace, если пользователь должен видеть только часть базы.

Свежесть и синхронизация

RAG по базе знаний ломается не в день запуска, а через месяц, когда статьи обновились, часть страниц удалили, а индекс продолжает цитировать старый текст. Нужен явный sync-контракт: как часто читать изменения, что считать удалением, кто отвечает за stale pages.

knowledge_sync_policy:
  sources:
    - system: confluence
      scope: "SUPPORT space"
      mode: incremental
      max_staleness_hours: 24
    - system: notion
      scope: "Customer Success teamspace"
      mode: scheduled_rescan
      max_staleness_hours: 48
  required_metadata:
    - source_system
    - source_url
    - owner
    - updated_at
    - access_group
    - document_status
  delete_behavior: "remove_from_index_after_source_delete"

Для Notion учитывайте, что API search имеет documented limitations. Не стройте гарантию полноты только на одном search call сразу после OAuth или sharing. Для чувствительных контуров добавьте периодический reconciliation: список ожидаемых страниц против того, что реально попало в индекс.

Citations как контракт ответа

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

Минимальная citation:

Операционное правило: если RAG не может показать citation к конкретной странице или файлу, он должен отказаться или попросить уточнение. “Похоже, по регламенту…” - плохой ответ для операционной базы знаний.

Stale-page cleanup

До внедрения RAG stale pages часто терпимы: сотрудник сам заметит дату или спросит коллегу. После внедрения устаревшая страница становится активным источником ответа. Поэтому cleanup нужен как часть пилота.

Признаки страницы на удаление или архив:

• нет owner;
• нет обновления дольше review cycle;
• дублирует новую страницу;
• содержит “временно”, “старый процесс”, “не использовать”;
• противоречит более свежей политике;
• не открывается пользователю, который должен отвечать клиенту;
• не имеет статуса approved.

Для каждой stale page создайте решение: обновить, объединить, архивировать или исключить из индекса. Не оставляйте “потом разберемся”: индекс будет продолжать использовать мусор.

Eval-набор

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

{
  "question": "как вернуть деньги клиенту после двойного списания",
  "expected_source": "confluence://support/refunds/double-charge",
  "allowed_groups": ["support_l2", "finance_ops"],
  "must_not_use": ["notion://drafts/refund-old-policy"],
  "expected_behavior": "answer_with_citation_or_escalate"
}

Соберите 80-120 вопросов: реальные формулировки сотрудников, вопросы с опечатками, вопросы к закрытым документам, вопросы по старым процессам и вопросы без ответа. Считайте source hit rate, refusal quality, freshness correctness и access correctness.

Чеклист

• Выбран узкий corpus, а не весь workspace.
• У каждой страницы есть owner, updated_at и статус.
• Права проверяются до retrieval.
• Service token не имеет лишнего доступа.
• Удаления и архивы удаляются из индекса.
• Ответ без citation запрещен.
• Stale-page cleanup включен в процесс владельцев базы.
• Есть eval-набор с правильными и запрещенными источниками.
• Логи пишут user, source URI, outcome и trace ID.
• Расширение на новый source проходит отдельную проверку.

FAQ

Можно ли смешать Confluence, Notion и SharePoint в одном индексе?

Можно, если вы сохраняете source_system, source_url, owner, updated_at и access_group. Без этих полей смешанный индекс быстро станет непрозрачным.

Что важнее: embeddings или коннектор?

На старте важнее коннектор и права. Сильные embeddings не помогут, если в индекс попали закрытые или устаревшие страницы.

Нужно ли обновлять индекс мгновенно?

Не всегда. Для регламентов поддержки часто хватает расписания и webhook/incremental sync. Для критичных политик нужен более короткий max staleness и ручная проверка после изменения.

Что делать, если источник найден, но устарел?

Ответ должен показать свежесть и, если документ просрочен, эскалировать владельцу. Не надо уверенно отвечать по странице с истекшим review cycle.

Можно ли использовать RAG для поиска по личным заметкам?

Только после отдельного согласования прав и приватности. Для первого корпоративного пилота личные черновики лучше исключить.