Taste of Tech Topics

Acroquest Technology株式会社のエンジニアが書く技術ブログ

セマンティック検索の活用で、Elasticsearchの検索が根本的に変わる!?

こんにちは、@shin0higuchiです😊
業務では、Elasticsearchに関するコンサルティングを担当しています。

最近すっかり春らしく、暖かくなってきました。
新年を迎えたばかりの感覚でしたが、あっという間に時が経ちますね。

さて、今回の記事では、Elasticsearchの検索を根本的に変える可能性を秘めたセマンティック検索に関して書かせていただきます。

概要

Elasticsearchは元々、キーワードベースのアプローチを主に取っており、クエリで指定されたキーワードを対象のドキュメント内で検索し、それらの出現頻度や位置に基づいて結果をランク付けしています。この方法では、文脈や意図に関係なく、単純にキーワードの一致度に基づいて検索結果が返されます。

一方、セマンティック検索とは、ユーザーのクエリの背後にある文脈と意図を理解しようとする検索手法で、キーワードだけに頼るのではなく、より正確で関連性のある結果を提供できます。このアプローチでは、自然言語処理NLP)や機械学習(ML)技術を活用して、単語や概念の関係やコンテンツの意味を理解し、検索クエリを最も適切な結果とよりよくマッチさせることができます。

最近GPTなどを始めとするLLM(大規模言語モデル)の話題をよく耳にするかと思いますが、それに類する学習済みモデルの力をElasticsearchの検索に活かすことが出来る、というお話です。
今回はGoogleが開発したBERTというモデルをベースにした学習済みモデルを実際に取り込んで利用します。

Elasticsearch 8.7 で何が変わったか?

実を言うとこれまでも、PyTorchの学習済みモデルをElasticsearchに取り込んで、一部のNLPタスクに利用することは可能でした。
たとえば 過去にElasticsearch勉強会で発表させていただいた通り、質問応答のタスクなどにも対応しています。
speakerdeck.com

これまでセマンティック検索を活用しづらかった背景としては、「クエリを事前にベクトル化(embedding)してからElasticsearchに問い合わせる必要がある」という制約が挙げられます。
つまり、せっかく機械学習モデルをElasticsearchに取り込んでも、一度外部でベクトル化をおこなってから検索しなければならなかったのです。
Elasticsearch 8.7 では、検索のリクエストに文字列を渡してモデルを指定すると、検索と一緒にベクトル化もおこなってくれるようになりました。

なお、日本語解釈の精度を課題と考えている方もいらっしゃると思いますが、取り込む学習済みモデルに依存するためここでは深く言及しません。また、今回は後述の通り日本語データで学習したモデルを利用することである程度検索精度を上げられる想定です。

具体的な利用方法

モデルの取り込み

まずは下準備です。

PyTorchモデルを Elandというライブラリを利用して取り込みます。
github.com

今回はHugging Faceで公開されている学習済みモデルを利用します。
cl-tohoku/bert-base-japanese-v2 は日本語のWikipediaで学習したモデルですので、日本語の検索で効果を発揮してくれることを期待しましょう。

eland_import_hub_model --url https://XX.XX.XX.XX:9200 --hub-model-id cl-tohoku/bert-base-japanese-v2 -u elastic --task-type text_embedding -p XXXX --ca-certs XXXX


取込みが完了したモデルは、次のようにスタートのエンドポイントを叩くことで利用可能になります。

POST _ml/trained_models/cl-tohoku__bert-base-japanese-v2/deployment/_start

取り込んだモデルは、「Trained Models」のメニューから確認することができます。
※lang_ident_model_1 というモデルも表示されますが、こちらはデフォルトで入っているモデルであり、今回の操作とは無関係です。

サンプルデータの登録

今回は当ブログ、Taste of Tech Topicsの記事を取り込んでみます。
ひとまずタイトルと本文を検索対象にしてみましょう。

Elasticsearchでは、ingest pipeline という機能を利用することで、ドキュメント登録時にベクトル化処理をおこなうことが可能です。
inference processor で、先ほど取り込んだモデルのID「cl-tohoku__bert-base-japanese-v2」を指定します。
また、最終的には vector.content, vector.title といったフィールドに値を入れたいので、rename processorも利用しています。

PUT _ingest/pipeline/text_embedding
{
  "processors": [
    {
        "inference": {
          "target_field": "inference.content",
          "model_id": "cl-tohoku__bert-base-japanese-v2",
          "inference_config": {
            "text_embedding": {}
          },
          "field_map": {
            "content": "text_field"
          }
        }
      },
      {
        "rename": {
          "field": "inference.content.predicted_value",
          "target_field": "vector.content"
        }
      },
       {
        "inference": {
          "target_field": "inference.title",
          "model_id": "cl-tohoku__bert-base-japanese-v2",
          "inference_config": {
            "text_embedding": {}
          },
          "field_map": {
            "title": "text_field"
          }
        }
      },
      {
        "rename": {
          "field": "inference.title.predicted_value",
          "target_field": "vector.title"
        }
      }
  ]
}


次に、ElasticsearchのMapping(スキーマ)を定義しておきます。
ポイントとしては、dense_vectorというデータ型でフィールドを定義する点です。
今回は詳細な説明を省きますが、 indexパラメータをtrueにすること、similarityパラメータを指定することが必要になります。
k-nearest neighbor (kNN) search | Elasticsearch Guide [8.7] | Elastic

PUT blogs
{
  "mappings": {
    "_source": {
      "excludes":["vector.title", "vector.content", "content"]
    }, 
    "properties": {
      "title": {
        "type": "text",
        "analyzer": "kurmoji"
      },
      "content": {
        "type": "text",
        "analyzer": "kurmoji"
      },
      "vector":{
        "properties": {
          "title": {
            "type": "dense_vector",
            "dims": 768,
            "index": true,
            "similarity": "l2_norm"
          },
          "content": {
            "type": "dense_vector",
            "dims": 768,
            "index": true,
            "similarity": "l2_norm"
          }
        }
      }
    }
  }
}

