この最後の投稿では、入力がAIエージェントから来る場合、何が変わるのかを問いかけます。

その答えは、アーキテクチャーは変わらなくとも、重要性は変わるということです。人間が作成したクエリにとって重要であるガバナンスを備えた制御プレーンのすべてのプロパティは、上流の意思決定者が大規模言語モデル（LLM）である場合、さらに重要になります。入力を生成するシステムが本質的に確率的であるため、決定論、監査可能性、競合の解決、制約の強制は、運用上の利便性ではなく、重要な安全策となります。

エージェント型検索の問題

AIを活用した検索の最も一般的なアプローチは単純明快です。LLMにデータベーススキーマを与え、プロンプトにビジネスルールを指定すれば、エージェントがクエリを直接生成します。

eコマースチャットボットの場合、これはElasticsearchのインデックスマッピング、フィールドタイプ、カテゴリー分類、価格設定ロジック、ビジネス制約をエージェントのコンテキストウィンドウに挿入し、LLMに自然言語を有効なElasticsearchクエリDSLに変換するように要求することを意味します。LLMがクエリ作成者となります。

このアプローチはデモでは有効です。本番環境で失敗する理由は4つあります。

コンテキストの肥大化

エンタープライズeコマースインデックスのマッピングは簡単な文書ではありません。フィールド定義、ネストされたオブジェクト、マルチフィールド設定、アナライザー設定は、ビジネスロジックを追加する前に何千ものトークンに実行される可能性があります。マッピングに加えて、エージェントにはカテゴリータクソノミー（エンタープライズeコマースでは数万の値を含む可能性がある）、価格設定ルール、ブランド階層、適格性制約、キャンペーンロジックが必要です。

その結果、コンテキストウィンドウはユーザーの実際の意図よりも、構造的なメタデータによって支配されることになります。これにより、待ち時間が長くなり、トークンのコストが増加し、コンテキストが大きくなるにつれてLLMの指示に従う能力が低下します。これはよく知られた現象で、文脈の劣化と呼ばれることもあります。つまり、プロンプトが長くなるにつれて、モデルが特定の指示に注意を払う能力が弱まるのです。

確率的なハルシネーション

LLMは、トレーニングデータのパターンと提供されたコンテキストに基づいてクエリを生成します。ElasticsearchクエリDSLを生成するように求められた場合、モデルは存在しないフィールド名を誤って生成したり、構文的に無効なクエリ句を構築したり、フィルタータイプを間違ったフィールドタイプに誤って適用したり、構文的には有効であるものの意味的に間違ったクエリを生成して、ユーザーの意図と一致しない結果を返したりする可能性があります。

Google CloudのテキストからSQLへの変換に関するBIRDベンチマークはこのアプローチの限界を示しています。Googleの最先端の単一モデルによる検索結果は70%から80%の精度を達成しましたが、これは生成されたクエリのほぼ4分の1が間違っていたことを意味します。これはSQL用で、ElasticsearchのクエリDSLよりもはるかに標準化されています。複雑なマッピングとビジネス固有のセマンティクスを含む実際の本番環境でのLLMで生成されたElasticsearchクエリのエラー率は、おそらくもっと高いでしょう。

収益に直結するeコマースシステムにとって、クエリエラー率が4回に1回というのは、反復的に解決できるようなチューニングの問題ではなく、このアプローチにおけるアーキテクチャー上の制約です。

セキュリティギャップ

LLMがデータベーススキーマにアクセスし、クエリ作成者として動作する場合、システムは間接的なプロンプトインジェクションに対して脆弱になります。eコマースチャットボットと対話するユーザーは、エージェントを操作して意図しないクエリを生成するように設計されたインプットを作成できます。

これは理論上のリスクではありません。プロンプトインジェクションは、デプロイされたLLMシステムにおいて最も活発に研究されている攻撃面の1つです。根本的な問題は、エージェントがクエリを作成する際に、ユーザーの意図とクエリ実行の間に構造的な境界がないことです。LLMは、ユーザーの要求を解釈すると同時に、データベース操作を構築します。前者への操作は後者に直接影響します。

高カーディナリティスケーリングの失敗

特定のeコマースフィールドは非常に高カーディナリティです。商品タログには、17,000のカテゴリ値、数千のブランド名、そして数百の属性の組み合わせが含まれている可能性があります。標準的なエージェントワークフローでは、LLMがクエリを構築する際に正しい値を選択できるように、これらの値をコンテキストに注入する必要があります。

これは不可能ともいえるトレードオフを生み出します。具体的には、すべての可能な値を注入する（膨大なコンテキストを消費し、パフォーマンスを低下させる）、サブセットを注入する（そして、エージェントがそのサブセット外の値を参照できないことを受け入れる）、または管理されていない検索にフォールバックすることのいずれかです。これはパート1の核心的な問題に直接つながります。LLMが「オレンジ」を検索し、Elasticsearchがオレンジソーダを返すようであれば、検索エクスペリエンスと同様にチャットエクスペリエンスが低下します。ガバナンスがないため、システムは顧客の意図した解決を強制できません。

クエリに基づいて関連値を動的に取得する方法は既知の代替手段ですが、取得自体が関連値を見落とす可能性があるという、非決定論的なステップが追加されます。さらに、これはすべてのクエリに遅延と複雑さを加えることになります。

アーキテクチャー上の代替案：意図と実行の切り離し

パート1から7で説明されているガバナンスを備えた制御プレーンは、根本的に異なるアプローチを提供します。LLMが最後のクエリを作成する代わりに、LLMの役割は、ユーザーの自然言語インプットから検索する意図文字列を抽出するという1つの明確なタスクに限定されます。

ユーザーは「安い茶色の靴を探しています」と言っています。エージェントの役割はElasticsearchクエリを生成することではなく、検索意図（この場合は「安い茶色の靴」のようなもの）を抽出して制御プレーンに渡すことです。コントロールプレーンは、これまでと同様に、意図文字列を保存済みのポリシーと照合し、カスケード変換によって一致するポリシーを構成、競合を決定論的に解決し、ガバナンスを備えたElasticsearchクエリを生成します。

LLMはインデックスマッピングを一切認識せず、フィールドタイプ、カテゴリ分類、価格設定のしきい値などについては一切認識しません。クエリ句は構築されません。これは、メタデータエアギャップと呼ばれるアーキテクチャ境界の自然言語側で動作し、確率的コンポーネント（LLM）と構造化データレイヤー（スキーマ、ポリシー、クエリ構築）との厳密な分離を意味します。

メタデータのエアギャップが提供するもの

• スキーマの盲点。LLMはデータベーススキーマにアクセスできないため、無効なクエリを生成したり、フィールド名を誤認したり、構造情報を公開するように操作されたりすることはありません。このスキーマはエアギャップの決定論的な側面にのみ存在します。

• 最小限の文脈。何千ものマッピングデータ、ビジネスルール、カテゴリータクソノミーの代わりに、LLMのプロンプトにはペルソナとインテント抽出の指示のみが含まれています。これによりトークンコスト、遅延、コンテキストのロットが劇的に削減されます。

• 決定論的な実行。Elasticsearchに届くすべてのクエリは、LLMによって確率的に生成されたものではなく、人間が精査したポリシーテンプレートを使用して制御プレーンによって構築されます。構文の妥当性は保証されています。意味論的正しさは、パート1から6までで説明された同じ政策フレームワークによって強制されます。

• アーキテクチャーによるセキュリティ。迅速な注入は構造的に効果的でなくなります。ユーザーがエージェントを操作して異常な意図文字列を生成しても、その文字列は保存されたポリシーに照合されます。ポリシーが一致しなければ、クエリは生成されません。エージェントはクエリを作成しないため、ユーザーはエージェントにクエリを作成するように指示することはできません。制御プレーンは指示できるため、決定論的です。

各部分がどのように繋がるか

以下のウォークスルーでは、ガバナンスを備えた制御プレーンがエージェント媒介クエリをどのように処理するかを示します。

ステップ1：ユーザーがエージェントに話しかける

ある購入者がECサイトのチャットボットに「ピーナッツが入っていない安いチョコレートを探しています」と言います。

ステップ2：エージェントが意図を抽出する

LLMの役割は意図の抽出であり、クエリ生成ではありません。最小限のプロンプトで製品の意図を識別するように指示された場合、エージェントは検索意図文字列「ピーナッツなしの安いチョコレート」を生成します。

これは軽量な分類タスクです。LLMは、インデックスマッピング、カテゴリ分類、価格設定ルールなどを必要としません。自然言語を理解する必要がありますが、まさにLLMが得意なことです。

ステップ3：制御プレーンがクエリを制御する

「ピーナッツなしの安いチョコレート」という意図文字列は制御プレーンに渡され、そこでポリシーインデックスと照合されます。3つのポリシーが一致します。

• 「安い」ポリシー（「安い」というキーワードを抽出し、商品カテゴリーに基づいて価格フィルターを適用します）。

• 「チョコレート」ポリシー（検索結果をチョコレートのカテゴリーに限定します）。

• 「なし」否定ポリシー（排除ターゲットを抽出し、must_notフィルターを適用します）。

制御プレーンは、パート3とパート4で説明されているものと同じカスケード変換（優先順位付け、フィールドごとの競合解決、消費されたフレーズの追跡）を通じて、これらのポリシーを適用します。「クリスマスキャンペーン」ポリシーも有効な場合、商品ポリシーと正確に同じように構成されます。これはパート3で説明されている通りで、エージェントの関与はガバナンスモデルを全く変更しません。

ステップ4：管理されたクエリが実行される

制御プレーンは、適切なカテゴリーに制限された「チョコレート」の検索、「安い」ポリシーから導出された価格上限、ピーナッツを含む製品の除外フィルター、適用されるアクティブなキャンペーンブーストなどの面で完全にガバナンスされたElasticsearchクエリを生成します。「チョコレート」ポリシーに経済的最適化の重みも含まれている場合（パート7）、それらも適用されます。マージンブーストは3.0倍に設定されています。これは、「チョコレート」が、小売業者が高利益率の商品を宣伝することで利益を得られる検索クエリであるためです。買い物客に購入履歴がある場合（パート6 ）、パーソナライゼーションシグナルがその上に重ねられます。このクエリは構造上は構文的に妥当であり、ポリシー設計上は意味的に正しいです。

ステップ5：結果はエージェントを通じて返送される

検索結果はエージェントに返され、エージェントはそれをユーザーに会話形式で提示します。返答パスにおけるエージェントの役割は、結果の提示、フォローアップの質問への回答、製品の詳細の提供などです。検索自体は、統制され、決定論的で、説明可能でした。

エージェントが得意なこと（そして得意でないこと）

このアーキテクチャーは、LLMの得意な部分を最大限に活用し、LLMの苦手な部分からシステムを保護します。

LLMは自然言語の意図を理解するのに優れています。「ピーナッツが入っていない安いチョコレートを探しています」は、意図の解析、製品参照の特定、否定の認識などを行う自然言語理解タスクです。LLMはこれを確実に処理できます。なぜなら、これは生成問題ではなく分類問題だからです。出力は短い意図文字列であり、複雑な構造化クエリではありません。

LLMは、複雑な制約の下で正確で構造化された出力を提供することに苦労しています。有効なElasticsearchクエリDSLを生成するには、正確なフィールド名、正しい句のネスト、各フィールドに適したフィルタータイプ、そして数千もの例外的なケースにわたるビジネスルールの一貫した適用が必要です。これらはまさに、決定論的システムが自明に保証する特性であり、確率論的システムが信頼性に欠ける形で保証する特性です。

