Elasticsearch simdvecの構築方法

Elasticsearchにおけるすべてのベクトル検索クエリは、Hierarchical Navigable Small World（HNSW）トラバーサル、転置ファイル（IVF）スキャン、再ランキングパスのいずれであっても、結局は同じ問題に帰着します。すなわち、クエリごとにベクトル間の距離を何百万回も計算しなければならないということです。Elasticsearchは、float32からint8、bfloat16、バイナリ、Better Binary Quantization（BBQ）まで、幅広いデータ型と量子化戦略をサポートしています。それぞれにメモリ、スループット、リコールのトレードオフが異なります。そのすべての背後にあるのは、simdvecという単一のエンジンです。

私たちは、ハードウェアが許す限りすべての距離計算を高速に行うためにsimdvecを構築しました。この記事では、simdvecを構築した理由、その内部構造、そしてどのような場面で最も効果を発揮するのかを説明します。

レースカーのような構造

F1愛好家として（当社チームには以前フェラーリのF1チームで勤務経験があるメンバーもいます）明確な類似点を見いだせます。F1カーは、最高のラップタイムを達成するという唯一の目的のために設計されています。エンジンのパワー、空力性能、シャーシ設計は、その結果に貢献する限りにおいてのみ重要です。ベクトルデータベースについても同様で、インデキシングのスループット、クエリのレイテンシ、リコールが成功を定義します。

最終結果は重要ですが、最高レベルのパフォーマンスを達成するには、各コンポーネントが最高の状態である必要があります。必要十分ではなく、そのカテゴリーで最高でなければなりません。simdvecはその考え方で構築されており、システムの重要な部分であるエンジンに焦点を当てています。これは、専用に構築された、単一命令多重データ（SIMD）最適化カーネルライブラリで、JavaからPanama外部関数インターフェース（FFI）を介して呼び出される、手動で調整されたネイティブC++距離関数を提供します。一括スコアリング、キャッシュラインのプリフェッチ、Elasticsearchで使用されるすべてのベクトルの種類とレイアウトをサポートしています。

それがすべてのクエリの背後にあるエンジンです。

自社開発した理由

当社は2023年にApache LuceneのPanama Vector APIを使用してスタートしました。float32の内積計算にはうまく機能しましたが、すぐにその機能ではElasticsearchのニーズには対応できなくなりました。Elasticsearchは、int8、int4、bfloat16、シングルビット、非対称BBQなど、幅広い量子化されたベクトルタイプをサポートしています。それぞれにSIMD戦略、パッキングレイアウト、アキュムレータの要件が異なります。型カバレッジに加えて、Elasticsearchのスコアリングパスは単一ペアのスループット以上のものを要求します。HNSWは1回のパスで複数のグラフ隣接ノードをスコアリングする必要があり、IVFはプリフェッチを使用して数千の候補を一括スコアリングする必要があり、ディスクベースのスコアリングはコピーせずにmmapされたメモリ上で直接動作する必要があります。入手可能なものを調べてみましたが、すべての条件を満たすものは見つかりませんでした。

そこで、simdvecを構築しました。これは、JavaからFFI経由で呼び出される手作業で調整されたネイティブC++カーネルで、一括スコアリング、プリフェッチ、Elasticsearchが使用するすべてのベクトルタイプをサポートしています。ライブラリを所有することで、私たちはフルスタックを制御できます。BBQのような新しい量子化タイプを追加すると、システム全体にわたって調整されたSIMDカーネルが組み込まれます。上流のライブラリがそれをサポートするのを待つ必要はなく、いかなる型においてもパフォーマンスに妥協することはありません。Elasticsearchにおけるすべてのベクトルクエリ（HNSW、IVF、リランキング、ハイブリッドなど）は、実際に使用する操作とタイプに基づいて構築されたこのエンジン上で実行されます。

simdvecには、x86とARMそれぞれに対応したネイティブライブラリが用意されており、起動時に複数の命令セットアーキテクチャ（ISA）階層を選択できます。FFIを介したJavaからの呼び出しオーバーヘッドは非常に低く、1桁ナノ秒です。

ランドスケープ

SIMD最適化されたベクトル距離カーネルを構築しているのは私たちだけではありません。このエコシステムは豊かで、私たちはsimdvecがどのように動作するのかを理解したいと考えました。プロジェクトの優劣を決めるのではなく、背景情報を提供し、Elasticsearchエンジンの位置づけを説明することが目的です。私たちは異なるアプローチを表す3つのプロジェクトを基準点として選びました。

• jvector：ベクトル化された距離計算にPanama Vector APIを使用するJava近似最近傍探索（ANN）ライブラリ。x86上ではオプションでネイティブCアクセラレーションが可能。

• FAISS：手作業で調整されたAVX2/AVX-512カーネルを備えた、広く展開されているオープンソースのベクトル検索フレームワーク。

• NumKong （旧称 SimSIMD）：距離関数、行列演算、地理空間計算など、2,000種類以上の手作業で調整されたSIMDカーネルを網羅した包括的なスイート。

各プロジェクトは異なる目的を持ち、異なるトレードオフをもたらします。Elasticsearchが必要とする特定の操作におけるsimdvecのパフォーマンスのコンテキストを提供するために、それらからの参照番号を含めています。

測定方法

simdvecとjvectorのベンチマークは、FFIオーバーヘッドを含めた標準JVMマイクロベンチマークハーネスであるJMHを使用してJavaで記述されています。NumKongベンチマークとFAISSベンチマークについては、標準的なC++マイクロベンチマークフレームワークであるGoogle Benchmarkを使って小さなC/C++ハーネスを作成しました。どちらのフレームワークも、ウォームアップと反復キャリブレーションを含めた1操作あたりのナノ秒数の精度を報告しています。ハードウェアパフォーマンスカウンターを介して、すべてのライブラリが両方のプラットフォームでSIMDを使用していることを確認しました。ベンチマークコードはすべて、リンク先のGitHubリポジトリ（およびsimdvecの場合はelasticsearchリポジトリ）で公開されています。

ソフトウェア： JDK 25.0.2、JMH 1.37、GCC 14、Google Benchmark（最新版）。

一度に1つのベクトル

ベクトル検索における最も基本的な操作は、2つのベクトル間の距離を計算することです。すべてのHNSW近隣評価、すべてのIVF候補スコア、すべての再ランク比較は、この内側のループに還元されます。

両プラットフォームで1024次元における単一ペアのスループットを測定しました。まず、ベースラインとなる型であり、エコシステムの競争が最も激しいfloat32から評価を開始しました。simdvecをFAISSおよびjvectorと比較しました。NumKongはfloat32にfloat64アキュムレータを使用するため、スループットよりも数値精度を優先し、処理速度が3.2倍から5.3倍遅くなる（プラットフォームによって異なる）ため、比較対象から除外しました。比較を同じように保つために、代わりにint8でNumKongのベンチマークを行います。ここでは、simdvecと同じアキュムレータ戦略を使用しています。

x86アーキテクチャーでは、FAISS AVX-512が23ナノ秒と最速のシングルペアカーネルです。simdvec AVX-512は28ナノ秒で続きますが、この差はFFI呼び出しのオーバーヘッドを反映したものです。どちらもマルチアキュムレータアンローリングを備えた512ビットFMAを使用しています。AVX2レベルでは、両者の性能差ははるかに小さく、それぞれ36ナノ秒と39ナノ秒で、どちらも256ビットのレジスタとメモリのロード幅によって制約されています。jvectorはJava Panama Vector APIを使用して44ナノ秒で到達します。Panamaは優れたSIMDコードを生成しますが、手作業で調整されたC++ intrinsicsが優位を保っています。

ARMでは、simdvecは70ナノ秒でリードしており、110ナノ秒のjvectorと156ナノ秒のFAISSをはるかに上回っています。simdvecはaarch64向けにNEONカーネルを独自にチューニングしました。JvectorにはネイティブのARMコードがなく、Panamaに依存しています。FAISSは明示的なNEON組み込み関数ではなく、コンパイラの自動ベクトル化に依存しているため、差が大きくなっています。これは、カーネルライブラリを所有することによる実用的な利点を反映しています。ElasticsearchがGravitonに拡張された際、専用に構築されたNEONカーネルを追加しました。jvectorもFAISSも、ARMネイティブコードを同程度に優先しているわけではありません。

しかし、Elasticsearchはfloat32だけを評価するわけではありません。Int8の量子化はメモリ使用量を4分の1に削減し、bfloat16は2分の1に、BBQは32分の1に削減します。それぞれのタイプには独自のSIMD戦略が必要であり、simdvecはすべてのタイプ向けに手動チューニングされたネイティブカーネルを提供しています。

比較したライブラリの中で、int8用の同等のカーネルを備えているものはNumKongのみでした。int8ドット積、二乗ユークリッド、余弦を1024次元で測定しました。

Int8シングルペアスコアリング（1024次元、ns/vec 演算 - 数値が小さいほど良い）

どちらのアーキテクチャでも、NumKongは小～中次元では同等かより高速です。その差は主に呼び出しのオーバーヘッドが少ないことに起因します（Cの直接呼び出しとJavaのFFI）。より大きな次元では、simdvecが追いつき、より効率的なカーネル実装（カスケードアンローリングを使用する）が呼び出しコストを償却します。次元が増えるにつれて、このギャップは閉じ、最終的には逆転します。クロスオーバーのサイズは、機能や構造によって768から1536の間となります。

Java FFIのオーバーヘッドが若干高いにもかかわらず、simdvecは高度に最適化されたC/C++ライブラリと同等の性能を発揮します。float32とint8の両方に対応した最適化されたカーネルを備えた唯一のライブラリであるだけでなく、ARMアーキテクチャではトップクラスの性能を誇り、x86アーキテクチャではFAISSにわずかに劣る程度（float32の場合）、そして両アーキテクチャにおいてNumKongに非常に近い性能（int8の場合）を実現しています。また、bfloat16、int4、binary、BBQについては、代替手段は存在するものの、simdvecは各型のデータレイアウトに合わせて手作業で調整されたSIMDによって差別化を図っています。

しかし、実際の検索エンジンは一度に1つのベクトルを評価するのではなく、クエリごとに数千のベクトルを評価します。次の質問は、そのスケールで何が起こるかということです。

一度に数千件

シングルペアのパフォーマンスは全体の一部に過ぎません。実際には、システムが負荷時にどのように動作するかが重要です。単一のHNSWクエリは数百のグラフ近傍をスコアリングすることがあります。IVFスキャンは、数千件の投稿リストエントリーをスコアリングすることがあります。リランクパスは数万の候補をスコアリングすることがあります。シングルペアのスループットは重要ですが、より重要なのは、多くのベクトルをどれだけ速くスコアリングできるか、そして作業セットがCPUキャッシュから溢れ出すにつれてパフォーマンスがどれだけスムーズに低下するかです。

simdvecは、あらゆるデータタイプに対して一括スコアリング機能を提供します。これらは単なる単一ペアカーネル上のループではなく、クエリベクトルを1次元ストライドごとに1回ロードし、複数のドキュメントベクトル間で共有するマルチアキュムレータ内部ループを使用します。次のバッチに対しては、明示的なキャッシュラインプリフェッチが行われます。jvectorもFAISSも同等の機能を提供していません（執筆時点では）。Jvectorには一括処理APIがないため、呼び出し元はループ内で一度に1組ずつスコアを計算します。FAISSはfvec_inner_products_nyを公開していますが、執筆時点では、クエリ償却やプリフェッチを行わずに、シングルペア距離関数のループとして実装されています。

Float32。カーネルレベルでのインパクトを測定するために、HNSWのような散在グラフの近傍検索をシミュレートするランダムアクセスパターンを用いて、1024次元float32ドキュメントベクトルの数を増やしながら単一のクエリのスコアを計算しました。3つのデータセットサイズ（32、625、32,500ベクトル）は、それぞれL1、L2、L3キャッシュを超えるように選択されています。

データがキャッシュに収まる場合、simdvecはどちらのプラットフォームでも最速ですが、カーネル演算が支配的であるため、マージンは控えめです。実際の分離は、ワーキングセットがL3を超えるにつれて現れます。x86では、simdvecのスコアは1ベクトルあたり95ナノ秒ですが、FAISSは165ナノ秒、jvectorは412ナノ秒です。ARM上でも同様の傾向が見られ、simdvecは162ナノ秒で安定しているのに対し、FAISSは347ナノ秒、jvectorは476ナノ秒に上昇します。simdvecのプリフェッチとクエリの償却により、シングルペアカーネル上の単純なループでは対応できない方法でメモリの待ち時間が隠され、メインメモリの奥深くで実際の検索ワークロードが動作する場所でその利点が広がります。

