好的 RAG 搜索和差的 RAG 搜索，差在哪里？

一、一个被普遍误解的事实

向量相似度检索，不等于找到了正确答案。

很多技术服务商的 RAG 方案看起来是这样的：文档切片 → embedding → 存入向量库 → 用户提问时做向量相似度匹配 → 把 top-k 结果丢给 LLM 生成答案。

这套流程跑通 Demo 很快。但真正回答用户问题时，问题会一个接一个出现：

• 用户问"P-LOW-FLOW 故障怎么处理"，检索回来的却是"压力传感器校准流程" 。向量相似度认为它们"语义相近"
• 用户问"AsterLab LX-2600 的保修政策"，检索结果里混进了 LX-2500 的政策 。原因是切片时把两个型号的文档切在了一起
• AI 给了一个答案，但用户不知道这个答案来自哪份文档、哪一页、哪一段，无法验证
• 用户问了一个知识库里没有的问题，AI 却一本正经地编造了一个答案，缺少"我不知道"的机制，这就是典型的AI幻觉
• 三年前的旧案例排在新案例前面，没有考虑时间衰减和业务优先级

这些问题的根源在检索环节。

二、好的 RAG 搜索 vs 差的 RAG 搜索

三、RAG 搜索的七个技术层次

层次一：切片策略决定后续质量

切片是 RAG 的第一个环节，也是最容易被忽视的环节。差的切片策略会让后续所有优化都失去意义。

固定长度切片的问题：

一个维修手册的段落是这样的：

"故障现象：泵压波动。可能原因：1. 进样阀密封圈老化；
2. 泵头单向阀磨损；3. 流动相未脱气。处理步骤见下方。"

如果按固定 200 字切片，很可能把"可能原因：1."切在 A 片，"进样阀密封圈老化；2."切在 B 片。用户问"泵压波动的原因"，A 片和 B 片单独看都回答不完整。

好的切片策略至少包含四层：

1. 结构感知切片：先识别文档结构（标题、段落、表格、列表），按语义单元切分，不跨段落
2. 重叠窗口：相邻切片之间保留 20% 重叠内容，确保跨边界的上下文不被切断
3. 元数据标记：每个切片标注所属章节、文档类型、设备型号、版本号
4. 大小自适应：根据内容类型动态调整切片大小。操作步骤类内容切小（100-200 字），概念解释类切大（500-800 字）

LabCare AI 的做法：

• 维修手册按"故障现象 → 可能原因 → 处理步骤 → 验证方法"的结构切片，确保每个切片包含完整的逻辑单元
• 表格单独切片，保留表头作为上下文
• 每个切片关联设备型号、文档版本、审核状态

层次二：混合搜索需要多路并行

纯向量搜索的局限非常明显：它擅长找"语义相近"，但很难保证"精准匹配"。

实际场景：

• 用户问"AsterLab LX-2600 的保修期是多久"，向量搜索可能检索到"AsterLab LX-2500 的保修政策"，两个型号的 embedding 非常接近
• 用户问"故障代码 P-LOW-FLOW"，向量搜索可能匹配到"压力低流量报警"的描述段落，但 miss 了精确包含"P-LOW-FLOW"这个代码的文档

好的搜索系统至少包含四层：

1. 向量语义层：理解"泵压波动"和"压力不稳定"是同一个意思
2. 关键词倒排层：精确匹配设备型号"AsterLab LX-2600"、故障代码"P-LOW-FLOW"、配件编号"SEAL-2847"
3. 元数据过滤层：只检索"已通过审核"+"适用于 HPLC"+"有效期在 2025 年内"的文档
4. 业务规则层：如果当前工单是"紧急"优先级，优先返回"预计耗时 < 10 分钟"的处理方案

多路召回的融合策略：

多路召回不能简单合并向量搜索结果和关键词搜索结果，应该用 RRF（Reciprocal Rank Fusion）算法：

• 向量检索返回一个排序列表
• 关键词检索返回另一个排序列表
• RRF 给每个文档打分：`score = 1/(k + rank_vector) + 1/(k + rank_keyword)`，k 取 60
• 两个列表都排在前面的文档，最终得分最高

四层叠加，才能做到既理解语义，又保证精准。

层次三：重排区分粗排和精排

