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

知识合成

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

目标

将此：

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

转化为此：

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

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

去重

跨源去重

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

表示结果涉及相同内容的信号：

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

如何合并：

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

去重优先级

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

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

不去重的情况

当以下情况时，保持为单独项：

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

引用和源归属

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

归属格式

直接引用时内联：

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

结尾处列出源列表以完整：

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

归属规则

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

置信度级别

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

新鲜度

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

对于状态查询，高度重视新鲜度。对于政策/事实查询，新鲜度重要性较低。

权威性

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

表达置信度

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

团队决定在API重设计中使用REST。[直接声明]

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

根据上月在#engineering中的讨论，团队倾向于在API重设计中使用REST。此后可能已演变。

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

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

冲突信息

当来源不一致时：

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

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

总是表面冲突，而非静默选择一种版本。

总结策略

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

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

[基于结果合成的直接答案]

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

来源：[完整归属]

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

按主题分组并总结每组：

[整体答案]

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

关键来源：[3-5个最相关来源]
完整结果：在[来源]中找到[计数]个项目

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

提供高级别合成，并可选深入探索：

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

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

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

在[来源列表]中找到[总计数]个结果。
是否要我深入任何特定方面？

总结规则

以答案开头，而非搜索过程
不列出原始结果—将其合成为叙述
将不同来源的相关项分组
保留重要细微差别和警告
包括足够细节，以便用户决定是否深入
当结果集大时，总是提供更多细节

合成工作流程

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

反模式

不要：

逐个来源列出结果（“从~~聊天：… 从~~邮件：… 从~~云存储：…”）
仅因匹配关键词而包含不相关结果
在方法解释下埋没答案
呈现冲突信息而不标记冲突
省略源归属
以与有充分支持的事实相同置信度呈现不确定信息
总结过于激进，导致有用细节丢失

要：

以答案开头
按主题分组，而非按来源
当适当时标记置信度级别
明确表面冲突
将所有声明归属到来源
当结果集大时，提供深入探索