MATCHとTO_TEXTが任意のES|QL式で全文検索を可能にする方法

まずは、Elasticsearch 9.4では不可能だったクエリから始めます。このクエリは EVALコマンドを使用します。

この例では、要約にはマッピングやアナライザーの設定がありません。また、逆インデックスとも関連付けられていません。このクエリの有効期間中のみ存在しますが、それでも検索可能です。これを機能させるには、2つの追加要素が必要です。

まず、MATCHは、マップされたフィールドだけでなく、すべての式を最初の引数として受け入れるようになりました。これにはEVALで生成されたカラムや、インラインで使われる関数結果も含まれます。また、元のドキュメントから直接読み込む未マッピングフィールドも含まれます。さらに、この新しいユースケースでは、MATCHで通常受け入れられるすべてのデータタイプがサポートされます。

2つ目の要素は新しいTO_TEXT関数であり、テキスト型の出力を生成する最初のES|QL変換関数です。これまで、テキスト列はインデックス付きマッピングフィールドからのみ取得でき、ES|QL式によって生成される文字列はすべてテキストではなくキーワード値でした。MATCHは2つを異なる方法で扱うため、区別が重要です。テキスト値は分析され、キーワード値は正確に比較されます。これは、インデックス付きキーワードフィールドのMATCHクエリが用語クエリに書き換えられる方法を反映しています。TO_TEXT(x) は、ES|QLに対して、「この文字列を全文として扱う」ように指示する方法です。

これはElasticsearch 9.5のテクニカルプレビューとして提供されるため、いくつかの制限があります。

• 現在はフィルタリング機能のみを提供しています。式に対するMATCHは、現時点では関連性スコアには影響しません。インデックス付きフィールドに対する一致のみがスコアに影響します。

• 式を照合する際、あいまい検索などのクエリオプションはまだサポートされていません。

• 実行時テキストは標準アナライザーで解析されます。これはまだ設定変更できません。

これらの制約に対処するための取り組みが進められています。

ES|QLでLIKEやRLIKEの代わりに全文検索を使うのはなぜですか？

ES|QLには、インデックスなしで文字列を検索するLIKE（ワイルドカードパターン）とRLIKE（正規表現）という2つの方法がすでにありました。どちらもどんな文字列式でも動作するので、MATCHが何を追加するのか疑問に思うのは当然です。答えは分析です。これは、語幹抽出や同義語などの技術を用いる、より高度な検索方法です。また、ストップワード処理も行います。

LIKEは文字列を構成する単語を理解せずに行う単純な部分文字列マッチングです。例えば、キツネ（fox）に関するログメッセージを探しているとします。

これは大文字表記の「Fox spotted near the henhouse（鶏小屋の近くでキツネが目撃された）」とは一致しませんが、キツネとは全く関係のない「Outfoxed by the competition（競争相手に出し抜かれた）」とは一致します。大文字小文字の区別に関しては偽陰性、他の単語の中に埋もれた部分文字列に関しては偽陽性と、どちらの方向にも問題があります。

正則表現は格の問題を補うことができますが、単語境界の問題はすぐに複雑化してしまいます。例えばこんな感じです。

これでさえ、正解ではありません。文末に「!」や「?」が続く場合、「fox」を見落としてしまいます。また、タブ、引用符、括弧については何も言及していません。修正を加えるたびにパターンが長くなり、次にクエリを読む人は、それが実際に何をしているのかをリバースエンジニアリングしなければならなくなります。

MATCHはクエリと値の両方をアナライザーに通し、テキストを小文字の単語にトークン化して、単語同士を照合するため、問題が解消されます。

このクエリは、「The quick brown fox」や「FOX spotted near the henhouse」のような値には一致しますが、「Outfoxed by the competition」や「FOXTROT protocol enabled」には一致しません。単語の周囲の句読点に関係なく一致します。もちろん、これはすべて、MATCH(TO_TEXT(message), "brown fox") のような複数語クエリにも、期待どおりに機能します。

