Pinecone、フルテキスト検索機能を一般提供へ

検索、レコメンデーション、RAG（Retrieval-Augmented Generation）、エージェントを実行する場合、リトリバルシステムに到達するクエリは単一の種類ではありません。意味に基づく検索（Semantic search）は、「意味で検索したい」というニーズのために設計されています。埋め込みベクトルがユーザーの意図を捉えるため、言葉遣いが原文と異なっていても、適切なデータを見つけることができます。

一方、識別子や正確なフレーズは異なる種類のクエリです。SKU（在庫管理単位）、部品番号、エラーコード、ケース番号、注文ID はすべて文字通りの文字列です。この場合、文字列そのものがクエリとなり、埋め込みベクトルでは一致しません。最悪のシナリオでも、埋め込みモデルは「PROD-001」をサブワードトークンに分割して処理し（もしトレーニングデータに含まれていれば）、他の SKU の隣に配置します。つまり、顧客が提供した部品番号「PROD-001」を検索しても、「PROD-002」や「PROD-003」も一緒に表示され、正解の部品が混在してしまうのです。ユーザーが必要としているのは「正確な一致」なのに、結果は「自信を持って近いもの」として返されます。エラーが発生するわけでもなく、エージェントは誤ったドキュメントから回答し、その応答内容に問題があることを示す兆候もありません。

正確な単語の一致を実現するには、通常、ノードベースの検索システムを別途実行する必要があります。これらのエンジンはその目的のために作られており、正確な単語のマッチングには優れています。しかし、それらを運用することは、チームが責任を持つ別プロジェクトとなります。ノードのサイズ調整、コーパスの拡大に伴うキャパシティ計画、シャード管理、メモリ最適化、マージサイクルのチューニング、バージョンアップの実行など、維持には多くの工数がかかります。エンジン自体は優秀ですが、それを稼働し続けるためには、チームの時間と労力が必要なのです。

ユーザーパートナーとの数か月にわたるプライベートプレビューでの検証を経て、本日、Pinecone Database においてフルテキスト検索が一般提供開始されました。これにより、BM25 キーワードランキングやテキストマッチフィルタ機能が、高密度ベクトルと同じインデックスに追加されます。その結果、エージェントはエンベディングでは見逃しがちな正確な注文番号やエラーコードを検出できるようになり、別システムのチューニングやメンテナンスも不要になります。

TL;DR

検索、レコメンデーション、RAG、またはエージェントのワークロードで、質問と識別子、および完全一致フレーズを混在させる必要がある場合、フルテキスト検索は以下を提供します：

• クエリ埋め込みが誤りやすい SKU、エラーコード、ケース番号、注文 ID、正確な引用句などに対して、確信度ではなく「正確さ」を追求します。
• インデックス内の複数のテキストフィールド全体で BM25 キーワードランキングを実行。Lucene 構文によるクエリ、ファジーマッチング、18 カ国語対応のトークン化と語幹抽出をサポートしています。
• セマンティック検索の結果をフィルタリングする「テキスト一致フィルター」。特定の識別子に基づいて取得しつつ、残りの結果は意味に基づいてランク付けする単一のクエリで実現可能です。
• テキストフィールド、密ベクトル（dense vectors）、疎ベクトル（sparse vectors）を 1 つのインデックスとスキーマに統合。Documents API を介してクエリを実行し、クラスタのチューニングやパッチ適用、アップグレードの手間はありません。
• デフォルトでは使用量ベースの容量管理を採用。ベクターインデックスと同じ読み取り単位・書き込み単位でメータリングされます。プロビジョンド型読み取り容量には Dedicated Read Nodes を、自社クラウド内での実行には BYOC を利用可能です。

クエリ埋め込みが誤りやすいケース

セマンティック検索は、意味が信号となるように設計されたクエリに対して効果を発揮します。一方、文字列の一致を厳密に求めるテストでは、ベクトルのみで構成されたインデックスは毎回同じ失敗を引き起こします。

類似品が正しいレコードと同等のランクで表示される問題があります。同じパターンを持つ SKU はすべて PROD-001 と多くのサブワードトークンを共有するため、検索システムは顧客が意図したものがどれかを区別できません。

この失敗は目に見えません。ベクトル検索は常に最も近い結果を返すため、空の結果を確認する余地もエラーをキャッチする機会もありません。間違った回答は、顧客に気づかれるまで正しい回答と見分けがつきません。

対照的に、ノードベースの語彙エンジン（lexical engine）という選択肢もあります。語彙エンジンは完全一致クエリには優れていますが、チームがノードのサイズ調整やチューニング、アップグレードを継続的に行う必要があります。

これらの失敗はビジネスにコストをもたらします：

• 正しく見える誤ったアクション。類似品を検索して取得したエージェントが、間違った部品を発送したり、誤ったポリシーを適用したりします。こうしたミス一つ一つがユーザーの信頼を損ないます。
• 継続的な運用コスト。誰かがノードのサイズ調整を行い、コパス（データ集合）の成長に合わせてキャパシティ計画を立て、アップグレードを実行する必要があります。システムが生産環境にある限り、この作業は続きます。
• 開発スピードの低下。エンジニアが検索インフラの維持に時間を割くことで、製品そのものの構築に注力する時間が削られます。

