FDE W3D4 学习手册 · Query 优化

W3 Day4 · A 级（必须掌握，面试核心）· 4h · 学完能讲透"用户原始问句如何被改写成更适合检索/生成的形式、无答案如何拒答、引用如何保真"

一、Query 优化总览：为什么要改用户的问句

用户原始问句（original query）往往不适合直接检索：措辞口语化、缺上下文、含指代（"它""这个"）、与知识库文档用词不一致、或问题过大需要拆分。Query 优化就是在"检索前"对问句做变换，让召回更准、答案更稳。

二、Query Rewrite（查询改写）

2.1 原理

用 LLM 把原始 query 重写为一个语义等价但更适合检索的问句。典型做法：

• 术语对齐：把口语换成知识库标准词（"报不报"→"是否符合理赔/报销条件"）。
• 补全上下文：结合用户画像（保单类型、城市、险种）把隐含信息补进 query。
• 消歧/纠错：纠正错别字、明确指代。
• 意图澄清：把模糊问题落到具体子意图。

2.2 实现（LangChain MultiQueryRetriever / query_transformer 思路）

# 简化示意：用 LLM 做 query rewrite
rewrite_prompt = """你是保险知识库检索助手。把用户问题改写成一句
术语标准、信息完整、适合在保险条款库中检索的问题。
只输出改写后的问题，不要解释。
用户问题：{question}
投保人画像：{profile}"""
better_q = llm.invoke(rewrite_prompt.format(question=q, profile=profile))

2.3 什么时候用

• 用户措辞口语化、与文档术语不一致（最常见）。
• query 依赖会话上下文（多轮对话里的指代）。
• 需要把用户意图对齐到知识库的组织方式（FAQ 标题、条款章节名）。

三、Multi-Query（多查询并行检索）

3.1 原理

一个问题往往可以从多个角度表述。Multi-Query 让 LLM 生成 N 个不同表述/不同侧重点的 query，分别检索，再把各路召回的文档去重合并后喂给生成模型。核心收益是提高召回覆盖率。

3.2 适合场景

• 语义宽泛的问题（"怎么理赔"可从流程/材料/时效多角度）。
• 知识库内答案分散在多处（需要广撒网）。
• 单 query 召回 topK 不足或质量不稳定。

3.3 代价与注意

• N 越大延迟/成本越高，常取 3~5。
• 多路召回合并后要做去重（按 chunk_id/doc_id），否则重复内容挤占上下文。
• 合并后建议走一次 Rerank 重新排序，避免某一路劣质召回拉低质量。

四、Query Decomposition（查询分解 / 子问题）

4.1 原理

对复杂复合问题，先让 LLM 拆成若干子问题，再分别检索回答，最后汇总。分两类：

• 独立子问题（Parallel）：子问题彼此无关，可并行检索。
• 依赖子问题（Sequential）：后一个依赖前一个的答案（多跳推理），需顺序执行。

4.2 什么时候用

• 问题需要多跳推理（"A 药报销吗？如果不报销，B 药在哪种保单下能报？"）。
• 答案依赖多个条件/文档，单问句无法覆盖。
• 需要"先定位再细查"（先找条款章节，再查具体金额）。

4.3 工程要点

• 要保留子问题与答案的依赖图，便于溯源和评测。
• 控制分解深度，避免无限递归（设最大层数）。
• 每个子问题可单独应用 Rewrite/Multi-Query。

五、Context Compression（上下文压缩）

5.1 原理

检索回来一堆 chunk 后，其中很多与问题无关。Context Compression 通过压缩/过滤只保留与 query 相关的片段，降低噪声、节省 token、提升生成质量。两类做法：

• 检索后压缩（Contextual Compression Retriever）：先用基础检索拿回较大候选集，再用一个 LLM/小模型对每片做"是否相关 + 抽取相关句子"的压缩。
• 历史压缩：多轮对话里把早期无关历史压缩成摘要，控制上下文长度。

5.2 与 Rewrite/Decomposition 的区别

六、三种 Query 策略对比与选型

七、无答案拒答（Refusal）

7.1 为什么必须拒答

企业知识库（保险条款、特药目录）里没有的信息，模型绝不能硬编——错误理赔结论会造成真实经济损失与合规风险。无答案时应明确拒答并引导。

7.2 实现方式

• Prompt 约束：明确"仅依据给定材料回答，材料无相关依据时输出 should_refuse=true 并说明"。
• 结构化输出：答案 JSON 含 should_refuse 布尔字段 + refusal_reason。
• 检索信号：若 topK 相关分都低于阈值（Rerank 分数 < 门槛），直接判无答案，无需进生成。
• 置信度兜底：生成后若答案里没有可引用来源，强制拒答。