ガバナンスを備えた制御プレーンは、各コンポーネントを適切な場所、つまり、自然言語側のLLM、クエリ構築側の決定論的ポリシーエンジン、そしてそれらの間のアーキテクチャ境界に配置します。

ガバナンスによる爆発半径の制約

これはパート3と同じ洞察を、エージェントのコンテキストに拡張したものです。パート3では、ガバナンスが検索開始前に候補を絞り込むことでセマンティック検索が安全性が高まることが観察されました。管理対象カテゴリー内の500製品に対するセマンティック検索は、50万SKUに対するセマンティック検索とは根本的に異なる提案です。

同じ原理はエージェントが媒介したクエリにも当てはまります。ガバナンスがなければ、「安いチョコレート」を誤って解釈したエージェントは、価格制約、カテゴリーフィルター、除外条件を一切設けずにカタログ全体を検索するクエリを生成してしまう可能性があります。ガバナンスがあれば、エージェントが不完全な意図文字列を生成した場合でも、制御プレーンはクエリを一致するポリシーに限定します。最悪の場合でも実行されるポリシーの数が減るだけで、無制限のクエリが商品カタログにヒットするわけではありません。

ガバナンスは確率的エラーの爆発範囲を狭めます。これは確率的要素がセマンティック検索モデルであれLLMエージェントであれ、すべて当てはまります。

LLMが提案するポリシー：適用範囲の拡大

第2部では、LLMが人間が作成したポリシーと同じ「作成 → テスト → 昇格」のパイプラインに入る新しいポリシーを提案できるという考え方を紹介しました。主体的な文脈においては、これは強力なフィードバックループとなります。

LLMはクエリログを分析し、制御プレーンに一致するポリシーがないパターン（変更されずに取得されるクエリ）を特定し、それらのギャップを埋めるための新しいポリシーを提案することができます。マーチャンダイザーは、各提案を検討し、テストし、期待される行動を生み出すものであれば、それを昇格します。このガバナンスモデルにより、LLMが提案するポリシーが人間の検証なしに本番環境に移行することは決してありません。

時間が経つにつれて、これは好循環を生み出します。制御プレーンのポリシーの対象範囲が拡大し、変更されていない取得を必要とするクエリの割合が減少し、システムの管理が次第に強化され、すべてのポリシーが監査、バージョン管理され、個別に元に戻せるようになります。

より広範なパターン：確率的システムのための決定論的ガードレール

このシリーズで説明されているアーキテクチャーは、確率的な入力ソースとデータ検索システムの間にある決定論的制御プレーンですが、これはeコマース検索に特化したものではありません。同じパターンは、AIエージェントが構造化データとやり取りする必要があるすべての場所に当てはまります。

SQLデータベースにクエリを実行するエージェントも、スキーマインジェクションによるコンテキストの肥大化、誤った列名、プロンプトインジェクションのリスク、高カーディナリティ値の選択といった同様の課題に直面します。Jiraのようなチケットシステム、Salesforceのような顧客関係管理（CRM）システム、またはGitHubのようなコードリポジトリとやり取りするエージェントも同様の問題に直面しています。いずれの場合も、アーキテクチャー上の根本的な問題は同じです。LLMがクエリを作成すべきか、それともLLMが意図を抽出し、それをクエリを作成する決定論的なレイヤーに渡すべきか、ということです。

制御プレーンは、その問いに対して再現性のある答えを提供します。ポリシーはデータであり、意図の抽出はLLMの仕事です。クエリの構築は制御プレーンの役割です。メタデータのエアギャップによって、それらは分離されたままとなります。また、ガバナンスフレームワーク（優先順位付け、競合の解決、段階的な変換、監査可能性）により、ポリシーの数が増加しても、決定論的レイヤーが運用上管理可能であることが保証されます。

まとめ

本シリーズで説明するeコマース検索ガバナンスパターン（データとしてのポリシー、作成 → テスト → 昇格のワークフロー、カスケード変換、フィールドごとの競合解決、パーコレーターベースの逆マッチング、マルチティアフォールバック）は、マーチャンダイザーがポリシーを作成し、購入者がクエリを入力する世界を想定して設計されています。しかし、このアーキテクチャーは、当初のユースケース以上のことを可能にします。

入力ソースが人間の購入者ではなくAIエージェントである場合、ガバナンスを備えた制御プレーンは、確率論的システムと本番環境のデータ格納レイヤーの間の重要な安全レイヤーとなります。これは、エンタープライズシステムが要求する決定論的な保証（構文の妥当性、意味の正しさ、監査可能性、セキュリティ）を提供するものであり、LLM単独では提供できないものです。

決定論的な制御プレーンはAIエージェントの代わりにはなりません。これにより、AIエージェントを安全に展開できるようになります。

ガバナンスを備えたeコマース検索を実践

このシリーズで説明されているガバナンスを備えた制御プレーンアーキテクチャーは、「データとしてのポリシー」パラダイムからパーコレーターベースのルックアップ、パーソナライゼーション、経済的最適化、そしてエージェンティックエアギャップに至るまで、Elastic Services Engineeringによって設計および構築されました。このシリーズで説明されているすべてのパターンは、企業規模の商品カタログに対して構築され、検証済みの実際のシステムから得られたものです。

チームがAIを利用した検索体験を構築し、エージェントが仲介するクエリに対して決定論的なガードレールが必要な場合、またはElasticsearch上で管理された、ビジネスで編集可能な検索アーキテクチャを実装したい場合は、Elastic Professional Servicesが実装を加速できます。Elastic Professional Servicesにお問い合わせください。

議論に参加

検索ガバナンス、検索戦略、またはeコマース検索アーキテクチャについてご質問がありますか？より広範なElasticコミュニティの議論に参加しましょう。

この記事では、アーキテクチャを変更することなく、ガバナンスを備えた制御プレーンを拡張する2つのパーソナライゼーションメカニズムを紹介します。両方のメカニズムは、パート1から5までのガバナンスレイヤーと乗算的に積み重なります。ポリシーは引き続き起動し、制約は引き続き適用され、競合は引き続き解決され、パーソナライゼーションシグナルは同じガバナンスされたクエリに統合されます。これにより、Elasticsearchが返す結果はすでにパーソナライズされていることが保証されます。

最初の仕組みは、個々の購入者が以前に購入した商品を優先的に販売促進するものです。2つ目は、購入者のプロフィールに基づいてコホート固有のポリシーを有効化します。これらは、パーソナライゼーションが検索の横にボルトで固定された別個のシステムでも、検索後の処理として適用されるものでもないことを示しています。それは、ポリシー駆動の制御プレーンの自然な延長です。

パーソナライゼーション技術に関する数学的な詳細については、ElasticsearchでMLの事後処理を行わずに検索をパーソナライズするとElasticsearchにおけるコホート対応ランキングをご覧ください。

購入履歴を使用してリピーターの検索結果を向上させる方法を実際にご覧になりたい場合は、ビデオ説明可能なパーソナライゼーション：購入履歴による検索結果の向上をご覧ください。

個人の購入履歴を活用したブースト

最もシンプルなパーソナライゼーションは、同時に最も効果的な方法の一つでもあります。それは、顧客が以前に商品を購入したことがある場合、その顧客が関連商品を検索した際にその商品を優先的に表示するというものです。特定のブランドのチョコレートチップクッキーを定期的に購入する購入者が「クッキー」と検索した際、そのクッキーが上位に表示されるべきです。これは、モデルが好みを予測したからではなく、直接的な行動証拠が存在するからです。

プログラム概要

ユーザー識別子を含む検索リクエスト（オープンセッションを持つユーザーの場合など）では、制御プレーンはスレッドプールを使用して2つのElasticsearchクエリを並行して実行します。

1. ポリシーインデックスに対するパーコレータークエリ（パート3およびパート4で説明したガバナンスルックアップと同じもの）。

2. user_purchasesインデックスに対する購入履歴クエリは、term(user_id)によって特定のユーザーにフィルタリングされ、そのユーザーの商品タイトルに現在の検索文字列をクエリします。

これらは並行して実行されるため（どちらも他方を待つことはない）、パーソナライゼーションの検索によってガバナンスパイプラインに意味のある遅延が発生することはありません。

購入履歴のクエリは、現在の検索文字列を保存されている商品タイトルと照合する際に、Elasticsearchのテキスト分析（ステミング、トークン化）を使用します。これはつまり、「クッキー」という検索語は、厳密な文字列一致を必要とせず、標準的なテキスト分析によって過去に購入した「ブラウニークッキー」と一致するということです。

ブーストの重み付けの計算

すべての過去の購入が同じように評価されるわけではありません。この重み付けは、購入者がその商品を購入した頻度と、最近購入した頻度という2つの直感的な要素を考慮したものです。先週15回購入された商品は、半年前に1回購入された商品よりもはるかに強いシグナルです。重み付けは、頻度に対して対数スケーリング（単一の頻繁に購入される商品が他のすべてを圧倒しないように）と、最近性に対して指数減衰（古い購入が時間とともに自然に薄れていくように）を使用します。

ブースト式の数学的な詳細については、ElasticsearchでMLの事後処理を行わずに検索をパーソナライズするをご覧ください。

これがクエリとなる方法

購入履歴のブーストは、クエリの最外レイヤーのスコアリングレイヤーとして構成され、パート3およびパート4のガバナンスポリシーフィルターとブースト、さらにビジネスシグナルのブースト（マージンや人気など）（パート7で詳しく説明します）を含みます。これは、ガバナンスポリシーによって削除された商品が、購入履歴のブースト効果によって再び表示されることはないことを意味します。ガバナンスは結果セットを制御し、パーソナライゼーションはその中の順序を調整します。購入履歴のない商品はペナルティを受けません。それらの商品のランキングは維持されますが、他の条件がすべて同じであれば、関連する購入履歴を持つ商品がそれらよりも上位にランク付けされます。

検索のたびにElasticsearchにクエリを実行する必要があるのはなぜですか？

購入履歴は、アプリケーションレイヤーにキャッシュされるのではなく、検索のたびにElasticsearchからクエリされます。これは意図的な設計上の選択です。クエリがElasticsearchのテキスト分析パイプラインを使用して商品タイトルと照合されるため、システムは商品検索自体を強化するステミング、トークン化、言語処理の恩恵を受けます。キャッシュされたメモリ内ルックアップは、その分析を再実装するか、より粗雑なマッチングを受け入れる必要があります。

この注文がなぜ重要なのかを理解するには、以前にオレンジジュースを購入した購入者が、今は「オレンジ」を検索しているとします。購入履歴クエリは、テキスト分析によって「オレンジジュース」という検索語と「オレンジ」を照合し、その商品のブーストを計算します。しかし、ガバナンスレイヤーはすでに「オレンジ」を農産物カテゴリーに限定しており、オレンジジュースは完全に除外しています。オレンジジュースの購入履歴ブーストはクエリに存在しますが、作用する対象となるガバナンスされた結果セットに一致するドキュメントがないため、効果がありません。購入者には、関連性とパーソナライズに基づいてランク付けされた果物のオレンジを目にします。ガバナンスのガードレールが維持されています。

