ナレッジ総合化

エンタープライズ検索の最終段階。複数のソースからの生結果を、一貫性のある信頼できる回答に変換します。

目標

以下を:

~~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再設計のためにGraphQLではなくRESTを採用することを決定しました。Sarahが判断を下し、
GraphQLは現在のユースケースには過剰であることを指摘しました。これは火曜日の#engineeringで議論され、
水曜日のメールで確認され、設計ドキュメントがこの決定を反映するように更新されました。
関連する~~project tracker タスクは完了とマークされています。

ソース:
- ~~chat: #engineering スレッド (1月14日)
- ~~email: Sarahから「API Decision」(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: Sarah Chenから「API Decision」(1月15日) — 正式な確認
- ~~cloud storage: 「API Design Doc v3」最終更新1月15日 — 更新された仕様

帰属ルール

• 常にソースタイプ(~~chat、~~email、~~cloud storage等)を記載
• 特定の場所(チャネル、フォルダ、スレッド)を記載
• 日付または相対時間を記載
• 関連がある場合は作成者を記載
• 利用可能な場合はドキュメント/スレッドのタイトルを記載
• ~~chatの場合はチャネル名を記載
• ~~emailの場合は件名と送信者を記載
• ~~cloud storageの場合はドキュメントタイトルを記載

信頼度レベル

すべての結果が同等に信頼できるわけではありません。以下に基づいて信頼度を評価します:

鮮度

直近性	信頼度への影響
本日/昨日	現在の状態に対して高い信頼度
今週	良好な信頼度
今月	中程度 — 状況が変わっている可能性
1ヶ月以上前	より低い信頼度 — 潜在的に時代遅れとしてフラグ

ステータス照会では、鮮度に大きく重みをつけます。ポリシー/事実照会では、鮮度の重要性は低くなります。

権威性

ソースタイプ	権威レベル
公式ウィキ/ナレッジベース	最高 — キュレーション、維持管理されている
共有ドキュメント(最終版)	高 — 意図的に公開されている
メールアナウンスメント	高 — 正式なコミュニケーション
会議ノート	中程度-高 — 不完全な可能性
チャットメッセージ(スレッド結論)	中程度 — 非公式だがリアルタイム
チャットメッセージ(スレッド中盤)	より低い — 最終立場を反映していない可能性
ドラフトドキュメント	低 — 確定していない
タスクコメント	文脈依存 — コメント者に依存

信頼度の表現

信頼度が高い場合(複数の新鮮で権威あるソースが合意):

チームはAPI再設計にRESTを使用することを決定しました。[直接的な陳述]

信頼度が中程度の場合(単一ソースまたはやや古い):

先月の#engineeringでのディスカッションに基づくと、チームはAPI再設計のためにRESTに傾いていました。
この後、状況は進展している可能性があります。

信頼度が低い場合(古いデータ、非公式なソース、または矛盾する兆候):

3ヶ月前の~~chatのAPI移行ディスカッションへの参照を見つけましたが、正式な決定ドキュメントを
見つけることができませんでした。情報は時代遅れである可能性があります。
現在のステータスについてチームに確認することをお勧めします。

矛盾する情報

ソースが異なる場合:

APIアプローチについて矛盾する情報が見つかりました:
- 1月10日の~~chatディスカッションはGraphQLを提唱
- しかし1月15日のSarahのメールはRESTを確認
- 設計ドキュメント(1月15日更新)はRESTを反映

最新のソースはRESTが最終決定であったことを示していますが、
初期の~~chatディスカッションは最初GraphQLを検討していました。

常に矛盾を表面化させ、サイレントに1つのバージョンを選ばないでください。

要約戦略

小規模な結果セット(1-5結果)

各結果をコンテキストともに提示します。要約は不要 — ユーザーにすべてを提供:

[結果から総合化された直接的な回答]

[ソース1の詳細]
[ソース2の詳細]

ソース: [完全な帰属]

中規模な結果セット(5-15結果)

テーマ別にグループ化し、各グループを要約:

[全体的な回答]

テーマ1: [関連結果の要約]
テーマ2: [関連結果の要約]

主要なソース: [最上位3-5の最も関連するソース]
完全な結果: [ソース全体での]アイテム数

大規模な結果セット(15以上の結果)

高レベルの総合化と詳細を掘り下げるオプション提供:

[最も関連する結果に基づく全体的な回答]

要約:
- [主要な発見1] (Nのソースでサポート)
- [主要な発見2] (Nのソースでサポート)
- [主要な発見3] (Nのソースでサポート)

主要なソース:
- [最も権威あり/関連があるソース]
- [2番目に最も関連]
- [3番目に最も関連]

[ソースリスト]全体で[合計数]結果が見つかりました。
特定の側面についてさらに詳しく掘り下げてほしいですか?

要約ルール

• 検索プロセスではなく、回答を先頭に
• 生の結果をリストしない — ナレーティブに総合化
• 異なるソースからの関連アイテムをグループ化
• 重要なニュアンスと警告を保持
• ユーザーが詳細を掘り下げるべきかを判断できるには十分な詳細を含める
• 結果セットが大きい場合は、常により詳細な情報提供をオファー

総合化ワークフロー

[すべてのソースからの生結果]
          ↓
[1. 重複排除 — 異なるソースからの同じ情報をマージ]
          ↓
[2. クラスタリング — テーマ/トピック別に関連結果をグループ化]
          ↓
[3. ランク付け — クラスタとアイテムをクエリへの関連性で順序付け]
          ↓
[4. 信頼度評価 — 鮮度 × 権威性 × 合意]
          ↓
[5. 総合化 — 帰属付きのナレーティブ回答を作成]
          ↓
[6. フォーマット — 結果数に適切な詳細レベルを選択]
          ↓
[ソース付きの一貫性のある回答]

アンチパターン

しないこと:

• ソースごとにリストする(「~~chatから: ... ~~emailから: ... ~~cloud storageから: ...」)
• キーワードにマッチしただけの無関関な結果を含める
• 方法論の説明の下に回答を埋める
• 矛盾する情報をフラグなしで提示
• ソース帰属を省略
• 不確実な情報を根拠のある事実と同じ信頼度で提示
• 有用な詳細が失われるほど積極的に要約

すること:

• 回答を先頭に
• ソースではなくトピック別にグループ化
• 適切な場合は信頼度レベルをフラグ
• 矛盾を明示的に表面化
• すべての主張をソースに帰属させ
• 結果セットが大きい場合はさらに詳細を提供をオファー