RAG三大冲突与三大死穴及解决方案

RAG ：向量召回 × 稀疏匹配 × 重排序融合 × 动态裁剪 —— 冲突根源与工程解法

面向开发者的深度技术解析：揭开 RAG 检索 pipeline 中三个环节的底层冲突，以及幻觉漂移、上下文溢出、检索冗余三大企业级死穴的根治方案。

GitHub 项目地址：Long-LLM/Enterprise-RAG-Agent

目录

1. 先认清问题：RAG 检索的三段博弈
2. 冲突一：向量召回 vs 稀疏匹配 —— 语义和关键词的天然对立
3. 冲突二：RRF 融合 —— 当两个排序说不同的话
4. 冲突三：动态上下文裁剪 —— 保精度还是控窗口
5. 三大死穴总览：它们不是独立存在的
6. 死穴一：幻觉漂移 —— 检索到的≠正确的
7. 死穴二：上下文溢出 —— 塞得进去≠LLM 看得见
8. 死穴三：检索冗余 —— 20 条结果里 15 条是同一句话的变体
9. 工程落地全景方案
10. 总结：一张表看清所有决策

1. 先认清问题：RAG 检索的三段博弈

RAG 检索 pipeline 不是一条直线，而是三段在目标上互相冲突的环节：

查询进来 │ ├─► [段一] 多路召回：向量检索（语义） + BM25（关键词） │ 目标：广撒网，宁可多召回不可漏掉 │ 代价：引入大量低质候选 │ ├─► [段二] 融合重排：RRF 融合 + Cross-Encoder 精排 │ 目标：从候选池里挑出真正相关的 │ 代价：计算开销大，排序标准不确定 │ └─► [段三] 上下文裁剪：拼 Prompt 时截断到 LLM 窗口 目标：把有限 token 分配给最高价值的信息 代价：裁掉什么、保留什么，两个决策同样致命

核心矛盾：段一追求"全"，段二追求"准"，段三追求"精"。这三个目标在同一个 pipeline 里互相掣肘——段一召回太多，段二算不过来；段二放水太多，段三塞不下；段三裁得太狠，LLM 看到的信息不完整，前面的努力全白费。

这就是 RAG 检索的"不可能三角"：

全 (Recall) /\ / \ / \ / 冲突 \ / 区域 \ /____________\ 准 (Precision) 精 (Density)

下面逐一拆解每个冲突的底层原因，然后给出工程上验证过的解法。

2. 冲突一：向量召回 vs 稀疏匹配 —— 语义和关键词的天然对立

2.1 向量召回的盲区

向量检索（本项目使用bge-m3，1024 维，COSINE 相似度，IVF_FLAT 索引）的核心是 dense embedding——把一个句子压成一个固定长度的浮点向量。这个压缩过程本身就是有损的。

向量召回的三个盲区：

根本原因：embedding 模型在训练时学到的是"语义分布"，不是"字符匹配"。向量空间里，bge-m3认为"AK-47"和"突击步枪"的距离比"AK-47"和"AK-47"（从不同文档片段来的）还要近——因为在训练语料中它们总是一起出现。

2.2 稀疏匹配的盲区

BM25（本项目使用 jieba 分词 + BM25 内存索引，见backend/app/core/retrieval.py:28-121）解决了精确匹配问题，但带来了相反的盲区：

BM25 的数学本质决定了它只看"词频 + 逆文档频率"——score = IDF × TF × (k1+1) / (TF + k1×(1-b+b×dl/avgdl))。这个公式里没有语义的位置。

2.3 它们为什么会冲突

当你把向量召回和 BM25 同时挂上去，冲突立刻出现：