Int8。同じパターンは量子化された型にも当てはまります。int8ドット積の一括スコアリングを1024次元で測定し、データセットのサイズが同じL1、L2、L3キャッシュ境界を超えるように選択して、simdvecのバルクスコアリングをループ内のNumKongシングルペアスコアリングと比較しました。

x86では、simdvecは1.2倍～1.9倍高速で、これは明示的なプリフェッチとバッチ処理の組み合わせによってもたらされます。ARM環境では、すべてのデータセットサイズにおいて、simdvecが再び優位に立ちました（1.7倍から1.9倍高速）。その利点は、4つのベクトルを一度にバッチ処理することで、インターリーブアクセスパターンを介してメモリレベルの並列処理を実現することにあります。いずれの場合も、最も顕著な結果は最大のデータセットサイズで何が起こるかであり、それが最も重要な場所です。

結果は、二乗距離とコサインで同様のパターンを示し、ARMでは1.4倍から1.8倍、x86では1.3倍から3.0倍の速度向上が見られました（詳細はこちら）。

メモリが重要となる場合

本番環境のベクトルインデックスは通常、CPUキャッシュに収まりません。1024次元の10Mベクトルint8インデックスは10GBです。候補のスコアリングとは、DRAMからデータをストリーミングすることを意味し、そこでバルクスコアリングアーキテクチャが大きな違いを生むのです。

バルクスコアリング中のCPU内部で何が起こるかを測定するためにハードウェアパフォーマンスカウンターを使用し、メモリーレイテンシを隠すためには、アーキテクチャごとに根本的に異なる2つの戦略が必要であることを発見しました。

x86アーキテクチャでは、明示的なプリフェッチによってキャッシュミスが解消されます。バルクカーネルはベクトルを逐次的に処理し、次のベクトルを処理する前に1つのベクトルを完全に計算しながら、次のバッチのためのプリフェッチ命令を発行します。将来のデータはCPUが必要とする前にL1に取り込まれます。

ARMアーキテクチャでは、プリフェッチを使用しても、同じ逐次的なアプローチではパフォーマンスが低下しました。代わりに、バルクカーネルが4つのベクターからすべてのストライド位置でロードをインターリーブし、アウトオブオーダーエンジンに4つの独立したメモリストリームを提供します。CPUのデータの取得速度が速くなったわけではなく、メモリ要求の処理中に常に別の計算処理を行うことで、待ち時間を短縮しているのです。詳細な分析についてはこちらのGitHubイシューをご覧ください。

数字は2つの異なる物語を語っています。

1. x86アーキテクチャでは、プリフェッチによって139,000回のキャッシュミスが19,000回に減り、1サイクルあたりの命令実行数（IPC）が2倍以上になります。データセットのサイズが大きくなるにつれてプリフェッチによってコストのかかるDRAM往復処理が徐々に隠蔽されるため、データ量の増加によるメリットは大きくなり、L2レベルでは1.2倍、L3レベルを超えると2.8倍になります。

2. ARMではキャッシュミスはほとんど変わりません。変化するのは利用率です。インターリーブアクセスパターンによってパイプラインへの供給が維持されるため、バックエンドの停止時間が40%減少します。この利点は、データセットのサイズに関係なく一貫して1.8倍です。これは、データがキャッシュまたはDRAMから来ているかに関係なく、メモリレベルの並列処理が適用されるためです。

2つのアーキテクチャ、2つの戦略、結果は1つ：本番環境規模では、simdvecはベクトルがメインメモリ全体に分散している場合でも、CPUパイプラインを常にフル稼働させます。

Elasticsearchユーザーへの影響

これらのカーネルレベルの能力は相乗効果を発揮します。単一のベクトル検索クエリでは、HNSWグラフの走査、候補のスコアリング、再ランキングなど、数百万もの距離演算が計算される場合があります。数千回の同時クエリにおいて、1回の操作でナノ秒単位がクエリ遅延やクラスタスループットに直接変換されます。float32、int8、bfloat16、BBQのいずれを使用する場合でも、インデックスがメモリ上にあるかディスク上にあるかに関わらず、simdvecが基盤となるエンジンであり、これらのすべての操作は同じエンジンを通して実行され、ナノ秒単位まで最適化されています。

重要なポイントは、本番規模では、ベクトル検索のパフォーマンスは主に生のSIMDスループットによって決まるわけではないということです。システムのパフォーマンスは、数百万もの小さな演算処理において計算能力を維持しながら、メモリの遅延をいかに効率的に隠蔽できるかに大きく左右されます。

simdvecカーネルは、ほぼすべてのElasticsearchリリースで改善されています。新しい量子化タイプやハードウェアプラットフォームが登場すると、初日からチューニング済みのカーネルが提供されます。また、既に出荷されている実装を改良していくにつれて、既存の型もますます高速化していきます。

そこで、Elasticは読み取り専用のダッシュボードを開発しました。求めていたコントロールが獲得でき、安心してダッシュボードを共有できます。編集アクセス権を持つ別の人が変更したり壊したりすることを心配する必要はありません。

注：読み取り専用の権限は、Elastic Cloud ServerlessおよびElastic Cloud Hosted、Elastic Self-Managedのバージョン9.3以降で利用可能です。

「すべてのユーザーが編集可能」権限が妨げになる場合

Kibanaにおいて、共有は通常、スペースレベルの権限を意味していました。誰かがスペースでダッシュボードを作成できる場合、他の人のダッシュボードも編集または削除できます。コラボレーションにとっては便利ですが、場合によってはそうとも言い切れません。たった一度の意図しない編集が、誤った判断、信頼の喪失、そして多大な後始末へと連鎖的に影響を及ぼす可能性があります。

ダッシュボード名に「read-only」と入れて皆が気づくことを期待するとか、タグを付けてうまくいくことを祈るといった回避策もあるにはありますが、期待と権限モデルはイコールではありません。必要なのは、スペースから全員を締め出すことなくダッシュボードをロックするための現実的な手段でした。

問題の実例

DebとKevinはどちらも、オペレーションスペース内のログ監視ダッシュボードへの編集権限を持っています。Kevinがチャートにいくつか変更を加えます。Debがダッシュボードに戻ると、数字は彼女が提示したものと一致しませんでした。彼女は（多くの場合記憶を頼りに）何が変更されたのかを突き止め、それを修正し、どれだけの報告書が誤ったデータで送信されたのかを考えなければならなくなります。

読み取り専用ダッシュボード：理にかなった所有権と制御

読み取り専用のダッシュボードでは、他のユーザーがダッシュボードを編集できるかどうかを管理できます。ダッシュボードを共有する際、編集（デフォルト：従来どおり）または閲覧を選択します。閲覧モードでは、あなた（とKibana管理者）のみが変更または削除できます。他のユーザーは開いて利用できますが、変更することはできません。

手に入るもの

• ダッシュボードの整合性：閲覧モードでは、スペースで編集アクセス権を持つ他のユーザーはダッシュボードを変更または削除できません。操作を試みると、ロックされているというメッセージが表示されます。グラフとロジックは設定した状態のまま維持されます。

• コントロールを維持：コントロールは所有者が維持し、いつでも編集、改良、更新が可能です。閲覧専用として共有しても、自分がアクセスできなくなるわけではありません。他の全員が表示できるバージョンが固定されるだけです。

• 柔軟なライフサイクル： ダッシュボードはいつでも「編集可能」に戻すことができます。また、Kibanaの管理者は引き続きすべてのダッシュボードを管理できます（所有者が退職した場合など）。行き止まりになることはありません。

最終決定済みの、業務上極めて重要なダッシュボードを広く共有しても、その一貫性が維持されることが保証されます。これは、Serverlessを含むすべてのElasticのティアとサービスで利用可能です。

役割と可能な操作

クイックリファレンス（役割別）：

• ダッシュボードの所有者：作成者として、完全な編集権限があります。

• Kibana管理者：すべてのダッシュボードを管理できます。

• スペース編集権限を持つユーザー：ダッシュボードの作成と編集が可能ですが、閲覧専用のダッシュボードの編集や削除はできません。

• スペース閲覧権限を持つユーザー：ダッシュボードの表示と一覧表示のみが可能です。

操作

ダッシュボード所有者

Kibana管理者

スペース編集権限を持つユーザー

スペース閲覧権限を持つユーザー

ダッシュボードの一覧表示と表示

✔

✔

✔

✔

新規ダッシュボードの作成

✔

✔

✔

✘

編集可能なダッシュボードの変更/削除

✔

✔

✔

✘

読み込み専用ダッシュボードの変更/削除

✔

✔

✘

✘

読み取り専用にする方法

新しいダッシュボードを保存する際、または後で共有メニューから「閲覧のみ」に設定できます。

新しいダッシュボードを保存する際

• ダッシュボードを作成し、「保存」をクリックします。

• 「新しいダッシュボードとして保存」モーダルで、「権限」を探します。

• 「編集可能」から「閲覧可能」に変更します。

• ［保存］をクリックします。これで完了です。他のユーザーにとっては閲覧専用となります。

既に所有しているダッシュボードの場合

• ダッシュボードを開いてください。

• 「ダッシュボードを共有」メニューを開きます。

• 共有モーダルで、「権限」を見つけて「閲覧可能」に切り替えます。変更はすぐに適用されます。そのスペースの他のユーザーは、編集や削除ができなくなります。

• 共有アクションにマウスを合わせると、特定のダッシュボードが持つ権限の種類を確認できます。

どのダッシュボードがロックされているかを確認する

メインのダッシュボードリストでは、編集または削除できないダッシュボードの選択用チェックボックスは無効化されています。これにより、閲覧専用の項目を簡単に見分けられます。

ダッシュボードでは、編集アクションも無効になっており、ツールチップが表示され、ダッシュボードが閲覧専用に設定されていることが説明されます。

試してみる

読み取り専用ダッシュボードが利用可能になりました。ダッシュボードを作成し、「閲覧可能」に切り替えて共有します。チームは信頼できる唯一の情報源を得ることができ、あなたは安心感を得られます。タイトルに「編集しないでください」という文言を入れる必要はもうありません。

読み取り専用ダッシュボードをどのように活用されているか、ぜひお聞かせください。コミュニティフォーラムでご意見をお聞かせください。

HNSWでは、グラフ内の候補ノードを反復的に拡張し、これまでに発見された最も近い近傍の制限されたセットを維持することで検索が進行します。各拡張にはコスト（ベクトル演算、ディスクへのランダムシークなど）がかかり、そのコストに対する限界効用は検索が進むにつれて減少する傾向があります。

HNSWグラフのトラバーサルを最適化する1つの方法は、新しい真の近傍を見つける周辺尤度が増加しない場合に検索を停止することです。このため、Elasticsearch 9.2では、新しい早期終了メカニズムを導入しました。これは、グラフノードを訪問しても一定回数連続して十分な数の新しい最近傍が提供されない場合に、検索プロセスを停止するものです。

この記事では、HNSWの前述の早期終了メカニズムを改良して、さまざまなデータセットやデータ分布に適したものにする方法について説明します。

HNSWでの早期終了

HNSW では、近接グラフ内の候補ノードを反復的に拡張し、これまでに発見された最も近い近傍の制限されたセットを維持して、グラフ全体を訪問するか、早期終了基準を満たすまで、検索が続行されます。

したがって、早期終了は必ずしも最適化ではなく、検索アルゴリズム自体の一部です。停止を決定する瞬間が、効率性と再現率のバランスを決定します。Elasticsearchでは、HNSWのクエリを早期終了させる方法がすでにいくつか存在します。

• 固定された最大数のノードが訪問されます。

• 一定のタイムアウトに達した場合。

これらのルールは単純かつ予測可能ですが、検索が実際に何をしているかにはほとんど関係がありません。また、これらは主に、クエリがエンドユーザーにとって妥当な時間内に完了することを確認するために使用されます。

前回のブログ投稿ではHNSWにおける冗長性の概念を紹介しました。つまり、HNSWが新しい候補ノードを評価し続けても、さらに最も近い近傍が見つからない場合、冗長な計算が発生します。

忍耐度：努力ではなく進歩を測る

忍耐度という概念は、努力ではなく進歩を中心に早期終了を再構築します。

次のように尋ねる代わりに

「何ステップ進んだ？」

新たに次のように問いかけます。

「希望を失うまでに受け入れられる無駄な計算はどれだけかな？」