これまでインデックス化やマッピングが行われていなかったデータに対しても自然言語をサポートするため、 36個の専用言語アナライザーを利用できるようにするための作業が進められています。

インデックス化されていないデータやマッピングされていないデータの全文検索のユースケース

上記の例ではマッピングされたフィールドから計算された値を検索しました。ES|QL MATCHを式に適用する際のより興味深いユースケースは、これまで全く検索できなかったデータに関するものです。いくつか見ていきましょう。

マッピングを追加せずにES|QLでマップされていないフィールドを検索する方法

詳細なスタックトレースや生のリクエストペイロードなど、意図的にマッピングからフィールドを除外する場合もあります。デバッグ用のデータブロックを省略することもあります。これらのうちの1つをインデキシングすると、ドキュメントごとにディスクとヒープ容量が消費されます。四半期に1回しかクエリしないようなフィールドのためにインデックスを作成する価値はありません。

この決定は常に最終的なものでした。なぜなら マッピングされていないフィールド はクエリから完全に見えなかったからです。Elasticsearch 9.5では、SET unmapped_fields="load"を使用して、ES|QLにマッピングされていないフィールドをソースドキュメントからキーワードとして直接ロードさせることができます。次に、それをTO_TEXTで囲むと、全文検索を実行できるようになります。

ここでは、stack_traceはマッピングされていません。すべての値は元の文書から取得され、その場で分析されます。行ごとにマッチングされています。これが実際の作業であり、逆インデックス検索ほど高速になることは決してありません。しかし今では、インデックスを作成しなかったそのフィールドも検索不能ではなくなりました。日常的なケースではマッピングを小さく保ちつつ、重要な場面では四半期に一度の質問にも対応できます。

キーワードフィールドでの全文検索（再インデックスなし）

キーワードフィールドは多くのことを可能にします。正確なマッチング、高速なアグリゲーション、ソート機能を提供するため、多くのフィールドがそのようにマッピングされます。しかし、マッピングはデータが到着した時点で決定されるため、当初の意図とは異なる方法でデータを利用したくなる状況に陥ることがあります。例えば、product_nameがダッシュボードで集約されるためキーワードとしてマッピングされ、1年分の製品データを受け取った後に、誰かがproduct_nameの値内で検索できるようにしたいと考えることもあるでしょう。

以前の解決策は、マッピングをテキストに変更する（または複数フィールドを追加する）ことと、すべてを再インデックスすることでした。これは時間と費用がかかる場合があり、多くの場合、ユーザーはわざわざその手間をかけたくないことが多いです。新しい答えは、1つの関数呼び出しです。

TO_TEXTはキーワード値をその場でテキストに変換するため、MATCHはそれらを正確に比較するのではなく、分析します。これにより、マッピングやソースドキュメントの再インデックス作成なしでキーワードフィールドをクエリできます。検索が日常的なクエリになった場合でも、フィールドをテキストとしてインデックスすることが長期的には正しい選択ですが、TO_TEXTを使えば、追加の手間なく今日すぐに結果を得られます。

異なるマッピングを持つインデックス間で同じフィールドを探索

ES|QLは複数のインデックスにまたがることができ、同じフィールドであっても、すべてのインデックスで常に同じ形式である必要はありません。同じフィールドが異なるインデックスで異なる型を持つ場合、ES|QLはそれを共用型として扱い、変換関数によって競合を解決します。今年のインデックステンプレートではメッセージフィールドのタイプがテキストになっているものの、昨年のテンプレートではキーワードだったという例を考えてみましょう。

クエリ実行時には、テキストインデックス由来の値であろうとキーワードインデックス由来の値であろうと、すべての値が分析されます。古いインデックスのキーワード値は、他のすべてと同様にトークン化され、小文字に変換されるため、「connection reset」は、どのインデックスに存在していても「Connection RESET by peer」を検索します。

もう一つ興味深いケースは、フィールドが一方のインデックスにのみマップされているものの、もう一方のインデックスにも存在（かつマップされていない）場合です。