7.3 拒答不等于"甩锅"

好的拒答要给出口：说明缺什么信息、建议联系谁/查哪个渠道（如"未在知识库找到该城市异地就医细则，建议联系保单客服确认"），而不是冷冰冰"不知道"。

八、引用准确性（Citation Accuracy）

8.1 为什么重要

保险场景，答案若没有可核查来源，无法审计、无法追责。引用准确性 = 答案里每条结论都能精确对应到知识库中的具体 chunk / 文档段落，且不能"张冠李戴"。

8.2 保证手段

• 检索即绑定：每片召回 chunk 带 doc_id / chunk_id / 页码，生成时强制"引用只能从这些 id 中选"。
• 结构化引用输出：答案 JSON 含 citations: [{claim, doc_id, chunk_id}]，每句结论挂来源。
• 生成约束：prompt 要求"每个关键结论后标注 [chunk_id]"，且禁止编造 id。
• 引用校验：后处理检查引用 id 是否真实存在、该 chunk 是否真的支持该 claim（可再做一次 LLM 判定"此 chunk 是否支持此句"）。
• 高亮回溯：前端点击引用跳转到原文段落，可人工复核。

8.3 常见失真

• 张冠李戴：结论正确但引用了不相关的 chunk。
• 虚构引用：引用了不存在的 chunk_id。
• 过度泛化：一个 chunk 被引去支撑它本不支持的宽结论。

九、工程落地：改写模型与提示设计

9.1 改写用"小模型"还是"大模型"

• 轻量改写（只消歧/术语对齐）：可用小模型或规则，省成本。
• 复杂改写/分解：需要推理能力，用主力模型，但可降温度（T=0.2~0.3）保稳定。
• 缓存命中：对完全相同的原始 query 直接复用历史改写结果（Redis/本地缓存）。

9.2 提示设计要点

• 明确输出格式（只输出改写问句 / JSON），避免模型啰嗦。
• 给出知识库术语表/同义词表（few-shot），提升对齐准确率。
• Multi-Query 要强调"不同角度、避免同义复述"。
• Decomposition 要输出结构化子问题列表 + 依赖关系。

9.3 评测闭环

改写/拒答/引用都要进评测集（见 W3D5）：改写看是否提升召回；拒答看拒答准确率；引用看引用准确率与幻觉率。

十、怎么评测 Query 优化与可靠性

十一、医疗保险实战案例：特药理赔问答

场景：投保人问"我去年买的百万医疗，现在确诊肺癌要吃奥希替尼，这个药能报吗？还有报销比例多少？"

1. Rewrite：补全画像 → "持有 XX 百万医疗险的投保人，确诊肺癌需使用奥希替尼（靶向药），该药品是否在特药目录内、报销比例及自付要求为何？"
2. Multi-Query：生成 ①"奥希替尼 特药目录 纳入情况" ②"百万医疗 靶向药 报销比例" ③"肺癌 靶向治疗 免赔额/自付比例"。
3. Decomposition（若问题含"先报重疾还是先报医疗"）：拆成重疾给付责任、医疗报销责任、补偿关系三子问题。
4. 拒答：若知识库无"奥希替尼具体比例"，输出 should_refuse=true，引导"以保单批单/客服确认为准"。
5. 引用：答案每条挂 chunk_id（特药目录条目、报销比例条款），前端可点开复核。

十二、常见坑与排查清单

十三、面试达标线①：三种 Query 策略各解决什么、何时用

十四、面试达标线②：引用准确性怎么保证、无答案怎么拒答

14.1 引用准确性保证

1. 每片 chunk 带 doc_id/chunk_id，生成时只允许从这些 id 引用。
2. 答案 JSON 要求 citations:[{claim, chunk_id}]，每句结论挂来源。
3. 后处理校验：引用 id 真实存在 + 该 chunk 确实支持该 claim（可做二次 LLM 判定）。
4. 多路召回合并时必须保留来源标记，否则引用混乱。

14.2 无答案拒答

1. 检索分数阈值：topK 相关分都低于门槛 → 直接判无答案。
2. 结构化 should_refuse 字段 + 生成时 prompt 约束"无依据就拒"。
3. 拒答要给出口（缺什么信息、建议联系谁），不是冷拒。
4. 拒答进评测集测拒答准确率，防止模型"自信硬编"。

十五、W3D4 自测清单

十六、高频面试题速记卡