YAMALEX が第３回 AI 王に参加しました

アクロクエスト アドベントカレンダー 12月7日 の記事です。

こんにちは、機械学習チーム YAMALEX メンバの駿です。

この度、東北大学、理化学研究所が主催する「 AI 王～クイズ AI 日本一決定戦～第３回コンペティション」（以下、AI王）に YAMALEX として参加しました。
初めて参加するコンペで、結果としては入賞できませんでしたが、今回は参加した感想をお伝えします。

技術的な詳細はこちらのスライドにまとまっているので、併せてごらんください。

speakerdeck.com

YAMALEX とは

YAMALEX とは2022年夏に Acro 社内で発足した、 会社の未来の技術を創る、データサイエンスチーム です。
Kaggle Grandmaster の山本を中心に、若手のデータサイエンティスト5人がメンバーです。

最先端技術の調査、実証を通し、会社としてのデータ分析事業の方向性を示すと同時に先端を切り開くデータサイエンティストになることを目指して活動しています。

YAMALEX についてもっと知りたい方はこちらの記事もご覧ください。

コンペ最終日の YAMALEX メンバ MTG

AI 王とは

AI王とは、日本の質問応答研究を推進させることを目的として、クイズ問題を題材とした質疑応答データセットを用いて、より正確に答えを出すことができるモデルを作成するコンペティションです。

AI王 ロゴ

2020年の第１回から毎年行われており、今回が第３回となります。

第１回は20個の選択肢の中からクイズの回答を選択するものでしたが、第２回からは自由回答になっていて、 回を重ねるごとに難易度が上がっています。
そんな中、 YAMALEX として AI 王となるため、挑戦を決めました。

参加のモチベーション

1. QA の経験を積みたい

   QA システム自体は、チームメンバがほぼ扱ったことが無かったので このコンペを知った際に、チャレンジしたくなった（今回、初参加です）。

2. 日本語の NLP コンペに参加したい

   Kaggle などには参加したことはあるが、問題のほとんどが英語の文章なので 日本のコンペにチームとして出たかった。

3. チームでまとまってコンペに参加してみたい

   YAMALEX チームはまだ個人参加はあれど、チームでコンペに取り組んだ ことがなかったので、チームで取り組んでみたかった。

スケジュール

時期	概要	内容
ある10月末頃	AI 王へのチャレンジが始動する	とあるチームメンバが唐突に本格的に AI 王をやりたいと発言したところから、私たち YAMALEX チーム５人の挑戦は始まりました。
～11月7日	作戦を立てる	既存ベンチマークの動作確認と昨年度のソリューションを読んで作戦を立てて、分担を決めました。 役割は、 Retriever （ BPR/DPR ） ／ FiD ／外部データセット取得で、3人、1人、1人ほどです。 Retriever が最もやることが多かったのでその部分に人を多めに担当してもらうようになりました。
～11月14日頃	チーム毎に作業を進める	チームに分かれて以下に取り組んでいました。 QA に取り組んだメンバがいないため勘所が分からないこともあり、一つ一つ、影響のあるパラメータや手法を考えて確認をしていました。 外部データセットの取得・実験 モデルのパラメータチューニング作業 機械学習モデルとは別に Elasticsearch を使ったテキスト検索を Retriever に導入
11月18日頃	外部データを追加する	計算時間が膨大になる Wikipedia のデータを新たに追加する解法を取り入れました。 Dev/Test 間の LB での相関が取れなくなり思うようにスコアが伸びず、頭を抱えるようになったのはこの頃です。
リーダーボード 締切直前	アンサンブルを導入する	複数のモデルを計算する時間が厳しい中、シンプルな Voting を行うアンサンブルを試みました。 アンサンブルのバリエーションもいくつかあると思いますが、この部分は詰め切れませんでした。 最終提出は LB 最高スコアに届きませんが、このアンサンブルした結果にしています。 Dev/Test で相関が取れていないことから問題傾向によるブレがあると予測し、安定した結果を出すためにシンプルな Voting を行うアンサンブルが妥当だといった判断です。
11月23日	リーダーボード提出締切	テストデータでのスコアの確認、他チームの進捗確認がこれ以降できなくなる。
リーダーボード 締切後	Dockerfileを作成する	リーダーボードへの提出が締め切られ、システムの最終提出のみとなってからは、 Dockerfile の作成に追われていました。 提出のために不要なファイルを消すなど試行錯誤をしていました。
11月26日	システム最終提出締切	本当に最後の締め切り。ここで提出した Docker イメージを使って未知の問題を解き、スコアと順位が確定する。

感想

1. チームとして話し合いながら進めるのが楽しい！

   私はあまり NLP が得意ではないのですが、モデル改良に向けてチームでの話し合いに参加しました。

   その中で、クイズを見ながら「こういう問題にはこういうアプローチをしたい」や「これができると精度上がらないですか」 などの意見を出して、できそう／できなそうを議論することができました。

   人がクイズを答えるときにやっていることと同様にやろうとすると、 複数モデルを用意して、問題文から適切なモデルを選択しないといけず、 複雑かつ巨大になってしまうことなども分かり、興味深かったです。
   例：ですが問題は「ですが」の前と後の対比をできるモデルがあれば強いが、他の問題に対しては全く使い物にならない。

   締め切りまじかになると、普段の生活では味わえない、ひりひり感を会話から感じる事ができました。

2. NLP 分野の知識が広がった！

   AI 王では主催者がベースラインのモデルを提供しており、初心者でも環境があれば動かせる状態から始めることができました。

   また、ベースラインを動かして各機能の入出力や中のコードを見ることで、 QA タスクのアプローチを知ることができました。
   一つのやり方を学ぶことができたため、別の機会に別のモデルを見たときには、 今回のモデルと比較することで、どんなことをやっているかが分かりやすくなると思います。

3. スコアが上がっていくのを見るのが楽しい！

   これはコンペティションなら言わずもがなですね。

   下の図はリーダーボードスコア（LB Score）といって、提出回数ごとに、AIによる質疑応答のスコアの遷移を表しています。
   当社のデータだけを示していますが、コンペ開催中は、リーダーボードに各チームの暫定スコアと順位が表示されており、 上の人のスコアに徐々に近づいて追い抜いていく、逆に追い越されるなど、 他チームとの駆け引きも面白いポイントでした。

   

   今回コンペのYAMALEXチームスコアの遷移

まとめ

今回は AI 王に参加した感想を書いてみました。

残念ながら、初参加で入賞！とはいきませんでしたが、確実に YAMALEX チームとしての強さとチームワークは上がったと思います。 この経験を糧に次の挑戦をしていきます。