パフォーマンスコストは最小限です。購入履歴インデックスは小さく（ユーザーの購入履歴は通常数十から数百のドキュメントであり、何百万というものではありません）、クエリはパーコレータールックアップと並行して実行されるため、クリティカルパスを延長しません。

ユーザー履歴なしの「spring water」のクエリ例

ログインしていないユーザーや「spring water」を購入したことがないユーザーが検索すると、次のような結果が表示されることがあります。

ユーザーの購入履歴の例

一方、Carolというユーザーのショッピング履歴には、以下の商品が含まれています。

上記の購入履歴で「spring water」を検索する例

Carolが「spring water」を検索すると、過去に購入した内容を反映したパーソナライズされた結果が表示されます。上記の購入履歴を見ると、彼女は「Carbonated Spring Water」（緑色のボトル）を約40回購入しており、最近では2日前に購入しています。彼女が「spring water」を検索した場合、彼女がそれを好んでいることがわかっているので、その商品が上位に表示されるようになります。パーソナライズされていない検索結果では、Rubiconのミネラルウォーターが最初に表示されたことに注目してください。

コホート認識ポリシーの有効化

個別の購入履歴は、確立された行動を持つリピーターにとって有効です。しかし、多くの購入者は新規顧客であったり、匿名であったり、普段とは異なるパターンで商品を探していたりします。こうした購入者にとって、コホートメンバーシップは、購入者の過去の行動ではなく、購入者自身がどのような人物であるかに基づいた、従来とは異なる種類のパーソナライゼーションを提供します。

「チョコレート」を検索するビーガンの購入者には、ビーガンチョコレートが上位に表示されるべきです。「スナック」を探すハラール遵守の購入者には、ハラール認証の選択肢が目立つように表示されるべきです。健康志向の購入者が「ヨーグルト」を探す際には、プロバイオティクスの選択肢が優先的に表示されるべきです。

商品タグではなくポリシーとしてのコホート

商品にはすでに通常の属性があり、dietary_restrictions: ["vegan"]やdietary_restrictions: ["halal"]などのフィールドが含まれます。問題は、購買者のコホートを商品の属性に関連付けるロジックがどこに存在するかという点です。

単純な方法は、アプリケーションレイヤーまたは検索テンプレートでそのマッピングをハードコードすることです。ユーザーがビーガンの場合は、dietary_restrictions: "vegan"にブーストを追加します。しかし、これはパート1で説明されたアプリケーションレイヤーのスパゲッティと同じであり、同じ運用上の摩擦を生み出します。新しいコホートの追加やコホートの意味の変更にはコードの変更が必要です。

ガバナンスを備えた制御プレーンは、代わりにコホートロジックをポリシーエンジンに保持します。コホートポリシーは、購入者のコホートメンバーシップ（例：「ビーガン」）と商品属性（例：dietary_restrictions: “vegan”）の2つを橋渡しします。このポリシーでは、次のような関連性を定義します。ビーガンの購入者が検索したとき、 dietary_restrictionsに「ビーガン」が含まれる商品をブーストします。

コホートロジックはアプリケーションコードではなくポリシーエンジンに存在するため、次のようになります。

• 新しいコホートは新しいポリシーを作成することで追加できます。プロダクトの再インデックスは不要です。

• コホートポリシーは、ルールエンジンを完全に活用します。フィルターの追加、ソフトブーストの適用、同義語の拡張、検索戦略の変更など、ポリシーが実行できるあらゆるアクションを実行できます。

• コホートの動作は、他のすべてのポリシーと同じ管理UIを通じて管理されます。マーチャンダイザーはパート2で説明されている「作成 → テスト → 昇格」ワークフローを通じて、コホートポリシーを作成、テスト、昇格できます。

ビーガンコホートポリシーの例

マーチャンダイザーは、以下の特徴を持つコホートポリシーを作成します。

• コホート：["vegan"]。

• 一致条件：任意のクエリ（または特定の商品カテゴリー）に一致します。

アクション：dietary_restrictions: "vegan"に対してブーストウェイト2でソフトブーストを行います。

コホートのアクティベーションの仕組み

各ポリシードキュメントには cohorts フィールドがあります。ユニバーサルポリシーは、コホートに関係なくすべての購入者に適用されます。このフィールドを空白のままにすることができます。制御プレーンによって内部的に"_all"の値が割り当てられます。コホート固有のポリシーは、["vegan", "kosher", “sweet_tooth”]などのターゲットコホート名を保存します。

検索リクエストにユーザープロファイルが含まれる場合、制御プレーンはパーコレータークエリに対して単純なtermsフィルタを構築します。

この単一のフィルターには、すべてのユニバーサルポリシーに加え、ユーザーのコホート固有のポリシーも含まれます。_all センチネルにより、これはクリーンな包含フィルターになります：ポリシーにコホートの制限がない場合を処理するために must_not または exists のクエリは必要ありません。

その後、パーコレーターは通常どおりポリシーの一致を評価します。唯一の違いは、候補となるポリシーが、この購入者のグループに関連するものに絞り込まれている点です。下流のすべての処理（カスケード変換、フィールドごとの競合解決、消費フレーズの追跡）は、パート3およびパート4で説明した非パーソナライズフローとまったく同じように動作します。

「chocolate」を検索した非ヴィーガン（標準）ユーザーの検索結果

非ビーガンのユーザーがチョコレートを検索しても、ビーガンコホートのブーストは結果に適用されません。検索結果の上位には、以下のような非ビーガンチョコレートがよく表示されていました。

「chocolate」で検索したヴィーガンコホートポリシーの結果

ヴィーガンコホートの購入者が「チョコレート」を検索すると、このポリシーはパーコレーター候補セットに含まれます。一致しており、制御プレーンはヴィーガン認証チョコレートに穏やかなブーストを適用します。このブースト効果は乗算的です。ヴィーガンチョコレートは上位にランクインしますが、上記のフィルターはソフトブーストとして定義されているため、非ヴィーガンチョコレートが完全に除外されるわけではありません。ソフトブーストについては、このシリーズのパート3で詳しく説明しました。

しかし、購入者が明示的に「ハーシーミルクチョコレート」を検索する場合、ヴィーガンブーストは依然として適用されますが、「ハーシーミルクチョコレート」商品のより強いテキスト関連性によって影響を受ける可能性があります。

ビーガンコホートの外にいる購入者が同じクエリを検索しても、「ビーガンコホート」ポリシーは表示されません。それは候補セットに含まれていないためです。ガバナンスレイヤーは同一であり、異なるのは有効なポリシーセットのみです。

購入履歴のあるコホート

豊富な購入履歴を持つヴィーガンの購入者は、ビーガンコホート特有のポリシーの有効化や購入履歴の向上といった恩恵を受けられます。新規の購入者や匿名の購入者の場合、行動データを必要とせずに、暗黙のコホートメンバーシップだけで意味のあるパーソナライゼーションを提供します（例えば、匿名のユーザーはビーガン商品しか検索することがないので、ビーガンコホートのメンバーとして分類します）。アカウント作成時にハラール遵守として自己申告した購入者については、最初の検索ですぐにハラールに合わせた結果が表示されます。

パーソナライズレイヤーの構成方法

function_score層の入れ子順序が重要です。最も内側から最も外側へ：

1. ベースクエリ：キーワードまたは名前付きクエリ（fulltext_match、title_phrase_match）とのセマンティック一致。

2. ガバナンスポリシーレイヤー：ハードフィルターはbool.filter節、ソフトブーストはfunction_score関数として定義されます（パート3と4）。

3. ビジネスシグナルの強化：マージンと人気度の向上（パート7で詳しく説明します）。

4. 購入履歴のブースト：一番外側の function_score レイヤー。

この順序付けにより、ガバナンスが結果セット（表示されるもの）を管理し、ビジネスシグナルがそのセット内でランキングを調整し（小売業者の視点で最初に表示されるもの）、購買履歴が個人の行動に基づいてさらにランキングを調整します（購入者の視点で最初に表示されるもの）。各レイヤーは前のレイヤーを乗法的に重ね合わせるため、効果は衝突するのではなく、相乗的に増幅されます。レイヤー

これが運用上で意味すること

パーソナライゼーションを通じたガバナンスを備えた制御プレーンは、パート1とパート2で説明されているすべての運用プロパティを保持します。

• デプロイの変更なし。コホートポリシーは管理者UIを通じて作成、テスト、推進されます。新しい食事コホートの追加やブーストの重みの調整には、コードの変更やエンジニアリングの関与は不要です。

• 監査可能性。すべてのコホートポリシーは、離散的でバージョン管理されたドキュメントです。マーチャンダイザーが「なぜこのユーザーに対してビーガン商品がより高いランキングを示しているのか？」と尋ねた場合、その答えは特定のポリシーとその特定の優先順位にあり、それはデバッグパネルで、そのクエリに対して起動した他のすべてのポリシーと共に表示されます。

• 競合解決。コホートポリシーは、第3部で説明したフィールドごとの競合解決と同じ処理に参加します。コホートポリシーのカテゴリブーストがキャンペーンポリシーのカテゴリーオーバーライドと競合する場合、競合は同じ優先順位と戦略のフレームワークによって決定論的に解決され、特別な処理は必要ありません。

• 測定可能性。コホートポリシーは個別に設定可能で、それぞれ独立しているため、システム内の他のポリシーと同様に、コンバージョン率、クリック率、カート追加率への影響を個別に測定できます。

このシリーズの次回作

次の投稿では、ガバナンスを備えた制御プレーンの別の側面を探ります。クエリごとにマージンと人気ブーストをポリシーを通じて調整し、経済的最適化を静的な設定ではなくガバナンス決定へと変える方法です。

パート7：クエリ制御型経済最適化：クエリごとのマージンと人気度向上を見る

ガバナンスを備えたeコマース検索を実践

この投稿で説明されているパーソナライゼーションパターン（個別の購入履歴ブーストとコホート対応ポリシーのアクティベーション）は、Elastic Services Engineeringによって、当社の繰り返し利用可能なeコマース検索アクセラレーターの一部として設計および構築されました。これらのメカニズムはどちらも、本シリーズ全体を通して説明してきたガバナンスを備えた制御プレーンアーキテクチャと統合されています。Elastic Professional Servicesにお問い合わせください。

議論に参加

検索ガバナンス、検索戦略、またはeコマース検索アーキテクチャについてご質問がありますか？より広範なElasticコミュニティの議論に参加しましょう。

アーキテクチャーから実装へ

パート3では、制御プレーンアーキテクチャについて説明しました。具体的には、ルックアップのプリミティブとしての逆マッチング、マッチングとアクションを分離するポリシー文書、そして複数のポリシーを単一の実行計画に構成するカスケード変換についてです。この投稿では、ポリシールックアップを駆動するElasticsearchの機能であるパーコレータークエリについて詳しく説明します。

パーコレーターは、制御プレーンが必要とするまさにその方法で探索の方向を反転させるため、ガバナンスに非常に適しています。この投稿では、パーコレーターの機能とその重要性の明確な説明から始め、インデックス設計、ポリシーストレージ、クエリ時評価、マルチポリシー構成に至るまでの実施手順を詳しくご紹介します。

通常の検索の仕組み

