RAG on 你怂你mua

RAG 评估与可观测性：如何知道检索真的有效

Sat, 09 May 2026 00:00:00 +0000

引言

RAG 系统最常见的错觉是：只要答案看起来通顺，就以为检索有效。

但 RAG 的质量不只取决于最后一句回答，而取决于整条链路：

用户问题
  ↓
查询改写
  ↓
向量/关键词/混合检索
  ↓
重排序
  ↓
上下文组装
  ↓
LLM 生成
  ↓
引用与答案

任何一环出错，最终答案都可能不可靠：

检索没找到关键文档
找到了但排序太靠后
上下文塞入了大量噪声
模型没有使用正确证据
答案看似合理但不忠于上下文
引用指向了错误段落

所以 RAG 评估要回答两个问题：

1
2

检索是否找到了正确证据？
生成是否忠于这些证据？

前者是检索评估，后者是生成评估。只看其中一个都不够。

RAG 评估的三层结构

一个完整 RAG 评估体系可以分三层。

┌────────────────────────────────────┐
│  第三层：端到端答案评估             │
│  答案是否正确、完整、忠于证据       │
├────────────────────────────────────┤
│  第二层：上下文评估                 │
│  进入模型的证据是否相关、充分       │
├────────────────────────────────────┤
│  第一层：检索评估                   │
│  召回候选是否命中标准证据           │
└────────────────────────────────────┘

第一层：检索评估

检索评估关注：

`1`	`系统有没有把正确文档找出来？`

它不关心模型最后怎么回答，只看候选文档列表。

第二层：上下文评估

上下文评估关注：

`1`	`最终塞进 LLM 的上下文质量如何？`

因为 RAG 通常不是把所有检索结果都塞给模型，中间还会经过重排序、过滤、压缩、拼接。

第三层：答案评估

答案评估关注：

`1`	`模型基于上下文生成的答案是否可信？`

它要检查正确性、完整性、忠实性和引用准确性。

评估集怎么构建

没有评估集，就没有可重复优化。

RAG 评估集至少包含四部分：

id: refund-policy-001
question: "会员退款需要多久到账？"
golden_answer: "会员退款通常在 3-5 个工作日到账。"
golden_context:
  - doc_id: "policy-refund"
    chunk_id: "policy-refund-03"
    text: "退款将在审核通过后 3-5 个工作日原路返回。"
metadata:
  category: "售后"
  difficulty: "easy"

关键不是只写标准答案，而是写清楚“正确答案应该来自哪些证据”。

样本来源

好的评估集来自真实场景：

用户搜索日志
客服工单
线上失败 case
高频业务问题
专家人工设计问题
文档更新后的回归问题

不要只让 LLM 生成一堆看起来合理的问题。合成问题可以补覆盖面，但核心样本必须来自真实用户。

样本类型

评估集建议覆盖：

类型	说明
单跳问题	一个文档片段即可回答
多跳问题	需要组合多个片段
时间敏感问题	答案依赖文档版本
否定问题	文档中明确说不支持
无答案问题	知识库没有答案
相似概念问题	容易检索到相近但错误内容
长尾问题	低频但重要

RAG 系统最容易在“相似但不相同”的问题上翻车。

检索评估指标

检索阶段的输入是 query，输出是 top-k 文档或 chunk。

Recall@K

Recall@K 衡量正确证据是否出现在前 K 个结果里。

`1`	`Recall@K = 命中标准证据的问题数 / 总问题数`

例如标准证据出现在 top-5，就算 Recall@5 命中。

Recall@K 是 RAG 最重要的基础指标。因为如果正确证据没有被召回，后面的 LLM 再强也只能猜。

Precision@K

Precision@K 衡量前 K 个结果中有多少是相关的。

`1`	`Precision@K = top-k 中相关结果数量 / K`

Recall 高但 Precision 低，说明系统虽然找到了答案，但也塞了很多噪声。噪声会占用上下文窗口，甚至误导模型。

MRR

MRR（Mean Reciprocal Rank）关注第一个正确结果排在第几位。

1
2
3

如果正确结果排第 1，得分 1
排第 2，得分 1/2
排第 5，得分 1/5

MRR 适合评估“用户希望第一个结果就有用”的场景。

NDCG

NDCG 适合有相关性等级的场景。

例如：