続いてドキュメントを登録します。
今回は次のように、Bulkリクエストで登録をおこないます。先ほど登録したパイプラインを指定するようにしましょう。

POST blogs/_bulk?pipeline=text_embedding
{"index":{}}
{"title": "XXXX", "content": "XXXX"}
{"index":{}}
{"title": "XXXX", "content": "XXXX"}
...

検索してみる

まず最初は、ベクトル検索を利用せずに「GPT3による質問応答システム」というクエリで全文検索を行ってみます。

GET blogs/_search
{
  "query": {
    "multi_match": {
      "query": "GPT3による質問応答システム",
      "fields": ["content", "title"],
      "operator": "or"
    }
  }
}

この際の検索結果は次のようになりました。

順位 タイトル
1 GPT-3を使って根拠付きで正確に質問応答してくれるシステムを作ってみる
2 GPTが出した回答の確からしさを見えるようにしてみる
3 第49回Elasticsearch勉強会で、ElasticsearchによるNLP(質問応答)の発表をしてきました
4 コンテナ内のアプリが複数種類のログを出力する場合の収集方法
5 GPT-3を使って自分だけのAIアシスタントを作る第一歩
6 Azure Container Instancesを使ってAngular+FastAPIなWebアプリを動かしてみた
7 Karateに性能試験とUI試験を任せてみる
8 新しいデータ基盤アーキテクチャである「データレイクハウス」について調べてみた
9 特徴量エンジニアリングのライブラリ xfeat を使ってみて便利だったこと
10 NFLのPlayer Contact Detectionで金メダル獲得&コンペ振り返り


この全文検索の結果では、「GPT3による質問応答システム」というクエリを形態素解析した結果でOR検索をおこなうため、GPT-3に関係ない質問応答関連の記事も上位に来てしまいます。
たとえば「第49回Elasticsearch勉強会で、ElasticsearchによるNLP(質問応答)の発表をしてきました」という記事が3番目に来ていますが、この記事はGPT-3に関連が無く、望んだ検索結果ではありません。

ここにセマンティック検索を追加することで検索結果が改善するかを見てみましょう。

セマンティック検索を利用するには通常の search APIにknnパラメータを指定して利用する形になります。以下のようなリクエストになります。
num_candidates の件数を各シャードで集めて、その中でスコアの高い k件を返却します。

GET blogs/_search
{
  "query": {
    "multi_match": {
      "query": "GPT3による質問応答システム",
      "fields": ["content", "title"],
      "operator": "or"
    }
  },
  "knn": [
    {
      "field": "vector.title",
      "k": 3,
      "num_candidates": "100",
      "query_vector_builder": {
        "text_embedding": {
          "model_id": "cl-tohoku__bert-base-japanese-v2",
          "model_text": "GPT3による質問応答システム"
        }
      }
    },
    {
      "field": "vector.content",
      "k": 3,
      "num_candidates": "100",
      "query_vector_builder": {
        "text_embedding": {
          "model_id": "cl-tohoku__bert-base-japanese-v2",
          "model_text": "GPT3による質問応答システム"
        }
      }
    }
  ]
}


以下のような結果が返ってきました。

順位 タイトル
1 GPT-3を使って根拠付きで正確に質問応答してくれるシステムを作ってみる
2 GPTが出した回答の確からしさを見えるようにしてみる
3 GPT-3を使って自分だけのAIアシスタントを作る第一歩
4 第49回Elasticsearch勉強会で、ElasticsearchによるNLP(質問応答)の発表をしてきました
5 Azure Container Instancesを使ってAngular+FastAPIなWebアプリを動かしてみた
6 Karateに性能試験とUI試験を任せてみる
7 NFLのPlayer Contact Detectionで金メダル獲得&コンペ振り返り
8 新しいデータ基盤アーキテクチャである「データレイクハウス」について調べてみた
9 Rustでトライ木による辞書検索のベンチマークをとってみた
10 特徴量エンジニアリングのライブラリ xfeat を使ってみて便利だったこと


初回の全文検索のみの検索結果と、knnによる検索を加えた後の検索結果を並べて比較してみましょう。
先ほどよりもGPT-3関連の記事がより上位に来ており、検索結果としては意図したものに近くなった印象があります。

順位 全文検索のみの場合 ベクトル検索を追加した場合
1 GPT-3を使って根拠付きで正確に質問応答してくれるシステムを作ってみる GPT-3を使って根拠付きで正確に質問応答してくれるシステムを作ってみる
2 GPTが出した回答の確からしさを見えるようにしてみる GPTが出した回答の確からしさを見えるようにしてみる
3 第49回Elasticsearch勉強会で、ElasticsearchによるNLP(質問応答)の発表をしてきました GPT-3を使って自分だけのAIアシスタントを作る第一歩
4 コンテナ内のアプリが複数種類のログを出力する場合の収集方法 第49回Elasticsearch勉強会で、ElasticsearchによるNLP(質問応答)の発表をしてきました
5 GPT-3を使って自分だけのAIアシスタントを作る第一歩 Azure Container Instancesを使ってAngular+FastAPIなWebアプリを動かしてみた
6 Azure Container Instancesを使ってAngular+FastAPIなWebアプリを動かしてみた Karateに性能試験とUI試験を任せてみる
7 Karateに性能試験とUI試験を任せてみる NFLのPlayer Contact Detectionで金メダル獲得&コンペ振り返り
8 新しいデータ基盤アーキテクチャである「データレイクハウス」について調べてみた 新しいデータ基盤アーキテクチャである「データレイクハウス」について調べてみた
9 特徴量エンジニアリングのライブラリ xfeat を使ってみて便利だったこと Rustでトライ木による辞書検索のベンチマークをとってみた
10 NFLのPlayer Contact Detectionで金メダル獲得&コンペ振り返り 特徴量エンジニアリングのライブラリ xfeat を使ってみて便利だったこと

