Query Decomposition Search

name: query-decomposition-search title: 查询分解多源检索 description: 当一句自然语言问题要并行查多个数据源（聊天/知识库/任务/邮件/云盘）并合成一个连贯答案时使用；做的是按查询类型分解出每源子查询、翻译成各源专用语法、并行执行后去重排序，产出排好序的合并结果；不适用于单一已知源的直接检索、或向量+关键词的算法级混排（用 hybrid-search-retrieval）。触发词：多源检索、查询分解、企业搜索、跨源搜索、search orchestration domain: 通用/misc triggers: [多源检索, 查询分解, 企业搜索, 跨源搜索, search orchestration, query decomposition, 并行搜索, 搜索策略] tags: [检索, 查询分解, 多源编排, 企业搜索, 排序, 去重, research] level: 进阶 status: stable agents: [claude-code, codex, cursor, gemini-cli] tools: [] requires: [] related: [hybrid-search-retrieval, fact-checking, entity-research-dossier, rag-pipeline-builder] combines_with: [entity-research-dossier, fact-checking] license: CC-BY-4.0 source: anthropics/knowledge-work-plugins source_license: Apache-2.0

何时使用

当一句自然语言问题需要在多个互不相通的数据源（团队聊天、知识库/Wiki、任务/项目跟踪、邮件、云盘文档）里同时找答案，再把分散结果合成一个连贯回复时使用。典型触发：

• 「我们当时关于 X 是怎么决定的？」「项目 Y 现在什么状态？」「Z 的设计文档在哪？」这类跨工具的内部知识查询。
• 已接入多个连接器，需要把一个问题拆成每源的针对性查询并并行下发。

不该用：

• 只查一个已知源（如就在某个 Wiki 里搜）——直接调该源的搜索，不必走分解编排。
• 算法级混排（同一语料里做向量召回 + 关键词召回 + RRF/重排）——用 hybrid-search-retrieval，本技能管的是「跨源编排」而非「单源召回融合」。
• 开放网络检索 / 实时事实查证——本技能面向内部已接入源；查证真伪用 fact-checking。
• 用户问题已足够明确指向单条结果，分解反而增加噪声。

步骤 / 指令

1. 判定查询类型（决定优先源与排序权重）
   决策类「我们决定了什么」 → 优先 聊天/邮件，找结论性信号（meeting notes、thread 结论）
   状态类「X 进展如何」     → 优先 近期活动、任务跟踪、状态更新
   文档类「X 的文档在哪」   → 优先 云盘、Wiki、共享文档
   人员类「谁在做 X」       → 搜任务负责人、消息作者、文档协作者
   事实/政策类「我们的 X 政策」→ 优先 Wiki/官方文档，再用对话确认
   时间类「X 何时发生」     → 放宽日期范围，找时间戳
   探索类「关于 X 我们都知道什么」→ 全源广撒网，再综合

2. 抽取检索要素
   - 关键词：结果中必须出现的核心词
   - 实体：人/项目/团队/工具（有记忆系统就用）
   - 意图信号：决策词、状态词、时间标记
   - 约束：时间范围、源提示、作者过滤
   - 排除项：要剔除的内容

3. 为每个源生成子查询
   - 概念性/关键词未知/探索类 → 优先语义搜索
   - 已知术语/项目名/缩写/用户引用的精确短语/重过滤(from:/in:/after:) → 优先关键词搜索
   - 同一主题可能有多种叫法时，生成多个变体：
     "Kubernetes" / "k8s" / "cluster" / "container orchestration"

4. 翻译成各源专用语法（见下方映射表）

5. 并行执行所有源的查询（关键：绝不串行）
   总耗时 ≈ 最慢的单源，而非各源之和。

6. 合并 → 按查询类型加权排序 → 去重 → 综合成单一答案

各源语法翻译（要点）

聊天（chat）——语义直接传自然语言问句；关键词支持过滤语法：

知识库（Wiki）——概念查询用 descriptive_query；精确词用 query，加引号即精确短语 "API migration timeline"。

任务/项目跟踪——

text: "API migration"
workspace: [workspace_id]
completed: false        # 状态类查询
assignee_any: "me"      # 「我的任务」

排序：按查询类型加权打分

权威层级随查询类型变化：

• 事实/政策：Wiki/官方文档 > 共享文档 > 邮件公告 > 聊天消息
• 「发生了什么」/决策：会议纪要 > thread 结论 > 邮件确认 > 聊天消息
• 状态：任务跟踪 > 近期聊天 > 状态文档 > 邮件更新

示例

把一个问题分解为多源并行查询：

用户：「我们当时关于 API 迁移时间线是怎么决定的？」  →  判定为【决策类】

聊天：语义 "API migration timeline decision"
      + 关键词 "API migration" in:#engineering after:2025-01-01
知识库：语义 "API migration timeline and decision rationale"
任务跟踪：text "API migration"，相关 workspace
（全部并行下发）
     ↓
合并 + 按决策权重排序（重 thread 结论/会议纪要）+ 去重
     ↓
综合成一段带出处的答案

歧义处理——确有分歧且会显著改变检索方向时，问一个聚焦的澄清问题，而非瞎猜：

模糊：「搜一下那个迁移」
→ 「我找到几个迁移，你指的是：
   1. 数据库迁移（Phoenix 项目）
   2. 云迁移（AWS → GCP）
   3. 邮箱迁移（Exchange → O365）」

查询过窄、结果太少时逐步放宽：

原始：  "PostgreSQL migration Q2 timeline decision"
放宽：  "PostgreSQL migration"
更宽：  "database migration"
最宽：  "migration"

放宽时按此顺序去约束：① 日期过滤（搜全时段）② 源/位置过滤 ③ 次要关键词 ④ 只保留核心实体/主题词。

注意事项

• 并行是硬要求：所有源同时下发，绝不串行；否则延迟累加，体验崩坏。
• 先判类型再分解：查询类型决定优先源、各源该用语义还是关键词、以及排序权重——跳过这步排序会失准。
• 语义 vs 关键词不是二选一：同一源可并发两种查询（自然语言语义 + 带过滤的关键词），取并集再去重。
• 澄清要克制：只在「确有多种迥异解读且会显著改变搜哪些源」时问；轻微歧义直接多解返回，别打断用户。
• 降级与兜底：源不可用→跳过并标注缺口；某源零结果→放宽词、去日期过滤、换近义词；全源皆空→建议用户改写查询；被限流→标注、返回其他源结果、提示稍后重试。
• 去重：同一结论可能被多源/转发命中，合并阶段按内容（非链接）去重，避免同一事实重复计权。
• 占位符 ~~chat/~~project tracker 等代表「已接入的某类连接器」，落地时替换为实际工具名。

互见

• related：hybrid-search-retrieval —— 本技能管「跨源编排」，单源内部的向量+关键词召回融合（RRF/重排）下钻到它。
• related：fact-checking —— 检索合成出结论后，对关键断言做二次查证、辨真伪。
• combines_with：entity-research-dossier —— 把多源检索作为调研档案的取证引擎，按实体并行拉取一手内部资料。
• related：rag-pipeline-builder —— 当检索结果要喂给生成式回答时，衔接到 RAG 管道的召回阶段。

采编自 anthropics/knowledge-work-plugins（Apache-2.0 许可证），原技能 search-strategy（enterprise-search 插件）。本条为适配中文「技能大典」的重写版，保留其查询类型→策略映射、检索要素抽取、各源语法/过滤翻译表、按类型加权的排序与权威层级、歧义澄清判据、降级/查询放宽顺序与并行执行约束等关键内容。