本文目录#

1. 为什么“向量 + LLM”还不够：RAG 1.0 的常见失效点#

很多团队第一次做 RAG（Retrieval‑Augmented Generation）时，会走一条最短路径：

  1. 把文档切块、做向量；
  2. 用户提问 → 向量检索 TopK；
  3. 把检索结果塞进上下文，让模型回答。

这条路能快速出 demo，但上生产后会反复踩同一类坑——不是模型不聪明，而是“检索与数据治理”没被当作系统来设计。最常见的失效点包括：

  • 命中不了“关键字/编号/专有名词”：像“错误码 E1234”“工单 INC‑20391”“服务名 billing‑api”这种问题，语义向量不一定比传统关键词检索（如 BM25）更可靠。[1][2]
  • 答对语义但答错事实：向量召回的块“看起来相关”，但缺少关键表格/结构化字段（时间、版本、阈值、责任人），模型只能补全想象。
  • 新鲜度不可控：文档更新了，索引没跟上；或者索引更新了，但你无法确认“答案基于哪一版数据”，导致线上纠错成本极高。[5]
  • 权限与多租户漏洞：如果检索层没有权限语义，最糟糕的不是“答错”，而是把不该看的内容喂给模型（随后再怎么“输出过滤”都晚了）。[4]
  • 不可解释、不可复盘：用户问“你依据什么？”你只能说“模型这么说”。没有引用、没有可追溯的检索链路，就没有可信度，也没有回归测试的抓手。

把这些问题合起来，你会发现：RAG 的核心挑战不是“把文档喂给模型”，而是“让知识在工程上可检索、可治理、可追责”。

2. RAG 2.0 的定义：把检索当作“可治理的数据系统”#

我把“RAG 2.0”总结成一句话：检索不只是一个向量搜索，而是一条可观测、可演进、可审计的检索管道。它的目标不是“偶尔答得惊艳”，而是长期稳定地满足这四个指标：

  1. 正确性：回答必须被证据支撑（grounded），并能给出可核验的引用；
  2. 新鲜度：能说明答案依赖的数据版本/时间，并控制索引延迟；
  3. 安全性：权限与隔离在检索层生效，避免越权证据进入上下文；
  4. 可运营性：可以监控、复盘、回放、回归测试，支持灰度与回滚。

一个实用的心智模型是把 RAG 拆成四步（每一步都可以被度量、被治理）：

1
2
3
4
5
用户问题
  -> 候选召回（BM25 / 向量 / SQL / 图谱）
  -> 权限与策略过滤（tenant/role/ACL/敏感级别）
  -> 重排与上下文打包（rerank + 去重 + 去噪 + 预算控制）
  -> 生成回答（带引用 / 置信度 / 拒答与追问）

3. 统一检索管道：Retrieve / Filter / Rerank / Ground#

RAG 2.0 的关键不是“选哪个向量库”，而是把管道结构固定下来，让能力可以逐层演进。

3.1 Retrieve：候选召回（多路并行，而非单点依赖）#

建议把“候选召回”视作多路并行，典型组合是：

  • BM25（关键词/倒排）：处理专有名词、编号、精确匹配、短 query；Lucene/Elasticsearch 是最成熟的工程实现。[1][2]
  • 向量检索：处理同义改写、口语化表达、跨语言；pgvector 等提供了把向量能力落在数据库里的路径。[3]
  • SQL/结构化查询：处理“事实性字段”的精确读取（订单状态、SLA 阈值、配置开关、负责人映射）。
  • 图谱/关系查询（可选）：处理“关系链”问题（依赖、归属、影响面），在特定场景下比“文本块”更可靠。[6]

3.2 Filter：权限与策略过滤（越早越好）#

过滤不只是“把结果列表删一删”，而是要保证两件事：

  1. 越权证据不会进入上下文：模型看见就可能复述。
  2. 过滤规则可解释、可审计：知道“为什么这条证据可用/不可用”。