3位までにGPT関連の記事がランクインするようになりました。
4位以降はある程度質問応答に関する内容が書いてあったり、下位の記事は「システム」といった一般的な単語によってスコアが上がっているものと思われます。
簡単な検証ではありますが、8.7の新機能を利用することで、より意図したものに近い検索結果を得ることができるようになりました。

最後に

いかがだったでしょうか?
今回ご紹介したセマンティック検索を用いれば、キーワードベースの検索だけではうまく類似度が取れないドキュメントも、上手くヒットさせることができるケースがありそうです。

言語モデルの発達は近年すさまじいスピードで進んでいます。
Elasticsearchの検索にも当たり前に取り込まれるようになる時代が来ていると思いますので、是非活用してみてください。
今回の記事は以上となります。最後までお読みいただきありがとうございました。


4/18追記:
本記事に関して第53回のElasticsearch勉強会で発表させていただくことになりました。ご興味ございましたら是非ご参加ください。
www.meetup.com


Acroquest Technologyでは、キャリア採用を行っています。


  • ディープラーニング等を使った自然言語/画像/音声/動画解析の研究開発
  • Elasticsearch等を使ったデータ収集/分析/可視化
  • マイクロサービス、DevOps、最新のOSSを利用する開発プロジェクト
  • 書籍・雑誌等の執筆や、社内外での技術の発信・共有によるエンジニアとしての成長

 
少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。

世界初のElastic認定エンジニアと一緒に働きたい人Wanted! - Acroquest Technology株式会社のデータサイエンティストの採用 - Wantedlywww.wantedly.com

Elastic Stack Advent Calendar 2022(2022年のElastic Search Platformを振り返る)

こんにちは、アクロクエストテクノロジー株式会社でElastic Stackのコンサルティング業務を担当している吉岡です。
本記事は、Elastic Stack (Elasticsearch) Advent Calendar 2022 の5日目の内容になります。

■Elastic Stackリリース概要

  • Elastic Stack Version 7.17.0リリース(2022年2月)
  • Elastic Stack Version 8.0.0リリース(2022年2月)
  • Elastic Stack Version 8.1.0リリース(2022年3月)
  • Elastic Stack Version 8.2.0リリース(2022年5月)
  • Elastic Stack Version 8.3.0リリース(2022年6月)
  • Elastic Stack Version 8.4.0リリース(2022年8月)
  • Elastic Stack Version 8.5.0リリース(2022年11月)


2022年1月時点での最新バージョンはVer.7.16.2、2022年12月5日時点での最新版はVer.8.5.2です。
待ちに待ったVer.8のリリースです。Ver.7.0.0がリリースされたのが2019年4月ですので、約3年振りのメジャーバージョンアップ!Ver.8.0.0リリース後、マイナーバージョンが5回上がっていますが、マイナーチェンジとは思えない多くの機能が盛り込まれています。

本ブログでは、Enterprise Search、Observablility、Elastic Security、3つのソリューションのコアとなる「Elastic Search Platform」の進化について紹介していきます。

■Elastic Search Platformとは

Elasticsearch、Kibana、Logstash、Beatsとう主要プロダクト群を以前はElastic Stackと呼んでいましたが、Ver.8.0あたりからElasticsearch、Kibana、Integrations(Logstash/Beats/Elastic Agent)という分け方になり、総称が「Elastic Search Platform」となりました。Elastic Stackと同様の意味に捉えてもらえればと思います。

Elastic Search Platformをまとめるとこのような感じです。

Elastic Search Platform

■Ver.7.17.0における進化ポイント

パフォーマンスの向上

  • インデックス設定の重複排除
    • Ver.7.16以前では、インデックスのSetting/Mapping情報は各インデックスに紐づいていたため、Setting/Mappingが全く同一だとしても、重複した情報全てをヒープに保持する非効率な仕様でした。特に、日/週/月などの単位でインデックスを集約する時系列データでは、インデックスが増加するほど、Setting/Mapping重複によるヒープ逼迫の影響が大きくなります。
    • Ver.7.17.0では、複数のインデックスに使用される同一のSetting/Mappingが1セットに削減されます。Elastic社の公式発表によると、Auditbeatのインデックスが10,000個あるとき、7.16以前ではヒープを約500MB消費するのに対して、Ver.7.17.0ではヒープ使用量が1MB(約500分の1)になるそうです。ノード間通信の量も削減されるため、クラスタのパフォーマンス向上につながります。

■Ver.8.0.0~Ver.8.5.0における進化ポイント

パフォーマンスの向上

  • インデックスサイズ
    • 圧縮率向上によりインデックスサイズが縮小(8.0.0)
    • 時系列メトリック データに最適な「時系列データ ストリーム (TSDS) 機能」がリリース。インデックスサイズを約30%削減(8.5.0)
  • ストレージサイズ
    • Doc value only field:ストレージサイズを20%以上削減(8.1.0)
  • インデクシング性能
    • ジオポイントのインデクシング性能が10~15%高速化(8.0.0)
    • Doc value only field:インデクシング性能を20%以上向上(8.1.0)
  • 検索性能
  • ヒープ使用量
    • リソース使用量を大幅に削減、データノードが保持可能なインデックス数が増加(8.3.0)

Ver.8.0.0以降、インデックスサイズ/ヒープ/ストレージの効率化に関する機能強化が多く、結果としてVer.7.Xと8.3以降で、10倍以上のシャードを保持できるようになっています。ぜひVer.8.3以降を使いましょう。

可視化/Kibana UI

  • Discover
    • フィールド統計機能が追加(8.0.0)
    • フィールド統計機能ジオデータに対応(8.2.0)
  • Lens
    • Gauge, Waffle, Mosaicが追加(8.1.0)
    • 新しいメトリックが追加(Tech Preview)(8.4.0)
    • 簡単にChoropleth Maps を作成可能に(8.2.0)
    • Annotation機能が追加(8.2.0)
    • クエリベースのAnnotation機能が追加(8.5.0)
  • Maps
    • Shapeファイルのアップロード機能を追加(8.1.0)
    • GeoServer不要でカスタムマップを利用可能に(8.1.0)
  • Dashboard
    • コントロール専用エリアが追加(8.3.0)
    • タイムスライダー機能が追加(8.5.0)
  • その他
    • フリートパッケージマネージャーから機械学習モデルやSecurityパッケージがインストール可能に(8.0.0)

