查询扩展高级实践

当 top-k=10 召回仍不足 85% 时，如何采用查询扩展（Query Expansion）提升？

一、核心方案环节细问（验证技术落地可行性）

1. 意图锚点抽取环节

• 细问1：为什么选择1.3B小模型做意图锚点抽取？不用规则模板（比如关键词匹配）或更轻量的TF-IDF？规则模板的优势是延迟几乎为0，你放弃的原因是什么？
• 考察点：技术选型的权衡思维，是否理解“规则vs模型”的适用边界，能否量化选型依据。
• 应答要点：① 规则模板的局限性：面对口语化/模糊表达（如“小孩半夜发烧哭闹怎么办”“3岁娃发烧38.5度”），关键词匹配容易漏抓核心实体（如“3岁娃”“38.5度”），意图锚点不准会导致后续扩展跑偏；② 1.3B模型的优势：经过领域微调后，能理解上下文语义，比如区分“小孩发烧”（需求是治疗）和“小孩发烧原因”（需求是科普），锚点准确率达96%+，而规则模板仅82%；③ 延迟权衡：1.3B模型经INT8量化后，延迟仅10ms，远低于线上200ms红线，相比规则模板的0ms延迟，收益（锚点准确率提升14%）远大于成本（增加10ms延迟）。
• 细问2：锚点抽取的“核心实体+意图动词”是怎么定义的？比如“小孩发烧吃什么药”，核心实体是“小孩、发烧、药”还是“小孩、发烧”？意图动词是“吃”还是“治疗”？如果定义模糊，后续扩展会跑偏，你怎么解决这个问题？
• 考察点：技术方案的细节设计能力，是否考虑到语义理解的模糊性，有无标准化方案。
• 应答要点：① 锚点定义标准：核心实体分“主体（如小孩）+ 核心事件（如发烧）+ 关键属性（如38.5度、半夜）”，意图动词需抽象到“领域核心意图”（而非表面动词）；② 举例说明：“小孩发烧吃什么药”中，核心实体是“小孩、发烧、药”，意图动词抽象为“治疗”（而非“吃”），因为“吃”是具体动作，核心需求是通过吃药实现治疗；③ 标准化保障：通过领域词典（如医疗领域的“发烧=发热、小孩=幼儿”）和标注数据集（10万条领域query标注锚点）微调1.3B模型，同时设置“锚点置信度阈值0.8”，低于阈值的query直接走“原query检索+人工审核”流程，避免锚点模糊导致扩展跑偏。

2. 大模型同步扩展环节