场景：用户问 "2024 年 Q3 的产品路线图" 向量召回 Top-10： #1 "产品规划与发布节奏" (score: 0.92) ← 语义相关，但不是 Q3 #2 "年度产品战略" (score: 0.88) #3 "新功能上线时间表" (score: 0.85) ... BM25 Top-10： #1 "2024 年 Q3 产品路线图 - 详细版" ← 精确匹配！ #2 "2024 年 Q3 路线图" ← 精确匹配！ #3 "产品路线图" (score: 2.1) ← 关键词部分匹配 ... 问题：两个列表几乎不相交。 向量召回的 #1-#10 可能没有一个出现在 BM25 的 #1-#10 里。

根本冲突：向量说"这几篇语义最像"，BM25 说"那几篇关键词最匹配"。当你面前摆着两个都不完美的排序列表时，怎么合并它们？这就是第二个冲突的来源。

2.4 工程解法：互补而不是对抗

关键认知转换：不要试图让向量和 BM25 “一致”，而是利用它们的不一致来互相补盲。

本项目的做法（retrieval.py:157-206）：

# 1. 两路独立召回，各取 top_kvector_results=milvus.search_by_vector(embedding,top_k=top_k_vector)bm25_results=bm25.search(query,top_k=top_k_bm25)# 2. 不做分数归一化（min-max 归一化在分布差异大时反而引入偏差）# 直接用 RRF 按排名融合，不依赖原始分数尺度# 3. BM25 先扩大召回范围（3x），再用 Milvus filter 过滤权限bm25_results=bm25.search(query,top_k=top_k_bm25*3)# 过滤后截断到 top_k_bm25

黄金法则：

• 向量侧重 recall（召回更多，top_k 设大一些，如 20-30）
• BM25 侧重 precision（精确命中，BM25 分数的区分度比向量距离高得多）
• 不归一化分数，只融合排名

3. 冲突二：RRF 融合 —— 当两个排序说不同的话

3.1 RRF 的数学与陷阱

Reciprocal Rank Fusion（RRF）是目前最广泛使用的多路召回融合算法：

RRF_score(chunk) = Σ 1 / (k + rank_i)

其中k=60（本项目默认值），rank_i是该 chunk 在第 i 路召回中的排名。

RRF 的隐含假设：每一路召回的排名都是"可信"的——即排名第 1 的确实比排名第 10 的更相关。但这个假设在企业文档场景下经常不成立：

• 向量召回的 #1 和 #10 可能差距极小（全是 0.85-0.92 的相似度）
• BM25 的 #1 可能分数是 #2 的 10 倍（精确匹配 vs 边缘匹配）
• 如果某个 chunk 只在向量那一路上有排名（BM25 完全没命中），它的 RRF 分数天然偏低

陷阱：RRF 对"双上榜（两条路同时命中）“的 chunk 有系统性偏好。这在直觉上是对的——能被两条路同时找到的 chunk 大概率更相关。但问题是：被两路同时命中的，不等于和查询最相关的。它只是命中了两种检索方式的"交集”，而这个交集可能恰好是噪声。

3.2 k 值的含义：你是信"前排"还是信"全员"

k=0 → score = 1/rank → 极度偏好 #1，后面的几乎没分 k=60 → score = 1/(60+rank) → 相对平滑，#1 和 #10 差距约 15% k=∞ → score = 常数 → 所有人一样，等于没排序

本项目使用k=60（retrieval.py:200），这是一个"温和偏好前排"的选择——#1 的权重约是 #10 的 1.17 倍。在实践中我们发现：

• k=0会导致"赢家通吃"——只要某路召回的 #1 和 #2 都不可靠，整个融合就崩溃
• k=60对排名差异有一定容忍度，但区分度不够，前 5 名的 RRF 分数经常几乎相同
• 这就是为什么RRF 之后必须接 reranker——RRF 负责把候选池从 20 个缩小到 10 个，reranker 负责真正精排

3.3 RRF 融合后的信息丢失问题

一个常被忽略的工程问题：RRF 融合后，原始分数信息丢失了。

# retrieval.py:260-265 - RRF 融合后只保留了一个 rrf_scoreitem["rrf_score"]=score# 原始 vector score 和 bm25_score 丢失

