knowledge-synthesis
把多來源搜尋結果整合成去重、標出處、附信心等級的答案
中文翻譯
---
name: knowledge-synthesis
description: 把多個來源的搜尋結果整合成連貫、去除重複、標明出處的答案。依新鮮度和權威性給出信心評分，並有效摘要大量結果。
user-invocable: false
---
# Knowledge Synthesis
企業搜尋的最後一哩路。拿多個來源的原始結果，產出連貫、可信的答案。
## 目標
把這個：
```
~~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
討論過，週三用 email 確認，設計文件也已經更新來反映這個決定。相關的 ~~project tracker 任務已標為完成。
Sources:
- ~~chat: #engineering thread (Jan 14)
- ~~email: "API Decision" from Sarah (Jan 15)
- ~~cloud storage: "API Design Doc v3" (updated Jan 15)
- ~~project tracker: "Finalize API approach" (completed Jan 15)
```
## 去除重複
### 跨來源去重
同樣的資訊常常出現在多個地方。要辨識並合併重複：
**代表結果在講同一件事的訊號：**
- 相同或非常相似的文字內容
- 相同的作者/寄件者
- 時間戳落在短時間內（同一天或相鄰的日子）
- 提到同一個實體（專案名稱、文件、決定）
- 一個來源引用另一個來源（「as discussed in ~~chat」、「per the email」、「see the doc」）
**怎麼合併：**
- 合併成單一敘述項目
- 引用它出現過的所有來源
- 以最完整的版本當主要文字
- 加上每個來源獨有的細節
### 去重的優先順序
同樣的資訊存在於多個來源時，優先選：
```
1. 最完整的版本（脈絡最齊全）
2. 最權威的來源（正式文件 > 聊天）
3. 最新的版本（持續演變的資訊以最新更新為準）
```
### 不該去重的情況
下列情況要保留成獨立項目：
- 討論同一個主題，但結論不同
- 不同的人表達不同的觀點
- 資訊在各來源之間有實質演變（決定的 v1 對比 v2）
- 代表不同的時間段
## 引用與來源標註
整合後的答案裡，每一個主張都必須能追溯到來源。
### 標註格式
直接引用時用行內標註：
```
Sarah 在週三的 email 裡確認了 REST 的做法。
設計文件也已更新來反映這點（~~cloud storage: "API Design Doc v3"）。
```
最後附來源清單，求完整：
```
Sources:
- ~~chat: #engineering discussion (Jan 14) — initial decision thread
- ~~email: "API Decision" from Sarah Chen (Jan 15) — formal confirmation
- ~~cloud storage: "API Design Doc v3" last modified Jan 15 — updated specification
```
### 標註規則
- 一定要寫出來源類型（~~chat、~~email、~~cloud storage 等）
- 要寫出具體位置（頻道、資料夾、討論串）
- 要寫出日期或相對時間
- 相關時要寫出作者
- 有的話要寫出文件或討論串的標題
- ~~chat 要註明頻道名稱
- ~~email 要註明主旨和寄件者
- ~~cloud storage 要註明文件標題
## 信心等級
不是所有結果都一樣可信。依下列因素評估信心：
### 新鮮度
| 時間 | 對信心的影響 |
|---------|------------------|
| 今天 / 昨天 | 對現況的信心高 |
| 本週 | 信心不錯 |
| 本月 | 中等，事情可能已經變了 |
| 超過一個月 | 信心較低，標記為可能已過時 |
狀態類的查詢，要重重加權新鮮度。政策或事實類的查詢，新鮮度比較沒那麼重要。
### 權威性
| 來源類型 | 權威等級 |
|-------------|----------------|
| 正式 wiki / 知識庫 | 最高：有人策展、有人維護 |
| 共用文件（最終版） | 高：刻意發布的 |
| Email 公告 | 高：正式溝通 |
| 會議記錄 | 中高：可能不完整 |
| 聊天訊息（討論串的結論） | 中：不正式，但是即時的 |
| 聊天訊息（討論串進行中） | 較低：可能不代表最終立場 |
| 草稿文件 | 低：尚未定稿 |
| 任務留言 | 看情況：取決於留言者 |
### 表達信心
信心高時（多個新鮮且權威的來源一致）：
```
團隊決定 API 改版用 REST。[直接陳述]
```
信心中等時（單一來源，或有點舊）：
```
根據上個月在 #engineering 的討論，團隊傾向於
API 改版用 REST。從那之後可能已經有變化。
```
信心低時（資料舊、來源不正式，或訊號互相矛盾）：
```
我在 ~~chat 找到三個月前一段關於 API 遷移的討論，
但找不到正式的決定文件。這份資訊
可能已經過時。你可能想跟團隊確認目前的狀況。
```
### 矛盾的資訊
來源互相矛盾時：
```
我找到關於 API 做法互相矛盾的資訊：
- 1 月 10 日 ~~chat 的討論傾向 GraphQL
- 但 Sarah 在 1 月 15 日的 email 確認了 REST
- 設計文件（1 月 15 日更新）反映的是 REST
最新的來源顯示最終決定是 REST，
但較早的 ~~chat 討論一開始探討的是 GraphQL。
```
一定要把矛盾攤出來，不要默默挑一個版本。
## 摘要策略
### 結果少的時候（1 到 5 筆）
每筆結果連同脈絡一起呈現。不需要摘要，把全部都給使用者：
```
[從結果整合出來的直接答案]
[來源 1 的細節]
[來源 2 的細節]
Sources: [完整標註]
```
### 結果中等的時候（5 到 15 筆）
依主題分組，並摘要每一組：
```
[整體答案]
主題 1：[相關結果的摘要]
主題 2：[相關結果的摘要]
Key sources: [最相關的前 3 到 5 個來源]
Full results: 在 [來源] 共找到 [數量] 筆
```
### 結果很多的時候（15 筆以上）
提供高層次的整合，並讓人可以再往下挖：
```
[根據最相關結果得出的整體答案]
Summary:
- [重點發現 1]（有 N 個來源支持）
- [重點發現 2]（有 N 個來源支持）
- [重點發現 3]（有 N 個來源支持）
Top sources:
- [最權威/最相關的來源]
- [第二相關的]
- [第三相關的]
在 [來源清單] 共找到 [總數] 筆結果。
要我深入看哪個特定面向嗎？
```
### 摘要規則
- 先講答案，不是搜尋過程
- 不要列出原始結果，要把它們整合成敘述
- 把來自不同來源的相關項目放在一起
- 保留重要的細微差異和但書
- 給足夠的細節，讓使用者能決定要不要再深入
- 結果很多時，一定要提議提供更多細節
## 整合工作流程
```
[所有來源的原始結果]
↓
[1. 去重：合併不同來源的相同資訊]
↓
[2. 分群：依主題把相關結果分組]
↓
[3. 排序：依與查詢的相關性排列各群與各項目]
↓
[4. 評估信心：新鮮度 × 權威性 × 一致性]
↓
[5. 整合：產出附標註的敘述性答案]
↓
[6. 格式化：依結果數量選擇適當的細節程度]
↓
[附來源的連貫答案]
```
## 反模式
**不要：**
- 一個來源一個來源地列結果（「From ~~chat: ... From ~~email: ... From ~~cloud storage: ...」）
- 只因為符合某個關鍵字就放進不相關的結果
- 把答案埋在方法論說明底下
- 呈現互相矛盾的資訊卻沒標示矛盾
- 省略來源標註
- 用跟有充分佐證的事實一樣的信心，呈現不確定的資訊
- 摘要得太狠，把有用的細節都丟了
**要：**
- 先講答案
- 依主題分組，不是依來源
- 適當時標示信心等級
- 明確攤出矛盾
- 每個主張都標明來源
- 結果很多時，提議再深入英文原文
---
name: knowledge-synthesis
description: Combines search results from multiple sources into coherent, deduplicated answers with source attribution. Handles confidence scoring based on freshness and authority, and summarizes large result sets effectively.
user-invocable: false
---
# Knowledge Synthesis
The last mile of enterprise search. Takes raw results from multiple sources and produces a coherent, trustworthy answer.
## The Goal
Transform this:
```
~~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"
```
Into this:
```
The team decided to go with REST over GraphQL for the API redesign. Sarah made the
call, noting that GraphQL was overkill for the current use case. This was discussed
in #engineering on Tuesday, confirmed via email Wednesday, and the design doc has
been updated to reflect the decision. The related ~~project tracker task is marked complete.
Sources:
- ~~chat: #engineering thread (Jan 14)
- ~~email: "API Decision" from Sarah (Jan 15)
- ~~cloud storage: "API Design Doc v3" (updated Jan 15)
- ~~project tracker: "Finalize API approach" (completed Jan 15)
```
## Deduplication
### Cross-Source Deduplication
The same information often appears in multiple places. Identify and merge duplicates:
**Signals that results are about the same thing:**
- Same or very similar text content
- Same author/sender
- Timestamps within a short window (same day or adjacent days)
- References to the same entity (project name, document, decision)
- One source references another ("as discussed in ~~chat", "per the email", "see the doc")
**How to merge:**
- Combine into a single narrative item
- Cite all sources where it appeared
- Use the most complete version as the primary text
- Add unique details from each source
### Deduplication Priority
When the same information exists in multiple sources, prefer:
```
1. The most complete version (fullest context)
2. The most authoritative source (official doc > chat)
3. The most recent version (latest update wins for evolving info)
```
### What NOT to Deduplicate
Keep as separate items when:
- The same topic is discussed but with different conclusions
- Different people express different viewpoints
- The information evolved meaningfully between sources (v1 vs v2 of a decision)
- Different time periods are represented
## Citation and Source Attribution
Every claim in the synthesized answer must be attributable to a source.
### Attribution Format
Inline for direct references:
```
Sarah confirmed the REST approach in her email on Wednesday.
The design doc was updated to reflect this (~~cloud storage: "API Design Doc v3").
```
Source list at the end for completeness:
```
Sources:
- ~~chat: #engineering discussion (Jan 14) — initial decision thread
- ~~email: "API Decision" from Sarah Chen (Jan 15) — formal confirmation
- ~~cloud storage: "API Design Doc v3" last modified Jan 15 — updated specification
```
### Attribution Rules
- Always name the source type (~~chat, ~~email, ~~cloud storage, etc.)
- Include the specific location (channel, folder, thread)
- Include the date or relative time
- Include the author when relevant
- Include document/thread titles when available
- For ~~chat, note the channel name
- For ~~email, note the subject line and sender
- For ~~cloud storage, note the document title
## Confidence Levels
Not all results are equally trustworthy. Assess confidence based on:
### Freshness
| Recency | Confidence impact |
|---------|------------------|
| Today / yesterday | High confidence for current state |
| This week | Good confidence |
| This month | Moderate — things may have changed |
| Older than a month | Lower confidence — flag as potentially outdated |
For status queries, heavily weight freshness. For policy/factual queries, freshness matters less.
### Authority
| Source type | Authority level |
|-------------|----------------|
| Official wiki / knowledge base | Highest — curated, maintained |
| Shared documents (final versions) | High — intentionally published |
| Email announcements | High — formal communication |
| Meeting notes | Moderate-high — may be incomplete |
| Chat messages (thread conclusions) | Moderate — informal but real-time |
| Chat messages (mid-thread) | Lower — may not reflect final position |
| Draft documents | Low — not finalized |
| Task comments | Contextual — depends on commenter |
### Expressing Confidence
When confidence is high (multiple fresh, authoritative sources agree):
```
The team decided to use REST for the API redesign. [direct statement]
```
When confidence is moderate (single source or somewhat dated):
```
Based on the discussion in #engineering last month, the team was leaning
toward REST for the API redesign. This may have evolved since then.
```
When confidence is low (old data, informal source, or conflicting signals):
```
I found a reference to an API migration discussion from three months ago
in ~~chat, but I couldn't find a formal decision document. The information
may be outdated. You might want to check with the team for current status.
```
### Conflicting Information
When sources disagree:
```
I found conflicting information about the API approach:
- The ~~chat discussion on Jan 10 suggested GraphQL
- But Sarah's email on Jan 15 confirmed REST
- The design doc (updated Jan 15) reflects REST
The most recent sources indicate REST was the final decision,
but the earlier ~~chat discussion explored GraphQL first.
```
Always surface conflicts rather than silently picking one version.
## Summarization Strategies
### For Small Result Sets (1-5 results)
Present each result with context. No summarization needed — give the user everything:
```
[Direct answer synthesized from results]
[Detail from source 1]
[Detail from source 2]
Sources: [full attribution]
```
### For Medium Result Sets (5-15 results)
Group by theme and summarize each group:
```
[Overall answer]
Theme 1: [summary of related results]
Theme 2: [summary of related results]
Key sources: [top 3-5 most relevant sources]
Full results: [count] items found across [sources]
```
### For Large Result Sets (15+ results)
Provide a high-level synthesis with the option to drill down:
```
[Overall answer based on most relevant results]
Summary:
- [Key finding 1] (supported by N sources)
- [Key finding 2] (supported by N sources)
- [Key finding 3] (supported by N sources)
Top sources:
- [Most authoritative/relevant source]
- [Second most relevant]
- [Third most relevant]
Found [total count] results across [source list].
Want me to dig deeper into any specific aspect?
```
### Summarization Rules
- Lead with the answer, not the search process
- Do not list raw results — synthesize them into narrative
- Group related items from different sources together
- Preserve important nuance and caveats
- Include enough detail that the user can decide whether to dig deeper
- Always offer to provide more detail if the result set was large
## Synthesis Workflow
```
[Raw results from all sources]
↓
[1. Deduplicate — merge same info from different sources]
↓
[2. Cluster — group related results by theme/topic]
↓
[3. Rank — order clusters and items by relevance to query]
↓
[4. Assess confidence — freshness × authority × agreement]
↓
[5. Synthesize — produce narrative answer with attribution]
↓
[6. Format — choose appropriate detail level for result count]
↓
[Coherent answer with sources]
```
## Anti-Patterns
**Do not:**
- List results source by source ("From ~~chat: ... From ~~email: ... From ~~cloud storage: ...")
- Include irrelevant results just because they matched a keyword
- Bury the answer under methodology explanation
- Present conflicting info without flagging the conflict
- Omit source attribution
- Present uncertain information with the same confidence as well-supported facts
- Summarize so aggressively that useful detail is lost
**Do:**
- Lead with the answer
- Group by topic, not by source
- Flag confidence levels when appropriate
- Surface conflicts explicitly
- Attribute all claims to sources
- Offer to go deeper when result sets are large