• 细问1：为什么选择10B大模型做扩展器？不用34B/70B模型提升扩展质量，也不用1.3B小模型进一步降低延迟？另外，temperature=0.3、top-p=0.85的参数是怎么确定的？调大temperature会有什么问题？
• 考察点：大模型选型的权衡思维，参数调优的逻辑，对生成式模型不确定性的把控能力。
• 应答要点：① 模型选型权衡：34B/70B模型扩展质量仅比10B高2%（相关扩展query占比从92%提升到94%），但延迟增加3倍（从35ms到105ms），超出可接受范围；1.3B小模型延迟仅15ms，但扩展质量差（相关扩展query占比仅75%），会导致后续过滤后有效扩展不足2条，无法提升召回率；10B模型是“质量-延迟”最优解；② 参数确定逻辑：通过离线实验对比不同参数组合的“扩展相关性+多样性”：temperature=0.3（低随机性，避免扩展跑偏）、top-p=0.85（保证一定多样性，避免扩展query重复），此时扩展query的“相关且不重复”占比达88%；③ 调大temperature的问题：若temperature调至0.7，扩展query多样性提升到95%，但相关占比降至72%，会增加后续过滤压力，甚至导致有效扩展不足，反而降低召回率。
• 细问2：你提到用“连续批处理（continuous batching）+ KV-Cache复用”降低延迟，能具体解释一下这两个技术在这个场景下的实现逻辑吗？比如KV-Cache复用是复用哪部分缓存？连续批处理如何避免请求排队导致的延迟波动？
• 考察点：大模型工程化部署能力，对低延迟优化技术的实际理解（而非仅知道名词）。
• 应答要点：① KV-Cache复用逻辑：扩展query的prompt包含“意图锚点”（如“小孩发烧”），不同用户的query若锚点相同（如“小孩发烧怎么办”“小孩发烧吃什么”），prompt的前缀（“请用同一场景的5种不同说法表达，保留‘小孩发烧’关键词”）和核心锚点部分完全一致，可复用这部分的KV-Cache，仅需计算不同后缀的token，减少70%的计算量；② 连续批处理实现：摒弃传统的“单批处理完再处理下一批”，采用动态批处理机制——当新请求到来时，若当前批处理还有剩余计算资源（如GPU显存、算力），直接将新请求加入当前批，同时为每个请求记录进度，避免长请求阻塞短请求；通过这种方式，在QPS 3000时，批大小稳定在16-32，p99延迟控制在50ms内，无明显波动。
• 细问3：prompt设计中要求“每条8～15字，保留核心关键词”，为什么要限制长度？如果不限制长度，会出现什么问题？另外，除了保留关键词，还有没有其他手段保证扩展不偏离原始意图？
• 考察点：prompt工程能力，对生成式模型输出控制的细节思考。
• 应答要点：① 限制长度的原因：一是减少检索延迟——扩展query越长，向量编码和BM25分词的计算量越大，每条query的检索延迟会增加3-5ms，5条扩展query就会增加15-25ms；二是避免语义稀释——过长的扩展query（如超过20字）容易引入无关信息（如“小孩发烧怎么办，有没有适合3岁宝宝的安全方法，最好是家庭护理的”），导致检索时匹配到无关文档；② 额外意图约束手段：一是在prompt中明确“同一场景”“不改变原始需求”等约束；二是加入负面示例（如prompt末尾补充“错误示例：‘大人发烧怎么办’（偏离小孩场景）、‘小孩感冒怎么办’（偏离发烧核心）”）；三是大模型输出后，先做“核心锚点匹配检查”，若扩展query不包含核心锚点（如“小孩发烧”），直接过滤，无需进入相似度打分环节。

3. 相关性过滤环节

• 细问1：为什么选择交叉编码器（cross-encoder）轻量版做相似度打分？不用双编码器（bi-encoder）？双编码器可以提前预计算向量，延迟更低，你放弃的原因是什么？另外，相似度阈值0.78是怎么确定的？
• 考察点：检索模型选型的权衡思维，阈值调优的逻辑，对不同编码器适用场景的理解。
• 应答要点：① 编码器选型权衡：双编码器的优势是延迟低（预计算向量后，相似度计算仅需1ms），但劣势是语义匹配精度低——面对同义但句式差异大的query（如原query“小孩发烧怎么办”、扩展query“幼儿发热该如何处理”），双编码器的相似度打分仅0.65，会误过滤；交叉编码器轻量版（如MiniLM-L6-v2）需实时计算query对的语义相似度，延迟3ms/条，5条扩展query仅增加15ms，但相似度计算精度高，能准确区分“同义句式”和“偏离句式”；② 阈值确定逻辑：通过离线验证集（1万条原query+扩展query对）统计阈值与“过滤准确率”“有效扩展保留数”的关系：阈值0.78时，过滤准确率（把偏离query过滤掉的比例）达95%，同时平均保留3.2条有效扩展query；若阈值提高到0.85，过滤准确率达98%，但平均仅保留2.1条有效扩展，无法充分扩大检索面；若阈值降低到0.7，保留4.5条扩展，但会引入12%的偏离query，降低后续检索精度。
• 细问2：交叉编码器的延迟是3ms/条，5条就是15ms，有没有办法进一步降低这部分延迟？比如批量推理？如果用批量推理，会影响整体链路的同步性吗？
• 考察点：工程化优化能力，对链路延迟的全局把控思维。
• 应答要点：① 批量推理优化：将5条扩展query组成一个batch输入交叉编码器，批量推理的延迟仅5ms（而非单条3ms×5=15ms），因为模型的前向计算可以并行处理多个样本，减少了重复的初始化和收尾操作；② 同步性保障：批量推理是在大模型输出5条扩展query后一次性进行的，属于“串行中的批量优化”，不会增加额外的等待时间，也不会影响后续并行检索的同步性；整个过滤环节的延迟从15ms降至5ms，全局p99延迟进一步降低10ms。

4. 并行检索与合并环节