3 分：完全相关
2 分：部分相关
1 分：弱相关
0 分：无关

它不仅看是否命中，还看高相关结果是否排在前面。

Hit Rate

Hit Rate 是最粗粒度指标：

`1`	`top-k 中只要出现任一相关结果，就算命中`

它简单直观，适合早期快速判断检索是否可用。

上下文评估指标

检索结果通常还要经过重排序、过滤、压缩，最后组装成 context。

这个阶段要评估的是：

`1`	`进入 LLM 的上下文是否既相关又充分？`

Context Recall

Context Recall 衡量答案所需证据是否都进入了上下文。

如果一个问题需要两个证据：

1
2

证据 A：退款 3-5 个工作日到账
证据 B：会员退款需要先审核

但上下文只包含 A，不包含 B，那么 Context Recall 不完整。

多跳问题尤其需要这个指标。

Context Precision

Context Precision 衡量上下文里有多少内容真正有用。

噪声太多会导致：

token 成本增加
模型注意力被稀释
错误信息干扰回答
引用不准确

一个高质量上下文应该是：

`1`	`该有的证据都在，不相关内容尽量少。`

Context Utilization

Context Utilization 衡量模型最终是否使用了检索到的证据。

有些 RAG 系统虽然检索到了正确文档，但模型回答时没有用，仍然凭内部知识或错误片段回答。

这种情况说明问题不在检索，而在上下文组织或生成提示。

答案评估指标

RAG 最终还是要回答用户问题。

Answer Correctness

答案是否正确。

这个指标可以通过：

人工评分
标准答案比对
LLM-as-Judge
规则校验

但它不能单独使用。因为一个答案可能正确，但不是基于检索上下文得到的。

Faithfulness

Faithfulness 衡量答案是否忠于上下文。

例如上下文说：

`1`	`退款通常 3-5 个工作日到账。`

模型回答：

`1`	`退款 24 小时内到账。`

这就是不忠实，即使语气再自然也不可信。

Faithfulness 是 RAG 区别于普通问答评估的核心指标。

Answer Relevance

Answer Relevance 衡量回答是否真正回应用户问题。

例如用户问：

`1`	`会员退款多久到账？`

模型回答：

`1`	`会员退款需要进入订单页面申请。`

这可能是事实，但没有回答“多久到账”。

Citation Accuracy

如果系统提供引用，就必须评估引用是否准确。

常见问题：

引用了无关 chunk
引用位置正确但答案没用它
答案有多个事实但只引用一个来源
引用文档已过期

引用不是装饰，而是 RAG 可信度的一部分。

Trace：RAG 可观测性的核心

没有 Trace，就很难知道 RAG 为什么错。

一次 RAG 请求至少应该记录：

{
  "trace_id": "rag-20260509-001",
  "question": "会员退款多久到账？",
  "query_rewrite": ["会员 退款 到账 时间"],
  "retrieval": [
    {
      "retriever": "hybrid",
      "doc_id": "policy-refund",
      "chunk_id": "03",
      "score": 0.87,
      "rank": 1
    }
  ],
  "rerank": [
    {
      "chunk_id": "03",
      "score": 0.94,
      "rank": 1
    }
  ],
  "context": {
    "chunk_ids": ["policy-refund:03"],
    "token_count": 420
  },
  "answer": "会员退款通常 3-5 个工作日到账。",
  "citations": ["policy-refund:03"]
}

有了 Trace，bad case 才能归因。

Trace 需要记录什么

阶段	关键字段
Query	原始问题、改写 query、用户上下文
Retrieval	retriever 类型、top-k、score、rank
Rerank	reranker 分数、排序变化
Context	chunk 列表、token 数、拼接顺序
Generation	prompt 版本、模型、答案、引用
Feedback	用户反馈、人工评分、失败原因

这些字段不只是为了调试，也是后续评估和优化的数据来源。

Bad Case 归因

RAG 失败要分层定位。

答案错误
├── 检索没召回
├── 召回了但排序靠后
├── 重排序误杀
├── 上下文被截断
├── 上下文噪声太多
├── 模型没使用正确证据
├── 模型幻觉
├── 引用错误
└── 文档本身过期

不同失败原因对应不同修复方式。

