RAG 查询改写与 HyDE 的使用边界

用户的问题不够清楚，RAG 系统该直接检索、先改写，还是先生成一段假想答案再检索？作者给出的答案是：先判断原文能不能动，再根据意图置信度和检索结果选择路径。

这套方案的价值，在于把 Query Rewriting 和 HyDE 放进同一个决策流程。不过，文中的 Python 只是教学示例，效果提升也没有附带具体数据。读它最有用的方式，是拿走分流思路和验收条件，同时看清哪些部分还需要自己验证。

哪些问题应该保留原样

作者首先处理的不是检索效果，而是查询里有没有必须保留的标识符。例如「stock ticker XYZ price」中的 XYZ，不能在补全语义时被替换或丢失。

流程图因此把领域关键性放在第一步：包含受监管标识符的查询保留原文，并执行护栏检查（Guardrails）；没有这类标识符，再判断意图是否足够明确。置信度高，也直接用原查询检索。

查询已经准确时，增加生成步骤未必能带来收益。

作者提供了只依赖 Python 标准库的 decide_strategy，返回值为 Literal["original", "rewrite", "hyde"]。下面这段负责输入校验和标识符检测：

    # 1. basic validation
    assert isinstance(query, str) and query.strip(), "query must be non‑empty"
    assert all(32 <= ord(ch) <= 126 for ch in query), "query must be printable ASCII"

    # 2. detect regulated tokens (very simple regex for illustration)
    regulated = re.search(r"\b([A-Z]{1,4}\d{0,2})\b", query)  # e.g., ticker XYZ or XYZ12
    if regulated:
        return "original"

要看清第二个 assert：它只接受字符编码在 32 到 126 之间的可打印 ASCII，中文输入会直接失败。正则也只是识别 1 到 4 个大写字母、后接 0 到 2 个数字，并没有实现注释中提到的 SSN 等完整检测能力。

还有一处分工不能混淆：这个函数只返回策略，不调用外部服务，也不执行护栏。识别出标识符并返回 "original"，并不能证明后续回答已经经过合规检查。

改写能补信息，也可能偷偷改需求

Query Rewriting 的做法，是把用户的简略表达扩展成更适合检索的查询。作者举的例子是「latest mortgage rates」：补充时间范围，可能帮助系统找到更相关的上下文。

收益来自词汇覆盖扩大。用户用一种表达，资料用另一种表达，改写可以增加两者相遇的机会。但补充条件也会改变搜索范围。用户问「today」，系统擅自加上「30-day」，就已经偏离了原始需求。

作者因此给改写设置了前提：没有受监管标识符，Intent Analyzer 判断意图置信度低，而且查询有足够内容可供有意义地扩展。

教学代码用下面的规则代替了真实分析：

    # 3. mock intent confidence (placeholder – real system uses a frozen LLM)
    #    Here we treat the presence of a question mark as a proxy for lower confidence.
    high_confidence = query.count("?") == 0
    if high_confidence:
        return "original"

    # 4. safe rewrite feasibility (e.g., length > 5 words → likely expandable)
    if len(query.split()) > 5:
        return "rewrite"

    # 5. fallback
    return "hyde"

关键是 query.count("?") == 0 和 len(query.split()) > 5：没有问号就算高置信度，有问号且超过 5 个词就选改写，其余进入 HyDE。这些只是占位条件，不能据此判断真实用户的意图，更不能证明一次改写是安全的。

原文提到真实系统使用冻结的 LLM，但没有交代置信度如何计算、阈值如何确定，以及怎样检测改写注入了额外假设。

HyDE 生成的是检索线索，不是事实依据

HyDE 先生成一段假想文档，再用它的向量表示检索真实资料。大白话解释：问题可能很短，但答案通常有更完整的术语和上下文，先模拟一段答案，有机会找到表达相近的文档。

作者认为，这适合法律、医疗、金融科技等领域中的简短事实请求。其决策记录提出了三个条件：意图置信度低、没有受监管标识符，而且原查询检索得到的高分候选不足。

这里存在一个实现缺口：开头流程图把 HyDE 放在「无法安全改写」之后，Python 则把它当作短查询的兜底；两者都没有实现「先检索，再判断高分候选是否足够」。

HyDE 的生成内容只能帮助找证据，不能自己充当证据。

假想文档可能包含虚构事实，因此作者要求依赖护栏，并由人工审计检查护栏处理后的事实错误率。文中还提到冻结模型的单次前向计算，以及无需额外外部调用的早期相关性收益，但没有说明部署方式。无需外部调用，也不等于没有推理成本或延迟。

至于效果，原文提出用 nDCG 等相关性指标与基线比较，却没有给出样本量、具体分数、错误率或耗时。因此，这些更适合作为验收要求，不能当作已经得到充分展示的实验结论。

我的判断

我认可它把保留原文放在优先位置，也认可把相关性、事实错误、延迟和成本放在一起评估。对 RAG 来说，召回更多候选只是中间结果，最终还要看答案是否可靠。

但「能安全改写」是整套方案最关键、也最缺少说明的一环。词数和问号无法承担这项判断。文中的领域检测也很粗，不能直接搬进面向中文用户的系统。

与始终使用原查询相比，分流增加了模型调用和维护工作；与所有问题都改写相比，它有机会减少不必要的处理。究竟哪种更划算，原文没有给出对照数据，目前只能视为作者的设计经验。

维护清单反而更值得借鉴：每次 LoRA 更新后跑稳定验证集，记录各阶段延迟和各策略 token 用量，定期检查意图置信度分布。涉及数值的子查询，还要求核验数据来自 Bloomberg、Federal Reserve 等授权 API。不过，原文没有解释 LoRA 更新哪个模型，以及它与冻结模型之间的关系。

能拿来做什么

• 给现有知识库问答保留一条原查询基线，用同一批真实问题比较改写和 HyDE 的相关性、事实错误与延迟，再决定是否启用。
• 在 Node 检索服务中单独记录策略选择和分阶段耗时，并为标识符检测、置信度分支、改写资格、HyDE 兜底补充单元测试和模拟集成测试。
• 如果产品面向中文用户，先替换 ASCII 校验和按空格计词的规则，再评估意图判断；这两个教学条件会直接影响分流结果。
• 对返回数值或受监管标识符的回答，检查授权 API 来源和护栏执行记录，不要把策略函数返回 "original" 当成校验已经完成。