• 细问1：为什么选择RRF（Reciprocal Rank Fusion）做重排？不用简单的分数加权（如向量检索分数×0.6 + BM25分数×0.4）？RRF的优势是什么？另外，RRF的参数（如k值）是怎么设置的？
• 考察点：检索重排算法的理解，技术选型的依据，对不同融合策略适用场景的认知。
• 应答要点：① 融合策略选型原因：简单分数加权的劣势是“分数尺度不统一”——向量检索的内积分数范围是[0,1]，而BM25分数范围是[0,100]，直接加权会导致BM25分数主导结果，忽略向量检索的语义匹配优势；RRF的优势是“基于排名而非绝对分数”，对不同检索系统的分数尺度不敏感，能有效融合不同来源的检索结果（向量检索擅长语义匹配，BM25擅长关键词匹配）；② RRF参数设置：RRF的核心参数是k（默认60），表示“排名越靠前的结果权重衰减越慢”；通过离线实验对比k=30、60、100的效果：k=60时，融合后的召回率最高（比k=30高2%，比k=100高1%），同时精确率下降最少；最终设置k=60，RRF公式为：score = Σ(1/(rank_i + k))，其中rank_i是某条结果在单个检索系统中的排名。
• 细问2：你提到“原query+3.2条扩展query并行走向量检索与BM25倒排，各取top-10”，为什么是各取top-10？取top-5或top-15会有什么影响？另外，并行检索是如何实现的？会不会因为某个检索分支延迟高导致整体链路延迟增加？
• 考察点：检索策略的细节设计，并行工程化的实现能力，链路延迟的风险控制。
• 应答要点：① top-k取值原因：取top-5会导致有效结果不足，融合后召回率提升不明显（仅提升3%，达不到85%红线）；取top-15会增加后续RRF重排的计算量（从42条结果增加到63条），延迟增加8ms，同时引入更多无关结果，精确率下降3%+；取top-10是“召回-精度-延迟”的最优解；② 并行检索实现：采用多线程并行调用向量检索服务和BM25检索服务，每个检索分支设置“超时时间30ms”；若某个分支超时（如向量检索服务异常），直接放弃该分支结果，仅用另一个分支的结果进行融合；通过这种“并行+超时降级”机制，避免单个分支延迟高导致整体链路延迟增加，实测并行检索环节的p99延迟仅25ms。
• 细问3：实验显示精确率（Precision@10）仅下降1.4%，这个下降幅度是怎么接受的？业务方为什么能认可？如果精确率下降超过3%，你会怎么处理？
• 考察点：业务思维，技术指标与业务价值的权衡能力，问题解决的兜底方案。
• 应答要点：① 精确率下降可接受的原因：一是业务核心目标是“召回率≥85%”（避免漏检相关结果，如医疗场景漏检治疗方案会影响用户体验甚至合规风险），精确率是次要目标；二是1.4%的下降幅度对业务影响极小——离线统计显示，精确率从92%降至90.6%，用户点击无关结果的比例仅增加0.8%，远低于业务可接受的5%阈值；② 精确率下降超3%的处理方案：一是优化扩展query的过滤阈值（如从0.78提高到0.82），减少无效扩展；二是调整RRF的参数（如k从60减小到40），增加原query检索结果的权重；三是对扩展query进行“权重分配”（如原query权重0.6，扩展query权重0.4），而非平等对待，提升精准性。

二、延伸场景细问（验证技术迁移能力）

1. 多语言/方言场景

• 细问：你提到方言query先用“方言转普通话模型”标准化，那这个模型的延迟和准确率是多少？如果遇到小众方言（如客家话、闽南话），转写准确率低，会怎么处理？另外，标准化后锚点抽取的准确率会不会受影响？
• 考察点：边缘场景的技术覆盖能力，风险兜底思维。
• 应答要点：① 方言转写模型指标：采用轻量版方言转普通话模型（如200M参数），INT8量化后延迟仅8ms，主流方言（如四川话、粤语）转写准确率达94%+，小众方言达85%+；② 小众方言处理方案：一是建立“方言词典”，对高频方言词汇（如“娃儿=小孩、发热=发烧”）进行规则匹配，辅助转写；二是对转写准确率低于80%的query，直接放弃扩展，仅用原query检索，同时记录这类query，后续补充标注数据微调方言转写模型；③ 锚点抽取影响控制：标准化后锚点抽取准确率仅下降1.2%（从96%降至94.8%），因为锚点抽取模型已通过“方言-普通话平行语料”微调，能适应转写后的文本差异；若准确率下降超3%，则在锚点抽取前增加“转写文本清洗”步骤（如去除转写错误的字符、补全缺失语义）。

