OpenSearchCon North America 2025のセッション「Introducing OpenSearch’s Search Relevance Workbench!」をまとめます。
スピーカー
このセッションは、AWSでOpenSearchのプロダクトマネージャーを務めるStavros Macrakis氏と、OpenSource ConnectionsのファウンダーであるEric Pugh氏によって行われました。
Stavros氏は検索の関連性に情熱を注いでおり、AWS、Google、GLG、FAST、Lycosといった企業で様々な組織やアプリケーションと共に仕事をしてきた経験を持っています。大規模で洗練された組織でさえ、検索システムの評価とチューニングに必要なデータ収集に失敗していることに頻繁に驚かされてきたという背景があり、今回紹介するSearch Relevance Workbenchの開発につながっています。
Eric氏はOpenSource Connectionsの共同創業者として、特にEコマース分野のクライアントが独自の検索チームを構築し、検索の成熟度を向上させることを支援しています。OpenSearchのアクティブなメンテナーでもあり、OpenSearchプロジェクトにおける検索関連性機能の拡充に注力しています。過去20年間、テスター、開発者、コミッター、ユーザーとしてオープンソースの世界に関わり続けており、Apache Software Foundationのメンバーでもあります。
検索品質の改善への課題意識
AWSのOpenSearchグループに参加して最初に顧客と話をした際、誰もが検索において求めているのは関連性、つまり良い検索結果であるにも関わらず、驚くべき現実に直面しました。ほとんどの顧客が結果の品質について不満を抱えていながら、それをどう改善すればよいのかわからないという状況にあったのです。
顧客の成熟度には大きな差がありました。一部の洗練された顧客は、ユーザーの行動やシステムで何が起きているかについてのデータを収集する仕組みを持っていましたが、多くはそうではありませんでした。独自のツールを使って結果を分析したり、異なるアルゴリズムを比較したりしている顧客も存在しましたが、これも少数派でした。結局のところ、ほとんどの顧客が関連性を改善するために私たちの支援を必要としていたのです。
この状況から明確になったのは、単にツールを提供するだけでは不十分だということでした。基本的なデータを収集する方法から始める必要があり、それこそがSearch Relevance Workbench開発の出発点となりました。
検索関連性の改善サイクル
検索関連性の本質は、検索処理、測定と分析、そして検索チューニングという3つの要素が形作る反復的なサイクルにあります。多くの人は検索処理の部分、つまり「語彙検索やセマンティック検索、ベクトル検索が必要だ」という技術的な側面に注目しがちです。確かにこれらは重要なツールですが、それだけでは結果が良いかどうか、以前より改善されたか、どのように結果を向上させるかという本質的な問いには答えられません。
真に重要なのは、右上の「測定と分析」の部分です。オンラインでリアルタイムにユーザーの行動を測定することも、オフラインで実験することも必要です。実際、検索エンジニアやプロダクトマネージャーが新しい検索エンジンを導入した際、最初にすることは何でしょうか。まず自分のお気に入りのクエリを試してみるのです。「赤い靴」と入力して問題なく動作することを確認した後、「では深紅色のパンプスはどうだろう」と試します。ここで「パンプス」という単語が水の取り扱い装置を返すのか、それとも期待通り女性用のハイヒール靴を返すのかを確認するのです。
こうした実験を通じて何が起きているかを確認し、リグレッションテストを行って新しいバージョンが古いバージョンより優れているかを検証したいと考えるのは自然なことです。しかし現実には、ほとんどすべてのユーザーにとってこれは非常に非公式なプロセスであり、それをサポートする適切なツールが存在しません。既存のツールといえばExcelやdiffといった原始的なもので、何もないよりはましですが、十分に機能しているとは言えません。
そして最後に、なぜ実験や測定を行うのかという根底には、検索チューニングがあります。実際にアルゴリズムを変更し、パラメーターを調整して、より良い結果を得るためのサイクルを完成させる必要があるのです。
測定と分析への注力
測定と分析の分野において、OpenSearchチームはまず最も基本的なところから始めました。それがUser Behavior Insightsプロジェクトで、現在OpenSearch 2.15に組み込まれています。このプロジェクトの核心は、ユーザーが実際に何をしているかを測定することです。ユーザーがどのようなクエリを入力し、どのような結果が表示されているか、そしてクリックした結果だけでなくすべての結果を記録します。典型的な行動パターンとして、ユーザーは1つか2つの結果を開いて確認し、3番目の結果で最終的に購入や読了といったアクションを取ることが多いのですが、こうした一連の行動データこそが基礎となります。このデータがなければ、何を改善すべきかを知ることは非常に困難です。
このプロセスの次の段階として開発されたのが、Search Relevance Workbench（SRW）です。数ヶ月前にオープンソースでリリースされ、まもなくマネージドサービスでも利用可能になるこのツールは、結果を比較・分析するために必要なすべての機能を備えています。オフライン評価では、複数のクエリとその結果を把握し、バージョン間で比較することができます。オンライン評価機能も含まれており、実際のユーザー環境での評価が可能です。
特に注目すべきは、将来のバージョンで実装予定のInterleaved A/Bテストです。従来のA/Bテストでは統計的に有効な結果を得るまでに1ヶ月以上かかることがありましたが、この新しい手法ではわずか1日で有効な結果を得ることができます。これによりターンアラウンドタイムが劇的に短縮されます。
また、Nightly評価機能では、アルゴリズムの変化を時系列で追跡するために、スケジュールに従って定期的にライブ結果を評価できます。さらにUniversal Search APIアクセスは、SolrなどからOpenSearchへ移行する際や、新しいサービスの導入を検討している際に、異なるシステム間での結果を比較して、同等以上の品質が保たれていることを確認するための機能です。これらの機能により、検索品質の継続的な監視と改善が可能になります。
Search Relevance Workbench
Search Relevance Workbenchは、単なる数字ではなく洞察を提供し、あなた自身のデータと連携して動作する一連のツールです。多くの検索評価の文献では、BEIRのようなベンチマークを使用して異なるアルゴリズムを比較することが一般的です。確かにBEIRは優れたベンチマークセットですが、あなたの実際のビジネスに対応しているとは限りません。特にEコマースのベンチマークとしては適切ではなく、すでに数年前のものになっています。さらに、多くの人がBEIRの特性を理解し、それに合わせて最適化してしまうという「チート」の効果も存在します。しかし重要なのは、BEIRは抽象的な比較には問題ないものの、あなたの文脈、ユーザー、ビジネスケースで物事を比較するにはあまり役に立たないということです。
だからこそSearch Relevance Workbenchでは、独自のデータを使用して評価することを重視しています。NDCGのようなベンチマークスタイルの指標も使用しますが、多くの人が「うちのNDCGは0.57で、あなたのところの0.55より大きい」と言っても、そこから得られる洞察は限定的です。本当に知りたいのは、何が良くなったのか、ある種類のクエリで改善され、別の種類では悪化していないか、ということです。
そのため、実験と探索の概念を重視しています。「結果を目で見て確認する」というアプローチは、あまり科学的ではないように聞こえるかもしれませんが、実際には新しい検索エンジンを導入した際に誰もが最初に行うことです。いくつかのテストクエリを試して、どのような結果が返されるかを確認します。しかし、このプロセスを体系的にサポートするツールは今まで存在しませんでした。1000個のクエリをテストする必要がある場合、すべての結果セットを人間が確認することは不可能です。どのクエリに注目すべきか、なぜこのクエリでこんなに結果が変わったのかを効率的に特定するツールが必要なのです。ほとんど変化のないクエリに人間の労力を費やす理由はありません。
Search Relevance WorkbenchはGUIだけでなく、実験とデータ管理をサポートし、さらにデータ管理のためのAPIも提供しています。これにより、視覚的な確認と自動化の両方のアプローチが可能になります。
デモ
デモ動画(開始時間指定リンク)
https://youtu.be/sk0QROv_44c?si=Ai1Te25teVwz9HCR&t=533
Nightly Playgroundで実行されているSearch Relevance Workbenchを使ってデモが行われました。以下はデモ内容のサマリです。
Nightly Playgroundは毎晩デプロイされる環境で、OpenSearchの最新機能をすべて試すことができる実験環境です。
playground.nightly.opensearch.org
検索改善の旅は、通常単一クエリの比較から始まります。住宅改修のEコマースサイトを例に、「テープと泥の道具」（乾式壁ツールの別名）というクエリで実演が行われました。まず基本的なクエリを実行し、その後タイトルフィールドにブーストをかけることで改善できるかを検証しました。UIから、2つの異なる検索設定の結果を並べて比較できます。
比較結果を見ると、タイトルブーストを適用した右側のアルゴリズムでは、最初の4つの結果は同じ位置を保っていましたが、ベースラインクエリでは窓用のスプラインツールやLEDライトといった関係のない商品が含まれていたのに対し、新しい設定では適切な乾式壁ツールが上位に移動し、関連性が改善されたことが確認できました。このように詳細を観察することで、色の考慮やその他のパターンの違いといった、定性的な変化を理解できます。
しかし、単一のクエリの最適化は森の中の1本の木を見るようなもので、CEOが「泥のクエリの結果を修正しろ」と言った際に、そのクエリだけを改善して他のすべてのクエリに悪影響を与えるという典型的な失敗につながる可能性があります。そこで次のステップとして、クエリセット比較実験に進みました。クエリセットは手動入力、アップロード、またはUser Behavior Insightsを使ってライブトラフィックから取得できます。
150個のクエリを使った評価では、JaccardスコアとRBO（Rank-Biased Overlap）という2つの重要なメトリクスが使用されました。Jaccardは結果セット間の重なりを示し、RBOはリストとしての変化を測定し、特に上位の結果により高い重みを置きます。例えば「to boot New York」というクエリではJaccardとRBOの両方が1.0となり、タイトルブーストが全く影響を与えなかったことがわかりました。逆にRBOでソートすると、重複がゼロのクエリを見つけることができ、これらは詳細な調査が必要な箇所として特定できます。
判断（judgments）の収集は検索評価の重要な要素ですが、歴史的に困難で費用がかかるプロセスでした。特許検索や医療検索などの専門分野では、検索エンジニアが適切な判断を下す資格があるとは限りません。Search Relevance Workbenchでは、LLMを判断者として使用する機能、User Behavior Insightsからの暗黙的な判断、または外部からのアップロードという複数の方法で判断を収集できます。
最終的な検索評価では、NDCGをはじめとする古典的な情報検索指標が計算されます。デモでは、ベースラインのNDCGスコア0.53がタイトルブースト適用後に0.54に改善されたことが示されました。わずかな改善ですが、重要なのは悪化していないことです。また、カバレッジ指標も重要で、返された結果の85%に判断が存在することが示されました。カバレッジが低い場合、他の指標の信頼性も低下するため、十分な判断データの収集が不可欠です。
特に注目すべきは「検索設定」（Search Configuration）の概念です。これはインデックス、クエリ、テンプレート、パイプラインだけでなく、同義語処理などの前処理も含む、アルゴリズムを決定するすべての側面を包含します。この検索設定という概念により、異なる設定に名前を付けて管理し、A/Bテストやインターリーブテストで比較することが可能になります。デモンストレーションは、バックグラウンドでの処理が可能で、10,000個のクエリでも実行できる柔軟性を示して締めくくられました。
今後の改善
継続的な品質監視
検索評価を何度か実行した後に必要となるのは、検索品質が時間とともにどのように変化しているかを理解することです。品質が向上しているのか、悪化しているのか、それとも同じレベルを維持しているのかを把握することは、検索システムの運用において極めて重要です。同じままであれば特に心配する必要はありませんし、向上していれば上司に対して良い成果を報告できます。しかし、もし悪化している場合には、いつの時点で新たな投資を行い、新しい検索設定を考案したり、コンテンツの問題を深く調査したりする必要があるのかを判断しなければなりません。
この監視の必要性は、意図的なアルゴリズム変更の場合だけでなく、予期せぬバグが発生した場合にも当てはまります。例えば、コンテンツフィードに問題が発生して何も更新されなくなった場合、検索結果にどのような影響が出るでしょうか。こうした問題を早期に検出するために、検索結果の品質に関する監視システムが必要となります。これは単にシステムが稼働しているかどうかを確認する標準的な監視とは異なり、実際に良い結果を生成しているかどうかを継続的に評価するものです。
実装されるアプローチは非常にシンプルです。まもなく、設定した任意の検索評価実験を、cronジョブ構文を使用して定期的に実行できるようになります。毎晩、毎時間、さらには毎分といった頻度で実行することが可能です。もちろん、毎分実行することが意味を持つのは特殊なストリーミングユースケースなどに限られますが、柔軟な設定が可能になります。現在はUIのモックアップの段階ですが、ほとんどの基盤となる機能は完成しており、まもなくダッシュボードが提供される予定です。この機能により、検索品質の継続的な監視と、問題の早期発見が可能になります。
サードパーティ検索API・エンジンとの統合
OpenSearchに対する評価は素晴らしいものですが、さらに野心的な目標があります。Search Relevance WorkbenchをOpenSearch以外の検索プラットフォームもネイティブに評価できるようにし、「ベイクオフ」（比較評価）や移行のユースケースをサポートすることを目指しています。また、OpenSearch上に構築されたカスタム検索APIの評価も可能にしたいと考えています。
多くの組織では、カスタムのマーチャンダイジングロジックを備えた独自の検索APIを構築しています。OpenSearch内部で起こっていることだけを評価しても、検索品質の完全な姿は把握できません。実際、昨年ある顧客から相談を受けた際の話が象徴的です。その顧客は既存の検索エンジンを数年間運用し、関連性のチューニングに多くの時間を費やしてきました。OpenSearchへの移行を検討していましたが、「移行後も以前と同じくらい良い結果が得られているかどうか、どうやって確認すればよいのか」という問いに答えることができませんでした。
この課題を解決するため、RFCを通じてコミュニティの意見を求めています。Scottが開発した概念実証では、Search Relevance WorkbenchがSolr APIと通信する機能を実装しました。この統合はテンプレートマッピング構造を介して行われ、Solrが生成するレスポンスをOpenSearchが期待する形式にマッピングします。これは概念実証の段階ですが、この仕組みを他の検索エンジンにも拡張できると考えており、移行を検討している組織にとって重要なツールとなる可能性があります。
その他の検索エンジンとの統合の試み
Search Relevance Workbenchを他の検索エンジンと組み合わせて使用することへの関心も高まっています。実際の例として、アムステルダムのSuperlinkedチームとの協業があります。Daniel Svavonaから「SuperlinkedのベクトルがEコマース分野でどれほど効果的か独立した評価ができるか」という問いかけがあり、私の同僚であるMatthias Kruegerが「できるが、どのデータセットを使用し、分析結果をどのように共有すべきか」と応答しました。
この協業では、Search Relevance Workbenchが公開するAPIを使用して、Superlinkedの検索エンジンの評価データをSRWにアップロードしました。具体的には、curlコマンドを使用してESCI評価データセットをSRWのエンドポイントに送信し、評価を実行しました。結果は印象的で、SuperlinkedのエンベディングはNDCG@10で0.71を記録し、語彙検索を大幅に上回りました。比較として、タイトルブーストのみのベースラインは0.37でした。
この実例は、Search Relevance WorkbenchのAPIが他の検索エンジンの評価にも活用できることを示しています。今後は、構造化データと非構造化データの両方をエンコードする混合エンコーダーアプローチと、テキストエンベディングのみを使用するアプローチの比較評価も予定されています。このように、SRWは異なる検索技術を公平に比較評価するためのプラットフォームを目指しています。
参考ブログ
Search Relevance Workbenchの活用方法について深く理解してもらうため、3つの詳細なブログ記事シリーズが計画されています。最初の記事「Taking your first steps towards search relevance」は、Daniel Wrigleyによって執筆され、すでにOpenSearchプロジェクトのウェブサイトで公開されています。
2つ目の記事は来週、3つ目は10月頃に公開予定で、これらの記事ではSearch Relevance Workbenchの活用方法についてさらに詳しく解説される予定です。
opensearch.org
opensearch.org
Search Relevance Workbenchの開発は、多くの貢献者の協力なしには実現できませんでした。過去1ヶ月間に新たに参加したメンバーを含め、すべての貢献者への感謝が述べられました。コミュニティと共にこのプロジェクトに取り組めたことは、オープンソースプロジェクトとしての大きな成果であり、今後もコミュニティからのフィードバックと貢献を歓迎しています。
まとめと更なる発展の展望
Search Relevance WorkbenchはすでにOpenSearch 3.1でオープンソースとしてリリースされており、AWS Managed Serviceでもまもなく利用可能になります。現在はNightly Playgroundで試すことができ、実際に機能を体験していただけます。ドキュメントもすでに公開されており、具体的な使い方を確認できます。
バージョン3.2ではさらに機能が強化され、実戦でのテストを経てより安定したものになりました。バージョン3.3では、さらに多くの新機能がリリースされる予定です。開発は継続的に進められており、コミュニティからのフィードバックを積極的に取り入れています。
フィードバックや質問がある場合は、Slackコミュニティの#search-relevance-workbenchチャンネルで意見を共有できます。また、カンファレンス会場では、Stavros、Daniel、Eric、Anthonyに直接話しかけていただくことも可能です。GitHubでソースコードとダッシュボードのコードも公開されており、コミュニティからの貢献を歓迎しています。Search Relevance Workbenchは、検索品質の測定と改善というこれまで困難だった課題に対して、実用的なソリューションを提供するツールとして、今後も発展を続けていきます。
Agentic Relevance Tuning（ART）
Search Relevance Workbenchは検索品質の測定において多くの興味深い機能を提供していますが、なぜ測定だけに留まるのか、なぜ自動的にチューニングしないのか、なぜマシンにチューニングを任せたり、少なくとも手伝ってもらったりしないのか、という問いが自然に生まれます。
この問いに答えるため、Open Source Connectionsとの共同プロジェクトとして「Agentic Relevance Tuning（ART）」が開始されます。プロジェクトのコードネームは哲学者デイヴィッド・ヒュームにちなんで「Hume」と名付けられました。これはSearch Relevance Workbench、特にInterleaved A/Bテストに基づいて構築される実験主導の検索チューニングシステムです。問題を特定し、機械がそれを解決するのを支援し、結果を測定して、最終的に本番環境に導入するという一連のプロセスを自動化します。
このアプローチを学習型ランキング（Learning to Rank）と同じだと考える人もいるかもしれませんが、実際には全く異なります。学習型ランキングには大きな制限が2つあります。1つ目は、結果を取得した後にしか適用できないため、リコール（再現率）の改善に貢献できないこと。2つ目は、アルゴリズム内で数値的に微調整できるパラメータにしか機能せず、同義語リストの変更のような構造的な変更には対応できないことです。
Agentic Relevance Tuningはこれらの制限を超えて、より包括的な検索チューニングを実現することを目指しています。プロジェクトは木曜日の大規模な社内会議でキックオフされ、今後の進捗状況が共有される予定です。これにより、検索関連性の改善が測定から自動チューニングへと進化し、より効率的で効果的な検索システムの実現が期待されています。
