搜索策略

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

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

目标

将这样：

"关于 API 迁移时间表，我们决定了什么？"

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

~~chat： "API 迁移时间表决策"（语义搜索）+ "API 迁移" in:#engineering after:2025-01-01
~~knowledge base： 语义搜索 "API 迁移时间表决策"
~~project tracker： 文本搜索 "API 迁移" 在相关工作区中

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

查询分解

步骤 1：识别查询类型

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

查询类型	示例	策略
决策	"关于 X 我们决定了什么？"	优先搜索对话（~~chat、email），寻找结论信号
状态	"项目 Y 的状态如何？"	优先搜索近期活动、任务跟踪器、状态更新
文档	"Z 的规格说明在哪里？"	优先搜索云存储、维基、共享文档
人员	"谁在负责 X？"	搜索任务分配、消息作者、文档协作者
事实	"我们在 X 方面的政策是什么？"	优先搜索维基、官方文档，然后确认性对话
时间	"X 是什么时候发生的？"	使用宽泛日期范围搜索，查找时间戳
探索	"关于 X 我们知道什么？"	在所有来源中广泛搜索，综合结果

步骤 2：提取搜索组件

从查询中提取：

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

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

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

优先使用语义搜索 的情况：

概念性问题（"关于……我们怎么看"）
精确关键词未知的问题
探索性查询

优先使用关键词搜索 的情况：

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

生成多个查询变体 的情况，当主题可能有不同的表述方式：

用户："Kubernetes 配置"
查询："Kubernetes"、"k8s"、"cluster"、"容器编排"

特定来源的查询翻译

~~chat

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

query："项目 aurora 的进展情况如何？"

关键词搜索：

query："项目 aurora 状态更新"
query："aurora in:#engineering after:2025-01-15"
query："from:<@用户ID> aurora"

筛选条件映射： | 企业搜索筛选条件 | ~~chat 语法 | |------------------|--------------| | from:sarah | from:sarah 或 from:<@用户ID> | | 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（维基）

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

descriptive_query："API 迁移时间线和决策理由"

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

query："API 迁移"
query："\"API 迁移时间线\""（精确短语）

~~project tracker

任务搜索：

text："API 迁移"
workspace：[工作区 ID]
completed：false（用于状态查询）
assignee_any："me"（用于"我的任务"查询）

筛选条件映射： | 企业搜索筛选条件 | ~~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

权威性层级

取决于查询类型：

对于事实/政策问题：

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

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

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

对于状态问题：

任务跟踪器 &gt; 近期聊天 &gt; 状态文档 &gt; 邮件更新

处理歧义

当查询存在歧义时，优先提出一个集中的澄清问题，而非猜测：

模糊："搜索迁移相关"
→ "我找到了几个迁移相关的引用。您是在寻找：
   1. 数据库迁移（Project Phoenix）
   2. 云迁移（AWS → GCP）
   3. 邮件迁移（Exchange → O365）"

仅在以下情况下询问澄清：

确实存在会产生截然不同结果的多种解释
歧义会显著影响需要搜索哪些来源

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

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

降级策略

当来源不可用或无结果时：

来源不可用：跳过它，搜索剩余来源，注明缺失
来源无结果：尝试更广泛的查询词，移除日期筛选，尝试备选关键词
所有来源均无结果：建议用户修改查询
遇到速率限制：注明限制，从其他来源返回结果，建议稍后重试

查询扩展

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

原始："PostgreSQL 迁移 Q2 时间线决策"
更宽泛："PostgreSQL 迁移"
更宽泛："数据库迁移"
最宽泛："迁移"

按此顺序移除约束条件：

日期筛选（搜索所有时间）
来源/位置筛选
不太重要的关键词
仅保留核心实体/主题词

并行执行

始终跨来源并行执行搜索，绝不串行执行。总搜索时间大致等于最慢的单个来源的时间，而非所有来源之和。

[用户查询]
     ↓ 分解
[~~chat 查询] [~~email 查询] [~~cloud storage 查询] [维基查询] [~~project tracker 查询]
     ↓            ↓            ↓              ↓            ↓
  (并行执行)
     ↓
[合并 + 排名 + 去重]
     ↓
[综合答案]