検索は死んでいない、ただ移動しただけだ

そのため、主にテキスト ボックスでコンテキストを検索し、返された情報 (コンテキスト) を使用して自分で回答を構築するという方法から、自然言語を使用してエージェントに必要なものを伝え、エージェントが自動的に回答を調査してまとめる方法へと移行しました。テクノロジー業界の多くの人々は、この変化を指摘し、「検索は死んだ」と主張しています（まあ、SEO とアドワーズの世界は確実に変化しています。GEOはどうですか？）。しかし、検索は依然として代理店の業務にとって絶対に不可欠です。ただ、現在では主にツールを介して目に見えない形で実行されているだけです。

以前は、主観的な関連性の主な判断者は人間でした。各ユーザーには検索を実行する独自の理由があり、個人的な経験が結果の相対的な正確性に影響を与えていました。エージェントが私たちと同じ（あるいはそれ以上の）結論に達することができると信頼するには、エージェントがアクセスできるコンテキスト情報が私たちの主観的な意図に可能な限り近いことを保証する必要があります。私たちはその目標に向けて、LLM に提供するコンテキストを設計する必要があります。

ハイブリッド検索によるコンテキストの生成

パート I でもう一度お伝えしましたが、Elastic のハイブリッド検索は、従来のキーワードベースの検索の強み (構文の柔軟性、キーワードの精度、関連性のスコアリング) とベクトル類似性検索の意味理解を組み合わせ、複数の再ランキング手法を提供します。この相乗効果（この言葉のより正確な使い方はこれまで見つかりませんでした！）クエリによってコンテンツをターゲットする方法がより細かく指定できるため、関連性の高い結果を得ることができます。主観的関連性を検索段階の1 つとして適用できるというだけでなく、実際には、第 1 段階の検索に関連性スコアリングを他のすべてのモードとともに一度に含めることができるのです。

優れた精度と効率

分散検索、取得、再ランク付け機能を備えたデータ プラットフォームを主要なコンテキスト検索エンジンとして使用することは、非常に理にかなっています。高度なクエリ構文を使用して、主観的な意図の欠落したコンポーネントを追加し、返されるコンテキスト情報の価値を損なったり不明瞭にしたりする可能性のあるコンテンツを除外できます。利用可能な個々の構文オプションから選択することも、モダリティを単一の検索に組み合わせて、各データの種類を最もよく理解できる方法でターゲットにし、それらを再ランク付けして組み合わせたり並べ替えたりすることもできます。不要なデータを除外し、必要なフィールド/値のみが含まれるように応答をフィルタリングできます。エージェントにとって、このターゲティングの柔軟性により、コンテキストを非常に正確に取得できるツールを構築できます。

コンテキストの洗練（集約と非コンテンツシグナル）

集約は、ツールがコンテキスト ウィンドウに配信するコンテンツを形成する際に特に役立ちます。集計により、返されるコンテキスト データの形状に関する数値ベースの事実が自然に提供されるため、LLM による推論がより容易かつ正確になります。集計は階層的にネストできるため、LLM に複数レベルの詳細を追加して、より微妙な理解を深めることが簡単にできます。集計はコンテキスト ウィンドウのサイズの管理にも役立ちます。10 万件のドキュメントのクエリ結果を、集約された分析情報の数百トークンに簡単に減らすことができます。

非コンテンツ シグナルは、データに内在する指標であり、見ているものの全体像を示します。つまり、人気、鮮度、地理的位置、カテゴリ、ホストの多様性、価格帯など、結果の追加特性です。これらの情報は、エージェントが受け取ったコンテキストの重要性をどのように評価するかをエージェントに通知するのに役立ちます。これを最もよく説明するために、いくつかの簡単な例を挙げます。

• 最近公開されたコンテンツや人気コンテンツの強化- 記事のナレッジ ベースがあると想像してください。ユーザーのクエリに関連する記事を見つけたいが、最近の記事であり、他のユーザーに役立つと判断された記事（「いいね」の数が多いなど）を優先したいとします。このシナリオでは、ハイブリッド検索を使用して関連する記事を見つけ、公開日と人気度の組み合わせに基づいて記事を再ランク付けすることができます。

• 売上と在庫調整を伴う電子商取引の検索- 電子商取引の設定では、検索語に一致する製品を顧客に表示したいだけでなく、売れ行きがよく在庫がある製品を宣伝したいとも考えます。顧客の不満を避けるために、在庫が少ない商品のランクを下げることもできます。

• バグ トラッカーで重大度の高い問題を優先する- ソフトウェア開発チームにとって、問題を検索する際には、重大度が高く、優先度が高く、最近更新された問題を最初に表示することが重要です。「重要度」や「最も議論されている」などの非シグナルを使用して、さまざまな要素を個別に評価し、最も重要で活発に議論されている問題が最上位に表示されるようにすることができます。

これらのサンプルクエリおよびその他の詳細は、付属の Elasticsearch Labsコンテンツ ページにあります。

セキュリティ強化

コンテキストエンジニアリングに Elastic のような検索を活用したスピードレイヤーを活用する重要な利点は、セキュリティ フレームワークが組み込まれていることです。Elastic のプラットフォームは、きめ細かなロールベースのアクセス制御 (RBAC) と属性ベースのアクセス制御 (ABAC) を通じて、エージェントおよび生成 AI オペレーションに提供されるコンテキストが機密性の高い非公開情報を尊重して保護することを保証します。これは、クエリが効率的に処理されるだけでなく、エージェントまたはリクエストを開始したユーザーの特定の権限に応じて結果がフィルタリングされることを意味します。

エージェントは認証されたユーザーとして実行されるため、プラットフォームに組み込まれたセキュリティ機能を通じてセキュリティが暗黙的に適用されます。

• きめ細かな権限:ドキュメント、フィールド、さらには用語レベルでアクセスを定義し、AI エージェントが表示を許可されているデータのみを受信するようにします。

• ロールベースのアクセス制御 (RBAC):エージェントまたはユーザーにロールを割り当て、定義された責任に基づいて特定のデータセットまたは機能へのアクセスを許可します。

• 属性ベースのアクセス制御 (ABAC):データ、ユーザー、または環境の属性に基づいて動的なアクセス ポリシーを実装し、適応性の高いコンテキスト認識型のセキュリティを実現します。

• ドキュメント レベルのセキュリティ (DLS) とフィールド レベルのセキュリティ (FLS):これらの機能により、取得したドキュメント内でも許可された部分のみが表示されるようになり、機密情報の漏洩を防止できます。

• エンタープライズ セキュリティとの統合:既存の ID 管理システム (LDAP、SAML、OIDC など) とシームレスに統合し、組織全体で一貫したセキュリティ ポリシーを適用します。