HNSW検索では、通常、初期の探索によっ上位k候補セットの最高の改善がもたらされます。HNSWグラフ探索の最初のステップでは、アルゴリズムがクエリベクトルにますます近い近傍を検出し続けるため、近傍のセットは継続的に更新されます。時間が経ち、検索が収束するにつれて、これらの改善はまれになります。忍耐度ベースの終了はこのパターンを監視し、改善が一定期間停止した時点で検索を終了します。

実際には、HNSWグラフを訪問する際、候補ノードをホップしながらキューの飽和比も計算します。これは、最新のグラフノードを訪問中に変更されなかった最も近い近傍の割合（または最後の反復中に導入された新しい近傍の数の逆数）を測定します。このような比率が連続した反復処理で大きくなりすぎると、グラフの訪問を停止します。

概念的には、忍耐度はHNSWの検索を収穫逓減プロセスとして扱います。リターンが平坦になると、グラフの調査を継続してもほとんど利益は得られません。

この枠組みは、終了を恣意的な固定された制限ではなく、観察可能な結果に直接結び付けるため、強力です。

このスマートな早期終了手法を使用する利点は、HNSWグラフ探索では、ほぼ完璧な相対再現率を維持しながら、より少数のグラフノードを訪問する傾向があることです。

これを視覚化するために、FinancialQAとQuoraという2つのデータセットと、JinaV3とE5-smallというモデルで、忍耐度に基づく早期終了（ et=staticとラベル付け）で取得した訪問ノードあたりの再現量を、デフォルトのHNSW動作（ et=noとラベル付け）と比較してプロットすることができます。

静的しきい値とHNSWのダイナミクス

実際には、Elasticsearchでは静的しきい値を使用してこれが実装されます。1つのしきい値は、飽和しきい値、つまり、最適ではないと判断される飽和度の比率を指します。もう1つのしきい値は、最適ではないキュー飽和を維持しながら連続して訪問できるグラフノードの数、つまり忍耐しきい値を指します。

Elasticsearch 9.2でこの早期終了戦略を導入したとき、レイテンシーとメモリ消費の面でメリットを得ながら再現率を可能な限り高められるように、保守的なデフォルトを選択することにしました。このため、KNNクエリでは飽和しきい値を100%に、忍耐しきい値を num_candidates の（有界の）30%に設定しています。

多くのシナリオでは、これらの設定はうまく機能しますが、同じ数の近傍を要求する2つのクエリでは、収束動作が根本的に異なる可能性があります。あるクエリは密集した局所的な近傍に遭遇し、すぐに飽和します。他のクエリは競争力のある候補を見つけるまでに、長くまばらな経路を通過しなければなりません。後者は、効果的に処理するのが最も困難であることが判明しました。

その結果、次のようなことに気付くことがありました。

• 簡単なクエリに対する過度の探索。

• 難しいクエリに対する時期尚早の終了。

したがって、固定されたしきい値は収束に関する全体的な仮定をエンコードしますが、HNSWをさまざまなダイナミクスに適応させることができると考えました。

HNSWの早期終了を適応的に

適応的早期終了は、この問題に異なる角度からアプローチします。事前に定義された停止しきい値を強制する代わりに、アルゴリズムが検索のダイナミクス自体からいつ停止するかを推測します。

したがって、2つの連続した候補間のキュー飽和比を比較する代わりに、即時平滑化発見率 （クエリqの最後の訪問iで導入された新しい隣接ノードの数）と、グラフ訪問中のそのような発見率の移動平均と標準偏差を導入することにしました（ウェルフォードのアルゴリズムを使用）。これらの発見率に関する統計はクエリごとに計算されるため、この情報をもとに各クエリの忍耐度を判断できます。

以前は静的であったしきい値は、発見率の統計に対して適応的になります。飽和しきい値はローリング平均と標準偏差の合計になり、一方で忍耐力は標準偏差に反比例して適応およびスケーリングされます。

早期終了ルールは変わらず、飽和は即時発見率が適応飽和しきい値より低い場合に発生します。適応的忍耐度よりも大きい連続候補訪問回数にわたって飽和が継続する場合、グラフ訪問は停止します。

こうすることで、KNNクエリの num_candidates パラメーターに依存しない動作（早期終了に関係なく、常に設定されるか、デフォルトのままになる場合がある）が得られ、各クエリとベクトル分布に動的に適応しやすくなります。

適応型戦略（ et=adaptiveとラベル付け）を使用したFinancialQAおよびQuoraでの訪問ノードあたりの再現率は、静的戦略（ et=static ）およびデフォルトのHNSW動作（ et=no ）と比較した場合、高くなっています。

適応的早期終了はElasticsearch 9.3ではHNSWの高密度ベクトルフィールドに対してデフォルトでオンになっています（最終的には同じインデックスレベルの設定でオフにすることができます）。

同時実行性の高いワークロード向けにElasticsearchをチューニングする場合の標準的なアプローチは、RAMを最大化してドキュメントのワーキングセットをメモリに保持し、検索レイテンシを低くすることです。結果として、best_compressionは検索ワークロードにはほとんど考慮されません。これは主に、ストレージ効率が優先されるElastic ObservabilityおよびElastic Securityのユースケースでのストレージ節約対策として見なされているためです。

このブログでは、データセットのサイズがOSページキャッシュを大幅に超える場合、best_compressionがI/Oボトルネックを軽減することで検索パフォーマンスとリソース効率を向上させることを示します。

セットアップ

ユースケースは、Elastic CloudのCPUに最適化されたインスタンス上で実行される高同時性検索アプリケーションです。

• データ量：ドキュメント約5億件

• インフラ：6つのElastic Cloud（Elasticsearch Service）インスタンス（各インスタンス：1.76 TBのストレージ | 60 GB RAM | 31.9 vCPU）

• メモリとストレージの比率：総データセットの約5％がRAMに収まる

課題：高いレイテンシ

19:00頃に現在のリクエスト数が急増すると、検索のレイテンシが大幅に悪化することが確認されました。図1と図2に示すように、Elasticsearchインスタンスあたりのトラフィックはピーク時で毎分400リクエスト程度でしたが、平均クエリサービス時間は60ミリ秒以上に低下しました。

初期の接続処理後、CPU使用率は比較的低いままであり、コンピューティングがボトルネックではなかったことを示しています。

クエリボリュームとページフォールトの間の強い相関関係が明らかになりました。リクエストが増加するにつれて、ページフォールトも比例して増加し、ピークは約40万件/分に達しました。これは、アクティブなデータセットがページキャッシュに収まらなかったことを示しています。

同時に、JVMヒープの使用量は正常かつ健全であるように見えました。これにより、ガベージコレクションの問題が排除され、ボトルネックが I/O であることが確認されました。

診断：I/Oバウンド

システムはI/Oバウンド状態でした。Elasticsearchは、メモリからインデックスデータを提供するためにOSページキャッシュに依存します。インデックスがキャッシュに対して大きすぎる場合、クエリによってコストのかかるディスク読み取りがトリガーされます。一般的な解決策は水平方向に拡張すること（ノード/RAMの追加）ですが、まずは既存のリソースの効率改善を最大限に図りたいと考えました。

修正

デフォルトでは、ElasticsearchはインデックスセグメントにLZ4圧縮を使用し、速度とサイズのバランスをとります。best_compression （zstdを使用）に切り替えるとインデックスのサイズが小さくなるという仮説を立てました。フットプリントが小さいほど、ページキャッシュに収まるインデックスの割合が大きくなり、CPUのわずかな増加（解凍用）と引き換えにディスクI/Oが削減されます。

best_compressionを有効にするために、インデックス設定index.codec: best_compressionでデータを再インデックスしました。あるいは、インデックスを閉じ、インデックスコーデックをbest_compressionにリセットしてから、セグメントのマージを実行することで、同じ結果を得ることができます。

結果

結果は、ストレージ効率の向上は、CPU使用率の増加を伴わずに検索パフォーマンスの大幅な向上に直接つながるという私たちの仮説を裏付けました。

best_compressionを適用するとインデックスの大きさは約25％減少しました。反復ログデータで確認された削減よりは少ないものの、この25%の削減により、ページキャッシュ容量が同じだけ実質的に増加しました。

次のロードテスト（17:00から）では、トラフィックはさらに増加し、Elasticsearchノードあたり1分あたり500リクエストでピークに達しました。

負荷が高まったにもかかわらず、CPU使用率は前回の実行時よりも低くなりました。前のテストで使用率が高かったのは、過剰なページフォールト処理とディスクI/O管理のオーバーヘッドが原因である可能性があります。

重要なのは、ページフォールトが大幅に減少したことです。ベースラインテストの30万件超に比較して、より高いスループットでもフォールトは1 分あたり20万件未満に留まりました。

ページフォールトの結果はまだ最適とは言えませんでしたが、クエリサービス時間は約50％削減され、負荷が高まった場合でも30ミリ秒未満に留まりました。

結論：検索にはbest_compressionを

データ量が利用可能な物理メモリを超える検索ユースケースでは、 best_compressionは強力なパフォーマンス調整手段となります。

キャッシュミスに対する従来の解決策はスケールアウトしてRAMを増やすことですが、インデックスのフットプリントを削減することで、ページ キャッシュ内のドキュメント数を最大化するという同じ目標を達成しました。次のステップは、インデックスの並べ替えを探求し、ストレージをさらに最適化し、既存のリソースからさらにパフォーマンスを引き出すことです。

ただし、この 1 つの問題を修正すると、すべてのケースを手動でテストすることができないため、他のクエリが誤って壊れてしまいます。しかし、1つのクエリの変更が他のクエリに波及効果をもたらすかどうかを、開発者やQAチームはどのようにテストできるでしょうか。さらに重要なのは、変更によってクエリが実際に改善されたことをどうやって確認できるかということです。

体系的な評価に向けて

ここで役に立つのが判断リストです。変更を加えるたびに手動の主観的なテストに頼るのではなく、ビジネスケースに関連するクエリの固定セットと、関連する結果を定義できます。

このセットが基準となります。変更を実装するたびに、それを使用して検索が実際に改善されたかどうかを評価します。

このアプローチの価値は、次の点にあります。

• 不確実性の排除：変更が他のクエリに影響を与えるかどうかを心配する必要はなくなり、データが教えてくれます。

• 手動テストの停止：判断セットが記録されると、テストは自動化されます。

• 変更を支援：変更のメリットを裏付ける明確な指標を示すことができます。

判断リストの作成方法

最も簡単な方法の1つは、代表的なクエリを取得して、関連するドキュメントを手動で選択することです。このリストを作成するには2つの方法があります。

• バイナリ判定：クエリに関連付けられた各ドキュメントに関連（通常「1」のスコア）とと非関連（「0」）のシンプルなタグが付けられます。

• 段階的な判断：ここでは、各ドキュメントに異なるレベルのスコアが付けられます。例えば、0から4の尺度を設定します。これはライカート尺度に似ており、0は「全く関連しない」、4は「完全に関連する」を意味し、「関連する」、「やや関連する」などのバリエーションがあります。

検索意図に明確な制限がある場合、つまり「このドキュメントは結果に含まれるべきかどうか」という場合には、バイナリ判断がうまく機能します。

段階的な判断は、グレーゾーンがある場合により役立ちます。一部の結果は他の結果よりも優れているため、「非常に良い」、「良い」、「役に立たない」という結果を取得し、結果の順序とユーザーのフィードバックを評価する指標を使用できます。ただし、段階的な評価尺度には欠点もあります。評価者によってスコアリングレベルの使い方が異なり、判断の一貫性が失われることがある点です。また、評価基準では高得点により重み付けされるため、小さな変更（評価を4ではなく3にするなど）でも、レビュー担当者の意図よりもはるかに大きな変化が評価基準に生じる可能性があります。この主観性が加わることで、段階的な判断はノイズが多くなり、時間の経過とともに管理が難しくなります。

書類を自分で分類する必要がありますか？

必ずしもそうとは限りません。なぜなら、判断リストを作成する方法はいくつかあり、それぞれに利点と欠点があるからです。

• 明示的な判断：ここでは、SMEが各クエリやドキュメントに目を通し、関連性があるかどうか（あるいはどの程度関連性があるか）を手動で判断します。これにより品質と管理は提供されますが、拡張性は低くなります。

• 暗黙的な判断：この方法では、クリック、直帰率、購入などの実際のユーザーの行動に基づいて関連するドキュメントを推測します。このアプローチにより、データを自動的に収集できますが、バイアスがかかる可能性があります。例えば、ユーザーは関連性がなくても上位の結果をクリックする傾向があります。