eコマースシステムでは、 title 、 category 、 priceなどのフィールドを含む数十万または数百万の商品ドキュメントが存在する場合があります。ユーザーが一致するドキュメントを検索すると、Elasticsearchに対して、ユーザーの検索文字列をこれらの商品ドキュメントに保存されている1つ以上のフィールドと比較するように指示することになります。Elasticsearchのデフォルトアナライザーである標準アナライザーは、テキストを小文字に変換し、トークンに分割します。「oranges」で検索すると「Oranges」が小文字で表示され、検索結果に一致します。語幹解析を含む言語認識アナライザーを使えば、両方の形が同じ語幹に還元されるため「orange」にも合致します。例えば、次の一致クエリは、 “title”フィールドに「orange」または「oranges」を含むドキュメントを返します。

そのため、上記のクエリでは、Elasticsearchはtitleフィールドが「oranges」にマッチする商品ドキュメントを返します。これには「Orange Fruit Spread」、「Orange Juice」、「Juicy oranges」、「Orange Marmalade」などの結果が含まれる可能性があります。覚えておくべき重要な点は、Elasticsearchは一般的に検索文字列をドキュメントと比較し、検索文字列に一致するドキュメントを返すために使用されるということです。

ガバナンスの問題：商品を検索する前に関連するポリシーを見つけること

パート1～3で確立されたように、ガバナンスを備えた検索システムは、ユーザーの検索文字列を直接商品カタログに送信しません。まず、その検索文字列に適用されるポリシーがあるかどうかを確認します。

マーチャンダイザーは、誰かが「オレンジ」を検索したときに、結果をオレンジのカテゴリーに制限し、オレンジジュース、オレンジマーマレード、オレンジソーダを除外することを決定しました。そのビジネス上の意思決定はポリシーとして格納されます。ユーザーが「オレンジ」と入力すると、制御プレーンはそのポリシーを見つけ、その指示を読み取り、それに応じて商品カタログに対する検索を修正する必要があります。そのためには、制御プレーンは、どの保存済みポリシーがこの検索文字列に関連するかを判断する必要があります。

企業環境における導入事例では、このようなポリシーが数百、あるいは数千にも及ぶ可能性があります。それらをif/elseロジックで1つずつチェックすることは、パート2で説明されているアプリケーションレイヤーのアンチパターンです。必要なのは、すべてのポリシーをインデックスに格納し、与えられた検索文字列に一致するものを即座に見つける方法です。そこでパーコレーターが役立ちます。

方向転換：パーコレーター

以前にも述べたように、通常の検索では、Elasticsearchは検索文字列をドキュメントと比較し、その検索文字列を含むドキュメントを返すためによく使用されます。

パーコレーターはこれを反転させます。パーコレーターを使用すると、各ドキュメントがクエリパターンを格納するインデックスがあり、その入力された検索文字列がこれらの格納されたクエリと比較され、どの格納されたクエリパターンがトリガーされたかを判断します。

ガバナンスにおいて、「保存されたクエリパターン」はポリシーとなります。各ポリシーには、一致させる検索文字列の種類を示すパターンが含まれています。例えば、検索文字列は「oranges」と完全に一致するでしょうか、それとも検索文字列に「olive oil」が含まれているでしょうか。入力される文字列はユーザーの検索テキストであり、クエリ実行時に到着し、保存されているすべてのポリシーパターンと照合する必要があります。これはPRISMの関連動画4:09で取り上げられています。

段階的に確認：検索で「oranges」がポリシーを見つける方法

ポリシー

あるマーチャンダイザーが、ユーザーが他の言葉を含めずに正確に「オレンジ」を検索した場合に一致するポリシーを作成しました。パーコレーターが一致すると、ドキュメントの残りの部分には、制御プレーンがプロダクトクエリの構築に使用するルールが含まれます。この例では、ルールの1つは結果を「果物」カテゴリーに制限（フィルター）することです。

percolatorフィールドには、このポリシーがいつ発動するべきかを定義するパターンが含まれています。この場合、それはフレーズ"START oranges END"に一致します。rule_typeフィールドとrule_argsフィールドは、ポリシーが発動したときに実行する内容を定義します。STARTトークンとENDトークンは境界マーカーです。これについては後ほど説明します。

PRISM StudioのUIでポリシーがどのように作成されているかは、関連PRISM動画の2:52で確認できます。

ユーザーが検索

購入者が検索バーに「oranges」と入力します。

制御プレーンがポリシーの一致をチェック

商品カタログを検索する前に、制御プレーンはユーザーの検索文字列をインターセプトし、境界マーカーでラップして、それをパーコレーターに送信します。

文字列 "START oranges END" は、保存されているすべてのポリシーパターンと照合されます。内部的には、Elasticsearchは保存されているポリシーパターンをこの文字列に対して実行し、一致するものを返します。それがパーコレーターです。ユーザーの検索文字列は、保存されているすべてのポリシーパターンと照合され、一致するものが返されました。if/elseチェーンや逐次評価はありません。インデックスがマッチングを処理します。

制御プレーンはポリシーを適用

制御プレーンはマッチしたポリシーのアクションを読み取ります。上記のポリシーは、制御プレーンに対し、検索結果を「果物」カテゴリに限定するよう指示するものです。コントロールプレーンは、商品カタログに対して最終的なElasticsearchクエリを以下のように構築します：

ユーザーは「oranges」を検索しました。商品カタログは、果物カテゴリに限定された「oranges」のクエリを受け取ります。この制約のため、オレンジジュース、オレンジマーマレード、オレンジソーダは除外されます。

「オレンジマーマレード」がオレンジポリシーを発動しない理由

別のユーザーが「orange marmalade」を検索すると仮定します。制御プレーンは文字列をラップし、パーコレーションします： "START orange marmalade END" 。オレンジポリシーのパターンは match_phrase: "START oranges END"です。オレンジポリシーは一致しないため、ポリシーは適用されず、結果は「果物」カテゴリーに限定されません。

これがSTARTおよびEND境界マーカーの目的です。これがないと、「oranges」という単語にマッチするポリシーが、誤って「orange marmalade」のようなクエリにマッチしてしまう可能性があります。ユーザーの検索文字列をSTARTとENDで囲み、それらのマーカーをポリシーのパターンに含めることで、ポリシーが「oranges」が完全な検索文字列であり、他の単語を含まない場合にのみ発動することを保証します。これは購入者とマーチャンダイザーの意図の両方に一致しています。

第二のポリシー：語幹解析されたフィールド上の「olive oil」

すべてのポリシーが正確な文字列一致を必要とするわけではありません。「olive oil」ポリシーは語幹解析されたフィールドで一致するため、単語形式のわずかな変化に関係なく発動します。

このポリシーのパターンはqueryではなくquery.stemmedに一致します。ユーザーの検索文字列が到着すると、それはqueryフィールド（正確なテキスト）とquery.stemmedフィールド（語幹解析アナライザーで分析され、単語がその語幹に削減されるため、「olives」と「olive」は同じ語幹に削減され、「oils」と「oil」も同じ語幹に削減される）の両方に格納されます。ポリシーのパターンは、文字列の語幹解析されたバージョンに対してチェックされるため、単語形式のわずかな変化に関係なくトリガーされます。

STARTとEND境界マーカーは、語幹解析されたフィールドでも機能するため、このポリシーは「olive oil」が検索文字列全体である場合にのみ発動し、より長い文字列の一部として出現する場合は発動しません。

この記事の残りの部分では、本番環境で使用できるようにするための実装の詳細について説明します。具体的には、2つのマッチングモードをサポートするインデックスマッピング、ハイライトがフレーズの削除と消費フレーズの追跡をどのように促進するか、そして複数の相反するポリシーがどのように単一の実行プランに統合されるかなどです。

ポリシーインデックスのマッピング

ポリシーインデックスには、格納するクエリパターンを保持するパーコレーターフィールドと、パーコレーターが一致させる対象となる入力検索文字列の構造を反映するテキストフィールドが必要です。以下のマッピングは明確さのために簡略化されています。本番環境への導入はより複雑で、境界マーカーの処理、変数パターンマッチング（例えば、「4ドル未満」に通貨値が含まれていることを認識するなど）、その他の種類の分析を行うために、カスタムアナライザーが使用されます。

インデックスにはpoliciesという名前が付けられています。これは、各ドキュメントがパート2で定義されているように完全な管理ポリシーを表しているためです。これには、一致基準、アクション、優先度、メタデータが含まれます。rule_typeおよびrule_argsフィールドにはポリシーのアクションコンポーネントが含まれており、これらには制御プレーンが商品カタログに対してクエリを実行するために使用する指示が含まれています。

queryフィールドとは、パーコレーターがマッチングする文字列のことです。このバージョンには、完全一致バージョンと語幹解析されたバージョンの2つのバリエーションがあります。ユーザーの検索文字列が到着すると、そのフィールドに一時的なメモリインデックスの中に入力されます。queryに一致するポリシーは完全一致する文字列を参照し、 query.stemmedに一致するポリシーは語幹解析されたバージョンを参照します。

ハイライト、フィルタリング、ソート機能を備えたパーコレーター

上記の簡単な例では、最小限のパーコレーター要求を示しました。実際には、制御プレーンはハイライト表示を追加し、無効化されたポリシーをフィルタリングし、優先度順に並べ替えます。

ハイライト構成では、フィールドキーとして"query"を使用し、matched_fields内の"query.stemmed"を使用します。これは、Elasticsearchの統合ハイライターに、親フィールドqueryハイライトを返すだけでなく、ハイライトするトークンを決定する際にquery.stemmedサブフィールドの一致も考慮するように指示します。これにより、語幹解析されたフィールドで一致するポリシーでも元のテキスト上に正確なハイライト範囲を生成できるようになり、これは制御プレーンがフレーズの削除や消費フレーズの追跡を行うために必要となります。

enabled: trueフィルターは無効なポリシーをスキップすることを保証します。優先度のsortは、優先度の高いポリシーが最初に返されることを保証し、制御プレーンがカスケード変換のために正しい順序でそれらを処理できるようにします。highlightフィールドは最も重要な追加要素です。これにより、ユーザーの検索文字列のどの単語が各マッチをトリガーしたかを正確に確認できます。

「olive oil」の検索結果は、以下のようなものになる場合があります。

ハイライトが重要な理由

応答のハイライト部分 "<em>START olive oil END</em>" に注目してください。Elasticsearchは、ユーザーの検索文字列のどの単語がポリシーを一致させたかを正確に教えてくれます。これは表面的なものではありません。ハイライトメタデータは、以下の2つの重要な下流の動作を左右します。

フレーズの削除。一部のポリシーでは、商品カタログクエリを作成する前に、検索文字列から一致したテキストを削除する必要があります。例えば、「安い」という条件に一致するポリシーでは、その単語が削除され、代わりに価格フィルターに変換されます。ハイライト表示によって、検索文字列のどの部分がポリシーに一致したかが正確に識別されるため、システムは削除すべき箇所を把握できます。

消費されたフレーズの追跡。パート3で説明したように、複数のポリシーが同じ検索文字列に一致した場合、優先度の高いポリシーが優先度の低いポリシーでも一致した単語を削除することがあります。各ポリシーのハイライトを現在の（進化する）検索文字列と比較することで、システムはフレーズが消費されたことを検出し、優先度の低いポリシーをスキップすることができます。これにより、二重処理が防止され、決定論的な動作が保証されます。

ハイライト表示の仕組みについてはこちらの記事で詳しく解説しています。

パーコレーターから実行計画へ