Discoverが機能強化で使いやすくなりました。最初にフィールドの統計分析からデータ傾向を掴み、KQLを使ってドキュメント抽出/調査、その後必要に応じて異常値検知用のアラートを作成。このようなデータの基礎調査作業がDashboardを作ることなく可能です。

Search/ML/NLP

  • Search
    • 近似最近傍(ANN)検索機能(8.0.0)
  • ML管理機能
    • 機械学習モデル管理画面が追加(8.1.0)
    • 機械学習モデルをスペース単位で管理可能に(8.2.0)
    • 機械学習モデルのテスト画面が追加(8.2.0)
  • NLP
    • PyTorchモデルのインポートが可能に(8.0.0)
    • Fill-mask、固有表現抽出、テキスト分類、Embeddingに対応(8.0.0)
    • 質問応答(Question-Answering)に対応(8.3.0)

PyTorchモデルのインポートが可能になったことで、Elasticsearch単体で様々なデータ分析ができるようになりました。今後も様々なNLPタスクがサポートされるはずです。非常に楽しみですね。

ちなみに、現時点でのElasticsearchにおけるNLPの変遷をまとめると以下のようになります。

NLPの変遷

ログ分析/監視

  • Kibana Alert
    • スヌーズ機能が追加(8.2.0)
    • Discoverからアラートルールを作成可能に(8.3.0)
  • データのエンリッチ
    • Lookup Runtime Fieldのサポート(8.2.0)
    • クエリのタイミングでデータ結合が可能(リアルタイムエンリッチ)
    • Enrich Processorとルックアップデータ更新に対する追従が容易
  • AIOps
    • ログパターン解析機能が追加(8.5.0)
    • Log Rate Spike原因調査機能が追加(8.5.0)

これまで、Elasticsearch上でデータのエンリッチを行うにはEnrich Processorの一択でした。Enrich Processorはルックアップ先が固定の場合は向いていますが、頻繁にルックアップデータが更新されるようなユースケースでは、再ルックアップ(Update by Query + Pipeline指定)が必要で使い勝手が良くありません。その課題を解決するのが、Ver.8.2.0でリリースされたLookup Runtime Fieldです。Lookup Runtime Fieldはクエリタイムジョインなので、常に最新のルックアップデータをエンリッチ可能です。柔軟な可視化を行うのに非常に便利です。

まとめ

2022年のElastic Search Platformを振り返って、特徴的な機能強化/新機能をピックアップしてみましたが、その中でも、NLP関連の進化が個人的に興味深いですね。Ver.8.0以降、BERTなどのPyTorch機械学習モデルをElasticsearchでダイレクトに使用したり、モデルを使った推論をElasticsearch内でネイティブに実行することができるようになり、データのエンリッチや検索の幅が大きく広がっています。来年も目が離せませんね。

Elastic Stack

Acroquest Technologyでは、キャリア採用を行っています。

  • ディープラーニング等を使った自然言語/画像/音声/動画解析の研究開発
  • Elasticsearch等を使ったデータ収集/分析/可視化
  • マイクロサービス、DevOps、最新のOSSを利用する開発プロジェクト
  • 書籍・雑誌等の執筆や、社内外での技術の発信・共有によるエンジニアとしての成長

 
少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。

【データ分析】
Kaggle Grandmasterと一緒に働きたエンジニアWanted! - Acroquest Technology株式会社のデータサイエンティストの採用 - Wantedlywww.wantedly.com

第49回Elasticsearch勉強会で、ElasticsearchによるNLP(質問応答)の発表をしてきました

こんにちは、@shin0higuchiです😊
先日、第49回Elasticsearch勉強会を開催しました。

私からは、Elasticsearch 8.3 で実装された、PyTorchモデルによる質問応答機能を紹介しました。
発表のスライドはこちらです。

www.slideshare.net
以下、発表の内容について簡単に説明します。

概要

「質問応答」とは?

今回の発表のテーマである「質問応答」とは、機械学習タスクのひとつで、
一般に、利用者の質問に対して適切な回答を自動で返すことを指します。

活用先の例としては、チャットボットで製品に関する質問に回答させることなどが考えられます。
この場合、質問に対する回答は製品マニュアルに書いてあるはずですので、マニュアル内の適切な箇所を抜き出して回答するのが良いと言えます。
※チャットボットの口調などはまた別の話になるので、ここでは扱いません。

たとえばユーザが「ネットに繋がらない」という質問をしたときに、
「インターネットに繋がらない場合は機器背面のボタンを長押しして再起動をしてください」という回答を返せば適切と言えるでしょう。


Elasticsearchは、 7.6で教師あり機械学習を利用できるようになって以降、
PyTorchモデルのインポートが可能になるなど自然言語処理周りの機能追加が続いており、8.3で質問応答がサポートされた形です。


Elasticsearchで質問応答を実現する仕組みは下図のようなイメージです。
製品マニュアルのような大量のデータから、質問文に対する回答となる箇所を適切に抽出する内容となります。

学習済みモデルの取り込み

Elasticsearchに機械学習モデルをインポートするためには eland というPythonライブラリを利用します。
github.com

eland は次のコマンドで簡単にインストールすることができます。

python -m pip install eland


elandをインストールすると、eland_import_hub_model コマンドが使えるようになります。
HuggingFace社が、様々な学習済みモデルをダウンロード可能なプラットフォームを提供しており、
elandでは公開済みモデルのIDを指定するだけで簡単にElasticsearchに取り込むことが可能です。
huggingface.co

  • deepset/tinyroberta-squad2 というモデルを取り込む場合のコマンド例
eland_import_hub_model --cloud-id xxxx -u ml_import_user -p xxxx --hub-model-id deepset/tinyroberta-squad2 --task-type question_answering 

