name: 企业搜索知识综合 description: 从多个来源结合搜索结果，生成连贯、去重的答案，并附带来源标注。基于新鲜度和权威性处理置信度评分，并有效总结大型结果集。

知识综合

Tandem搜索的最后一英里。从多个来源获取原始结果，生成连贯、可信的答案。

目标

将以下内容：

~~chat result: "Sarah said in #eng: 'let's go with REST, GraphQL is overkill for our use case'"
~~email result: "Subject: API Decision — Sarah's email confirming REST approach with rationale"
~~cloud storage result: "API Design Doc v3 — updated section 2 to reflect REST decision"
~~project tracker result: "Task: Finalize API approach — marked complete by Sarah"

转化为：

团队决定在API重新设计中使用REST而非GraphQL。Sarah做出了这个决定，指出GraphQL对于当前用例过于复杂。这已在周二在#engineering中讨论过，周三通过电子邮件确认，并且设计文档已更新以反映此决定。相关的~~project tracker任务已标记完成。

来源：
- ~~chat: #engineering线程（1月14日）
- ~~email: "API Decision"来自Sarah（1月15日）
- ~~cloud storage: "API Design Doc v3"（更新于1月15日）
- ~~project tracker: "Finalize API approach"（完成于1月15日）

去重

跨源去重

相同信息通常出现在多个地方。识别并合并重复项：

表示结果是关于同一事物的信号：

相同或非常相似的文本内容
相同作者/发件人
时间戳在短时间内（同一天或相邻几天）
引用相同实体（项目名称、文档、决策）
一个来源引用另一个（“如~~chat中讨论”、“根据电子邮件”、“参见文档”）

如何合并：

合并为单个叙事项
引用所有出现来源
使用最完整版本作为主要文本
添加每个来源的独特细节

去重优先级

当相同信息存在于多个来源时，优先选择：

1. 最完整版本（最全上下文）
2. 最权威来源（官方文档 > 聊天）
3. 最新版本（最新更新获胜用于演变信息）

不进行去重的情况

保持为独立项当：

同一主题讨论但结论不同
不同人表达不同观点
信息在来源间有意义地演变（决策的v1与v2）
表示不同时间段

引用和来源标注

综合答案中的每个声明都必须可归因于一个来源。

标注格式

直接引用的行内标注：

Sarah在她的电子邮件中确认了REST方法。
设计文档已更新以反映这一点（~~cloud storage: "API Design Doc v3"）。

末尾的来源列表用于完整性：

来源：
- ~~chat: #engineering讨论（1月14日） — 初始决策线程
- ~~email: "API Decision"来自Sarah Chen（1月15日） — 正式确认
- ~~cloud storage: "API Design Doc v3"最后修改于1月15日 — 更新规范

标注规则

始终命名来源类型（~~chat、~~email、~~cloud storage等）
包括具体位置（频道、文件夹、线程）
包括日期或相对时间
包括作者（如相关）
包括文档/线程标题（如可用）
对于~~chat，注明频道名称
对于~~email，注明主题行和发件人
对于~~cloud storage，注明文档标题

置信度级别

并非所有结果都同样可信。基于以下评估置信度：

新鲜度

新近性	置信度影响
今天/昨天	高置信度用于当前状态
本周	良好置信度
本月	中等 — 可能已更改
超过一个月	较低置信度 — 标记为可能过时

对于状态查询，重度加权新鲜度。对于政策/事实查询，新鲜度较不重要。

权威性

来源类型	权威级别
官方维基/知识库	最高 — 策划、维护
共享文档（最终版本）	高 — 有意发布
电子邮件公告	高 — 正式沟通
会议笔记	中高 — 可能不完整
聊天消息（线程结论）	中等 — 非正式但实时
聊天消息（中间线程）	较低 — 可能未反映最终立场
草稿文档	低 — 未最终定稿
任务评论	上下文相关 — 取决于评论者

表达置信度

当置信度高（多个新鲜、权威来源一致时）：

团队决定使用REST进行API重新设计。[直接声明]

当置信度中等（单一来源或有些过时）：

根据上个月在#engineering的讨论，团队倾向于REST进行API重新设计。这可能自那时以来已演变。

当置信度低（旧数据、非正式来源或冲突信号时）：

我找到了三个月前在~~chat中关于API迁移讨论的参考，但未找到正式决策文档。信息可能已过时。您可能想向团队查询当前状态。

冲突信息

当来源不一致时：

我发现关于API方法的冲突信息：
- ~~chat讨论于1月10日建议GraphQL
- 但Sarah的电子邮件于1月15日确认REST
- 设计文档（更新于1月15日）反映REST

最新来源表明REST是最终决策，但早期的~~chat讨论首先探讨了GraphQL。

始终表面冲突，而不是默默选择一种版本。

总结策略

对于小结果集（1-5个结果）

呈现每个结果及其上下文。无需总结 — 给用户所有内容：

[从结果中综合的直接答案]

[来源1的细节]
[来源2的细节]

来源：[完整标注]

对于中等结果集（5-15个结果）

按主题分组并总结每组：

[整体答案]

主题1：[相关结果总结]
主题2：[相关结果总结]

关键来源：[前3-5个最相关来源]
完整结果：[计数]个项目跨越[来源]

对于大结果集（15+个结果）

提供高层综合并可选深入挖掘：

[基于最相关结果的整体答案]

总结：
- [关键发现1]（由N个来源支持）
- [关键发现2]（由N个来源支持）
- [关键发现3]（由N个来源支持）

顶部来源：
- [最权威/相关来源]
- [第二最相关]
- [第三最相关]

找到[总计数]个结果跨越[来源列表]。
要我深入任何特定方面吗？

总结规则

以答案开头，而不是搜索过程
不列出原始结果 — 将它们综合为叙事
将不同来源的相关项目分组在一起
保留重要细微差别和注意事项
包含足够细节，以便用户决定是否深入挖掘
如果结果集大，始终提供更多细节

综合工作流

[来自所有来源的原始结果]
          ↓
[1. 去重 — 合并来自不同来源的相同信息]
          ↓
[2. 聚类 — 按主题/主题分组相关结果]
          ↓
[3. 排名 — 按查询相关性排序聚类和项目]
          ↓
[4. 评估置信度 — 新鲜度 × 权威性 × 一致性]
          ↓
[5. 综合 — 生成带标注的叙事答案]
          ↓
[6. 格式化 — 根据结果数量选择适当细节级别]
          ↓
[连贯答案带来源]

反模式

不要：

按来源列出结果（“来自~~chat：… 来自~~email：… 来自~~cloud storage：…”）
仅因匹配关键字而包含不相关结果
将答案埋于方法解释之下
呈现冲突信息而不标记冲突
省略来源标注
以相同置信度呈现不确定信息与良好支持事实
总结过于激进，以至于有用细节丢失

要：

以答案开头
按主题分组，而不是来源
适当时标记置信度级别
明确表面冲突
将所有声明归因于来源
当结果集大时，提供深入挖掘选项