这导致下游 reranker 无法利用"这个 chunk 在向量空间里相似度很高，但 BM25 不高"这样的混合信息来做更精准的判断。reranker 只能看到 chunk 的内容文本 + 一个扁平的 RRF 分数——它不知道这个 chunk 是"语义高度相关但关键词不匹配"还是"关键词命中但语义不相关"。

3.4 工程解法：三层漏斗

这个项目采用了"三层漏斗"架构来化解 RRF 融合的冲突：

Layer 1: 粗筛（多路召回） 向量 top_k=20 + BM25 top_k=20 → 去重后约 30-35 个候选 │ ▼ Layer 2: 融合（RRF k=60） 按排名融合，不依赖原始分数尺度 → 取 top_k_rerank=10 个送入精排 │ ▼ Layer 3: 精排（Cross-Encoder Reranker） BGE-Reranker 逐对计算 query-document 相关性 → 取最终 top_k=5 构建上下文

每一层只做一件事，不越界：

• Layer 1 只管"不遗漏"（recall 最大化）
• Layer 2 只管"去噪声"（把明显不相关的踢掉）
• Layer 3 只管"排序"（对剩余的做精细判断）

4. 冲突三：动态上下文裁剪 —— 保精度还是控窗口

4.1 问题的本质

经过 RRF + Reranker 后，你拿到了 5 个最相关的 chunk。然后你要把它们拼进 system prompt，送进 LLM。

这就是第三个冲突引爆点：

假设每个 chunk 是 512 tokens（使用 parent-child 后可能是 1024+ tokens） 5 个 chunk = 2560-5120 tokens 的参考文档 + system prompt 模板 ≈ 200 tokens + 历史消息（5 轮）≈ 1000-2000 tokens + 用户问题 ≈ 100 tokens + LLM 输出预留 ≈ 2048 tokens ───────────────────────────────── 总计：≈ 6000-9500 tokens

qwen2.5:7b 的上下文窗口是 32768 tokens，看起来够用。但LLM 的"有效注意力"远小于理论窗口。

4.2 长上下文的"中间丢失"问题

学术研究（Lost in the Middle, Liu et al. 2023）已经证明：LLM 对长文本开头和结尾的内容关注度高，对中间部分关注度急剧下降。

LLM 对上下文各位置的注意力分布（示意图）： ▲ 注意力强度 │ │ ██ │ ██ │ ██ ██ │ ██ ██ │ ██ ░░░░░░░░░░░░ ██ │ ██ ░░ 中间盲区 ░░ ██ │ ██ ░░░░░░░░░░░░ ██ │ ██ ██ └──┴──────────────────────────┴──► 位置 开头 结尾

这意味着：你把 5 个 chunk 按 RRF/rerank 分数从高到低排，最相关的排最前面，次相关的排最后面——排中间的那个 chunk，恰好落在 LLM 的注意力低谷里。

4.3 多轮对话的上下文侵蚀

更严重的问题是：在多轮对话中，历史消息会逐步"侵蚀"参考文档的空间。

第 1 轮：参考文档 4000 tokens + 历史 0 tokens = 还可以 第 3 轮：参考文档 4000 tokens + 历史 4000 tokens = 窗口占一半 第 5 轮：参考文档 4000 tokens + 历史 8000 tokens = 窗口快满了

这时候你必须在"裁参考文档"和"裁历史消息"之间做选择——两个选择都会损害回答质量。

4.4 工程解法：分层裁剪策略

本项目在rag_service.py:459-490的_build_context中实现了上下文构造，在此基础上需要更强的裁剪策略：

策略一：去重先行
在拼 context 之前，对 5 个候选 chunk 做文本去重：

# 用 Jaccard 或 n-gram 相似度检测冗余# 如果 chunk_3 和 chunk_1 的 n-gram 重叠度 > 70%，降级 chunk_3 的优先级

策略二：信息密度排序
不要只用 rerank 分数排序。引入"信息密度"指标：