2. 低延迟敏感场景

• 细问：你提到把10B模型蒸馏成0.8B小模型，量化到INT8，能具体解释一下“蒸馏”的过程吗？蒸馏后模型的扩展质量损失0.7%，这个损失是怎么衡量的？另外，华为昇腾310P单卡QPS 500，若业务QPS达1000，该怎么扩容？
• 考察点：模型压缩技术的实际应用能力，硬件部署经验，高并发场景的扩容思维。
• 应答要点：① 蒸馏过程：采用“知识蒸馏”——以10B大模型为教师模型，0.8B小模型为学生模型，用领域内的10万条query作为训练数据，让学生模型学习教师模型的“扩展query分布”和“语义相似度打分分布”；同时加入“对比学习”，让学生模型区分“相关扩展”和“偏离扩展”；蒸馏后模型的参数规模从10B降至0.8B，推理速度提升3倍；② 质量损失衡量：通过离线验证集计算“扩展query相关占比”和“召回率提升幅度”——蒸馏前10B模型的扩展相关占比92%，召回率提升8%；蒸馏后0.8B模型的扩展相关占比91.3%，召回率提升7.3%，损失0.7%；③ 高并发扩容方案：一是采用“多卡部署”——华为昇腾310P单卡QPS 500，2卡集群即可满足QPS 1000的需求，通过负载均衡分发请求；二是“边缘节点部署”——在靠近用户的边缘节点部署模型，减少网络传输延迟（从中心节点的20ms降至5ms）；三是“动态扩缩容”——基于QPS监控数据，在高峰时段自动增加节点，低谷时段减少节点，降低成本。

3. 合规风险场景

• 细问：你提到“prompt层加红线+敏感词过滤+大模型自检”的双保险，能具体说明这三步的执行顺序和各自的作用吗？如果大模型生成了未经验证的疗效描述（如“吃XX药能快速退烧”），敏感词过滤没拦住，大模型自检能发现吗？准确率多少？
• 考察点：合规风险的把控能力，方案的兜底机制设计。
• 应答要点：① 执行顺序及作用：第一步“prompt层红线”（前置约束）——在prompt中明确禁止生成违规内容，从源头减少违规输出；第二步“大模型自检”（事中检查）——大模型生成扩展query后，自动对每条query进行合规性判断（如是否包含疗效承诺、违规广告），准确率达98%+；第三步“敏感词过滤”（事后兜底）——用领域敏感词库（如医疗领域的“快速治愈、特效、根治”）对扩展query进行匹配过滤，准确率达99%；② 未拦住的违规内容处理：大模型自检的准确率达98%，能覆盖大部分未经验证的疗效描述；若仍有遗漏（2%），敏感词过滤会进一步兜底，最终违规内容的输出率低于0.05%；同时，所有扩展query都会实时写入日志，次日离线审计，若发现违规内容，立即冻结对应prompt模板，补充标注数据微调大模型。

4. 动态优化场景

• 细问：你提到把扩展query的点击反馈建模成bandit问题，能具体解释一下这个模型的实现逻辑吗？比如用什么bandit算法？如何平衡“探索”（尝试新的扩展query权重）和“利用”（沿用效果好的权重）？另外，在线调整权重的频率是多少？会不会影响系统稳定性？
• 考察点：在线学习算法的应用能力，动态优化的工程化保障思维。
• 应答要点：① bandit模型实现逻辑：采用“epsilon-greedy”算法，将每条扩展query视为一个“臂”，点击反馈（点击=正奖励，未点击=负奖励，点击后转化=高奖励）作为奖励信号；模型实时计算每条扩展query的“累积奖励”，权重与累积奖励正相关；② 探索-利用平衡：设置epsilon=0.1（10%的概率探索新权重，90%的概率利用当前最优权重），避免陷入局部最优；探索时，权重在当前最优值的±20%范围内波动；③ 调整频率及稳定性保障：每小时根据前一小时的点击反馈调整一次权重，而非实时调整，避免权重波动过大影响系统稳定性；同时设置“权重调整阈值”——单次权重变化不超过30%，若超过则触发人工审核；调整后的权重通过灰度发布（先覆盖10%流量）验证效果，无问题再全量推广。

