RAG 检索增强工程

RAG（检索增强生成）不是“把文档转成向量后问模型”。它是一条证据供应链：先找到正确证据，再让模型基于证据回答，最后验证答案是否忠于证据。任意一环失效，最终文本仍可能流畅，却不可靠。

1. 把问题拆成三类质量

数据质量 × 检索质量 × 生成质量 = 最终可用性

• 数据质量：文档是否最新、完整、可解析，权限元数据是否正确。
• 检索质量：正确片段是否出现在候选集和最终上下文里。
• 生成质量：回答是否覆盖问题、忠于证据、给出可核验引用。

先检查检索结果，再调整提示词。证据根本没被取回时，换更强模型通常只是生成更自信的错误答案。

2. 文档摄取与规范化

每个片段应保留正文之外的元数据：

{
  "chunk_id": "handbook:refund:policy:12",
  "document_id": "refund-policy",
  "title": "退款规则",
  "section_path": ["企业套餐", "退款窗口"],
  "source_uri": "/policies/refund#enterprise",
  "updated_at": "2026-08-01T00:00:00Z",
  "version": "sha256:...",
  "tenant_id": "tenant-a",
  "acl": ["support", "finance"],
  "text": "..."
}

chunk_id 要稳定，文档更新后能做增量删除与重建；source_uri 用于引用；version 用于缓存失效；租户和 ACL 必须在检索阶段过滤，不能等生成后再隐藏。

2.1 切分要服从语义结构

固定每 500 字切一刀会截断表格、步骤或条件。优先按标题、段落、列表和代码块切分，再用长度上限兜底。片段需要适度重叠，但重叠过大会让候选集充满重复内容。

经验不能代替评测。至少比较两到三组切分策略，并测“正确证据是否进入前 K 条”。

3. 查询理解与改写

用户问题往往不适合直接检索：

• “它怎么退款？”中的“它”依赖对话；
• “装不上”缺少系统、软件和错误码；
• 一个问题可能同时问资格、流程与时限。

查询层可以做：补全指代、提取过滤条件、拆分多问题、生成关键词和语义查询。改写后同时保留原问题，避免模型把用户真实意图改丢。

原问题：企业版能退吗？多久能到账？
检索子问题 A：企业套餐退款资格与申请窗口
检索子问题 B：企业套餐退款到账时间
过滤：product=enterprise, status=published

4. 混合检索与重排

向量检索擅长语义相近，关键词检索擅长错误码、型号、人名和精确术语。生产系统常把两者合并：

1. 关键词检索取 Top 30；
2. 向量检索取 Top 30；
3. 用倒数排名融合（RRF）合并；
4. 用重排模型对前 30 条重新评分；
5. 去重并选择能覆盖不同子问题的 5–10 条。

RRF 的简化形式：

score(d) = Σ 1 / (k + rank_i(d))

它不要求不同检索器的原始分数处在同一尺度。重排提高精度，但增加延迟，应单独记录耗时与收益。

4.1 上下文选择不是盲目 Top K

最终上下文要兼顾：相关性、证据覆盖、来源权威性、新旧版本、片段多样性和 Token 预算。十段近似重复的高分结果通常不如五段分别覆盖定义、条件、例外、步骤和时限的结果。

5. 权限过滤必须早于生成

错误做法是先检索所有租户资料，再告诉模型“不要泄露”。正确做法是在查询执行层把 tenant_id、用户角色、文档 ACL 和有效期加入强制过滤器。模型没有机会看到无权内容，自然也无法在答案、日志或引用中泄露它。

缓存同样必须带权限范围。两个文本完全相同的问题，来自不同租户时不能共享包含私有证据的答案。

6. 让回答可核验

要求模型对关键事实附上 chunk_id，服务端再把它映射到允许访问的链接。不要让模型自由编造 URL。

{
  "answer": "企业套餐可在付款后 7 天内申请……",
  "claims": [
    { "text": "申请窗口为 7 天", "citations": ["handbook:refund:policy:12"] }
  ],
  "insufficient_evidence": false
}

生成后验证：引用 ID 必须来自本次上下文；关键数字必须能在引用片段找到；证据不足时应明确请求补充信息或拒绝下结论。

7. RAG 评测分层进行

7.1 检索指标

• Recall@K：标注的正确证据是否出现在前 K 条；
• MRR：第一条正确证据排得多靠前；
• nDCG：多个不同相关度证据的排序质量；
• 权限泄露率：无权片段进入候选集的比例，目标必须是零。

7.2 生成指标

• 答案是否回答问题；
• 每个关键主张是否有证据支持；
• 引用是否准确定位到原文；
• 证据不足时是否正确拒答；
• 是否混入旧版本或相互矛盾的规则。

建立 50–200 条真实问题作为起点，并刻意加入缩写、错别字、指代、多跳问题、无答案问题和权限边界问题。

8. 常见失败与定位顺序

现象	先检查	常见修复
完全找不到	解析、索引、过滤器	修摄取任务和元数据
找到相似但非正确条目	查询与召回	混合检索、同义词、字段加权
正确证据排太后	重排与去重	加重排器、改训练样本
有证据仍答错	生成与上下文组织	结构化主张、降低干扰、强化引用
总引用旧规则	版本与失效机制	发布状态过滤、增量更新、缓存版本化

9. 一个可运营的更新闭环

文档发布触发增量解析和索引；失败进入重试队列；删除文档同步删除片段；每天对源数据与索引做数量及版本对账；抽样检查解析质量。线上无答案问题进入待标注队列，经过人工确认后加入评测集。

RAG 的护城河不是向量数据库品牌，而是持续维护的数据、可解释的检索链路和能阻止回归的评测集。