RAG база знаний: как собрать источники, права и freshness

Раздел

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

Сложность

средняя

Обновлено

2026-05-21

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

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

Практический первый релиз: один домен, 50-200 документов, владелец корпуса, access groups, freshness SLA, правила chunking, обязательные citations, eval-набор и rollback-план. Модель и vector store важны, но они не компенсируют грязную базу знаний.

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

Чем отличается от RAG-хаба

Запрос “RAG база знаний” обычно не про теорию retrieval augmented generation. Читатель уже понимает, что модель будет искать по документам, и хочет собрать рабочий контур: какие файлы брать, как не открыть лишнее, как обновлять индекс и как доказать, что ответ основан на источнике.

Поэтому здесь фокус уже операционный.

Отдельные страницы про локальный RAG и embeddings/hybrid search помогут, когда уже выбран контур размещения и retrieval-стратегия. Здесь важнее базовая дисциплина знаний.

Source inventory

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

knowledge_source:
  name: support_runbooks
  system: confluence
  domain: technical_support
  owner: support_ops
  access_groups: [support_l1, support_l2]
  freshness_sla_hours: 24
  document_status: approved_only
  exclude:
    - drafts
    - archived_pages
    - personal_notes

Для первого релиза лучше взять один рабочий домен: база знаний поддержки, runbooks технической поддержки, продуктовые инструкции или юридический playbook. Если смешать все сразу, ошибки трудно диагностировать: непонятно, виноват source connector, права, chunking, устаревший документ или сама генерация.

Официальные облачные документы описывают одинаковый базовый принцип: RAG добавляет к запросу внешний контекст из корпоративных документов. AWS в Understanding Retrieval Augmented Generation отдельно выделяет подготовку данных, chunking, metadata и fine-grained access. Microsoft в материале про Azure AI Search называет ключевыми вызовами multi-source access, token constraints, security governance и citations.

Граница утверждения: vendor-документация подтверждает архитектурный паттерн, но не доказывает качество вашей базы знаний. Качество проверяется только на ваших источниках, правах и тестовых вопросах.

Владельцы и статусы

У RAG базы знаний должно быть два уровня ответственности.

Документ без владельца нельзя считать надежным источником. Его можно положить в cleanup-очередь, но не в боевой индекс. То же относится к страницам со статусом draft, outdated, legacy, duplicate или “не использовать”.

Минимальные статусы:

• approved - можно индексировать;
• needs_review - не индексировать до проверки владельцем;
• deprecated - удалить из индекса и оставить редирект или ссылку на новый процесс;
• draft - не использовать для ответов;
• restricted - индексировать только с жестким access filter.

Права до retrieval

Главное правило: RAG не должен сначала найти закрытый документ, передать его модели и попросить “не раскрывать”. Права должны применяться до retrieval и до формирования контекста.

user identity
  -> allowed groups
  -> source filter
  -> retrieval over permitted chunks
  -> answer with citations
  -> audit event

Microsoft в документации Azure AI Search описывает security trimming, permission metadata и filter-based security at query time для RAG-сценариев. Это хороший ориентир даже если вы не используете Azure: доступ должен быть частью search layer, а не только текстом в system prompt.

Проверьте опасные случаи:

• сотрудник без доступа спрашивает закрытый регламент;
• закрытый документ похож на открытый FAQ;
• пользователь просит “ответь без источника”;
• сервисный токен видит больше, чем должен видеть пользователь;
• старый документ доступен шире, чем новый;
• citation показывает ссылку, которую пользователь не может открыть.

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

Freshness SLA

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

Для каждого source задайте freshness SLA:

Google Cloud в описании Vertex AI RAG Engine показывает типовой процесс: ingestion из источников, transformation с разделением на chunks, indexing в corpus, retrieval и generation. Но какой бы сервис вы ни использовали, ему нужен внешний договор о свежести: когда источник перечитывается, как удаляются архивы, кто получает ошибку sync и как быстро пересобирается индекс после критичного изменения.

Chunking boundaries

Chunking нужно проектировать по типу документа. Универсальное “резать каждые N токенов” часто ломает смысл: в одном chunk оказывается правило без исключения, таблица без заголовка или пункт договора без приложения.

Для каждого chunk храните metadata: source URL, title, section, owner, updated_at, access_group, status, language, product, version. Без metadata вы не сможете отфильтровать права, показать citation, найти stale page и объяснить владельцу, почему ответ был плохим.

Citations и отказ

Для RAG базы знаний citation - это не украшение. Это контракт: пользователь видит, откуда пришел ответ, а владелец знаний может исправить источник.