パーコレーターは一致するポリシーのセットを返します。しかし、パート3で説明したように、ルックアップは全体の一部に過ぎません。その後、それらの一致を一貫した実行計画にまとめる必要があります。具体的なクエリは次のようになります。

例：クリスマスキャンペーン中の「安いチョコレート」

システムには、「安いチョコレート」ポリシー（優先度210）と「クリスマスチョコレート」ポリシー（優先度300）という2つのアクティブなポリシーがあるとします。どちらもパート3で詳しく説明されています。

ステップ1：抽出する。ユーザーは「cheap chocolate（安いチョコレート）」を検索します。制御プレーンは検索文字列を "START cheap chocolate END" として巻き込み、パーコレーターに送ります。2つのポリシーが一致します。「安いチョコレート」ポリシーのパターンは「安いチョコレート」というフレーズに一致し、「クリスマスチョコレート」ポリシーのパターンは語幹解析されたフィールドを介して「チョコレート」に一致します。

ステップ2：優先順位で並べ替える。パーコレーターは両方のポリシーを優先順に並べて返します。「クリスマスチョコレート」ポリシー（300）が最初に処理され、次に「安いチョコレート」ポリシー（210）が処理されます。

ステップ3：カスケード変換を適用する。これはパート3のinitial state → [Policy A] → state' → [Policy B] → state'' → execution planモデルです。

「クリスマスチョコレート」ポリシー（優先順位300）が最初に適用されます。

• 「クリスマスの食べ物と飲み物」、「クリスマスのお菓子」というカテゴリーのハードフィルターを追加します。

• 「7ドル未満」価格フィルターを追加します。

• カテゴリーのソフトブースト「アドベントカレンダー」（3倍）を追加します。

「安いチョコレート」ポリシー（優先度210）は、修正された状態に対して次に適用されます。

• カテゴリーのハードフィルター「チョコレート」、「ミルクチョコレート」を追加しようとしましたが、クリスマスのポリシーですでにこのフィールドにon_conflict: override設定されているため、「安いチョコレート」カテゴリーは削除されます。

• 「2ドル」の価格フィルターを追加しようとしましたが、クリスマスのポリシー設定は価格に対してon_conflict: restrictに設定されており、2ドルは 7ドルよりも制限が厳しいので、2ドルが優先されます。

• 検索文字列から「cheap」を削除します。

ステップ4：Elasticsearchクエリを作成する。制御プレーンは、商品カタログに対する単一のElasticsearchクエリとして実行計画を組み立てます。

元の検索文字列は「cheap chocolate」でした。商品カタログに到達するクエリは、ガバナンスを備え、意図を考慮した検索計画です。「安い」という単語は消費され、価格制約に変換され、結果はクリスマスシーズンのカテゴリーに限定され、アドベントカレンダー商品はランキングが上がり、価格上限は優先度の低いポリシーによるより厳しい値を反映しています。すべての変換は決定論的であり、追跡可能であり、説明可能です。

これらの乗数が基本のBM25スコアとどのように相互作用するかについての概要については、関連PRISM動画の8:45をご覧ください。ここでは、乗算ブーストについて簡単に説明しています。

これがスケールする理由

パーコレーターはこのユースケースにおいて効率的です。なぜなら、非対称性が存在するからです。企業向けeコマースシステムには数百万の商品が存在しても、ポリシーは数百から数千件しかないかもしれません。パーコレーターは、入力された検索文字列を、保存されているポリシーパターンのセットと照合するだけであり、商品カタログ全体をスキャンするわけではありません。コストはポリシーの数に比例し、Elasticsearchは内部最適化（格納されたクエリパターンから用語をインデキシングし、ブールロジックを短絡させる）を適用してマッチングを高速化します。

新しいポリシーの追加は、単に新しいドキュメントをインデキシングすることです。いずれかを無効にすると、フィールドが更新されます。コードの変更も、デプロイも、再起動も一切不要です。

検索からガバナンスを備えた検索へ

パーコレーターは、パート3の制御プレーンアーキテクチャを大規模なスケールで実用的にする高速逆マッチングプリミティブを提供します。ポリシーとは、保存およびインデックス化され、入力された検索文字列と効率的に照合されるデータのことです。制御プレーンは、パート3で説明されているカスケード変換とフィールドごとの競合解決を通じて、マッチングポリシーをガバナンスに基づく実行計画へと統合します。そして、検索エンジンは商品カタログに対してガバナンスに基づく実行計画を実行します。

結果として、マーチャンダイザーがアプリケーションコードに触れることなく新しいポリシーを作成し、代表的なクエリに対してテストし、本番環境に導入し、即座に効果を確認できるシステムが実現します。パーコレーターはポリシーの検索を高速化し、制御プレーンはポリシーの構成を決定論的にし、ガバナンスを備えたワークフローはプロセス全体を安全にします。

このシリーズの次回作

このシリーズの次の投稿では、ガバナンス制御プレーンを新たな領域へと拡張します。多層検索アーキテクチャを紹介し、安定したページネーションとファセットを維持しながら、厳密な検索、緩やかな検索、セマンティックな検索をどのように連携させるかを説明します。

ガバナンスを備えたeコマース検索を実践

本稿で説明するパーコレーターベースの制御プレーンは、インデックスマッピングや境界マーカーから、ハイライト駆動型のフレーズ追跡、カスケード型ポリシー構成に至るまで、Elastic Services Engineeringが当社の再利用可能なeコマース検索アクセラレーターの一部として構築したものです。ここに示されているすべてのクエリ例とポリシー構造は、企業規模の商品カタログに対し、検証済みの実稼働しているシステムから得られたものです。

Elasticsearch上にガバナンスを備えたポリシー駆動型の制御プレーンを実装したい場合、 Elastic Services を利用すれば、より迅速に実現できます。Elastic Professional Servicesにお問い合わせください。

議論に参加

検索ガバナンス、検索戦略、またはeコマース検索アーキテクチャについてご質問がありますか？より広範なElasticコミュニティの議論に参加しましょう。

クエリの解釈が難しい理由

ポリシーをコードとして保存する（アプリケーション層のif/elseブロックとして保存する）と、クエリ時に効率的にポリシーを取得するためのインデックスが一切ない、何万行にも及ぶ脆弱なロジックが生成されます。反復処理が遅く（単一のクエリの動作変更に6週間の導入サイクルが必要になる場合も）、責任の所在が不明確（結果が変更された理由は？）、そしてビジネスユーザーはエンジニアリングの関与なしに検索動作を変更できません。これは次の画像の左側に表示されています。

ポリシーをデータとしてElasticsearchインデックスに格納する方法は上の画像の右側に示されています。このアプローチにより、ハードコードされたクエリ解決ロジックに伴う問題をすべて解消できます。ただし、これを機能させるには、どのポリシーがユーザーのクエリに一致するかを素早く判断し、競合をどのように解決するかを決定する方法が必要です。ここで、ガバナンスを備えた制御プレーンが役立ちます。

制御プレーンのパターン

ガバナンスを備えた制御プレーンは、生のユーザークエリとElasticsearchの検索の間に位置します。ユーザーテキストを入力として受け取り、出力にフィルター、ブースト、検索ルーティングの決定を含む実行計画です。

制御プレーンパイプラインは以下で構成されます:

1. ユーザークエリ：ユーザーは探しているものの文字列を入力します。例えば「オレンジ」や「おじいちゃんへのプレゼント」など。

2. ポリシー検索：ユーザーのクエリをポリシーインデックスと照合します。

3. 一致するポリシーを返す：ユーザークエリに一致するポリシーがポリシーインデックスから返されます。

4. ポリシーの適用：制御プレーンは、返されたこれらのポリシーを分析し、一致するポリシーを、フィルター、ブースト、オーバーライド、ガードレールを含む単一の一貫性のある実行計画に構成し、適切な検索方法（語彙的、意味的、ハイブリッドなど）を適用します。

5. 実行：変更された意図認識型のElasticsearchクエリがアプリケーションに渡され、商品カタログインデックスに対して実行されます。

6. 説明（オプション）：ビジネスと意図に沿った結果を提供するクエリの作成に加えて、制御プレーンは、どのポリシーがトリガーされ、それらがどのように組み合わせられたかを示すオプションの説明ペイロードを提供します。

ユーザーの検索文字列にどのポリシーを適用すべきかを判断するには高速な逆マッチングプリミティブが必要であり、私たちはそれをpercolator（パーコレーター）クエリで解決します。関連するポリシーを取得した後、一致する複数のポリシーを統合された実行計画に組み合わせるには、判断フレームワークが必要です。これには、優先順位、競合戦略、使用済みフレーズの追跡、ポリシーを個別にではなく順番に適用するカスケード変換が含まれます。さらに、最も適切な検索技術を選択する必要があります（例えば、「オレンジ」にはBM25 、一方「おじいちゃんへのプレゼント」にはセマンティック検索など）。

ポリシー検索：商品検索前にクエリを確認

購入者がクエリを入力しても、ガバナンス付きの制御プレーンを備えた検索システムは、そのクエリを直接商品カタログに対して実行することはありません。まず、クエリは保存されたポリシーのセットと照合され、クエリの意図やビジネスの優先順位を反映するように修正されます。

ポリシー構造

各ポリシーは、以下の2つの事項を定義するシンプルな文書です。

• 一致基準：このポリシーをトリガーするクエリテキスト。正確なフレーズ、単語、パターン、またはそれらの組み合わせです。

• アクション：ポリシーが発動した際に何をすべきか。これは、カテゴリーフィルターの適用、商品の除外、価格制約の抽出、または検索戦略の変更などが考えられます。

システムは、一致するすべてのポリシーを検出し、それらを実行計画にまとめ、その後で初めて商品検索を実行します。これらのポリシーを総合的に見ると、まるであなたが探しているものを理解し、適切な通路まで案内してくれる知識豊富な店員のような役割を果たします。

ポリシーパターン

本シリーズの最初の記事では、実際に運用されているポリシーの例を紹介しました。「オレンジ」を農産物カテゴリーに限定すること、「ピーナッツなし」を除外対象として扱うこと、「おじいちゃんへのプレゼント」をセマンティック検索にルーティングすることなどです。重要なアーキテクチャー上のポイントは、いずれの場合も、商品検索を開始する前に、クエリが保存されているポリシーと照合されるという点です。これらのポリシーは、適用する制約、変更するテキスト、使用する検索戦略を決定します。商品カタログに対するクエリは、ポリシーが適用され、新たに書き換えられたクエリが作成された後に行われます。

これが高速である理由

企業向けeコマースシステムには数百万の商品が存在しても、ポリシーは数百から数千件しかないかもしれません。ポリシー検索のステップでは、商品カタログ全体ではなく、厳選された小規模なインデックスに対して検索を行うため、高速です。また、ポリシーは独自のインデックスにデータとして保存されるため、マーチャンダイザーが新しいポリシーを追加する際にアプリケーションコードを変更する必要はなく、商品検索を最適化するエンジニアもポリシーインデックスを変更する必要がありません。この2つの懸念は独立して発展していきます。

上記の例では、概念的に何が起こるかを説明しています。内部的には、ポリシー検索はElasticsearchのパーコレータークエリタイプを使用して実装されています。これは、受信テキストを保存済みのクエリセットと照合するという、この種のパターンに特化して設計されたものです。パート4では、このシリーズのパーコレーター実装について、インデックスマッピング、境界マーカー、ハイライトベースのフレーズ追跡を含めてハンズオン形式で詳しく解説しています。パート4でルックアップメカニズムについて詳しく解説したので、ここではポリシードキュメントに実際に何が含まれているのか、そして制御プレーンが複数のポリシーをどのように組み合わせて単一の実行計画を作成するのかを見ていきましょう。