これらのセキュリティ対策をコンテキスト取得メカニズムに直接統合することで、Elastic は安全なゲートキーパーとして機能し、AI エージェントが定義されたデータ境界内で動作し、不正なデータ公開を防ぎ、データプライバシー規制へのコンプライアンスを維持できるようにします。これは、機密情報や独自情報を扱うエージェント AI システムへの信頼を構築する上で非常に重要です。

追加のボーナスとして、エンタープライズ データ ソース上で統合されたデータ スピード レイヤーを使用することで、エージェント ツールによって作成されるリポジトリでの予期しないアドホック クエリ負荷を軽減できます。ほぼリアルタイムであらゆるものを検索できる単一の場所と、セキュリティとガバナンスの制御を適用できる単一の場所が提供されます。

ハイブリッド検索ベースのツール

Elastic プラットフォームには、コンテキスト エンジニアリングの追求を加速させるコア機能がいくつかあります (今後もさらに増える予定です)。ここで重要なのは、このプラットフォームが、AI エコシステムの進化に合わせて方法を適応、変更、拡張できる柔軟性を備え、さまざまな達成方法を提供していることです。

エージェントビルダーの紹介

Elastic Agent Builder は、Elastic にすでに保存されているデータと対話するために構築されたエージェント AI ツールの領域への最初の進出です。Agent Builder は、ユーザーが Kibana 内で独自のエージェントとツールを作成および管理できるようにするチャット インターフェースを提供します。組み込みの MCP および A2A サーバー、プログラム API、Elasticsearch インデックスのクエリと探索、および自然言語からの ES|QL クエリの生成用の一連の構築済みシステム ツールが付属しています。Agent Builder を使用すると、表現力豊かなES|QLクエリ構文を通じてエージェントに返されるコンテキスト データをターゲットにして整形するカスタム ツールを作成できます。

ES|QL はハイブリッド検索をどのように実行するのでしょうか?コア機能は、 semantic_textフィールド タイプとFORK / FUSEコマンドの組み合わせによって実現されます (FUSE はデフォルトでRRFを使用して各フォークの結果をマージします)。架空の製品検索の簡単な例を次に示します。

上記の例の各 FORK ブランチに含まれるEVAL句は厳密には必須ではありません。これは、特定の結果がどの検索モダリティから返されたかを追跡する方法を示すためだけに含まれています。

検索テンプレート

独自の外部エージェントツールを Elastic デプロイメントにポイントするとします。また、ES|QL の代わりに、マルチステージ リトリーバーを使用したり、開発した既存の DSL 構文を再利用したり、クエリが受け入れる入力、検索を実行するために使用される構文、および出力で返されるフィールドを制御できるようにしたいと考えています。検索テンプレートを使用すると、ユーザーは一般的な検索パターンの定義済み構造を定義できるため、データ取得の効率と一貫性が向上します。これは、定型コードの標準化と検索ロジックの高速な反復処理を可能にするため、検索 API と対話するエージェント ツールにとって特に有益です。そして、これらの要素のいずれかを調整する必要がある場合は、検索テンプレートを更新するだけで、変更が実装されます。エージェントツールで実際に実行される検索テンプレートの例を探している場合は、Elasticsearch Labs のブログ「 MCP for intelligent search 」をご覧ください。このブログでは、外部 MCP サーバーからのツール呼び出しの背後で検索テンプレートが使用されています。

統合ワークフロー (最高!)

新しいエージェント AI の世界で最も扱いにくいことの 1 つは、半自律型で自己指向的な「推論」エージェントの非決定論的な性質です。コンテキスト エンジニアリングは、エージェント AI にとって非常に重要な分野です。これは、エージェントが生成できる可能性のある結論を、私たちが知っている事実に絞り込むのに役立つ手法です。非常に正確で関連性の高いコンテキスト ウィンドウがあっても、(数値的事実の領域から外れると) エージェントの応答が完全に再現可能で信頼できるという安心感がまだ少し欠けています。

エージェントに対して同じリクエストを複数回実行すると、応答に わずかな違いがあるだけ で、回答は 基本的に 同じになる可能性があります。これは通常、単純なクエリでは問題なく、ほとんど気づかれない程度で、コンテキスト エンジニアリング手法を使用して出力を調整することができます。しかし、エージェントに要求するタスクが複雑になるにつれて、1 つ以上のサブタスクによって差異が生じ、最終結果がわずかに変わる可能性が高くなります。エージェント間のコミュニケーションにさらに依存するようになると、状況はさらに悪化し、差異が累積していくでしょう。これは、エージェントが対話するツールは、コンテキスト データを正確にターゲットにするために非常に柔軟かつ調整可能である必要があり、予期される出力形式で応答する必要があるという考えを再び示しています。また、多くのユースケースでは、エージェントとツールのやり取りを誘導する必要があることも示しています。ここでワークフローが登場します。

Elastic ではまもなく、プラットフォームの中核に完全にカスタマイズ可能なワークフローが組み込まれる予定です。これらのワークフローはエージェントやツールと双方向に操作できるため、ワークフローはエージェントやツールを呼び出すことができ、エージェントやツールはワークフローを呼び出すことができます。これらの機能が、すべてのデータが存在する同じ検索 AI プラットフォームに完全に統合されることで、ワークフローの可能性は大きく変化します。もうすぐ、もうすぐ登場です！

統合メモリバンクとしてのElastic

Elastic は、ほぼリアルタイムの検索向けに作られた分散データ プラットフォームであるため、エージェント AI システムの長期メモリ機能を自然に実行します。組み込みの Agent Builder チャット エクスペリエンスにより、短期記憶とチャット履歴の追跡と管理も行えます。また、プラットフォーム全体が API ファーストであるため、エージェントのコンテキスト ウィンドウを圧倒する可能性のあるツールのコンテキスト出力を永続化するためのプラットフォームとして Elastic を利用する（そして後で参照できるようにする）ことは非常に簡単です。この手法は、コンテキスト エンジニアリングの分野では「メモを取る」と呼ばれることもあります。

同じ検索プラットフォームに短期記憶と長期記憶の両方を持つことで、多くの本質的なメリットが生まれます。チャット履歴と永続的なコンテキスト応答を、将来のチャットのやり取りに対する意味的影響要因の一部として使用したり、脅威分析を実行したり、頻繁に繰り返されるツール呼び出しから自動的に生成される永続的なデータ製品を作成したりできるようになることを想像してみてください。可能性は無限です。

まとめ