失败原因	修复方向
检索没召回	改 chunk、embedding、hybrid search
排序靠后	增加 reranker、调召回路数
重排序误杀	调整 reranker 或保留多路结果
上下文截断	优化上下文预算和压缩策略
噪声太多	提高过滤阈值、做上下文精简
模型没用证据	改生成 prompt、强制引用
模型幻觉	加 faithfulness 检查
文档过期	加文档版本和时效性监控

如果只看最终答案，所有错误都会被粗暴归为“模型不行”。这会误导优化方向。

离线评估流程

RAG 离线评估可以按以下流程跑。

评估集
  ↓
运行检索
  ↓
计算 Recall@K / MRR / NDCG
  ↓
运行重排序和上下文组装
  ↓
计算 Context Recall / Precision
  ↓
运行生成
  ↓
计算 Correctness / Faithfulness / Citation Accuracy
  ↓
输出 bad case

对比实验

每次优化都应该做 A/B 对比：

1
2

baseline: dense retrieval top-5
variant: hybrid retrieval top-20 + rerank top-5

比较：

Recall@5 是否提升
Precision@5 是否下降
Faithfulness 是否提升
平均 token 是否增加
延迟是否可接受

不要只看一个指标。RAG 优化经常是 trade-off：

召回更多 → 上下文更吵 → 生成更容易跑偏
重排序更准 → 延迟更高
chunk 更小 → 命中更准但上下文不完整
chunk 更大 → 上下文完整但噪声更多

线上监控

离线评估不能替代线上监控。

线上需要持续观察：

指标	说明
No Answer Rate	系统无法回答比例
User Retry Rate	用户重复提问比例
Low Confidence Rate	低置信回答比例
Citation Click Rate	用户点击引用比例
Retrieval Empty Rate	检索为空比例
Avg Context Tokens	平均上下文 token
P95 Latency	95 分位延迟
Cost per Answer	单次回答成本

线上监控的重点是发现分布漂移：

用户开始问新问题
文档更新后旧答案过期
新产品功能没有进入知识库
某类 query 的检索突然变差
embedding 模型升级导致排序变化

RAG 系统不是一次建好就结束，它需要持续维护。

人工反馈闭环

用户反馈和人工标注是 RAG 持续优化的燃料。

每个低分回答都应该沉淀为：

question: "会员退款多久到账？"
bad_answer: "24 小时内到账"
correct_answer: "3-5 个工作日"
root_cause: "模型使用了过期文档"
fix:
  - "下线旧退款政策文档"
  - "增加文档版本过滤"
regression: true

这样 bad case 才能进入回归集，防止同类问题反复出现。

最小可用评估方案

从零开始可以先做一套最小闭环。

第一步：准备 50 条真实问题

每条问题标注：

标准答案
标准证据 chunk
问题类型
是否多跳
是否允许无答案

第二步：记录完整 Trace

先不要急着调参数。没有 Trace，优化就是猜。

第三步：先看 Recall@K

如果 Recall@K 很低，优先优化检索，不要调生成 prompt。

第四步：再看 Context Precision

如果 Recall 高但答案差，检查上下文噪声和排序。

第五步：最后看 Faithfulness

如果上下文正确但答案错，说明生成阶段没有忠于证据。

这个顺序很重要：

`1`	`先检索，再上下文，最后生成。`

常见反模式

只看答案满意度

答案满意度是结果，不是诊断。它告诉你错了，但不告诉你哪里错。

没有标准证据

只有标准答案，没有 golden context，就无法评估检索。

只调 prompt

很多 RAG 问题根本不是 prompt 问题，而是检索没召回或上下文噪声太多。

盲目增大 top-k

top-k 越大，召回可能更高，但噪声也更多。需要配合重排序和上下文压缩。

忽略无答案问题

知识库没有答案时，RAG 应该承认不知道。强行回答会制造幻觉。

小结

RAG 评估的核心不是问“答案看起来好不好”，而是沿着链路逐层追问：

检索有没有找对？
排序有没有排前？
上下文有没有塞对？
模型有没有用证据？
答案有没有忠于证据？
引用有没有指对？

真正有效的 RAG 系统，一定有三样东西：

带标准证据的评估集
端到端 Trace
bad case 回归闭环

没有这些，RAG 优化就只能靠感觉。
有了这些，才能知道“检索真的有效”，也才能把 RAG 从 demo 做成可靠系统。

RAG向量检索策略与召回优化详解

Wed, 08 Apr 2026 00:00:00 +0000

