Grafana+CloudWatchを使ったAWSマルチアカウントでのプロダクト監視基盤構築のご紹介

ACESのソフトウェアエンジニアの稲田です。私は普段、弊社で提供しているシステムのアーキテクト設計、MLOpsをメインに担当しております。 今回は、ACES Meetという弊社のAIプロダクトサービスをターゲットに弊社のサービス監視基盤を標準化した話について、事例紹介をしたいと思います。

営業支援AIツール「ACES Meet」

想定する読者

• マルチアカウントで複数サービスの監視運用を考えている管理者
• 複数の AWS アカウント環境下でManaged Grafanaを利用するメリットを知りたいヒト
• プロダクトの監視を楽にしたいヒト

プロダクトサービスの品質可視化の重要性について

サービスの信頼性を維持・向上させるためには、まず、サービスのシステム品質を可視化することが大切です。 例えますと、健康診断の定期健診のように、定点で確かなメトリクスで体の状態を細かくチェックするのが大事なのに似ています。症状が出るまでほっておいて調べてみた時にガンのStage4では遅いのです。
プロダクト監視のあるべき姿は、

• サービス品質を表現するメトリクスが定義されダッシュボードに可視化されている
• 障害発生時にどこで何が起きたか素早く確実に把握するために必要となる全てのシステムメトリクスを一つのダッシュボードで網羅的に見れるようになっている
• 日々の経年の変化を継続的に見ることで、傾向から障害の早期検知を行い障害を未然に防げるようになっている

このような監視ダッシュボードがあり、サービス品質を表現するメトリクスが閾値を超えたら自動でアラート通知が飛んでくるようになっているのがあるべき姿です。

弊社が抱えていた課題と背景

これまで弊社はSentryをベースにB2Bプロジェクトの提供サービスの障害監視を行っておりました。
また、これまで商用プロダクトサービスは展開しておらず、ACES Meetを昨年末β版提供でデモ利用を頂いておりましたが、正式リリースに向けて、商用に耐え得る、安心してお客様にご利用して頂けるサービスのプロダクト監視基盤の整備が急務となっておりました。 ただ、ACES Meetは3月正式リリース予定のサービスで(現時点ではリリース済)、監視基盤構築にかけられる時間は必ずしも潤沢にあるとは言えない状況でした。
弊社はセキュリティ設計上の観点で、顧客/プロダクト毎にAWSアカウントを発行して運用しており、作った監視基盤が専用のプロダクトでしか使えないものではなく、新しいサービスを構築した時にAWSマルチアカウント環境で簡単に水平展開出来るようにしておきたいと考えておりました。

技術選定の方針

そのような背景から、まずは手軽に、監視要件に対して全てを満たすシステム基盤をはじめから作ろうとするのではなく、スモールスタートではじめたいと思いました。 というのも、監視基盤のソリューションとして代表的にDatadogやMackerel等のSaaSもあると思うのですが、外部サービスを使うと構成が複雑になり、外部サービスに引きずられて後で後悔するというのは避けたいと言う気持ちがありました。スモールにスタートしておけば、実際のプロダクトが成熟してサービスレベル目標(SLO)による監視要件が明らかになった時に、必要に応じて外部サービスを使う構成に拡張できます。

AWSだけでスモールにとなると、監視基盤の技術選定としては、 「CloudWatch + Xray (+ Prometheus)でメトリクス収集を行い、Grafanaを可視化ダッシュボードとして利用する」 ぐらいで良さそうです。 AWSが標準で提供しているダッシュボードではなく、Grafanaを可視化ツールとして使うことを選定したのは、私自身がGrafanaを前職で使い慣れていて可視化ツールとして優れている点を理解しており、また、AWSが標準で提供しているダッシュボードは使いにくい印象があったためです。 Amazon Managed GrafanaをサーベイしてAWSマルチアカウントで使いやすいサービス設計になっていることがわかったのもGrafana選定を後押ししました。

結果、普通すぎて少し退屈な感じではありますが、技術選定としては一旦この通りとして走り始めました。 監視基盤の技術選定のおおまかな方針が決まり、以下の通り監視基盤設計を行いました。

プロダクト監視基盤設計

目的

プロダクトの標準監視ダッシュボードを作成し、サービス品質を可視化します。

• サービス品質を表現するモニタリング測定値(SLI)の定義と可視化
• 異常早期検知と原因特定のためのシステム詳細メトリクスの可視化
• 異常状態の定義とアラート通知
• リクエスト処理ボトルネックの特定のため、リクエスト単位でどこで処理に時間がかかっているか可視化

要件

• メトリクスの収集
  • AWSマルチアカウントに対して一元的にメトリクス収集が可能であること
  • メトリクスの保存期間は13カ月 (ここはCloudWatchのメトリクス保存期間の制約にあわせる)