大規模言語モデルの出現により、コンテンツを一致させる方法や、データを調査するために使用する手法が変化しました。私たちは、人間が自らの疑問に答えるために調査、状況の考慮、論理的推論を行う現在の世界から、それらのステップがエージェント AI によって大部分が自動化される世界へと急速に移行しつつあります。生成された回答を信頼するには、エージェントが応答を生成する際に最も関連性の高い 情報（主観的関連性の要素を含む） をすべて 考慮したという保証が必要です。エージェント AI を信頼できるものにするための主な方法は、RAG とコンテキスト エンジニアリング技術を通じて追加のコンテキストを取得するツールを基盤化することですが、それらのツールが最初の取得をどのように実行するかが応答の精度に非常に重要になる場合があります。

Elastic Search AI プラットフォームは、ハイブリッド検索の柔軟性と利点に加えて、エージェント AI の精度、パフォーマンス、スケーラビリティを向上させるいくつかの組み込み機能を提供します。つまり、Elastic はコンテキスト エンジニアリングのさまざまな側面に対応する素晴らしいプラットフォームを実現します。検索プラットフォームを介したコンテキスト検索の標準化により、エージェントツールの操作がいくつかの面で簡素化されます。「速度を落としてスピードを上げる」という矛盾した表現と同様に、コンテキスト生成レイヤーの簡素化は、より高速で信頼性の高いエージェントAIを意味します。

データと対話する新しい方法

ジェネレーティブ (genAI) AI とエージェント AI は、従来の検索とは異なる処理を行います。かつて私たちが情報を調べ始める方法は検索（「グーグルで検索してみます…」）でしたが、gen AI とエージェントの両方にとって、開始アクションは通常、チャット インターフェースに入力された自然言語を通じて行われます。チャット インターフェースは、意味理解を使用して質問を簡潔な回答、つまりあらゆる種類の情報に関する幅広い知識を持つ予言者から出されたような要約された応答に変換する LLM とのディスカッションです。本当に売れているのは、LLM が表面化した知識の断片をつなぎ合わせて首尾一貫した思慮深い文章を生成する能力です。たとえそれが不正確であったり完全に幻覚的であったりしても、そこには真実味があります。

私たちが使い慣れている古い検索バーは、私たち自身が推論エージェントであったときに使用した RAG エンジンと考えることができます。現在では、インターネット検索エンジンでさえ、使い古された「ハント・アンド・ペック」という語彙検索エクスペリエンスを、クエリに対する結果の要約で答える AI 主導の概要へと変えつつあり、ユーザーがクリックして個々の結果を自分で評価する必要がないようにしています。

生成AIとRAG

生成 AI は、世界の意味理解を活用してチャット リクエストを通じて表明された主観的な意図を解析し、推論能力を使用して専門的な回答を即座に作成します。生成 AI インタラクションにはいくつかの部分があります。ユーザーの入力/クエリから始まり、チャット セッションでの以前の会話が追加のコンテキストとして使用でき、LLM に推論方法と応答の構築手順を指示する指示プロンプトがあります。プロンプトは、「5 歳児に説明するように説明してください」という単純なタイプのガイダンスから、リクエストを処理する方法の完全な詳細へと進化しました。これらの内訳には、AI のペルソナ/役割、生成前の推論/内部思考プロセス、客観的な基準、制約、出力形式、対象者、および期待される結果を示すのに役立つ例の詳細を説明する個別のセクションが含まれることがよくあります。

ユーザーのクエリとシステム プロンプトに加えて、検索拡張生成 (RAG) は、「コンテキスト ウィンドウ」と呼ばれる追加のコンテキスト情報を提供します。RAG はアーキテクチャへの重要な追加機能であり、世界の意味理解において欠落している部分を LLM に通知するために使用します。

コンテキスト ウィンドウは、何を、どこに、どれだけ与えるかという点では、かなり細かい指定が必要になる場合があります。もちろん、どのコンテキストが選択されるかは非常に重要ですが、提供されたコンテキストの信号対雑音比やウィンドウの長さも重要です。

情報が少なすぎる

クエリ、プロンプト、またはコンテキスト ウィンドウに提供される情報が少なすぎると、LLM が応答を生成するための正しいセマンティック コンテキストを正確に判断できないため、幻覚が発生する可能性があります。また、ドキュメント チャンク サイズのベクトル類似性にも問題があります。つまり、短くて単純な質問は、ベクトル化された知識ベースにある豊富で詳細なドキュメントと意味的に一致しない可能性があります。Hypothetical Document Embeddings (HyDE)などのクエリ拡張手法が開発され、LLM を使用して、短いクエリよりも豊富で表現力豊かな仮説的な回答を生成します。もちろん、ここでの危険は、仮説文書自体が LLM を正しい文脈からさらに逸脱させる幻覚であるということです。

情報が多すぎる

私たち人間と同じように、コンテキスト ウィンドウに情報が多すぎると、LLM は重要な部分が何であるのかについて混乱し、圧倒されてしまう可能性があります。コンテキスト オーバーフロー (または「コンテキスト ロット」) は、生成 AI 操作の品質とパフォーマンスに影響します。LLM の「注意予算」(作業メモリ) に大きな影響を与え、競合する多くのトークン間の関連性を薄めます。「コンテキスト腐敗」の概念には、LLM が位置の偏りを持つ傾向があるという観察も含まれます。つまり、LLM はコンテキスト ウィンドウの中央セクションのコンテンツよりも、コンテキスト ウィンドウの先頭または末尾のコンテンツを優先します。

気が散ったり矛盾したりする情報

コンテキスト ウィンドウが大きくなるほど、LLM が正しいコンテキストを選択して処理する妨げとなる余分な情報や矛盾した情報が含まれる可能性が高くなります。ある意味、これは「ガベージ イン/ガベージ アウト」の問題になります。つまり、ドキュメント結果セットをコンテキスト ウィンドウにダンプするだけで、LLM に処理すべき大量の情報が提供されます (多すぎる可能性があります)。ただし、コンテキストの選択方法によっては、矛盾した情報や無関係な情報が入り込む可能性が高くなります。

エージェント型AI