为什么检索是 RAG 的瓶颈

RAG 系统的回答质量取决于 LLM 生成质量，但生成质量的天花板由检索环节决定。检索回来的文档如果不相关，LLM 再强也给不出正确答案——垃圾进，垃圾出。

RAG 的核心瓶颈不是生成，是召回（Recall）。

据统计，企业 RAG 项目失败的案例中，60% 以上根因在检索环节：检索不到、检索不准、检索到的内容噪声太大。本文深入 RAG 检索模块，系统性地梳理向量检索策略和召回优化手段。

基础：文本如何变成向量

嵌入模型（Embedding Model）

嵌入模型将文本映射到高维向量空间。语义相近的文本，向量距离也相近。

1
2
3

"今天天气真好" → [0.12, -0.34, 0.56, ...]  (1536维)
"今日气候宜人" → [0.11, -0.32, 0.54, ...]  (向量距离很近)
"数据库索引优化" → [-0.78, 0.23, 0.91, ...] (向量距离很远)

主流嵌入模型选型

模型	维度	最大输入	多语言	开源
OpenAI text-embedding-3-large	256~3072	8192 token	一般	否
OpenAI text-embedding-3-small	512~1536	8192 token	一般	否
BGE-M3 (BAAI)	1024	8192 token	优	是
Cohere Embed v3	1024	512 token	优	否
jina-embeddings-v3	1024	8192 token	优	是
E5-mistral-7b-instruct	4096	32768 token	良	是

选型建议：

中文为主：BGE-M3 是首选，多语言能力强
对维度敏感：OpenAI 支持自定义维度，可平衡精度和效率
本地部署：BGE-M3 或 E5 系列
长文档：jina-embeddings-v3 或 E5-mistral

相似度度量

检索的本质是在向量空间中找最接近的 top-k 个向量：

余弦相似度（最常用）：

`1`	`cos(u, v) = (u·v) / (\|u\|·\|v\|)`

值域 [-1, 1]，越接近 1 越相似。对方向敏感，不受向量长度影响。

欧氏距离：

`1`	`d(u, v) = sqrt(Σ(ui - vi)²)`

对向量长度敏感，适合归一化后的向量。

内积（Dot Product）：

`1`	`u·v = Σ(ui × vi)`

适合预归一化的向量（如 OpenAI 嵌入），计算开销最小。

多数向量数据库默认使用余弦相似度，这也是嵌入模型训练时最常用的一致性目标。

基础检索策略

密集检索（Dense Retrieval）

纯向量检索，直接用 query 向量在向量库中做 ANN（近似最近邻）搜索：

1
2
3

# 伪代码
query_vec = embedding_model.encode("用户的提问")
results = vector_db.search(query_vec, top_k=10)

优点：语义理解强，能召回字面不同但意思相同的文档。

缺点：对专有名词、精确 ID、数字等不敏感。比如"订单号 ORD-2024001"这种情况，纯向量检索容易跑偏。

稀疏检索（Sparse Retrieval / BM25）

传统搜索引擎的核心算法，基于词频-逆文档频率（TF-IDF）：

`1`	`BM25(q, d) = Σ IDF(qi) × TF(qi, d) × (k1 + 1) / (TF(qi, d) + k1 × ...)`

优点：精确关键词匹配，专有名词、编码、数字等场景表现好。

缺点：不懂语义。搜索"怎么连接到数据库"匹配不到"如何建立数据库连接"。

混合检索（Hybrid Search）

密集 + 稀疏 = 互补融合，这是目前工业界的主流方案：

# 伪代码
dense_results = vector_db.search(query_vec, top_k=20)   # 语义检索
sparse_results = bm25_index.search(query_text, top_k=20) # 关键词检索
final_results = fusion(dense_results, sparse_results)    # 融合排序

融合策略：

RRF（Reciprocal Rank Fusion）：score(d) = Σ 1/(k + rank_i(d))，简单有效，无需调权
加权求和：score(d) = α × dense_score + β × sparse_score，需要调超参数
学习融合：用一个小模型学习 dense 和 sparse 的融合权重

RRF 因其无需调参、效果稳定，是目前混合检索最常用的融合策略。

召回优化

查询改写（Query Rewriting）

用户自然的提问方式，和文档的书写风格，往往存在巨大差异。