实践上，你可以把“Filter”拆成三类规则：

  • 鉴权/权限：tenant、role、ACL、行级权限（RLS）等；最好在数据源层或检索层就做掉。[4]
  • 安全策略：敏感级别（PII、密钥、合同条款）、合规区域（地域/数据驻留）。
  • 业务策略：只允许某些数据源、只取最新版本、只取已发布文档等。

3.3 Rerank：重排与预算控制（把“相关”变“可用”）#

候选集里“相关”不等于“可用”。重排阶段建议显式做三件事：

  • 去重与聚合：同一文档多 chunk 命中时，合并成“文档级证据包”（便于引用）。
  • 去噪与裁剪：把“背景介绍”类内容降权，把“结论/规则/阈值/步骤”类内容升权。
  • 预算控制：固定 token 预算，优先保留高置信证据；把“更多内容”变成链接而不是塞进上下文。

3.4 Ground：回答必须带证据（引用 + 可回放）#

最低标准建议做到：

  • 回答中的关键结论能对应到 1–3 个引用来源（标题/链接/段落摘要）；
  • 记录本次检索的关键元数据：query、index_version、doc_ids、scores、过滤原因、最终上下文摘要；
  • 允许“回放”：当用户质疑或线上出错时，你能复现当时的证据集与决策链。

4. 混合检索：BM25、向量、SQL 各管一段路#

把“检索”拆成不同类型的证据通道，往往比在一个向量库里硬凹更稳。

下面是一个可落地的分工表（不是标准答案，但很少出错）：

问题类型 主通道 辅通道 备注
专有名词/编号/报错信息（如 E1234、INC‑20391） BM25 向量 先命中精确 token，再用向量补同义。BM25 的工程实现成熟。[1][2]
口语化/同义改写（“怎么把告警静音？”） 向量 BM25 向量负责语义，BM25 用于补关键字约束。
强结构化事实（状态、时间、阈值、负责人） SQL BM25/向量 结构化字段尽量别让模型“猜”。
关系链（“谁依赖谁/影响面”） 图谱/CMDB 文本检索 关系优先，文本补解释。

一个经验法则：能用结构化字段回答的问题，不要用大段文本去逼模型推断。 这不是“模型能力不行”，而是工程上更便宜、更稳定、更可审计。

5. 新鲜度与一致性：CDC、索引版本与回滚#

RAG 走向生产后，新鲜度往往成为最硬的 SLA：知识更新慢一小时，客服/运维就会用脚投票。

5.1 把索引当作“可版本化的数据产物”#

建议为每次索引构建/增量更新生成一个可追踪的版本标识，例如：

  • index_version（时间戳或递增版本）
  • watermark（数据源最新同步位点）
  • source_updated_at（文档最后更新时间）

当用户看到错误答案时，你至少能回答两个问题：

  1. 当时系统用的是哪一版索引？
  2. 这条证据来自哪个数据源、何时更新？

5.2 用 CDC 把“变更”变成“增量索引”#

当知识来自数据库/业务系统时，CDC（Change Data Capture）通常是更稳的增量路径。Debezium 等工具提供了以日志方式捕获变更并驱动下游索引的工程方案。[5]

你不一定要“一开始就全量 CDC”，但至少要规划：

  • 新增/更新/删除如何反映到索引；
  • 失败如何重试、如何幂等；
  • 发生数据污染时，如何回滚到上一个可信版本（索引回滚比“删库重建”要现实得多）。

6. 权限与多租户：别把“过滤”当成“鉴权”#

RAG 的权限问题经常被低估：很多团队把权限当作“检索后过滤”，但这在工程上并不等价于“安全”。

6.1 权限要在检索层可表达#