カバーすべき内容がたくさんあると言いましたが、ついにエージェント AI のトピックについて話すことができました。エージェント AI は、LLM チャット インターフェイスの非常にエキサイティングな新しい使用法であり、独自の知識とユーザーが提供するコンテキスト情報に基づいて応答を合成する生成 AI (すでに「レガシー」と呼んでもいいでしょうか?) の機能を拡張します。生成 AI が成熟するにつれて、当初は人間が簡単に確認/検証できる、面倒でリスクの低いアクティビティに限定されていた、一定レベルのタスク処理と自動化を LLM に実行させることができることに気付きました。短期間で、当初のスコープは拡大しました。LLM チャット ウィンドウは、AI エージェントが自律的に計画、実行し、指定された目標を達成するためにその計画を反復的に評価および適応させるきっかけとなることができるようになりました。エージェントは、LLM 自身の推論、チャット履歴、思考メモリ (現状のまま) にアクセスでき、その目標達成に向けて活用できる特定のツールも利用できます。また、トップレベルのエージェントが、それぞれ独自のロジック チェーン、命令セット、コンテキスト、ツールを持つ複数のサブエージェントのオーケストレーターとして機能することを可能にするアーキテクチャも登場しています。

エージェントは、ほぼ自動化されたワークフローへのエントリ ポイントです。エージェントは自己主導型であり、ユーザーとチャットしてから「ロジック」を使用して、ユーザーの質問に答えるために使用できるツールを決定します。ツールは通常、エージェントに比べて受動的であると考えられており、1 種類のタスクを実行するために構築されています。ツールが実行できるタスクの種類はほぼ無限です (これは本当に素晴らしいことです!) が、ツールが実行する主なタスクは、エージェントがワークフローを実行する際に考慮するコンテキスト情報を収集することです。

技術としては、エージェント AI はまだ初期段階にあり、注意欠陥障害に相当する LLM になりがちです。つまり、指示されたことをすぐに忘れてしまい、指示にまったく含まれていない他の作業に走り出してしまうことがよくあります。一見魔法のように見えますが、LLM の「推論」機能は、シーケンス内で次に最も可能性の高いトークンを予測することに基づいています。推論（あるいは将来的には、汎用人工知能（AGI））が信頼できるものになるためには、正確で最新の情報が与えられたときに、私たちが期待する通りに推論してくれるか（そしておそらく、私たち自身では考えつかなかったようなちょっとした追加情報を提供してくれるか）を検証できなければなりません。これを実現するには、エージェント アーキテクチャに、明確に通信する機能 (プロトコル)、指定されたワークフローと制約を順守する機能 (ガードレール)、タスク内の位置を記憶する機能 (状態)、使用可能なメモリ領域を管理する機能、応答が正確でありタスクの基準を満たしていることを検証する機能が必要になります。

私に理解できる言語で話してください

新しい開発分野ではよくあることですが (特に LLM の世界ではそうです)、当初はエージェントとツール間の通信にはかなり多くのアプローチがありましたが、すぐにモデル コンテキスト プロトコル (MCP) が事実上の標準として採用されました。モデル コンテキスト プロトコルの定義はまさにその名前の通りで、 モデルが コンテキスト 情報を要求および受信するために使用する プロトコル です。MCP は、LLM エージェントが外部ツールやデータ ソースに接続するためのユニバーサル アダプタとして機能し、さまざまな LLM フレームワークやツールが簡単に相互運用できるように API を簡素化および標準化します。そのため、MCP は、エージェントが目的を達成するために自律的に実行するために与えられるオーケストレーション ロジックとシステム プロンプトと、より分離された形式 (少なくとも開始エージェントに関しては分離された形式) で実行するためにツールに送信される操作との間の、一種のピボット ポイントになります。

このエコシステムは非常に新しいため、あらゆる方向への拡大が新たなフロンティアのように感じられます。エージェント間のインタラクション（もちろんAgent2Agent (A2A) ）用の類似プロトコルのほか、エージェントの推論メモリを改善するプロジェクト（ ReasoningBank ）、手元のジョブに最適な MCP サーバーを選択するプロジェクト（ RAG-MCP ）、ゼロショット分類や入力と出力のパターン検出などのセマンティック分析をガードレールとして使用してエージェントが操作できる内容を制御するプロジェクトもあります。

これらの各プロジェクトの根本的な目的は、エージェント/genAI コンテキスト ウィンドウに返される情報の品質と制御を向上させることであることにお気づきでしょうか。エージェント AI エコシステムは、コンテキスト情報をより適切に処理する (制御、管理、操作する) 能力の開発を継続していますが、エージェントが処理するための最も関連性の高いコンテキスト情報を取得する必要性は常に存在します。

コンテキストエンジニアリングへようこそ!

生成 AI の用語に詳しい方なら、おそらく「プロンプト エンジニアリング」という言葉を聞いたことがあるでしょう。現時点では、プロンプト エンジニアリングはそれ自体がほぼ疑似科学となっています。プロンプト エンジニアリングは、LLM が応答を生成する際に使用する動作を積極的に記述するための最良かつ最も効率的な方法を見つけるために使用されます。「コンテキスト エンジニアリング」は、「プロンプト エンジニアリング」の手法をエージェント側を超えて拡張し、MCP プロトコルのツール側で利用可能なコンテキスト ソースとシステムもカバーし、コンテキストの管理、処理、生成という幅広いトピックを扱います。

• コンテキスト管理- 長時間実行される、またはより複雑なエージェント ワークフロー全体で状態とコンテキストの効率を維持することに関連します。エージェントの目標を達成するために、タスクとツールの呼び出しを繰り返し計画、追跡、オーケストレーションします。エージェントが動作しなければならない「注意予算」は限られているため、コンテキスト管理は主に、コンテキスト ウィンドウを絞り込んでコンテキストの最大限の範囲と最も重要な部分 (精度と再現率) の両方をキャプチャするのに役立つ手法に関係しています。技術には、圧縮、要約、前のステップまたはツール呼び出しからのコンテキストを永続化して、後続のステップで追加のコンテキストのために作業メモリ内にスペースを確保することが含まれます。

• コンテキスト処理- エージェントがすべてのコンテキストをある程度統一された方法で推論できるように、異なるソースから取得したコンテキストを統合、正規化、または調整するための論理的かつできればほとんどプログラム的な手順。基本的な作業は、すべてのソース (プロンプト、RAG、メモリなど) からのコンテキストを、エージェントが可能な限り効率的に使用できるようにすることです。

• コンテキスト生成- コンテキスト処理が、取得したコンテキストをエージェントが使用できるようにすることであるならば、コンテキスト生成は、追加のコンテキスト情報を自由に、しかし制約付きで要求して受け取るための範囲をエージェントに提供します。

LLM チャット アプリケーションのさまざまな一時的な機能は、コンテキスト エンジニアリングの高レベル機能に直接 (場合によっては重複して) マッピングされます。