三、落地保障（LLMOps闭环）细问（验证工程化与运维能力）

1. 离线评测与回滚机制

• 细问1：你提到“召回率<85%自动回滚扩展模型到上一版本”，召回率是怎么计算的？用什么数据集计算？如果离线评测的召回率和线上真实召回率有偏差（如离线86%，线上84%），会怎么处理？
• 考察点：LLMOps的核心逻辑，指标监控的准确性保障，偏差修正能力。
• 应答要点：① 召回率计算方式：离线评测用“线上真实query日志+人工标注的相关结果集”作为数据集，计算Recall@10（真实相关结果在top-10中的占比）；② 偏差处理方案：一是定期同步线上线下数据集（每周更新一次），保证离线数据与线上真实场景一致；二是引入“线上召回率估算模型”——通过用户点击行为（如点击top-10外的结果视为漏检）估算线上真实召回率，若离线与线上偏差超过2%，则调整离线评测数据集的权重（如增加线上高频query的占比）；三是设置“回滚阈值缓冲”——离线召回率<86%时，不直接回滚，而是先减少扩展query的数量（如从3.2条减至2.5条），观察线上召回率变化，避免误回滚。
• 细问2：用GitOps + Flagr实现分钟级回滚，能具体说明这个流程吗？比如GitOps如何管理扩展模型的版本？Flagr的灰度开关是怎么设置的？回滚后如何验证效果？
• 考察点：工程化运维能力，对主流运维工具的实际应用理解。
• 应答要点：① GitOps版本管理：扩展模型的配置文件（如模型路径、参数、prompt模板）存储在Git仓库中，每个模型版本对应一个Git提交记录；当需要回滚时，通过Git拉取上一版本的配置文件，自动替换当前配置；② Flagr灰度开关设置：Flagr创建“扩展模型版本”灰度开关，支持按流量比例（如10%、50%、100%）和用户维度（如地域、设备）分发流量；回滚时，先将流量切回上一版本（100%流量），同时保留当前版本的1%流量用于对比效果；③ 回滚验证：回滚后实时监控线上指标（召回率、精确率、延迟、用户点击率），若30分钟内指标稳定（召回率≥85%，延迟≤200ms），则完成回滚；若仍有问题，继续回滚到更早的版本，同时触发人工排查。

2. 监控与告警机制

• 细问：除了召回率和延迟，你还会监控哪些指标来保障扩展方案的稳定性和效果？这些指标的告警阈值是怎么设置的？如果出现“扩展query相关占比突然下降10%”的告警，你会怎么排查？
• 考察点：系统监控的全面性，问题排查的逻辑思维。
• 应答要点：① 核心监控指标：除召回率、延迟外，还包括——扩展query相关占比（过滤后有效扩展/总扩展）、精确率、用户点击率、违规内容输出率、模型服务可用性；② 告警阈值设置：基于历史数据的3σ原则（超出正常波动范围3倍标准差），如扩展query相关占比正常范围90%±3%，告警阈值设为<84%；延迟正常范围35ms±10ms，告警阈值设为>65ms；③ 相关占比突降10%的排查流程：第一步，检查大模型输入的意图锚点是否准确（若锚点错误，扩展会跑偏）；第二步，检查大模型参数是否被修改（如temperature被调大）；第三步，检查训练数据是否有异常（如新增了大量小众query，模型未适配）；第四步，检查过滤阈值是否被调整（如阈值被降低，导致无效扩展增多）；排查完成后，针对性修复（如回滚锚点抽取模型、恢复大模型参数），并通过灰度开关验证效果。

四、总结：面试官细问的核心逻辑

所有细问最终都围绕三个核心目标：① 验证方案的“可行性”（技术选型有依据、延迟可控、指标达标）；② 验证落地的“稳定性”（有监控、有回滚、有兜底）；③ 验证思维的“全面性”（能覆盖边缘场景、能解决突发问题、能平衡技术与业务）。应答时需避免“只说名词不解释逻辑”，要结合“量化指标”（如延迟、准确率、占比）和“实际场景”（如医疗合规、低延迟需求），体现“技术落地而非理论堆砌”的能力。