生成AI時代に問われる「検索」の役割
Elastic社が創業したのは2012年。この10年間を振り返ると、GitHubのスター数10万3000以上、ダウンロード数420万以上、貢献社数3500以上、プルリクエスト18万3000以上、コミット14万8000以上、Elastic Cloud（Elastic社が提供するマネージドサービス）が1日で処理する検索リクエスト数60億以上となっており、検索を通じてデータ活用に新たな可能性を生み出すとともに、多くのユーザーに貢献してきたことがわかる。
当初は、創業者が妻のためにレシピ検索アプリを作ろうと、オープンソースの検索エンジンライブラリであるApache Luceneをベースに構築されたElasticsearchは、「無料かつオープン」を志向しながら、ログ監視・アプリケーションパフォーマンス監視・インフラ監視・シンセティック監視・リアルユーザー監視など、さまざまな機能を追加しながら進化を続けている。
ところが2023年、センセーショナルな事件が起きる。「検索」の世界しか知らなかった私たち恐竜のもとに、突如、「生成AI」という隕石が落ちてきたのだ。かつての歴史がそうであったように、隕石の衝突がもたらす環境の変化によって、私たち恐竜は滅びる運命を受け入れるしかないのか——。
賢明な開発者たちは、新たな環境に適合すべく、生成AIをどう組み込めば良いのか、さまざまな実験を始めた。そこで浮き彫りになった課題が以下のようなものである。
- ハルシネーション、誤回答……嘘の情報をあたかも本当かのように返答してくる。
- 複雑な技術スタック……生成AIを組み込むには、いろいろな場所をAPIでつなぐなどしているうちに、構成が複雑になってしまう。
- プライベートデータへのリアルタイムなアクセス……生成AIは汎用的なデータを学習しているため、最新の情報や業界特有の専門知識などが不足している。
なかでも最も大きいのが、「プライベートデータへのリアルタイムなアクセス」だろう。この問題を解決するには、「ファインチューニング」と「RAG（Retrieval-Augmented Generation：検索機能拡張生成）」の2つの手法があるが、ファインチューニングには相当な時間やお金のコストがかかってしまう。
「だからこそ、すでに実績のある検索を活用した『RAG』を活用すべきであり、『検索は今まで以上に重要になっている』と言えるのだ」と杉本氏は強調する。
「検索は生成AIに駆逐されるのではないかと思われるかもしれないが、まったくそんなことはない。Elasticはこれまで培った検索技術を用いて、プライベートなデータと生成AIの橋渡し役を担っていく」（杉本氏）
RAGを使うと、検索はどのように変わるのか
LLMによるテキスト生成に、外部情報の検索を組み合わせることで、最新の正確な情報に基づいた回答を導き出させるRAG。
たとえば「弊社の確定拠出年金の申込方法は何ですか？」とWeb検索エンジンに聞いても、まともな結果は返って来ない。ではRAGを使うとどうか。まずRAGでは、社内のイントラにあるようなデータを検索できる状態にしておく。そのデータの中から検索エンジンを介して、関連する結果を探す。さらに、そのデータをプロンプトに組み込んだ形で、当初の質問を生成AIに投げると、適切な回答が返ってくるという流れだ。
「これであれば検索まわりのチューニングをすれば精度を上げられるし、LLMの利用料を最小限に抑えられるメリットもある」（杉本氏）
このような生成AI時代の検索を見据え、Elasticが発表したのが「Elasticsearch Relevance （ESRE）」。利用者が自社独自のリアルタイムデータを使用して、ビジネスに特化したAI検索アプリを開発できるものだ。魅力的なAI検索アプリを開発するための各種開発ツールが提供されており、テキスト・ベクトル・ハイブリッド検索をさまざまなLLMと連携することが可能。ドキュメントやフィールドレベルセキュリティ、オンプレもしくは50以上のクラウドリージョンといったエンタープライズレディなプロダクトとなっている。以下はその主な特徴だ。
テキスト・ベクトル・ハイブリッド検索
- 文章検索＆ベクトルデータベース
- RRF（Reciprocal Rank Fusion）：ハイブリッドスコアのモデル（ベクトル＆文章検索）による意図検索
- kNN（k-Nearest Neighbor）とハイブリッドクエリのフィルタとファセット
機械学習モデルの選択肢
- 自作のトランスフォーマーモードを管理、あるいはサードパーティLLM（OpenAI）
- Elastic独自のゼロショットMLモデル
- LangChainなどのサードパーティツールとの統合
エンタープライズレディな開発者体験
- ドキュメント・フィールドレベルセキュリティ
- いくつかのコンプライアンスフレームワークのカバレッジ
- オンプレ上、あるいはクラウド上の30以上のリージョンにデプロイ
RAGを使った検索体験。その裏側ではどんな技術が動いているのか
続いて、杉本氏はElasticsearchの検索結果とRAGの差分を実際に示すべく、デモを行った。今回は、Elasticの日本語ブログをElasticsearchのWebクローラーに読み込ませたものを使用。フロントエンドのWebアプリはPythonで記述し、裏でLLM（OpenAI）に投げている。
これが「ベンチマークツールについて教えて」と聞いたときの、Elasticsearchの通常の検索結果だ。
同様の質問をRAGに投げかけるとどうなるのか。上位3つの検索結果の全文を掛け合わせて要約したものが、サマリーとして表示されているのがわかる。
「裏では、泥臭いことをいっぱいしている」と言いながら、杉本氏はベクトル検索と全文検索を組み合わせたPythonのコードを見せた。ChatGPTのモデルを使うとプロンプトが長くなり過ぎてしまうので、2500字で切るような工夫もしている。
なかでも注目したいのが、タイトルの横にある「＋」と「－」のボタンだ。これはリアルタイムなデータの重み付けをするためのものである。データの鮮度や重要性などによって、重視したいものは「＋」を押して順位を上げることで任意の値が付与され、検索結果の順位が変わると同時に、サマリーの内容も変わるのだ。
「LLMのモデルの中で何かをしなくても、『このデータを使って回答して』とリアルタイムで指示できるのが一番有用なポイントだ」（杉本氏）
ちなみに最新バージョンに近いElasticsearchにはWebクローラーも搭載されている。サイトの一部をインデックスに含める／除外するといったクローリングのルールを自由に設定できるほか、各種API経由でフレキシブルにクローラーを管理することも可能だ。
また、「ElasticsearchのIngest Pipelinesという機能を使えば、外のAPIに投げることなく、Elasticsearch内でテキストエンベディング（＝ベクトル化）することもできる」とし、わずか数クリックでデプロイする様子も見せてくれた。
「Elasticは検索エンジンだけでは終わっていない。生成AIの他にも、さまざまな先進的な取り組みを進めている。RAGや生成AIは銀の弾丸ではなく、あくまでもひとつのツール。これからも試行錯誤は必要だし、Elasticが寄与できることがたくさんあると知ってもらえれば」と語り、また14日間のフリートライアルもあるのでぜひElasticsearchを体験頂きたい、とセッションを終えた。