※ ml_import_user というユーザーで、インポートしています。適宜書き換えてください。

モデルの利用

モデルは、KibanaのUIから、もしくはElasticserchのAPIを通じて実行可能です。

たとえば、Inference API は、以下のような形で利用することができます。

curl -XPOST "http://<host>:9200/_ml/trained_models/question-answering-demo/_infer?timeout=60s&pretty" -H "Content-Type: application/json" -H "Authorization: ApiKey xxxxxxxx" -d'
{
  "inference_config": {
    "question_answering": {
      "question": "ネットに繋がらない"
    }
  },
  "docs": [
    {
      "text_field": "「スリープ設定」で設定した時間内に操作しないと液晶モニターが消灯します。いずれかのボタンを押すと、復帰します。\n        インターネットに繋がらない場合は機器背面のボタンを長押しして再起動をしてください。それでも繋がらない場合はサポートカウンターまでお問い合わせください。\n        暗い場所では、液晶モニターの明るさを維持するためにノイズが出ることがあります。印刷に影響はありません。\n        2枚以上の連続プリントまたは周囲温度が高いところでのプリントは時間がかかることがあります。\n        印刷時にプチプチという音がすることがありますが、インク・紙の走行によるものであり異常ではありません。\n        パソコンで作成したフォルダ名に特殊文字が入っている場合、そのフォルダ内の画像は表示できません。フォルダ名を変更してください。 "
    }
  ]
}'

レスポンスは以下のような形式で返ってきます。

{
  "inference_results" : [
    {
      "predicted_value" : " インターネットに繋がらない場合は機器背面のボタンを長押しして再起動をしてください",
      "start_offset" : 72,
      "end_offset" : 113,
      "prediction_probability" : 0.702419152359398672
    }
  ]
}


以上のように、質問と情報源を渡すことで、回答を得ることができます。
通常の全文検索とはまた異なる方向の情報検索が実現でき、活用の可能性を感じますね。

今回は学習済みのモデルをそのまま取り込んで利用しましたが、
日本語での精度を改善したい場合や、ドメイン特有の文脈を上手く扱いたい場合などは、
転移学習と呼ばれる手法で、既存モデルを自身のユースケースにフィットさせてください。

転移学習そのものの方法は、ここでは割愛しますが、
TorchScriptと呼ばれる形式に変換したモデルを、下記のように取り込むことが可能です。

import eland as ed
from elasticsearch import Elasticsearch
from eland.ml.pytorch import PyTorchModel

es = Elasticsearch("http://ml_admin:xxxxxxxx@<host>:9200")
ptm = PyTorchModel(es, 'question-answering-demo')
ptm.import_model(model_path='/path/to/model', config_path='/path/to/config', vocab_path='/path/to/vocabfile', config=config)

詳細は下記のリンクをご確認ください。
GitHub - elastic/eland: Python Client and Toolkit for DataFrames, Big Data, Machine Learning and ETL in Elasticsearch


今後の期待

今回紹介した機能は、実装されたばかりの機能なので今後の改善に期待したい箇所もあります。
たとえば、現状はモデル実行に多少時間がかかる場合があります。こちらは 8.4 で推論時のキャッシュ利用や、推論時のスレッド数を並列化する改善が入っているようなので、その効果に期待したいところです。
また、現状は情報源となるドキュメントをリクエストに含める必要がありますが、インデックス内のドキュメントをまとめて指定できるようになると実用性が飛躍的に上がりそうです。

今後 Elasticsearch における検索の幅をより一層広げてくれるであろう NLP機能、今後も目が離せませんね。


ということで今回の記事は以上になります。最後までお読みいただきありがとうございました。


Acroquest Technologyでは、キャリア採用を行っています。

  • ディープラーニング等を使った自然言語/画像/音声/動画解析の研究開発
  • Elasticsearch等を使ったデータ収集/分析/可視化
  • マイクロサービス、DevOps、最新のOSSを利用する開発プロジェクト
  • 書籍・雑誌等の執筆や、社内外での技術の発信・共有によるエンジニアとしての成長

 
少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。
Kaggle Grandmasterと一緒に働きたエンジニアWanted! - Acroquest Technology株式会社のデータサイエンティストの採用 - Wantedlywww.wantedly.com

ElasticON Global 2021 最速レポート2

こんにちは。Elastic認定エンジニアのノムラです。

今回の記事は以下の続きになります。
acro-engineer.hatenablog.com


Opening Keynoteの後、Keynoteで紹介された各ソリューションについて、詳細説明のセッションがありました。
そのセッションについてそれぞれ紹介します。

1.Elastic Observability: Unified, actionable, frictionless

Observabilityの発表では、Logs, Metrics, Insights それぞれに関して現在取り組んでいる内容の説明の後、
ad hoc analysis & machine learning」というデモがありしました。
アプリケーションがバックエンドに使っているDBの種別などに基づいて絞込みをおこなったり、ログメッセージをカテゴライズできるようになるという話は興味深かったです。

f:id:acro-engineer:20211007061535p:plain:w500

また、最近機能追加された Prometheus や OpenTelemetry への対応についても説明がありました。
f:id:acro-engineer:20211007062440p:plain:w500
f:id:acro-engineer:20211007062646p:plain:w500

OpenTelemetryなどの標準的な規格に対応することで、Observabilityのバックエンドとして、より汎用的にElastic Stack を利用可能になりましたね。

2.Elastic Security: Limitless XDR. Unbounded security

この発表では、

  • バージョン7.14でリリースされた Limitless XDR
  • Cmdとbuild.security がElasticに加わった話
  • 今後おこなわれるクラウドセキュリティの強化について

といった内容が中心に話されました。

2019年にEndgameを買収し、XDR (eXtended Detection and Reactions)に力を入れていており、そこがさらに強化されてきたような形です。その結果、エンドポイントでセキュリティ脅威を検出し、さらにそこへの対処までをおこなうことが可能になっています。

f:id:acro-engineer:20211007063609p:plain:w500