Минимальная citation должна показывать:

• название документа;
• ссылку на источник;
• раздел или фрагмент;
• дату обновления;
• владельца;
• статус документа;
• уровень доступа или аудит-группу.

Если источник не найден, не разрешен пользователю или просрочен по SLA, система должна отказаться, попросить уточнение или отправить вопрос владельцу. Плохой ответ: “по регламенту можно”. Хороший ответ: “в базе знаний нет утвержденного регламента для этой ситуации” или “найден документ, но он просрочен и требует проверки владельца”.

Eval-набор перед запуском

Eval-набор должен проверять не только красивость ответа. Разделите retrieval, generation, права и freshness.

{
  "question": "можно ли закрыть инцидент без подтверждения клиента",
  "user_group": "support_l1",
  "expected_source": "confluence://support/runbooks/incident-close",
  "must_not_use": ["confluence://drafts/old-incident-policy"],
  "expected_behavior": "answer_with_citation_or_escalate",
  "critical_errors": ["uses_deprecated_policy", "no_citation", "auto_close_allowed"]
}

Для пилота достаточно 80-150 вопросов, если они реальные: из поиска по wiki, тикетов, обращений поддержки, переписок сотрудников и ручных проверок владельцев. Обязательно добавьте вопросы без ответа и вопросы на закрытые документы. Если в тесте есть только простые вопросы с правильным источником, RAG научится отвечать всегда, даже когда нужно отказаться.

Запускать можно, когда:

• правильный источник стабильно попадает в top results;
• ответ использует только разрешенные источники;
• citations открываются пользователю;
• просроченные документы не проходят как нормальные;
• вопросы без ответа дают отказ;
• owner видит журнал ошибок и может исправить документ.

Rollback, если ответы деградировали

У RAG базы знаний должен быть rollback-план до первого пользователя. Нельзя ждать, пока поддержка заметит массовые плохие ответы.

Минимальный rollback:

1. Отключить новую версию индекса для всех, кроме пилотной группы.
2. Вернуть предыдущий corpus snapshot.
3. Отключить новый source или новый chunking rule.
4. Добавить проблемные вопросы в eval-набор.
5. Отправить stale или ошибочные документы владельцам.
6. Запустить повторный прогон retrieval и generation.
7. Вернуть доступ только после сравнения с baseline.

Логируйте trace ID, user group, query, chosen sources, refusal, model version, index version и outcome. Не храните лишний текст пользовательского запроса, если он может содержать персональные или коммерческие данные. Для чувствительных контуров обсудите retention до запуска.

План на две недели

Не обещайте “RAG по всей компании” на первом спринте. Обещайте один проверенный контур, где видно, какие документы вошли, кто за них отвечает и почему ответ можно проверить.

Чеклист

• Выбран один домен, а не вся wiki.
• Для каждого источника есть owner, access group, freshness SLA и статус.
• Draft, deprecated, personal notes и orphan pages исключены.
• Права применяются до retrieval.
• Chunking сохраняет заголовки, таблицы, версии и исключения.
• Каждый ответ показывает citation или корректно отказывается.
• Eval-набор содержит вопросы без ответа, вопросы на права и stale cases.
• Есть index version, журнал ошибок и owner feedback loop.
• Есть rollback на предыдущий corpus snapshot.
• После пилота обновлены внутренние ссылки: RAG hub, поиск по документам, eval и support сценарии.

FAQ

Можно ли начать с одного PDF или одной wiki?

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

Что важнее для RAG базы знаний: embeddings или чистка документов?

На старте важнее чистка документов и metadata. Embeddings помогают искать смысловые совпадения, но не исправляют устаревшие регламенты, дубли и неправильные права.

Нужно ли сразу делать agentic RAG?

Не обязательно. Если вопросы простые и домен узкий, классический retrieval с хорошими фильтрами, citations и eval может быть надежнее первого релиза. Agentic retrieval имеет смысл, когда вопросы сложные, требуют декомпозиции или нескольких источников.

Как понять, что source можно расширять?

Когда текущий домен проходит eval, владельцы быстро исправляют ошибки, citations открываются нужным ролям, а rollback уже проверен. Если эти условия не выполнены, новый source только увеличит шум.

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

Для архитектуры начните с RAG системы, для retrieval-качества - с оценки качества RAG, а для корпоративных источников - с RAG для Confluence, Notion и SharePoint. Если нужен короткий пилот базы знаний с проверкой sources и прав, откройте услуги Woghan.