很多系统把"向量检索 top-k"直接送进 LLM，这相当于让 LLM 在垃圾堆里找金子。

为什么需要重排？

向量检索是"粗排"，追求的是召回率（Recall），目标是不漏掉任何可能相关的文档。它的特点是快（毫秒级），但不够准。

Cross-Encoder 重排是"精排"，追求的是精确率（Precision），目标是在粗排结果里找出真正最相关的文档。它的特点是慢（百毫秒级），但非常准。

两阶段漏斗的工作流程：

用户提问
    ↓
第一阶段：粗排（快）
  - 向量检索召回 top-50
  - 关键词检索召回 top-50
  - RRF 融合为统一的 top-50
    ↓
第二阶段：精排（准）
  - Cross-Encoder 对 top-50 逐条打分
  - 按相关性重新排序
  - 取 top-5 送给 LLM
    ↓
LLM 生成答案

Cross-Encoder 为什么更准？

Bi-Encoder（向量检索用的模型）把查询和文档分别编码成向量，然后算余弦相似度。问题是：查询和文档没有"交互"，模型看不到"这个词在那个语境下是什么意思"。

Cross-Encoder 把查询和文档拼接在一起，送进 Transformer 做交叉注意力。模型能看到查询中的每个词和文档中的每个词之间的关系，从而判断"这段文档是否真的在回答这个问题"。

实验数据表明，加入 Cross-Encoder 重排后，RAG 答案准确率提升 15-40%。对于多跳推理类问题，提升可达 47%。

LabCare AI 的做法：

• 粗排召回 50 条候选，融合向量+关键词+元数据三层
• 用 BGE-Reranker-v2 对候选逐条精排
• 最终只送 top-5 最相关的切片给 LLM，既保证质量，又控制 token 成本

层次四：引用来源保证答案可追溯

AI 说"根据维修手册，建议更换单向阀"，用户问"哪本手册第几页？"，差的系统答不上来。

没有引用来源的隐患：

• 用户无法验证答案的正确性
• 如果答案错了，无法追溯是哪个文档出了问题
• 合规场景（医疗、金融、法律）下，不可接受的

好的引用系统至少做到：

1. 片段级溯源：AI 答案中的每句话都标注来源切片编号
2. 文档级定位：显示来源文档的标题、版本号、页码（或章节编号）
3. 原文高亮：用户可以查看原文切片，对比 AI 是否准确概括
4. 多源整合：当答案综合了多个来源时，分别标注每个论断的来源

LabCare AI 的做法：

• 每个回答下方显示"参考来源"卡片，列出 3-5 个来源切片
• 点击来源卡片可直接查看原文，关键句子高亮显示
• 如果答案综合了多个案例，标注"基于 3 个历史案例"，并列出每个案例的编号和日期

层次五：置信度让用户知道答案边界

差的 RAG 系统对所有回答一视同仁，用户无法判断哪个答案更可靠。

好的系统应该暴露两层置信度：

第一层：检索置信度

• 重排后 top-1 切片的 Cross-Encoder 分数是多少？
• 如果最高分的切片得分 < 0.3（满分为 1），说明检索到的内容与问题相关性很低
• 此时系统应该降低答案的可信度提示，或直接告知"找到的内容可能不够相关"

第二层：生成置信度

• LLM 生成答案时，是否大量引用了检索内容？还是主要靠"脑补"？
• 可以用 RAGAS（Retrieval-Augmented Generation Assessment）框架评估：

• Faithfulness（忠实度）：答案中的信息有多少能在检索内容中找到依据
• Answer Relevance（回答相关性）：答案是否真正回答了用户的问题
• Context Precision（上下文精确度）：检索到的内容中有多少是真正相关的

置信度的实际应用：

LabCare AI 的做法：

• 每轮对话显示"可信度：高/中/低"标签
• 可信度为"中"时，提示"以下回答基于有限资料，建议与工程师确认"
• 可信度为"低"时，直接回答"当前知识库中未找到相关案例，建议提交工单或联系技术支持"

层次六：无答案处理要敢说不知道

最危险的 RAG 行为：知识库里没有答案，但 AI 硬编一个。

为什么 LLM 会编造？