• 指示 / システム プロンプト- プロンプトは、生成的 (またはエージェント的) AI アクティビティがユーザーの目標を達成するためにどのように思考を導くかを示す足場です。プロンプトはそれ自体がコンテキストです。単なる音声による指示ではなく、回答がユーザーの要求に完全に応えているかどうかを確認するために、応答する前に「段階的に考える」や「深呼吸する」などのタスク実行ロジックやルールも含まれることがよくあります。最近のテストでは、マークアップ言語はプロンプトのさまざまな部分を組み立てるのに非常に効果的であることが示されていますが、指示を曖昧になりすぎず、具体的になりすぎないように注意して調整する必要があります。LLM が適切なコンテキストを見つけるのに十分な指示を与える必要がありますが、予期しない洞察を見逃すほど規範的であってはなりません。

• 短期記憶(状態/履歴) - 短期記憶は、基本的にユーザーと LLM 間のチャット セッションのやり取りです。これらはライブ セッションのコンテキストを絞り込むのに役立ち、将来の取得や続行のために保存できます。

• 長期記憶- 長期記憶は、複数のセッションにわたって役立つ情報で構成されている必要があります。また、RAG を通じてアクセスされるのはドメイン固有の知識ベースだけではありません。最近の研究では、以前のエージェント/生成 AI 要求の結果を使用して、現在のエージェントのやり取り内で学習および参照を行っています。長期記憶領域における最も興味深い革新のいくつかは、エージェントが中断したところから再開できるように、状態がどのように保存され、リンクされるかを調整することに関係しています。

• 構造化された出力- 認知には努力が必要なので、推論能力があっても、LLM が (人間と同じように) 考えるときにあまり努力を費やしたくないのは当然です。また、定義された API やプロトコルがない場合、ツール呼び出しから返されたデータを読み取る方法のマップ (スキーマ) を持つことは非常に役立ちます。構造化出力をエージェント フレームワークの一部として組み込むと、思考主導の解析の必要性が減り、マシン間のやり取りがより高速かつ信頼性が高くなるようになります。

• 利用可能なツール- ツールは、追加情報の収集 (エンタープライズ データ リポジトリへの RAG クエリの発行、またはオンライン API 経由の RAG クエリの発行など) から、エージェントに代わって自動アクションを実行すること (エージェントからのリクエストの基準に基づいてホテルの部屋を予約するなど) まで、さまざまな処理を実行できます。ツールは、独自のエージェント処理チェーンを持つサブエージェントになることもできます。

• 検索拡張生成 (RAG) - RAG の「動的な知識統合」という説明がとても気に入っています。前述のように、RAG は LLM がトレーニング時にアクセスできなかった追加情報を提供するための手法であり、主観的なクエリに最も関連性の高い正しい答えを得るために最も重要だと考えられるアイデアを繰り返し述べたものです。

驚異的な宇宙のパワー、小さな居住空間！

エージェント AI には、探索すべき魅力的でエキサイティングな新しい領域が数多くあります。解決すべき従来のデータ検索および処理の問題はまだたくさんありますが、LLM の新時代に初めて日の目を見るようになったまったく新しい種類の課題もあります。私たちが現在取り組んでいる差し迫った問題の多くは、コンテキスト エンジニアリング、つまり、LLM の限られた作業メモリ空間を圧迫することなく、必要な追加のコンテキスト情報を取得することに関係しています。

さまざまなツール (および他のエージェント) にアクセスできる半自律エージェントの柔軟性により、AI を実装するための非常に多くの新しいアイデアが生まれ、さまざまな方法でそれらを組み合わせることができるのかを推測するのは困難です。現在の研究のほとんどはコンテキスト エンジニアリングの分野に属し、大量のコンテキストを処理および追跡できるメモリ管理構造の構築に重点を置いています。これは、LLM に解決してほしい深い思考の問題には、記憶することが極めて重要となる、複雑さが増し、実行時間が長く、多段階の思考ステップが含まれるためです。

この分野で現在行われている多くの実験では、エージェントの口を満たすための最適なタスク管理とツール構成を見つけようとしています。エージェントの推論チェーンにおける各ツール呼び出しは、そのツールの機能を実行するための計算と、制限されたコンテキスト ウィンドウへの影響の両方の点で累積的なコストを発生させます。LLM エージェントのコンテキストを管理する最新の技術の一部は、長時間実行されるタスクの蓄積されたコンテキストを圧縮/要約すると損失が 大きくなりすぎる 「 コンテキストの崩壊 」などの意図しない連鎖効果を引き起こしています。望ましい結果は、貴重なコンテキスト ウィンドウのメモリ領域に余分な情報が漏れることなく、簡潔で正確なコンテキストを返すツールです。

可能性が多すぎる

私たちはツール/コンポーネントを再利用するための柔軟性を備えた職務の分離を望んでいるため、特定のデータ ソースに接続するための専用のエージェント ツールを作成することは完全に理にかなっています。各ツールは、1 つのタイプのリポジトリ、1 つのタイプのデータ ストリーム、または 1 つのユース ケースのクエリに特化できます。しかし、注意してください。時間や費用を節約し、何かが可能であると証明しようとすると、LLM をフェデレーション ツールとして使用する強い誘惑に駆られるでしょう... やめてください。私たちは以前にもその道を歩んだことがあります。フェデレーション クエリは、受信したクエリをリモート リポジトリが理解できる構文に変換する「ユニバーサル トランスレータ」のように機能し、その後、複数のソースからの結果を何らかの方法で合理化して一貫した応答を生成する必要があります。技術としてのフェデレーションは小規模では 問題なく 機能します が、大規模で、特にデータがマルチモーダルである場合、フェデレーションは大きすぎるギャップを埋めようとします。

エージェントの世界では、エージェントがフェデレーターとなり、ツール (MCP 経由) がさまざまなリソースへの手動で定義された接続となります。専用のツールを使用して接続されていないデータ ソースにアクセスすることは、クエリごとにさまざまなデータ ストリームを動的に統合する強力な新しい方法のように思えるかもしれませんが、ツールを使用して複数のソースに同じ質問をすると、解決するよりも多くの問題が発生する可能性があります。これらのデータ ソースはそれぞれ、その下にある異なるタイプのリポジトリである可能性があり、それぞれが内部のデータを取得、ランク付け、保護するための独自の機能を備えています。もちろん、リポジトリ間のこうした差異、つまり「インピーダンスの不一致」により、処理負荷が増加します。また、矛盾する情報やシグナルが生じる可能性があり、スコアの不一致のように一見無害に見えるものでも、返されたコンテキストの重要性が大きく損なわれ、最終的に生成された応答の関連性に影響する可能性があります。

コンテキストスイッチはコンピュータにとっても難しい

