当发现 RAG 系统召回结果与用户 query 意图不匹配时，有哪些可能的改进方向？
- 标签：大模型
🏛 业务架构师
召回与意图不匹配，我先按"定位—归因—对症"三步走，避免盲目堆技术：
第一步：归因分类（抽样 badcase 打标，这是关键）：
- A 类·query 侧问题：用户问法口语化、有代词、缺主语（"那个还能用吗"）——query 本身没表达清楚意图；
- B 类·索引侧问题：知识库没有覆盖该主题，或文档写法与提问视角不一致（文档写"售后政策"，用户问"咋退货"）；
- C 类·检索侧问题：文档在库里但没召回——embedding 不匹配、分块切坏了语义、Top-K 太小。
第二步：对症下药：
- A 类 → 查询改写（结合多轮历史补全指代）、查询扩展、HyDE；
- B 类 → 补知识运营（长尾问题补录）、文档按"用户视角"重写 FAQ、父子分块保语义完整；
- C 类 → 混合检索（关键词补语义盲区）、换更适配的 Embedding 模型、调 Top-K 与阈值、加 Rerank 精排。
业务原则：每次优化前必须跑一遍评测集，量化各归因类别的占比——把力气花在占比最大的那类上。没有归因分析的调优是"轮盘赌"，改十处不如改对一处；而且要向业务方同步"多少比例是知识缺失问题"——那部分根本不是技术的锅，是知识运营的投入问题。
🏗 系统架构师
召回与 query 意图失配，我按归因诊断 → 分层修复的方法论处理，不盲调：
先归因（最重要）：抽样 50~100 条 badcase，分类失配原因——query 表达问题（口语、指代、错字）？分块问题（语义破碎、粒度不当）？Embedding 问题（领域漂移、专有名词不敏感）？还是"库里根本没有答案"？不同根因修法完全不同。
按层修复：
- 检索前：query 攒写/改写（补全指代、纠错）、查询扩展、自查询抽元数据过滤、意图路由（FAQ/文档/闲聊分流）；
- 检索中：换或微调 Embedding 模型（领域漂移时在领域语料上对比测试）、混合检索补关键词通道（专有名词失配的特效药）、调 Top-K 放宽候选再交给 Rerank；
- 检索后：加 Cross-Encoder Rerank（双塔召回不准的最后防线）、相关性阈值过滤（低相关直接不给模型，宁可少答不乱答）；
- 数据侧：分块策略重审（标题感知、父子块）、知识覆盖缺口补文档。
验证闭环：建 badcase 回归集，每项改动跑 recall@K 对比，防止按下葫芦浮起瓢。经验排序：Rerank 和混合检索解决六成失配，query 改写两成，剩下的动 Embedding 和分块。
💻 全栈开发专家
召回与意图不匹配，我按「先定位、再下药」的排查路径处理：
第一步：定位问题在哪一环。抽样 50 条 badcase，人工判断是「检索没召回」（期望文档不在 top-k）还是「召回了但排不上来」（在 top-50 不在 top-5）还是「召回了但模型用错」（检索对、答案错）。三种病因药方完全不同。
检索没召回 →：
- 查询侧：同义词缺失、口语化——上查询改写/扩展（Multi-Query、同义词典）；
- 向量侧：Embedding 模型与语域不匹配（通用模型跑专业术语）——换 bge-m3 或领域微调 embedding；
- 分块侧：答案被切碎——调 chunk 策略（结构化切分、父子块）。
召回了排不上 →：上 Rerank（bge-reranker-v2-m3），或混合检索 RRF 融合。
模型用错 →：改生成 prompt（编号引用、强制依据上下文）、降温度。
系统性手段：
- 建 golden set，把 badcase 沉淀成回归用例，每次调优跑一遍防退化；
- 加 query 意图分类前置——闲聊/检索/操作类分流，检索型才走向量库；
- 加元数据过滤（时间、部门、产品线），缩小搜索空间自然提升相关性。
一个高频根因提醒：知识库本身没有答案却硬要模型答，必然文不对题——加拒答分支和知识缺口周报，补数据比调模型有效。