ここで指摘しておくべき微妙なニュアンスがあります。error_detailsがlogs-2026にマッピングされていて、logs-2025にはマッピングされていない場合、ElasticsearchはこのクエリをLuceneにプッシュできません。フィールドがマッピングされていないインデックスは、マッチを返さないためです。代わりに、プランナーはフィールドが潜在的に未マッピングであることに気づき、行の出所に関わらず、行ごとにMATCH全体を評価します。どのインデックスにフィールドがマッピングされているかを知る必要はありません。クエリがその質問に答えます。

ES|QLが逆インデックスなしでクエリ時にテキストを分析する方法

ES|QLが式に対してMATCHを計画する場合、クエリ文字列を事前に一度だけ解析して、一連の用語に分解します。各行がどのように評価されるかは、式の型によって異なります。

式の種類

処理

マッチング動作

テキスト（TO_TEXT経由）

アナライザーは値を小文字の用語にトークン化

トークン同士の比較。いずれかのトークンがクエリ用語のいずれかと一致する場合、その行は一致（ORセマンティクス）。

キーワード、IP、日付、数字

分析なし。クエリ定数は一度ネイティブ型に変換。

行ごとの正確な比較

どちらの経路もLuceneを完全に迂回し、値を行ごとに評価します。非テキストパスは、これらのフィールドタイプに対してLuceneにプッシュダウンされたマッチクエリの動作と完全に一致するため、クエリがインデックスにヒットするかどうかに関わらず、セマンティクスは一貫しています。

逆インデックス検索は取り込み時に作業を行い、クエリ時に一致しない文書には一切触れません。実行時マッチはクエリ時に、到達するすべての行に対してその分析を行います。一方は既に処理が完了しているため高速であり、もう一方はデータがインデックス化されている必要がないため柔軟性があります。

ES|QL全文検索の今後の展望は

この記事の内容はすべて、ES|QLの検索機能を、事前にインデックスを作成したデータだけでなく、あらゆるデータに対して動作させるための、より大規模な取り組みの第一弾です。先に挙げた制約事項については積極的に改善に取り組んでおり、ロードマップはさらに次の段階へと進んでいます。

• スコアリング。実行時の一致結果も_scoreに反映されるため、データがインデックス化されていない場合でも、関連性に基づいてソートできます。

• 式に対するMATCH_PHRASE。Elastic Cloud Serverlessですでに利用可能で、9.6でElastic Stackに登場します。

• 設定可能なアナライザー。式に対するMATCHおよびMATCH_PHRASEのアナライザーサポートにより、クエリ実行時に言語アナライザー、ステミング、同義語を利用できるようになります。

• マッチオプション。実行時マッチングのためのあいまい度や演算子などのオプション。

• ベクトル検索。行ごとに埋め込みを生成し、実行時にdense_vector式に対してk近傍法（kNN）を実行することで、インデックス化されていないデータにもセマンティック検索を適用できるようにします。

ES|QLの全文検索を今すぐ試す

実行時検索を今すぐお試しください。新しいES|QL機能が最初に実装されるElastic Cloud Serverlessでは現在利用可能で、Elasticsearch 9.5ではテクニカルプレビューとして提供されます。まず検索関数の参照から始め、ES|QLの制限ページで現在の制限を確認してください。これはテクニカルプレビュー版であり、皆様からのフィードバックをお待ちしています。これまでインデックス登録されていなかったものを検索して、良い意味でも悪い意味でも驚いたことがあれば、ぜひお聞かせください。

1. _mapping API を使用してフィールド情報を取得する

2. _search API を使用してフィールド値を表示する

3. サブフィールドの表示

4. Synthetic _source

5. ランタイムフィールド

1. _mapping APIを使用してフィールド情報を取得する

_mapping API を使用すると、1 つまたは複数のインデックスのマッピング定義を取得できます。これには、フィールド、そのデータ型、およびその他のプロパティに関する情報が含まれます。特定のインデックスのマッピングを取得するには、次のリクエストを使用します。