エージェントを任務に送り出す場合、多くの場合、最初の任務はエージェントがアクセスできるすべての関連データを見つけることです。人間の場合と同様に、エージェントが接続する各データ ソースが類似していない分散した応答を返すと、取得したコンテンツから重要なコンテキスト ビットを抽出することに関連する認知負荷 (まったく同じ種類ではありませんが) が発生します。これには時間と計算がかかり、エージェントのロジック チェーンでは少しずつ蓄積されていきます。このことから、 MCPについて議論されているように、ほとんどのエージェント ツールは、API (既知の入力と出力を持つ分離された関数で、さまざまな種類のエージェントのニーズをサポートするように調整された) のように動作する必要があるという結論に至ります。実際、 LLM にはコンテキストのためのコンテキストが必要であることにも気づき始めています。特に、自然言語を構造化構文に翻訳するようなタスクでは、参照できるスキーマがあれば、LLM は意味の点と点を結びつけるのがはるかに上手です (まさに RTFM!)。

7回裏ストレッチ！

ここでは、 LLM がデータの取得とクエリに与えた影響と、チャット ウィンドウがエージェント AI エクスペリエンスへとどのように成熟しているかについて説明しました。これら 2 つのトピックを組み合わせて、最新の検索機能と取得機能を使用してコンテキスト エンジニアリングの結果を改善する方法を見てみましょう。パート III へ進みます: コンテキスト エンジニアリングにおけるハイブリッド検索の威力!

私たちの多くと同じように、私も AI の能力が進化している速さに興奮すると同時に驚いています。大規模言語モデル (LLM) とベクトル検索によって、キーワードで検索する必要がなくなったセマンティック革命が初めて実現しました。その後、LLM は、チャット インターフェースを使用して自然言語によるリクエストを応答に変換し、膨大な知識ベースから簡単に利用できる要約を抽出するなど、データと対話する新しい方法を教えてくれました。私たちは今（すでに！）「エージェント AI」ワークフローの形で自動化された LLM 駆動型ロジックが始まります。このワークフローは、受信したリクエストを意味的に理解し、実行する手順を推論し、利用可能なツールから選択してアクションを反復的に実行し、目標を達成します。

エージェント AI の可能性により、私たちは、主に「プロンプト エンジニアリング」を使用して生成 AI のインタラクションを形成することから、エージェント ツールが LLM が応答を生成する際に考慮する必要がある最も関連性の高い効率的な追加情報を取得できるようにする方法に重点を置くように進化することを余儀なくされています。つまり、「コンテキスト エンジニアリング」が次のフロンティアです。ハイブリッド検索は、関連するコンテキストを明らかにするための最も強力で柔軟な手段であり、Elastic の Search AI プラットフォームは、コンテキストエンジニアリングに役立つデータを活用するまったく新しい方法を実現します。この記事では、LLM が情報検索の世界をどのように変えたかを 2 つの角度から説明し、さらに、LLM がどのように連携してより優れた成果を上げることができるかについて説明します。カバーすべき領域はかなり広いです…

パート1: LLMが検索に与えた影響

まず、LLM が情報にアクセスし取得する方法をどのように変えたかという観点から始めましょう。

私たちの語彙の遺産

私たちは皆、長い間、ある程度制限された語彙検索の世界で（できるだけうまく）生きてきました。検索は、調査をしたり新しいプロジェクトを開始したりするときに最初に使用するツールであり、最近まで、語彙検索エンジンが理解できる方法でクエリを言い表すのは私たち次第でした。語彙検索は、コンテンツが構造化されているか非構造化されているかに関係なく、何らかの形式のクエリ用語をドキュメント コーパスで見つかったキーワードと一致させることに依存します。語彙検索で文書がヒットとして返されるためには、そのキーワードに一致している必要があります (または、概念的なつながりを作るために同義語リストや辞書などの制御された語彙が必要です)。

語彙の 複数一致 クエリの 例

少なくとも検索エンジンには、関連性スコア付きのヒットを返す機能があります。検索エンジンは、インデックスされたデータを効果的にターゲットするための豊富なクエリ構文オプションと、ユーザーのクエリ構文の意図に応じて結果をスコア付けする組み込みの関連性アルゴリズムを提供します。検索エンジンは、関連性ランキング アルゴリズムの数十年にわたる進歩の恩恵を受けており、クエリとの関連性に基づいてスコア付けされ、並べ替えられた結果を提供できる効率的なデータ検索プラットフォームとなっています。データを取得する主な方法として SQL を使用するデータベースやその他のシステムは、ここでは不利です。データベース クエリには関連性の概念がなく、せいぜいアルファベット順または数字順に結果を並べ替えることしかできないからです。良いニュースとしては、これらのキーワードでヒットするものがすべて得られる (リコール) ことですが、それらは必ずしも、検索を求めた理由に対して役立つ順序 (精度) になっているわけではありません。これは重要なポイントです。すぐにわかります…

（意味論的）ドラゴンの登場

キーワード検索の代替として情報のベクトル表現の可能性は、かなり長い間研究されてきました。ベクトルは、キーワードのみのコンテンツ一致モードから抜け出すことができるため、大きな可能性を秘めています。ベクトルは用語と重みの数値表現であるため、トレーニング領域で用語が互いにどのように関連しているかについての言語モデルの理解に基づいて、概念を数学的に近づけることができます。汎用ベクトル検索の長い遅延は、モデルが主に特定のドメインに限定されていたためであり、異なるコンテキスト内で用語が表す可能性のあるさまざまな概念を十分に理解できるほどモデルが大きくなかったのです。

ベクトル検索が実用的になったのは、数年前に大規模言語モデル (LLM) が登場し、トランスフォーマーとアテンションを使用してはるかに大量のデータをトレーニングできるようになったときでした。LLM のサイズと深さにより、ベクトルは最終的に十分なニュアンスを保存できるようになり、実際に意味を捉えることができるようになりました。理解の深さが突然増加したことにより、LLM は、以前はロックされていた多数の自然言語処理 (NLP) 機能を提供できるようになり、おそらく最も影響力があるのは、これまでのシーケンスの内容に基づいて、シーケンス内で最も可能性の高い次の用語を推測する機能です。推論は、生成 AI に人間に近いテキスト生成能力を与えるプロセスです。AI によって生成されたテキストは、LLM がトレーニング データ内で用語がどのように関連しているかを理解した上で生成され、また、リクエストのフレーズを使用して、用語が出現する可能性のあるさまざまなコンテキスト間の曖昧さを解消します。

