Elasticのサーチエンジンビジネスの責任者にインタビュー。ビヘイビア分析の未来とは？

2022年11月30日に都内で開催されたElasticのプライベートイベント「ElasticON」から、ElasticのエンタープライズサーチソリューションのジェネラルマネージャーであるMatt Riley氏のインタビューを紹介する。

Elasticはオープンソースの検索エンジンElasticsearchやElasticsearchのユーザーインターフェースのKibanaなどの開発元として知られている。しかし、AWSがElasticsearchなどを用いてモラルに反したサービスを提供し、そこから利益を上げているとして、それを防ぐためにライセンスを変更した。AWSは対抗措置としてElasticsearchとKibanaのコードをフォークさせ、OpenSearchと命名して独自のオープンソースソフトウェアとして公開を行っている。

Elasticsearch自体はGitHubで公開されているため、オープンソースソフトウェアであることには違いがなく、AWS以外のパブリッククラウド、つまりGCPとAzureではElasticが両社と共同開発したマネージドサービスが提供されている。2022年11月現在、Elasticはオープンソースソフトウェアの会社ではあるものの、一般的なApacheライセンスを独自のライセンスに変更し、パブリッククラウドのトップベンダーAWSには真正面から敵対しているという微妙な立ち位置にいると言えるだろう。

AWSに対する処置としてのライセンス変更については、以下のElasticのCTOであるShay Banon氏が書いたブログを参照されたい。

●参考：Amazonと、NOT OK - Elasticがライセンスを変更しなければならなかった理由

しかしこのカンファレンスでは、Elasticが提供するソフトウェア、サービスについて語ることがメインであり、ユーザーもパートナーもElasticのソリューションを使っていることの利便性を理解しているのが前提であり、特にライセンス問題について語られることはなかった。これは至極当然と言えるだろう。

今回のインタビューではElasticsearchの未来、よりスマートな検索エンジンを実装するためのアイデアなどについて回答をしてくれた。

まず自己紹介をお願いします。

私はElasticのエンタープライズ向けサーチソリューションの責任者をやっています。2017年に前職のSwiftypeが買収されたことで、Elasticの一部となりました。Swiftypeは私が創業したSolrをベースにした検索エンジンの会社で、それからずっと検索エンジンの仕事をしています。Swiftypeを創業した時は丁度Elasticがごく初期のバージョンをリリースした頃で、その時からElasticsearchをエンジンにして検索エンジンの開発を続けていました。買収はElasticのShay Banonが「Elasticも君たちが作ってるようなソフトウェアを作ろうとしていて君たちのソフトウェアがとっても良いと思ってるんだけど、どうせなら一緒にやらない？」って誘ってくれたのがきっかけですね。Shayは今はCTOですが、Elasticの創業者で、一時期CEOの役職に就いていましたが、今は元のCTOに戻っています。

インタビューに応えたMatt Riley氏

2018年のElasticONでは、Shay氏はCEOでしたね。

その時に私もElasticONにいましたよ。会えなかったのはなぜでしょうね？（笑）2018年はSwiftypeが買収された直後でした。その時はApp Searchが丁度立ち上がった時で、それまでSaaSベースで作られていたApp Searchをオンプレミスでも使えるように開発を行ったわけです。その意味ではエキサイティングな時期でしたね。

セッションの中でステートレスサーチ、ベクターサーチという言葉が出てきました。Elasticの新しい方向性だと思いますが、それについてもう少し詳しく教えてください。それはSaaSだけではなくオンプレミスもハイブリッドも可能になるという説明がありました。

ステートレスサーチは「ステートレス」という単語が示すように、クラウドネイティブなサーチ機能を指します。これはサーチのバックエンドのストレージとのコーディネーション機能を分離して、例えばS3を使うなどが可能になります。

ベクターサーチはもうかなり長い間、リサーチの領域では話題になっていますし、実際にベクターサーチをビジネスにしている企業もあります。ElasticsearchはBM25というアルゴリズムで全文検索を行いますが、同じAPIでベクターサーチもできるようになっています。ここが単なるベクターサーチのソフトウェアとは違うところで、彼らはベクターサーチを実装してそれからBM25のアルゴリズムを実装しようとしています。なぜならベクターサーチとBM25を組み合わせたハイブリッドサーチこそが最良の結果を出すということに気が付いたからなんですね。