ポリシーの例

ポリシーが概念的にどのような役割を果たすのかを見てきたところで、次に政策が実際にどのような内容を含んでいるのかを見ていきましょう。以下の2つのポリシーは、意図的に対立するように設計されており、次のセクションで説明する競合解決システムの実例となります。

安いチョコレート

以下に示すポリシーは、ユーザーが「安いチョコレート」というフレーズを含む検索を送信したかどうかを検出します。その場合、結果は「チョコレート」と「ミルクチョコレート」のカテゴリーに限定されます。このポリシーには2ドルの価格フィルターも適用されます。また、このポリシーの優先度は210であることにも注意してください。これについては、競合解決についてより詳しく説明する際に改めて触れます。

ここに示されているフィルターモードと競合戦略の設定（hard_filter、soft_boost、restrict、override）については、以下の競合解決セクションで詳しく説明します。

上記のポリシーが有効になっている場合、「安いチョコレート」を検索すると、2ドルの価格フィルターが適用され、検索結果は「チョコレート」と「ミルクチョコレート」のカテゴリーに制限されます。結果の例を以下に示します。

クリスマスチョコレート

以下に示すポリシーは、クリスマスの時期に適用すると想定できるポリシーの例です。この例では、検索結果を「クリスマスの食べ物と飲み物」と「クリスマスのお菓子」に限定し、「アドベントカレンダー」カテゴリーに含まれる商品をブーストし、手頃な価格の季節商品にフォーカスするために7ドル未満の価格フィルターを適用しています。さらに、このポリシーの優先度は300であることにも注意してください。これについては、競合解決をさらに詳しく説明する際に改めて取り上げます。

上記のポリシーが有効で、競合するポリシーがない場合、「チョコレート」の検索では7ドルの価格フィルターが適用され、「クリスマスの食べ物と飲み物」および「クリスマスのお菓子」のカテゴリに結果が限定され、「アドベントカレンダー」としてタグ付けされた商品の表示がブーストされます。結果の例を以下に示します。

一致するポリシーの組み合わせ

上記のポリシー検索は話の半分に過ぎません。もう半分は、複数のポリシーが同じクエリに一致した場合に起こることです。

複雑なシステム展開においては、単一のクエリによって複数のポリシーが同時に実行されることが一般的です。「安いチョコレート」は、上記で示した2つのポリシーの両方に合致します。それぞれのポリシーは単独で見れば正しいものです。課題は、それらを矛盾なく、二重計算せずに、そして一つのポリシーが他のポリシーの作業を静かに無効にすることなく、単一の一貫した実行計画にまとめることです。

これは検索の問題ではなく、判断の問題です。システムは以下を決定しなければなりません。

• 適用順序：否定ポリシーにより「ピーナッツなし」がクエリから削除された場合、価格ポリシーは元のテキストと変更後のテキストのどちらを参照するか？

• フィルターの競合：2つのポリシーで異なる価格上限が設定されている場合、どちらを優先するか？敗者はひっそりと切り捨てられるのか、それとも穏やかに順位を落とし、ソフトブーストにつなげるのか？

• フレーズの所有権：2つのポリシーが同じ単語に一致し、最初のポリシーがすでにその単語を消費している場合、2番目のポリシーは実行されるべきか？

単純な実装（一致するポリシーをすべて個別に適用し、結果をマージ）では、ポリシー同士が相互作用するとすぐに問題が発生します。アーキテクチャーにはポリシーの構成方法に関する明示的なモデルが必要です。次の2つのセクションでは、そのモデルについて説明します。すなわち、優先順位付けと競合解決の枠組み、そしてポリシー間の相互作用を決定論的にするカスケード変換モデルです。

重要な点は、ポリシーの適用は独立した一連の操作ではなく、カスケード的な変換であるということです。各ポリシーは、すべての上位ポリシーによって生成された書き換え状態を受け取り、それをさらに変換します。

初期状態 → ［ポリシーA］ → 状態' → ［ポリシーB］ → 状態'' → ... → 実行計画

状態は書き換えられたクエリテキスト、累積されたフィルター、現在の意図、そしてすべての同義語展開を保持します。優先度の高いポリシーはクエリからテキストを削除することができ、それ以降のすべてのポリシーは元のクエリではなく、変更されたクエリを参照します。コンテキストが蓄積されます。順序が重要です。

優先順位と競合の解決：決定論が重要

具体的な競合戦略は設計上の選択です。組織によって競合解決の方法は異なり、それぞれのビジネス上の要件によって左右されます。以下のアプローチは、制御プレーンに必要な判断フレームワークの種類を示しています。重要なのはこれらの具体的な戦略そのものではなく、システムが予測不可能な相互作用によって競合を解決するのではなく、明確で決定論的な戦略を持つことです。

優先度による順序付け

ポリシーは優先度の高い順に並べ替えられます（最も優先度の高いものから）。複数のポリシーが同じクエリに一致する場合、それらは優先順位に従って適用されます。2つのポリシーが同じフィルターフィールドを設定しようとすると、そのフィールドに対して優先順位の高いポリシーが宣言した戦略が優先されます。同じ優先度を持つポリシーが複数トリガーされた場合、IDが最も高いポリシーが優先されます（より高い優先度が割り当てられているかのように）。この選択により、競合が発生した場合でも決定的な動作が保証されます。

ポリシー単位ではなく、フィールド単位の解決

重要な設計原則：競合解決はフィールドごと（例えば、ブランド、カテゴリー、または説明）で動作し、ポリシーごとではありません。2つのポリシーが特定のフィールドで重複するフィルターを生成する場合、その特定のフィールドのみが競合解決戦略の影響を受け、解決戦略は最も優先度の高いマッチングポリシーによって定義されます。両ポリシーの競合しないフィールドはそのまま残ります。

これは重要です。なぜなら、ポリシーごとのアプローチの代替案では、フィールドの1つだけが競合する場合でも、システムはポリシー全体を受け入れるか拒否しなければならないからです。

フィールドごとの解決により、有用な制約情報を最大限保持できます。

フィルターフィールドごとに3つの設定

ポリシー内の各フィルターフィールドには、3つの独立した設定があります。

フィルターモード：競合がない場合にフィルターがどのように適用されるか。

• hard_filter （デフォルト）：Elasticsearchのbool.filter句として適用されます。これは無関係な商品を完全に除外するのに役立ちます。例えば、「オレンジ」という検索語を農産物カテゴリーに限定すると、オレンジジュースやオレンジマーマレードなどの検索結果は除外されます。一致しない文書は検索結果から完全に除外されます。

• soft_boost：Elasticsearch function_score の重みとして適用され、boost_weight を設定可能です。一致する文書はランキングが上がりますが、一致しない文書も除外されるわけではありません。これは、他のブランドを排除することなく、自社ブランドの認知度を高めるといった場合に役立ちます。

競合戦略

低優先度のポリシーが同じフィールドを設定した場合、何が起こるのでしょうか。

• override：この優先度の高いポリシーの値が優先され、優先度の低いポリシーの値は完全に無視されます。すべてのフィールドタイプに有効です。

• restrict:より制限的な数値（例えば、価格__max, the higher floor for price__分の下限）を取ります。数値範囲フィールドでのみ有効です。

• merge：両方の値を結合して和集合にします。数値以外のフィールドにのみ有効です。

• soft_boost：競合するフィルターを、ハードフィルターではなく、設定可能なboost_weightを持つfunction_score重みに変換します。function_scoreブーストの詳細については、Elasticsearchの乗算ブーストによるBM25ランキングへの影響をご覧ください。これは非否定フィールドにのみ有効です。

値：実際のフィルター値（例：カテゴリーリスト、価格しきい値）。

フィールド別戦略：すべての戦略がすべてのフィールドに有効とは限りません。例えば、除外は本質的に二項的であるため、ソフトブーストはできません。以下の表は各フィールドタイプで利用可能な戦略を示しています。

フィールドタイプ

利用可能な戦略

デフォルト

否定フィールド(__not, __match__not)

オーバーライド、マージ

オーバーライド

数値範囲フィールド（__max, __min、__gt, __lt）

制限、オーバーライド、soft_boost

制限

その他すべてのフィールド（keyword、text）

soft_boost、override、merge

ソフトブースト

否定フィールドは、除外が二値であるため、ソフトブーストすることはできません。「缶詰食品を一切表示しない」を「缶詰以外の食品をやや優先する」に変更すると、意味が根本的に変わってしまいます。「缶詰食品」の商品は依然として表示され、順位が少し下がるだけなので、除外する目的が損なわれてしまいます。

具体的な例：クリスマスキャンペーン中に「安いチョコレート」を検索

あるマーチャンダイザーが、先に説明した2つのチョコレートに関するポリシーを作成したとします。1つは安価なチョコレート向けの優先度の低いポリシー、もう1つはクリスマス期間中に有効になる優先度の高いチョコレート関連のポリシーです。これらのポリシーが両方とも有効になっている場合、それらがどのように組み合わせられるかは、優先順位の高いポリシーのフィルターモードと競合戦略によって決まります。前述の2つのポリシーが両方とも有効になっている場合、それらは以下のように組み合わせられます。

これは、カテゴリーに関する競合と価格に関する競合という2つの対立を示しています。この変換後に実行されるクエリは以下の特徴を持つことに注意してください:

• 「クリスマスの食べ物と飲み物」および「クリスマスのお菓子」のカテゴリーに属する商品のみが表示されます。

• これらのカテゴリーの中で、商品に「アドベントカレンダー」カテゴリーのタグが付けられている場合は、3倍ブーストされます。

• 2ドルの価格フィルターが適用されます。これは優先度の低いポリシーから取得されたものです（優先度の高いポリシーでは、競合が発生した場合に「制限」するように指定されているため）。

• 「安い」という単語が削除され、「チョコレート」に一致する商品のみが表示されます。

これら2つのポリシーを有効にすると、「安いチョコレート」という検索語は、以下の画像のような結果を返します。

制約の緩和

おそらく、その小売業者はクリスマス期間中に「チョコレート」や「ミルクチョコレート」といったカテゴリーの商品を除外したくないのでしょう。クリスマスポリシーの設定が行き過ぎて、「安いチョコレート」ポリシーで適用されているカテゴリが誤って削除された可能性があります。これは、優先度の低いポリシーと相反する優先度の高いポリシーを組み合わせる方が望ましい場合がある理由を示す一例です。例えば、クリスマスチョコレートのプロモーションを修正して、競合が発生した場合に「オーバーライド」するのではなく、優先度を少し高めるようにすることができます。そのポリシーの変更は以下の通りです。

この修正後、「安いチョコレート」のクエリ書き換え変換パイプラインの実行は次のようになります。

競合時のソフトブーストでは、競合するフィルターは削除されるのではなく、ソフトブーストに変換されます。この変換後に商品カタログに対して実行されるクエリは、以下の特徴を持ちます。

• 優先度の高いポリシーでは「競合発生時」が「ソフトブースト」として指定されているため、競合は以下のようにブーストに変換されます。

  • 「クリスマスの食べ物と飲み物」および「クリスマスのお菓子」のカテゴリーの商品には、1倍のブーストが適用されます。

  • 「チョコレート」および「ミルクチョコレート」カテゴリーの製品には、3倍のブーストが適用されます。