生成 AI は魔法のようですが、LLM には品質と精度のエラー (一般に幻覚と呼ばれる) を引き起こす制限があります。幻覚は、LLM が真実に基づいた回答をするための情報にアクセスできない (または正しいコンテキストに誘導されない) 場合に発生します。そのため、LLM は役に立とうとして、代わりに自信に満ちたもっともらしい応答をでっち上げで生成します。原因の一部は、LLM が多様な情報の大規模な領域内で言語の使用法を学習する一方で、ある時点でトレーニングを停止する必要があるため、理解に適時性の要素があることです。つまり、モデルはトレーニングを停止した時点までの正確さしか認識できないということです。幻覚を引き起こすもう 1 つの要因は、モデルが非公開データ (パブリック インターネットで利用できないデータ) を認識しないことです。これは、データに特定の用語や命名法が含まれている場合に特に重要です。

ベクターデータベース

LLM は、テキスト埋め込みと呼ばれる手法を使用してコンテンツをモデル空間にベクトル化します。テキスト埋め込みとは、受信したトレーニングに基づいて、モデルの世界観内にコンテンツの意味を埋め込む、つまりマッピングすることを指します。埋め込み用のコンテンツを準備して処理するには、チャンク化とトークン化（およびサブワードトークン化）など、いくつかの手順が必要です。結果は通常、ベクトル空間内でのコンテンツ チャンクの意味に関するモデルの理解を表す密なベクトルのセットになります。チャンキングは、埋め込みを生成するためのモデルの処理制約の制限内にコンテンツを収めることを目的とした不正確なプロセスであり、文や段落のインジケーターなどのセマンティック構造を使用して関連するテキストをチャンクにグループ化しようとします。

チャンク化の必要性により、埋め込まれたドキュメントでは、個々のチャンクが同じドキュメントの他のチャンクと完全に関連付けられていないため、多少の意味的損失が生じる可能性があります。ニューラル ネットワークの本質的な不透明性により、この損失が悪化する可能性があります。LLM はまさに「ブラック ボックス」であり、トレーニング中に作成された用語と概念間の接続は非決定論的であり、人間が解釈することはできません。これにより、説明可能性、再現性、無意識の偏見に関する問題が発生し、信頼性と正確性が失われる可能性があります。それでも、クエリ時に特定のキーワードに縛られずにアイデアを意味的に結び付ける機能は非常に強力です。

セマンティック クエリの 例

ベクター データベースに関して考慮すべきもう 1 つの問題があります。ベクター データベースは検索エンジンではなく、データベースなのです。ベクトル類似性検索を実行すると、クエリ用語がエンコードされ、モデルのベクトル空間内の一連の (埋め込み) 座標が検索されます。これらの座標は、ブルズアイとして使用され、ブルズアイに「最も近い」近傍にあるドキュメントが検索されます。つまり、ドキュメントのランク (または結果の配置) は、クエリの座標からのそのドキュメントの座標の計算された類似距離によって決まります。ランキングはどの方向を優先すべきでしょうか、考えられるコンテキストのうちどれがユーザーの意図に最も近いでしょうか?私がこれを例えると、映画「スターゲイト」のワンシーンになります。そのシーンでは、交差する 6 つの座標点が目的地 (的) を示しますが、ユーザーの主観的な意図を表す出発点の座標である「7 番目のシンボル」を知らないとそこに到達できません。したがって、ベクトルの相対的なランキングが常に拡大し区別のない類似性の領域に基づくのではなく、表現構文と関連性スコアリングを通じてクエリの主観的な意図を考慮することによって、段階的な主観的関連性の円筒に似たものを得ることができます。

LLM の推論機能は、クエリに対して最も可能性の高いコンテキストを識別するのに役立つ可能性がありますが、問題は、支援がなければ、着信クエリの座標はモデルが最初にトレーニングされた方法によってのみ決定できることです。

ある意味、ベクトル類似性は厳密なキーワード一致とは正反対の極限にあると言えます。その強みは用語の不一致の問題を克服する能力にありますが、それはほとんど欠点でもあります。LLM は関連する概念を区別するのではなく、統合する傾向があります。ベクトル類似性により、コンテンツを意味的に一致させる能力は向上しますが、モデルによって十分に明確にされていない正確なキーワードや具体的な詳細を見落とす可能性があるため、精度は保証されません。ベクトル類似性検索はそれ自体強力ですが、ベクトル データベースから取得した結果と他の取得方法の結果を相関させる方法が必要です。

再ランキング手法

ここで、結果セットを統一されたランク順に再スコアリングまたは正規化する、再ランク付けと呼ばれる一般的な手法について説明するのが良いでしょう。再ランク付けが必要になるのは、複数のソースからの結果や、ランク付け/スコアリング メカニズムが異なる (または SQL の場合はまったくメカニズムがない) 検索方法による場合です。また、非セマンティック ソースからの結果をユーザーのクエリに意味的に合わせるために再ランク付けを使用する場合もあります。再ランキングは第2段階の操作であり、何らかの初期検索方法（つまり、その後、検索クエリ (SQL、語彙検索、ベクトル検索) は、異なるスコアリング方法で並べ替えられます。

利用可能なアプローチはいくつかありますが、その中にはLearning-To-Rank (LTR)やReciprocal Rank Fusion (RRF)などがあります。LTR は、検索結果の特徴 (いいね、評価、クリックなど) をキャプチャし、それらを使用して結果にスコアを付けたり、結果をブーストしたり、バイアスをかけたりするのに役立ちます。RRFは、異なるクエリモダリティから返された結果をマージするのに最適です（例：語彙データベース検索とベクトルデータベース検索を 1 つの結果リストにまとめます。Elastic は、線形再ランキング方式を使用してスコアを調整する柔軟性も提供します。

ただし、最も効果的な再ランキング手法の 1 つは、セマンティック再ランキングです。これは、LLM のセマンティック理解を使用して、クエリと結果の両方のベクトル埋め込みを分析し、関連性スコアリング/再スコアリングを適用して最終的な順序を決定します。もちろん、セマンティック再ランク付けには再ランク付けモデルへの接続が必要です 。Elasticsearch は、組み込みモデル ( Elastic Rerank )、 インポートされた サードパーティモデル、または Cohere や Google Vertex AI などの外部でホストされるサービスを活用する 再ランク付け エンドポイントを作成できる推論 API を提供します。次に、リトリーバークエリ抽象化構文を使用して再ランク付けを実行できます。

多段階リトリーバー再ランキング操作の例

素晴らしいですね。さまざまなソースからの結果の再ランキングを実行し、あらゆる種類のコンテンツの意味的理解に近づくことができます。意味的再ランキングは、計算コストと必要な処理時間の両方でコストがかかる可能性があり、そのため、意味的再ランキングは限られた数の結果に対してのみ実行できます。つまり、最初の結果をどのように取得するかが重要になります。

文脈検索方法が重要