開催していただいた運営の方々、ありがとうございました！

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

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

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

モデル最適化ソフトウェアOpenVINOを用いた性能高速化とモデル比較の実験

皆さんこんにちは。
@tereka114です。

モデル最適化の選択肢の一つであるOpenVINOを試してみました。
モデル最適化とは、モデルの精度を殆ど落とさず、高速化する技術で、以下のような恩恵が得られることが知られています。

①特にGPU等を利用できない、RasberryPiのようなエッジデバイス上で機械学習モデルを動かすケースで性能を上げられる
②モデル最適化のエンジンが動く環境であれば、一度構築したモデルを複数の環境で実行させることができる

今回、その技術の一つであるOpenVINOとそれを用いた有名なモデルのベンチマークを紹介します。

OpenVINO

Intel社が開発したディープラーニングを高速に実行するためのソフトウェアです。
OpenVINOが学習済のモデルをハードウェアに合わせて最適化し、CPU、GPUなどのアクセラレータで高速で推論できるようにします。

www.intel.com

本記事では、インストールに関して詳細を扱いません。
インストール方法は次のリンク先を参考にしてください。

docs.openvino.ai

PyTorchからOpenVINOを動かす

PyTorchは実装のしやすさとPyTorch Image Models（timmライブラリ）を利用した学習モデルの多様性から私も含め、多くのデータサイエンティストが利用しています。
そのため、今回は、PyTorchで作られたモデルからOpenVINOを動かしてみます。

github.com

OpenVINOを利用する手順

PyTorchのモデルをOpenVINO形式に変換するには次のステップが必要になります。

1. PyTorchのモデルからONNX形式に変換する。
2. ONNXからOpenVINO形式に変換する。
3. OpenVINOモデルで推論する。

モデル変換・推論の流れ

PyTorchのモデルをONNXに変換する。

OpenVINOはPyTorchのモデルを直接変換できないため、まずはONNXに変換します。
PyTorchにONNX変換を行う関数が用意されているため、その関数を利用します。
ここで、モデルはevalを呼び出して推論モードにしておくことが必要です。
なぜならば、推論時の最適化を行う必要があるためDropoutやBatch Normalizationなど学習、推論で挙動が変わるものでは、期待する計算ができなくなります。

また、SwinTransformerには、ONNXに備わっていない演算があるため、その関数を外部からONNXに登録（roll関数）しています。

import torch
import torch.onnx as torch_onnx
import timm
import argparse
import torch
from torch.onnx.symbolic_helper import parse_args, _slice_helper
from sys import maxsize as maxsize


@parse_args('v', 'is', 'is')
def roll(g, input, shifts, dims):
    # Swin Transformerの計算に必要なOperatorを定義
    assert len(shifts) == len(dims)
    result = input
    for i in range(len(shifts)):
        shapes = []
        shape = _slice_helper(g, result, axes=[dims[i]], starts=[-shifts[i]], ends=[maxsize])
        shapes.append(shape)
        shape = _slice_helper(g, result, axes=[dims[i]], starts=[0], ends=[-shifts[i]])
        shapes.append(shape)
        result = g.op("Concat", *shapes, axis_i=dims[i])
    return result

parser = argparse.ArgumentParser()
parser.add_argument("--model")
parser.add_argument("--output")
parser.add_argument("--size", type=int)

args = parser.parse_args()

# モデルの読み込み
torch.onnx.symbolic_registry.register_op('roll', roll, '', version=9)
net = timm.create_model(args.model, pretrained=True)
net.eval()
# モデル出力のための設定
model_onnx_path = args.output # 出力するモデルのファイル名
input_names = ["input"] # データを入力する際の名称
output_names = ["output"] # 出力データを取り出す際の名称

# ダミーインプットの作成
input_shape = (3, args.size, args.size) # 入力データの形式
batch_size = 1 # 入力データのバッチサイズ
dummy_input = torch.randn(batch_size, *input_shape) # ダミーインプット生成

# 変換実行
if "swin" in args.model:
    # Swin Transformer用に、ONNXのOpsetを固定
    output = torch_onnx.export(
        net, dummy_input, model_onnx_path,export_params=True, 
        verbose=False, input_names=input_names, output_names=output_names, opset_version=11)
else:
    output = torch_onnx.export(
        net, dummy_input, model_onnx_path,export_params=True, 
        verbose=False, input_names=input_names, output_names=output_names)

この実装を次のコマンドで動かします。

python pytorch_to_onnx.py --model resnet50 --output resnet50.onnx --size 224

ONNXからOpenVINO形式に変換する。

ONNXからOpenVINOへの変換はOpenVINOのモデル最適化コマンドを実行するのみです。
前段のResNet50のモデルを利用して、変換する場合は以下のコマンドです。

python /opt/intel/openvino_2021/deployment_tools/model_optimizer/mo.py --input_model resnet50.onnx

OpenVINOモデルで推論する。

最後にOpenVINOを動作させます。
事前に以下のコマンドでOpenVINOのPythonモジュールをインストールします。

pip install openvino

以下、先程までコンパイルしたモデルの推論の実装です。
PyTorch、ONNX、OpenVINOの推論速度を比較する実装も含まれています

import numpy as np
import time as tm
import timm

import torch
import onnxruntime
from openvino.inference_engine import IECore

import argparse

parser = argparse.ArgumentParser()
parser.add_argument("--model")
parser.add_argument("--output")
parser.add_argument("--size", type=int)

args = parser.parse_args()
SIZE = int(args.size)

# Pytorchの準備
net = timm.create_model(args.model, pretrained=True)
net.eval()
# ONNXの準備
session = onnxruntime.InferenceSession(f"{args.output}.onnx")

# OpenVINOの準備
ie = IECore()
model_path = f'{args.output}.xml'
weight_path = f'{args.output}.bin'
net_openvino = ie.read_network(model=model_path, weights=weight_path)
exec_net = ie.load_network(network=net_openvino, device_name='CPU', num_requests=1)

# 時間計測用
time_onnx = 0
time_openvino = 0
time_pytorch = 0

# 予測結果比較用
out_onnx = []
out_pytorch = []
out_openvino = []

TIMES = 300
for i in range(TIMES):
    image = torch.rand(1, 3, SIZE, SIZE)
    with torch.no_grad():
        start_time = tm.time()
        out = net(image)
        out_pytorch.append(np.argmax(out[0]))
        time_pytorch += tm.time() - start_time

    start_time = tm.time()
    preds = session.run(["output"], {"input": image.cpu().numpy()})
    out_onnx.append(np.argmax(preds[0]))
    time_onnx += tm.time() - start_time

    start_time = tm.time()
    outputs = exec_net.infer(inputs={'input': image.cpu().numpy()})['output']
    out_openvino.append(np.argmax(outputs[0]))
    time_openvino += tm.time() - start_time