info_density = unique_tokens(chunk) / total_tokens(chunk)

优先保留信息密度高的 chunk，把含有大量重复句式的 chunk 往后排。

策略三：动态 token 预算
不要固定取 top_k=5。改为：

remaining_budget=llm_context_window-system_prompt_tokens-history_tokens-expected_output_tokensforchunkinreranked_candidates:iftoken_count(chunk)<=remaining_budget:add_to_context(chunk)remaining_budget-=token_count(chunk)else:truncate_and_add(chunk,remaining_budget)break

策略四：窗口滑动裁剪历史
多轮对话中，历史消息不取最近的 N 轮，而是根据语义相关性做挑选：

# 不是 "取最近 10 条消息"# 而是 "从最近 20 条中挑和当前问题最相关的 5 条"

5. 三大死穴总览：它们不是独立存在的

在讲具体的解法之前，先认清这三大死穴之间的关系：

幻觉漂移 ▲ │ 提供了错误上下文 │ 上下文溢出 ──────────►│◄────────── 检索冗余 (太多信息塞进窗口) │ (重复信息挤掉有效信息) │ │ │ │ ┌─────────┴─────────┐ │ └────►│ 三者互相加剧 │◄────┘ │ │ │ 幻觉漂移导致LLM │ │ 自信地说错话 │ │ 上下文溢出导致 │ │ LLM 看不到关键信息│ │ 检索冗余导致 │ │ 真正有用的被挤出 │ └───────────────────┘

它们不是三个独立的问题，而是一个问题的三个症状。根因只有一个：检索质量和上下文构造质量之间的 mismatch。检索阶段不知道上下文阶段的约束（token 预算），上下文阶段不知道检索阶段的偏差（哪个结果的置信度实际更高）。

6. 死穴一：幻觉漂移 —— 检索到的 ≠ 正确的

6.1 幻觉漂移的定义

传统 RAG 文献中，"幻觉"指 LLM 生成的内容不在知识库中。但在企业场景下，有一种更隐蔽、更危险的幻觉我们称为幻觉漂移：

LLM 生成的内容确实可以追溯到某个检索到的 chunk，但这个 chunk 本身不是用户真正需要的那条信息。LLM 被次相关的检索结果"带偏了方向"。

6.2 幻觉漂移的真实场景

知识库中有两份文档： 文档 A：《2024 年绩效考核制度 v1.0》（旧版，已被 v2.0 替代） - 内容：绩效评级分 S/A/B/C/D 五档，S 级可获得 6 个月年终奖 文档 B：《2025 年绩效考核制度 v2.0》（新版，当前执行版本） - 内容：绩效评级分 A/B/C 三档，A 级可获得 4 个月年终奖 用户问题："年终奖是怎么算的？" 向量检索结果： #1 文档 A 的 chunk（相似度 0.94）← 语义高度匹配！ #2 文档 B 的 chunk（相似度 0.91）← 语义也匹配，但排在后面 #3 文档 A 的另一个 chunk（相似度 0.88） LLM 看到 #1 后坚定地回答："S 级员工可获得 6 个月年终奖" → 幻觉漂移：回答有据可查，但依据是错的（旧版本）

这种问题比纯粹的信息缺失更危险——因为 LLM 回答得很自信，引用了来源，用户更容易采信。

6.3 根因分析

幻觉漂移的根因有三层：

6.4 工程解法

解法 1：元数据时效性加权

在检索阶段引入文档元数据权重。本项目中 Milvus 的 chunk 存储了doc_id、created_at等字段，可以在后处理阶段调整分数：

# 在 RRF 融合之后、reranker 之前，对分数做时效性衰减fromdatetimeimportdatetimedefapply_recency_boost(results,current_year=2025,weight=0.15):"""时效性加权：新文档的 RRF 分数获得小幅加成"""forrinresults:created_at=r.get("created_at")ifcreated_at:age_years=(datetime.now()-created_at).days/365decay=max(0.5,1.0-age_years*0.1)# 每年衰减 10%，最低保留 50%r["rrf_score"]=r["rrf_score"]*(1+weight*decay)returnresults

