查询改写怎么设计？

先这样答

查询改写的设计核心是弥合口语提问与知识库书面语的语义鸿沟。用户提问多为非正式的口语表达。知识库文档通常使用严谨的书面术语。直接检索容易导致字面匹配失效。改写模块需要把用户原始输入翻译成检索友好的标准形态。

具体设计包含三个处理方向。第一是指代补全。多轮对话中用户常常使用代词。模型需要结合历史上下文把代词替换成具体名词。第二是口语转术语。模型要把通俗的口语描述准确映射到知识库内部的专业词汇。第三是长问题拆分子问题。用户经常在一个复杂句子里提出多个独立需求。系统需要把长句切分为多个短查询。系统再拿这些短查询分别执行检索。

评估改写效果必须依赖固定的评测集。开发者要在评测集上对比改写前后的召回率变化。改写操作存在引入新噪声的风险。模型一旦理解错误，改写出的查询就会偏离用户原意。系统必须在架构上设计回退机制。如果发现改写后的查询召回效果变差，系统要直接抛弃改写结果。系统重新使用用户的原始提问进行检索。

面试官会怎么追问

• 「你提到要在固定评测集上比召回率，这个评测集怎么构建？」 评测集需要收集真实用户的原始口语提问。开发者针对这些提问人工标注对应的知识库文档。测试时分别用原句和改写句去检索。系统统计这两者命中人工标注文档的比例来计算召回率。

• 「怎么判断改写后的召回效果变差了，从而触发原句回退？」 系统比较改写句和原句检索结果的相似度得分。如果改写句召回的文档得分普遍低于原句召回的文档得分。系统判定改写引入了噪声。系统直接丢弃改写结果并使用原句。

• 「长问题拆分子问题后，检索回来的多份内容怎么处理？」 系统用拆分出的多个子问题分别执行检索。系统把所有召回的文档片段放入同一个候选池。模型结合用户的原始长问题对候选池内容进行统一阅读理解。

回答的坑

• 盲目相信大模型的改写能力，忽略改写错误引入新噪声的风险。
• 缺失定量的评估标准，没有建立固定评测集来对比召回率指标。