search-strategy

搜索策略

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

这是企业搜索背后的核心智能。它将一个自然语言问题转换为并行的、针对特定来源的搜索，并生成排序且去重的结果。

目标

将这个：

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

转换为对每个已连接来源的定向搜索：

~~chat:  "API migration timeline decision" (semantic) + "API migration" in:#engineering after:2025-01-01
~~knowledge base: semantic search "API migration timeline decision"
~~project tracker:  text search "API migration" in relevant workspace

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

查询拆解

第 1 步：识别查询类型

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

查询类型	示例	策略
决策	"我们关于 X 做了什么决定？"	优先搜索对话（~~chat、电子邮件），查找结论信号
状态	"Y 项目的状态如何？"	优先搜索近期活动、任务跟踪器、状态更新
文档	"Z 的规格说明在哪里？"	优先搜索云端硬盘、wiki、共享文档
人员	"谁在负责 X？"	搜索任务分配、消息作者、文档协作者
事实	"我们关于 X 的政策是什么？"	优先搜索 wiki、官方文档，然后是佐证性对话
时间	"X 是什么时候发生的？"	使用宽泛的日期范围搜索，查找时间戳
探索	"关于 X 我们了解哪些情况？"	在所有来源中进行广泛搜索，并加以综合

第 2 步：提取搜索要素

从查询中提取：

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

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

对于每个可用来源，创建一个或多个定向查询：

优先使用语义搜索的场景：

• 概念性问题（"我们对……有什么看法"）
• 不知道确切关键词的问题
• 探索性查询

优先使用关键词搜索的场景：

• 已知术语、项目名称、缩写
• 用户引用的精确短语
• 筛选条件较多的查询（from:、in:、after:）

当同一主题可能有不同说法时，生成多个查询变体：

User: "Kubernetes setup"
Queries: "Kubernetes", "k8s", "cluster", "container orchestration"

特定来源的查询转换

~~chat

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

query: "What is the status of project aurora?"

关键词搜索：

query: "project aurora status update"
query: "aurora in:#engineering after:2025-01-15"
query: "from:<@UserID> aurora"

筛选条件映射：

企业筛选条件	~~chat 语法
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

~~knowledge base（Wiki）

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

descriptive_query: "API migration timeline and decision rationale"

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

query: "API migration"
query: "\"API migration timeline\""  (exact phrase)

~~project tracker

任务搜索：

text: "API migration"
workspace: [workspace_id]
completed: false  (for status queries)
assignee_any: "me"  (for "my tasks" queries)

筛选条件映射：

企业筛选条件	~~project tracker 参数
from:sarah	assignee_any 或 created_by_any
after:2025-01-01	modified_on_after: "2025-01-01"
type:milestone	resource_subtype: "milestone"

结果排序

相关性评分

根据以下因素为每个结果评分（权重因查询类型而异）：

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

权威性层级

取决于查询类型：

针对事实/政策类问题：

Wiki/Official docs > Shared documents > Email announcements > Chat messages

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

Meeting notes > Thread conclusions > Email confirmations > Chat messages

针对状态类问题：

Task tracker > Recent chat > Status docs > Email updates

处理歧义

当查询存在歧义时，优先提出一个有针对性的澄清问题，而不是擅自猜测：

Ambiguous: "search for the migration"
→ "I found references to a few migrations. Are you looking for:
   1. The database migration (Project Phoenix)
   2. The cloud migration (AWS → GCP)
   3. The email migration (Exchange → O365)"

仅在以下情况下才请求澄清：

• 存在确实不同的解读，且会产生非常不同的结果
• 歧义会显著影响应搜索哪些来源

以下情况不要请求澄清：

• 查询已经足够清晰，能够产生有用的结果
• 轻微的歧义可以通过返回多种解读的结果来解决

回退策略

当某个来源不可用或没有返回结果时：

1. 来源不可用：跳过该来源，搜索其余来源，并说明缺失的部分
2. 某来源没有结果：尝试更宽泛的查询词、移除日期过滤条件、尝试替代关键词
3. 所有来源均无结果：向用户建议修改查询
4. 被限流：说明该限制，返回其他来源的结果，并建议稍后重试

查询放宽

如果初始查询返回的结果过少：

Original: "PostgreSQL migration Q2 timeline decision"
Broader:  "PostgreSQL migration"
Broader:  "database migration"
Broadest: "migration"

按以下顺序移除约束条件：

1. 日期过滤条件（搜索全部时间）
2. 来源或地点过滤条件
3. 次要关键词
4. 仅保留核心实体或主题词

并行执行

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

[User query]
     ↓ decompose
[~~chat query] [~~email query] [~~cloud storage query] [Wiki query] [~~project tracker query]
     ↓            ↓            ↓              ↓            ↓
  (parallel execution)
     ↓
[Merge + Rank + Deduplicate]
     ↓
[Synthesized answer]