# 推論結果の整合性確認のため
print(np.sum(np.array(out_pytorch) == np.array(out_openvino)))
print(np.sum(np.array(out_pytorch) == np.array(out_onnx)))
print(np.sum(np.array(out_onnx) == np.array(out_openvino)))

# 計算結果
print('PyTorch: ', time_pytorch / TIMES)
print('ONNX: ', time_onnx / TIMES)
print('Open VINO: ', time_openvino / TIMES)

実行は次のコマンドです。

python infer.py --size 224 --model resnet50--output resnet50

性能実験

OpenVINOを利用すればどの程度高速化されるのか
画像認識の有名なモデルと先程の実装を用いて、性能を比較しました。

計測環境

• Mac OS Big Sur
• Apple M1
• メモリ16GB

現在一般的に利用されるモデルを中心に計測しました。
モデルの精度・性能の目安はPyTorchのモデル実装の宝庫であるtimmライブラリのリンクをご確認ください。

github.com

結果は次のとおりです。PyTorch(s),ONNX(s),OpenVINO(s)は1枚あたりの推論速度を示しています。
PyTorchと比較して、30-70%ほどの高速化を達成し、また、ONNXよりもほとんどの場合で高速化を達成できました。
また、本方式では、最終的な推論結果は変わりませんでした。

Model	Image Size	PyTorch(s)	ONNX(s)	OpenVINO(s)	高速化率(Pytorch)	高速化率(ONNX)
resnet50	224	0.271	0.137	0.112	58.67%	18.25%
resnet152	224	0.795	0.409	0.332	58.24%	18.83%
convnext_tiny	224	0.324	0.201	0.182	43.83%	9.45%
swin_tiny_patch4_window7_224	224	0.317	0.135	0.184	41.96%	-36.30%
mobilenetv2_120d	224	0.065	0.031	0.028	56.92%	9.68%
mobilenetv3_large_100_miil	224	0.03	0.014	0.019	36.67%	-35.71%
vit_tiny_patch16_224	224	0.088	0.053	0.057	35.23%	-7.55%
vgg16	224	1.09	0.31	0.275	74.77%	11.29%
vgg19	224	1.309	0.388	0.339	74.10%	12.63%
tf_efficientnet_b0_ns	224	0.054	0.024	0.024	55.56%	0.00%
tf_efficientnet_b7_ns	224	0.448	0.216	0.18	59.82%	16.67%

モデル最適化

棒グラフはPyTorch(s)、ONNX(s)、OpenVINO(s)の値を表示しており、低い値であればよりよい性能であることを示しています。

最後に

CPUで処理を行った場合、OpenVINOの結果が最も早い場合が多かったです。
IoTデバイス上で動作させた場合に少し性能に満足できない場合にOpenVINOを適用すると良いかもしれません。
推論性能に困った場合の選択肢の一つに入れると良いと思います。

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

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

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

AWSでお手軽時系列データの異常検知 ~Lookout for Metricsを試してみた~

はじめに

機械学習アプリケーションエンジニアの@yktmです。
本記事では、2020年12月のAWS re:Inventでアナウンスされ、2021年3月にGAとなった、
Amazon Lookout for Metricsを、実際に利用してみて、使い勝手を確認してみたいと思います。

Amazon Lookout for Metricsの特徴、実際の使い方をお伝えできればと思います。

Amazon Lookout for Metricsとは

概要

Amazon Lookout for Metricsは、機械学習を使った時系列データ分析を、機械学習の知識なしに簡単に始められるサービスです。

例えば、ECサイトのトラフィックに発生した異常な外れ値を検知し、アラートを出す、という仕組みを簡単に構築することができます。

特徴

Lookout for Metricsの大きな特徴は、3つあります。

機械学習による分析

Lookout for Metricsは機械学習に基づく分析を、機械学習の知識なしに使える点が最大の特徴です。

柔軟なデータ連携

分析対象とするデータは、S3、RDSなどのAWS関連サービスのほかに、
SalesforceやGoogle Analytics、Zendeskなどからシームレスに接続できます。

アラートのカスタマイズ性

Amazon SNS、AWS Lambdaはもちろん、Slack、Datadog、WebHookなどに対しても、
カスタマイズしたアラートを送信することができます。

分析としては、複数のパラメーターの関連を見た異常検知や、複数項目を同時に異常検知することも可能な点が嬉しい点です。
例えば、地域と時間帯から店舗収益の異常を検知したり、アクセス数と収益を同時に異常検知する、といったことができます。

Amazon Lookout for Metricsを使った分析

次に、Lookout for Metricsを使い、いかに手軽に分析できるかを見ていきたいと思います。

検証データセット

利用するデータセットは、AWS公式Githubで提供されているE-Commerceのサンプルデータを利用していきます。 zipファイルダウンロード・解凍し、backtest/input.csvが利用するファイルです。

CSVの中身は、プラットフォームと利用国ごとの、閲覧数・収益を1時間おきに記録した履歴データになります。 期間は、2021/01/01から2021/09/30までです。

カラムは以下の5つとなっています。

カラム名	説明
platform	利用デバイスと利用媒体 (pc_web, mobile_web, mobile_appの3パターン)
marketplace	利用国 (us, uk, de, fr, es, it, jpの7パターン)
timestamp	タイムスタンプ
views	閲覧数
revenue	収益

このデータから、閲覧数と収益の異常を見つけ、どのプラットフォーム・利用国で、何時に異常が発生したかを分析していきたいと思います。

設定手順

以下の順に設定していきます。
1. Detector(分析器)の作成
2. データセットを作成 / Detectorの有効化
3. 分析結果の確認
4. アラート設定

1. Detector(分析器)を作成

AWS コンソールで、Amazon Lookout for Metricsを開きます。 Create Detectorを押下し、分析器の作成画面を開きます。

分析器の作成画面では、
①分析器の名前
②分析のインターバル
を設定します。

分析のインターバルとは、分析の細かさを示します。 ここでは、1 hourを指定しています。
1 dayにすれば1日単位で粗く分析でき、10 minuteにすれば10分単位の細かい分析が可能になります。
後述しますが、与えられたデータを学習用とテスト用に分けて検証するBacktestモードでは、interval x 285(1dayなら285日分)のデータが必要になる点は注意が必要です。 分析のインターバルによって、利用料金が変動することはありません。(コストについては記事後半で解説しています。)

設定が完了したら、「Create」を押します。

2. データセットを作成 / Detectorの有効化