主観的な意図は、結果の正確性を判断し、関連性を評価する上で重要な要素です。クエリを実行するユーザーの意図（柔軟な構文または第 2 段階の再ランク付けによって表現される）を考慮する機能がなければ、モデル空間内にすでにエンコードされている既存のコンテキストから選択することしかできません。このコンテキストの欠如に対処する一般的な方法は、検索拡張生成 (RAG)などの手法を使用することです。RAG の仕組みは、文脈的に関連するデータの事前クエリから返された追加の関連用語を含めることで、クエリの座標を効果的にシフトすることです。そのため、追加のコンテキストを提供するエンジンと、検索を実行するための初期方法が、コンテキストの正確さにとってさらに重要になります。

さまざまなコンテキスト取得方法と、それが RAG 操作にどのように役立つか、または悪影響を与えるかを確認しましょう。

• 検索エンジンを使用しないハイブリッド検索では、依然として主観的な関連性が欠けています。RAG を提供するプラットフォームが主に SQL ベースである場合 (ほとんどの「データ レイク」プラットフォームが含まれます)、最初の検索段階で関連性スコアリングが欠如しています。多くのデータ レイク プラットフォームは、独自のハイブリッド検索 (検索ではない) を提供しており、通常は SQL ベースの検索とベクター データベースの結果にセマンティック リランキングや RRF などの再ランキング手法を組み合わせています。単純なソートは主観的なランキング付けには明らかに不十分ですが、第 2 段階のセマンティック リランキング操作の基礎として使用した場合でも、第 1 段階の検索としての SQL では、セマンティック リランキングが「上位 k」のヒットに対してのみ実行される場合に問題が生じます。検索時に結果にスコアを付ける方法がなければ、最善の結果が実際に上位の結果にあるという保証はありません。

• ベクトルの類似性だけでは RAG には不十分です。これは実際には、一連の問題が複合的に絡み合った結果です。つまり、埋め込みの損失、単純なチャンク化方法、類似性の計算方法、そして主観的な意図という重要な要素が欠落しているという問題です。RAG の主な目標の 1 つは、生成 AI のインタラクションを客観的な真実に基づいて確立することです。これにより、幻覚を防ぐと同時に、トレーニング中に認識されなかったプライベート情報を LLM に通知します。RAG を通じて提供される追加のコンテキストを使用して、手近の質問に答えるために最も重要であることがわかっている接続と詳細を考慮するように LLM を制限および指示できます。そのためには、意味論的アプローチと語彙的アプローチの両方を使用する必要があります。

• ファイルベースの grep/regex RAG。エージェント AI の世界では、外部の検索プラットフォームではなく、RAG の grep と regex を介してローカル ファイルにアクセスする、大幅に拡大されたコンテキスト ウィンドウの使用を指摘する声も上がっています。その考え方は、はるかに大きなコンテキスト ウィンドウを利用できることで、LLM が、関連情報を収集するために断片的な情報や複数の検索方法/プラットフォームに頼るのではなく、独自の思考空間内で概念的なつながりを構築できるようになるというものです。理論上は、文書全体があれば文書セグメントよりも完全な画像が得られるというのは本当ですが、これは小さなデータドメインでのみ機能します (または、たとえば、 vibecodingにファイルを提供する場合)。また、その場合でも、最初の検索方法は、キーワードのみが一致するすべての文書をスキャンすることです。

検索は単なる回収以上のもの

検索エンジンは、クエリを可能な限り高速かつ柔軟に実行することを目的として構築されています。内部的には、さまざまな種類のデータをそれらのデータ型に適した方法で保存および取得するための特殊なデータ構造を利用します。Elasticsearchは、非構造化/全文語彙検索（一致、フレーズ、近接、複数一致）、高速キーワード（完全一致）マッチングとフィルタリング、数値範囲、日付、IPアドレスなど、基本的にすべてのタイプのデータの最適化された保存とクエリを提供し、ドキュメント構造（例：ネストされたドキュメントやフラット化されたドキュメントなど)。Elasticsearch は、スパース ベクトル タイプと密ベクトル タイプの両方を保存およびクエリできるネイティブ ベクトル データベースでもあり、ベクトル化されたコンテンツに関連する速度、スケーラビリティ、コストを改善しながら検索の忠実度を維持するための革新的な方法 ( Better Binary Quantization (BBQ)やDiskBBQなど) を継続的に模索しています。Elasticsearch プラットフォームには、組み込みのデータ回復力と高可用性も備わっており、検索可能なスナップショットなどのデータライフサイクル管理機能も含まれています。検索可能なスナップショットを使用すると、アクセス頻度の低いデータや長期保存データをコスト効率の高いオブジェクトストレージに保存しながらも、完全に検索可能です。

ハイブリッド検索はあらゆる面で最高です

ハイブリッド検索(単なるハイブリッド取得ではありません!)従来の語彙検索の長所と、LLM の意味理解およびベクトル類似性検索を組み合わせます。この相乗効果により、検索エンジンが提供する柔軟なクエリ構文オプション（意図主導型の構文オプションと関連性スコアリング、マルチモーダル データ検索、フィルタリング、集約、バイアスなど）を通じて、検索段階で関連性の高い結果をターゲットにすることができます。ES|QLやマルチステージリトリーバーなどの検索構文を使用すると、従来の検索とセマンティック検索、フィルター、複数の再ランキング手法をすべて 1 つのリクエストで柔軟に組み合わせることができます。

ハイブリッド検索の最大の利点の 1 つは、クエリで複数の異なるデータ タイプに同時に特殊な構文を使用できることです。これらのさまざまなクエリ構文は、結果の検索だけでなく、結果のフィルターや集計としても使用できます。たとえば、他の構文と頻繁に組み合わせられる最も一般的なクエリ タイプの 1 つは、地理空間分析です。特定のポイントから指定された距離内の地理座標を持つ結果をクエリしたり、地域別に結果の集計を要求したり、ゾーンへの出入りの動きを追跡してアラートを発する集計を実行したりできます。ハイブリッド検索を使用すると、構文を柔軟に組み合わせて、最も正確な方法で結果をターゲットにし、コンテキストに最も近いコンテンツを取得できます。

休憩

この最初の部分では、ベクトル検索によってデータの取得方法がどのように変化したかを説明し、LLM がデータの操作に使用するクエリ メカニズムにもたらした変化の基礎を説明します。LLM がコンテキストを失うことなく理解できるように、これを複数の部分に分割する必要があったと仮定します... ;-)これがなぜ重要なのかについては、パート II: エージェント AI とコンテキスト エンジニアリングの必要性で詳しく説明し、パート III ではハイブリッド検索について再び説明します。