たとえば、 my_indexという名前のインデックスがある場合、次のリクエストでそのマッピングを取得できます。

応答には、フィールドとそのプロパティに関する情報を含むインデックスのマッピング定義が含まれます。

特定のフィールドのマッピングを取得することもできます。これは、マッピングが非常に大きく、特定のフィールドにのみ焦点を当てたい場合に便利です。特定のフィールドのマッピングを取得するには、次のリクエストを使用します。

次のリクエストのように、フィールド名をコンマで区切ることで、複数のフィールドのマッピングを取得することもできます。

2. _search APIを使用してフィールド値を表示する

Elasticsearch インデックス内のフィールドの値を表示するには、 _search API を使用できます。_search API では、返されるフィールドを制御する方法が複数用意されています。主な方法は次の 2 つです。

1. _source: _sourceフィールドには、取り込みパイプラインまたは前処理手順によって行われた変更も含め、インデックスが作成されたとおりの元の JSON ドキュメント本体が含まれます。ソース ドキュメントの特定のフィールドを表示するには、以下に示すようにソース フィルタリングを実装します。

2. fields: fieldsパラメータを使用すると、インデックス マッピングに基づいて検索を実行するときにドキュメントから特定のフィールドを取得できます。_sourceとは異なり、 fields _sourceを参照せずに、保存されたフィールド、ドキュメント値、またはランタイム フィールドから値を返すこともできます。ただし、ドキュメント値や保存された設定のない標準フィールドの場合は、 _sourceにフォールバックします。これによって、後述するように、パフォーマンスなど多くの利点が得られます。

_source フィールドの使用

デフォルトでは、 _search API は、インデックスが作成された元の JSON ドキュメントを含む_sourceフィールドを返します。特定のフィールドを表示するには、検索リクエストの_source パラメータにフィルターを追加できます。これはソース フィルタリングと呼ばれます。

以下は、 my_indexインデックス内のドキュメントのtitle フィールドとauthorフィールドの値を返す検索要求の例です。

この例では、 _sourceパラメータは返されるフィールドを指定します。

さらに詳細な制御が必要な場合は、 _sourceオブジェクトのincludesプロパティとexcludes プロパティを使用できます。たとえば、次のクエリは、トップレベルのtitleフィールドと、 author.descriptionを除くauthorのすべてのサブフィールドを返します。

この例では、 author.* パターンを使用して、 author オブジェクトのすべての直接サブフィールドを取得します。次に、 author.description 明示的に除外して、他の著者フィールドのみが返されるようにします。ソース JSON を読み込んで解析する必要があるため、パフォーマンスは向上しませんが、ネットワーク経由で送信される応答のサイズは小さくなることに注意してください。

フィールドパラメータの使用

fieldsパラメータを使用して、検索応答で返されるフィールドをフィルタリングできます。_sourceではなくfieldsを使用すると、次のようないくつかの利点があります。

• パフォーマンスの向上: fields 、 _source全体をロードせずに、保存されたフィールドまたはドキュメント値から直接値を返すことができるため、応答のペイロード サイズが小さくなります。

• フォーマットされた出力:標準フィールドの場合、 fields値を取得するために_sourceにフォールバックすることがありますが、インデックス マッピングを参照して、フォーマットされた日付などの出力を適切にフォーマットし、集計や並べ替えに使用されるものと一貫性を保ちます。

• ランタイム フィールドへのアクセス: fields 、元の_sourceには存在しないランタイム フィールドを返す場合があります。

• さらに詳しい特典については、こちらをご覧ください。

たとえば、 my_indexインデックス内のtitleフィールドとauthorフィールドのみを返すには、次の検索リクエストを使用できます。