常见的可落地做法有三类（按隔离强度从强到弱）：

  1. 物理隔离：每租户独立索引/库；成本高但最直观。
  2. 逻辑隔离 + 强约束：同一索引内带 tenant_id/acl_tags，并在检索查询时做强制过滤（而不是拿到结果再过滤）。
  3. 数据源层行级权限（RLS）：把权限交给数据库执行，检索层只拿“已授权的结果”。PostgreSQL 的 Row Level Security 提供了明确的机制来表达这类约束。[4]

6.2 权限不仅是“看不看”，还包括“能不能被推断”#

即使最终结果被过滤，某些系统仍可能泄露侧信道信息（例如命中数、相似度分布、错误提示差异）。这也是为什么许多安全基线强调：把“策略与证据链”做成可审计、可复盘的系统工程，而不是零散的补丁。[7][8]

7. 结构化知识与图谱：什么时候值得“上图”#

“上知识图谱”经常被当作 RAG 的银弹，但图谱真正擅长的是关系，而不是大段事实文本。它适合的典型场景：

  • 依赖关系（服务 → 依赖 → 下游 → 风险扩散）
  • 归属关系（服务/组件 → owning team/oncall）
  • 版本关系（组件 → 版本 → 变更记录 → 兼容性）

图谱不适合的场景也很明确：

  • 你缺少稳定的实体/关系抽取与维护流程；
  • 你的问题本质上是“从文档里找一段规则/步骤”，倒排 + 向量足够；
  • 你想用图谱替代权限系统（通常会变成新的权限地狱）。

如果要引入图谱，建议把它当作“证据通道之一”，和 BM25/向量/SQL 一样走同一套管道与引用输出。Neo4j 文档可作为图数据建模与查询的权威入口。[6]

8. 可信回答：引用、置信度与拒答（用户体验的一部分）#

RAG 的终点不是“回答一段话”，而是“让用户敢用、敢依赖”。

8.1 引用（Citations）是最低成本的可信度杠杆#

建议引用至少包含：

  • 证据来源（文档/工单/配置项/表记录）
  • 标题/标识（便于人工核对）
  • 可点击链接或可定位字段
  • 证据摘要（不要把整段敏感内容原样输出）

8.2 置信度与拒答：让系统知道“自己不知道”#

你不需要一开始就做复杂的概率校准，也可以用工程启发式做第一版：

  • Top1 与 TopK 的分差过小 → 可能语义不清，先追问澄清；
  • 命中证据过少/证据互相矛盾 → 触发“谨慎模式”（列出证据差异、提示不确定）；
  • 权限过滤后结果为空 → 明确提示“无可用证据”而不是编造答案。

9. MVP 落地路线图（建议按阶段交付）#

如果你要把 RAG 2.0 真正落到团队可复用的能力里，一个更现实的推进方式是“先稳再全”：

  1. MVP（1–2 周）：混合召回（BM25 + 向量）+ 引用输出 + 基础日志（记录 doc_ids、scores、index_version）
  2. 权限版本（2–4 周）：权限在检索层强制表达；补齐审计字段与越权防线（目标：越权证据进入上下文 = 0）[4]
  3. 新鲜度版本（4–8 周）：增量更新/CDC、索引版本化、回滚机制（目标：索引延迟可量化、可告警）[5]
  4. 质量闭环（持续）：离线评测集 + 线上回放回归；把“引用命中率/事实正确率/拒答率/成本”纳入看板
  5. 图谱增强（按需）：只为关系类问题引入，避免“为了上图而上图”[6]

最后给一个面向测试/验收的最小 Checklist（可直接放进评审）：

1
2
3
4
5
6
✅ RAG 2.0 最小验收清单（建议）
- 回答必须带引用（可定位到文档/记录）
- 记录并可回放：query、doc_ids、scores、index_version、过滤原因
- 权限在检索层强制生效（越权证据不会进入上下文）
- 索引新鲜度可量化（同步位点/延迟指标）并支持回滚
- 当证据不足时可追问/拒答，而不是编造

10. 参考资料#

本作品系原创，采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可，转载请注明出处。