查询理解与改写

改写的目标是补齐检索条件

用户问“新版本报销到底改了什么”时，检索需要识别资料域、版本、地区和比较对象；用户问一个精确错误码时，最重要的可能是保留原字符串。查询处理不应默认把所有问题交给模型自由改写，因为改写也可能删除编号、否定词和日期，扩大本应受限的搜索范围。

建议始终保存原query，在旁路生成结构化条件与可选改写：实体、精确ID、语言、as-of、资料类型和未明确的约束。授权条件由服务端加入，不能由改写模型推断。Vespa的查询与排名分离机制说明召回表达与后续打分可以独立设计，原始问题也应保留供最终重排。

一次改写不等于一次事实发现

扩展同义词可改善术语差异，跨语言变体可帮助寻找原始英文资料，但生成的新词不是已经存在的事实。使用假设性描述构造查询时，应标记其搜索用途，并保留原query并行召回，避免模型的先验错误把候选集带偏。

对多部分问题，可以拆成具有明确证据需求的子query，如某一地区旧版上限、新版上限和生效日期。是否继续搜索应由尚未解决的证据缺口决定，而不是只因Agent仍有剩余轮次。每次扩展要消耗独立的时间与费用预算。

评价信息保持与额外收益

固定一组含产品代号、日期、否定条件和中英混写的问题，比较原query与改写query的必需证据召回。记录改写删除了什么、增加了什么、是否改变问题含义，以及多出的模型调用带来多少真正新增成功。

当原query已经足以定位资料时，跳过改写通常更简单。若问题缺少决定性条件，可以先给出明确范围的检索结果或请求补充；不能默默选择一个地区，再把结果写成全企业通用结论。