• 前の例と同様に、商品が「アドベントカレンダー」カテゴリーに分類されている場合、それらは3倍ブーストされます。

• 前述の例と同様に、2ドルの価格フィルターが適用されます。

• 「安い」という単語が削除され、「チョコレート」に一致する商品のみが表示されます。

フィルタリング条件を緩めると、結果は以下のようになります。

優先順位の高いポリシーによる価格のオーバーライド

あるいは、小売業者はクリスマス期間中に少し高めのチョコレートを表示できるように、価格の上限を7ドルに引き上げたいと考えているかもしれません。誰かが「安いチョコレート」を検索した場合でも、クリスマスチョコレートポリシーの最大価格がオーバーライドされないようにするには、価格の競合モードを「制限」ではなく「上書き」に設定できます。設定方法は以下のとおりです。

このオーバーライドでは、「安いチョコレート」のクエリは、「安いチョコレートポリシー」で定義されている最高価格を無視し、次のように「クリスマスチョコレート」ポリシーで指定された価格のみを適用します。

これは前の例と似ていますが、違いは、優先順位の高いポリシーで競合時に「オーバーライド」が指定されているため、最大価格が7ドルの値に設定されている点です。クリスマス価格フィルターを優先すると、結果は次のようになります。

これら3つのバリエーション（override、soft_boost、価格のoverride）は、システムの重要なプロパティを示しています。マーチャンダイザーは、コードをデプロイせずに、1つのポリシー内の1つのフィールド設定を変更するだけで2つのポリシーの相互作用を変更できます。競合戦略は、ビジネスの行動を制御する手段となります。

消費されたフレーズの追跡

より微妙な形の対立もあります。同じ言葉で一致する2つのポリシーです。優先度の高いポリシーがクエリから「ピーナッツなし」を削除した場合、「なし」に一致した優先度の低いポリシーは処理すべき対象がなくなります。システムは、一致したフレーズが書き換えられたクエリに存在しないことを検出すると、優先度の低いポリシーをスキップします。

インテントポリシーは、消費されたフレーズの追跡の対象外です。優先度の高いポリシーによって削除されたテキストに関係なく、元のクエリの一致に基づいて検索戦略を設定します。

優先順位付け、フィールドごとの競合解決、消費されたフレーズの追跡を組み合わせることで、制御プレーンは決定論的な構成モデルを実現できます。その基盤が整えば、システムはリスクのあるルーティング決定を行うことができます。

ガバナンスにより検索戦略が安全に

適切な検索方法（テキスト、セマンティック、またはハイブリッド）へのルーティングに関する重要な洞察は、それがガバナンスの後に実行されるということです。ポリシーですでに「農産物カテゴリー」が規定されている場合、候補セットが制限されるため、セマンティック検索のリスクは大幅に軽減されます。500点の商品アイテムに対するセマンティック検索は、50万点のSKUに対するセマンティック検索とは全く異なるものです。ガバナンスにより、検索が始まる前に影響範囲が狭められます。

例えば、ガバナンスがない場合、「4ドル以下のビタミンCを多く含む果物」というセマンティッククエリは、果物に加えて、ビタミン剤、ニンジン、ピーマンを返す可能性があります。制御プレーンは、これらの望ましくない結果が意味展開の一部として考慮されないことを保証します。

この制約が設定されると、制御プレーンは実用的なルーティングロジックを適用します。

• ナビゲーションクエリやヘッドクエリなど、決定論的な精度が重要な場面における語彙。

• 概念マッチングが役立つ、記述的なディスカバリークエリのためのセマンティクス。

• 制約がすでに実施されており、企業がより広範なリコールを受け入れる場合には、選択的にハイブリッドを採用。

アーキテクチャーから実装へ

ガバナンスを備えた制御プレーンは、アプリケーションコードにそのロジックを組み込むことなく、ビジネスの意図を決定論的で構成可能な実行計画に変換します。ポリシーはデータであり、クエリ時に照合され、フィールドごとの明示的な競合戦略によって解決され、説明可能な結果を生み出すカスケード変換として適用されます。Elastic Services Engineeringは、企業のeコマースチーム向けに、コンセプトから本番環境までの道のりを短縮する反復可能なパターンとアクセラレーターを使用してこのアーキテクチャーを構築しデプロイしました。制御プレーンの実装デモは、YouTubeの「Fixing Search Relevance in Seconds: Introducing PRISM」でご覧いただけます。

このシリーズの次回作

次回の投稿では実装をハンズオンで解説し、Elasticsearchパーコレーターがポリシーのルックアップをどのように支えているかを取り上げます。インデックスのマッピング、境界マーカー、ハイライトに基づくフレーズ追跡、具体的なクエリ例も紹介します。

ガバナンスを備えたeコマース検索を実践

この投稿で説明されている制御プレーンアーキテクチャー（フィールドごとの競合解決、カスケードポリシー変換、ガバナンス制約付き検索ルーティング）は、Elastic Services Engineeringによって設計および構築されました。このシリーズで紹介するパターン、スクリーンショット、トランスフォーメーションパイプラインはすべて、Elastic Services Engineeringによって構築され、エンタープライズスケールの商品カタログと照合された実際のシステムからのものです。

Elasticsearch上にガバナンスを備えたポリシー駆動型の制御プレーンを実装したい場合、Elastic Servicesを利用すれば、より迅速に実現できます。

議論に参加

検索ガバナンス、検索戦略、またはeコマース検索アーキテクチャについてご質問がありますか？より広範なElasticコミュニティの議論に参加しましょう。

語彙検索（テキストのマッチング）、セマンティック検索（概念のマッチング）、ハイブリッド検索（語彙シグナルとセマンティックシグナルの組み合わせ）は、単独ではこれらの問題を解決できません。語彙検索は「オレンジ」という単語を含むあらゆるものを返す可能性がある一方で、「オレンジ」のような意図の強いクエリに対する純粋なセマンティック検索は、レモンやグレープフルーツなどの関連項目へと広がる可能性があります。ハイブリッド検索はこれらの語彙シグナルとセマンティックシグナルを組み合わせますが、それでもこのクエリをナビゲーションとして扱うべきか、どの制約を適用すべきか、あるいはどのビジネスポリシーを適用すべきかの判断は行いません。欠けているのは検索技術そのものではなく、これがどのような種類のクエリであるか、そして検索を開始する前にどの制約を適用すべきかを理解するガバナンスレイヤーです。

このブログでは、eコマースの検索ガバナンス、その重要性、そして制御レイヤーが予測可能で正確な検索結果をどのように保証するかについて探ります。

eコマース検索におけるガバナンスの意味

ガバナンスは、この文脈では、ユーザーのクエリと検索エンジンの間に意思決定レイヤーを導入することを意味します。このレイヤーは以下の機能を果たします。

• クエリの意図を分類する：これはナビゲーション（「オレンジ」）か発見（「おじいちゃんへの贈り物」）か？

• ビジネス上の制約を適用する：どのようなカテゴリー境界、資格要件、在庫状況の制約、または販売促進ポリシーが適用されるか？

• 適切な戦略への道筋：語彙検索、セマンティック検索、ハイブリッド検索のどれを使用すべきか？

ガバナンスレイヤーは、各クエリにどの検索アプローチを使用すべきか、どの制約を適用しなければならないか、また検索が始まる前にどのビジネスポリシーを適用すべきかを決定します。ガバナンスとハイブリッド検索は混同すべきではありません。ハイブリッド検索は語彙的シグナルと意味的シグナルを組み合わせた検索戦略の一つであり、ガバナンスは語彙、セマンティック、ハイブリッドのいずれを使用すべきかを決定する上流の意思決定レイヤーです。

現状：アプリケーションレイヤーの「スパゲッティ」型実装

現在、多くの小売業者は、アプリケーションレイヤーに直接ロジックを追加することでこの問題を解決しようとしています。これはしばしばスパゲッティコード（何千行ものハードコーディングされたif-then文、正規表現、複雑な検索テンプレート）を生み出します。

このアプローチは、上記に示したような望ましい検索結果をもたらすことができますが、運用上の大きな摩擦を生じさせます。

• エンジニアリングへの依存：ビジネスユーザーやマーチャンダイザーは、エンジニアリングチケットの提出や数週間に及ぶ長い導入サイクルなしに検索動作を変更することができません。

• 断片化：検索ロジックはアプリケーションコードと検索テンプレートの間に散在し、説明や監査が困難になり、進化させるにはリスクが伴います。

チームがルーティングの必要性を認識したとしても、議論はしばしば間違った点、つまりどの取得方法を選択するかという点に集中してしまいます。

誤った選択：語彙検索、セマンティック検索、ハイブリッド検索のどれかを選ぶこと

検索チームはしばしば、この課題を検索戦略の選択として捉えています。この場合の選択肢は語彙/BM25、セマンティック/ベクトル、ハイブリッドの組み合わせです。その考え方は理解できます（検索方法は確かに重要です）が、実際の導入環境で最も一般的な失敗パターンを見落としています。それは、すべてのクエリに対して単一の検索方法を使用すると、最適とは言えない結果しか得られないということです。

コマース検索は、根本的に異なる意図が混在したものです。

• 決定論的で意図の高いナビゲーション（「オレンジ」、「牛乳」、「ピーナッツなしのチョコレート」、「安いオリーブオイル」）。

• 探求的な発見（「山でのハイキング用のジャケット」、「ロボット工学が好きな12歳の子供へのプレゼント」）。

• 運用上の制約（在庫状況、サイズ、価格、色）。

• マーチャンダイジングおよびキャンペーン（ブースト、非表示、季節限定キャンペーン）。

システムがこれらすべてを同じ検索戦略を通じてルーティングした場合、運用モデルにガバナンスが欠如しているため、予測可能な方法で体系的に誤った結果が返されることが多くなります。チームがこれをガバナンスのギャップと認識していない場合、唯一の手段であるチューニングの強化で対応します。

「関連性のチューニング」が循環的になり得る理由

ルーティングレイヤーがなければ、「関連性」はしばしば終わりのないバックログに変わります。

• なぜこのクエリでは主要製品よりも付属品が上位に表示されるのか？

• なぜこのヘッドクエリは突然関連アイテムを表示し始めたのか？

• 同義語を追加したり、アナライザーを調整したり、ハイブリッドを有効にしたりした後に結果が変わった理由は？

• なぜビジネスチームは単一のクエリを修正するのにエンジニアリングリリースが必要なのでしょうか?

チームは、同義語、ブースト、再ランキング実験、アプリケーションコードにおける例外処理などの追加といったさらなるチューニングで対応します。これはしばらくの間は機能するかもしれませんが、クエリの種類を決定し、取得前に適切な制約を適用するための明示的な決定レイヤーがシステムにまだないため、不安定な動作を引き起こすことがよくあります。

eコマースの意図の構造：ヘッドとテール

このセクションでは、eコマースにおける一般的なナビゲーションおよび探索クエリパターンの実用的な省略形として「ヘッド」と「テール」を使用します。現実世界では、多くのクエリには次の両方の側面が含まれています。

ヘッドクエリ（決定論的意図）

これらは、ユーザーが何を求めているかを正確に把握している、直接的なナビゲーションクエリです。

• 単一アイテムの意図（「オレンジ」、「牛乳」、「パン」）。