続いて、データセットを作成します。ここで設定するのは、2つの項目です。
① 分析対象のデータソース
② 分析対象のフィールド

まず始めに、「Add a dataset」からデータセット作成画面を開きます。

データセット作成画面は、以下のようになっています。

設定が必要な項目は、
①データセットの名前
②分析対象データソースの指定
③分析対象データソースのフォーマット設定
④認証情報
です。

ここでは、Amazon S3上のCSVファイルを分析対象データソースとしています。

また、分析のモードが2つ選択できます。 モードの違いによる、コストのかかり方に違いはありません。

モード	説明	用途
Backtest	指定したデータを学習用と検証用に分割して検証を行う。 古い70％が学習に利用され、最新の残り30％をバックテストで利用（※interval x 285 のデータが必要になる。）	検証
Continuous	新しく取り込まれるデータを利用し、推論精度を向上させていく。	運用

続いて、分析対象のフィールドを設定します。

「Measure」で指定するのは、異常を検知する対象のフィールドです。 「Demensions」で指定するのは、Measureをどのフィールドでカテゴライズするか、というものです。 例えば、プラットフォーム毎の閲覧数を見たい場合、「Measure」に「views(閲覧数)」を、「Demensions」に「platform(利用デバイス/利用媒体 )」を指定します。

最後にTimestamp情報がどういった形式で表されているかを指定します。

「Next」を押すと、設定情報確認画面が出てきます。

「Save and active」を押すと、データセットが作成され、分析が始まります。

3. 分析結果の確認

「View annomalies」から異常を確認してみましょう。

発生した異常は、以下のようにリストで表示されます。

このリストは、どのメトリクスに、何時に異常が発生したかのリストです。 「Severity score」でソートすれば、異常度の大きさで並び替えできます す。「Time detected」でソートすれば、異常が発生した時間でソートできます。

そのうちの一つを開くと、以下のような画面になります。

Anomaly overviewを見ると、2021/09/04 00:00(GMT時間)に発生した異常の詳細であることがわかります。

続いて、Dimension valuesを確認します。 Dimension valuesは、検知した異常に対し、どのDimensionの影響が大きかを表しています。

ここでは、以下のような影響度になっています。

Dimension	Dimensionの値	影響度
Marketplace	De(ドイツ)	71%
Marketplace	Uk(イギリス)	28%
Platform	Mobile_web	100%

ここから、Marketplaceが「De(ドイツ)」Platformが「Mobile_web」のrevenue(収益)に、より大きな異常が出ていることが読み取れます。

Metric graphsには、それぞれの異常箇所がグラフとして表示されます。
まず、9/3の21:00 ~ 9/4の1:00の間(赤枠部分)で異常が検知されていることが確認できます。 「De(ドイツ)のMobile_web」と、「Uk(イギリス)のMobile_web」を比較すると、確かに、「De(ドイツ)のMobile_web」の収益が0になっており、異常度が大きいと言えそうです。

もし、異常と検知された部分が、予想の範囲内である場合、「Is this relevant?」(緑枠部分)でラベル付けしてアルゴリズムにフィードバックすることで、異常検知の精度を向上させることが可能です。

4. アラート設定

最後に、アラートを設定しましょう。 設定項目は、
①アラート名
②閾値(threshold)
③アラートチャンネル
です。

アラートチャンネルは、Amazon SNSの他に、AWS Lambda、Skack、Webhooksなどが選択できます。

使用感

以上で、Lookout for Metricsを使った分析は完了です。使用感として、使いやすい点と注意点をまとめてみます。

使いやすい点

Lookout for Metrics が、複数のアルゴリズムから適切なものを自動で選択してくれる

アルゴリズムを意識することなく使えるので、機械学習の知識・経験がない人にとっても使いやすいと思いました。

異常のデータがなくても異常を検出できる

教師なし学習という方法で異常データなしで分析を開始でき、データの準備が楽なところは嬉しいですね。

誤判定を、アルゴリズムに簡単にフィードバックできる

検知した異常を簡単に再ラベリングでき、アルゴリズムを再学習できるところは、運用しながら精度を向上できる、嬉しい部分だと感じました。

注意が必要な点

全体の傾向が見れない

例えば、過去1ヶ月に起きた異常を、まとめて一つのグラフに表示する、という使い方はできないようです。今回のデータでは、異常発生から遡って約72時間分のデータのみ見ることができました。

複数のMesureの異常を同時に見ることができない

複数の分析軸(=Dimension)から異常を分析できることに対し、複数の分析対象(=Mesure)を同時に比較することはできないようです。

設定の変更が柔軟にできない

分析の時間単位(Interval)や、Measure/Dimensionを後から変更できない点は、注意が必要だと思いました。設定を変更するためには、新たに分析器を1から作成する必要があるため、とにかくランダムにパラメータを変えるという使い方は避けた方がよいと思いました。

コスト

ここまで、分析が簡単にできることは分かりましたが、実際使うとなると、利用コストが気になるところかと思います。

Lookout for Metricsは従量課金制で、メトリクスと呼ばれる単位で課金が発生します。

メトリクスは、Measureの数 × Demensionsがもつユニークな値の数から算出されます。 例えば、1時間あたりのオンライン注文数、1日あたりのウェブサイト訪問数などが例として挙げられています。

したがって、ユニークな値を大量に持つ可能性があるフィールドを「Demensions」に設定すると、メトリクスが大きくなり料金が肥大化することに繋がります。 この点は注意が必要です。

ここで、今回実施した分析を例にコスト試算してみたいと思います。

まず、「Measure」には、views(閲覧数)とrevenues(収益)を指定したので、Measureの数は2です。

続いて、「Demensions」には、platform(利用デバイス)とmarketplace(利用国)を指定しました。 それぞれのユニーク値は以下のようになっています。

カラム名	ユニーク値	カウント
platform	pc_web, mobile_web, mobile_app	3
marketplace	us, uk, de, fr, es, it, jp	7

上記より、Demensionsには3 x 7 = 21個のユニーク値が存在します。

つまり、Measureの数 × Demensionsがもつユニークな値の数という式に当てはめると、 2 Measure × 21 Demensions = 42メトリクス となります。

以下の料金表に基づき、最初の1000メトリクスでは 42 * 0.75USD = 31.5USD(約3500円) が1ヶ月ごとに課金される計算になります。

(出典: 料金 - Amazon Lookout for Metrics | AWS)

請求ダッシュボードを見ても、計算通りの課金が発生していました。