上記のクエリでは、 _source フィールドを false に設定して、ソース ドキュメントを返さないようにします。これにより、応答のペイロード サイズを大幅に最小化できますが、これが機能するのは、フィールドtitleとauthorがkeyword フィールド タイプであり、デフォルトでdoc_values有効になっている場合のみであることに注意してください。フィールドでdoc_values有効になっておらず、 _sourceが false に設定されている場合、Elasticsearch はそれらを取得する方法がなく、応答でスキップされます。

fieldsレスポンスでは、値が 1 つしかない場合でも、常に各フィールドの値の配列が返されることに注意してください。これは、Elasticsearch に専用の配列タイプがなく、どのフィールドも複数の値を持つ可能性があるためです。Elasticsearch の配列の詳細については、ここをクリックしてください。

フィールドを取得する他の方法

_sourceまたはfieldsを使用してフィールドを取得する方法が推奨されますが、特定のユースケースでは次のような異なる方法も使用できます。

ドキュメント値フィールド: _source完全に回避したい場合は、 docvalue_fields パラメータを使用して検索できます。Doc 値は_sourceと同じフィールド値を、並べ替えと集計に最適化されたディスク上のデータ構造で保存します。

これは_sourceで保存された値とは別であるため、 _source全体をロードせずに特定のフィールドを要求できます。これは、大きなドキュメントをクエリしているが、ドキュメント値をサポートするいくつかの小さなフィールドのみが必要な場合に便利です。docvalue_fields 使用するもう 1 つのユース ケースは、以下の例に示すように、 dateとnumericフィールドでカスタム フォーマットを使用する場合です。

これは、 doc_values有効にしたフィールド、またはkeyword 、 date 、数値型、 booleanなど、デフォルトで有効になっているフィールド タイプに対してのみ機能し、 textまたはannotated_textに対しては機能しないことに注意してください。

この例では、 docvalue_fieldsパラメータを使用して、 _sourceドキュメント全体をロードせずにtitle 、 author 、およびpublishedフィールドを取得します。

このクエリを実行すると、Elasticsearch は各ドキュメントの_source を参照するのではなく、ディスク上の列ストアから直接値を取得します。クエリに指定されたformatパラメータにより、 publishedフィールドはデフォルトの形式ではなくepoch_millis形式で返されます。

保存されたフィールド:特定のフィールドをマッピングに保存されているものとして明示的にマークした場合は、 stored_fieldsパラメータを使用してそれらのフィールドをフィルターできます。これは、特定のフィールドのみで簡単な応答が必要な場合や、後で検索するために意図的に保存したフィールドの場合に便利です。これは_sourceとは別に保存されるため、このメソッドは_sourceをロードする必要を回避するのにも役立ちます。

このオプションはデフォルトでオフになっており、通常は推奨されないことに注意することが重要です。代わりにソース フィルタリングを使用して、元のソース ドキュメントの特定のサブセットを返します。

以下のサンプルクエリでは、 stored_fieldsパラメータを使用して、インデックス マッピング構成が「 store”: true 」であるsummaryフィールドを取得します。

このクエリが実行されると、Elasticsearch はこのフィールドが”store”: trueでマークされているかどうかを確認し、見つからない場合はフィールド全体をスキップします。

3. サブフィールドの表示

インデックスにサブフィールドが含まれている場合は、ドット表記を使用してfieldsパラメータでフィールド パスを指定できます。サブフィールドはネストされたフィールド タイプとは異なることに注意してください。たとえば、 address.cityという名前のサブフィールドがある場合、次のように検索応答に含めることができます。

この例では、検索応答にはtitle 、 author 、およびaddress.cityフィールドの値が含まれます。

4. 合成_ソース

_sourceを使用する機能を維持しながらディスク領域を節約したい場合は、インデックス マッピングで合成_sourceを使用するオプションがあります。合成_sourceは、 _sourceが無効になっている場合でも、Elasticsearch が保存されたフィールドやドキュメント値などの既存のデータから_sourceを再構築できるようにする機能です。これにより、再構築がオンザフライで行われるため、クエリ時の速度が若干低下しますが、多くのストレージ スペースを節約できます。インデックス設定で以下の値を使用してこの機能を有効にします。

