Enterprise RAG Pipeline

摘要

Retrieval-Augmented Generation（RAG）把外部知识检索结果放进模型上下文，让模型在回答时引用可追溯证据。它的基本思想来自 Lewis 等人在 2020 年提出的 RAG 方法：参数化模型负责生成，非参数化知识库负责提供可更新事实。

企业 RAG 的难点不在“能不能搜到一段相似文本”，而在检索前后的约束：用户是否有权看到这段证据，文档是否仍然有效，多个来源冲突时哪个更权威，答案是否忠实于证据，以及失败能否被定位到 ingestion、retrieval、reranking 还是 generation。

标准链路

一个可生产化的 RAG pipeline 通常包含七个阶段：

documents
  -> parsing and cleaning
  -> chunking
  -> metadata and permission binding
  -> sparse / dense indexing
  -> retrieval and reranking
  -> grounded generation
  -> evaluation and feedback

这里每一层都会影响最终答案。chunk 太大，召回噪声上升；chunk 太小，证据上下文被切碎。metadata 不完整，系统无法按产品版本、地区、客户或权限过滤。reranker 不稳定，正确证据可能被埋在候选集后面。

企业 RAG 与普通文档问答的区别

普通文档问答常从“上传 PDF 并提问”开始。企业 RAG 必须先解决访问边界。

type KnowledgeChunk = {
  id: string;
  sourceId: string;
  content: string;
  sourceType: "policy" | "manual" | "case" | "ticket" | "contract";
  version: string;
  validFrom: string;
  validUntil?: string;
  ownerTeam: string;
  authorityLevel: "draft" | "reviewed" | "approved" | "deprecated";
  acl: {
    tenants: string[];
    roles: string[];
    projects: string[];
    customers?: string[];
  };
};

这些字段不是装饰。它们决定一个 chunk 能不能进入候选集。企业 RAG 的安全边界应该发生在检索之前，而不是答案生成之后。

混合检索是默认架构

单一向量检索很容易漏掉精确符号，例如产品型号、错误码、合同条款编号。单一关键词检索又不擅长处理同义表达。更稳的架构是 hybrid retrieval：

组件	擅长问题	常见失败
BM25	精确词、错误码、字段名、版本号	语义近似召回弱
Dense embedding	同义改写、自然语言问题	数字、专有名词、否定关系不稳
Metadata filter	权限、版本、地区、客户范围	元数据缺失时无法过滤
Reranker	在候选中重新排序	成本增加，长文档需要截断
Context compressor	控制上下文长度	可能删掉限定条件

企业场景通常先用 metadata filter 收窄范围，再合并 sparse 和 dense 的候选，最后用 reranker 排序。这样能同时照顾精确匹配、语义召回和访问控制。

证据治理比向量模型更早

很多 RAG 失败并不是向量模型不好，而是知识本身没有治理。

失败现象	可能原因	修复位置
答案引用旧制度	文档生命周期缺失	source registry / versioning
用户看到无权项目	ACL 未绑定到 chunk	ingestion / metadata
召回结果语义相似但无效	authority level 缺失	source classification
多个证据互相冲突	没有冲突标记	governance workflow
模型编出结论	prompt 和 eval 未约束证据范围	generation / evaluation

如果数据源里同时存在草稿、审批版、历史版和客户定制版，RAG 不能只按语义相似度排序。系统必须知道哪些来源更权威，哪些已失效，哪些只适用于特定客户或版本。

评估指标

企业 RAG 评估不能只看答案对不对。建议分层记录：

retrieval:
  Recall@k, MRR, nDCG, correct_source_recall

reranking:
  top1_authority_rate, stale_source_rate

grounding:
  faithfulness, citation_precision, unsupported_claim_rate

permission:
  permission_leakage_rate, forbidden_chunk_recall

operation:
  latency_p95, index_freshness_lag, feedback_resolution_time

RAGAS 等评估框架把 faithfulness、answer relevancy、context precision、context recall 等指标自动化了一部分，但企业仍需要加入权限、版本和来源权威性指标。

评估样本也要带身份

同一个问题由不同身份发起，期望行为可能不同：

{
  "question": "上一季度制造行业项目采用了哪套数据接入架构？",
  "actor": {
    "role": "presales",
    "project_ids": ["p_218"],
    "tenant_id": "t_01"
  },
  "expected_sources": ["case_218_review_v3"],
  "forbidden_sources": ["contract_218_private", "case_197_review"],
  "expected_behavior": "answer_with_citations"
}

如果另一个用户没有项目权限，正确行为可能是只返回公开产品资料，或者明确拒答。没有身份维度的评估集，无法发现越权召回。

局限

RAG 不是知识治理的替代品。它不能自动让过期文档变成有效知识，也不能从空白流程里凭空生成业务规则。高质量企业 RAG 往往先要求组织回答几个问题：谁维护知识，谁确认版本，谁处理冲突，谁决定失效。

因此企业 RAG 的起点不应是“导入所有资料”，而是选择一个资料边界清楚、责任人明确、问题高频的知识域。

参考材料

• Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, Lewis et al., 2020。
• RAGAS：面向 RAG 的自动化评估框架。
• Self-RAG：让模型通过反思 token 控制检索和自我评估。