メトリクスごとの課金となるため、BacktestモードとContinuousモードでの課金体系に差分はありません。 1ヶ月動かし続けても、1時間だけ動かしても、料金は変わらない点は注意が必要です。
また、検出された異常の保持、閲覧による課金は発生しません。 他方、Amazon SNS によるカスタムアラートや AWS Lambda を利用したカスタムアクションには別途課金が発生します。

コスト試算には、AWS公式Githubで提供されているJupyter Notebookを利用できます。

さいごに

以上で、Lookout for Metricsを使った分析は完了です。

時系列データの異常を検知したいけど、難しいことはしたくない、というニーズに応えるサービスだと思いました。 機械学習を利用した時系列分析が、ここまで簡単に利用できるのは、Lookout for Metricsの魅力ですね。

今回は深く触れませんでしたが、データ連携の容易さやアラートのカスタマイズ性も、実運用するにあたり重要になってくるポイントかと思います。

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

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

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

Shopee - Price Match Guaranteeでゴールドメダルを獲得しました

皆さんこんにちは。
@tereka114です。
GPU熱により、部屋が熱くなってきており、冷房が欠かせません。

先日、Kaggleで開催された「Shopee - Price Match Guarantee」でゴールドメダル（5位/2426）を獲得しました。

※本件のプレスリリースをこちらで公開しています。
www.acroquest.co.jp

この記事ではコンペの概要と当チームの取り組みを紹介します。

概要

ECサイトを運営するShopee社が主催で開催されたECサイトの商品をグルーピングするコンペティションです。
期間は2021/3/8〜2021/5/10の約2ヶ月間に渡り、開催されました。
商品数34250, 商品種別11014に渡る商品のタイトル（テキスト）と画像が与えられ、同一の商品をまとめます。
これにより、ユーザ体験の向上やスパムの排除を実現できます。

テキストと画像といった複数のドメインを利用するといったマルチモーダルのタスクであること、
また、単純に分類や回帰をする問題でなかったことから非常に様々な検証の可能性が見えるのが面白そうと感じて参加していました。

www.kaggle.com

本コンペの評価指標は商品ごとに同一の商品をリストアップしますが、そのリストのF1 Scoreの平均（分母は商品）を算出します。

チームでの取り組み

終了一ヶ月ほど前、私がゴールドメダル獲得圏内に入ったあたりからチームを組みはじめ、最終的にはAhmet, Alvor、私の3人チームで進めてました。
体制としては、Ahmetと私で２つのベースラインとなる手法を構築し、Alvorが特徴量探索（EDA）やFeature Engineeringを進めてました。
チームメンバがそれぞれ得意なところを進めているような感じになりました。

この2つのベースラインの流れは大きく変わりませんが、細部で利用しているモデルは異なります。
利用しているモデルの統合したソリューションは制限時間の都合でできませんでした。
ただ、あえて、最後のスコアのShake対策も兼ねて、全くモデルの異なる２つのソリューションにすることにしていました。

※チームのソリューションはこちらのスレッドに掲載しています。（英語）
www.kaggle.com

課題やうまくいったことを共有しながら進めていたのもあり、日々議論しながら進められたことは学びが非常に大きかったと感じました。

解法

私達のソリューションの流れは次のとおりです。

1. 商品群の中でペアの候補群を作成する。
2. ペアの候補群から候補を絞り、最終的なペアを作成する。

1. 商品群の中でペアの候補群を作成する。

商品群の中からペアの候補群を作成します。
ここでは、タイトルと商品画像を別々に解析しました。
実を言えば、タイトル、商品画像を同時に学習させることも試みました。
しかし、各々から近しいものを候補としたものを最終的に結合するのが最も精度が高かったです。

1-1. 画像解析

画像の検索で利用されるArcFaceを用いました。
ArcFaceは画像検索で用いられる距離学習の手法です。Backboneとしては、次の種類を試しました。

• ResNet200D
• EfficientNetB3/B4/B5
• Swin Transformer
• ViT

まだまだ畳み込みを用いたもののほうがImageNetよりもデータの少ない場合には精度が高いと思っていました。
今回、Swin TransformerやViTでチームメンバーが精度改善していたのに驚きました。

※ArcFaceの解説はこちらの記事がわかりやすいです。
qiita.com

1-2. テキスト解析

Distilbert IndonesianとMLP+Character basedのCountVector（ngram=1,3）をベースにArcFaceを用いて特徴量を作成しました。
与えられたタイトルの言語は大きくインドネシア語と英語が占めていました。そのため、インドネシア語を学習させてあるDistilbertは特に効果がありました。

huggingface.co

MLP+CountVectorを用いた理由は、タイトル中の数値の違い（同じ種類の商品でも、1000mg, 100mgは商品として異なる）を捉えることでした。
これにより、当時のPublicは0.742->0.756まで向上しました。

1-3. 候補の検索

ArcFaceから得られた中間の特徴量を用いて、類似度が一定のしきい値以上のものを候補としました。
ここで、画像検索で用いられる近しいデータのベクトルから新しいデータを生成するDatabase Augmentation（＝Query Expansionと等価）を利用しました。
ベクトルの生成方法は近傍2件（自分含め）の重み付け平均です。データから最低2件以上の同一商品が存在することが確定していたのでこの設定にしました。

ここまでで、すべて導入するとPublic 0.767には乗ります。

※Database Augmentationについては、次のスライドのP23を見ていただくのが良いと思います。

Image Retrieval Overview (from Traditional Local Features to Recent Deep Learning Approaches) from Yusuke Uchida

www.slideshare.net

2. ペアの候補群から候補を絞り、最終的なペアを作成する。

上記のペアを用いていくつか特徴量を作り、ペアらしさを算出しました。
このペアらしさの候補群ですが、テキストは合致しているが、画像が違う、画像は同じだが、テキストが違う候補が含まれています。
このようなものを候補から省くことを目的としています。

2-1. XGBoostを用いて、候補を絞る

ペアの候補群から絞るためにXGBoostを利用しています。
2つのペアを使って、特徴として利用したのは次のとおりです。この特徴を学習し、最終的に一致しているか否かのスコアを算出するモデルを構築しました。

• 画像特徴量の類似度
• テキストの類似度
• 画像類似度 + テキストの類似度（単純な加算）
• 画像類似度 * テキストの類似度
• FP類似度（学習データの特徴量との類似度を計算し最も近いものの値）

2-2. 凝集型クラスタリング（Agglomerative Clustering）

最後に凝縮型のクラスタリングを利用して同一商品群を求めます。
導入する前は閾値ベースでペアを作成していましたが、これを導入することにより、スコア自体もPublic 0.774->0.778へ向上しました。
最終的には少し画像のサイズを向上させるなどして精度を上げています。

