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"

次のように変換します：

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)

重複排除

ソースをまたいだ重複排除

同じ情報が複数の場所に現れることはよくあります。重複を特定して統合します。

同じ情報についての結果であることを示す手がかり：

• 同一または非常によく似たテキスト内容
• 同じ著者／送信者
• 短い期間内のタイムスタンプ（同じ日または前後の日）
• 同じエンティティ（プロジェクト名、ドキュメント、決定）への言及
• あるソースが別のソースに言及している（「~~chat で話したとおり」「メールによると」「ドキュメントを参照」）

統合方法：

• 1つの説明にまとめる
• 該当するすべてのソースを引用する
• 最も完全な内容を主なテキストとして使用する
• 各ソース固有の詳細を追加する

重複排除の優先順位

同じ情報が複数のソースにある場合は、次のものを優先します：

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)

重複排除しないもの

次の場合は、項目を分けて残します：

• 同じ話題でも、異なる結論が示されている
• 異なる人が異なる見解を示している
• ソース間で情報が大きく変化している（決定の v1 と v2）
• 異なる期間の情報が含まれている

引用とソースの帰属表示

統合した回答内のすべての主張は、ソースを特定できる必要があります。

帰属表示の形式

直接参照する場合はインラインで記載します：

Sarah confirmed the REST approach in her email on Wednesday.
The design doc was updated to reflect this (~~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 の場合はドキュメントのタイトルを記載する

信頼度

すべての検索結果が同じように信頼できるとは限りません。次の要素に基づいて信頼度を評価します。

情報の新しさ

新しさ	信頼度への影響
今日／昨日	現在の状況について信頼度が高い
今週	信頼度が高い
今月	信頼度は中程度 — 状況が変わっている可能性がある
1か月より前	信頼度は低い — 古くなっている可能性があると明記する

状況を尋ねるクエリでは、新しさを大きく重視します。ポリシーや事実に関するクエリでは、新しさの重要度は下がります。

権威性

ソースの種類	権威性のレベル
公式ウィキ／ナレッジベース	最高 — 内容が精査され、維持管理されている
共有ドキュメント（最終版）	高 — 公開を意図して作成されている
メールでの告知	高 — 正式なコミュニケーション
会議メモ	中～高 — 不完全な場合がある
チャットメッセージ（スレッドの結論）	中 — 非公式だがリアルタイムの情報
チャットメッセージ（スレッドの途中）	低 — 最終的な見解を反映していない場合がある
ドラフト文書	低 — 最終決定されていない
タスクへのコメント	文脈による — コメントした人によって異なる

信頼度の表現

信頼度が高い場合（新しく権威性のある複数のソースが一致する）：

The team decided to use REST for the API redesign. [direct statement]

信頼度が中程度の場合（ソースが1つ、または情報がやや古い）：

Based on the discussion in #engineering last month, the team was leaning
toward REST for the API redesign. This may have evolved since then.

信頼度が低い場合（古い情報、非公式なソース、または矛盾する手がかりがある）：

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.

矛盾する情報

ソース間で意見が食い違っている場合：

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.

一方の内容を黙って選ぶのではなく、必ず矛盾を明示します。

要約の方法

検索結果が少ない場合（1～5件）

各結果を文脈とともに提示します。要約は不要です。すべての情報をユーザーに提供します：

[Direct answer synthesized from results]

[Detail from source 1]
[Detail from source 2]

Sources: [full attribution]

検索結果が中程度の場合（5～15件）

テーマごとにまとめ、グループごとに要約します：

[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]

検索結果が多い場合（15件以上）

概要を統合し、詳細を掘り下げられるようにします：

[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?

要約ルール

• 検索プロセスではなく、回答を最初に提示します
• 検索結果をそのまま列挙せず、内容をまとめて説明します
• 異なるソースにある関連項目をまとめます
• 重要なニュアンスや注意点を保ちます
• ユーザーがさらに詳しく調べるかどうか判断できるだけの詳細を含めます
• 検索結果が多い場合は、いつでも詳細を説明できることを伝えます

統合ワークフロー

[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]

アンチパターン

次のことは避けてください：

• ソースごとに結果を列挙する（「~~チャットから：……、~~メールから：……、~~クラウドストレージから：……」）
• キーワードに一致したという理由だけで、関連性のない結果を含める
• 手法の説明で回答を埋もれさせる
• 矛盾を指摘せずに提示する
• ソースの帰属を省略する
• 不確かな情報を、十分に裏付けられた事実と同じ確度で提示する
• 有用な詳細が失われるほど大幅に要約する

次のことを行ってください：

• 回答を最初に提示する
• ソース別ではなく、トピック別にまとめる
• 適切な場合は確信度を示す
• 矛盾を明確に指摘する
• すべての主張についてソースを明記する
• 検索結果が多い場合は、さらに詳しく説明できることを伝える