Цитаты и traceability в RAG: как показать источник каждого ответа

RAG-ответ становится проверяемым только тогда, когда читатель может открыть фрагмент источника, который подтверждает вывод. Одной ссылки рядом с готовой фразой недостаточно: система должна знать версию источника, выбранный passage, право пользователя на него и то, сохраняет ли evidence смысл после обновления документа.

Это практический разбор long-tail вопроса «цитаты и источники в RAG». Широкая продуктовая задача принадлежит странице RAG-систем; для архитектурного решения используйте критерии ниже в техническом брифе, а не заменяйте статьёй коммерческий landing page.

Предпосылки: сделать источник цитируемым до retrieval

Не добавляйте citations как элемент интерфейса после того, как модель уже написала ответ. При ingestion каждому source нужны stable identity, version, owner, lifecycle state, access attributes и locator, который может открыть человек. При chunking сохраните parent source и locator до section-level. При retrieval переносите эти поля рядом с текстом, а не восстанавливайте их по title позже.

Минимальная evidence-запись может выглядеть так:

{
  "sourceId": "policy-refunds",
  "sourceVersion": "2026-08-21T09:40Z",
  "passageId": "policy-refunds#returns-3.2",
  "locator": "/policies/returns#3-2",
  "lifecycle": "current",
  "accessScope": ["support"],
  "contentHash": "..."
}

Это контракт, не универсальная schema. Для PDF нужны page и paragraph locator, для knowledge-base page — revision URL, для записи базы — immutable record ID. Главное, чтобы оператор мог воспроизвести путь evidence, не доверяя тексту модели.

TRACE-8 workflow: от вопроса к source-linked ответу

Авторский TRACE-8 workflow удерживает evidence рядом с каждым решением и не зависит от конкретного vendor.

QUESTION + authenticated scope
  -> retrieve eligible passages with source/version/locator
  -> reject stale, unauthorized or unlocatable candidates
  -> select diverse evidence for each planned claim
  -> draft only from selected evidence
  -> attach claim-to-passage citations
  -> verify links, versions and coverage
  -> answer | ask for review | no-answer

Например, пользователь поддержки спрашивает, принимается ли возврат после указанного срока. Workflow ищет только current policy passages, разрешённые этому пользователю, выбирает section с правилом срока и section с исключениями, затем показывает ответ с точными ссылками. Если policy неоднозначна, система должна обозначить ограничение или направить кейс на review, а не заменить rule общей FAQ-страницей.

Контракты интеграций

Ingestion → index. Публикуйте версию source и её locators атомарно, где это возможно. При изменении документа сначала сделайте superseded version ineligible, а затем считайте новую searchable. Успешный embedding job сам по себе не доказывает, что старая citation больше не появится.

Retriever → reranker. Передавайте identity source, lifecycle и access scope с каждым candidate. Reranker может улучшить порядок, но не должен находить passage за trusted corpus. Почему этому selection layer нужен явный no-answer route, показано в статье Reranking в RAG.

Answer composer → UI. Храните citations как structured objects, а не как HTML из model output. Тогда UI единообразно покажет title, locator, version date и verified link, а telemetry отличит missing citation от broken link.

Acceptance criteria перед контролируемым пилотом

Используйте representative, permission-safe questions и проверяйте workflow целиком:

Проверяйте это на cases, а не по одному average quality score. Добавьте недавно обновлённую policy, denied source, удалённый document, конфликтующие current sources и вопрос без достаточного evidence.

Эксплуатация: сохранить traceability после запуска

Traceability быстро деградирует, если не управлять ownership и lifecycle sources. Назначьте owner для source changes, index reconciliation, мониторинга broken citations и rollback. Сохраняйте конфигурацию ingestion и retrieval, породившую ответ, но redact query и document content по правилам хранения данных продукта.

Отслеживайте практические сигналы: citation-link success, selected passages без locators, stale-version rejections, no-answer rate по query class и regression evaluation после изменений source или model. Это не универсальные показатели качества, а диагностические сигналы конкретной evidence boundary.

Для контролируемого RAG-пилота подготовьте representative questions, типы документов, access rules, update paths и определение случаев для human decision. Страница RAG-систем остаётся широкой технической точкой входа, а кейсы дают delivery context. Начните с ограниченного corpus и сделайте путь evidence каждого ответа проверяемым до расширения доступа или автоматизации.