• AI生成の判断：この最後のオプションでは、モデル（LLMなど）を使用してクエリとドキュメントを自動的に評価します。これは、LLM審査員とも呼ばれます。スケーリングは高速かつ簡単ですが、データの品質は、使用しているモデルの品質と、LLMトレーニングデータがビジネス上の利益とどの程度一致しているかによって異なります。人間の採点者と同様に、LLM審査員も独自のバイアスや不整合を導入する可能性があるため、信頼できる判断の小さなセットに対してその出力を検証することが重要です。LLMモデルは本質的に確率的であるため、 温度 パラメータを0に設定しても同じ結果に対して異なる評価を与えるLLMモデルがよく見られます。

判断セットを作成するための最適な方法を選択するための推奨事項を以下に示します。

• ユーザーのみが適切に判断できる特徴（価格、ブランド、言語、スタイル、製品詳細など）の重要性を決定します。これらが重要な場合は、判断リストの少なくとも一部について明示的な判断が必要です。

• 検索エンジンにすでに十分なトラフィックがある場合は、暗黙的な判断を使用して、クリック、コンバージョン、滞在時間の指標を使用して使用傾向を検出できます。これらの結果は人間が注意深く解釈し、明示的な判断セットと対比させて、バイアスを防御する必要があります（例：ユーザーは、たとえ低いランクの結果がより関連性が高くても、上位にランクされた結果をクリックする傾向があります）。

これに対処するために、位置バイアス除去技術はクリックデータを調整または再重み付けして、実際のユーザーの関心をより適切に反映します。アプローチには以下のようなものがあります。

• 結果のシャッフル：一部のユーザーの検索結果の順序を変更し、位置がクリックにどのように影響するかを推定します。

• クリックモデルにはダイナミックベイジアンネットワーク（DBN）、ユーザーブラウジングモデル（UBM）が含まれます。これらの統計モデルは、スクロール、滞在時間、クリックシーケンス、結果ページへの戻りなどのパターンを使用して、クリックが単なる位置ではなく実際の関心を反映している可能性を推定します。

例：映画評価アプリ

要件

この例を実行するには、稼働しているElasticsearch 8.xクラスター、ローカルまたはElastic Cloud（HostedまたはServerless）、REST APIまたはKibanaへのアクセスが必要です。

ユーザーが映画についての意見をアップロードしたり、見たい映画を検索したりできるアプリを考えてみてください。ユーザー自身がテキストを書くため、タイプミスや表現の多様性がある可能性があります。そのため、検索エンジンがその多様性を解釈し、ユーザーにとって有益な結果を提供できることが不可欠です。

全体的な検索動作に影響を与えずにクエリを反復処理できるようにするために、会社のビジネスチームは、最も頻繁に実行される検索に基づいて、次のバイナリ判定セットを作成しました。

クエリ

DocID

テキスト

ディカプリオの演技

doc1

『レヴェナント：蘇えりし者』でのディカプリオの演技は息を呑むほど素晴らしかった。

ディカプリオの演技

doc2

『インセプション』ではレオナルド・ディカプリオが最も象徴的な役柄の一つを演じています。

ディカプリオの演技

doc3

ブラッド・ピットはこの犯罪スリラーで堅実な演技を見せています。

ディカプリオの演技

doc4

見事な視覚効果を備えたアクション満載の冒険。

泣ける悲しい映画

doc5

何時間も泣いてしまった、愛と喪失の悲痛な物語。

泣ける悲しい映画

doc6

史上最も悲しい映画の1つです。ティッシュが必須。

泣ける悲しい映画

doc7

笑える軽快なコメディ

泣ける悲しい映画

doc8

アクションと興奮に満ちたSF大作。

インデックスの作成：

一括リクエスト：

以下は、このアプリが使用しているElasticsearchクエリです。

判断から指標へ

判断リスト自体は、多くの情報を提供しません。これは、クエリから得られる結果の期待値にすぎません。これらが真価を発揮するのは、検索パフォーマンスを測定するための客観的な指標の計算に使用するときです。

現在、人気の指標のほとんどには以下が含まれます。

• 精度：すべての検索結果の中で本当に関連性の高い結果の割合を測定します。

• リコール：検索エンジンがx件の結果の中で見つけた関連する結果の割合を測定します。

• 割引累積利得（DCG）：最も関連性の高い結果が上位にあるべきであることを考慮して、結果のランキングの品質を測定します。

• 平均逆順位（MRR）：最初の関連結果の位置を測定します。リストの上位にあるほど、スコアも高くなります。

同じ映画評価アプリを例に使い、リコール指標を計算して、クエリに抜け落ちている情報がないかを確認します。

Elasticsearchでは、Ranking Evaluation APIを通じて判断リストを使って指標を計算できます。このAPIは、判断リスト、クエリ、および評価する指標をインプットとして受け取り、クエリ結果と判断リストを比較した値を返します。

次の2つのクエリの判断リストを実行してみましょう。

_rank_evalには 2 つのリクエストを使用します。1つはディカプリオクエリ用、もう1つは悲しい映画用です。各リクエストには、クエリと判断リスト（評価）が含まれています。評価に含まれていない文書は判断対象外とみなされるため、すべての文書に等級を付ける必要はありません。計算を行うために、リコールは評価において関連性があると見なされるドキュメントである「関連セット」のみを考慮します。

この場合、ディカプリオのクエリのリコールは1ですが、悲しい映画のリコールは0です。つまり、最初のクエリでは関連する結果をすべて取得できましたが、2 番目のクエリでは何も取得できませんでした。したがって、平均リコールは0.5です。

クエリ内の単語の100%がドキュメント内で見つかることを要求することで、おそらく関連する結果が除外されるため、minimum_should_matchパラメータを厳しすぎるのかもしれません。minimum_should_matchパラメーターを削除して、クエリで1つの単語しか見つかっていない文書が関連性があると見なされるようにしましょう。

ご覧のように、2つのクエリのうちの1つでminimum_should_matchパラメーターを削除すると、両方のクエリの平均リコール率は1になります。

要約すると、minimum_should_match: 100%句を削除すると、両方のクエリで完璧なリコールが得られます。

これで完了でしょうか？

安心するのはまだ早いです。

リコールを改善することで、より幅広い結果を得る道が開かれます。ただし、それぞれの調整にはトレードオフが伴います。だからこそ、完全なテストケースを定義し、異なる指標を使って変更を評価することが重要です。

判断リストと指標を使用すると、変更をバックアップするデータが得られるため、変更を行うときに盲目的に変更を行うことがなくなります。検証は手動で繰り返し行う必要がなくなり、変更を1つのユースケースだけでなく複数のユースケースでテストできるようになります。さらに、A/Bテストでは、どの構成がユーザーやビジネスケースに最適かをライブでテストできるため、技術的な指標と実際の指標から完全に把握できます。

判断リストの使用に関する最終的な推奨事項

判断リストを扱うことは、単に測定することだけでなく、自信を持って反復作業を行うためのフレームワークを作ることでもあります。これを実現するには、次の推奨事項に従ってください。

1. 規模にこだわらずとにかく始める。それぞれ50個の判断リストを持つ10,000個のクエリを用意する必要はありません。ビジネスケースの最も重要な5〜10個のクエリを特定し、結果の冒頭にどの文書が表示されたいかを定義するだけで十分です。これですでに基礎が整いました。通常は、上位クエリと結果なしのクエリから始めるのが望ましいです。また、精度のような設定が簡単な指標でテストを開始し、複雑さを上げていくこともできます。

2. ユーザーとともに検証する。本番環境でのA/Bテストで数値を補完します。こうすることで、指標で良さそうに見える変更が実際に効果を生んでいるかどうかを知ることができます。

3. リストをアクティブに保つ。ビジネスケースは進化し、重要な問い合わせも進化していきます。新たなニーズを反映するために、定期的に判断を更新してください。

4. フローの一部に組み込む。判断リストを開発パイプラインに統合しましょう。各構成の変更、同義語、またはテキスト分析が基本リストに対して自動的に検証されることを確認します。

5. 技術的な知識と戦略を結び付ける。精度やリコールなどの技術的な指標の測定にとどまらず、評価結果をビジネスの成果に役立てましょう。

再帰チャンキングとは何ですか?

再帰チャンク化では、指定されたセクション分離パターンのリストを反復処理して、必要な最大チャンク サイズを満たすまで、ドキュメントを段階的に小さなセグメントに分割します。

再帰チャンクを構成するにはどうすればよいですか?

以下は、再帰チャンク化に対してユーザーが指定できる構成可能な値です。

• (必須) max_chunk_size : チャンク内の最大単語数。

• 次のいずれか:

  • separators: ドキュメントをチャンクに分割するために使用される正規表現文字列パターンのリスト。

  • separator_group: 特定の種類のドキュメントに使用するために Elastic によって定義された区切り文字のデフォルト リストにマップされる文字列。現在、 markdownとplaintextが利用可能です。

再帰チャンキングはどのように機能しますか?

入力ドキュメント、 max_chunk_size (単語単位で測定)、および区切り文字列のリストが与えられた場合の再帰チャンク化のプロセスは次のとおりです。

1. 入力ドキュメントがすでに最大チャンク サイズ内である場合は、入力全体にわたる単一のチャンクを返します。

2. 区切り文字の出現に基づいてテキストを潜在的なチャンクに分割します。潜在的なチャンクごとに:

   1. 潜在的なチャンクが最大チャンク サイズ内である場合は、ユーザーに返すチャンクのリストに追加します。

   2. それ以外の場合は、潜在的なチャンクのテキストのみを使用して、リスト内の次のセパレーターを使用して分割し、手順 2 から繰り返します。試す区切り文字がもう残っていない場合は、文ベースのチャンクに戻ります。

再帰チャンクの設定例

チャンク サイズとは別に、再帰チャンク化の主な構成は、ドキュメントを分割するために使用するセパレーターを選択することです。どこから始めればよいかわからない場合は、Elasticsearch では一般的なユースケースに使用できるデフォルトのセパレーター グループがいくつか用意されています。

セパレーターグループの活用

セパレーター グループを利用するには、チャンク設定を構成するときに使用するグループの名前を指定するだけです。例えば：

これにより、区切りリスト["(?<!\\n)\\n\\n(?!\\n)", "(?<!\\n)\\n(?!\\n)")]を利用する再帰的なチャンク化戦略が提供されます。これは、2 つの改行文字とそれに続く 1 つの改行文字で分割する、一般的なプレーン テキスト アプリケーションに適しています。

セパレーターリストを利用するセパレーターグループmarkdownも提供しています。

この区切りリストは、6 つの見出しレベルとセクション区切り文字のそれぞれに分割する一般的なマークダウンの使用例に適しています。

リソース (推論エンドポイント/セマンティック テキスト フィールド) を作成すると、その時点のセパレーター グループに対応するセパレーターのリストが構成に保存されます。セパレーター グループが後日更新されても、既に作成されたリソースの動作は変更されません。

カスタム区切りリストの利用

定義済みの区切り文字グループのいずれかが使用ケースに適していない場合は、ニーズに合った区切り文字のカスタム リストを定義できます。区切りリスト内に正規表現を指定できることに注意してください。以下は、カスタムセパレーターを使用して構成されたチャンク設定の例です。

上記のチャンク化戦略では、 2 つの改行文字、続いて 1 つの改行文字、最後に文字列“<my-custom-separator>”で分割されます。

再帰チャンキングの実際の例

再帰チャンキングの実際の例を見てみましょう。この例では、上位 2 つのヘッダー レベルを使用してマークダウン ドキュメントを分割するセパレーターのカスタム リストとともに、次のチャンク設定を使用します。

単純なチャンクなしの Markdown ドキュメントを見てみましょう。

ここで、上で定義したチャンク設定を使用してドキュメントをチャンク化してみましょう。

注: 各チャンク (チャンク 3 を除く) の末尾の改行は強調表示されませんが、実際のチャンク境界内に含まれます。

今すぐ再帰チャンキングを始めましょう!

この機能の利用方法の詳細については、チャンク設定の構成に関するドキュメントを参照してください。

この取り組みの「全体像」について詳しくは、ブログ「Elasticsearch を使用した AI エージェントワークフローの構築」をお読みください。より実践的な入門書として、「初めての Elastic エージェント: 単一のクエリから AI を活用したチャットまで」もご覧ください。

ただし、このブログでは、チャットを開始したときに最初に起こることの 1 つに焦点を絞り、最近行った改善点のいくつかについて説明します。

ここで何が起こっているのですか?

Elasticsearch データとチャットする場合、デフォルトの AI エージェントが次の標準フローを実行します。

1. プロンプトを検査します。

2. どのインデックスにそのプロンプトの回答が含まれている可能性があるかを特定します。

3. プロンプトに基づいて、そのインデックスのクエリを生成します。

