name: 企业知识合成 description: 将来自多个源的搜索结果结合成连贯、去重且带有来源归因的答案。

知识合成

企业搜索的最后一步。从多个源获取原始结果，并生成连贯、可信的答案。

目标

将此：

~~聊天结果: "Sarah 在 #eng 中说：'让我们使用 REST，GraphQL 对于我们的用例来说过于复杂'"
~~邮件结果: "主题: API 决策 — Sarah 的邮件确认 REST 方法并附有理由"
~~云存储结果: "API 设计文档 v3 — 更新第 2 部分以反映 REST 决策"
~~项目跟踪结果: "任务: 最终确定 API 方法 — 由 Sarah 标记完成"

转换为此：

团队决定在 API 重新设计中使用 REST 而不是 GraphQL。Sarah 做出了这个
决定，指出 GraphQL 对于当前用例来说过于复杂。这已在
#engineering 频道在周二讨论，周三通过邮件确认，并且设计文档已经
更新以反映这个决定。相关的 ~~项目跟踪任务已标记完成。

来源：
- ~~聊天: #engineering 线程 (1 月 14 日)
- ~~邮件: "API 决策" 来自 Sarah (1 月 15 日)
- ~~云存储: "API 设计文档 v3" (更新于 1 月 15 日)
- ~~项目跟踪: "最终确定 API 方法" (完成于 1 月 15 日)

去重

跨源去重

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

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

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

如何合并：

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

去重优先级

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

1. 最完整的版本（最全面的上下文）
2. 最权威的源（官方文档 > 聊天）
3. 最新版本（对于演进信息，最新更新胜出）

什么不去重

在以下情况保持为单独项：

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

引用和来源归因

合成答案中的每个声明必须可追溯到源。

归因格式

直接引用的内联：

Sarah 在周三的邮件中确认了 REST 方法。
设计文档已更新以反映这一点（~~云存储: "API 设计文档 v3"）。

末尾的源列表以保持完整性：

来源：
- ~~聊天: #engineering 讨论 (1 月 14 日) — 初始决策线程
- ~~邮件: "API 决策" 来自 Sarah Chen (1 月 15 日) — 正式确认
- ~~云存储: "API 设计文档 v3" 最后修改于 1 月 15 日 — 更新规范

归因规则

始终命名源类型（~~聊天、~~邮件、~~云存储等）
包括具体位置（频道、文件夹、线程）
包括日期或相对时间
包括相关作者
包括文档/线程标题（如果可用）
对于 ~~聊天，注意频道名称
对于 ~~邮件，注意主题行和发送者
对于 ~~云存储，注意文档标题