解法 2：冲突检测提示词

在 LLM 的 system prompt 中明确告知可能存在版本冲突：

如果参考文档中存在信息矛盾（如同一政策的不同版本）， 请明确指出矛盾所在，并优先采信发布时间最新的文档。 如果无法确定哪份是最新版，请告知用户存在多个版本。

解法 3：意图判断快速路径（本项目已有）

本项目的rag_service.py:34-42已实现了意图判断的规则匹配，对闲聊/问候直接跳过检索。这是防止"没必要的检索带偏 LLM"的第一道防线——很多幻觉漂移的触发场景是用户的模糊问题被强行检索后匹配到了不相关文档。

7. 死穴二：上下文溢出 —— 塞得进去 ≠ LLM 看得见

7.1 上下文溢出的两种形态

显性溢出：token 数超过 LLM 上下文窗口 → 被硬截断 → 丢失末尾信息（往往是需要精确引用的部分）。

隐性溢出：token 数在窗口内，但信息密度太低，LLM 的有效注意力被稀释 → “看了但没看到”。

显性溢出容易发现（接口报错或输出被截断），隐性溢出才是企业场景的真正杀手——系统正常工作，但回答质量持续下降，且没有明显的告警信号。

7.2 隐性溢出的数学模型

LLM 的注意力机制在长上下文场景下有著名的"稀释效应"：

对于长度为 N 的上下文，位置 i 的 token 获得的有效注意力权重约为： attention(i) ∝ 1 / (1 + β × |i - N/2|) 其中 β 随 N 增大而增大——上下文越长，中间的注意力衰减越严重。

这个衰减不是线性的。当上下文从 2000 tokens 涨到 8000 tokens 时，中间位置的注意力可能下降 40-60%。这意味着：

你把 chunk 从 3 个加到 5 个，LLM 实际"看到"的信息量可能反而减少了。

7.3 父子分块的双刃剑效应

本项目的父子分块策略（retrieval.py:222-235）用子块精准检索、父块补充上下文——这解决了"检索时上下文不足"的问题，但同时放大了上下文溢出的风险：

不使用父子分块： 检索到 child_chunk (256 tokens) → 拼入 context 使用父子分块： 检索到 child_chunk (256 tokens) → _enrich_parent_context 获取 parent_chunk (1024 tokens) → 拼入 context 多出的 768 tokens 真的都有价值吗？ 父块中可能 70% 的内容和当前问题无关。

解法：对父块内容做定向裁剪。不是把整个 parent_chunk 拼进去，而是截取子块在父块中的"上下文窗口"：

# 改进 _enrich_parent_context：# 找到子块在父块中的位置，只取该位置前后各 N 个字符child_content=r.get("content","")parent_content=parent.get("content","")child_pos=parent_content.find(child_content[:100])# 用前 100 字符定位ifchild_pos>=0:window_start=max(0,child_pos-256)window_end=min(len(parent_content),child_pos+len(child_content)+256)r["parent_content"]=parent_content[window_start:window_end]

7.4 token 预算的工程实现

建议在本项目的_build_context中引入显式的 token 预算管理：

MAX_CONTEXT_TOKENS=4096# 为 LLM 输出预留足够空间def_estimate_tokens(text:str)->int:"""粗略估算：中文约 1.5 字符/token"""returnint(len(text)/1.5)def_build_context_with_budget(self,candidates,history_messages,max_context_tokens=4096):budget=max_context_tokens context_parts=[]sources=[]fori,candinenumerate(candidates,start=1):content=cand.get("parent_content")orcand.get("content","")estimated_tokens=_estimate_tokens(content)ifestimated_tokens<=budget:context_parts.append(f"[{i}]{content}")budget-=estimated_tokenselifbudget>256:# 剩余预算还够容纳截断内容truncated=content[:int(budget*1.5)]+"...(已截断)"context_parts.append(f"[{i}]{truncated}")budget=0# budget ≤ 256 时直接丢弃，不再强行塞入sources.append(...)# 来源引用仍然保留全部return"\n\n".join(context_parts),sources