用户问：“上次那个登录报错的 bug 修好了吗？”

但知识库里的文档写的是：“2026-04-15 修复 auth 模块 session 过期导致 401 的问题”。

直接用原问题检索，大概率召回不到。

解决方案——用 LLM 改写查询：

原始查询 → LLM 改写 → 多个标准化查询 → 检索 → 合并去重

Prompt:
"请将用户的问题改写为多个适合知识库检索的关键词查询。提取关键实体、技术术语和可能的同义表达。
用户问题：上次那个登录报错的 bug 修好了吗？

输出：
1. 登录 报错 bug 修复
2. auth 认证 错误 修复记录
3. session 过期 401 错误 fix
4. 登录失败 问题修复 changelog"

查询改写的常见模式：

模式	做法	适用
关键词提取	LLM 提取关键实体和术语	用户问题口语化
多角度生成	从不同角度生成多个查询	问题模糊、维度多
假设文档	让 LLM 先生成假想答案，用答案当 query 检索	问题复杂需要推理
逐步细化	根据检索结果迭代改写 query	初检不理想时

多路召回（Multi-Channel Recall）

一条检索路径容易漏，多条路径交叉覆盖：

query
  ├── 路径1：原始 query → 密集检索 → Top-20
  ├── 路径2：改写 query → 密集检索 → Top-20
  ├── 路径3：原始 query → BM25 稀疏检索 → Top-20
  ├── 路径4：提取实体 → 精确过滤检索 → Top-10
  └── 路径5：query 向量 → 跨模态检索 → Top-10
            ↓
         RRF 融合 → 最终 Top-10

这个架构是目前生产级 RAG 的标配。多路召回的本质是用冗余换覆盖，用融合算法保证最终结果的质量。

重排序（Re-ranking）

初检的 Top-K 只是"粗排"——向量相似度高不代表真正语义相关。重排序用小模型对初检结果做精排。

`1`	`初检 Top-50 → Re-ranker → 精排 Top-5 → 送 LLM 生成`

常用 Re-ranker：

模型	特点
Cohere Rerank v3	云服务，效果优秀
BGE-Reranker-v2-m3	开源，支持多语言
Cross-Encoder (SBERT)	经典方案，准确但较慢
LLM as Reranker	用 LLM 直接打分排序

Re-ranker 本质是 Cross-Encoder 架构：将 query 和 document 拼接后送入模型，输出一个 0~1 的相关性分数。比向量余弦相似度更准确，但计算开销大，所以只对初检 Top-K 使用。

重排序的关键权衡：K 越大，精排效果越好，但延迟和成本也越高。经验值 20~50 是一个不错的起点。

分段检索与上下文扩展

检索时只返回匹配的 chunk，但 chunk 前后可能有重要上下文。需要在检索后做上下文扩展：

窗口扩展：返回匹配 chunk + 前后各 N 个 chunk

`1`	`检索命中 chunk 5 → 实际返回 chunk 3, 4, 5, 6, 7`

句子滑动窗口：以匹配句子为中心，前后各取 M 个句子

父文档检索：检索小 chunk，返回其所属的父文档

这就是 Small-to-Big 策略：用小粒度做检索（避免噪声），用大粒度喂 LLM（保留上下文）。

索引优化

分块策略对检索的影响

分块是 RAG 的"基础工程"，分块方式直接决定检索质量：

策略	做法	检索影响
固定 Token 分块	每 512/1024 token 切一块	简单但容易割裂语义
递归字符分割	按段落→句子→词的优先级切	尽量保留自然边界
语义分块	LLM 判断分块边界	效果最好但成本高
层级分块	父子文档多层索引	支持多粒度检索

经验分块参数：

文档问答：256~512 token
技术文档：512~1024 token
长文总结：1024~2048 token
chunk 重叠度：10%~20%

元数据过滤

纯向量检索是在全库中搜索。加上元数据过滤，可以先缩小搜索范围：

# 伪代码：带过滤的向量检索
results = vector_db.search(
    query_vec,
    top_k=20,
    filter={
        "doc_type": "技术文档",    # 只搜技术文档
        "date": ">2026-01-01",     # 只看今年
        "department": "后端组"      # 只看本组
    }
)

元数据设计原则：

记录时间戳（时效性过滤）
标注文档类型（分类过滤）
保留来源路径（可追溯）
添加自定义标签（业务过滤）

