你以为的 RAG vs 真实的 RAG

很多团队的 RAG 是这样上线的：

文档丢进向量库

用户问题向量检索 topK

把 topK 拼到 prompt 里让模型回答

然后遇到典型问题：

“明明知识库里有，它就是答不出来”（召回失败）

“检索到了，但回答还是胡编”（生成没被证据约束 / 证据噪声太大）

“引用了一堆段落，但都不相关”（相似度不是相关性、chunk 不合理、缺重排）

“效果时好时坏”（query 改写、topK、分块策略、embedding 模型不稳）

结论先给：RAG 是一条 4 段检索-生成链路，每段都有可测指标。效果差时，先定位是哪一段坏了。

1）RAG 的第一性原理（为什么它有效）

纯大模型回答是“闭卷”：只靠参数中的记忆做概率生成，缺证据就会补全（幻觉）。

RAG 把问题变“开卷”：先把外部知识作为上下文注入，让模型在回答时条件化于证据。

工程视角：RAG 的价值不是“更聪明”，而是把真值来源外置，让输出更可控、更可验证（能引用、能追溯）。

2）RAG 四段链路：Chunk → Retrieve → Rerank → Generate

把系统拆成四段，你就能分别优化，而不是盲目调 prompt。

2.1 Chunk（分块与索引）

输入：原始文档（PDF/网页/Markdown/数据库导出）

输出：chunk 列表（每块带 id、来源、时间、权限、内容）

常见坑：

chunk 太大：召回不准、上下文塞不下

chunk 太小：语义断裂、需要跨块拼接才能回答

文档结构没保留：标题/小节/表格丢失导致证据不可用

经验起点（不是圣经）

以“语义段落”为单位：200500 tokens/块，overlap 50100 tokens

chunk 元数据必须有：doc_id, section, updated_at, ACL, source_url

2.2 Retrieve（召回：向量/关键词/混合）

目标：把“可能相关”的证据先找全（宁可多一点再筛）

典型策略：

向量检索（semantic）

BM25（keyword）

混合检索（常见最佳实践）

关键点：召回阶段优先追求 recall，而不是 precision。

2.3 Rerank（重排：把相关的放前面）

向量相似度 ≠ 问题相关性。重排器（cross-encoder 或 rerank LLM）把 topK 候选重新打分，选出 topN 进上下文。

工程收益：

让上下文更“干净”，减少噪声导致的胡答

在 token 预算有限时，提高“有效证据密度”

2.4 Generate（生成：基于证据回答 + 引用）

这一步你已经在第二篇建立了“输出契约”：结构化输出、引用校验、答/追问/拒答动作枚举。

生成阶段最常见的失败不是“不会写”，而是：

证据里没有答案，你却逼它必须回答（导致编）

证据有冲突，没有要求它指出冲突与不确定性

引用没校验，产生“假引用”

3）每段的核心指标（让 RAG 可量化）

想让工程团队愿意投入，必须把“效果”变成指标。建议从这组最小指标开始：

3.1 Chunk 指标

avg_chunk_tokens/ p95_chunk_tokens

chunk_coverage：能否覆盖常见问题（抽样人工评估）

structure_retention_rate：标题/表格是否被保留（抽样）

3.2 Retrieve 指标（离线评测最关键）

需要一个小规模标注集：(query, relevant_chunk_ids)，几十到几百条就能起步。

Recall@K：相关 chunk 是否在 topK 里（最重要）

MRR@K：第一个相关 chunk 排名靠前程度

No-hit rate：topK 全不相关的比例

3.3 Rerank 指标

nDCG@N或简单点：Precision@N

evidence_density：进入上下文的 chunk 中相关比例

3.4 Generate 指标（线上最实用）

citation_success_rate：引用是否可在 evidence 中定位（子串/offset）

grounded_answer_rate：回答是否能被引用支撑（抽样人工或 LLM-judge）

ask_clarify_rate：追问比例（过高可能检索不足，过低可能爱编）

fallback_rate：转人工/拒答比例

成本与体验：avg_tokens, p95_latency

核心理念：RAG 的问题经常不在“生成”，而在“Recall@K 不够”。

4）排障树：RAG 效果差时从哪一步开始查（强烈建议收藏）

你可以按下面顺序定位，命中率很高：

Step 1：先判定是“召回问题”还是“生成问题”

抽 20 条失败样本，问一个简单问题：

正确答案所在 chunk 是否出现在 topK？

如果不在：优先修 Retrieve/Chunk（别折腾 prompt）

如果在：再看 Rerank/Generate

Step 2：召回不全（Recall@K 低）

优先检查：chunk 是否切坏了（答案跨多段、表格被打散、标题丢失）

query 是否偏离文档用词（需要 query rewrite 或混合检索）

embedding 模型是否不适配语料（中英混杂、专业术语）

K 是否太小（先把 K 拉大验证召回上限）

过滤条件是否误杀（ACL、时间、doc type）

快速修复路线：

上混合检索（BM25 + 向量）

加 query rewrite（把口语问题改写为检索友好问法）

调 chunk 策略（语义分段 + overlap）

Step 3：召回到了但不相关（Precision 低，噪声大）

优先检查：

chunk 太大导致“沾边就进来”

语料重复/模板化内容干扰（公告、页眉页脚、目录）

缺 rerank，或 rerank N 太大

修复：

加 rerank（cross-encoder/LLM rerank）

文档清洗：去页眉页脚、目录、重复块

降低进入上下文的 topN，提升证据密度

Step 4：证据相关但仍胡答/不引用

优先检查：

生成 prompt 没有“基于 Evidence、信息不足要追问/拒答”的硬约束

输出没有结构化与引用校验（假引用）

上下文太长，关键证据被淹没（注意 token 预算与排序）

修复：

强制 JSON 输出 + citations

引用必须可定位，不通过则重试/降级

把最相关证据前置（rerank 后按得分排序）

5）一个工程可落地的 RAG 参考架构（后端/架构关心）

建议把 RAG 做成可观测的流水线，而不是一坨 prompt：

Ingress（鉴权、限流、日志trace）

Query Processor（意图识别、query rewrite、语言检测）

Retriever（hybrid：BM25+Vector）

Reranker（cross-encoder/LLM）

Context Builder（token 预算、去重、排序、拼装 evidence）

LLM Generator（结构化输出/工具调用）

Validator（schema 校验、引用校验、安全策略）

Observability（样本回放、指标、告警）

Store（向量库、文档库、评测集、反馈数据）

关键工程点：每个阶段都要输出中间产物（e.g. retrieved_ids、rerank_scores、final_context），否则线上坏了你无法定位。

6）你可以直接用的“RAG 最小评测集”搭建法（低成本）

很多团队卡在“没法评测”。最小可行方案：

从真实日志里抽 50~200 条 query（覆盖高频场景）

人工为每条 query 标注：相关 chunk（1~3 个即可）

跑离线检索，算 Recall@K / MRR

每次改 chunk/retrieve/rerank 都回归一次

这一步做完，你团队会立刻从“感觉好点了”变成“Recall@20 从 0.62 到 0.81”。

7）本篇小结

RAG 不是“向量库 + prompt”，而是四段链路工程

优化顺序通常是：召回（Recall） > 重排（证据密度） > 生成约束（grounding）

没有指标与中间产物日志，就没有可迭代性