企业搜索策略Skill enterprise-search-strategy

---

名称: 企业搜索策略 描述: 查询分解和多源搜索协调。将自然语言问题分解为每个源的针对性搜索，将查询翻译成源特定语法，按相关性排名结果，并处理模糊性和后备策略。

搜索策略

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

目标

将这样：

“我们关于API迁移时间线的决定是什么？”

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

~~聊天: “API迁移时间线决定”（语义） + “API迁移” in:#工程 after:2025-01-01
~~知识库: 语义搜索 “API迁移时间线决定”
~~项目跟踪器: 文本搜索 “API迁移” 在相关工作区

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

查询分解

步骤1: 识别查询类型

对用户的问题进行分类以确定搜索策略：

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

步骤2: 提取搜索组件

从查询中提取：

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

步骤3: 生成每个源的子查询

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

优先语义搜索 用于：

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

优先关键词搜索 用于：

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

当主题可能以不同方式引用时，生成多个查询变体：

用户: “Kubernetes设置”
查询: “Kubernetes”, “k8s”, “集群”, “容器编排”

源特定查询翻译

~~聊天

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

查询: “项目aurora的状态是什么？”

关键词搜索：

查询: “项目aurora状态更新”
查询: “aurora in:#工程 after:2025-01-15”
查询: “from:<@用户ID> aurora”

过滤器映射：

过滤器	~~聊天语法
from:sarah	from:sarah 或 from:<@用户ID>
in:engineering	in:工程
after:2025-01-01	after:2025-01-01
before:2025-02-01	before:2025-02-01
type:thread	is:thread
type:file	has:file

~~知识库（维基）

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

描述性查询: “API迁移时间线和决策理由”

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

查询: “API迁移”
查询: “\"API迁移时间线\"”  （确切短语）

~~项目跟踪器

任务搜索：

文本: “API迁移”
工作区: [工作区ID]
完成: false  （用于状态查询）
分配人任何: “我”  （用于“我的任务”查询）

过滤器映射：

过滤器	~~项目跟踪器参数
from:sarah	assignee_any 或 created_by_any
after:2025-01-01	modified_on_after: \"2025-01-01\"
type:milestone	resource_subtype: \"里程碑\"

结果排名

相关性评分

根据这些因素对每个结果评分（按查询类型加权）：

因素	权重（决策）	权重（状态）	权重（文档）	权重（事实）
关键词匹配	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

权威层次

取决于查询类型：

对于事实/政策问题：

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

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

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

对于状态问题：

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

处理模糊性

当查询模糊时，优先提出一个集中的澄清问题而不是猜测：

模糊: “搜索迁移”
→ “我找到了几个迁移的参考。您在寻找：
   1. 数据库迁移（项目凤凰）
   2. 云迁移（AWS → GCP）
   3. 电子邮件迁移（Exchange → O365）”

只在以下情况请求澄清：

• 有真正不同的解释会产生非常不同的结果
• 模糊性会显著影响搜索哪些源

当以下情况时，不要请求澄清：

• 查询足够清晰以产生有用结果
• 轻微模糊性可以通过返回多个解释的结果解决

后备策略

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

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

查询扩展

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

原始: “PostgreSQL迁移Q2时间线决定”
更广泛:  “PostgreSQL迁移”
更广泛:  “数据库迁移”
最广泛: “迁移”

按此顺序移除约束：

1. 日期过滤器（搜索所有时间）
2. 源/位置过滤器
3. 不太重要的关键词
4. 仅保留核心实体/主题术语

并行执行

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

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