凝縮型クラスタリングそのものに関しては、次のサイトがわかりやすいと思います。
qiita.com

このコンペで学べたこと

• Transformerベースの画像認識モデル（ViT/Swin Transformer）は各コンペで今後、試す価値があり。
• BERT+画像モデルは他のソリューションでは成功しているものがあったため、チューニング次第では十分コンペ用途には足りた。
• 検索で利用されるDatabase AugmentationはECサイトの検索でも効果を示せた。検索タスクだと非常に有効そうに見える。

最後に

ECサイトの商品検索といった非常に面白く、実践的なコンペティションで刺激的な日々を過ごしていました。
非常に勉強になったのでまた面白いコンペに参加しようと思います。

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

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

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

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

Elasticsearchで教師あり機械学習 ~Data Frame Analyticsまとめ ~

この記事は Elastic stack (Elasticsearch) Advent Calendar 2020 の 22日目の記事になります。

こんにちは、@shin0higuchiです😊
今回のテーマは、「Elasticsearchで教師あり機械学習」ということで、Data Frame Analyticsの機能を紹介します。

はじめに

2017年ごろから、Elasticsearchには時系列データの異常検知に特化した、教師なしの機械学習機能がありました。
詳しくは、昨年（2019年）のAdvent Calendarで @yukata_uno さんが
「Elastic Machine Learningの歴史を振り返る」という記事を書いていらっしゃるのでそちらをご参照ください。

今年は Elasticsearch の Ver.7.2 で transform が利用可能となり、
そこから outlier detection, regression, classification などの機能が続々リリースされました。

本記事では、その中の Classification を利用して、実際に機械学習を試してみます。
※X-Packの有償機能を利用するため、トライアルライセンスを有効化しています。

利用するデータについて

データセットとしてはこちらを利用します。
www.kaggle.com

データに含まれる「年齢」、「給与」、「婚姻状況」、「クレジットカードの制限」、「クレジットカードのカテゴリ」などの情報から、その顧客がクレジットカードを解約するかどうかを予測することを今回の目標としましょう。
Attrition_Flagのカラムに「Existing Customer」「Attrited Customer」の２値が入っており、これを予測する形になります。

では、CSVファイルをKibanaから取り込んで中身を見てみましょう。

bank_churners という名前のインデックスに取り込みます。

機械学習ジョブの作成

Machine LearningのメニューからData Analytics Jobの「Create job」を選択し...

Classificationを選択します。
Dependent variable には分類の対象となる Attrition_Flag を指定します。

分析に利用するフィールドはチェックボックスで選択することができます。
ここでは前述の「年齢」、「給与」、「婚姻状況」、「クレジットカードの制限」、「クレジットカードのカテゴリ」を含む14フィールドを指定しています。

ElasticsearchのClassificationでは、内部的にBoosted Decision Tree Regressionによる学習をおこないます。
設定項目は分析の種類によって異なりますが、Classificationの場合は以下の通りです。

項目名	説明
Feature importance values	結果に大きく影響したカラムを取得する最大数
Prediction field name	予測結果を入れるフィールド名
Top classes	分類するクラス数
Model memory limit	モデルの上限メモリ量
Maximum number of threads	分析時の最大スレッド数

ハイパーパラメータについては、内部で適切な値を選択してくれるようなので、詳しくない場合はデフォルトで良いでしょう。ここでは説明を割愛します。Hyperparameter optimization | Machine Learning in the Elastic Stack [7.10] | Elastic

設定の詳細はこちらをご参照ください。
Concepts | Machine Learning in the Elastic Stack [7.10] | ElasticClassification | Machine Learning in the Elastic Stack [7.10] | Elastic

学習の開始

ジョブ名などを決めたあと、学習を開始することができます。

学習の進行度はプログレスバーで確認することができます。
学習が終わると「View Results」のリンクが表示されます。

結果の確認

結果画面では、影響度の大きいカラム・モデルの評価値・推定結果などが確認可能です。
まずは、影響度の大きいカラムのランキングを見てみましょう。
Avg_Utilization_Ratio, Months_Inactive_12_mon, Contacts_Count_12_monなどが上位となっています。カードの利用率や過去１２カ月の動きが少ない人が解約しやすいと思われるので、感覚的には正しそうな印象ですね。
※表示されるフィールド数は、先ほど設定したFeature importance valuesによります。

そしてこちらが、モデルの評価値です。
実際の推論結果と、正解ラベルをマトリクスで示したものになります。
解約しそうなユーザーを漏れなく見つけることが重要になるので、Attrited Customer側の正解率をもっと上げたい（再現率を上げたい）印象はあるものの、解約と継続の正解率はそれぞれ68%, 80%となっており、総じて悪くない結果なのではないでしょうか。

作成したモデルの利用

学習したモデルは、inferenceという機能を通じて、ingest nodeの processor や、Aggregation から利用することができます。

たとえば次のような ingest processor を用意することで、新規に取り込むドキュメントを学習済みのモデルで分類することができます。

{
  "inference": {
    "model_id": "bank_churners-1608484239997",
    "target_field": "BunkChrner_prediction_infer",
    "inference_config": {
      "classification":{
        "num_top_classes": 2,
        "results_field": "prediction",
        "top_class_results_field": "probabilities"
      }
    }
  }
}

※ model_idは GET /_ml/trained_models で確認することができます

Aggregationについては割愛します。親となるAggregationの値に対して推論をかける形になりますので、 inference processorと基本的な設定内容は同じです。詳しくはこちらを参照してください。Inference bucket aggregation | Elasticsearch Reference [master] | Elastic

まとめ

以上のように、Elasticsearchの機械学習が大幅に強化され、専門的な知識がなくとも利用できるようになって来ています。Elasticsearchの強みは、集約したデータを様々なユースケースに横断的に活用できる点だと思っていますが、今回紹介した機能はさらにその幅を広げてくれるのではないかと思っています。
皆さんも是非ElasticsearchのData Frame Analyticsを試してみてください。

それでは。

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

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

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

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

Azure Cognitive Searchのコグニティブスキルを使った自動でフィルタ検索

皆さんこんにちは。@Ssk1029Takashiです。
気づけば今年もあとわずかになってきて、一年の早さを感じますね。

以前、GiNZA＋Elasticsearchを使って固有表現抽出を使ったタグ検索のデモを作成しました。
acro-engineer.hatenablog.com

ただ、デモというのは何より早さが必要な場合もあります。
その場合だと、なるべくプログラミングを減らして、作成したいと思うこともあります。
今回は、Azure Cognitive Searchを使って、上記のような内容を、一切プログラミングせずに実現してみます。

Azure Cognitive Searchとは