一方Elasticは最初からそれを知っていましたし、だからこそ同じAPIで検索を行えるように実装したんです。またSaaSだけではなくオンプレミスでもというのは、企業の使い方をみればその必要性がわかるからです。例えばUberはElasticsearchを使っていますが、そのコアのビジネスと深く連携しています。なのでサーチが落ちるとビジネス全体が落ちるということになります。そういう事態を避ける意味でもSaaS、オンプレミスのどちらでも実装できるようにする選択肢を作ることが大事だと我々は理解しています。

●参考：「BM25」：https://ja.wikipedia.org/wiki/Okapi_BM25

ここから少し違う角度の質問をします。サーチが賢くないというのは一般消費者であれば体験からわかることですが、サーチエンジンに質問をした時にコンテキスト（文脈）を保持してくれないことに対する不満があります。これはAlexaの開発チームの責任者に質問した時にコンテキストを保持して対話することの難しさを説明してくれました。これに対してサーチの専門家であるElasticの見解はありますか？

これは例えばレストランを検索した時に「このレストランの閉店時間は？」と訊いて「9時です。」とサーチエンジンが答えた後に「それにはここからどの位で着けますか？」と移動時間を質問したとしてもそのレストランと私が居る現在地を理解して距離と掛かる時間を調べて回答するのが人間だとすれば、サーチエンジンは「それ？ ここ？」が理解できなくて毎回全部のパラメーターをクエリーとして渡さないと回答できないという問題ですね。

そうです。それが難しいのはわかりますが。

コンテキストの保持というのは、現時点ではサーチエンジンではなくそれを使うアプリケーションのデベロッパーが保持して使うという工夫が必要です。Alexaもそうですし、OpenAIのChatでもごく短い時間しかコンテキストを保持できません。Alexaは声という表現方法、インターフェースしかないので余計に難しいことは理解できますね。まぁ、賢くないという意見には賛成します（笑）。

であれば、いつの日にか、それがサーチエンジン側で可能になるんでしょう？

私のセッションの最後の方にThe Futureとしてかなり右のほう、つまり時間的にはまだだいぶ未来のほうに「Behavioral Analytical Dataを使う」という文字があったことは覚えていますか？ それがつまりコンテキストを保持するという機能に近いことを目指しているわけです。これはこれまでアプリケーションデベロッパーが負担していたユーザーのビヘイビアを使う、つまりコンテキストを保持するという機能をサーチエンジン側で担当することを意味しています。すでに最新バージョンではその一部の機能が実装されていますが、最初に私がこの機能の必要性を社内のデベロッパーに説明した時に「What ?」という反応しか返ってこなかったことを覚えていますが、のちに彼らもその必要性をすぐに理解してくれました。Elasticはそれをビルディングブロックとして提供しようと考えています。なのでBM25とベクターサーチの他にユーザーの行いを獲得して、より賢いサーチエンジンの実装を目指しています。

Riley氏が語ったエンタープライズ向けサーチエンジンの将来像

ビルディングブロックということは他の企業がそれを組み込んでソリューションとして使うということも可能になるわけですね。

その通りです。ベクターサーチもコミュニティが欲しいと声を挙げたことに対して我々が開発を行ったわけで、コミュニティとの対話を通じて何が必要なのかを常にリサーチしています。ベクターサーチも約2年前からスタートしていますので、我々はかなり素早く動ける組織だと思いますね。

サーチエンジンソリューションのトップとしてチャレンジは何ですか？

チャレンジはテクノロジーの進化や変化が速い時に、それを適切に選択するという部分ですかね。例えばサーチに関してはベクターサーチもそうですし、OpenAIが開発しているLLM（Large Language Model、大規模言語モデル）も含めて最新の技術が凄い速さで出てきます。それをコミュニティの声を聞きながら遅れを取らないようにする、適切に使って製品にフィードバックを行うというのが難しいと言えば難しいですね。

最近はITベンダーの中で機械学習のエンジニアが多く解雇されていますが、エンジニアを雇うというのも難しい問題ですか？

そうですね、それは最近だけではなく昔から難しい問題です。解雇が多いからと言って簡単になることはありませんよ（笑）。

Elasticのサーチエンジンの現状から未来について率直に回答してくれたRiley氏だったが、コンテキストを理解するサーチについては、消費者目線と開発者目線の両方を理解した上でユーザーの行いを理解するデータレイヤーが必要であると明確に説明してくれたのが印象的なインタビューだった。従来の全文検索に加えてベクターサーチ、そしてビヘイビア分析という新境地に、今後Elasticがどのように挑んでいくのか注視したい。