エージェント向けのテキストマッチフィルターの追加

セマンティック検索は意味的に近い結果を返しますが、必ずしもユーザーが意図した質問に答える結果とは限りません。人間であれば、文脈から外れた結果を見分けてスキップできますが、エージェントにはそれができません。エージェントは戻ってきた結果を真実として受け取り、事前のチェックなしにその情報に基づいて行動を開始してしまいます。

このギャップを最も鋭く示すのが「暗黙の文脈」です。質問自体は明確であっても、システムが正しく回答するために必要な情報が欠落しているケースがあります。本稿では、Hugging Face が公開する 2022 年から 2024 年にかけての CNN ニュース記事 10,000 件からなる公的データセットを用いて、この失敗モードを解説します。各記事のテキストとトピックラベルはメタデータとして保存されており、Pinecone の新しいテキストマッチフィルターの導入により、事前のケース別ラベル付けなしにこの問題を解決できる方法を示します。

以下のクエリと結果については、こちらのノートブックで実際に確認できます。

曖昧さの問題

「大統領候補のトップは誰か？」というクエリを例に挙げましょう。アメリカのユーザーがこの質問をした場合、ほぼ間違いなく米国の大統領選挙について尋ねているはずです。しかし、クエリ自体にはその旨は一切記載されていません。

密ベクトル検索（Dense vector search）のみでは、以下のような結果が返されます：

これらすべてはフランスの選挙に関するものであり、それぞれが意味的に正しい一致ではあるものの、ユーザーが本当に尋ねたかった問いには答えていません。

最も obvious な解決策は、ユーザーにクエリを「米国の主要な大統領候補」のように書き直させることですが、これには二つのコストがかかります。第一に、シンプルだと感じた質問を持ってきたユーザー側に、正確なクエリの作成という負担を押し付けることになります。第二に、エージェントパイプラインにおいては、最初の検索結果の質が悪いことが再検索を行うよりも大きな損失をもたらします。例えば、世論調査の動向をチャート化し、誰が支持を伸ばし誰が失っているかを分析するようエージェントに指示した場合でも、その分析がフランスの選挙データに基づいて構築されていれば、間違った回答を生成するために消費されたトークンは無駄になり、それに続くツール呼び出しも無意味になります。このエラーは下流のプロセスにおいて段階的に蓄積・増幅していきます。これを数千件のクエリ規模に拡大すれば、コストが単なる付随的な問題ではなくなることは明らかです。

メタデータフィルタリングを用いて国別に結果を制限することは可能ですが、これは事前に「国」「選挙年」「地方選対全国選」など、あらゆる重要になりうる次元ごとにすべてのレコードにラベル付けを行うことを意味します。後から発見されたフィルタの次元に対しては、適用前に全データを再処理する必要があります。生産環境ではこれが数十億件のレコード規模になることもあり、その場合の再処理コストは膨大になります。

解決策：テキストマッチフィルタリング

現在、パブリックプレビュー版として提供されている Pinecone のフルテキスト検索では、「テキストマッチフィルタ」がサポートされています。これは、アプリケーションが扱う可能性のあるあらゆるケースに対して事前にメタデータをラベル付けする必要なく、特定のテキストに一致するレコードのみを候補プールに制限する語彙クエリです。

"United States" という条件でテキストマッチフィルタを適用すると、セマンティック検索の実行前に候補プールが絞り込まれます。

クエリ、モデル、インデックスは上記の検索と同じです。唯一の違いは、ベクトル検索を実行する前に候補プールを「記事本文に 'United States' という単語が含まれるレコード」に限定した点で、その結果、3 つの結果すべてが実際の米国関連のレースに収束しました。

この一般化が適用される場面

ニュース検索では曖昧さが目に見えやすいですが、クエリが明示されていない文脈を前提とするあらゆる場面で同様のパターンが見られます。例えば、機械番号やエラーコードに基づいてスコープを絞った産業用マニュアル、保険証券番号や種別で限定された保険請求処理、裁判や管轄区域に特化した法務検索などが該当します。ほとんどのセマンティック・サーチアプリケーションは、クエリが何らかの情報を暗黙的に含んでいるため、この種の課題に直面することになります。

これらのフィルタは連鎖して機能します。ブール演算子で結合したり、メタデータフィルタを積み重ねたり、他のフィールドに対して追加のテキストマッチングフィルタを重ねたりすることで、単一のクエリ内で候補プールの絞り込みが複数の次元で行われます。

エージェント型アプリケーションにおける変化

エージェントには、意味的に近い結果が実際にタスクに適しているかを再確認する工程がありません。必要なフィルタリングは、結果がエージェントに到達した「後」ではなく、「前」に行わなければなりません。

テキストマッチングによるフィルタリングは、この修正プロセスをクエリ自体に組み込むものです。これにより、アプリケーションが必要とする可能性のあるあらゆるフィルタリングに対してデータセットを事前にラベル付けする必要はありません。検索結果の誤りが無駄なツール呼び出しの連鎖へと繋がるパイプラインにおいては、事後にエラーを検出するよりも、クエリ時点で候補範囲を絞り込む方がコストを抑えられます。