4. そのクエリでそのインデックスを検索します。

5. 結果を統合します。

6. 結果はプロンプトに対応できますか?はいの場合は応答してください。そうでない場合は、別の方法を試しながら繰り返します。

これはあまり目新しいものではないはずです。これは単に Retrieval Augmented Generation (RAG) です。そして当然のことですが、応答の質は最初の検索結果の関連性に大きく左右されます。そのため、応答品質の向上に取り組む中で、ステップ 3 で生成してステップ 4 で実行するクエリに細心の注意を払ってきました。そして、私たちは興味深いパターンに気づきました。

多くの場合、最初の応答が「悪い」場合、それは実行したクエリが悪かったからではありません。クエリを実行するために間違ったインデックスを選択したためです。通常、ステップ 3 と 4 は問題ではありません。問題はステップ 2 です。

私たちは何をしていたのでしょうか?

当初の実装はシンプルでした。私たちは、 _cat/indicesを効果的に実行して利用可能なすべてのインデックスをリストし、これらのインデックスのうちどれがユーザーのメッセージ/質問/プロンプトに最も一致するかを LLM に識別させるツール (index_explorer と呼ばれる) を構築しました。このオリジナルの実装はここで見ることができます。

これはどれくらいうまく機能しましたか?よく分かりませんでした！うまく機能していない明確な例はありましたが、私たちにとっての本当の最初の課題は、現状を定量化することでした。

ベースラインの確立

それはデータから始まる

私たちが必要としていたのは、ユーザーのプロンプトと既存のインデックス セットに基づいて適切なインデックスを選択するツールの有効性を測定するためのゴールデン データ セットでした。そして、手元にそのようなデータセットがなかったので、それを生成しました。

謝辞: これは「ベスト プラクティス」ではないことは承知しています。しかし、時には、自転車を捨てるよりも前進する方が良いこともあります。進歩、シンプルな完璧さ。

このプロンプトを使用して、いくつかの異なるドメインのシードのインデックスを生成しました。次に、生成されたドメインごとに、このプロンプトを使用してさらにいくつかのインデックスを生成しました (ここでの目標は、ハードネガティブと分類が難しい例を使用して LLM に混乱を引き起こすことです)。次に、生成された各インデックスとその説明を手動で編集しました。最後に、このプロンプトを使用してテストクエリを生成しました。次のようなサンプルデータが得られました。

そして次のようなテストケース:

テストハーネスの作成

ここからのプロセスは非常に簡単でした。次の機能を備えたツールをスクリプト化します。

1. ターゲット Elasticsearch クラスターを使用してクリーンな状態を確立します。

2. ターゲット データセットで定義されているすべてのインデックスを作成します。

3. 各テスト シナリオに対して、 i ndex_explorerツールを実行します (便利なことに、実行ツール API があります)。

4. 結果のインデックスを予想インデックスと比較し、結果を取得します。

5. すべてのテストシナリオを終了したら、結果を表にまとめます。

調査によると…

当初の結果は予想通り平凡なものでした。

全体として、正しいインデックスを識別する精度は 77.14% です。これは、すべてのインデックスに意味的に意味のある適切な名前が付けられている「最良のケース」のシナリオでした。`PUT test2/_doc/foo {...} ` を実行したことがある人なら、インデックスの名前が必ずしも意味のあるものではないことはご存じでしょう。

つまり、ベースラインがあり、改善の余地が十分にあることがわかります。さあ、科学の時間です！🧪

実験

仮説1: マッピングは役立つ

ここでの目標は、元のプロンプトに関連するデータが含まれるインデックスを識別することです。インデックスに含まれるデータを最もよく表す部分は、インデックスのマッピングです。インデックスの内容のサンプルを取得しなくても、インデックスに double 型の価格フィールドがあることがわかれば、そのデータは販売されるものを表していることがわかります。テキストタイプの著者フィールドは、何らかの非構造化言語データを意味します。これら 2 つを組み合わせると、データが書籍、物語、詩であることを意味する可能性があります。インデックスのプロパティを知るだけで、意味上の手がかりを数多く得ることができます。そこでローカルブランチで`.index_explorer`を調整しましたインデックスの完全なマッピング (およびその名前) を LLM に送信して決定を下すツール。

結果（Kibana ログより）:

ツールの最初の作成者はこれを予期していました。インデックスのマッピングは情報の宝庫ですが、非常に冗長な JSON ブロックでもあります。そして、多数のインデックス (評価データセットでは 20 個が定義されています) を比較する現実的なシナリオでは、これらの JSON BLOB が加算されます。したがって、LLM に、すべてのオプションのインデックス名だけでなく、それぞれの完全なマッピングほどではなく、決定のためのより多くのコンテキストを提供したいと考えています。

仮説2: 妥協案としての「フラット化された」マッピング（フィールドリスト）

私たちは、インデックス作成者が意味的に意味のあるインデックス名を使用するという前提から始めました。その仮定をフィールド名にも拡張するとどうなるでしょうか?前回の実験は、JSON のマッピングに大量の煩わしいメタデータと定型句が含まれているため失敗しました。

たとえば、上記のブロックは 236 文字で、Elasticsearch マッピング内の 1 つのフィールドのみを定義します。一方、文字列「description_text」は 16 文字だけです。これは文字数が約 15 倍に増加していることを意味しますが、そのフィールドが利用可能なデータについて何を意味するかを説明する意味的な改善は見られません。すべてのインデックスのマッピングをフェッチしたが、それを LLM に送信する前に、フィールド名のリストだけに「フラット化」するとどうなるでしょうか?

試してみました。

これは素晴らしいですね！全面的に改善されました。しかし、もっと良い方法はないでしょうか?

仮説3: マッピング_meta内の説明

追加のコンテキストのないフィールド名だけでこれほど大きな変化が生じたのであれば、実質的なコンテキストを追加すればさらに良くなると思われます。すべてのインデックスに説明を添付することが必ずしも慣例ではありませんが、マッピングの _meta オブジェクトにあらゆる種類のインデックス レベルのメタデータを追加することは可能です。生成されたインデックスに戻り、データセット内のすべてのインデックスに説明を追加しました。説明が極端に長くない限り、完全なマッピングよりも少ないトークンが使用され、インデックスに含まれるデータに関するはるかに優れた洞察が提供されるはずです。私たちの実験はこの仮説を検証しました。

若干の改善があり、現在では全体的に 90% を超える精度を実現しています。

仮説4：全体は部分の合計よりも大きい

フィールド名により結果が向上しました。説明により結果が向上しました。したがって、説明とフィールド名の両方を利用すると、さらに良い結果が得られるはずです。

データは「いいえ」（前回の実験から変化なし）を示しました。ここでの主な理論は、説明はそもそもインデックス フィールド/マッピングから生成されたため、これら 2 つのコンテキストの間には、組み合わせたときに何か「新しい」ものを追加するのに十分な情報がないというものでした。さらに、20 個のテスト インデックスに送信するペイロードもかなり大きくなっています。これまで私たちが辿ってきた考え方はスケーラブルではありません。実際、これまでの私たちの実験は、数百または数千のインデックスから選択できる Elasticsearch クラスターでは機能しないと考えられる十分な理由があります。インデックスの合計数が増加するにつれて、LLM に送信されるメッセージ サイズが直線的に増加するアプローチは、おそらく一般化可能な戦略にはなりません。

私たちに本当に必要なのは、多数の候補から最も関連性の高い選択肢だけを絞り込むのに役立つアプローチです...

ここで問題となるのは検索の問題です。

仮説5：意味検索による選択

インデックスの名前に意味がある場合は、ベクトルとして保存し、意味的に検索することができます。

インデックスのフィールド名に意味がある場合は、それらをベクトルとして保存し、意味的に検索することができます。

インデックスに意味を持つ記述がある場合は、それもベクトルとして保存し、意味的に検索することができます。

現在、Elasticsearch インデックスではこの情報を検索可能にしていません (検索可能にすべきかもしれませんが) が、そのギャップを回避できるものをハックするのは非常に簡単でした。Elastic のコネクタ フレームワークを使用して、クラスター内のすべてのインデックスのドキュメントを出力するコネクタを構築しました。出力ドキュメントは次のようになります。

これらのドキュメントを、次のように手動でマッピングを定義した新しいインデックスに送信しました。

これにより、単一の semantic_content フィールドが作成され、セマンティックな意味を持つ他のすべてのフィールドがチャンク化され、インデックスが作成されます。このインデックスの検索は、次のようにするだけで簡単になります。

修正されたindex_explorerツールは、LLM へのリクエストを行う必要がなくなり、代わりに指定されたクエリに対して単一の埋め込みをリクエストして効率的なベクトル検索操作を実行できるため、大幅に高速化されました。トップヒットを選択したインデックスとして取得すると、次の結果が得られました。

このアプローチはスケーラブルです。このアプローチは効率的です。しかし、このアプローチはベースラインよりわずかに優れているだけです。しかし、これは驚くことではありません。ここでの検索アプローチは信じられないほど単純です。ニュアンスがない。インデックスの名前と説明は、インデックスに含まれる任意のフィールド名よりも重視されるべきであるという認識がありません。正確な語彙の一致を同義語の一致よりも重視するアフォーダンスはありません。ただし、非常に微妙なニュアンスのあるクエリを構築するには、手元のデータについて多くのことを想定する必要があります。これまで、インデックス名とフィールド名には意味があるという大きな仮定をすでに立ててきましたが、さらに一歩進んで、インデックス名とフィールド名がどの程度の意味を持ち、互いにどのように関連しているかを仮定する必要があります。そうしないと、最上位の結果として最適な一致を確実に特定することはできないかもしれませんが、最上位 N 個の結果のどこかに最上位の一致があると言える可能性が高くなります。意味情報をそれが存在するコンテキスト内で消費し、意味的に異なる方法で自身を表現する別のエンティティと比較し、それらを判断できるものが必要です。LLM のようなものです。

仮説6: 候補セットの削減

他にも簡単に触れる実験はいくつかありましたが、重要な突破口となったのは、純粋にセマンティック検索から最適な一致を選択したいという欲求を捨て、代わりにセマンティック検索をフィルターとして活用して、LLM の検討対象から無関係なインデックスを除外したことです。検索では、リニア リトリーバー、RRF を使用したハイブリッド検索、 semantic_textを組み合わせて、一致する上位 5 つのインデックスに結果を制限しました。

次に、一致ごとに、インデックスの名前、説明、フィールド名を LLM のメッセージに追加しました。結果は素晴らしかったです。

これまでのどの実験よりも最高の精度です!また、このアプローチではインデックスの合計数に比例してメッセージ サイズが増加しないため、このアプローチははるかにスケーラブルです。

成果

最初の明らかな結果は、ベースラインを改善できるということでした。振り返ってみるとこれは明らかなようですが、実験が始まる前に、 index_explorerツールを完全に放棄して、ユーザーからの明示的な構成に依存して検索空間を制限すべきかどうかについて真剣な議論がありました。これはまだ実行可能かつ有効なオプションですが、この調査では、そのようなユーザー入力が利用できない場合にインデックス選択を自動化するための有望な道筋があることが示されています。

次の明らかな結果は、問題に対して説明文字をさらに追加するだけでは、効果は減少するということです。この調査を行う前、Elasticsearch のフィールドレベルのメタデータ保存機能を拡張することに投資すべきかどうかについて議論していました。現在、これらのmeta値は 50 文字に制限されており、フィールドの意味を理解できるようにするにはこの値を増やす必要があると想定されていました。これは明らかに事実ではなく、LLM はフィールド名だけでかなりうまく機能しているようです。これについては後でさらに調査するかもしれませんが、もはや緊急の問題ではないように思われます。

逆に言えば、これは「検索可能な」インデックス メタデータを持つことの重要性を明確に示しています。これらの実験のために、インデックスのインデックスをハッキングしました。しかし、これを Elasticsearch に直接組み込むか、管理するための API を構築するか、少なくとも規則を確立することを調査することはできます。私たちは選択肢を検討し、社内で議論する予定ですので、お楽しみに。

最後に、この取り組みにより、時間をかけて実験し、データに基づいた意思決定を行うことの価値が確認されました。実際、これにより、Agent Builder 製品には強力な製品内評価機能が必要になることが再確認されました。インデックスを選択するツール専用のテスト ハーネス全体を構築する必要がある場合、お客様は反復的な調整を行う際にカスタム ツールを定性的に評価する方法が絶対に必要になります。

私たちが何を構築するのか楽しみにしています。皆さんも楽しみにしていただければ幸いです。

