AI-порталAI-портал

Retrieval Provenance Policies в 2026: как делать происхождение источника частью RAG-политики

Retrieval provenance policies в 2026: как хранить owner, source type, freshness и trust class для каждого retrieval item, чтобы ответы и actions опирались не только на релевантность, но и на происхождение.

Retrieval provenance policies в 2026 нужны потому, что один retrieval item без происхождения значит слишком мало. Да, он может быть релевантным. Но кто его написал, когда он был обновлён, какой это source type, относится ли он к trusted corpus и можно ли на его основе принимать action decision — всё это не видно из одного similarity score. Без provenance RAG становится хорошим поиском, но слабой системой принятия решений.

Provenance — это происхождение источника: откуда пришёл фрагмент, кто владелец, насколько он свежий, к какому классу доверия относится и можно ли считать его нормативным.
Самый вредный anti-pattern - хранить provenance только ради красивой citation в UI. На деле provenance должен влиять на routing, confidence и право системы делать claims или actions.

Короткая версия

Хорошая provenance policy в 2026 обычно хранит:

  1. Source type
  2. Owner
  3. Freshness
  4. Trust class
  5. Action eligibility

Что особенно важно

  • provenance должен жить не в UI, а в retrieval record;
  • similarity score и trust class нужно разводить;
  • ownership и freshness должны влиять на answer policy;
  • provenance пригоден не только для цитат, но и для audit и incident repair.
Без техники
RAG хранит только текст chunk-а и similarity score.
С техникой
Каждый item знает owner, corpus, freshness, trust class и rule: можно ли на нём основывать answer, citation или action.
ПромптProvenance intuition
Почему релевантный retrieval item без provenance опасен?
Ответ модели

Потому что без происхождения нельзя понять, нормативный это источник или случайный фрагмент, свежий он или устаревший и можно ли вообще на него опираться.

1. Provenance нужен для policy, а не только для explainability

Сильная provenance policy отвечает на вопросы:

  • это internal KB или external web;
  • это официальная policy или просто заметка;
  • кто отвечает за обновление документа;
  • это свежая версия или stale copy;
  • допустим ли этот источник для risky decision.

Без этого retrieval item слишком легко получает незаслуженный authority.

2. Provenance должен быть structured

Полезные поля:

  • source_id;
  • corpus_id;
  • source_type;
  • owner_team;
  • last_verified_at;
  • trust_class;
  • action_eligible.
Если provenance нельзя проверить машинно, он быстро превращается в декоративный label, который не влияет на поведение системы.

3. Ownership и freshness особенно важны для enterprise RAG

Вопрос не только в том, "правда ли это", но и в том:

  • кто исправит источник после инцидента;
  • как быстро можно обновить stale item;
  • какой corpus считается нормативным;
  • можно ли использовать tenant-specific data в shared route.

Именно поэтому provenance policy полезно связывать с ownership model, а не держать отдельно.

4. Provenance должен менять policy ответа

Например:

  • trusted policy source разрешает более сильные claims;
  • stale but trusted source требует caution note;
  • external source разрешён только как low-trust evidence;
  • ownerless source нельзя использовать для action support.

Иначе provenance остаётся справкой для человека, но не правилом для системы.

5. Что особенно часто ломают команды

Provenance only in UI

Backend routing и answer policy его не используют.

No owner field

Непонятно, кто чинит плохой источник.

Stale source treated as normal

Freshness не влияет на trust.

External and internal sources mixed

Одинаковый policy weight для разных classes.

No action eligibility

Система не различает answer-only и decision-capable evidence.

6. Какие метрики полезны

Минимальный dashboard обычно включает:

  • provenance coverage rate;
  • ownerless-source rate;
  • stale-source usage rate;
  • answers based on low-trust provenance;
  • action attempts backed by ineligible sources;
  • incident repair time by owner_team.

Плюсы

  • Structured provenance делает RAG policy-aware, а не только relevance-aware
  • Ownership ускоряет incident repair и content governance
  • Freshness и trust class уменьшают риск ложной authority
  • Provenance помогает строить честные citations и audits

Минусы

  • Нужно хранить больше metadata на каждый retrieval item
  • Сбор owner и freshness требует дисциплины на ingestion
  • Слишком грубые trust classes могут потерять полезные нюансы
  • Без integration в routing provenance быстро становится формальностью

Пример provenance record

{
  "source_id": "doc_182_chunk_4",
  "corpus_id": "tenant_kb",
  "source_type": "policy_doc",
  "owner_team": "support_ops",
  "last_verified_at": "2026-04-01T10:00:00Z",
  "trust_class": "trusted_internal",
  "action_eligible": false
}

Простой policy sketch

def may_support_claim(record):
    if record["trust_class"] == "low_trust":
        return False
    if not record["last_verified_at"]:
        return False
    return True

Практический совет: provenance policy начинает работать только тогда, когда система меняет поведение на основе происхождения источника, а не просто рисует красивый label в citation popup.

Проверьте себя

1. Почему provenance важен не только для UI citations?

2. Какие поля особенно полезны в provenance?

3. Какой anti-pattern особенно опасен?

Источники

  1. OpenAI API Docs - Evaluation best practices
  2. Ragas Docs - Evaluate and Improve a RAG App
  3. LangChain Docs - Retrievers
  4. LangChain Docs - Vector stores
Предыдущая
Retrieval Policy Overrides в 2026: как вводить исключения в RAG, не ломая базовую retrieval policy
Следующая
Retrieval Reindex Playbooks в 2026: как переиндексировать knowledge base без слепых деградаций