Limitless XDRは、SIEM・Endpoint Security・Cloud Security からなります。
今回は、今後導入される予定の Cloud Securityに関する話が特に印象的でした。
f:id:acro-engineer:20211007070430p:plain:w500


Endpoint Securityに関しては、発表の中で簡単なデモがありました。
組み込みの検出ルールによって脅威を発見してアラート、ホストをネットワークから切り離すところまでKibana上で完結しています。
f:id:acro-engineer:20211007064603p:plain:w500

また、Elastic AgentがOSQueryに対応したことで、
脅威の検出後に各エンドポイントでOSQueryを実行した結果を収集し、Kibanaで確認できるようになりました。素早く問題の特定をするのに役立ちますね。

さて、目玉となるCloud Securityについてですが、Elasticが今年8月に買収をおこなった2社から、
CmdのCSOである Jake King 氏と、build.securityのCEOであるAmit Kanfer 氏による発表+デモがありました。
Cmd社はeBPFを活用したクラウドにおける Runtime Securityを得意としており、build.securityは OPA(Open Policy Agent)によってクラウドインフラを管理するような内容に強みがあります。
これらの2社を取りこむことによって、セキュリティ基盤としてのElastic Stack がクラウドインフラに対しても大きな力を発揮できるようになるだろうと感じました。

f:id:acro-engineer:20211007070212p:plain:w500
f:id:acro-engineer:20211007070118p:plain:w500

この2社がElasticにジョインしたことについては、Elasticからブログ記事が出ていますので是非ご一読ください。
www.elastic.co

www.elastic.co

セキュリティの基盤として大きな躍進を遂げているというのが特に印象的でした。今後の動きも目が離せなさそうです。

3.Elastic Enterprise Search: Solve with speed, scale, and relevance, out of the box

Enterprise Searchでは以下のキャプチャのように、文書検索について手動/自動両方の調整機能がかなり開発されてきました。
その各機能の紹介とデモが主な内容でした。
f:id:acro_nomura:20211006225444p:plain:w500

その中で個人的には、Keynoteで紹介されたWeb Crowler以外ではRuntime Fieldを活用する、という話が面白かったです。
f:id:acro_nomura:20211006223343p:plain:w500

Runtime FieldはElasticStack7.11で登場した機能です。ひとまずデータをElasticsearchにインデキシングしておいて必要な時にRuntime Fieldを生成して Enterprise Searchで検索可能にする、という考え方のようです。
Runtime Fieldの再インデキシングが不要であるという利点を活かしているのが良いですね。

また機械学習を利用した検索機能の強化も非常に面白そうな内容でした。
f:id:acro_nomura:20211006224148p:plain:w500

これからは登録したドキュメントから学習して、自動で似た意味の単語や文章を判断してくれるようになる可能性がある、と思うと辞書整備の手間も減り非常に便利そうです。

まとめ

今年のKeynoteと各サービスのセッションから以下を感じました。
クラウド利用により世界中でサービスを簡単に展開可能となった
・Elastic Stackを活用することで簡易にあらゆるサービス/アプリケーションのデータを集め、横断的に検索・分析することができるようになった

実際にElasticStackを触り続けている身として、年々ElasticStackがより簡単に高度な検索/分析ができるようになっていると思います。
これからもどんどん強力になるElastic Stackを使いこなしていきたいです。

それでは。

Acroquest Technologyでは、キャリア採用を行っています。

  • ディープラーニング等を使った自然言語/画像/音声/動画解析の研究開発
  • Elasticsearch等を使ったデータ収集/分析/可視化
  • マイクロサービス、DevOps、最新のOSSを利用する開発プロジェクト
  • 書籍・雑誌等の執筆や、社内外での技術の発信・共有によるエンジニアとしての成長

 
少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。

世界初のElastic認定エンジニアと一緒に働きたい人Wanted! - Acroquest Technology株式会社のデータサイエンティストの求人 - Wantedlywww.wantedly.com

ElasticON Global 2021 最速レポート

こんにちは。Elastic認定エンジニアのノムラです😊

最初に個人的な話で恐縮ですが、今週「Elastic認定オブザバビリティエンジニア」の資格を取得したので、
以下3つの認定資格をコンプリートしました!
・Elastic認定エンジニア
・Elastic認定アナリスト
・Elastic認定オブザバビリティエンジニア

さて、本題です。
現在Elastic最大のイベントである、「ElasticON Global 2021」が 10/05~10/07で開催中です。
今年も去年に引き続きオンラインでの開催で、多くのセッションがあり盛り上がっています!

f:id:acro_nomura:20211006114948p:plain:w500

アジェンダ

全部で、100近いセッションがあります。
3日間の開催ですが、後半2日間は各地域のタイムゾーンに合わせて同一内容を再配信する形式になっています。

セッションの一覧は下記のURLから確認することができます。
www.elastic.co

今回は、Keynoteについて簡単に内容をご紹介します。

ElasticON Global Opening Keynote: Solving for innovation

Elastic社CPOであるAshutosh Kulkarni氏、Microsoft社のScott Guthrie氏、そしてElastic社CEOであるShay Banon氏による発表でした。

f:id:acro-shiroi:20211007001849p:plain:w500

Keynoteでは大きく以下について、話がありました。
①Azure等のクラウドプロバイダーとの連携について
②Observability、Enterprise Search、Securityの各ソリューションについて

Azure等のクラウドプロバイダーとの連携について

Elastic社は去年から今年にかけて、各クラウドプロバイダーと連携を強化しています。
現在では5つのクラウドプロバイダーを利用でき、リージョン数も40を超えています。
f:id:acro_nomura:20211006120703p:plain:w500

またクラウド上で非常に簡易にElasticStackを構築することが可能です。
今回のKeynoteではAzure上に構築するデモが紹介されていましたが、構築完了までほんの数クリックです。
f:id:acro_nomura:20211006124359p:plain:w500