• メトリクスの集計
  • レートの計算、SLIの算出
  • キー項目でのグループ化(API毎の集計、テナント毎の集計）
  • 時系列データの時間単位(BIN)のグループ化(最小、最大、平均、パーセンタイル)
• メトリクスの監視
  • SLIが閾値を下回った時、特定監視イベント発生時のアラート通知 (Slack/SMS)
• メトリクスの可視化
  • 個別プロダクト、個別テナント単位でダッシュボードが作成できる
  • 一方で全プロダクトのSLIがサービスレベルで規定する閾値に対してどう推移しているか一つのダッシュボードで確認できるようになっている
• 性能要件
  • 内部サービスのため監視ができる範囲の最低限の性能が出れば良い
• 拡張性要件
  • 新しいプロダクトが追加された時に、プロダクトを監視するための定義がテンプレート化されていて追加しやすいようになっている
• 運用要件
  • プロダクト内で動的に生成される監視対象インスタンスの監視登録/削除の自動化

監視項目

サービス品質

• リクエストエラーレート
• リクエストレンテンシ (平均, 90パーセンタイル, 95パーセンタイル)
• バッチエラーレート
• バッチ処理時間 (平均, 最大)
• API毎のリクエスト数、エラーレート、レイテンシ

システム詳細メトリクス

AWSサービス	監視項目
ALB	RequestCount, SurgeQueueLength, HTTPCode_ELB_5XX, Latency, HealthyHostCount, UnHealthyHostCount
Fargate	CPU, Memory, Network In/Out, Storage Read/Write
SQS	NumberOfMessageReceived, NumberOfMessageReceived(DLQ)
Sagemaker	CPU, Memory, Disk, GPU, GPUMemory, Invocations, Invocations4xxErrors, Invocations5xxErrors, ModelLatency
AWS Batch	CPU, Memory, Disk (*1)
RDS	CPU, FreeStorageSpace, DatabaseConnections, ReadLatency, WriteLatency, DiskQueueDepth
ElasticSearch	CPU, JVMMemoryPressure, FreeStorageSpace, ClusterStatus, ClusterIndexWritesBlocked, 2xx, 5xx, IndexingLatency, SearchLatency

*1: AWS Batchのキューの状態はAWSデフォルトのメトリクスではサポートされないため、AWS公式の実装を参考に自分でカスタムメトリクスを出力する必要があります。

参考記事
AWS公式 ECS Container insights 取得できるメトリクス
AWS公式 RDS監視項目
AWS公式 ElasticSearch監視項目
aws-samples/aws-batch-runtime-monitoring: Serverless application to monitor an AWS Batch architecture through dashboards.

アラート通知

リクエストエラーレート、レイテンシのサービス毎に設定した閾値を下回った場合に通知します。
各々の死活監視は全てリクエストエラーレート、レイテンシに現れるため、個別のインスタンス、コンポーネントシステムの死活監視のアラート設定は基本行わない想定です。
エラー発生時、エラー原因がすぐ確認できるようになっていれば良しとします。

但し、以下は例外で個別にアラート通知するようにしました。

• AWS Batch JobFail (ACES Meetの監視ユースケースとして全ての推論Batchを正常完了させる必要があるため)
• ElasticSearchの推奨項目監視 (ElasticSearchは表面上は動いていても例えば裏でレプリカが落ちている状態でインスタンスが落ちるとデータが消失してしまい、データ復旧には時間がかかりサービスへの影響が大きいため)

システム構成

監視ダッシュボードの仕組み

監視ダッシュボードは、ログ、メトリクス、トレースという別々のデータソースからデータを取得して表示します。
表示部分はGrafanaが担当しますが、Grafana自体はデータは保持せず表示するだけで、データソースとしてとして、ログはCloudWatch Logs、メトリクスはCloudwatch Metrics、トレースはX-Rayから取得します。
各々のデータソースは以下の通り性格が異なります。

引用元：[レポート] Application Performance Management (APM) on AWS

データソース	データ取得可能期間とメトリクス表示速度
ログ (CloudWatch Logs)	ログから毎回メトリクスを作るため、メトリクスの表示速度がログ量に比例し、長期間の表示には時間がかかるため長期間の表示には向かない
メトリクス (Cloudwatch Metrics)	表示速度が高速で、長期間のメトリクス表示が高速に行え長期間の傾向も高速につかめる。AWSが基本的なメトリクスはデフォルトで用意してくれている(ただ、全てのメトリクスはサポートされておらず、例えばAWS Batch等はメトリクスサポートがない)。また一方で、カスタムのメトリクスを作るのは実装が必要となるためメトリクス毎に*Nでインフラ実装工数が必要となる
トレース (X-Ray)	データを取得できる期間の範囲が最大6時間までで、長期間の傾向は見れない。アプリケーションにエージェント組み込みの実装が必要となり、初期コストとしてアプリケーションへの組み込み実装工数が1回だけ必要となる

参考記事
AWS X-Ray トレーシング入門 AWS X-Ray とは？

Amazon Managed GrafanaのAWSマルチアカウントのデータソースサポート

Amazon Managed Grafanaは、AWS Organizationが裏でうまく活用されていて、複雑な設定不要でコンソールからセットアップ後、Grafanaからすぐデータソースとしてorganizationに属しているAWSアカウントのデータソースを追加可能です。
CloudWatchのメトリクスを他のAWSアカウントから見れるようにしたり、他のAWSアカウントにエクスポートしたり、マルチアカウントのIAM Roleの設計をしたりというマルチアカウントで発生する面倒な作業が一切なくmanagedでAWSが隠蔽してやってくれるので快適です。 以下のようにGrafanaからAWSアカウントを選んでデータソースを追加するだけで良いです。

Amazon Managed GrafanaのX-Rayサポート

Amazon Managed GrafanaはデータソースとしてX-Rayプラグインをデフォルトでサポートしており、X-RayのServiceMapをGrafanaの一つのパネルとして統合可能で、障害発生時にどこで何が起きたか素早く確実に把握するための強力な可視化メトリクスを監視ダッシュボードに提供してくれます。

引用元：[YouTube] Set Up AWS X-Ray as a Data Source Plugin for Amazon Managed Grafana | Amazon Web Services

同じものを作れば障害時の障害ノード特定が迅速に行える監視ダッシュボードが実現できますので、ありがたくまるっとコピーさせて頂きました。

監視ダッシュボードのデータソースの拡張性

弊社初期構成ではPrometheusはデータソースとして除外しましたが、監視メトリクスのデータソースとして Prometheus / AWS Timestream / ElasticSearch等、比較的柔軟に多種多様なデータソースを追加可能である点は魅力です。

コスト概算

CloudWatch

AWSデフォルトで提供しているメトリクスは無料、カスタムメトリクスは10,000メトリクスまでは1メトリクスあたり月$0.3です。 プロダクト監視基盤設計の「監視項目」の節で対象としたメトリクスを取得するためにはECS/ContainerInsightsを有効にする必要があり、その場合自動でカスタムメトリクスが作成されます。 コスト感はサービスの規模にもよりますが、AWS公式のAmazon CloudWatchの料金の例を意識しておくと良いと思います。

引用元：Amazon CloudWatch の料金

この料金とは別に、監視ダッシュボードを見た時に都度X-Rayからトレースデータを取り出してくる料金がかかります。 料金の見積もりは監視ダッシュボードの使用頻度によるため見積もりは難しいですが、弊社でAWSコンソールのCostExplorerから実際にかかっている料金を確認したところ、CloudWatchにかかっている料金の1/10程度となっていました。

引用元：Amazon X-Ray の料金

Amazon Managed Grafana

Amazon Managed Grafanaの料金体系は月額利用ユーザ数課金で、利用10名想定で$60/Month程度の試算です (監視対象サービス毎の金額ではなく、弊社内でトータルの金額)

以下参考で、自前でEC2インスタンスでGrafanaを建てた場合の検討ですが、弊社ではコスト比較で自前でGrafanaを建てるメリットはあまりみあたらず、まだ人数も少ないこともあり、まずは Amazon Managed Grafana で軽くはじめるで良さそうです。

• 自前Grafana

項目	料金	備考
構築(initial cost)	人件費(2w)	Route53, ALB, SSO, AWSマルチアカウントテンプレート作成
運用(monthly cost)	$100/M	以下合計
vcpu(fargate)	($73)	2vcpu (2 * 30d * 24h * $0.051/h)
memory(fargate)	($9)	2G (2 * 30d * 24h * $0.006/h)
システムアップデート	人件費	Grafanaアップデート

• Amazon Managed Grafana

項目	料金	備考
構築(initial cost)	人件費(0.5d)	AWSコンソールからぽちぽちやるだけ
運用(monthly cost)	$62-$120/M	月額利用ユーザ課金: $9.00 (Editor license) $5.00 (Viewer license) 10名(Engineer(Server)+Manager): 3 * $9.00 (Editor license) + 7 * $5.00 (Viewer license) 20名(Engineer(All)+Manager): 4 * $9.00 (Editor license) + 16 * $5.00 (Viewer license)

参考記事
Amazon Managed Grafana pricing

構築した監視ダッシュボードのご紹介

監視ダッシュボードへのログイン

まずは、Grafanaへのログインからですが、弊社では AWS へのログインは AWS SSO を利用しており、Amazon Managed Grafanaのユーザ管理画面でログインさせたいAWSユーザを追加すると、以下のように参加させたユーザからGrafanaのエントリーポイントのアプリケーションが見えるようになります。ここからGrafanaにログインします。

監視ダッシュボードの構成

パネルを以下の種類ごとにグルーピングして監視ダッシュボードを作成しました。

• プロダクトサービスを運用する上で最低限これだけは見る項目
• コンテナ詳細
• アプリケーションモニタリング項目
• データベース詳細

「最低限これだけは見る項目」は、監視ダッシュボードでは最上段に配置しました。

プロダクトサービスを運用する上で最低限これだけは見る項目

一番大事で最低でも見ておかなければいけないのはリクエストエラーレート、リクエストレスポンス(リクエストレイテンシ)の二つです。 BatchJobが存在する場合は、これにくわえて、Batchのエラーが発生しているかとBatch処理時間の最大値(時間的に許容最大値があれば超えていないかどうか)、 また、そもそもリクエストがきているか、リクエストのスパイクがないか、時系列のリクエスト推移に変化がないか、も見ておきます。

AWSでX-Rayを導入している場合、X-Ray Insightsという自動的に障害を検知してレポートをあげてくれる機能があり、これをそのままパネルとして表示するようにしました。StateがActiveであればまさに「障害中」なので、ここも必ず見ます(incidentの発生期間もレポートとしてよしなにまとめてくれるようです)

監視ダッシュボードを見るタイミング

• 障害発生時(言わずもがな)
• 本番リリース後、数時間程度経過観察
• 基本的に本番運用している場合は障害早期検知、未然検知という観点でも朝会で毎日1分でも見る

サーバチームの朝会で毎朝1分眺める、週ごとに監視担当を決めて回していく、等やりかたはいろいろなので、プロダクトチームのスタイルにあわせて監視体制を構築することになると思います。 継続的に見ることで、日々の変化から、障害の早期検知に繋がりやすく、最初はダッシュボードを見てもすぐに障害と気付けなくとも、運用していくとで練度があがっていき、熟練の目が養われた状態になるとダッシュボードをパット見たら怪しいところが分かる状態になれます。

その他見るべきポイント

障害の原因は、単純なバグの他、リクエストの高負荷、DBの高負荷、接続外部システムのダウン、Zone障害(センターの災害、センターで掃除のおばちゃんがサーバラックの電源足にひっかけて引っこ抜いた)等さまざまです。

リクエストエラーレート、リクエストレイテンシで異常がみられる場合は、X-Rayでエラーリクエスト一覧と、スローリクエスト一覧を見て、個別のリクエストのトレースを行って原因を究明を開始します。 外部システムがダウンしている障害も非常におこりやすいく、これもX-Rayのサービスのノードマップでどのサービスがダウンしているか特定します。

経年の変化はCPU/Disk/MemoryやDBのConnection数等を通して徐々にあらわれてきます。 システムダウンにつながる障害がおこりやすいのは、一番処理に時間がかかるDBで、DBの状態は特に把握しておく必要があります。 スパイクアクセスがあった場合、一番処理に時間のかかるDBに処理が集中し、DBのconnection数がはねがあってconnection上限に達してconnectionがつなげられなくなり、システムダウンに至ります。 システムダウンに至らなくとも、システム全体としてリクエストレイテンシが大幅に悪化し、ユーザ影響を与えます。事前に変化や負荷状態に気付ければ、DBレプリカやスケールの検討が可能です。

リクエストの高負荷はサーバの問題というよりリクエスト側の問題である可能性もあり、Frontチームに連携して不要なアクセスを省けるようであれば全体としてパフォーマンスがあがりユーザビリティの向上につながります。 サーバにリクエストがこなくなった場合は、Front側での何かのリリースエラーや、前段のロードバランサーのSSL証明書の期限切れ等が考えられます。 Zone障害はたまに発生する現象で、AWSでのベストプラクティスでは複数のavailability zoneに各々1台サーバを配置して、「センターで掃除のおばちゃんがサーバラックの電源引っこ抜いた」状態でも継続してサービス提供が出来るように構成を組んでおけるようになっているので、Zone障害でサービスダウンになっていればシステム構成をAWSのベストプラクティスに沿うように修正する必要があります。

さらに監視に対する知見を深めるには

毎日のサービス監視にくわえ、こちらの書籍などを読むことであわせてさらに深く知見をたかめていくことをチームメンバーにお勧めしております。
入門 監視 ―モダンなモニタリングのためのデザインパターン
SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

他のサービスへの監視ダッシュボード展開の拡張性

今回作成した監視ダッシュボードは監視基盤設計で記載した弊社で現在サービスと使用しているAWSサービスの一通りのメトリクスを網羅しています。 作成した監視ダッシュボードはデータソース部分を変数化していて、新たなサービス追加時は、Grafanaのデータソース追加の画面からサービスを提供するAWSアカウントのデータソースを追加し、変数となっているデータソースを追加したデータソースに選びなおし、続いて変数化しているLoadBalancer、システム名(Project)を選びなおせば、新しいサービスの監視ダッシュボードが開始可能になっています。

最低限の監視ダッシュボードは秒で出来てしまいます(言い過ぎました...分だと思います...)。 あとは、必要に応じて、ダッシュボードにサービス固有のメトリクスを追加、必要ないメトリクスを削除していきます。

終わりに

ACES Meetのプロダクトの正式リリースのタイミングで、エラーレート、レイテンシの監視、アラーム通知の仕組みと、朝会で監視ダッシュボードを見る、というプロダクト運用を行うスタートラインに無事立つことが出来ました。

今後の課題

今回のフェーズでは、AIのモデルの品質の可視化や監視はスコープ外とし、まずはプロダクトのSRE的な監視基盤の構築をゴールとしました。 長い将来を考えるとプロダクトサービスはAIを包含して新しいステージ、新しい付加価値へさらに進化していくと予想されます。AIを含めて「顧客に価値を安全に素早く届ける」ために、

• AI部分を含めた安全を担保する網羅的なテストを、
• バランス良く形を保った高速なテストで品質を担保しつつ、
• 自動化されたテストにより、自動化されたデプロイメントに組み込む

必要があるのですが、現状AIのテストは手法が確立されておらず、優秀なアノテーターによりデータセントリックに学習データの品質を高めていくのが有効であり、Human in the loopで人間の目をはさんで定性評価して品質をモニタリングしていく必要があるという認識です。

弊社では、4月からはACES Meetでモデルの継続的学習パイプラインと、学習で出来たマルチモデルを素早く定性評価できる環境を構築していきます。 MLOpsとしてとてもやりがいのある仕事であり、今この瞬間今ここでしかできない仕事を一緒にチャレンジして頂けるメンバーを絶賛募集中です！

所感

昨年ACESにJoinして1年が立ちますが、ACES Meetを僅かのBizメンバーで必死に立ち上げているのを近くで見つつ、私自身も時にサーバAPI実装に入ったりでフルスタックエンジニアとしての仕事の醍醐味を感じつつ、プロダクトリリースにたどり着くところを目のあたりにして、0から1になるところに立ち会えて、これはそう何度も経験できるものではない貴重な経験だなというのを私自身もしみじみ感じながら仕事をすることが多かったです。素晴らしいデザイナー、素晴らしいフロントエンジニア、素晴らしく強いアルゴリズムエンジニア、尊敬出来る素晴らしい方たちと近くで仕事が出来たことに感謝。
そして、Happy monitoring!

ACESでは、積極的に採用を行っています。ACESに興味をもっていただいた方がいらっしゃいましたら、お気軽にご連絡下さい！

ACESのリクルートページはこちら↓

acesinc.co.jp

Multiple-object tracking (MOT) アルゴリズム研究の歴史 ~DeepSORT 以後の SOTA モデル紹介~

こんにちは、株式会社 ACES (以下 ACES) の檜口です。普段はアルゴリズムエンジニアとして Deep Learning (以下 deep) を中心とする研究開発業務に従事しています。

このポストは multiple object tracking (MOT) の解説と簡単なアルゴリズム紹介をした前回ポストの続きで、引き続き現代 MOT のアルゴリズム紹介を行います。前回記事で紹介したキーワードの説明は省略されているため、適宜前回記事を見返していただければと思います。

• (2016年) 物体検出を deep で置き換え、association はカルマンフィルタを基にした affinity matrix を介して行う
• (2016年〜2017年) Deep model で抽出した特徴量をベースにして類似度を計算して affinity matrix を利用する
• (2019年〜現在) 一体型モデルの導入
  • ex. JDE, FairMOT
• (2021年〜現在) 類似度計算の改善
  • ex. UniTrack
• (2020年〜現在) Transformer の導入
  • ex. TransMOT
• (2021年〜現在) カルマンフィルタモデルの拡張
  • ex. ByteTrack

今回紹介するのは上記研究の発展軸のうち後半四つです。(最後の一つは前回ポストにはない項目ですが、新たに付け加えました。)

MOT の代表的なアルゴリズム

1. 一体型モデルの導入

MOT モデルは物体検出とオブジェクトの特徴抽出を別々の deep モデルを用いて行う分離型と、物体検出とオブジェクトの特徴抽出を単一の deep model で行う一体型が存在します。分離型は訓練の容易さやアルゴリズムの保守性が売りですが、二つの deep モデルを直列に利用する関係でどうしても推論速度が遅くなりがちです。一体型モデルは訓練は難しくなるものの、単一の deep model で推論を完結させられるため、速度面で優れています。また、オブジェクトの周辺の文脈を特徴量に反映できる (と期待される) ため¹、うまく学習できた際には分離型のモデルより高いパフォーマンスを発揮することができます。

1.1. JDE

ポイント：一体型モデルの学習難易度を下げる

一体型のマイルストーンの一つは2019年に提案された JDE だと思います²。このモデルは本ポスト執筆時点で papers with code の MOT ベンチマーク で9位に位置しています。

JDE はマルチタスク学習の各ロスの係数を自動調整する機構を導入して物体検出と特徴抽出の学習を一つのネットワークで行う際のハードルを下げたことが貢献として大きいと思います。なお、この機構は MOT に限らずマルチタスク学習の文脈で広く使えるもので、元々はセグメンテーションや深度推定などのマルチタスク学習を行うために提案されたようです。

また、tracklet の appearance feature を移動平均で保持していることも特徴です。過去のモメンタム項を重ために持たせた appearance feature は交錯などの直近フレームでの摂動に対して強くなるので、ID switch をかなり抑制することができます。

1.2. FairMOT

ポイント：一体型モデルの物体検出タスクと特徴抽出タスクのバランスを適正化する

FairMOT は2020年に提案された一体型のモデルで、JDE の強化版³という表現がしっくりきます。マルチタスク学習の係数自動調整機能などを引き継いだ上で、マルチタスク学習における物体検出と特徴抽出の学習の不均衡を改善する (二つの学習を fair にする) 工夫が数多く組み込まれています。YOLOv4 のようにベストプラクティスの集大成といった感じの研究です。このモデルは本ポスト執筆時点で papers with code の MOT ベンチマーク で2位に位置しています。

FairMOT の JDE に対する差分として大きいものは、anchor-based のネットワークではなく、anchor-free のネットワークを採用したことです⁴。具体的には FairMOT では CenterNet を学習のパラダイムとして採用しています。anchor-based のモデルは一つの anchor に複数の target が紐づいてしまう && 一つの target に対して複数の anchor が紐づいてしまい、これが特徴抽出の学習を進める上で障害になることなどが指摘されています。実際、ablation study では anchor-based のモデルより anchor-free のモデルの方が高いパフォーマンスが出ています。また、オブジェクトの特徴量の次元を減らすことでも物体検出と特徴抽出の学習の不均衡を改善できたことが報告されています⁵。

Anchor-based と anchor-free の比較。論文中では既存の anchor-base のモデルは anchor がオブジェクトに対して不適当な結びつき方をするために特徴抽出の学習がうまくいかないことを指摘している。図は FairMOT の論文から引用した。

2. 類似度計算の改善

MOT において視覚的な特徴量を deep model によって抽出して紐付けに利用する際には、コサイン類似度を利用するのが主流です。実際、今までに紹介した DeepSORT や JDE 、FairMOT はいずれもコサイン類似度を利用して紐付けを行なっています。ところで、オブジェクト同士の類似度が測れるのであれば、類似度の指標は必ずしもコサイン類似度である必要はありません。UniTrack は紐付けに利用できる類似度はコサイン類似度だけではないことを示した論文として価値が高いと思います。

2.1. UniTrack

ポイント：コサイン類似度に変わる類似度を利用する

UniTrack はトラッキングタスク (SOT, MOT, PoseTrack 等) に共通した特徴抽出器は作れないか？という問いの元に提案された手法です。結論から言えば、トラッキングに使う特徴抽出器は ReID や MOT のデータセットで学習する必要は必ずしもなく、大規模データセットで pretrain した教師あり or 自己教師あり学習済みモデルであればよいということが主張されています。このモデルは本ポスト執筆時点で papers with code の MOT ベンチマーク で3位に位置しています。

UniTrack はトラッキングにおける特徴抽出器のチョイスの幅を広げたという点がメインの主張ではありますが、それ以外にもコサイン類似度に代わる、Reconstruction Similarity Metric (RSM) と呼ばれる新しい affinity matrix の提案がなされている点は注目に値します。RSM はデータセットにもよりますが概ねコサイン類似度よりもパフォーマンスが高く、既存のモデルにも比較的簡単に組み込めるので、個人的にはかなりのブレイクスルーだと思っています。今後は UniTrack の成功を受けてコサイン類似度に代わるパフォーマンスの高い affinity matrix 計算方法に関する提案が増えることを期待しています。

3. Transformer の導入

3.1. TransMOT

ポイント：オブジェクトの紐付けに transformer を利用する

TransMOT はオブジェクトの移動制約を transformer によってモデリングしたアルゴリズムで、物体の移動を data driven に学習することができます。このモデルは本ポスト執筆時点で papers with code の MOT ベンチマーク で1位に位置していますが、残念なことに実装は公開されていません。カルマンフィルタを使わずこのベンチマークのトップを取っているモデルは自分が MOT を追い始めてから初めてだと思います⁶。

既存の多くのアルゴリズムが cost matrix を経由して association を作成していたのに対して、TransMOT は過去のフレームの情報と現在のフレームの情報を入力にして association matrix⁷ を直接出力します。より具体的には、TransMOT は検出されたオブジェクト間の関係性を「オブジェクト同士の IoU が非零であればフラグが立つような隣接行列」と「オブジェクト同士の IoU を格納したオブジェクト間ノードの重み行列」で表現したものと検出されたオブジェクトの特徴量を入力として、Spatial Graph Transformer Encoder / Temporal Transformer Encoder / Spatial Graph Transformer Decoder の3つの encoder / decoder を用いて association matrix を出力します。それぞれの encoder / decoder は次のような働きを持ちます。

• Spatial Graph Transformer Encoder: それぞれのフレームで独立に空間的な情報をエンコードします。空間的な情報とはオブジェクト間の位置関係を記述した隣接行列と重み行列です。
• Temporal Transformer Encoder: フレーム間の時系列的な情報をエンコードします。Spatial Graph Transformer Encoder で encode した各フレームの情報を統合する役割を持ちます。
• Spatial Graph Transformer Decoder: 上記2つの encoder を通して得られた情報をデコードして association matrix を出力します。

TransMOT の概略図。2つの encoder と1つの decoder を用いて association matrix を直接出力する。図は TransMOT の論文から引用した。

TransMOT の優れた点はカルマンフィルタなどのヒューリスティクスに頼っていた物体の動きやオブジェクト間相互作用を deep model に押し込めて高いパフォーマンスを保ちつつ学習可能にしたことです。今までも物体の動きを deep model でモデリングするような提案はいくつかされていましたが、カルマンフィルタ＋ハンガリアンアルゴリズムタイプのアルゴリズムを超えるようなものはありませんでした。コードが公開されていないのは残念ですが、もし公開されたら TransMOT のようなアプローチのモデルがどんどん update されていくような気がします。

4. カルマンフィルタモデルの拡張

4.1. ByteTrack

ポイント：deep 特徴量をベースにしたマッチングを廃してカルマンフィルタのみを使って高速に予測する

ByteTrack は FPS を向上させるために deep 特徴量を使わず、カルマンフィルタによる移動予測だけでトラッキングを行います。このモデルは MOT17 のリーダーズボードにおいて執筆時点で1位を獲得しています。ByteTrack の名前の由来は tracking BY associaTing Every detection box instead of only the high score ones の略とのことですが、これはおそらくこじつけで、ByteDance が開発したからこの名称がついていると思われます。

一般的なトラッキングアルゴリズムが confidence の低いオブジェクトをトラッキング対象から外して紐付けを行うのに対して、ByteTrack は confidence の高いオブジェクトを紐付けを先に行い、その後 confidence の低いオブジェクトの紐付けを行う2段階の紐付け⁸を提案しています。Deep 特徴量を使っていない＋カルマンフィルタでオブジェクトの移動予測と紐付けを行うことから、ByteTrack は前回記事で紹介した SORT の紐付けを2回行うように改良したアルゴリズムと捉えることができそうです。実際論文中でも SORT や DeepSORT との比較が行われています。

カルマンフィルタを使うトラッキングアルゴリズムは物体検出の精度が重要になってくるため、論文中では物体検出器のチョイスに紙面が多めに割かれています。ByteBrack は物体検出器に COCO で pretrain された yolov5x を使い、人物オブジェクトを多く含むデータセット (MOT17/CrowdHuman/CityPerson/ETHZ) で finetune しています。物体検出器が強力ならカルマンフィルタだけでもトラッキングができるというのは SORT の時代 (2016年ごろ) から主張されていましたが、ここまで高いパフォーマンスを発揮できるのは驚きでした。

まとめ

今回の記事では現代的な MOT アルゴリズムの紹介を行いました。今回紹介した研究は比較的開拓されたばかりでこれからも発展のしがいがあるような領域だと思います。個人的にはコサイン類似度以外の類似度を採用した UniTrack や類似度を implicit に表現した TransMOT は非常に面白い研究だと思います。MOT アルゴリズムを実運用に移していくとなると、オクルージョン等で必ずしもオブジェクトが常に見えているわけではないので、やはり ByteTrack のようなオブジェクトの視覚的情報を一切使わないモデルはちょっと厳しくて、類似度をうまく表現していくことが大切であるように感じます。今後もこの方面の研究が進むことを期待しています。

ACESでは積極的に採用を行っています！

ACESでは、積極的に採用を行っています。ACESでは「アルゴリズムで、社会をもっとシンプルに」するために様々な観点からアルゴリズムの開発を行っています。ACESに興味を持っていただいた方がいらっしゃいましたら、お気軽にご連絡下さい！

会社紹介資料はこちら↓

speakerdeck.com

ACESのリクルートページはこちら↓

acesinc.co.jp

---

1. 分離型のモデルはオブジェクトを含む bounding box を入力として特徴抽出をするため、オブジェクトの周囲の文脈を特徴に反映させることができません。↩

2. JDE は一体型モデルを初めて提案したわけではないですが、マルチタスク学習の係数自動調整機能などのちのアルゴリズム (FairMOT) につながる提案をしているためピックアップしました。↩

3. 実装を眺めると FairMOT のコードの大半が JDE から移植されています。↩

4. Anchor-based とは物体検出モデルを学習する際に、特定の畳み込みカーネルに特定のサイズの target の予測を担当させるような仕組みを指します。大抵の物体検出モデルは anchor-based であり、例えば Faster-RCNN や EfficientDet 、yolo シリーズ (yolox を除く) などは anchor-based です。一方、anchor-free とは物体検出モデルを学習する際に anchor-based のように特定のカーネルと target を紐づけることなく、一つの畳み込みカーネルで全ての予測をさせるようなモデルを指します。Anchor-free モデルの代表例は CenterNet です。↩

5. MOT のメトリクス全てにおいて特徴次元が低次元の方が良いというわけではないことには注意が必要です。ただ、低次元の方が計算量が少なく、推論が高速化しやすいので、同じくらいのパフォーマンスなら基本的に次元数は少ないほど良いと思います。↩

6. 厳密には low confidence のオブジェクトに対してはカルマンフィルタによる予測とそれに基づく association を行ってます。↩

7. (num_tracklet, num_detection) 型の行列であって、 tracklet_i と detection_j が紐づいている時に (i, j) 成分が 1 、紐づいていない時に 0 となるような行列。↩

8. 2段階の紐付け自体は POI などでも提案されています。↩

Multiple-object tracking (MOT) アルゴリズム研究の歴史 ~現代 MOT の基礎となった SORT/DeepSORT の紹介~

こんにちは、株式会社 ACES (以下 ACES) の檜口です。普段はアルゴリズムエンジニアとして Deep Learning (以下 deep) を中心とする研究開発業務に従事しています。

ACES ではリアルな現場の画像認識を行う機会が多いです。この時さまざまなアルゴリズムを利用していますが、その中でもトラッキング技術は多くのアルゴリズムの基礎となるモジュールとして重要です。例えば、複数の人物がいるような状況で、ある人物に着目してなんらかの分析を行いたいときなどにはトラッキング技術が必須になってきます。

トラッキング技術は研究領域では multiple-object tracking (MOT) と呼ばれており¹、動画とオブジェクトのクラスが与えられたときに、動画中の対象のオブジェクトの位置を特定しつつ、個別のオブジェクトがどのように移動したかを追跡するタスクです。Machine learning の文脈でより正確に記述するならば MOT は動画中のオブジェクト位置を bbox² で検出しつつ (物体検出、object detection) 、同一のオブジェクトが動画中で検出された時には、それらが同一の ID を持つようにする (フレーム間でのオブジェクトの紐付け、association) というタスクになっています。

トラッキングの概略。連続する動画フレーム t と t+1 において、同一のオブジェクトである青い服の男の子 (ID: 2) と赤い服の女の子 (ID: 3) には同じ ID を付与する必要がある。一方で、フレーム t で画面左に消えていった疾走する男性 (ID: 1) の ID はフレーム t+1 では検出されないため、ID: 1 を誰にも割り当ててはならない。また、画面右上に新しく現れたゼッケンを着けた男性 (ID: 4) には新しい ID を発行する必要がある。

MOT は deep model を使った物体検出モデルがパフォーマンスを伸ばすにしたがって、物体検出モデルの出力を利用してトラッキングを行う tracking-by-detection というパラダイムで大きく性能を向上させました。Tracking-by-detection 方式を採用した MOT アルゴリズムは2016年以降、現在まで state-of-the-art であり続けており、その動向からは目が離せません。

このポストでは tracking-by-detection 方式の MOT における基本的なアプローチを解説したのち、アルゴリズム発展の歴史を紹介したいと思います。MOT アルゴリズム発展の軸としては以下のようなものがあると思います。

• (2016年) 物体検出を deep で置き換え、association はカルマンフィルタを基にした affinity matrix を介して行う
• (2016年〜2017年) Deep model で抽出した特徴量をベースにして類似度を計算して affinity matrix を利用する
• (2019年〜現在) 一体型モデルの学習難易度を下げる
• (2021年〜現在) コサイン類似度に変わる類似度を利用する
• (2020年〜現在) Transformer の導入

今回紹介するのは上記研究の発展軸のうち前半二つです。

MOT のキモ 、association

Tracking-by-detection パラダイムに従う場合、物体検出を独立したタスクとして切り離して考えると、MOT の本質はフレーム間のオブジェクトの紐付け、すなわち association にあることがわかります。このセクションでは具体的な研究の紹介に移る前に MOT のキモである association について解説します。

MOT³ では t-1 フレーム目までのオブジェクトの追跡情報 (tracklet) と t フレーム目での物体検出の結果 (detection) を逐次的に紐づける必要があります。このような紐付けを動画の最初のフレームから最後のフレームまで連続して行うと、動画全体のオブジェクトのトラッキングができるようになります。

紐付けに際して tracklet と detection は似ているはずであるという仮定を導入します。つまり、似ている tracklet と detection をフレームごとに繋いでいって、最終的に動画全体でのオブジェクトの軌跡を得ることを考えます。この時の『似ている』とは以下のような状態を指します。

1. 検出された bbox と tracklet から予測された bbox の位置が近い
2. 検出された bbox と tracklet から予測された bbox の形状が似ている
3. 検出された bbox の中と以前 tracklet に紐づけられた bbox の中の視覚的な特徴が似ている

この仮定は動画のフレームレートが十分高ければ尤もらしい仮定だと思います。実装上は 1、2の tracklet からの bbox の予測はカルマンフィルタ⁴を、3の視覚的な類似度は deep model によって抽出された特徴ベクトルを利用することによって達成されます。

さて、上記のような tracklet と detection の類似度が計算できたとすると、その類似度の和が最大になるような組み合わせを計算すれば最適な紐付けが決められそうです。そのような目的を達成できるアルゴリズムとしてはハンガリアンアルゴリズムという割り当てアルゴリズムが知られており⁵、MOT アルゴリズムで広く活用されています。ハンガリアンアルゴリズムの概要は英語版 Wikipedia に記述が見つかります。なお、ハンガリアンアルゴリズムは scipy.optimize.linear_sum_assignment などから利用できるので、自前で実装する必要はありません。

さて、物体検出を所与のものとして、さらにハンガリアンアルゴリズムを割り当てアルゴリズムとして採用することを決めてしまうと、MOT というタスクはハンガリアンアルゴリズムに供する affinity matrix (tracklet と detection の類似度を並べた行列)⁶ を作るタスクであると言い換えることができます。実際、近年発展した MOT アルゴリズムのほとんどがこの affinity matrix をいかにうまく作るかにフォーカスして研究が行われています。

MOT の代表的なアルゴリズム

2.1. SORT

ポイント：物体検出を deep で置き換え、association はカルマンフィルタを基にした affinity matrix を介して行う

物体検出を行う deep model で一番有名なのは何かというのには議論もあるかと思いますが、個人的には Faster R-CNN かなと思っています。この辺りで deep による物体検出の基礎は概ね確立されたように思います。Faster R-CNN が公開されたのは2015年のことですが、このような物体検出モデルの目覚ましい発展を受けて2016年に公開されたのが SORT です。SORT は物体検出モデルからトラッキングのターゲットとなる bbox の情報を受け取り、それら bbox を直前フレームまでの情報からカルマンフィルタによって予測された bbox と紐付けます。このとき、affinity matrix はカルマンフィルタによって予測された tracklet の bbox と検出された bbox の IoU⁷ を使います。

SORT の優れた点はとにかく高速に動作することで、計算時間は ①物体検出モデルの推論時間 ②カルマンフィルタの予測 ③affinity matrix の計算 (= IoU の計算) ④ハンガリアンアルゴリズム にかかる時間程度です。これらの計算は ① を除いて全て非 deep であり、物体検出さえ動作すれば紐付け自体は CPU 上でも高速で動作します。また、物体検出のモデルのパフォーマンスが高ければ高いほど SORT は非常に高いパフォーマンスを発揮します。実際、MOT のベンチマークで正解の bbox を使って SORT を動作させると (系列にもよりますが) ほぼ100％に近いパフォーマンスが出て驚いた記憶があります。

逆に SORT の欠点はオクルージョン (オブジェクトが物体の陰に隠れること) やオブジェクト同士の交錯などに弱いことが知られています。association の際に bbox の位置情報しか見ていないので、物陰に一時的に消えたオブジェクトが再び画面に戻ってきたときなどにオブジェクトがカルマンフィルタで予測できる位置に現れてくれないと tracklet が途切れてしまったり、オブジェクトが交錯したときに ID switch (ふたつのオブジェクトの ID が入れ替わってしまうこと) が起きることを避けることができません。

2.2. DeepSORT

ポイント：Deep model で抽出した特徴量をベースにして類似度を計算して affinity matrix を利用する

SORT の欠点はオブジェクトの位置しか見ていないことに由来していたので、位置だけではなく視覚的な特徴量 (appearance feature / visual feature) も考慮すればもっとパフォーマンスが出るのではないか？という仮説の元に研究が進みました。こうして登場したのが DeepSORT です⁸。DeepSORT は SORT の著者らが発表したモデルで、その名の通り deep な特徴量を使って association を行います。

DeepSORT では物体検出モデルによって検出された bbox 領域に対して person-ReID⁹ データセットで学習されたモデル¹⁰を適用して特徴ベクトルを獲得します。person-ReID モデルによって抽出された特徴量は tracklet の持つ特徴量とのコサイン類似度を affinity matrix として association に利用します。ハンガリアンアルゴリズムによって紐付けが発生した tracklet にはその時紐づいた detection の特徴量が登録されます。Association の際には Matching Cascade と呼ばれるアルゴリズムを採用しており、直近で観測があった tracklet に優先的に association を行うようなアルゴリズムを採用しています。

移動制約には SORT に引き続きカルマンフィルタを利用していますが、カルマンフィルタで推定する bbox の状態が変更されていたり、カルマンフィルタによって予測された bbox と検出された bbox の類似度が IoU からカルマンフィルタの推定の不確実さを利用したものに置き換えられたりなどのマイナーチェンジがいくつか施されています。DeepSORT で提案されたカルマンフィルタはこれ以降のカルマンフィルタを用いたほとんどのアルゴリズムに利用されており、MOT におけるカルマンフィルタの利用方法のデファクトを作ったという意味で重要性が高いと思います。

DeepSORT の利点は高速に動作することとオクルージョンに強いことが挙げられます。SORT よりは速度は落ちるものの視覚的な特徴量を紐付けに利用するようにしたことでオクルージョンによって多少の期間観測がなされなかったとしても、再度観測ができた時に紐付けができるようになりました。

DeepSORT の欠点は物体検出モデルによって検出されたオブジェクトを ReID モデルにかけるため、モデル2回分の推論が必要で推論時間がかかることや、検出された bbox を固定サイズにリサイズして特徴抽出を行うため、オブジェクトのサイズを視覚特徴量に反映できない¹¹こと、オブジェクト周辺の文脈を考慮できないことなどがあると思います。また、オブジェクトの移動には引き続きカルマンフィルタを採用しているため、カルマンフィルタの仮定に反するような動きをするオブジェクトは tracklet が切れてしまうことがあります。

まとめ

今回の記事では MOT アルゴリズムで標準的に利用されている association の仕組みとそれ以降の MOT 研究のベースとなるような二つのアルゴリズム (SORT/DeepSORT) について紹介しました。次回記事では DeepSORT 以後に登場したアルゴリズムの紹介をしていきたいと思います。

ACESでは積極的に採用を行っています！

ACESでは、積極的に採用を行っています。ACESでは「アルゴリズムで、社会をもっとシンプルに」するために様々な観点からアルゴリズムの開発を行っています。ACESに興味を持っていただいた方がいらっしゃいましたら、お気軽にご連絡下さい！

会社紹介資料はこちら↓

speakerdeck.com

ACESのリクルートページはこちら↓

acesinc.co.jp

---

1. トラッキングのタスクとしては single object tracking (SOT) や pose tracking などもありますが、この記事では MOT にフォーカスしています。↩

2. bbox は bounding box の略で、画像中のオブジェクトの位置を長方形で囲った領域として表現したものです。↩

3. ここではオンラインで動作する MOT を仮定しています。なお、近年提案されているアルゴリズムのほとんどはオンラインでの動作を仮定しています。↩

4. MOT で使われるのは専ら線形カルマンフィルタで、これはオブジェクトの動きに等速直線運動を仮定しています。実際、動画のフレームレートが十分に高ければ、オブジェクトの動きは等速直線運動で近似できそうなので、実用上はうまくいくことが多いです。しかしながら、突然進行方向を切り返すなどの動きをするとうまく動きを予測することができない場合があります。あるいは長期間のオクルージョンが発生した場合にはオブジェクトの動きに等速直線運動を仮定するとうまく動きが予測できない場合があります。そのような場合には本来紐付けられるはずだった tracklet と detection が紐づけられなくなり、MOT アルゴリズムのパフォーマンスが下がってしまうことが問題点として指摘されています。↩

5. 実際には類似度に -1 をかけたコストを考えて、コスト合計が最小になるような組み合わせをハンガリアンアルゴリズムで計算します。↩

6. あるいは cost matrix についての研究と言い換えることもできます。Cost matrix は tracklet と detection の類似度の代わりに距離を表現した行列です。こちらの用語も MOT 研究では頻繁に使われます。↩

7. IoU は intersection over union の略で bbox 同士の重なり度合い (近さ) の指標として使われます。↩

8. DeepSORT は appearance feature を使ったアルゴリズムの初出ではありません。ここでは SORT との差分がわかりやすかったため採用しました。DeepSORT 以前の appearance feature を使うモデルとしては POI が比較的有名だと思います。DeepSORT でも POI の著者が公開している detection の結果をアルゴリズム評価のために利用しています。↩

9. Person ReID は与えられた人物 (クエリ) が同一人物かどうかを判定したり、与えられた人物が事前に登録された人物 (ギャラリー) の誰に当たるのかを判定するタスクです。顔認証と類似していますが、一般に顔認証が高解像度の顔にフォーカスした画像を利用するのに対して、person ReID は監視カメラなどの画質の粗い画像でなどから得られる全身の画像がクエリとして与えられることなどが違いとして挙げられます。↩

10. 他の特徴量ベースのモデルでもほぼ共通ですが、person-ReID では ResNet-base のネットワークアーキテクチャが使われることが多く、特殊なアーキテクチャはあまり使われない印象です。リアルタイムでのトラッキングを目指すときには特徴抽出は可能な限り高速で動作した方が良いので、あまり複雑なネットワークアーキテクチャは使われづらいという背景があるかもしれないです。↩

11. 解像度の違いなどによって実質的にサイズが考慮されている可能性はあります。↩

マスク着用時にも認証可能な顔認識モデルを作成した話

こんにちは、株式会社ACESの市川です。アルゴリズムエンジニアとしてDeep Learningを中心としたアルゴリズムの開発・検証を進めています。

ACESでは「アルゴリズムで、社会をもっとシンプルに。」というビジョンの元、「Issue driven, simple solution.（最重要の課題発見から、最高の課題解決をしよう。）」、「Fact based, build trust.（客観的事実を大切にし、信頼関係を構築しよう。）」、「Gemba first, verify quickly.（自分の足で情報を得て、自分の手で検証しよう。）」という行動指針を掲げ、画像認識を中心に様々なアルゴリズムの開発を行っています。

その中でも、顔認識アルゴリズムは多岐に渡る用途を持つAIアルゴリズムのひとつで、研究・ビジネル両面から高精度のモデルが多数開発されています。しかし、現実世界の「Issue」を考えると、特に近年は「マスクをつけている場合でも正確に認証が可能な顔認識アルゴリズム」が必要になっているものの既存のモデルではこれに対応できないことが指摘されています。

参照：マスクがいかに顔認識を阻んでいるか--NISTが研究結果を発表

japan.cnet.com

今回は、その「Issue」を解決するために取り組んだ「マスク対応型顔認識モデルの開発」について紹介させて頂きます。

顔認識アルゴリズムの基本

顔認識を行う方法にはいくつか選択肢がありますが、現在主流となっている手法のひとつに顔特徴量ベースの手法があります。この手法では、特徴抽出器を利用して顔画像からその人物固有の特徴ベクトルを求めます。この特徴ベクトルが得られれば、異なる2つの顔画像について、特徴ベクトル同士の類似度を比較することで2つの顔画像が同一人物か否かを推定することができるようになります。

顔画像を入力として、ニューラルネットワークはその人物固有の特徴ベクトルを出力する

特徴ベクトルは当然どのようなものでもいいというわけではなく、「同一人物同士は近く、異なる人物同士は遠い」ような性質を持つ必要があります。この性質を満たす特徴ベクトルを得るニューラルネットワークを学習させるために、距離学習を用いて学習が行われます。距離学習についてはさまざまな文献があり分かりやすくまとまっているので、ここでは割愛したいと思います。

同一人物同士は近く、異なる人物同士は遠くなるような特徴ベクトル

距離学習については例えば以下の記事が分かりやすいのでご参照ください。

qiita.com

マスク対応の方針

なぜ一般的な顔認識モデルはマスクをつけている人物の顔認識が苦手なのか？それには2つの原因があります。

1. 口元がマスクで隠れているため、質の高い特徴ベクトルを得るために使える情報が減ってしまっている
2. モデルを学習する際に用いるデータの中に、マスクをつけている写真が著しく少ない

1.についてはまさにその通りなのですが、例えば人であればマスクをつけていても誰か認識できるという経験事実があるため、目元から上の情報だけでも十分「その人らしさ」を抽出できるのではという仮説が成り立ちます。

この仮説に基づいて、ニューラルネットワークを「目元から上という限られた情報」のみからでも特徴ベクトルを推定できるように学習させるという方針のもと、2.の問題を同時に解決するために「人工的にマスク付きの顔画像を生成してデータ拡張を実施する」というプロセスを実行することにしました。

人工マスクデータの作成

まず「マスクを顔のどの位置につけるのか」を定めるために、顔特徴点推定モデルを利用します。これは顔画像を入力として、定められた顔特徴点の座標を推定するアルゴリズムで瞬き検知や視線推定などの技術に応用されています。

以下の画像のように、顔特徴点推定モデルの出力結果から顔の輪郭がわかるので、この輪郭に沿うようにマスク画像を合成することで、マスク付き画像を作成することができました。

まず顔の特徴点を抽出してマスクを合わせる位置を定め、マスク画像を合成する

上記のようなマスクの合成は単純なパターンですが、他にも人物の向きや画像の色調・マスクの多様な種類に合わせて様々なパターンの合成をしています。

学習結果

マスク対応モデルの有効性を検証するため、検証用の画像に人工的にマスクを合成したものCALFW+mask)と本物のマスク付き画像を集めたデータセットであるMFR2 というデータセットを用いて、マスク対応をしていないモデルとの精度比較を実施しました。