顧客との会議の前に、状況を把握しておく必要がある財務マネージャーを想像してください。ニュース フィードを手動で調べたり、ポートフォリオ ダッシュボードを相互参照したりする代わりに、カスタム構築されたエージェントに直接質問するだけで済みます。これは「チャットファースト」アプローチの利点です。マネージャーはデータに直接、会話形式でアクセスし、「ACME Corp の最新ニュースは何ですか。また、それがクライアントの保有株にどのような影響を与えますか」などと質問します。数秒以内に専門家による総合的な回答が得られます。

私たちは現在、金融の専門家を構築していますが、そのアプリケーションはデータと同じくらい多様です。同じ力で、脅威を探すサイバーセキュリティアナリスト、機能停止を診断するサイト信頼性エンジニア、キャンペーンを最適化するマーケティングマネージャーを生み出すこともできます。分野に関係なく、中核となる使命は同じです。データを、チャットできる専門家に変換することです。

ステップ0: データセット

本日のデータセットは、金融口座、資産状況、ニュース、財務レポートで構成される合成的な金融ベースのデータセットです。これは合成ではありますが、実際の金融データセットの簡略化されたバージョンを複製したものです。

financial_accounts: リスクプロファイル付き顧客ポートフォリオ

financial_holdings: 購入履歴のある株式/ETF/債券のポジション

financial_asset_details: 株式/ETF/債券の詳細

financial_news: 感情分析によるAI生成の市場記事

financial_reports: 企業収益とアナリストのコメント

ここにある付属のノートブックに従って、このデータセットを自分でロードできます。

ステップ1: 基盤 - ES|QLとしてのビジネスロジック

すべての AI スキルは、確かなロジックから始まります。Financial Manager エージェントには、「市場のセンチメントが心配です。」というよくある質問に回答する方法を教える必要があります。悪いニュースによって最もリスクにさらされている顧客は誰なのか教えていただけますか？」この質問は単純な検索の範囲を超えています。市場の感情と顧客のポートフォリオを相関させる必要があります。

否定的な記事で言及されている資産を見つけ、それらの資産を保有しているすべての顧客を特定し、そのエクスポージャーの現在の市場価値を計算し、結果をランク付けして最も高いリスクを優先する必要があります。この複雑な複数結合の分析は、当社の高度な ES|QL ツールに最適です。

使用する完全なクエリは次のとおりです。見た目は印象的ですが、コンセプトは単純です。

分解：接合部とガードレール

このクエリでは、エージェント ビルダーを構成する 2 つの重要な概念が関係しています。

1.ルックアップ結合

長年にわたり、Elasticsearch で最も要望が多かった機能の 1 つは、共通キーに基づいて異なるインデックスのデータを結合する機能でした。ES|QL では、 LOOKUP JOINでそれが可能になりました。

新しいクエリでは、3 つのLOOKUP JOINのチェーンを実行します。最初に否定的なニュースを資産の詳細に関連付け、次にそれらの資産をクライアントの保有資産にリンクし、最後にクライアントのアカウント情報に結合します。これにより、単一の効率的なクエリで 4 つの異なるインデックスから非常に豊富な結果が作成されます。つまり、すべてのデータを事前に 1 つの巨大なインデックスに非正規化する必要がなく、異なるデータセットを組み合わせて単一の洞察に満ちた回答を作成できるということです。

2. LLMガードレールとしてのパラメータ

クエリでは?time_durationが使用されていることがわかります。これは単なる変数ではなく、AI のガードレールです。大規模言語モデル (LLM) はクエリの生成に優れていますが、データに対して LLM を自由に制御させると、非効率的なクエリや間違ったクエリが発生する可能性があります。

パラメータ化されたクエリを作成することで、LLM は、人間の専門家がすでに定義したテスト済みの効率的で正しいビジネス ロジック内で動作するように強制されます。これは、開発者が長年にわたり検索テンプレートを使用して、クエリ機能をアプリケーションに安全に公開してきた方法に似ています。エージェントは「今週」のようなユーザーのリクエストを解釈してtime_durationパラメータを埋めることができますが、回答を取得するにはクエリ構造を使用する必要があります。これにより、柔軟性と制御の完璧なバランスが実現します。

最終的に、このクエリにより、データを理解している専門家は自分の知識をツールにカプセル化できるようになります。他の人や AI エージェントは、そのツールを使用して、基礎となる複雑さについて何も知らなくても、単一のパラメータを提供するだけで相関結果を得ることができます。

ステップ2：スキル - クエリを再利用可能なツールに変える

ES|QL クエリは、ツールとして登録されるまでは単なるテキストです。エージェント ビルダーでは、ツールは単なる保存されたクエリではなく、AI エージェントが理解して使用することを選択できる「スキル」です。その魔法は、私たちが提供する自然言語による説明にあります。この説明は、ユーザーの質問と基礎となるクエリ ロジックを結び付ける橋渡しとなります。作成したクエリを登録しましょう。

UIパス

Kibana でツールを作成するのは簡単なプロセスです。

1.エージェントへ移動

• [ツール]または[ツールの管理]をクリックし、 [新しいツール]ボタンをクリックします。

2. フォームに以下の詳細を入力します。

• ツールID: find_client_exposure_to_negative_news

私。これはツールの一意のIDです

• 説明: 「クライアントのポートフォリオがネガティブなニュースにさらされているかどうかを調べます。」このツールは、最近のニュースやレポートをスキャンして否定的な感情を検出し、関連する資産を識別して、その資産を保有しているすべてのクライアントを見つけます。最も高い潜在的リスクを強調するために、ポジションの現在の市場価値でソートされたリストを返します。

私。これは、LLM が読んで、このツールが仕事に適しているかどうかを判断します。

• ラベル: retrievalおよび risk-analysis

ラベルは複数のツールをグループ化するのに役立ちます

• 設定:ステップ1の完全なES|QLクエリを貼り付けます

私。これはエージェントが使用する検索です

3.クエリからパラメータを推測するをクリックします。UI は自動的に?time_duration見つけて以下にリストします。エージェント (および他のユーザー) が目的を理解できるように、それぞれに簡単な説明を追加します。

• time_duration: ネガティブなニュースを遡って検索する期間。フォーマットは「X時間」です。デフォルトは8760時間です。

4. 試してみましょう!

• [保存してテスト]をクリックします。

• クエリが期待どおりに動作していることを確認できる新しいフライアウトが表示されます。

私。time_durationに希望の範囲を入力します。ここでは「8760時間」を使用します。

• 「送信」をクリックすると、すべてがうまくいけば JSON レスポンスが表示されます。期待どおりに動作することを確認するには、下にスクロールしてvaluesオブジェクトを確認します。ここで、実際に一致するドキュメントが返されます。

5. 右上の「X」をクリックして、テストのフライアウトを閉じます。新しいツールがリストに表示され、エージェントに割り当てる準備が整います。

APIパス

自動化を好む開発者やツールをプログラムで管理する必要がある開発者は、1 回の API 呼び出しで同じ結果を得ることができます。ツールの定義を含むPOSTリクエストを/api/agent_builder/toolsエンドポイントに送信するだけです。

ステップ3：頭脳 - カスタムエージェントの作成

再利用可能なスキル (ツール) を構築しました。ここで、実際に使用するペルソナであるAgentを作成する必要があります。エージェントは、LLM、アクセスを許可する特定のツール セット、そして最も重要な、エージェントの構成として機能し、エージェントの性格、ルール、目的を定義するカスタム インストラクションセットの組み合わせです。

プロンプトの芸術

信頼できる専門エージェントを作成する上で最も重要なのはプロンプトです。よく練られた一連の指示こそが、一般的なチャットボットと、集中力のあるプロのアシスタントとの違いです。ここで、ガードレールを設定し、出力を定義し、エージェントにミッションを与えます。

Financial Managerエージェントでは、次のプロンプトを使用します。

このプロンプトがなぜ効果的なのかを分析してみましょう。

• 洗練されたペルソナを定義します。最初の行で、エージェントが「専門的なデータ インテリジェンス アシスタント」であることを即座に示し、プロフェッショナルで有能な雰囲気を醸し出します。

• これは推論フレームワークを提供します。エージェントに「理解、計画、実行、統合」を指示することで、標準的な操作手順を提供します。これにより、複雑で複数のステップから成る質問を処理する能力が向上します。

• インタラクティブな対話を促進します。 「明確な質問をする」という指示により、エージェントはより堅牢になります。曖昧なリクエストに対する誤った想定を最小限に抑え、より正確な回答が得られます。

UIパス

1.エージェントに移動します。

• [ツール]または[ツールの管理]をクリックし、 [新しいツール]ボタンをクリックします。

2. 基本的な詳細を入力します。

• エージェント ID: financial_assistant 。

• 手順:上記のプロンプトをコピーします。

• ラベル: Finance 。

• 表示名: Financial Assistant 。

• 表示の説明: An assistant for analyzing and understanding your financial data 。

3. 上部に戻り、 「ツール」をクリックします。

• find_client_exposure_to_negative_newsツールの横にあるボックスにチェックを入れてください。

4. 「保存」をクリックします。

APIパス

/api/agent_builder/agentsエンドポイントへのPOSTリクエストを使用して、まったく同じエージェントを作成できます。リクエスト本体には、ID、名前、説明、完全な指示セット、エージェントが使用を許可されているツールのリストなど、すべて同じ情報が含まれています。

ステップ4：成果 — 会話をする

ビジネス ロジックがツールにカプセル化され、エージェントでそれを使用できる「頭脳」が準備されました。すべてが一つにまとまるのを見る時が来ました。専用のエージェントを使用して、データとのチャットを開始できるようになりました。

UIパス

1. Kibana のエージェントに移動します。

2. チャット ウィンドウの右下にあるドロップダウンを使用して、デフォルトのElastic AI エージェントから新しく作成したFinancial Assistantエージェントに切り替えます。

3. エージェントが当社の専用ツールを使用できるように、次の質問をしてください。

   1. 市場のセンチメントが心配です。悪いニュースによって最もリスクにさらされている顧客は誰なのか教えていただけますか?

しばらくすると、エージェントは完全にフォーマットされた完全な回答を返します。LLM の性質上、回答の形式が若干異なる場合がありますが、この実行ではエージェントは次のように返しました。

何が起こったのですか?エージェントの推論

エージェントは単に答えを「知っていた」だけではありません。仕事に最適なツールを選択することを中心とした多段階の計画を実行しました。その思考プロセスは次のようになります。

• 識別された意図: 「リスク」や「ネガティブなニュース」など、質問のキーワードがfind_client_exposure_to_negative_newsツールの説明と一致しました。

• 計画を実行しました:リクエストから時間枠を抽出し、その専用ツールを1 回呼び出しました。

• 作業を委任:ツールは連鎖結合、値の計算、並べ替えなど、面倒な作業をすべて実行しました。

• 結果の統合:最後に、エージェントはプロンプトのルールに従って、ツールからの生データを明確で人間が読める要約にフォーマットしました。

思考を広げて詳細を見れば、推測するだけでは足りません。

APIパス

同じ会話をプログラムで開始することもできます。入力した質問をconverse API エンドポイントに送信し、 financial_managerのagent_idを必ず指定してください。

開発者向け: APIとの統合

Kibana UI はエージェントの構築と管理に素晴らしく直感的なエクスペリエンスを提供しますが、今日見てきたことはすべてプログラムで実現することもできます。Agent Builder は一連の API に基づいて構築されており、この機能を独自のアプリケーション、CI/CD パイプライン、または自動化スクリプトに直接統合できます。

使用する 3 つのコア エンドポイントは次のとおりです。

• /api/agent_builder/tools: エージェントが使用できる再利用可能なスキルを作成、一覧表示、管理するためのエンドポイント。

• /api/agent_builder/agents: エージェントのペルソナ（重要な指示やツールの割り当てなど）を定義するためのエンドポイント。

• /api/agent_builder/converse: エージェントと対話し、会話を開始し、回答を得るためのエンドポイント。

これらの API を使用してこのチュートリアルのすべてのステップを実行するための完全な実践的なチュートリアルについては、 こちらの GitHub リポジトリで入手できる付属の Jupyter Notebook を ご覧ください。

結論: 構築する番です

まず、ES|QL クエリを取得して、それを再利用可能なスキルに変換することから始めました。次に、明確なミッションとルールを与えて、そのスキルを付与した専用の AI エージェントを構築しました。その結果、複雑な質問を理解し、複数段階の分析を実行して、正確でデータに基づいた回答を提供できる洗練されたアシスタントが誕生しました。

