第1条：根据用户问题用向量化给提示词提供少量样例

将用户问题向量化后，从知识库/历史问答库中检索出最相似的几个（比如3-5个）“样例”（问题-答案对），然后把这些样例放进提示词中，供大模型参考回答方式。

• 可拓展的方向：

  • 动态样例选择：不仅按相似度取Top-K，还可以考虑样例的多样性（避免样例过于雷同）。

  • 样例质量过滤：低质量或错误的答案样例不要喂给模型，可以先做置信度打分。

  • 样例与指令融合：在提示词中明确告诉模型“请参考以下样例的回答风格和结构”，比单纯罗列样例效果更好。

第2条：将问题内容补全召回

用户问题往往简短、模糊或缺上下文（如“那第二个呢？”“它的价格呢？”），直接检索效果很差。“补全”是指：结合对话历史、用户画像、或业务规则，把问题改写成完整且自包含的查询语句，然后再去做召回。

• 可拓展的方向：

  • 指代消解：如“它”“那个方法” → 替换成具体的实体名。

  • 省略补全：如“那苹果呢？” → “苹果公司的股价现在是多少？”（如果上一轮在问股价）。

  • 意图驱动的补全：如果识别出用户是想对比产品，补全成“产品A vs 产品B 的性能参数对比”。

  • 基于知识图谱的补全：如果问题中实体缺失属性，自动补上该实体常见查询维度（如“北京” → “北京的天气”）。

第3条：将用户问题转成多个问题召回

同一个用户问题的语义空间可能很广，转成多个不同侧重点或不同表述的问题，可以提升召回的相关文档覆盖度。

• 可拓展的方向：

  • 同义改写：用大模型或同义词词典把问题改写3-5个语义相近但措辞不同的版本。

  • 抽象与具体：一个版本保留原细节，另一个版本去细节化（利于召回更通用的知识）。

  • 反向提问：如果原问题是“A为什么导致B”，可扩展出“B的常见原因有哪些”。

  • 多语言/多领域改写：适用于跨语种或跨专业术语的知识库。

第4条：复杂问题拆分多个问题逐一召回

这是处理多跳问题（Multi-hop QA）和组合问题的标准做法。比如“比较A和B的优点，并告诉我哪个更省电” → 拆成“A的优点”“B的优点”“A的功耗”“B的功耗”“A和B谁更省电”。

• 可拓展的方向：

  • 依赖关系管理：有些子问题之间有顺序依赖（如先问“A在哪年发布”，再问“那年同期的竞品是谁”）。需要按DAG顺序执行。

  • 冗余去重：不同子问题可能召回相同文档，要合并去重。

  • 答案融合：拆完之后还要把多个召回结果整合成一个连贯的回答，而不是罗列子答案。可以设计一个“聚合提示词”，或者用另一个模型做总结。

  • 动态拆解：让模型先判断是否“有必要拆分”，避免过度拆分简单问题（浪费算力且可能引入噪声）。

下面是一个用 Mermaid 绘制的流程图，它把你提到的 4 个策略整合成一个统一的问答处理流程：

flowchart TD
    A[用户原始问题] --> B[第2条：问题内容补全<br>（指代消解 / 上下文补齐）]
    B --> C[第4条：问题拆分<br>复杂问题 → 多个子问题<br>简单问题 → 1个子问题]
    C --> D[得到子问题列表]
    D --> E[遍历每个子问题]

    E --> F[第3条：多查询召回<br>（同义改写 / 多视角生成多个查询）]
    F --> G[向量检索<br>每个查询独立召回，合并去重]
    G --> H[第1条：基于问题向量化<br>检索少量 Few-shot 样例]
    H --> I[构建提示词<br>（样例 + 召回文档 + 问题）]
    I --> J[调用大模型生成子答案]

    J --> K{是否还有子问题？}
    K -- 是 --> E
    K -- 否 --> L[合并所有子问题答案]
    L --> M[最终回答]

流程简要说明

1. 补全（第2条）→ 把用户原始问题改写成完整、自包含的问题。

2. 拆分（第4条）→ 如果是简单问题，会得到一个“伪子问题”（即原问题本身）；如果是复杂问题，拆成多个真正需要分别召回的子问题。

3. 多查询召回（第3条）→ 对每个子问题生成多个同义/多角度查询，并行召回，合并文档。

4. 样例检索（第1条）→ 用子问题向量检索几个高质量的历史问答对，作为大模型的 Few-shot 示例。

5. 生成与合并→ 依次生成每个子问题的答案，最后合并输出最终回答。