指標としては「2枚の画像が与えられた時にそれが同一人物か否かを判定する際の精度」(=ACC)を用いました。

結果は以下のようになり、どちらのデータセットでも4,5%程度の精度改善が実現しました。

また、Masked Face Recognition Competitionというコンペに参加しました。これはマスクをつけた顔画像に対する顔認識モデルの精度を競うコンペで、様々な背景のもと様々なマスクを着用した人物同士について人物同士が一致しているかどうかを正しく判定できるかを評価します。

上で説明した手順で学習させたモデルはこのコンペで3位を獲得することができました。なお、今回紹介したモデルや論文に掲載されているモデルはベンチマークの内容で、実際に提供しているモデルは、データセットの拡充やクレンジング、学習アルゴリズムの工夫をはじめ、様々な工夫を行って、さらなる精度向上も行っています。

コンペの結果は以下の論文にて公開されています。

ieeexplore.ieee.org

(arxiv: https://arxiv.org/abs/2106.15288 )

既存の顔認識モデルとの比較

上で示した学習結果はあくまでベンチマーク指標を用いた定量的な結果なので、現実世界における顔認識を考えた時に有効なモデルになっているかを確認する必要があります。

そこで、今回はAWSのサービスのひとつで、広く用いられているAmazon Rekognitionの「顔の比較」デモと比較してみました。この「顔の比較」は参照画像を比較画像を入力すると、比較画像の中から顔を検出して、それぞれの顔について参照画像の顔と一致しているかどうかを出力してくれます。

デモの様子。かなり正確な顔認証ができるようです

早速自分の顔写真で試してみました。比較画像は会社のメンバーと撮影した写真を使用します。

実行結果。顔の検出・認識ともに高精度で実現できていることが分かります。

光の当たり具合などでパッと見た時の印象は変わっているかもしれませんが、正確に同一人物を当てることができています。

では参照画像をマスク付きにした場合はどうでしょうか。

マスク付きの画像を入力した時の結果

比較画像内の全員が「不一致」と判定されました。やはり、マスクをつけている画像に対しては苦手なようです。

次に、今回開発した顔認識モデルを用いて一致度の計算を行なってみます。

同一人物の判定は50%を閾値として判定しているので、マスク着用時と非着用時、どちらにおいても正しく同一人物を判定できていることが分かります。

ACESでは積極的に採用を行っています！

ACESでは、積極的に採用を行っています。ACESでは「アルゴリズムで、社会をもっとシンプルに」するために様々な観点からアルゴリズムの開発を行っています。ACESに興味を持っていただいた方がいらっしゃいましたら、お気軽にご連絡下さい！

会社紹介資料はこちら↓

speakerdeck.com

ACESのリクルートページはこちら↓

acesinc.co.jp

クラウド上でアルゴリズムを素早くセキュアに顧客に提供するためのインフラ基盤 (AWS Transit Gatewayを活用した構築パターン)

こんにちは、株式会社ACESのソフトウェアエンジニアの稲田です。 ACESは画像認識アルゴリズムに強みを持つAIスタートアップです。ACESでサーバエンジニアはどんな仕事してるのだろう？という疑問に答えるべく、ACESのソフトウェア技術関連の発信をしていきたいと思っております。 この記事では、ACESのセキュリティの根幹を支えるネットワークインフラを紹介させて頂きます。

ACESでは保険/スポーツ/報道/小売/建設/製造業など様々な顧客の課題に対してDX提案/取り組みを行っており、抱えているプロジェクト数も多くなっております。 そこで、当たり前の話ですが、

• 顧客毎のデータをセキュアに保つ
• オペミス等で誤って他の顧客の環境を壊さない

を満たすデータ管理が必須です。 ACESではこれを実現するため、以下のインフラを構築しております。

• B2Bビジネスにおいてクラウドを利用する場合、顧客毎に利用するAWSアカウントをわけ、顧客データにアクセスできるメンバーをプロジェクトメンバーに限定する
• 一方で認証や監視等の共通基盤はまとめる

顧客毎にAWSアカウントをわけることで、AWSがクラウドで提供するセキュリティ責任がそのままダイレクトに顧客データに対して担保されることを顧客にわかりやすく説明することができ、安心してデータをお預け頂くことが出来ます。 また、顧客のIT内部統制などのコンプライアンス上の観点から、データへのアクセスログ等の監査ログの取得が必須となる場合にも、AWSアカウントをわけることで比較的簡単かつ柔軟に対応することが可能となります。

ここからは技術的な話にフォーカスして、主にサーバエンジニア向けに「セキュリティを担保しつつ認証や監視等の共通基盤はまとめる」部分をACESではどうやって実現しているか、システム事例紹介させて頂きます。

技術概要

ACESでは前述のインフラを構築するためにAWS OrganizationsとAWS Transit Gatewayというサービスを活用しています。AWS Organizationsを使って複数のAWS アカウントを管理しつつ、認証や監視等の共通基盤は専用のAWSアカウント(shared serviceアカウント)に集約しています。そして、個別のアカウントとshared serviceアカウントの通信ネットワークをAWS Transit Gatewayによって接続しています。利用シーンは大きく2パターンが存在しており、

1. アルゴリズム推論単体をAPIとして提供 (アルゴリズム単体利用構成)
2. アルゴリズム推論を活用したサービスを提供 (フルセットサービス構成)

があります。構築の中心となるAWS Transit Gatewayを説明した後に、これらの2パターンのネットワークの構成の詳細について説明していきます。

AWS Transit Gateway とは

まず、構築の中心となるAWS Transit Gatewayについて説明します。AWS Transit Gatewayは、AWSアカウントをまたぐネットワーク(VPC)やオンプレミスを含めた異なるネットワークを一つの中央ハブで接続して通信、通信制御出来る仕組みです。特徴として以下の項目が挙げられます。

• VPC間接続を簡単に管理するためのシンプルなリージョナルゲートウェイ
• 数千のVPC, VPN, DirectConnectを接続可能
• アタッチメントごとのルーティングを可能にするルーティングドメインのサポート

引用元：[AWS Black Belt Online Seminar] AWS Transit Gateway

ネットワークは合理化され、スケーラブルになります。AWS Transit Gateway は、各 VPC または VPN との間のすべてのトラフィックをルーティングします。すべてのトラフィックを 1 か所で管理して監視できます。

引用元：AWS Transit Gateway（VPC およびアカウント接続を簡単にスケール）

インフラ構築方針

構築の方針を技術的にブレークダウンすると以下のような項目を実現することになります。

• インフラ構築のリードタイムを最小限にする
• アルゴリズム単体利用からフルセットサービスまで柔軟なユースケースに対応できるインフラ構成を実現する
• shared serviceアカウントを活用して共通利用可能な機能を管理する

ネットワーク構成

アルゴリズム単体利用構成

まず、学習済のアルゴリズムをAPI利用する場合ですが、shared serviceで基本的な認証や利用ログ等を含む共通的なFront画面とAPIを提供しており、shared serviceからアルゴリズムリポジトリテーブルを参照してアルゴリズムのendpointを特定しTransit Gatewayを経由してアルゴリズム推論を実行します。

ネットワークの簡単な説明を致しますと、shared serviceアカウントのネットワークを10.0.0.0/16、顧客アカウントを10.1.0.0/16としてTransit Gatewayで接続して、必要なネットワーク(VPC)間のみ通信可能となるようルーティングテーブルを設定します。個別サーバへのセキュリティは基本的には必要なセキュリティグループに所属していない場合はアクセス不可となり、セキュリティグループを作成しアクセス権を付与して担保します。 顧客が増えますと10.2.0.0/16、10.3.0.0/16とネットワークが増えていきますが、各々の顧客のネットワークはルーティング上、相互参照せず、shared serviceとのアクセスのみ可能となっています。

フルセットサービス構成

推論だけではなくて何らかの個別のドメインデータを持ってサービスを提供する場合はオーソドックスに顧客アカウントでサービスを構築します。この場合はshared serviceの認証や利用ログ等マイクロサービスで提供される機能を必要に応じて利用できます。ここまでくるとAWSアカウントをまたいだ認証情報を持っていなければ、Transit Gatewayは使わず、顧客アカウント内に全部機能を持ってしまって顧客アカウント内でネットワークは閉じてしまっても良いです。

各々の要素はInfrastructureAsCodeでテンプレート化できます。InfrastructureAsCodeでテンプレート化はエンジニアみんな大好きの楽しいお仕事です。

所感

スタートアップのスピード感を保ちながら、守るべきセキュリティーは担保するという課題を、大きすぎる仕組みにならず適切な手早さで実現できている構成だと思います。

顧客毎にAWSアカウントをわけると一言で言ってしまえば簡単ですが、API提供する場合個別AWSアカウントにAPI認証基盤を各々作るのか（例えば認証用に個別にbackendのDBの構築が必要な場合、DBの管理やDBのインスタンス費用を個別に持つのが果たして適切なのか）、実際の構築作業をはじめると多くの細かな問題と作業に悩まされてしまいます。 すぐ顧客にサービスを提供したいというビジネスのニーズは、InfrastructureAsCodeでインフラをコードでテンプレート化することで実現可能にも思えますし、実際できなくはないですが、NATや運用系のリソースを含めたフルセットのテンプレートはなかなかに重く、出来れば各々のビジネスで使うAWSアカウントで作成するリソースセットは最小限の依存関係に留め、誰でも理解できるレベルの小さなテンプレートにしたいものです。

また、ネットワーク周りのインフラは歴史ある組織だと既にVPC Peering等で実現している部分があったりで、それをわざわざ作りなおすかというとなかなかタスクの優先度の観点で後回しになりがちで、AWS Transit Gateway使って今どきのいい感じのシンプルなネットワークインフラを作ってみたくてもなかなか機会がない、組織が微妙に大きすぎてネットワークインフラの再構築はなかなか手がでないとかあったりするのではないでしょうか。 その点、スタートアップだとまっさらなキャンパスでワクワクしながら今どきのAWSのネットワーク構成を構築することができたりします。まだまだまっさらなキャンパス(=最新の技術を使ってみることでスキルが身に付きエンジニアとして成長する領域)はいっぱいあります。

ACESではAWSマルチアカウント構成をAWS organizationsとAWS Single Sign-On構成で実現していますが、こちらのご紹介はまたの機会に。

おわりに

この記事では、ACESのAWSマルチアカウントのネットワークインフラ構成をご紹介しました。 ACESでは、積極的に採用を行っています。ACESに興味をもっていただいた方がいらっしゃいましたら、お気軽にご連絡下さい！

ACESのリクルートページはこちら↓

acesinc.co.jp

モーションキャプチャスタジオを借りて3D姿勢推定用データセットを構築した話

こんにちは、株式会社ACESの武市です。アルゴリズムエンジニアとしてDeep Learningを中心としたアルゴリズムの開発や各アルゴリズムを社内外で効率的に利用できるようにするパッケージ化の業務を行っています。

ACESでは「アルゴリズムで、社会をもっとシンプルに。」というビジョンの元、「Issue driven, simple solution.（最重要の課題発見から、最高の課題解決をしよう。）」、「Fact based, build trust.（客観的事実を大切にし、信頼関係を構築しよう。）」、「Gemba first, verify quickly.（自分の足で情報を得て、自分の手で検証しよう。）」という行動指針を掲げ、画像認識を中心に様々なアルゴリズムの開発を行っています。

AIアルゴリズムの開発にはモデルのアーキテクチャに加えて学習データが重要になりますが、特にACESの取り組んでいる現実世界の問題を解決するためには研究用に公開されているデータでは不十分なことも多いので、ACESでは「Gemba」の課題解決のために泥臭くデータの収集を行うことを含めてアルゴリズムの改善を行っています。

今回、普段我々がどのようにして「Gemba first」なアルゴリズムの開発を行っているかを知って頂くため、最近モーションキャプチャスタジオをお借りして行った3D姿勢推定のためのデータセットの構築についてご紹介させて頂きたいと思います。

3D姿勢推定とは

3D姿勢推定とはヒトの姿勢を3次元的に認識する技術のことを言います。3次元的に認識することができるようになるため、2次元の姿勢推定に比べてより高度な分析や多様なアプリケーションが可能になります。

従来は深度カメラが用いられることが多かったですが、近年ではDeep Learning技術を用いることで2次元画像から高精度に認識することができるようになってきています。ACESでも画像から3次元姿勢推定を行う技術の開発を行っています。

3D姿勢推定 [1]

3D姿勢のデータセット

Deep Learningを用いたアルゴリズムの開発には学習データが重要となります。

3D姿勢のデータセットとしてよく用られるものにHuman3.6M Dataset [2]があります。Human3.6Mは11名の被験者を4台のカラーカメラとモーションキャプチャシステムで食事、歩行等の15種類の動作を撮影した計約360万フレームのデータから構成されるデータセットです。

Human3.6Mデータの例

なぜデータセットの構築を行うのか

Human3.6Mのようなデータセットが世の中にあるにも関わらず新たに構築を行う理由は2つあります。

1つ目はデータセットのライセンスに制限があるためです。Human3.6Mもそうですが、公開されているデータセットには商用利用が不可のものが多くあります。

2つ目は多様かつ実世界での利用シーンに適した行動のデータセットを構築することで精度の向上が見込まれるためです。Human3.6Mでは食事や歩行などの日常的な動作を中心に15種類の動作で構築されていますが、ACESが解決しようとしている現実世界の課題では床に横たわっているなどより複雑な動作を認識する必要がある場合もあります。

撮影手順

モーションキャプチャスタジオ

3次元の姿勢データを計測するモーションキャプチャシステムには様々な種類がありますが、一般的には光学式モーションキャプチャシステムが最も高い精度で計測できます。光学式モーションキャプチャシステムを自社で構築するには数百万円単位での投資が必要ですが、国内にレンタルスタジオが10以上あります。複数のスタジオを検討し、今回は株式会社スパイスのモーションキャプチャスタジオを利用させて頂きました。

マーカーの貼り付け

モーションキャプチャ用スーツの上からモーションキャプチャシステムで認識することのできるマーカーを50点以上に貼り付けます。

ACESの社員が被撮影者をしました

モーションキャプチャシステムのキャリブレーション

モーションキャプチャで認識できるマーカーのついたワンドと呼ばれる器具を用いてモーションキャプチャシステムのキャリブレーションを行います。キャリブレーションを行うことでマーカーの3次元的な位置及びそれらから構築した人体のスケルトンが認識できるようになります。

モーションキャプチャシステムで認識している様子

カラーカメラのキャリブレーションによる内・外部パラメータ、歪みの推定

3D姿勢推定モデルの出力はカメラの位置を原点としたカメラ座標系であることが一般的です。しかし、モーションキャプチャシステムから得られた3次元姿勢はワールド座標系と呼ばれる別の座標系で定義されているため、学習に活用するには、カメラ座標系への変換が必要となります。変換を行うためには、カメラの内・外部パラメータ、歪みの値が必要で、それらの値はカラーカメラのキャリブレーションによって推定することができます。内部パラメータはカメラの焦点距離やカメラ中心の情報を持ち、外部パラメータはワールド座標系に対する回転・並進の情報を持ちます。

モーションキャプチャスタジオをお借りする場合、モーションキャプチャシステムのキャリブレーションはスタジオのスタッフの方に行って頂ける場合が多いようですが、カラーカメラのキャリブレーションは自分たちで行う必要があり、私たちは以下のような手順で行いました。

カラーカメラの内部パラメータ、歪みの推定

まずは内部パラメータ、歪みの推定のために各カメラでチェスボードパターンを多様な角度から撮影します。各画像から認識したチェスボードの角の位置の情報を用いて内部パラメータ、歪みの推定を行います。

内部パラメータ推定のためのキャリブレーションの様子

カラーカメラの外部パラメータの推定

外部パラメータの推定のためにモーションキャプチャで認識できるマーカーのついたワンドを各カメラで多様な角度から撮影します。カラーカメラ画像中のマーカーの位置とモーションキャプチャで計測されたマーカーの位置の関係から外部パラメータの推定を行います。

外部パラメータ推定のためのキャリブレーションの様子

動作の撮影

今回、ACESの取り扱う「Gemba」で認識したい動作を中心に51種類の動作について撮影を行いました（歩く、手を挙げるなど基本的な動作から、投げる打つなどのスポーツ動作、脚立の昇降、転倒、床に横たわるなどより実用的な動作まで含みました）。また、撮影をスムーズに行うために被撮影者の前方にカンペ動画を表示して撮影を行いました。

撮影の様子

効果の確認

今回構築したデータセットを用いて学習したモデル行い、ベンチマークモデルと比較してみました。例えば、床にうつ伏せになっている姿勢は、ベンチマークモデルでは認識が難しいですが、今回構築したデータセットで学習したモデルを用いることで正しく認識ができるようになっていることが確認できます。

3D姿勢推定結果の比較（黒：モーションキャプチャで認識した正解データ、青：今回構築したデータセットを用いて学習したモデルで認識した結果、赤：ベンチマークモデルで認識した結果

ACESでは積極的に採用を行っています！

ACESでは、積極的に採用を行っています。ACESでは「Gemba」の課題を解決するために様々な観点からアルゴリズムの開発を行っています。ACESに興味を持っていただいた方がいらっしゃいましたら、お気軽にご連絡下さい！

会社紹介資料はこちら↓

リクルートページはこちら↓

[1] J. Martinez, R. Hossain, J. Romero, J. J. Little, “A simple yet effective baseline for 3d human pose estimation,” In ICCV, 2017.

[2] C. Ionescu, D. Papava, V. Olaru, C. Sminchisescu, “Human3.6M: Large Scale Datasets and Predictive Methods for 3D Human Sensing in Natural Environments,” In TPAMI, 2014.

ACESの開発概要・開発思想のご紹介 ~ACESエンジニアブログの開設にあたって~

こんにちは、株式会社ACESの開発部責任者の久保 (@seishin55) です。

ACESは「アルゴリズムで、社会はもっとシンプルになる。」というビジョンのもと、アルゴリズム事業を展開する会社です。これまで「ヒトの知見を数式化する」ために、画像認識アルゴリズムの開発を特に強みとして開発を行ってきました。さらに現在では、音声認識や自然言語処理といったアルゴリズム領域の開発やソフトウェアプロダクトの開発も行っています。そのため、アルゴリズムのエンジニアのみならず、フロントエンド、サーバーサイド、モバイル、インフラなど様々なポジションのエンジニアが活躍しています。

このように、様々な領域で様々なエンジニアが活躍しているにも関わらず、積極的な外部への情報発信をこれまで行ってきておらず、ACESは「謎の多き組織」になってしまっていました。そこで、ACESで「普段どのような開発が行われているか」、「どのような技術・アルゴリズムに注目しているか」、など、ACESの開発について、社外の方々に知ってもらいたいと思い、エンジニアブログを始めることにしました。

ブログを開設するにあたって、ACESがどのような開発を、どのような考えに基づいて行っているのかを紹介していきたいと思います。

ACESの開発概要

ACESの事業は、Deep Learningを中心としたアルゴリズムの価値を社会に届けるという考えのもと設計されています。事業の形態は、具体的には以下の2つに大別されます。

ACESのビジネスモデル

DXパートナー事業

1つ目の 「DXパートナー事業」は顧客の課題に対して、ACESが伴走して一緒に価値実現していくという形態です。ACESが強みとしているリアル産業では、まだまだアルゴリズムによって価値が出せる余地が大きいものの、実際に事業価値に落とし込むところには依然として難しさがあります。ACESはAIのプロフェッショナルの立場から、パートナーとして一緒にAIを事業に組み込んでいきます。

ところで、アルゴリズムを事業価値に落とし込むのはなぜ難しいのでしょうか？ 確かに、2012年にDeep Learningアルゴリズムが注目されはじめ、特にここ数年で、アルゴリズムのパフォーマンスも大きく向上しましたし、様々なライブラリやサービスの登場で手軽にアルゴリズムを使用できるようになってきています。ただ、そのような潮流の中で、事業に簡単にアルゴリズムを組み込めるようになったかというと必ずしもそうではないのが現状かと思います。というのも、実際の現場では、Deep LearningモデルのInput/Ouputだけで完結することは多くなく、最終的な価値から逆算した上で、モデル構築や検証、オペレーションの実装などを行っていく必要があるためです。単にSOTA(State of the art / 最先端)のアルゴリズムを提供することが大事なのではなく、最終的な価値を実現するためのプロセスを回すことが大事だと考えています。ACESではこれを「アルゴリズムバリューデザイン」と呼んでいて、1つのコアコンピタンスになっていると思っています。

なお、「アルゴリズムバリューデザイン」を実現する上で、最先端のアルゴリズムの開発を疎かにしてもいいとは思っていません。むしろ、最先端のアルゴリズムを理解した上で選択できるようにしておく必要があります。つまり、単に精度が少し高いアルゴリズムを盲目的に実装することはやらずに、価値を実現する上で必要なものを選択することが大事だということです。そういった考え方に共感してくださる技術者・研究者の方はACESでチャレンジできることが多々あるので、是非ジョインしてほしいと思います。

アルゴリズムソフトウェア事業

次に、2つ目の「アルゴリズムソフトウェア事業」は、ACESで開発してきたアルゴリズム及びノウハウを生かして、アルゴリズムが組み込まれたソフトウェアを提供していく形態です。「DXパートナー事業」は個社ごとのバリューチェーンを意識した形態ですが、「アルゴリズムソフトウェア事業」では企業問わず、または、業界問わずに顕在化する共通の課題に対するソリューションを提供するところに大きな違いがあります。

例えば、現在、特に力を入れて開発を行っているのが、「ACES Meet」というオンライン商談の共有・解析サービスです。昨今ではオンライン会議が一般的になったことによって、商談等の会議がデジタル化され、活用できる土壌が整ってきており、そこに対するソリューションの提供を行っています。

meet.acesinc.co.jp

アルゴリズムを十分に活用するためには、ソフトウェアプロダクトとしてすぐに価値を享受できる状態にして提供することには大きな価値があります。その意味でソフトウェアプロダクトの開発も広義の「アルゴリズムバリューデザイン」のひとつです。プロダクト開発の側面から、どのようにアルゴリズム価値を届けられるかのUXを一緒に創ってみたいという方に是非ジョインしてほしいです。

レバレッジを効かせる開発思想

ACESの開発の特徴のひとつに、レバレッジを効かせる開発を行っていることがあります。元々、プロジェクト型の事業がメインという背景もあり、単にプロジェクトごとに開発を行うだけでは規模の拡大に合わせて、事業は線形にしか伸びていきません。そこで、アルゴリズムをパッケージとしてまとめ上げ、パッケージとしてのアセットの蓄積と提供するアルゴリズムのライセンス提供による積み上げによる非線形な成長を意識して開発を行ってきました。

ACESのパッケージ化戦略

アルゴリズムパッケージ

現在では社内のパッケージは複数存在するのですが、特に初期から作り上げてきた社内パッケージの一つに、aces-visionと名付けられたパッケージがあります。このパッケージは動画像系のDeep Learningを中心としたアルゴリズム群が共通の規約の元で実装され、統一されたインターフェース・環境で利用できるようになっています。

例えば以下は、aces-visionによるクラス分類モデルの推論のサンプルです。モデルを選択して読み込み、モデルの設定や重み (model_hashとして定義)を指定するだけのシンプルなインターフェースでアルゴリズムを簡単に利用できます。このパッケージだけでも数十のアルゴリズムモデルが実装されていて、どのアルゴリズムも同様のやり方で利用可能です。動画での推論や複数のアルゴリズムを連続的に適用するためのラッパーも用意しているため、様々なケースに活用できます。

from acesvision.Classification import BasicModel
model = BasicModel(model_hash='BasicModel_xxx_xxx')

image = 'path/to/sample.jpg'

# 1枚の画像の推論
model(image)

# 複数枚の画像の推論
images = [image] * 3
model(images)
# [1, 1, 1]

また、学習も以下のようなインターフェースで簡単に実行できます。学習済みの重みを使ったり、学習を再実行したりする各種オプションが実装されていたり、設定ファイルを変更することでオーグメンテーションやロス関数、Optimizerなどを変更できたりします。

from acesvision.Classification import BasicModel

model = BasicModel(
    model_hash='BasicModel_xxx_xxx',
    dataset_hash='xxx_xxx',
    training=True,
)

# 学習の実行
model.train(initialize='random')

全てのモデルの実装が、ベースとなるクラスを継承してすっきりと実装してあり、学習の実装もPyTorch Lightningのようにシンプルに実装できるように設計しています。そのため、新規のモデルの開発を行う場合も、質の高いアルゴリズムモデルを早く実装できるようになっています。

現在開発を行っている他のアルゴリズムパッケージにもaces-visionの設計思想は継承されています。

アルゴリズム提供基盤とプロダクト

アルゴリズムを提供するにあたって、以下のようにアルゴリズムパッケージを中心とした技術の展開を考えて開発を行っています。

ACESの技術展開

ACESではアルゴリズムを活用した単独のソフトウェアプロダクトを開発しているわけではなく、複数のソフトウェアプロダクトを開発しています。このような開発をするにあたって、全てを1から作ろうとするとコストが線形に積み上がってしまいます。そこで、ここでもレバレッジを効かせるために、アルゴリズムのソフトウェア利用のためのモジュールを基盤として切り離し、その基盤をプロダクト開発で活用するような疎結合な設計を取っています。これによって、複数のソフトウェアプロダクトを開発するときに、都度、共通の基盤が強化され、新規のプロダクト開発のコストが下がっていきます。これによって、プロダクト開発の回転率を高くすることができます。現在では基盤としては「ACES Platform」と呼んでいる社内のAPIの基盤が中心的に開発されています (どのような設計になっているかは別途記事になる予定です)。

その他にも、オンプレでの提供やモバイルパッケージの提供、エッジデバイスへの展開のための開発なども行っていますが、今後さらに力を入れたい項目となっています。開発思想に共感して、一緒に作り上げていってくださる方を絶賛募集中です。

おわりに

この記事ではACESの開発概要と開発思想についてご紹介しました。開発するアルゴリズムの詳細、基盤やソフトウェアプロダクト開発で使用されている技術の詳細は説明しきれませんでしたが、今後このエンジニアブログで紹介していきたいと思っています。（是非、「読者になる」や「シェア」等して頂けると励みになります！）

また、ACESでは各種ポジションで積極採用を行っています。この記事を読んで、「興味あり！」と思った方は是非応募頂きたいです。アルゴリズムエンジニアも引き続き募集していますし、フロントエンド、バックエンドのエンジニアなど広く募集しています。

ACESのリクルートページはこちら↓

acesinc.co.jp

Meetyも開設しているので、とりあえず話を聞いてみたいという方はこちらからどうぞ↓

meety.net