このワークフローは、Elastic の新しいAgent Builderの中心です。これは、技術に詳しくないユーザーが UI を通じてエージェントを作成できるほどシンプルでありながら、開発者が API 上にカスタム AI 搭載アプリケーションを構築できるほど微妙なニュアンスも備えた設計になっています。最も重要なのは、定義したエキスパート ロジックに従って、LLM を独自のデータに安全かつ確実に接続し、データとチャットできることです。

エージェントを使用してデータとチャットする準備はできていますか?

学んだことを定着させる最良の方法は、実際に手を動かしてみることです。今日お話しした内容をすべて、無料のインタラクティブな実践ワークショップで試してみてください。専用のサンドボックス環境で、このフロー全体とその他の内容を実行します。

今後のブログでは、 Financial Assistantエージェントと対話するスタンドアロン アプリケーションの使用方法と、それを可能にするモデル コンテキスト プロトコル (MCP)について詳しく説明します。また、別のブログでは、開発中の Agent2Agent (A2A) プロトコルに対する Agent Builder のサポートについて説明します。

引き続きご注目ください、そして楽しい建築を！

エージェントビルダー: データ駆動型 AI エージェント構築の基盤

AI エージェントの約束はシンプルです。目標を与えれば、仕事が完了します。しかし、開発者にとって、現実は一連の複雑な課題です。まず、エージェントの優秀さは、環境の認識と、ユーザーの目的を達成するために与えられたツールによって決まります。そして、多様な企業データから適切なコンテキストを提供することは大きな課題です。最後に、これらすべては、計画、実行、学習できる信頼性の高い推論ループによって調整される必要があります。

これを解決するには、開発者は複雑で脆弱なスタックをゼロから構築する必要があります。今日のエージェント アーキテクチャでは、LLM、ベクター データベース、メタデータ ストア、ログ記録とトレースの個別のシステム、そしてすべてが機能しているかどうかを評価する方法など、複数の異なる部分をつなぎ合わせる必要があります。これは単に複雑なだけでなく、コストがかかり、エラーが発生しやすく、ユーザーが求める高品質で信頼性の高い AI システムの構築が困難になります。

だから、もっとシンプルにしたいんです。これを実現するための私たちのアプローチは、効果的なコンテキスト駆動型エージェントの重要な要素を取り上げ、 Elastic AI Agent Builderと呼ばれる新しい機能セットを使用して Elasticsearch の中核に直接統合することです。この新しいレイヤーは、Elasticsearch を活用した AI エージェントを作成するためのすべての重要な構成要素（オープンなプリミティブ セット、標準ベースのプロトコル、データへの安全なアクセス）を備えたフレームワークを提供します。これにより、現実世界のデータと要件に合わせてカスタマイズされたエージェント システムを構築できます。

AI エクスペリエンスの提供: これが究極の目標です。当社の Search AI プラットフォームとお客様のデータを基盤として、カスタム チャット インターフェースから、LangChain などのエージェント フレームワークや Salesforce などのビジネス アプリケーションとの統合まで、あらゆるタイプの生成 AI アプリケーションを構築できます。

エージェントとツールを搭載: プラットフォームの上に、クリーンでシンプルな抽象化レイヤーを公開します。エージェントやツールと直接対話し、特定のニーズに合わせてカスタマイズできます。強力な API や MCP、A2A などのオープン スタンダードを通じてプラットフォームの機能にアクセスすることもできます。

Search AI Platform によって有効化: これは、コンポーネントを統合したコア エンジンです。高度なベクトル データベース、エージェント ロジック、クエリ構築、セキュリティ機能、評価のためのトレースはすべてここに存在し、Elastic によって管理および最適化されています。

データの力を解き放つ: 優れたエージェントの基盤は優れたデータです。当社のプラットフォームは、すべての企業データへのアクセスを取り込み、連携する機能から始まります。

プラットフォームにおけるエージェント構築

Search AI プラットフォームに統合された Agent Builder は、エージェント開発のための完全なフレームワークを提供します。これは 5 つの主要な柱に基づいて構築されており、各柱は実稼働レベルの AI システムの構築と展開の重要な側面に対処するように設計されています。エージェントが目的を定義し、ツールが機能を提供し、オープン スタンダードが相互運用性を確保し、評価が透明性をもたらし、セキュリティが信頼を提供する仕組みについて詳しく見ていきましょう。

エージェント

エージェントは、Elasticsearch のこの新しいレイヤーにおける最高レベルの構成要素です。エージェントは、達成する目的、実行に使用できるツールのセット、および操作できるデータ ソースを定義します。エージェントは会話によるやり取りに限定されず、完全なワークフロー、タスクの自動化、ユーザー向けのエクスペリエンスを実現できます。

クエリがエージェントに送られると、構造化されたサイクルに従います。

1. 入力内容と目的を解釈する

2. 実行に適したツールと引数を選択する

3. ツールの応答の理由

4. 結果を返すか、さらにツールの呼び出しを続行するかを決定します

Elastic は、このサイクルのオーケストレーション、コンテキスト、および実行を処理します。開発者は、エージェントが何をすべきか（目的、ツール、データ）を定義することに重点を置き、システムは推論とワークフローの実行方法を管理します。

デフォルトエージェント

このプラットフォーム上に構築された最初のエージェントは、Kibana のネイティブ会話エージェントであり、データとすぐに対話できるようになります。完全な拡張性を維持しながらすぐに使用できるエクスペリエンスを提供し、追加の構成なしですぐにデータの操作を開始できます。

新しいチャット ユーザー エクスペリエンスまたは API を介して、Kibana でこのエクスペリエンスを直接操作できます。

API を介してデフォルトのエージェントを照会するには、1 回の呼び出しだけが必要です。

会話はステートフルなので、 conversation_id を使用してエージェントとの対話を継続したり、完全な会話履歴を取得したりできます。

カスタムエージェント

開発者は、シンプルな API を通じて独自のカスタム エージェントを作成することもできます。エージェントは、指示、ツール、データ アクセスをカプセル化し、カスタマイズされた推論エンジンを作成します。

カスタム エージェントの作成は、1 回の API 呼び出しを行うだけで簡単に行えます。以下のサンプルは例を示しています。「構成」フィールドには、手順や利用可能なツールなどのすべての重要な詳細が含まれています。

作成されたエージェントは直接クエリできます。

このアプローチにより、エージェントはゼロから構築する複雑なシステムから、ビジネス ロジックの単純な宣言型ユニットに変換され、インテリジェントな自動化をより迅速に提供できるようになります。

特化したエージェントをゼロから構築する方法の詳細については、詳細なステップバイステップガイド「初めての Elastic エージェント: 単一のクエリから AI を活用したチャットまで」をご覧ください。

ツール

エージェントが達成すべきことを定義するのに対し、ツールは達成方法を定義します。

ツールは、エージェントが情報を実行および取得したり、アクションを実行したりするための特定の Elastic Core 機能を公開します。ツールには、インデックスの取得やマッピングの取得などのコア機能や、自然言語から ES|QL への変換などのより高度な機能を含めることができます。

Elasticsearch には、一般的なニーズに合わせて最適化された一連のデフォルト ツールが付属しています。しかし、本当の柔軟性は、独自のものを作成することから生まれます。ツールを定義することで、ES|QL を使用してエージェントに公開されるクエリ、インデックス、フィールドを正確に決定し、速度、精度、セキュリティを正確に制御できます。

新しいツールの登録も、1 回の API 呼び出しと同じくらい簡単です。ES|QL (Elasticsearch クエリ言語)を活用して特定の金融資産に関するニュースを検索するツールを作成できます。

登録が完了すると、新しいツールをカスタム エージェントに割り当てることができ、適切なタイミングで推論して呼び出すための厳選された一連の機能をエージェントに提供できるようになります。

当社では、お客様固有のニーズに合わせてカスタム ツールを作成するためのプラットフォームを提供しています。たとえば、ES|QL を使用すると、エージェントを汎用エージェントから、お客様独自のデータとビジネス ドメインに基づいたドメイン固有のエキスパートに変換できます。

オープンスタンダードと相互運用性

Elasticsearch エージェントとツールはオープン標準 API を介して公開されるため、エージェントフレームワークのより広範なエコシステム内の基礎ブロックとして簡単に統合できます。私たちのアプローチはシンプルです。ブラックボックスはありません。Elastic の検索における強みを活かし、それを補完的な機能や他のエージェント システムと組み合わせることができるようにしたいと考えています。

これを実現するために、当社は API、新しいプロトコル、オープン スタンダードを通じて機能を公開しています。

モデルコンテキストプロトコル（MCP）

モデル コンテキスト プロトコル (MCP)は、システム間でツールを接続するためのオープン スタンダードとして急速に普及しつつあります。MCP をサポートすることで、Elasticsearch は会話型 AI をデータベース、インデックス、外部 API に接続できるようになります。Elastic Stack に組み込まれたリモート MCP サーバーを使用すると、MCP 対応のクライアントはどれでも Elastic のツールにアクセスし、それらをより大規模なエージェントワークフローの構成要素として使用できます。

これは一方通行ではありません。外部の MCP サーバーからツールをインポートし、Elasticsearch 内で利用できるようにすることもできます。近い将来、MCP サーバーはほぼすべての用途で利用できるようになる見込みで、私たち自身が作成するものよりもはるかに包括的なものになるでしょう。Elastic は大規模な検索と取得機能を提供しており、これを他のプラットフォームの特殊な機能と組み合わせて効果的なエージェントを構築できます。

エージェント間（A2A）

また、エージェント間 (A2A) サポートにも取り組んでいます。MCP はツールを接続することに重点が置かれていますが、A2A はエージェントを接続することに重点が置かれています。A2A サーバーを使用すると、構築する Elastic エージェントは他のシステムのエージェントと直接通信して、コンテキストを共有したり、タスクを委任したり、ワークフローを調整したりできるようになります。

これを推論層における相互運用性と考えてください。Elastic エージェントは検索と取得を処理し、タスクを専門のサポート エージェントまたは IT エージェントに引き渡して、結果をシームレスに返すことができます。その結果、各エージェントが最善を尽くして協力するエコシステムが実現します。

最終的に、MCP と A2A を採用することで、Elasticsearch が第一級市民としての役割を担うという当社の取り組みが強化され、より広範なエージェントエコシステム全体でのオープンな統合が保証されます。

追跡と評価

検索がエージェントと統合されるにつれて、効果的な評価の課題が重要になります。実際の企業環境にエージェントを自信を持って導入するには、エージェントが正確であるだけでなく、効率的で信頼できるという保証が必要です。パフォーマンスを測定したり、悪い応答を診断したり、ベースラインを改善したりするにはどうすればよいですか?すべては可視性から始まります。

そのため、私たちはエージェント API を最初から透明性を重視して設計しました。次の単純なエージェントのやり取りを考えてみましょう。

応答には、最終的な回答だけでなく、エージェントが選択したツール、使用したパラメーター、各ステップの結果の詳細を含む完全な実行トレースが含まれます。

包括的なトレースとログ記録は継続的な改善ループに不可欠であり、まもなくこれらのエージェント トレースを Elasticsearch に直接保存して表示できるようになります。さらに、これらのトレースは OpenTelemetry プロトコルに基づいて構築されているため、標準化され、移植可能であり、選択した監視プラットフォームとの統合が可能です。

このレベルの詳細は、真の継続的改善ループの基礎となります。これにより、包括的なテスト スイートを構築し、障害をデバッグし、障害モードを特定して回帰を防ぎ、成功パターンをキャプチャしてパフォーマンスを微調整できるようになります。最終的に、このデータ主導のアプローチは、有望なプロトタイプを製品レベルの信頼できる AI システムに変換するための鍵となります。

セキュリティ

エージェントとツールの性能が向上するにつれて、セキュリティはオプションではなく、基礎的なものになります。API を公開し、タスクやワークフローを自動化するには、エンタープライズ システムが信頼されている必要があります。特に、エージェントがより多くのワークフローを自動化し始めると、これらを保護し、企業の要件を満たしていることを確認する機能が不可欠になります。

上記の機能はすべて、API 呼び出しのロールベースのアクセス制御 (RBAC)や API キー管理など、現在 Elastic ですでに利用可能な制御を継承しています。同じ制御を MCP などの新しいプロトコルにも拡張しています。つまり、OAuth などの標準のサポートと、カスタム認証メカニズムをプラグインする機能を意味します。

私たちの目標は、組織が求めるセキュリティ、コンプライアンス、ガバナンスのレベルを維持しながら、エージェントとツールを実験する柔軟性を提供することです。

次に何が起こるか

機能を追加するだけではなく、エージェントコンテキストエンジニアリング向けに Elasticsearch を拡張しています。当社は、以下の理念に基づいて今後開発を進めていく予定です。

