企業知識におけるエージェントの検索パフォーマンス測定

企業知識におけるエージェントの検索パフォーマンス測定 Company Knowledge Benchの紹介 2026年10月2日 Finn Bauer チームが検索を行う方法は、あらゆる領域で急速に変化しています。Cursorは最近、埋め込みによるコード検索を停止し、grepとインデックス検索のみに依存するようになりました。他のチームは、従来の再ランキングモデルをJevのような新しいモデルに置き換えています。 エージェントが依存する最も重要な知識の1つは、企業知識です。ドキュメント、チケット、チャットメッセージ、社内Wiki、コードなどです。しかし、ほとんどのチームは、実際のデータで検索がどのように機能するかを測定する方法がないため、どの検索がそれに最適かを知ることができません。 Kapaは、企業知識をインデックス化し、エージェントがそれを検索できるようにするプラットフォームです。ソースを接続すると、Kapaはそれらを1つの検索可能な知識ベースに変換し、どのエージェントでも必要な情報をクエリできます。検索は私たちが構築するものの中心であり、私たちは常にその方法を変更しています。 Company Knowledge Benchは、私たち自身のシステムを改善するために構築したものです。実際のプロダクションデータからアノテーションされた1,000件の評価ケースが含まれています。この記事では、それがどのように機能するかを説明し、それに対していくつかの一般的な検索実装をスコアリングします。 Company Knowledge Benchの結果：クエリあたりの時間に対するスコア 固定検索、エージェントgrep、およびKapa：1,000件の評価ケースに対する7つの検索器。 スコアが高いほど、左側にあるほど良い。 固定検索（従来のRAG） grepを備えたエージェント検索器 Kapa 時間あたりの最良スコア 検索スコア 0.4 0.5 0.6 0.7 0秒 5秒 10秒 15秒 クエリあたりの時間、秒 ハイブリッド検索 0.41 ハイブリッド検索 + 再ランキング 0.50 クエリ分解 0.56 Kapa デフォルト 0.61 Kapa ディープ 0.65 エージェント + grep (Luna) 0.54 エージェント + grep (Sol) 0.61 結論：grep以外の何物も持たないフロンティアモデルは、0.61で調整された最新の検索パイプラインに匹敵しますが、5倍の時間がかかります。最適化されたエージェント検索器（Kapa Deep）はさらに優れています。約5秒で0.65です。 バイアスに関する注意：検索は私たちの製品の中核であり、7つの検索器すべてが私たちによって構築され、私たちのパイプラインで取り込まれたドキュメントを使用しています。 なぜ公開ベンチマークは私たちには機能しないのか 公開ベンチマークは、私たちが目にするすべてのユースケースとクエリの種類をカバーしていないため、私たちには機能しません。 ユースケース チームはKapaにソースをインデックス化し、エージェントを検索に接続します。そのエージェントは、それぞれ独自のドキュメントと質問する人々を持つ、かなり異なるユースケースに対応できます。 開発者は、ドキュメント、API仕様、コード、GitHubの問題を通じて、しばしばClaude Codeを介して製品について質問します。 営業担当者やその他の従業員は、Slack、Confluence、Notion、Google Driveなどの製品、プロセス、顧客について質問します。 サポートチームは、過去のチケット、ヘルプセンターの記事、社内ハンドブックから新しいチケットへの返信を作成します。 クエリ これらのユースケースが示すように、さまざまな種類のエージェントがKapaの検索にクエリを送信し、クエリは誰が書いたかによって異なります。 人々は1つのメッセージにすべてを詰め込みます：いくつかの質問、貼り付けられたエラー、以前の発言への参照。 Claude Codeのようなエージェントは、複雑な質問を短く正確な検索に分解して、独自のクエリを作成します。例：「webhook retry backoff config」 公開検索ベンチマークは、法律や医学のような単一のドメインを中心に構築されているか、合成ドキュメントと質問から構築された人工的なものがほとんどです。これらのいずれもこの範囲をカバーしていないため、私たちは独自のものを構築しました。 エージェントの検索をどのようにスコアリングするか 良い検索を測定する前に、それが何であるかを定義する必要があります。 まずいくつかの用語を説明します。クエリは、検索器に送信されるものです。コーパスは、チームがKapaにインデックス化したすべてのものです。チャンクは、ページのセクションのような短い断片です。検索器は、クエリを受け取り、コーパスから最も関連性の高いチャンクを返します。 私たちの定義： 検索器の目標は、利用可能な最高品質のソースを使用して、クエリに完全に回答する最小限のチャンクセットを収集することです。 Company Knowledge Benchは、3つのプロパティに基づいています。 完全性。エージェントがチャンクを受け取っても、回答するために他に何も必要としない必要があります。セットが不完全な場合、エージェントは不完全または不正確な回答を返します。 最小性。どのチャンクを削除しても、セットは不完全になります。クエリが必要としない追加のチャンクはコストがかかり、モデルの推論を困難にします。 ソースの優先順位。コーパスはしばしば同じクエリに回答できる複数のチャンクセットを保持しており、それらの品質が同等であることはほとんどありません。私たちのベンチマークは、優先されるもののみを受け入れます。どのソースが優先されるかを決定するのは困難であり、多くのグレーゾーンがありますが、一般的には2つの要因になります。 ソースの権威。専用の参照ページは、同じ事実を繰り返すチュートリアル、問題スレッド、またはブログ投稿よりも優先されます。 鮮度。現在のソースは、古いソースよりも優先されます。先週のSlackスレッドは、3年前に最後に編集されたConfluenceページよりも優れています。 これらに加えて、ベンチマークは特定の状況に対してルールを強制します。例えば： クエリが曖昧な場合。検索器は、そのすべての合理的な読み取りに対してチャンクを返す必要があります。1つの読み取りを選択するのはエージェントの仕事です。 問題に複数の有効な解決策がある場合。検索器は、各文書化された解決策に対してチャンクを返す必要があります。これにより、エージェントはオプションとそのトレードオフを説明できます。 コーパスにクエリに回答するものが何もない場合。検索器は、利用可能な最も強力な証拠を返す必要があります。その機能がサポートされていないという声明、機能が欠落している完全なリスト、または文書化された回避策です。それらが存在しない場合、正しい結果は何もありません。 これらすべてが、私たちのベンチマークラベリングハンドブックに正確に文書化されています。 評価ケースの例 私たちのベンチマークは、評価ケースのセットです。各ケースは、実際のプロダクションクエリ、クエリが発行された時点のコーパスのスナップショット、および検索基準で構成されます。検索基準は、クエリに対して有効なコーパスのチャンクを指定するブール式です。 以下は、検索器が返したチャンクに対してスコアリングされた、簡略化された評価ケースです。 クエリ 「どのプランにSSOが含まれていますか？また、有効にする方法を教えてください。」 検索基準 { "operator": "AND", "operands": ["chunk_1", "chunk_2"] } 検索器が返したチャンク chunk_1 価格ページ「SSOはTeamおよびEnterpriseプランに含まれています。」 chunk_2 SSOセットアップガイド「SSOを有効にするには、設定 > セキュリティに移動し、IDプロバイダーを選択して、そのメタデータURLを貼り付けます。」 chunk_3 コミュニティフォーラム投稿「TeamおよびEnterpriseプランでSSOを利用できます。」 chunk_4 Changelog「ダークモードがダッシュボードで利用可能になりました。」 スコア 合格。基準はchunk_1とchunk_2を必要とし、両方とも返されました。 精度：4件中2件、つまり50%。chunk_3とchunk_4は基準に含まれていません。 フォーラム投稿はソースの優先順位のため基準に含まれていません。それは同じ事実を繰り返しています。