• LLM 的训练目标是最小化困惑度（perplexity），它的本能是"输出看起来像答案的文本"
• 即使检索内容为空或不相关，LLM 也会试图用内置知识或想象力"填补空白"
• 用户往往无法分辨 AI 是在引用资料还是在编造

好的无答案处理机制：

1. 检索空值检测：如果粗排召回的 top-k 全部得分低于阈值，直接进入"无答案"分支
2. 拒绝回答策略：明确告知"根据现有知识库，我无法回答这个问题"
3. 引导式追问："您的问题涉及 [某领域]，知识库中暂无相关内容。您可以尝试：① 用更具体的关键词重新提问 ② 提交新工单 ③ 联系技术支持"
4. 学习闭环：记录用户追问的未回答问题，提示管理员补充知识库

LabCare AI 的做法：

• 当检索置信度 < 0.25 时，触发"无答案"流程
• 不生成任何猜测性回答
• 自动提示"是否要基于现有资料进行推测性回答？"，需要用户明确同意后才继续
• 未回答的问题自动进入"知识缺口"列表，管理员每周收到补充提醒

层次七：历史案例优先级要重视新案例

维修知识库有一个特殊问题：同一个故障，三年前的处理方案和现在的处理方案可能完全不同。因为设备固件升级了、配件换代了、操作规范更新了。

差的排序方式：

• 纯按向量相似度排序，2019 年的案例和 2024 年的案例混在一起
• 用户拿到一个旧方案，按步骤操作后发现设备报错，因为固件版本已经不兼容

好的优先级策略：

1. 时间衰减：越新的案例权重越高。2024 年的案例默认排在 2019 年的前面
2. 频次加权：被多次成功引用的案例权重更高。说明这个方案经受了更多实践检验
3. 业务规则：

• 如果用户问的是"紧急故障"，优先返回"预计处理时间 < 15 分钟"的案例
• 如果用户设备型号是"LX-2600"，优先返回该型号的专用案例，通用案例次之
• 如果当前工单状态是"客户催单"，优先返回"已验证"状态的案例，"草稿"状态的案例过滤掉
• 4. 版本匹配：只返回与用户当前设备固件版本兼容的案例

LabCare AI 的做法：

• 案例默认按"时间衰减 + 引用频次"综合排序
• 用户查询时自动关联当前工单信息（设备型号、固件版本、工单优先级）
• 不兼容的案例显示灰色标签"此案例适用于旧版本固件，请核实"

四、为什么检索层决定了 RAG 的上限

很多人把 RAG 的瓶颈归结为"LLM 不够强"，其实更大的瓶颈在检索层：

• 切片策略决定了 LLM 能不能拿到完整的上下文
• 混合搜索决定了 LLM 能不能拿到精准的上下文
• 重排机制决定了 LLM 拿到的上下文质量
• 引用来源决定了用户对答案的信任度
• 置信度决定了系统什么时候该说"我不知道"
• 无答案处理决定了系统什么时候不该张嘴
• 历史优先级决定了答案的时效性和适用性

检索层做得差，LLM 再强也是在垃圾堆里炼金。检索层做得好，普通的 LLM 也能给出可靠的答案。

五、总结：评估 RAG 搜索质量的七个问题

如果你正在评估 AI 知识库方案，建议用这七个问题筛选服务商：

1. 切片策略：切片是否按语义边界切分？表格和列表是否单独处理？切片大小是否自适应？
2. 混合搜索：是否支持向量+关键词+元数据多层检索？融合策略是什么？
3. 重排机制：是否有两阶段漏斗（粗排+精排）？精排用什么模型？
4. 引用来源：答案是否标注具体来源文档和原文切片？用户能否一键验证？
5. 置信度：是否暴露检索置信度和生成置信度？低置信度时如何处理？
6. 无答案处理：知识库里没有答案时，是编造还是明确告知？
7. 历史优先级：是否考虑时间衰减、频次加权和业务规则排序？

这七个问题答不好的厂商，交付的是一个"会编造的搜索框"。

答得好的，交付的是一个可追溯、可验证、敢说不知道的知识检索引擎。

LabCare AI 提供完整的 RAG 检索优化方案，从切片策略到重排机制，从引用溯源到置信度评分。

如需了解技术细节或预约检索效果评估，请联系我们的技术团队。