Azure Cognitive Searchとは、名前の通りAzure上の検索サービスです。
特長としては、AIエンリッチメントという拡張機能を備えており、機械学習を活用したリッチな検索システムを簡単に実現できます。
docs.microsoft.com

AIエンリッチメントについて

この機能は、データソースから検索データを投入するときに、コグニティブスキルというAzure上の機械学習連携機能を使って、データから検索に使うデータを抽出できる拡張機能です。
例えば、エンティティ認識スキルを使えば、文書から自動で場所や人などを抽出して、データに持たせることができます。

docs.microsoft.com

データ投入準備

Azure Cognitive SearchはAzure Blob StorageやCosmos DBなどのデータ連携がサポートされています。
詳細な連携先サービスは以下のURLのページに記載されています。
docs.microsoft.com

今回は、Blob Storageにファイルを配置して、その内容を検索できるようにします。
Blob Storageにこのブログの内容を張り付けたテキストファイルをアップロードします。

検索データを投入する

検索データの連携は基本的なものならGUIから操作することが可能です。
Azure PortalのAzure Cognitive Searchの画面から「データのインポート」を選択することで、設定画面に移行します。

ここから、以下の項目を設定することで、インデックスを作成することができます。

連携するBlob Storageのコンテナ

検索対象のファイルが配置してあるBlob Storageの場所を設定します。

適用するコグニティブスキル

データ投入時に機械学習を使って抽出したい内容を選択します。

組み込みのコグニティブスキルは以下のURLで一覧が示されています。
docs.microsoft.com

インデックスのフィールドと型

どのようなデータ構造でデータを投入するかを設定します。
各フィールドの名前・検索対象可能か・フィルター可能か・集計可能か・ソート可能かを設定します。
変更点としては、locationsなどのコグニティブスキルで抽出したフィールドは、フィルターで表示したいので、フィルター可能・ファセット可能に設定します。

ここまで設定すれば、後はインデクサー名とスケジュールを設定すればデータのインポートが実行されます。

作成されたデータを見てみる

それでは投入された結果のデータを一部見てみましょう。
Searchサービスの「概要」から「検索エクスプローラー」を選択することで、簡易的にクエリを打ってデータを確認することができます。

    {
            "@search.score": 1,
            "content": "皆さんこんにちは。\r\n@tereka114です。\r\n\r\n今週からCVPR2020がはじまりました。\r\n本記事では初日と2日目に参加したWorkshop/Turtorialを紹介します。\r\n\r\nf:id:acro-engineer:20200616135912p:plain\r\nCVPR2020\r\nCVPR2020の正式名称は「Computer Vision and Pattern Recognition」です。\r\n6月14日〜19日まで開催されています（時間はPDT）\r\nこれは、アメリカのコンピュータビジョンの国内学会で、毎年非常に盛り上がっています。\r\n\r\n今回、私は1年ぶりに参加しています。\r\nコロナウィルスの影響で現地開催ではなく、バーチャル開催になりました。\r\nPDT（日本から16時間遅れ）の時間とそれから12時間後に動画が放送されています。\r\n\r\n日本にいながら、私はシアトル時間で参加しています。\r\n普段の現地参加と異なり、太陽の時間がずれているので、体調を整えるのが難しい感覚です。\r\n\r\n\r\ncvpr2020.thecvf.com\r\n\r\n自動運転技術の基本を学べるチュートリアル\r\n初日はチュートリアル「All About Self-Driving」に参加しました。\r\n\r\nwww.allaboutselfdriving.com\r\n\r\nこのチュートリアルでは、Zoomのセミナー機能を利用し、既に収録されている動画が放映されます。\r\n途中でSlidoから質問を拾い、質疑応答を行っていました。\r\n\r\nこのチュートリアルは、自動運転技術に必要なことを包括的に紹介していました。\r\n例えば、ハードウェア（LiDAR、RADERなど）からソフトウェア（物体検出、予測、コントロール方法など）のそれぞれの種類と長短の説明がありました。\r\n私自身、自動運転技術の細かいハードウェアや方式にはあまり馴染みがないところもあったので、新しく得られた学びも多かったです。\r\n\r\nf:id:acro-engineer:20200615102403p:plain:w720\r\n2日目：深度推定と最適化\r\n2日目は午前と午後で異なるセッションに参加していました。\r\n\r\nLearning and understanding single image depth estimation in the wild\r\n公式ページで動画が公開されているので、それを見てました。\r\n質問は発表時間中にリアルタイムで受け付けていました。\r\n\r\n単眼深度推定のチュートリアルで、深度推定を行う上での仕組み（視差）、データセット、そして、各種アルゴリズムの紹介が行われていました。\r\n新しい分野でも包括的に学べて、資料も公開され、後で振り返られるのが良いところです。\r\n\r\n\r\nsites.google.com\r\n\r\nf:id:acro-engineer:20200616142257p:plain:w720\r\nFrom NAS to HPO: Automated Deep Learning\r\nこのチュートリアルはハイパーパラメータとアーキテクチャのチューニングの話です。\r\n機械学習には多くのハイパーパラメータが存在し、そのパラメータを調整する方法も知られています。\r\nまた、最近だと、ニューラルネットワークの構造を自動的に計算する方式もあるので、その件も紹介されていました。\r\n\r\nハンズオン付きで実装もあるので、いざ試してみたい！と思った時に便利そうなのはありがたいことです。\r\n\r\nhangzhang.org\r\n\r\nf:id:acro-engineer:20200616142437p:plain:w720\r\n最後に\r\n明日からCVPRのメインカンファレンスです。\r\n前年よりも論文数が多く、盛り上がっているなぁと感じています。\r\nぱっと見面白そうな論文も見られるので、きちんと読んで楽しみたいと思います！\n",
            "metadata_storage_path": "aHR0cHM6Ly9zZWFyY2hzb3VyY2UuYmxvYi5jb3JlLndpbmRvd3MubmV0L3NvdXJjZS1maWxlL0NWUFIyMDIwJUU1JThGJTgyJUU1JThBJUEwJUU4JUE4JTk4JUUzJTgwJThDJUU1JTg4JTlEJUUzJTgyJTgxJUUzJTgxJUE2JUUzJTgxJUFFJUUzJTgzJTkwJUUzJTgzJUJDJUUzJTgzJTgxJUUzJTgzJUEzJUUzJTgzJUFCJUU5JTk2JThCJUU1JTgyJUFDJUUzJTgwJTgxJUUzJTgzJTgxJUUzJTgzJUE1JUUzJTgzJUJDJUUzJTgzJTg4JUUzJTgzJUFBJUUzJTgyJUEyJUUzJTgzJUFCJUUzJTgxJThDJUU1JTg1JTg1JUU1JUFFJTlGJUUzJTgwJThEJTIwJTIzY3ZwcjIwMjAudHh00",
            "people": [],
            "organizations": [],
            "locations": [
                "アメリカ","日本","シアトル"
            ],
            "keyphrases": [
                "まし","チュートリアル","acro-engineer","plain","現地参加","紹介","自動運転技術","w720","シアトル時間","動画","CVPR2020","ハイパーパラメータ","現地開催","単眼深度推定","発表時間中","質問","初日","ハードウェア","方式","バーチャル開催","こと","公開","PDT","日本","ところ","コントロール方法","楽しみたい","論文数","Automated Deep Learning","Learning and understanding single image depth estimation in the wild","Computer Vision and Pattern Recognition","リアルタイム","From NAS to HPO","物体検出","All About Self-Driving","国内学会","利用","データセット","ソフトウェア","予測","仕組み","名称","アーキテクチャ","受け付け","20200615102403p","20200616142257p","20200616142437p","コンピュータビジョン","セミナー機能","質疑応答","アメリカ","視差","構造","拾い","RADER","各種アルゴリズム","Zoom","コロナウィルス","影響","チューニング","存在","太陽","基本","20200616135912p","毎年","種類","計算","LiDAR","Slido","収録","ずれ","調整","馴染み","Workshop","Turtorial","自身","ニューラルネットワーク","機械学習","新しく得","学び","ハンズオン付き","実装","体調","長短","説明","思い","本記事","ページ","放送","最適化","セッション","カンファレンス","感じ","感覚","資料","はじまり","放映","分野","皆さん","tereka114","最後"
            ],
            "language": "ja"
        }