• 具体的なブランド名や製品ファミリー名（「iPhone 15 Pro」、「ダイエットコーク」）。

• SKU、モデル番号、サイズ（「ABC123」、「air max 270」）。

これらのクエリに対して、語彙検索はトークンの対応関係（単語のマッチング）を処理できますが、ビジネス側は制約を尊重し、予測可能なランキングを返し、制御可能な結果を得ることも期待しています。マーチャンダイザーは、クエリが正しいカテゴリーの境界内で解決され、適格性を尊重し、特定のビジネス優先事項を明確にすることを確認する必要があります。

意図された解決を強制するためにはガバナンスが必要です。例えば、「オレンジ」は農産物カテゴリーに分類されるべきであり、オレンジジュース、オレンジマーマレード、オレンジソーダに分類されるべきではありません。

テールクエリ（探索的発見）

これらは、購入者が探している情報を含む、詳細で意図が豊富なクエリです。

• 「甘いもの好きなおじいちゃんへのプレゼント」

• 「山でのハイキング用のジャケット」

• 「一日中立っていられる靴」

語彙検索は、このような場合にしばしば困難に直面します。セマンティック検索は、文言が一致しなくてもクエリの概念を製品に結びつけることができる点で優れています。しかし、セマンティック検索だけで十分なことは稀です。実際のクエリでは、どの検索方法を用いるかにかかわらず、制約を適用する必要がある場合が多くなります。

制約条件は検索方法に直交

制約をセマンティック検索に適用することは、ハイブリッド検索を意味するものではなく、これらは直交する概念です。Elasticsearchのフィルターやブーストなどの制約は、語彙、セマンティック、ハイブリッドのいずれの検索にも適用できます。課題は、クエリをどのように解釈すべきか、どの制約を強制すべきか、どの検索戦略を使用すべきかを決定することです。

以下は、検索とハードな制約を組み合わせたクエリの例です。

• オレンジ：「オレンジ」という語句に「果物」や「農産物」などのカテゴリー制約を加えた語彙検索を行い、オレンジマーマレード、オレンジジュース、オレンジソーダを除外。

• ビタミンCが豊富な4ドル未満の果物：栄養に関する意図を理解し、結果を果物カテゴリーと4ドル未満の製品に制限するセマンティック検索。

• 履きやすい仕事向けの靴：コンテキスト上の意図に基づくセマンティック検索と、結果を靴に限定するカテゴリー制約。

これらのクエリは単一の方法では処理できません。

• 純粋な語彙検索では不十分です。なぜなら、「ビタミンCが豊富」や「履きやすい」といったフレーズは、きれいに構造化された属性として存在しない可能性があるからです。これらは、製品の説明、レビュー、または仕様から推測する必要があるかもしれません。

• 純粋なセマンティック検索だけでも十分ではありません。明示的な制約がない場合、「ビタミンCが豊富な果物」のようなクエリは、意図したカテゴリーや価格帯から外れたビタミンサプリメント、フルーツ風味の飲料、ビタミン含有量の多い野菜などにまで広がる可能性があるからです。

ガバナンスレイヤーは、クエリが語彙検索、意味的理解、制約の適用、またはこれらの組み合わせを必要とするかどうかを決定します。このレイヤーがなければ、eコマースチームは以下のような状況に陥る可能性があります。

• 制約過剰：意味的なリクエスト（例：「おじいちゃんへのプレゼント」）に対して語彙検索を使用すること。

• 制約不足：意図の明確なヘッドクエリ（「オレンジ」など）に対してセマンティッククエリを使用すること。

ガバナンスの課題は、各クエリのクラスに対して適切な判断を下せるシステムを構築することです。

ガバナンスがない場合に起こること

最も一般的な失敗パターンは単純明快です。チームがユーザーの生のクエリを受け取り、中間的なガバナンスレイヤーを介さずに、それを単一の検索戦略（語彙、セマンティック、またはハイブリッド）に直接渡してしまうのです。

語彙検索は意図した解決を見逃す

ユーザーが「オレンジ」を検索すると、語彙検索戦略では、そのトークンを含むあらゆるもの（オレンジジュース、オレンジマーマレード、オレンジソーダなど）が返される可能性があります。システムはその用語を正しく照合しましたが、ガバナンスがなければ、意図した買い物のコンテキスト（果物）を解決できない可能性があります。

セマンティック検索は意図された制約を超えて広がる

ユーザーが「オレンジ」を検索すると、セマンティックシステムは、関連する製品コンセプト全体から、概念的に関連するアイテムを検索する可能性があります。システムはより広い領域（果物や農産物）を正しく理解しているかもしれませんが、明確なガバナンスがなければ、ユーザーが意図した制約（特にオレンジ）を超えてしまう可能性があります。

ギャップはガバナンスです

必要なのは、クエリの意図を判断し、検索開始前に適切な制約を適用する上流の決定レイヤーです。これにより、以下のような問題が修正されます。

• ユーザーが実際に求めていたものと類似または関連するアイテムが並べて表示される。

• カテゴリーの境界線が曖昧になる（「飲料」対「農産物」）。

• 季節ごとのブーストやキャンペーンを実施できない。

• 予測不可能で説明のつかない結果。

意図の理解とルーティング：必要な制御プレーン

ガバナンスを擁する検索システムは、検索の前（Elasticsearchでクエリを実行する前）に軽量な制御プレーンを導入します。この制御機能については、このブログシリーズの第3部と第4部で詳しく説明します。ここでは、その機能についてのみ説明し、動作原理については触れません。

コントロールプレーンは、以下のように意図を検出し、ビジネスポリシーを適用し、適切な検索戦略を確保することができます。

1. 意図シグナルを検出

• このクエリの目的はナビゲーションか、発見か？

• これは既知のヘッドクエリ（牛乳、パン、バナナなど）か？

• 既知の製品、ブランド、またはカテゴリー解釈はあるか（「オレンジ」は果物と解釈されるべきなど）？

• クエリはSKUのようなパターンですか？

• その検索クエリは、現在実施中のキャンペーンや季節的なポリシー（例えば、クリスマス期間中に七面鳥関連の検索結果をブーストするなど）の対象となるか？

• クエリは制約（カテゴリー、属性、除外、価格/サイズ/色）を示唆しているか？

2. ガバナンスおよびビジネスポリシーを適用

• まず決定論的制約（カテゴリー/属性/否定/可用性）を強制します。

• 積極的なマーチャンダイジングポリシー（ブースト/非表示/ピン留め/上書き）を適用します。

• 優先順位ルールとの競合を解決します（キャンペーンによる上書きとグローバルポリシーなど）。

3. 適切な検索戦略へルーティング

• ナビゲーションや意図の高いヘッドクエリには語彙的（高速かつ決定論的）な処理。

• 真の発見クエリにはセマンティック検索。

• 語彙と意味のシグナルを組み合わせて、明示的なビジネス制約の下で価値を加えるハイブリッド。

実際には、制御プレーンの出力は単に「ハイブリッドを使用」または「セマンティックを使用」というものではありません。これはガバナンスを備えた検索計画であり、購入者の意図、適用されるべき制約とポリシー、そして実行されるべき検索戦略の解釈です。いくつかの簡単な例を挙げると、これがより具体的に理解できるでしょう。

検索クエリ

ガバナンスを備えた解釈

検索計画の例

「ピーナッツなしのチョコレート」

ハード除外制約付きの製品指向クエリ

チョコレートの語彙検索とピーナッツを含む製品の除外フィルター

「安いオリーブオイル」

価格制約付きの製品/カテゴリー検索

オリーブオイルの語彙検索と小売業者の低価格基準で上限を設定した価格フィルター

「4ドル以下のビタミンCを多く含む果物」

セマンティックな理解と厳格な制約を必要とする検索クエリ

栄養に関する意図を意味的に検索し、果物カテゴリーに限定し、価格が4ドル以下の製品に絞り込み

制御プレーンは、各クエリに対して一貫して、予測可能かつスケールで適切なポリシーと検索戦略を選択します。これにより、意図に沿った制約が最初に適用され、ルーティングの決定が暗黙的ではなく明示的になるため、高度な検索方法が本番環境でより予測可能になります。

他のアプローチとの関連

一部のチームは、製品のセマンティクスをより正確に捉えるために改良された埋め込みモデルを使用しており、これによりセマンティック検索の品質を大幅に向上させることができます。その他には、検索後のエンゲージメントやビジネスシグナルに基づいて結果の順序を最適化するために、ランク学習（LTR）などの再ランキング手法を用いるものもあります。どちらも価値があり、多くの場合、互いに補完し合う関係にあります。より良い埋め込みは類似性マッチングを改善します。再ランク付けは取得した候補の順序を改善します。

ガバナンスは問題の別のレイヤーに対処するものであり、情報取得よりも上流に位置します。どの検索戦略（例えば、語彙、セマンティック、ハイブリッド）を使用するか、どのような決定論的制約が必要か、そしてどのクエリで複数のビジネスポリシーを組み合わせるべきかを決定します。

ガバナンスされたコントロールプレーンが可能にすること

一度ガバナンスレイヤーが設置されると、運用モデルは根本的に変わります。売上に直結するクエリは予測可能になり、ビジネスチームは、エンジニアリングリリースサイクルを待たずに検索動作を更新できます。また、セマンティック検索やハイブリッド検索といった高度な検索手法は、全体的なオン/オフスイッチとしてではなく、ルーティングやガードレールの背後で段階的に導入することができます。

このシリーズの次回の記事では、その運用モデルが実際にどのようなものなのか、そしてなぜそれが基盤となる検索技術と同じくらい重要なのかを探ります。

もしマーチャンダイザーがJiraチケットを開いて、売上に大きく影響するクエリを修正するためのデプロイを待たなければならないとしたら、ボトルネックはエンジンではなく、運用モデルにあります。現代のeコマース検索では、ビジネスの意図を迅速かつ安全に、管理可能で監査可能な検索動作に変換する方法が必要であり、同時に、測定可能な価値を付加する高度な検索機能も引き続き活用する必要があります。

このシリーズの次回作

本シリーズで探求するパターンは、検索の上流で機能します。クエリ生成が始まる前に、ビジネス上の意図を適切なクエリ戦略に変換します。次回の記事では、技術的な問題から運用上の問題へと視点を移します。ビジネスチームがエンジニアリングの介入なしに検索動作を変更できるようになった場合に何が起こるか、そしてガバナンスがそれを安全にする理由について説明します。

ガバナンスを備えたeコマース検索を実践

エンタープライズ向けeコマースサービスにおけるエンジニアリング上のボトルネック、脆弱なアプリケーションレイヤーロジック、予測不可能な検索結果などは、Elastic Servicesが解決に役立つ問題です。本シリーズで解説するガバナンスを備えた制御プレーンアーキテクチャーは、Elastic Services Engineeringによって構築されました。

もし貴社のチームが商品企画に関する要望をコード変更に落とし込むためにエンジニアリングサイクルを費やしていたり、検索関連性に関する未解決の課題が一向に減らないようであれば、Elasticは現在のアーキテクチャーを評価し、ガバナンスを備え、ビジネス部門が編集可能な検索システムへの道筋を構築するお手伝いをいたします。Elastic Servicesにご連絡ください。

議論に参加

検索ガバナンス、検索戦略、またはeコマース検索アーキテクチャについてご質問がありますか？より広範なElasticコミュニティの議論に参加しましょう。