8. 死穴三：检索冗余 —— 20 条结果里 15 条是同一句话的变体

8.1 检索冗余的成因

在企业文档中，同一条信息经常在多个位置重复出现：摘要里有一遍，正文里有一遍，FAQ 里又有一遍。向量检索对这种重复高度敏感——三个 chunk 的相似度可能分别是 0.94、0.92、0.91，排在 #1、#2、#4。但它们的内容几乎一样。

这对 RAG 的伤害是双重的：

1. 挤占 token 预算：3 个重复 chunk 占掉了 3 个位置，真正有价值的不同信息被挤出 top-k
2. 强化 LLM 偏见：如果 5 个 chunk 中有 3 个都是同一个说法，LLM 会过度自信

8.2 多查询检索加剧了冗余

本项目引入了查询改写（rag_service.py:308-383），将用户问题改写为 2-3 条查询，分别检索后合并结果。这提高了 recall，但也放大了冗余——不同改写查询可能命中同一批文档的不同 chunk。

# _multi_query_retrieve: 同一个 chunk_id 被多次命中时，分数累加all_results[chunk_id]["_score_sum"]+=r.get("rrf_score",0.0)all_results[chunk_id]["_hit_count"]+=1

这个策略本身是合理的（多次命中确实意味着更相关），但它没有解决相邻 chunk 的内容重复问题。

8.3 工程解法：语义去重 + 多样性重排

解法 1：chunk 级语义去重

在构建 context 前，对 candidate 做 n-gram 或 embedding 级别的去重：

defdeduplicate_candidates(candidates,similarity_threshold=0.85):"""基于 embedding 相似度的去重"""fromsklearn.metrics.pairwiseimportcosine_similarityimportnumpyasnpiflen(candidates)<=1:returncandidates# 可以用内容 embedding 做比较contents=[c.get("content","")forcincandidates]# 简化：用 Jaccard 相似度（基于 2-gram 字符集）kept=[candidates[0]]forcandincandidates[1:]:is_dup=Falseforkept_candinkept:ifjaccard_similarity(cand["content"],kept_cand["content"])>similarity_threshold:is_dup=Truebreakifnotis_dup:kept.append(cand)returnkept

解法 2：MMR（Maximal Marginal Relevance）

MMR 是信息检索中经典的多样性重排算法，在保持相关性的前提下最大化结果之间的差异性：

MMR = argmax[ λ × relevance(d) - (1-λ) × max_similarity(d, selected) ] 其中 λ 控制"相关性 vs 多样性"的权衡： λ=1.0 → 纯相关性排序（标准 reranker 输出） λ=0.7 → 偏相关性，适度增加多样性（推荐） λ=0.5 → 平衡 λ=0.0 → 纯多样性排序

defmmr_rerank(query_embedding,candidates,lambda_param=0.7,top_k=5):"""MMR 多样性重排"""selected=[]remaining=list(candidates)whilelen(selected)<top_kandremaining:mmr_scores=[]forcandinremaining:relevance=cand.get("rerank_score",0)redundancy=0ifselected:# 计算和已选 chunk 的最大相似度similarities=[cosine_sim(cand["embedding"],s["embedding"])forsinselected]redundancy=max(similarities)mmr=lambda_param*relevance-(1-lambda_param)*redundancy mmr_scores.append(mmr)best_idx=mmr_scores.index(max(mmr_scores))selected.append(remaining.pop(best_idx))returnselected

9. 工程落地全景方案

上面讨论了每个问题的独立解法。这一节把它们串联成一个完整的工程方案。

9.1 检索 pipeline 的完整改造