これを見ると、locationsで国名などを拾えていることがわかります。

キーフレーズは、「チュートリアル」や「CVPR2020」などの重要単語は拾えていますが、「こと」や「はじまり」などの意味のない単語も拾ってしまっているようです。
この辺は今後の精度改善に期待ですね。

デモアプリを作成する

Azure Cognitive Searchでは、GUI操作だけで検索画面を見るためのデモアプリを作成することができます。
Cognitive Searchの概要の画面から、「インデックス」→「デモアプリの作成」を選択することで、作成画面に移動します。
以下の項目を表示したい内容に沿って、設定します
1. 検索結果に表示する内容

2. フィルターに表示する内容
ここでコグニティブスキルで抽出したフィールドを設定します。

3. ドロップダウンで表示する内容

これらを設定すると、HTMLファイルをダウンロードすることができます。
ブラウザで表示すると、簡易的なデモアプリを表示することができます。

この画面で、キーワード検索・フィルターでの絞り込みが可能です。

ここまでで、一切プログラミングをすることなく、フィルターで絞り込みができるデモアプリが作成できました。
ほぼGUIの操作のみで、作成できたので、非常に簡単でした。

まとめ

今回はAzure Cognitive Searchの機能を使いながら、簡単に機械学習によるテキスト抽出を使ったタグ検索デモを作成しました。
サービスの機能を使うことで、一切プログラミングすることなくデモまで作成することができました。
もちろん、あくまでデモは簡易的な画面なので、画面開発は必要かと思いますが、検索結果のイメージをなるべく早く見せたいなどのケースでは重宝しそうです。
皆さんもぜひ使ってみてはいかがでしょうか？

それではまた。

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

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

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

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

小麦物体検出のKaggleコンペティションGlobal Wheat Detectionで6位になりました

皆さんこんにちは
@tereka114です。

先日まで開催された物体検出のコンペティション「Global Wheat Detection」で6位になりました。
これまでチームではGoldを2度獲得したことがありましたが、ソロゴールドを獲得しました。
Kaggleはじめて6年目でようやく獲得できたので感慨深いです。

本記事では簡単にそのコンペの参加状況を記載します。

※コンペティションのサイト
www.kaggle.com

コンペティション概要

本コンペティションは、世界各地で撮影された多種の小麦の画像から、1つのモデルで小麦の穂の部分を検出する課題です。
小麦の穂の検出精度が向上することにより、農家の収穫の品質が上がったり、研究者が穂の密度やサイズを正確に計算できたりします。
コンペティションの開催期間は3ヶ月ほどで、5月5日開始、8月4日に終了しました。私は開催の初期の頃から参加していました。
そこから、主催者による終了2週間ほどの期間で提出物のチェックがあり、8月20日に確定しました。

結果、Public 1st/Private 6thでした。後述で説明するデータセットの扱いがなかなか難しく、PrivateとPublicの順位が離れる、いわゆる、Shake upの対策に難儀していました。

Private Leaderboard

難しかったところ

今回の難しいは主にデータセットにあります。
世界中の小麦の写真を集めていますが、品種や地域によって育成度合いや形が全く違います。
また、学習データと評価用のデータには共通となる品種、地域はありません。
そのため、新しい環境でも運用できるモデルを構築しなければなりません。

小麦は環境や品種などで、想像以上に見え方に差分があります。公式の小麦画像によればこれぐらい違います。

小麦画像（Kaggle公式より）

解法

日本語で詳細を書く予定ですが、一応、英語でKaggle Discussionに書いています。
www.kaggle.com

そのため、本記述では詳細は省きますが、簡単に紹介します。
モデルはEfficientDetB3,B4,B5を利用しています。
処理は簡単に次の5段階に分かれています。

1. EfficientDetB3を使って学習データのみでモデルを構築し、評価データ（公開の10枚）に対して疑似ラベル（推論の結果）を作る。
2. 評価データと疑似ラベルに加え、学習データを入れて、EfficientDetB4とB5のモデルを作る。
3. Kernel上で予測したEfficientDetB5の結果を用いて、評価データ（全体）に対して疑似ラベル（推論の結果）を作る。
4. 3で利用したEfficientDetB5を学習データと評価データ（全体）でFinetuninigする。
5. EfficientDetB4(2) + EfficientDetB5(3) + EfficientDetB5(4)を組み合わせて最終的な予測をする。

基本的なソリューションコンセプトはいかにドメインが同じである評価データを利用するかです。
この情報をモデルに取り入れられると、ロバストなモデルの構築ができるのではと考えていました。
仕事でも違う場所にモデルを適用することに応用できそうなので、そのあたりのアプローチについて、自分なりに追求していました。

最後に

コンペ中は色々とありましたが、楽しかったです。
物体検出は仕事で使うことが多いので、仕事でも活かせると思ったテクニックは多々ありました。
仕事にも活かして、製品の改善などに貢献していきたいと思います。

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

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

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

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