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

Retrieval Canonical Source Policies в 2026: как задавать главные источники знания в RAG, чтобы система не путалась в конкурирующих документах

Retrieval canonical source policies в 2026: как определять canonical sources, приоритеты и override-правила, чтобы RAG не смешивал равноправно черновики, архивы и официальные документы.

Retrieval canonical source policies в 2026 нужны потому, что RAG редко ломается только из-за векторного поиска. Часто проблема в том, что в knowledge base одновременно живут официальные политики, устаревшие архивы, локальные черновики, tenant-specific exceptions и случайные копии одних и тех же правил. Если система не знает, какой источник canonical, retriever может честно найти релевантный текст, но всё равно привести к неправильному ответу.

Canonical source policy — это правило, которое говорит RAG-системе, какой источник считается главным и более авторитетным, если данные конфликтуют или дублируются.
Самый вредный anti-pattern - считать все найденные документы равноправными только потому, что они похожи по тексту и попали в топ выдачи.

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

Хорошая canonical-source policy в 2026 обычно задаёт:

  1. Какие источники считаются canonical
  2. Какие только supplemental
  3. Как решаются конфликты
  4. Как учитываются tenant-specific overrides
  5. Как canonical status влияет на routing и citations

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

  • релевантность и авторитетность — не одно и то же;
  • архив, draft и official policy не должны иметь одинаковый вес;
  • canonical status должен быть виден retrieval pipeline;
  • конфликт двух supposedly canonical sources — уже отдельный incident class.
Без техники
RAG одинаково использует старый PDF, черновик в wiki и официальный policy doc.
С техникой
Система знает, какой source canonical, а какие можно использовать только как supplemental context.
ПромптCanonical-source intuition
Почему RAG мало просто найти релевантный документ?
Ответ модели

Потому что релевантный текст ещё не означает authoritative текст. Система должна понимать, какой источник имеет приоритет.

1. Canonicality должна быть отдельным сигналом

Полезно различать:

  • canonical source;
  • supplemental source;
  • historical archive;
  • draft or working note;
  • tenant override source.

Так retrieval использует не только similarity, но и governance semantics.

2. Policy нужна именно для конфликтов и дублей

Частые кейсы:

  • старый и новый policy doc;
  • global rule и tenant exception;
  • draft process note и published procedure;
  • copied chunks из разных систем.

Без canonical policy модель часто смешивает их в один будто бы согласованный answer.

Если два источника выглядят одинаково полезными для retriever-а, но один из них реально authoritative, canonical status должен быть encoded явно, а не подразумеваться в голове команды.

3. Canonical policy должна влиять не только на ranking

Полезные эффекты:

  • prefer source in citations;
  • block action support from non-canonical docs;
  • mark conflict for review;
  • downgrade archive results;
  • escalate when canonical owner missing.

Это делает canonicality operational, а не декоративной меткой.

4. Tenant overrides должны жить поверх canonical base

Нужно понимать:

  • что глобально canonical;
  • где разрешён local override;
  • кто владелец override;
  • не истёк ли он;
  • не конфликтует ли он с новой global policy.

Иначе local exception quietly разрушает общий knowledge layer.

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

Similarity equals authority

Релевантность путают с приоритетом источника.

Drafts indexed as peers

Черновики конкурируют с official docs.

Archive not downgraded

Исторические документы продолжают влиять на ответы.

Canonical status only in humans' heads

Pipeline его не видит.

No conflict handling

Система не знает, что делать, если canonical sources расходятся.

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

Полезно считать:

  • answers citing non-canonical sources in sensitive flows;
  • canonical-vs-noncanonical citation split;
  • conflicts involving canonical docs;
  • archive hit rate in active answers;
  • stale tenant overrides over canonical base;
  • incidents caused by source-authority mismatch.

Плюсы

  • Canonical policies улучшают reliability RAG-ответов
  • Снижают риск путаницы между official docs и шумом
  • Делают conflicts и overrides видимыми
  • Усиливают retrieval governance

Минусы

  • Нужно поддерживать source metadata и ownership
  • Часть документов трудно однозначно классифицировать
  • Система усложняется по сравнению с pure similarity search
  • Без cleanup canonical policy быстро устаревает

Пример source policy

sources:
  global_refund_policy:
    canonical: true
  support_wiki_draft:
    canonical: false
    role: supplemental

Простой ranking hint

def source_priority(doc):
    return 2 if doc.get("canonical") else 1

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

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

1. Почему similarity сама по себе недостаточна для RAG?

2. Какой anti-pattern особенно вреден?

3. Что полезно делать с canonical policy downstream?

Источники

  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 Cache Invalidation в 2026: как кэшировать RAG без выдачи вчерашней правды
Следующая
Retrieval Conflict Escalation в 2026: что делать, когда источники спорят друг с другом