用户查询 │ ├─ 1. 意图判断 ────────── 闲聊/问候 → 直接回答（不走检索） │ │ │ ▼ 知识库查询 ├─ 2. 查询改写 ────────── 1 条变 2-3 条，补全上下文 │ │ │ ▼ ├─ 3. 多路召回 ────────── 向量 top_k=20 + BM25 top_k=20 │ │ BM25 先扩大 3x 再用权限过滤 │ ▼ ├─ 4. 时效性加权 ──────── 对 RRF 分数做时效衰减，新文档加权 │ │ │ ▼ ├─ 5. RRF 融合 ────────── k=60，融合排名，取 top_k=10 │ │ 保留原始分数用于后续 debug │ ▼ ├─ 6. Cross-Encoder 重排 ── BGE-Reranker，取 top_k=8（多留 3 个给 MMR） │ │ │ ▼ ├─ 7. 语义去重 ────────── Jaccard/embedding 去重，阈值 0.85 │ │ │ ▼ ├─ 8. MMR 多样性重排 ───── λ=0.7，取 top_k=5 │ │ │ ▼ ├─ 9. 父子上下文提取 ──── 保留子块前后各 256 字符窗口（非完整父块） │ │ │ ▼ ├─ 10. Token 预算裁剪 ──── 动态分配，预算耗尽时截断而非抛弃 │ │ │ ▼ └─ 11. 构造 Prompt → LLM 生成

9.2 本项目的落地对照

9.3 可观测性：你不能优化看不见的东西

企业级 RAG 必须对检索 pipeline 的每一步做可观测性埋点：

# 每个检索请求应输出的 metrics：{"query_id":"uuid","intent":{"type":"retrieve","reason":"...","latency_ms":120},"rewrite":{"original":"...","rewritten":[...],"latency_ms":350},"recall":{"vector":{"count":20,"latency_ms":45},"bm25":{"count":20,"latency_ms":8},},"rrf":{"input_count":35,"output_count":10,"latency_ms":2},"rerank":{"input_count":10,"output_count":5,"latency_ms":180},"dedup":{"before":5,"after":4,"removed":["chunk_id_xxx"]},"context":{"total_tokens":3200,"budget_used_pct":78,"truncated_count":1},"llm":{"latency_ms":2500,"output_tokens":480},"total_latency_ms":3205}

9.4 分级降级策略

当外部服务（Reranker/LLM/Ollama）出现延迟或故障时，需要有降级路径：

Level 0（全功能）：向量 + BM25 + RRF + Reranker + 去重 + MMR + Token预算 │ 延迟: ~3-4s │ Level 1（无 Reranker）：向量 + BM25 + RRF + 去重 + Token预算 │ 延迟: ~2s | Reranker 挂了或被检测到延迟 > 1s │ Level 2（无 BM25）：纯向量 + 去重 + Token预算 │ 延迟: ~1s | BM25 索引重建中 │ Level 3（纯向量 + 截断）：纯向量 top_k=5，不做任何后处理 延迟: ~500ms | Redis/其他依赖挂了，保底可用

本项目已有的降级设计：

• reranker.py:68-76：BGE-Reranker 加载失败时降级为 embedding 余弦相似度
• retrieval.py:152-155：BM25 首次加载失败时降级为纯向量检索
• rag_service.py:381-383：查询改写失败时降级为原始查询

10. 总结：一张表看清所有决策

最后一条建议：RAG 不是一个算法问题，而是一个系统工程问题。向量召回、BM25、RRF、Reranker、去重、MMR、Token 预算——这七个环节中的任何一个出问题，最终用户看到的都是"这个 AI 不太行"。但用户不会告诉你哪个环节出了问题，他们只会说"答案不对"。所以可观测性不是 nice-to-have，是生存必需品。

本文所有代码示例均基于 Enterprise-RAG-Agent 项目的实际架构，包含 FastAPI + Milvus + Ollama + Celery 的完整企业级 RAG 方案。欢迎 Star / PR。