全文検索（full-text search）は、回答が文字列のリテラルな一致に依存するクエリのために設計されており、すべての他のクエリを処理する意味検索（semantic search）と同じインデックス上で動作します。

完全一致の精度が求められる場面

識別子中心の検索。 SKU、部品番号、エラーコード、ケース番号などでは、埋め込みモデルの弱点が最も顕著に現れます。こうした場面でフルテキスト検索は真価を発揮します。BM25 は用語そのものをランク付けし、テキストマッチフィルターは該当する文書が見つからない場合、結果を空に返します。つまり、「一致しない」ことが「似ている」と誤認されるのを防ぎます。

厳格な制約条件付きのレコメンデーション。 特定のモデル名や互換性のある部品番号を指定した顧客は、その条件を満たす提案だけを期待しています。埋め込みモデル単体ではこれを満たすことができません（例：PROD-001 のアクセサリーが PROD-002 の隣に表示されるなど）。テキストマッチフィルターで候補セットを「文字通りその用語を含むアイテム」に絞り込み、その中で密集ベクトルクエリによる類似度ランキングを行います。これにより、ユーザーが明示した制約が類似度によって無視されることはありません。これは、ティッカーシンボルや規制番号、ストリーミング動画 ID をキーにしたコンテンツレコメンデーションにも当てはまります。

エンタープライズ文書における RAG。 概念的な質問にはセマンティック検索が適しています。一方、特定の条項やエラーコードを指定するクエリでは正確な用語が必要であり、それを確実に返せるのは語彙ベースの検索だけです。フルテキスト検索とセマンティック検索を同じインデックスで利用すれば、RAG システムは「類似した記述」ではなく、「質問が依存する条項そのもの」を正しく取得できます。

構造化データにおけるエージェントのツール利用

エージェントは、過去のステップで取得した注文番号やステータス文字列などの値を用いてデータを参照する必要があります。全文検索はこの値そのものを照合するため、その後のすべての処理が正しいデータに基づいて構築されます。

Documents API を用いて作成された Pinecone Database のインデックスは、ドキュメントスキーマ上で動作します。テキストフィールド、密ベクトルフィールド、疎ベクトルフィールドを一つのスキーマ内で宣言し、単一のインデックスでこれらすべてを管理できます。

維持される機能:

• 既存の Pinecone APIs および SDK の継続利用
• インデックスライフサイクルの変更なし
• ストレージ、読み取りユニット、書き込みユニットで計測される従量課金モデルの継続
• チームがノードを管理する必要のないサーバーレスアーキテクチャの維持
• Dedicated Read Nodes や Bring Your Own Cloud を含む既存のデプロイオプションの継続

新たに追加された機能:

• 1 つのインデックス内の複数のテキストフィールドにわたる BM25 キーワードランク付け
• 論理演算子やフレーズ検索を含む Lucene クエリ構文のサポート
• セマンティック検索を含むあらゆる検索を、フィルタ条件に一致するドキュメントに限定するためのテキストマッチフィルター
• タイポ耐性を備えた ~ オペレーターによるファジーマッチング
• 18 か国語に対応したトークナイゼーションとステミングに加え、部分文字列やプレフィックスマッチングのための言語非依存な n-gram トークナイゼーション

意味するものも、言葉通りのもさも正確に見つける検索

類似レコードを検索して取得しようとしたエージェントが失敗すると、静かにエラーを返すだけです。間違った部品を送り出したり、誤った条項を引用したりします。その結果、後になってサポートチケットとして現れたり、顧客を失ったりするのです。

そのようなクエリの背後にノードベースの語彙エンジン（lexical engine）を配置することで、リスクをチームが管理できるクラスタに置き換えることができます。

このたび一般提供された全文検索は、すでに運用しているベクトルデータベース内の両方のギャップを埋めます。エンコーディング（埋め込み）では正しく処理できないクエリも、今度は正しいレコードを返すようになります。一方、セマンティック検索はそれ以外のすべての処理を引き続き担当します。

一つのパラメータチューニングやメンテナンス不要のクラスタではなく、一つのインデックスと一つのスキーマが両方の機能を支えています。

今すぐインデックスを作成して 全文検索を使い始めるか、全文検索についてご質問がある場合やインスタンスのサイズ選定にお手伝いが必要な場合は、お問い合わせください。

フルテキスト検索についてさらに詳しく

• ドキュメントを読む。 フルテキスト検索ガイド では、スキーマや分析機能、クエリ構文、現在の制限事項などについて解説しています。
• サンプルを実行する。 Pinecone で鳥を検索する では、スキーマ、フィルター、クエリ構文の使い方を順を追って説明。Wikipedia の鳥データセットを対象に、フルテキスト検索とマルチモーダルベクトル検索を組み合わせたデモも紹介しています。
• さらに深く掘り下げる。 フルテキスト検索：アーキテクチャと設計 では、API の背後にある仕組みについて知りたい人向けに、システムがどのように構築されているかを解説します。