仮想ネットワークとElastic Cloud を直接繋ぐPrivateLinkが利用可能となったほか、最新版である7.15では通信コストが以前から50%~70%抑えられるようになっているそうです。
f:id:acro_nomura:20211006131429p:plain:w500

Observability、Enterprise Search、Securityの各ソリューションについて

次に各ソリューションについて最新版ではどのようなことが可能なのか紹介がありました。

その中でもEnterprise SearchのWeb Crowlerは一押しの便利機能です。
デモでは画面から簡単にElastic社のブログをクロール/インデキシングして検索可能とするデモを紹介。
f:id:acro_nomura:20211006214538p:plain:w500

また以下のスライドの通り、Enterprise Searchでは様々なサービスのメッセージやファイルをインデキシングして検索可能です。
企業内検索を簡易に実現できるのは嬉しいですね。
f:id:acro_nomura:20211006214010p:plain:w500

Securityでは Limitless XDR として、エンドポイント検知や対処が強化されました。
特にクラウドセキュリティは注目すべき部分だと思います。
Elastic Stackという単一のプラットフォームで「SIEM」「エンドポイントセキュリティ」「XDR」の機能をフル活用できるのは
非常に魅力的だと感じました。
f:id:acro_nomura:20211007003807p:plain:w500

次の記事ではKeynote以外のセッションについて紹介予定です。お楽しみに!

Acroquest Technologyでは、キャリア採用を行っています。

  • ディープラーニング等を使った自然言語/画像/音声/動画解析の研究開発
  • Elasticsearch等を使ったデータ収集/分析/可視化
  • マイクロサービス、DevOps、最新のOSSを利用する開発プロジェクト
  • 書籍・雑誌等の執筆や、社内外での技術の発信・共有によるエンジニアとしての成長

 
少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。

世界初のElastic認定エンジニアと一緒に働きたい人Wanted! - Acroquest Technology株式会社のデータサイエンティストの求人 - Wantedlywww.wantedly.com

第40回 Elasticsearch勉強会で「Searchable Snapshot」について発表しました

こんにちは、@shin0higuchiです😊

昨日は 第40回となる、Elasticsearch勉強会がオンライン開催されました。
www.meetup.com

開催概要(Meetupイベントページより抜粋)

===============================================
■開催日時
2/25(木)19:30~21:00
■内容
登壇
1.株式会社ZOZOテクノロジーズ 有村和真さん
ZOZOTOWNとElasticsearch(ElasticCloud)のこれまで/これから」

2.Acroquest 樋口慎さん
「Searchable Snapshotでコスト削減」

3.Elastic社 鈴木章太郎さん
「Elastic Stack & Cloud 7.11 Technical Enablement ダイジェスト版」

===============================================

「Searchable Snapshotでコスト削減」の内容

今回私が発表した内容を簡単に紹介します。
詳細はこちらの発表資料をご覧ください。

www2.slideshare.net

今回のバージョンでGAとなった「Searchable Snapshot」に関する発表でした。
Searchable Snapshotとは、クラウドストレージなどに置いたSnapshotを、Elasticsearchにマウントして検索できるようにする機能です。
従来であればノード障害に備えてレプリカシャードを保持する必要があったケースでも、
Searchable Snapshotを利用すればプライマリシャードのみ持てば良いので、最大50%のストレージ削減が可能です。
結果としてコストの削減や、シャード数が減ることによるヒープ使用低減が期待できます。
f:id:shin0higuchi:20210225220209p:plain:w400
f:id:shin0higuchi:20210225215933p:plain:w400


使い方としては、Snapshotを従来通り取得し、Mount Snapshot API を利用して検索可能状態にします。
マウントする際に、SnapshotのファイルがElasticsearchのローカルにコピーされるため、検索のたびにSnapshotにアクセスすることはありません。
(つまりパフォーマンスの大きな劣化がない、クラウドストレージからの読み出しコストが抑えられる)

POST _snapshot/fs_backup/my_snapshot/_mount
{
  "index": "kibana_sample_data_logs",
  "renamed_index": "kibana_sample_data_logs_snapshot",
  "index_settings":{
    "index.number_of_replicas":0
  },
  "ignored_index_settings": ["index.refresh_interval"]
}

www.elastic.co

また、Index Lifecycle Management からも制御ができるので、
時系列データのライフサイクルに組み込むのは定石になりそうな予感です。
f:id:shin0higuchi:20210225220654p:plain:w600

次のマイナーバージョンである 7.12 では、
Snapshotのうち、検索に必要なメタデータのみをローカルにコピーするオプションも利用可能になる予定で、
ますますストレージを効率的に使うことができるようになりそうです。
リリースが今から楽しみですね。

さいごに

勉強会全体の動画アーカイブYoutubeにて公開される予定ですので、
興味があれば是非ご覧ください。

お読みいただきありがとうございました。
それでは。

Acroquest Technologyでは、キャリア採用を行っています。

  • ディープラーニング等を使った自然言語/画像/音声/動画解析の研究開発
  • Elasticsearch等を使ったデータ収集/分析/可視化
  • マイクロサービス、DevOps、最新のOSSを利用する開発プロジェクト
  • 書籍・雑誌等の執筆や、社内外での技術の発信・共有によるエンジニアとしての成長

 
少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。

【データ分析】
Kaggle Masterと働きたい尖ったエンジニアWanted! - Acroquest Technology株式会社のデータサイエンティストの求人 - Wantedlywww.wantedly.com

Ver.7.11からElasticsearchのスキーマ設計が大きく変わる

こんにちは、アクロクエストテクノロジー株式会社でElastic Stackのコンサルティング業務を担当している吉岡です。本記事は、Elastic Stack (Elasticsearch) Advent Calendar 2020 の14日目の内容になります。

本記事では、2020/10/13~2020/10/15に開催されたElastic ON Globalで、個人的に最もエキサイティングに感じたセッション「Schema on read with runtime fields」を紹介します。

Elastic ON Global
www.elastic.co

Schema on read with runtime fields

セッション概要

