11.3 检索失败与相关性陷阱
11.3.1 现象描述
完全依赖向量数据库（Vector DB）进行语义检索，认为“相似度高”就是“答案所在”。语义检索的优势在于理解模糊查询的意图，但它在精确匹配、否定逻辑和跨领域区分方面存在固有短板。
11.3.2 反模式示例
案例一：否定语义被忽略
查询：“我不想要苹果手机。” 检索结果（基于向量相似度）：
“苹果手机是最好的手机...” （语义高度相关，但在意图上完全相反）
“如何购买苹果手机...”
后果：向量模型擅长捕捉语义相似性，但往往忽略了否定词（“不”、“不要”、“排除”），导致检索结果与用户意图南辕北辙。
案例二：专业术语的语义偏移
查询（医疗场景）：“病人出现 水银柱 升高的症状。” 检索结果：
“水银温度计的使用方法...”
“汞中毒的急救措施...” 期望结果：“血压升高的诊疗指南...”
后果：“水银柱”在医疗语境中是“血压”的代称（来自水银血压计的刻度单位），但通用嵌入模型将其与“水银/汞”关联，完全偏离了临床语义。
案例三：多义词导致的跨领域混淆
查询（软件开发场景）：“如何处理 Python 中的 死锁 问题？” 检索结果：
“Python 蟒蛇在进食时出现的'死锁'行为...”
“Python 爬虫遇到的网页死链问题...” 期望结果：“Python 多线程 threading.Lock 死锁的排查与解决方案...”
后果：“Python”既是编程语言也是蟒蛇，“死锁”在不同领域有完全不同的含义。没有领域元数据过滤的纯语义检索在多义词面前容易产生混淆。
11.3.3 后果总结
语义与意图的偏差：向量模型擅长捕捉语义相似性，但往往忽略了否定词（not）、精确数值匹配等逻辑意图。
领域漂移：通用嵌入模型对专业术语的理解可能与领域实际含义不一致，导致检索“看着相关但完全错误”。
信息茧房：总是检索到语义上相似的内容，导致模型无法获得不同维度的补充信息。
11.3.4 修正方案
混合检索（Hybrid Search）：同时使用关键词检索（BM25）和向量检索。BM25 对否定词和精确匹配更敏感，两者互补可显著提升召回质量。
Query Rewrite：在检索前，先用 LLM 改写用户查询。例如将“我不想要苹果”改写为“推荐非苹果品牌的手机”，将“水银柱升高”改写为“血压升高”，再进行检索。
元数据过滤：为文档打上领域标签（如“医疗”、“编程”、“法律”），检索时根据用户所在场景先做领域过滤，再做语义匹配。
重排序（Reranking）：对初步检索结果使用交叉编码器（Cross-Encoder）进行二次排序，交叉编码器能更精细地判断查询与文档的真实相关性。
11.3.5 检测方法
检索命中率监控：定义“黄金标准”检索数据集（Ground Truth），定期运行 Recall@K 和 MRR 评估，跟踪检索质量趋势。
Bad Case 归因分析：对用户不满意的回答进行溯源——先检查检索结果是否相关，再检查生成是否正确。如果检索结果本身就偏离，则是检索层的问题。
否定/精确查询特别测试：维护一组包含否定词、精确数值、专业术语的测试查询，作为检索质量的“金丝雀”指标。
多义词和领域混淆检测：定期对检索日志进行抽样，检查返回结果是否存在领域混淆现象。
11.3.6 预防清单
默认启用混合检索（BM25 + 向量检索），对专有名词、否定和数字查询尤为重要
为知识库中的文档标注领域元数据，检索时先按领域过滤
在检索管道中集成 Query Rewrite 模块，自动处理否定语义和术语转换
建立检索质量回归测试集，覆盖否定查询、专业术语、多义词等边界场景
对于高价值场景（医疗、法律、金融），考虑使用领域微调的嵌入模型替代通用模型
最后更新于