name: 搜索策略 description: 查询分解和多源搜索协调。将自然语言问题分解为针对每个源的针对性搜索，将查询转换为源特定语法，按相关性排名结果，并处理歧义和备用策略。

搜索策略

如果您看到不熟悉的占位符或需要检查连接的工具，请参阅CONNECTORS.md。

企业搜索背后的核心智能。将单个自然语言问题转换为并行、特定源的搜索，并产生排名、去重的结果。

目标

将此：

"What did we decide about the API migration timeline?"

转换为每个连接源的针对性搜索：

~~聊天:  "API migration timeline decision" (语义) + "API migration" in:#engineering after:2025-01-01
~~知识库: 语义搜索 "API migration timeline decision"
~~项目跟踪器:  文本搜索 "API migration" 在相关工作区

然后将结果综合成一个单一的连贯答案。

查询分解

步骤1：识别查询类型

分类用户问题以确定搜索策略：

查询类型	示例	策略
决策	“我们关于X的决定是什么？”	优先对话（~~聊天，邮件），寻找结论信号
状态	“项目Y的状态是什么？”	优先最近活动、任务跟踪器、状态更新
文档	“Z的规范在哪里？”	优先驱动器、维基、共享文档
人员	“谁在负责X？”	搜索任务分配、消息作者、文档协作者
事实性	“我们关于X的政策是什么？”	优先维基、官方文档，然后确认性对话
时间性	“X什么时候发生的？”	搜索广泛日期范围，寻找时间戳
探索性	“我们关于X知道什么？”	跨所有源的广泛搜索，综合

步骤2：提取搜索组件

从查询中提取：

关键词：必须在结果中出现的核心术语
实体：人员、项目、团队、工具（如果可用，使用记忆系统）
意图信号：决策词、状态词、时间标记
约束：时间范围、源提示、作者过滤器
否定：要排除的事物

步骤3：为每个源生成子查询

对于每个可用源，创建一个或多个针对性查询：

优先语义搜索对于：

概念性问题（“我们关于…的想法是什么？”）
确切关键词未知的问题
探索性查询

优先关键词搜索对于：

已知术语、项目名称、缩写
用户引用的确切短语
过滤器重的查询（from:, in:, after:）

生成多个查询变体当主题可能有不同引用时：

用户："Kubernetes setup"
查询："Kubernetes", "k8s", "cluster", "container orchestration"

源特定查询翻译

~~聊天

语义搜索（自然语言问题）：

查询："项目aurora的状态是什么？"

关键词搜索：

查询："项目aurora状态更新"
查询："aurora in:#engineering after:2025-01-15"
查询："from:<@UserID> aurora"

过滤器映射：

企业过滤器	~~聊天语法
`from:sarah`	`from:sarah` 或 `from:<@USERID>`
`in:engineering`	`in:engineering`
`after:2025-01-01`	`after:2025-01-01`
`before:2025-02-01`	`before:2025-02-01`
`type:thread`	`is:thread`
`type:file`	`has:file`

~~知识库（维基）

语义搜索 — 用于概念查询：

descriptive_query: "API migration timeline and decision rationale"

关键词搜索 — 用于确切术语：

查询："API migration"
查询："\"API migration timeline\""  （确切短语）

~~项目跟踪器

任务搜索：

文本："API migration"
工作区：[workspace_id]
完成：false  （用于状态查询）
assignee_any: "me"  （用于"我的任务"查询）

过滤器映射：

企业过滤器	~~项目跟踪器参数
`from:sarah`	`assignee_any` 或 `created_by_any`
`after:2025-01-01`	`modified_on_after: "2025-01-01"`
`type:milestone`	`resource_subtype: "milestone"`

结果排名

权威层次结构

取决于查询类型：

对于事实性/政策问题：

维基/官方文档 > 共享文档 > 邮件公告 > 聊天消息

对于"发生了什么" / 决策问题：

会议记录 > 线程结论 > 邮件确认 > 聊天消息

对于状态问题：

任务跟踪器 > 最近聊天 > 状态文档 > 邮件更新

处理歧义

当查询歧义时，优先问一个聚焦的澄清问题而不是猜测：

歧义："search for the migration"
→ "我找到了一些迁移的参考。您在寻找：
   1. 数据库迁移（项目凤凰）
   2. 云迁移（AWS → GCP）
   3. 邮件迁移（Exchange → O365）"

仅在以下情况询问澄清：

有真正不同的解释，会产生非常不同的结果
歧义会显著影响搜索哪些源

不要在以下情况询问澄清：

查询足够清晰以产生有用结果
次要歧义可以通过返回多个解释的结果来解决

备用策略

当源不可用或返回无结果时：

源不可用：跳过它，搜索剩余源，注意差距
无结果来自源：尝试更广泛的查询词，移除日期过滤器，尝试替代关键词
所有源返回无结果：建议用户修改查询
速率限制：注意限制，从其他源返回结果，建议稍后重试

查询扩宽

如果初始查询返回太少结果：

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

按此顺序移除约束：

日期过滤器（搜索所有时间）
源/位置过滤器
不那么重要的关键词
只保留核心实体/主题术语

并行执行

始终跨源并行执行搜索，不要顺序执行。总搜索时间应大致等于最慢单个源的时间，而不是所有源的总和。

[用户查询]
     ↓ 分解
[~~聊天查询] [~~邮件查询] [~~云存储查询] [维基查询] [~~项目跟踪器查询]
     ↓            ↓            ↓              ↓            ↓
  （并行执行）
     ↓
[合并 + 排名 + 去重]
     ↓
[综合答案]

因素	权重（决策）	权重（状态）	权重（文档）	权重（事实性）
关键词匹配	0.3	0.2	0.4	0.3
新鲜度	0.3	0.4	0.2	0.1
权威性	0.2	0.1	0.3	0.4
完整性	0.2	0.3	0.1	0.2

搜索策略Skill search-strategy