Elasticsearch has always been fast, but required structuring and indexing your data up front. We're changing that with the introduction of runtime fields, which enable you to extract, calculate, and transform fields at query time. They can be defined after data is indexed or provided with your query, enabling new cost/storage/performance tradeoffs, and letting analysts gradually define fields over time.

  • 発表動画

www.elastic.co

  • 発表資料

www2.slideshare.net

セッションを読み解くための重要キーワード

Schema on Write と Schema on Read

  • Schema on Write と Schema on Readの詳細にについては以下のブログが参考になります。

www.elastic.co

Runtime Field

これまで、Elasticsearchは主に「Schema on Write」のアプローチを採用してきました。検索/分析要件を先に決めて、Mappingを書いてからデータを投入する。スキーマレスと言いながら、最適な性能を得るには「Schema on Write」が必須でした。
Elasticsearch Ver.7.11から「Runtime Field」というデータ型が導入されます。一言で言うと、クエリ時にスクリプト(データ加工/抽出)を実行できるデータ型。スクリプトはMappingに記述(事前に定義)することも、クエリ自体に指定(実行時に定義)することも可能です。この「Runtime Field」と「非同期検索(Ver.7.7~)」を併用することで「Schema on Read」のユースケースが実現可能になります。

発表資料に関するコメント

以降はセッションの発表資料を抜粋しながらコメントしたいと思います。

f:id:acro-engineer:20201213182153p:plain:w800

  • Schema on Write と Schema on Readの比較です。
  • 左が従来の「Schema on Write」アプローチ。インデクシングする際にデータ加工を行うことで高速なクエリ/アグリゲーションを実現します。
  • 右が新しくサポートする「Schema on Read」アプローチ。インデクシング時にデータ加工をせず、ほぼ生データをロードする形になるためインデクシングは高速です。データ加工は必要に応じてクエリ毎に指定すればOK。これは、投入するデータの詳細がよく分かっておらず、事前のスキーマ(Mapping)作成が困難なシーンで特に有効です。

f:id:acro-engineer:20201213182208p:plain:w800

  • Runtimeフィールドを利用した場合「Schema on Write」と比較してインデックスサイズ(消費ストレージ)は小さく、インデクシングは高速になります。ただし、クエリの速度は大きく下がります。(クエリ時にデータ加工するので当然です)

f:id:acro-engineer:20201213182220p:plain:w800

f:id:acro-engineer:20201213182229p:plain:w800

  • Async search(非同期検索)での利用例。Rangeクエリで時間範囲を指定し、statusが「200」のドキュメントを検索しています。
  • Rangeクエリでヒットする全ドキュメントに対して「Mappingのstatusフィールドに定義されたスクリプトを実行し動的にstatusの値を生成、statusが200のドキュメントに絞り込むクエリ。Schema on Writeアプローチでの時間感覚(検索は100ms以下が当たり前)からするとスロークエリそのものです。
  • しかし、Schema on Readのユースケースはクエリの実行頻度が少ないシーンを想定しているので、非同期検索(デフォルトのタイムアウトは5日)でゆるやかに実行する形です。逆に、検索速度を求めるシーンでは、Runtimeフィールドではなく、通常のフィールドをSchema on Writeで使いましょう。

f:id:acro-engineer:20201213182242p:plain:w800

  • クエリ時にスクリプトを定義する場合のサンプル。「runtime_mappings」というパラメータに、ipフィールドを生成するスクリプトを記述しています。
  • MappingにRuntimeフィールドを定義していなくても、クエリで動的にフィールドを生成することができるのは非常に便利ですね。Schema on Writeではスキーマ設計/変更を管理者に集約する運用になると思いますが、Schema on Readでは各ユーザーがクエリを通して自由にスキーマ設計できることになります。


f:id:acro-engineer:20201213182256p:plain:w800

  • 将来的にはPainless以外にもGrokやその他のエンリッチをサポートするようです。

f:id:acro-engineer:20201213182327p:plain:w800

  • Schema on Readにおけるフィールドライフサイクルは以下のようになります。
    1. インデクシング時に@timestampだけを抽出し、時刻以外をmessageフィールドに入れておく。
    2. データを抽出したい時にクエリに抽出スクリプトを記述し、必要なデータ取得する(Mappingの変更が不要)。Schema on Writeでデータ加工をしようとすると、その都度Reindexが必要ですが、Schema on Readでは、データ加工の試行錯誤をするのにReindexが不要です。
    3. 頻繁に利用するフィールドは、通常のフィールド(Indexed Field)に移行する。具体的には、インデックステンプレートにIndexed Fieldを追加、次に生成される(日単位インデックスであれば翌日、月単位インデックスであれば翌月)インデックスからはSchema on Write用フィールドになります。

f:id:acro-engineer:20201213182340p:plain:w800

  • 通常の検索(左)と非同期検索(右)の仕様の比較。非同期検索は長時間かかるクエリを実行するもので、クエリが完了する前でも、途中までの検索結果を取得することが可能です。

f:id:acro-engineer:20201213182359p:plain:w800

  • まとめを意訳。
  • Schema on Readの導入により、Elasticsearchのスキーマ設計が大きく変わります。従来のように一気にスキーマを完成させてからデータ投入するのではなく、スキーマを大雑把に決めてデータ投入をしてしまい、必要に応じてフィールドを作成し、徐々にスキーマを確定していくことになります。また各フィールドは、検索、可視化、アドホックな調査、バッチ処理など、コンテキスト毎に設計するのが主流になるでしょう。

Acroquest Technologyでは、キャリア採用を行っています。

  • ディープラーニング等を使った自然言語/画像/音声/動画解析の研究開発
  • Elasticsearch等を使ったデータ収集/分析/可視化
  • マイクロサービス、DevOps、最新のOSSを利用する開発プロジェクト
  • 書籍・雑誌等の執筆や、社内外での技術の発信・共有によるエンジニアとしての成長

 
少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。

【データ分析】
Kaggle Masterと働きたい尖ったエンジニアWanted! - Acroquest Technology株式会社のデータサイエンティストの求人 - Wantedlywww.wantedly.com