层级索引（Hierarchical Index）

对于大型知识库，全库平面检索效率低、精度差。层级索引先定位范围再精细检索：

用户 query
  │
  ▼
第一层：粗粒度检索（文档/章节级）
  → 定位到 "后端-数据库-MySQL" 目录下的 5 篇文档
  │
  ▼
第二层：细粒度检索（段落/chunk级）
  → 在这 5 篇文档的 chunk 中检索
  │
  ▼
返回 Top-10

适合文档数量 > 10,000 的大规模场景。

高级检索技术

HyDE（Hypothetical Document Embeddings）

用 LLM 先生成假想答案，再用假想答案的向量去检索：

`1`	`用户问题 → LLM 生成假设答案 → 假设答案向量化 → 检索 → 真实文档`

为什么有效？因为真实文档和"假设答案"往往比和"简短问题"在向量空间中更接近。尤其在问答类场景中效果显著。

代价：多一次 LLM 调用，增加延迟和成本。

自查询检索（Self-Query Retrieval）

让 LLM 从用户问题中提取结构化查询条件 + 语义向量：

用户："2026 年 3 月之后后端组写的关于 Redis 的文章"

LLM 提取：
{
  "semantic_query": "Redis 文章",
  "filter": {
    "date": ">2026-03-01",
    "department": "后端组"
  }
}

多跳检索（Multi-hop Retrieval）

复杂问题需要多步检索，每一步的结果指导下一步：

问题：张三所在部门的数据库负责人是谁？

Hop 1：检索 "张三" → 得到 "张三，后端开发部"
Hop 2：检索 "后端开发部 数据库负责人" → 得到 "李四"

需要 Agent 范式配合——Agent 判断是否需要多跳、何时终止。

查询分解（Query Decomposition）

复杂问题拆解为多个子问题分别检索：

问题：Redis Cluster 和 Codis 的对比，以及各自的适用场景

拆解：
1. "Redis Cluster 架构特点优势劣势"
2. "Codis 架构特点优势劣势"
3. "Redis Cluster 适用场景"
4. "Codis 适用场景"

各子问题检索结果汇总去重后送给 LLM。

检索效果评估

关键指标

指标	含义	目标
Recall@K	Top-K 中相关文档占全部相关文档的比例	越高越好（>80%）
Precision@K	Top-K 中相关文档的比例	越高越好
MRR	第一个相关文档排名的倒数均值	越高越好
NDCG@K	考虑排序位置的归一化指标	越高越好（>0.7）
Hit Rate	至少命中一个相关文档的比例	越高越好（>90%）

构建评估集

需要一个"黄金测试集"——(问题, 正确答案/相关文档)对：

从历史问答中收集 100~500 个真实问题
人工标注每个问题对应的正确答案和应该召回的文档
用评估集测试不同检索策略的效果

没有评估集的调优是盲调——你不知道改了参数到底是变好了还是变坏了。

实践：检索优化清单

按优先级排列的调试清单：

[必做] 检查嵌入模型：模型和语料语言是否匹配？中文用 BGE-M3 通常比 OpenAI 好
[必做] 检查分块质量：切出来的 chunk 语义完整吗？相邻 chunk 之间有信息断层吗？
[必做] 上混合检索：密集 + BM25，用 RRF 融合，这个改动通常能带来 10%~20% 的召回提升
[推荐] 加上重排序：初检 Top-50 + BGE-Reranker 精排 Top-5，对最终答案质量提升显著
[推荐] 查询改写：如果用户提问偏口语化，加一层 LLM 改写
[进阶] 多路召回：在混合检索基础上增加改写查询、实体匹配等召回通道
[进阶] Small-to-Big：小粒度检索 + 父文档上下文扩展
[高阶] HyDE：问答类场景效果明显，但需评估额外延迟

小结

RAG 的检索优化本质是做减法：从海量文档中筛出最相关的那几条，同时尽可能不遗漏。

核心链路：好的嵌入模型 → 合理的分块 → 混合检索（密集+稀疏）→ 重排序 → 上下文扩展 → 喂给 LLM

在这个链路上，每一个环节都有优化空间，但混合检索 + 重排序是高性价比的组合——一个保证覆盖，一个保证精度。在这套基本功之上，再按实际场景评估是否需要查询改写、多路召回、HyDE 等高级策略。