合成_source を使用する利点としては、 _search API 使用時の完全なドキュメント表示、ソース フィルタリング、 _sourceが利用可能であると想定されている Kibana などの他の機能やツールとの互換性などが挙げられますが、これらはすべて、完全な_sourceドキュメントを保存する必要性を回避しながら実現できます。

5. ランタイムフィールド

ランタイム フィールドを使用すると、クエリ時またはランタイム ブロックの下のインデックス マッピングでスクリプト フィールドを定義できます。これらのフィールドにはインデックスが付けられないため、ランタイム フィールドを追加してもインデックス サイズは増加しませんが、 _sourceには表示されません。マッピングで定義されたランタイム フィールドは永続的であり、すべてのクエリで使用できますが、クエリ時に定義されたランタイム フィールドは一時的であり、その検索要求でのみ使用できます。

ランタイム フィールドを使用する主な利点は、ドキュメントを取り込んだ後にフィールドを追加できるため、マッピングの決定が簡素化されることです。ランタイム フィールドは、文字列の書式設定やスコアの計算など、元のドキュメントには存在しないがスクリプトを使用して生成された値でドキュメントを充実させるのにも最適です。

また、結果セット内のすべてのドキュメントに対してスクリプトを実行する必要があるため、ランタイム フィールドはパフォーマンスに悪影響を与える可能性があることにも注意してください。ランタイム フィールドを取得するには、 _search API のfieldsパラメータを使用することもできます。

まとめ

Elasticsearch インデックスのフィールドの表示は、インデックス マッピングまたは_sourceを使用して単純に値を取得する方法から、 fields 、 docvalue_fields 、またはランタイム フィールドを使用して制御と効率性を高めるより高度な方法まで多岐にわたります。さまざまな方法間のトレードオフを理解することが、検索エクスペリエンスを最適化する鍵となります。ペイロードを最適化したり、ドキュメントを充実させたり、合成_sourceを使用してストレージを節約したりする場合でも、Elasticsearch は必要なデータを必要な方法で見つけるための複数のツールと機能を提供します。これらの手法は、データの構造を理解し、特定のフィールドを識別し、問題のトラブルシューティングを行うのに役立ちます。

この記事では、これらのフィールド タイプ、それぞれのフィールド タイプをいつ使用するか、インデックス作成時とクエリ時の両方で埋め込み生成と使用戦略にどのように関連するかについて説明します。

密ベクトル型

Elasticsearch のdense_vectorフィールド タイプは、ほぼすべての次元が関連する、テキスト、画像、音声などのデータの数値表現である密なベクトルを格納するために使用されます。これらのベクトルは、OpenAI、Cohere、Hugging Face などのプラットフォームによって提供される埋め込みモデルを使用して生成され、他のドキュメントと正確な用語を共有していない場合でも、データの全体的な意味をキャプチャするように設計されています。

Elasticsearch では、使用されるモデルに応じて、密なベクトルは最大 4096 次元を持つことができます。たとえば、all-MiniLM-L6-v2 モデルは 384 次元のベクトルを生成しますが、OpenAI の text-embedding-ada-002 は 1536 次元のベクトルを生成します。

dense_vectorフィールドは、事前に生成されたベクトルの使用、カスタム類似度関数の適用、外部モデルとの統合など、より高度な制御が必要な場合に、この種の埋め込みを格納するためのデフォルトのタイプとして一般的に採用されています。

dense_vector 型をいつ、なぜ使用するのでしょうか?

高密度ベクトルは、文、段落、またはドキュメント全体の間の意味的な類似性を捉えるのに最適です。同じ用語を共有していなくても、テキストの全体的な意味を比較することが目的の場合、非常に効果的です。

密ベクトル フィールドは、OpenAI、Cohere、Hugging Face などのプラットフォームによって提供されるモデルを使用した外部埋め込み生成パイプラインが既にあり、これらのベクトルを手動で保存およびクエリするだけの場合に最適です。このタイプのフィールドは、埋め込みモデルとの高い互換性と、生成およびクエリの完全な柔軟性を提供し、検索中にベクトルがどのように生成、インデックス付け、使用されるかを制御できます。