1. オープンソースと標準への取り組み

当社はオープン ソースとオープン スタンダードに注力しており、これらの機能が外部のエージェント フレームワークと相互運用可能であることを保証します。データとワークフローを常に管理しながら、エコシステム全体でエージェントを接続、拡張、構成できるようになります。

2. 文脈の価値

AI エージェントのコンテキストは最大の資産です。エージェントが検索やワークフロー操作を実行するときにコンテキストを管理することは、難しいタスクになる可能性があります。私たちは Elastic の強みを活用してコンテキスト エンジニアリングを解決し、エージェントが最も関連性の高い情報を常に利用できるようにしています。

3. エージェントデータストリームに焦点を当てる

今後、エージェントは、エージェントの出力 (生成されたドキュメント、レポート、視覚化) やエージェントの実行トレース (思考、ツールの呼び出し、メモリ/コンテキスト) など、ますます大きなデータソースになります。Elastic はこの種のデータの処理に適しており、私たちはこのデータを使用して分析、評価、自動改善を実行するための研究に取り組んでいます。

4. セキュリティと安全性を考慮した設計

AI エージェントは、セキュリティと安全性に関するまったく新しい一連の課題をもたらします。Elastic は常に安全なソリューションのリーダーであり、エンタープライズグレードのガードレール、アクセス制御、および「ゼロトラスト」原則の構築を継続しています。

5. プラットフォームに組み込む

AI エージェントを構築するための機能は、Elasticsearch プラットフォームに組み込まれています。つまり、トレース、評価、視覚化、分析などのプラットフォーム レベルの機能はすべてエージェントに適用できます。エージェントの実行に基づいてダッシュボードを開発したい - それが組み込まれています。感情分析を使用して AI エージェントのパフォーマンスを評価したい場合、プラットフォームでそれが可能です。これにより、AI エクスペリエンスを中心とした完全なライフサイクルを構築できるようになります。

Elastic の目標は、データに完全に統合され、拡張可能で、データに基づいた会話型 AI と自動化されたワークフローを構築するためのインターフェースを提供することです。より詳しい技術的な詳細と進捗状況については、近日中に共有される予定です。

Agent Builder は現在、プライベート プレビューでご利用いただけます。アクセスをリクエストするには、当社にご連絡ください。ご質問やフィードバックはありますか?Slack ワークスペースまたはディスカッション フォーラムで開発者コミュニティとつながりましょう。

ベクトル検索でのフィルタリングの仕組みを理解すると、パフォーマンスとリコールのトレードオフのバランスをとるのに役立ちます。また、フィルタリングの使用時にベクトル検索のパフォーマンスを高めるために使用される最適化のいくつかを知ることもできます。

なぜフィルタリングするのですか?

ベクトル検索は、大規模なデータセット内で関連情報を検索する方法に革命をもたらし、クエリと意味的に類似する項目を発見できるようになりました。

ただし、類似アイテムを見つけるだけでは十分ではありません。多くの場合、特定の基準や属性に基づいて検索結果を絞り込む必要があります。

電子商取引ストアで商品を検索していると想像してください。純粋なベクター検索では視覚的に類似したアイテムが表示される場合がありますが、価格帯、ブランド、在庫状況、または顧客評価でフィルタリングすることもできます。フィルタリングがなければ、類似した製品が大量に表示され、探しているものを正確に見つけることが難しくなります。

フィルタリングにより、検索結果を正確に制御できるようになり、取得された項目が意味的に一致するだけでなく、必要な要件をすべて満たすことが保証されます。これにより、より正確で効率的、そしてユーザーフレンドリーな検索エクスペリエンスが実現します。

Elasticsearch と Apache Lucene が優れているのはこの点です。さまざまなデータ タイプにわたって効果的なフィルタリングを使用することが、他のベクター データベースとの主な違いの 1 つです。

正確なベクトル検索のためのフィルタリング

正確なベクトル検索を実行するには、主に 2 つの方法があります。

• dense_vector フィールドにflatインデックス タイプを使用します。これにより、 knn検索では近似検索ではなく正確な検索が使用されるようになります。

• ベクトル関数を使用してスコアを計算するscript_score クエリを使用します。これはどのインデックス タイプでも使用できます。

正確なベクトル検索を実行すると、すべてのベクトルがクエリと比較されます。このシナリオでは、フィルターを通過するベクトルのみを比較する必要があるため、フィルタリングによってパフォーマンスが向上します。

いずれにしてもすべてのベクトルが考慮されるため、結果の品質には影響しません。興味のない結果を事前にフィルタリングするだけで、操作の数を減らすことができます。

これは非常に重要です。適用したフィルターによって少数のドキュメントが生成される場合、近似検索ではなく正確な検索を実行するとパフォーマンスが向上する可能性があるためです。

経験則としては、フィルターを通過するドキュメントが 10,000 個未満の場合は完全一致検索を使用します。BBQインデックスは比較が非常に高速なので、ベース インデックスが 10 万未満の場合は、完全一致検索を使用するのが合理的です。詳細については、このブログ投稿をご覧ください。

フィルターが常に非常に制限的である場合は、HNSW ベースのインデックス タイプではなくflatインデックス タイプを使用して、近似検索ではなく完全検索に重点を置いたインデックス作成を検討してください。詳細については、 index_options のプロパティを参照してください。

近似ベクトル検索のためのフィルタリング

近似ベクトル検索を実行する場合、結果の精度とパフォーマンスをトレードオフします。HNSW のようなベクトル検索データ構造は、数百万のベクトルのおおよその最近傍を効率的に検索します。計算コストのかかるベクトル比較を最小限に抑えて、最も類似したベクトルを取得することに重点を置いています。

つまり、他のフィルタリング属性はベクター データの一部ではないということです。さまざまなデータ タイプには、用語辞書、投稿リスト、ドキュメント値など、検索やフィルタリングに効率的な独自のインデックス構造があります。

これらのデータ構造はベクトル検索メカニズムとは別であるため、ベクトル検索にフィルタリングをどのように適用すればよいでしょうか?フィルターには、ベクター検索の後にフィルターを適用する (ポストフィルタリング) か、ベクター検索の前にフィルターを適用する (プレフィルタリング) という 2 つのオプションがあります。

それぞれの選択肢には長所と短所があります。詳しく見ていきましょう！

ポストフィルタリング

ポストフィルタリングは、ベクトル検索が完了した後にフィルターを適用します。これは、最も類似した上位 k 個のベクトル結果が見つかった後にフィルターが適用されることを意味します。

明らかに、結果にフィルターを適用した後、 k 件未満の結果が返される可能性があります。もちろん、ベクトル検索 (より高い k 値) からより多くの結果を取得できますが、フィルターを適用した後に k 以上の結果が得られるかどうかはわかりません。

ポストフィルタリングの利点は、ベクトル検索の実行時の動作を変更しないことです。つまり、ベクトル検索はフィルタリングを認識しません。ただし、取得される結果の最終的な数は変わります。

以下は、 knn クエリを使用したポストフィルタリングの例です。フィルタリング句が knn クエリとは別であることを確認します。

post-filterを使用した knn 検索では、ポストフィルタリングも利用できます。

knn 検索では明示的なポストフィルター セクションを使用する必要があることに注意してください。ポストフィルターを使用しない場合、knn 検索はポストフィルターを実行する代わりに、最近傍の結果を他のクエリまたはフィルターと組み合わせます。

プレフィルタリング

ベクトル検索の前にフィルターを適用すると、まずフィルターを満たすドキュメントが取得され、次にその情報がベクトル検索に渡されます。

Lucene はBitSetsを使用して、フィルター条件を満たすドキュメントを効率的に保存します。次に、ベクトル検索は条件を満たすドキュメントを考慮して、HNSW グラフを走査します。候補を結果に追加する前に、それが有効なドキュメントの BitSet に含まれているかどうかを確認します。

ただし、有効なドキュメントでない場合でも、候補を調査してクエリと比較する必要があります。HNSW の有効性は、グラフ内のベクトル間の接続に依存します。つまり、候補の探索を停止すると、その近傍もスキップされる可能性があることを意味します。

ガソリンスタンドに行くために車を運転するのを想像してください。ガソリンスタンドのない道路を無視すると、目的地にたどり着く可能性は低くなります。他の道はあなたにとって必要なものではないかもしれませんが、目的地まであなたを繋いでくれます。HNSW グラフ上のベクトルも同様です。

したがって、プレフィルタリングを適用すると、フィルタを適用しない場合よりもパフォーマンスが低下します。検索で訪れるすべてのベクトルに対して作業を実行し、フィルターに一致しないベクトルを破棄する必要があります。私たちは、トップ k の結果を得るために、より多くの作業とより多くの時間をかけています。

以下は、Elasticsearch クエリ DSL での事前フィルタリングの例です。フィルタリング句が knn セクションの一部になっていることを確認します。

事前フィルタリングは、 knn 検索とknn クエリの両方で利用できます。

プレフィルタリングの最適化

プレフィルタリングのパフォーマンスを確保するために適用できる最適化がいくつかあります。

フィルターの制限が厳しい場合は、完全一致検索に切り替えることができます。比較するベクトルが少ない場合は、フィルターを満たす少数のドキュメントに対して正確な検索を実行する方が高速です。

これは、 Luceneおよび Elasticsearch で自動的に適用される最適化です。

別の最適化方法では、フィルターの条件を満たさないベクトルを無視します。代わりに、このメソッドは、フィルターを通過するフィルター処理されたベクトルの近傍をチェックします。このアプローチでは、フィルタリングされたベクトルは考慮されず、現在のパスに接続されたベクトルの探索が継続されるため、比較の回数が効果的に削減されます。

このアルゴリズムは ACORN-1 であり、そのプロセスについてはこちらのブログ記事で詳しく説明されています。

ドキュメントレベルのセキュリティを使用したフィルタリング

ドキュメント レベル セキュリティ (DLS)は、ユーザー ロールが取得できるドキュメントを指定する Elasticsearch 機能です。

DLS はクエリを使用して実行されます。ロールにはインデックスに関連付けられたクエリを持たせることができ、これにより、そのロールに属するユーザーがインデックスから取得できるドキュメントを効果的に制限できます。

ロール クエリは、それに一致するドキュメントを取得するためのフィルターとして使用され、BitSet としてキャッシュされます。この BitSet は、基盤となる Lucene リーダーをラップするために使用されるため、クエリから返されたドキュメントのみがライブであると見なされます。つまり、それらのドキュメントはインデックス上に存在し、削除されていません。

knn クエリを実行するためにリーダーからライブ ドキュメントが取得されるため、ユーザーが利用できるドキュメントのみが考慮されます。プレフィルターがある場合は、DLS ドキュメントがそれに追加されます。

つまり、DLS フィルタリングは、近似ベクトル検索のプレフィルタとして機能し、同じパフォーマンスへの影響と最適化を実現します。

完全一致検索を使用した DLS には、任意のフィルターを適用する場合と同じ利点があります。つまり、DLS から取得されるドキュメントが少ないほど、完全一致検索のパフォーマンスが向上します。DLS によって返されるドキュメントの数も考慮してください。DLS ロールの制限が非常に厳しい場合は、近似検索ではなく完全検索の使用を検討してください。

ベンチマーク

Elasticsearch では、ベクトル検索フィルタリングが効率的であることを確認したいと考えています。当社には、さまざまなフィルタリングを使用して近似ベクトル検索を実行するベクトル フィルタリング用の特定のベンチマークがあり、ベクトル検索で関連する結果を可能な限り高速に取得し続けることができるようにします。

ACORN-1 が導入されたときの改善点を確認します。ベクトルの 2% のみがフィルターを通過するテストでは、クエリの待機時間は元の期間の 55% に短縮されます。

まとめ

フィルタリングは検索の不可欠な部分です。ベクトル検索でフィルタリングのパフォーマンスを確保し、トレードオフと最適化を理解することが、効率的で正確な検索の成否を左右します。

フィルタリングはベクトル検索のパフォーマンスに影響します。

• フィルタリングを使用すると、正確な検索が高速になります。フィルタリングが十分に制限されている場合は、近似検索ではなく完全検索の使用を検討する必要があります。これは Elasticsearch での自動最適化です。

• 事前フィルタリングを使用すると近似検索が遅くなります。事前フィルタリングを使用すると、検索速度は遅くなりますが、フィルターに一致する上位 k 件の結果を取得できます。

• ポストフィルタリングでは、フィルターの適用時にフィルターによってフィルタリングされる可能性があるため、必ずしも上位 k 件の結果が取得されるわけではありません。

フィルタリングをお楽しみください！