Pinecone の全文検索機能が公開プレビューへ
Pinecone は、意味検索の精度不足を補うため、単一インデックス内で BM25 スコアリングや Lucene 構文に対応した全文検索機能を公開プレビューとして導入し、RAG システムの検索精度と柔軟性を大幅に向上させた。
キーポイント
意味検索とキーワード検索の統合
従来の意味検索(ベクトル)とキーワード検索(BM25)を別々のインデックスで管理するのではなく、単一のスキーマ内で同時に実行可能にし、結果の統合コストを排除した。
高度なテキストフィールド制御
18 か国語に対応し、 stemming(語幹化)やストップワード除去を個別に設定可能な複数のテキストフィールド(タイトル、本文、タグなど)をインデックス内で独立して定義・検索できる。
Lucene 構文と BM25 スコアリング
開発者が Lucene クエリ構文を使用して複雑なキーワード検索(例:特定の SKU やエラーコードのピンポイント指定)を実行でき、BM25 アルゴリズムによる高精度なランキングが可能になった。
Text Match フィルター機能
キーワード論理(完全一致句、全トークン一致、任意トークン一致)を用いてベクトル検索前の候補セットを絞り込む機能です。
メタデータフィルターとの組み合わせ
単一のクエリでテキストフィールドの完全一致、日付範囲によるフィルタリング、およびベクトル類似度によるランク付けを同時に実行できます。
Public Preview のサポート範囲と制限
ドキュメントのアップロード、取得、削除がサポートされていますが、1 つのクエリ内で BM25、dense、sparse のスコアリングを同時に実行することはできず、複数モーダルが必要な場合はクライアント側でマージする必要があります。
スキーマの変更制限
フルテキスト検索機能はインデックス作成時に固定されたスキーマに依存するため、既存のインデックスを後から変換して使用することはできず、可変スキーマ機能が実装されるまで待機する必要があります。
影響分析・編集コメントを表示
影響分析
この機能追加は、RAG(生成AIによる情報検索)システムの実用化において長年の課題であった「意味検索の曖昧さ」と「キーワード検索の精度」を同時に解決する画期的な進展です。開発者は複雑なハイブリッド検索アーキテクチャを構築する手間が省け、より信頼性の高いアプリケーションを短期間で実装できるようになります。特に、エラーコードや製品 SKU などの厳密な照合が必要なユースケースにおいて、Pinecone の競争優位性をさらに強化する要因となります。
編集コメント
意味検索の限界を補完する「精密なキーワード検索」機能をネイティブに統合した点は、実務レベルの RAG アプリケーション開発において極めて重要なマイルストーンです。
*FTS の構築方法に関する技術的な詳細については、Full Text Search: Architecture and Design をご覧ください*
セマンティック検索が本番環境スケールに到達した際、検索におけるデフォルトの手法はテキストを埋め込み(embedding)、意味に基づいて検索することでした。その結果、クエリが一致する対象範囲が拡大しました:同じコーパスをセマンティックに検索しても、以前よりも多くの検索可能なシグナルが含まれるようになりました。
しかし、カバー範囲の拡大には両刃の剣という側面があります。あいまいなクエリで関連文書を見つけられるようにする同一の特性は、正確な文書を特定することをより困難にもします。特定の事項(つまり製品 SKU、法的引用、人物名、エラーコードなど)に基づく検索における精度は、埋め込み空間には存在しません。したがって、検索システムが成熟するにつれて、キーワードマッチングはセマンティック検索の代替としてではなく、自然な補完手段として再び注目されるようになりました。
フルテキスト検索(Full Text Search: FTS)が現在、パブリックプレビューとして Pinecone で利用可能になりました。 インデックスごとの複数のテキストフィールドにわたる BM25 スコアリング、Lucene クエリ構文、多言語トークン化はすべて標準で組み込まれています。
1 つのインデックスに、テキストとベクトルを一緒に
単一のインデックスには、インデックス作成時に定義されたスキーマに基づき、テキストフィールド、密なベクトル(dense vectors)、スパースベクトル(sparse vectors)、およびフィルタ可能なメタデータがすべて保持されます。各テキストフィールドには言語設定が含まれており、これによりトークン化(tokenization)、語幹抽出(stemming)、およびオプションのストップワード除去(stop word removal)が制御されます。語幹抽出は単語をその基本形に縮約するため、「running」や「runs」も「run」というクエリに一致します。18 の言語がサポートされています。
インデックスあたり複数のテキストフィールドを設定可能であり、これにより、検索可能なすべての文字列を単一のフィールド経由でルーティングする必要があるというモデリングの回避策(workaround)は不要になります。タイトル、本文、タグはそれぞれ独立したテキストフィールドとして設定でき、それぞれの条件に基づいてスコアリングやフィルタリングが可能です。
キーワード検索とベクトル検索は、同じスキーマに対して同一クエリ内で実行されます。維持する必要がある別個のキーワードインデックスはなく、2 つのシステムからの結果を統合する必要もありません。
クエリ:Lucene 構文(BM25 ランキング)を使用したタイトル/本文全体でのキーワード検索
index = pc.preview.index(name="articles-multi")
response = index.documents.search(
namespace="errors",
score_by=[
{
"type": "query_string",
"query": 'title:("error code 4092") OR body:("error code 4092")'
}
],
top_k=10,
include_fields=["title", "body", "category"],
)
テキストマッチ:テキストフィールドをフィルタとして
テキストマッチフィルタは、ベクトルランキング実行前にキーワードロジックによって候補セットを絞り込みます。3 つのモードがサポートされています:完全一致フレーズ、すべてのトークンが存在する、いずれかのトークンが存在する。その後、ベクトル検索はすでにキーワード条件を満たすドキュメントのみに対して実行されます。
法文書検索システムを例に考えましょう。弁護士が判例を検索する場合、2 つの要件が必要です:文書には特定の条項や引用が正確に含まれていること、そしてその中から論点に最も意味的に関連するものが最上位に表示されることです。テキストマッチフィルタは最初の条件を処理し、密集ランキング(dense ranking)は2番目の条件を処理し、これらは単一のクエリで実現されます。
これはメタデータフィルタとも組み合わせ可能です。単一のクエリで、テキストフィールド内の完全一致フレーズを要求し、日付範囲でフィルタリングし、ベクトル類似度に基づいてランキングを行うことができます。
最初に完全一致フレーズでフィルタし、残りのドキュメントを密集類似度でランク付け
index = pc.preview.index(name="articles-multi")
query_vector = [...] # 1536 次元のクエリ埋め込み
response = index.documents.search(
namespace="default",
filter={
"$and": [
{"body": {"$match_phrase": "force majeure clause"}},
{"category": {"$eq": "legal"}}
]
},
score_by=[
{
"type": "dense_vector",
"field": "embedding",
"values": query_vector,
}
],
top_k=5,
include_fields=["title", "body"],
)
パブリックプレビューでサポートされている機能
ドキュメントに対して、アップサート(upsert)、フェッチ、削除がサポートされています。単一のクエリ内では、スコアリングは一度に 1 つのタイプ(BM25、dense、sparse)のみで行われます。複数のモダリティにわたるスコアを組み合わせる必要があるワークロードの場合、各クエリを個別に発行し、クライアント側でマージすることができます。スキーマはインデックス作成時に固定されるため、可変スキーマが実装されるまで、既存のインデックスをフルテキスト検索に対応させることはできません。
始め方
フルテキスト検索は、現在 API バージョン 2026-01.alpha で利用可能です。ドキュメントでは、スキーマ定義、クエリ構文、フィルタ演算子、Python SDK のエンドツーエンドの利用方法について解説されています。Google Colab ノートブックには、Wikipedia データセットを使用した実行可能な例が用意されています。
より詳細な手順については、この Bird Search デモ をご覧ください。これは約 2,079 件の北米の鳥に関する Wikipedia 記事に対して、Gemini Embedding 2 で埋め込まれたマルチモーダルベクトル検索とフルテキスト検索を組み合わせたものです。
原文を表示
*For the technical deep dive into how FTS is built, see Full Text Search: Architecture and Design*
When semantic search hit production scale, the default move for retrieval was to embed text and search by meaning. As such, the surface area of what a query could match expanded: the same corpus, searched semantically, contained more retrievable signal than it had before.
But expanded coverage cuts both ways. The same property that lets a vague query find a relevant document also makes it harder to pin down an exact one. Precision for searching on specifics (i.e. a product SKU, a legal citation, a person's name, an error code) doesn't live in embedding space. So as retrieval systems matured, keyword matching came back into purview, not as a replacement for semantic search but as the natural complement.
Full text search is now available in Pinecone, in Public Preview. BM25 scoring across multiple text fields per index, Lucene query syntax, and multi-language tokenization are all built in.
One index, text and vectors together
A single index now holds text fields, dense vectors, sparse vectors, and filterable metadata, defined together in a schema set at index creation. Each text field takes a language setting that controls tokenization, stemming, and optional stop word removal. Stemming reduces words to their root form, so "running" and "runs" all match a query for "run." Eighteen languages are supported.
Multiple text fields can be configured per index, which removes the modeling workaround of routing every searchable string through a single field. Title, body, and tags can each be independent text fields, scored or filtered on their own terms.
Keyword search and vector search run in the same query against that schema. There is no separate keyword index to maintain, no results from two systems to reconcile.
# Query: keyword search across title/body using Lucene query syntax (BM25 ranking)
index = pc.preview.index(name="articles-multi")
response = index.documents.search(
namespace="errors",
score_by=[
{
"type": "query_string",
"query": 'title:("error code 4092") OR body:("error code 4092")'
}
],
top_k=10,
include_fields=["title", "body", "category"],
)Text match: text fields as filters
Text match filters narrow the candidate set by keyword logic before vector ranking runs. Three modes are supported: exact phrase, all tokens present, any token present. The vector search then operates only over documents that already satisfy the keyword condition.
Consider a legal document retrieval system. A lawyer searching for precedents needs two things: the document must contain a specific clause or citation verbatim, and among those, the most semantically relevant to their argument should rank highest. A text match filter handles the first condition, dense ranking handles the second, in a single query.
This composes with metadata filters too. A single query can require an exact phrase in a text field, filter on a date range, and rank by vector similarity.
# Filter by exact phrase first, then rank remaining docs by dense similarity
index = pc.preview.index(name="articles-multi")
query_vector = [...] # 1536-dim query embedding
response = index.documents.search(
namespace="default",
filter={
"$and": [
{"body": {"$match_phrase": "force majeure clause"}},
{"category": {"$eq": "legal"}}
]
},
score_by=[
{
"type": "dense_vector",
"field": "embedding",
"values": query_vector,
}
],
top_k=5,
include_fields=["title", "body"],
)What's supported in Public Preview
Upsert, fetch, and delete are supported for documents. Within a single query, scoring operates on one type at a time: BM25, dense, or sparse. For workloads that need to combine scores across modalities, the queries can be issued separately and merged client-side. Schema is fixed at index creation, which means existing indexes cannot be converted to use full text search until mutable schema lands.
Get started
Full text search is available now on under API version 2026-01.alpha\verb|2026-01.alpha|. The documentation covers schema definition, query syntax, filter operators, and the Python SDK end to end. The Google Colab notebook has a runnable example using a Wikipedia dataset.
For a fuller walkthrough, this Bird Search democombines full text search with multimodal vector search over ~2,079 North American bird Wikipedia articles, embedded with Gemini Embedding 2.
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み