さらに、ランキングロジックを調整する必要がある場合には、k-NN や script_score などのクエリを使用して、さまざまな形式のセマンティック検索をサポートします。これらの可能性により、高密度ベクトルは、RAG (検索拡張生成)、推奨システム、類似性に基づくパーソナライズされた検索などのアプリケーションに最適です。

最後に、このフィールドでは、 cosineSimilarity 、 dotProduct 、 l2normなどの関数を使用して関連性ロジックをカスタマイズし、ユースケースのニーズに応じてランキングを調整できます。

柔軟性、カスタマイズ性、および上記のような高度なユースケースとの互換性を必要とする人にとって、高密度ベクターは依然として最適なオプションです。

密ベクター型のクエリを使用するにはどうすればいいですか?

dense_vectorとして定義されたフィールドの検索では、k 近傍クエリが使用されます。このクエリは、密なベクトルがクエリ ベクトルに最も近いドキュメントを見つける役割を果たします。以下は、密なベクトル フィールドに k-NN クエリを適用する方法の例です。

k-NN クエリに加えて、ドキュメントのスコアリングをカスタマイズする必要がある場合は、script_score クエリを使用して、 cosineSimilarity、dotProduct、l2normなどのベクトル比較関数と組み合わせて、より制御された方法で関連性を計算することもできます。例を参照してください:

さらに詳しく知りたい場合は、 「Elasticsearch でベクトル検索を設定する方法」の記事を参照することをお勧めします。

スパースベクトル型

sparse_vectorフィールド タイプは、ほとんどの値がゼロで、少数の項のみに重要な重みがある数値表現であるスパース ベクトルを格納するために使用されます。このタイプのベクトルは、SPLADE や ELSER (Elastic Learned Sparse EncodeR) などの用語ベースのモデルで一般的です。

スパースベクトル型をいつ、なぜ使用するのでしょうか?

スパースベクトルは、意味的インテリジェンスを犠牲にすることなく、語彙的により正確な検索が必要な場合に最適です。テキストをトークン/値のペアとして表現し、関連する重みを持つ最も関連性の高い用語のみを強調表示することで、明確さ、制御性、効率性を実現します。

このタイプのフィールドは、テキスト内の相対的な重要度に基づいて各トークンに異なる重みを割り当てる ELSER モデルや SPLADE モデルなどの用語に基づいてベクトルを生成する場合に特に役立ちます。

クエリ内の特定の単語の影響を制御したい場合には、スパースベクター型を使用すると、用語の重みを手動で調整して、結果のランキングを最適化できます。

主な利点としては、ドキュメントが関連性があると判断された理由を明確に理解できるため検索の透明性が高く、また、すべての次元を保存する密なベクトルとは異なり、ゼロ以外の値を持つトークンのみが保存されるためストレージ効率が高くなる点が挙げられます。

さらに、スパース ベクトルはハイブリッド検索戦略の理想的な補完であり、稠密ベクトルと組み合わせて語彙の精度と意味の理解を組み合わせることもできます。

スパースベクトル型のクエリを使用するにはどうすればいいですか?

sparse_vectorクエリを使用すると、トークン/値形式のクエリ ベクトルに基づいてドキュメントを検索できます。以下のクエリの例を参照してください。

トレーニング済みのモデルを使用する場合は、クエリ テキストをスパース ベクトルに自動的に変換する推論エンドポイントを使用できます。

このトピックをさらに詳しく調べるには、 「トレーニング済み ML モデルによるスパース ベクトル埋め込みの理解」を読むことをお勧めします。

セマンティックテキストタイプ

semantic_textフィールド タイプは、Elasticsearch でセマンティック検索を使用する最もシンプルで簡単な方法です。推論エンドポイントを通じて、インデックス作成時とクエリ時の両方で埋め込み生成を自動的に処理します。つまり、ベクトルを手動で生成したり保存したりする手間がかかりません。

