検索戦略

見慣れないプレースホルダーを見かけた場合、またはどのツールが接続されているかを確認する必要がある場合は、CONNECTORS.md を参照してください。

エンタープライズサーチの中核的な知能。単一の自然言語の質問をソース固有の並列検索に変換し、ランク付けされた重複排除済みの結果を生成します。

目標

以下を:

"API移行のタイムラインについて何を決めたか?"

すべての接続されたソースにわたる的確な検索に変換します:

~~chat:  「API移行タイムラインの決定」(セマンティック) + in:#engineering after:2025-01-01 の「API移行」
~~ナレッジベース: セマンティック検索「API移行タイムラインの決定」
~~プロジェクトトラッカー:  テキスト検索「API移行」(関連ワークスペース内)

その後、結果を単一の首尾一貫した回答に統合します。

クエリの分解

ステップ1: クエリタイプの特定

検索戦略を決定するために、ユーザーの質問を分類します:

クエリタイプ	例	戦略
決定	「Xについて何を決めたか?」	会話(~~chat、メール)を優先し、結論シグナルを探す
ステータス	「プロジェクトYのステータスは?」	最近のアクティビティ、タスクトラッカー、ステータス更新を優先
ドキュメント	「Zの仕様はどこにあるか?」	Drive、wiki、共有ドキュメントを優先
人物	「誰がXに取り組んでいるか?」	タスク割り当て、メッセージ作成者、ドキュメント共有者を検索
事実確認	「Xのポリシーは何か?」	wiki、公式ドキュメント、その後確認会話を優先
時間的	「Xはいつ起こったか?」	広い日付範囲で検索、タイムスタンプを探す
探索的	「Xについて何を知っているか?」	すべてのソースにわたる広範な検索、統合

ステップ2: 検索コンポーネントの抽出

クエリから以下を抽出します:

• キーワード: 結果に含まれなければならないコアターム
• エンティティ: 人物、プロジェクト、チーム、ツール(利用可能な場合はメモリシステムを使用)
• インテントシグナル: 決定用語、ステータス用語、時間マーカー
• 制約: 時間範囲、ソースヒント、作成者フィルター
• 否定: 除外する事項

ステップ3: ソースごとのサブクエリの生成

利用可能な各ソースについて、1つ以上の的確なクエリを作成します:

セマンティック検索を推奨 する場合:

• 概念的な質問(「どう思っているか...」)
• 正確なキーワードが不明な質問
• 探索的なクエリ

キーワード検索を推奨 する場合:

• 既知の用語、プロジェクト名、頭文字略語
• ユーザーが引用した正確なフレーズ
• フィルターが多いクエリ(from:、in:、after:)

クエリバリアントを複数生成 する場合(トピックが異なる方法で参照されるかもしれない場合):

ユーザー: 「Kubernetes設定」
クエリ: 「Kubernetes」、「k8s」、「cluster」、「container orchestration」

ソース固有のクエリ変換

~~chat

セマンティック検索(自然言語の質問):

query: "プロジェクトauroraのステータスは?"

キーワード検索:

query: "project aurora status update"
query: "aurora in:#engineering after:2025-01-15"
query: "from:<@UserID> aurora"

フィルターマッピング:

エンタープライズフィルター	~~chat構文
from:sarah	from:sarah or from:<@USERID>
in:engineering	in:engineering
after:2025-01-01	after:2025-01-01
before:2025-02-01	before:2025-02-01
type:thread	is:thread
type:file	has:file

~~ナレッジベース (Wiki)

セマンティック検索 — 概念的なクエリに使用:

descriptive_query: "API移行タイムラインと決定根拠"

キーワード検索 — 正確な用語に使用:

query: "API migration"
query: "\"API migration timeline\""  (正確なフレーズ)

~~プロジェクトトラッカー

タスク検索:

text: "API migration"
workspace: [workspace_id]
completed: false  (ステータスクエリ用)
assignee_any: "me"  (「マイタスク」クエリ用)

フィルターマッピング:

エンタープライズフィルター	~~プロジェクトトラッカーパラメータ
from:sarah	assignee_any or created_by_any
after:2025-01-01	modified_on_after: "2025-01-01"
type:milestone	resource_subtype: "milestone"

結果のランク付け

関連性スコアリング

これらの要因に基づいて各結果をスコアリングします(クエリタイプ別に加重):

要因	加重(決定)	加重(ステータス)	加重(ドキュメント)	加重(事実確認)
キーワードマッチ	0.3	0.2	0.4	0.3
鮮度	0.3	0.4	0.2	0.1
権威性	0.2	0.1	0.3	0.4
完全性	0.2	0.3	0.1	0.2

権威性の階層

クエリタイプに応じて異なります:

事実確認/ポリシー質問の場合:

Wiki/公式ドキュメント > 共有ドキュメント > メール通知 > チャットメッセージ

「何が起こったか」/決定質問の場合:

会議ノート > スレッド結論 > メール確認 > チャットメッセージ

ステータス質問の場合:

タスクトラッカー > 最近のチャット > ステータスドキュメント > メール更新

あいまいさの処理

クエリがあいまいな場合、推測するよりも1つの的確な確認質問を優先してください:

あいまい: 「移行を検索」
→ 「いくつかの移行への参照が見つかりました。以下のどちらをお探しですか?
   1. データベース移行(プロジェクトPhoenix)
   2. クラウド移行(AWS → GCP)
   3. メール移行(Exchange → O365)」

以下の場合にのみ確認を求めてください:

• 非常に異なる結果を生成する明確な解釈がある場合
• あいまいさが検索するソースに大きく影響する場合

確認を求めないでください:

• クエリが有用な結果を生成するのに十分明確な場合
• 軽微なあいまいさを複数の解釈からの結果を返すことで解決できる場合

フォールバック戦略

ソースが利用不可またはリクエストが結果を返さない場合:

1. ソース利用不可: スキップして、残りのソースを検索し、ギャップを記録
2. ソースから結果なし: より広いクエリ用語を試す、日付フィルターを削除する、代替キーワードを試す
3. すべてのソースから結果なし: ユーザーにクエリ修正を提案
4. レート制限: 制限を記録し、他のソースからの結果を返す、後でリトライするよう提案

クエリの拡大

初期クエリが結果が少なすぎる場合:

元: 「PostgreSQL移行Q2タイムラインの決定」
拡大: 「PostgreSQL移行」
さらに拡大: 「データベース移行」
最も拡大: 「移行」

この順序で制約を削除します:

1. 日付フィルター(すべての時間を検索)
2. ソース/ロケーションフィルター
3. 不要なキーワード
4. コアエンティティ/トピック用語のみを保持

並列実行

常にソース全体でシーケンシャルではなく、並列で検索を実行します。総検索時間は、すべてのソースの合計ではなく、最も遅い単一ソースのほぼ等しくなるべきです。

[ユーザークエリ]
     ↓ 分解
[~~chatクエリ] [~~メールクエリ] [~~クラウドストレージクエリ] [Wikiクエリ] [~~プロジェクトトラッカークエリ]
     ↓            ↓            ↓              ↓            ↓
  (並列実行)
     ↓
[マージ + ランク付け + 重複排除]
     ↓
[統合された回答]