セマンティックテキストはいつ、なぜ使用するのでしょうか?

semantic_textフィールドは、最小限の技術的労力で、ベクトルを手動で処理することなく開始したい場合に最適です。このフィールドは、埋め込み生成やベクトル検索マッピングなどの手順を自動化し、セットアップをより速く便利にします。

シンプルさと抽象化を重視する場合は、マッピング、埋め込み生成、および取り込みパイプラインを手動で構成する複雑さが排除されるため、 semantic_text使用を検討する必要があります。推論モデルを選択するだけで、残りの作業は Elasticsearch が処理します。

主な利点としては、インデックス作成とクエリの両方で実行される自動埋め込み生成と、選択した推論モデルをサポートするように事前構成された、すぐに使用できるマッピングが挙げられます。

さらに、このフィールドは長いテキストの自動分割 (テキスト チャンク) をネイティブにサポートしており、大きなテキストをそれぞれ独自の埋め込みを持つ小さな段落に分割できるため、検索の精度が向上します。これにより、特にセマンティック検索の基礎となるエンジニアリングを扱うことなく価値を迅速に提供したいチームにとって、生産性が大幅に向上します。

ただし、 semantic_textスピードとシンプルさを提供しますが、このアプローチにはいくつかの制限があります。Elasticsearch の推論エンドポイントとして利用できる限り、市場標準モデルの使用が可能になります。ただし、 dense_vectorフィールドの場合のように、外部で生成された埋め込みはサポートされません。

ベクトルの生成方法をより細かく制御する必要がある場合、独自の埋め込みを使用する場合、または高度な戦略のために複数のフィールドを組み合わせる必要がある場合は、 dense_vectorフィールドとsparse_vectorフィールドによって、よりカスタマイズされたシナリオやドメイン固有のシナリオに必要な柔軟性が得られます。

セマンティックテキストタイプのクエリの使用方法

semantic_textより前は、埋め込みの種類 (密または疎) に応じて異なるクエリを使用する必要がありました。スパースフィールドにはsparse_vectorクエリが使用されましたが、 dense_vectorフィールドには KNN クエリが必要でした。

セマンティック テキスト タイプでは、セマンティック クエリを使用して検索が実行されます。セマンティック クエリは、クエリ ベクトルを自動的に生成し、それをインデックス付けされたドキュメントの埋め込みと比較します。semantic_textタイプでは、クエリを埋め込むための推論エンドポイントを定義できますが、何も指定されていない場合は、インデックス作成時に使用されたのと同じエンドポイントがクエリに適用されます。

詳細については、 「Elasticsearch の新しい semantic_text マッピング: セマンティック検索の簡素化」という記事を読むことをお勧めします。

まとめ

Elasticsearch で埋め込みをマッピングする方法を選択するときは、ベクトルを生成する方法とベクトルに対して必要な制御レベルを理解することが重要です。シンプルさを求める場合、セマンティック テキスト フィールドを使用すると、自動かつスケーラブルなセマンティック検索が可能になり、多くの初期使用ケースに最適です。より高度な制御、微調整されたパフォーマンス、またはカスタム モデルとの統合が必要な場合は、密ベクトル フィールドと疎ベクトル フィールドが必要な柔軟性を提供します。

理想的なフィールド タイプは、ユース ケース、利用可能なインフラストラクチャ、機械学習スタックの成熟度によって異なります。最も重要なのは、Elastic が最新の、適応性に優れた検索システムを構築するためのツールを提供していることです。

参照資料

• セマンティックテキストフィールドタイプ

• スパースベクトル場型

• 密ベクトル場型

• セマンティッククエリ

• スパースベクトルクエリ

• kNN検索

• Elasticsearchの新しいsemantic_textマッピング：セマンティック検索の簡素化

• 学習済み ML モデルによるスパースベクトル埋め込みの理解