こんにちは、MLOpsチームです。先日OCRモデルを学習するためのアノテーションにおいて、作業効率を検証するためのPoCとしてアノテーションUIを開発しました。本記事ではこのアノテーションUIにおける工夫について、試用によって得られた知見をまじえつつ紹介します。
はじめに
アノテーションUIを開発することとなった背景について説明します。
アノテーションUIとは
アノテーションUIは機械学習の学習データを作成するためのUIです。アノテーションUIはアノテーション作業の効率に強く影響し、アノテーション作業によって得られる学習データの量は機械学習の精度に大きく寄与します。したがって、アノテーションUIは機械学習において最も重要なコンポーネントのひとつといえます。
UIを開発した背景
キャディではOSSツールなどのUIを用いてアノテーションが行われていましたが、ここに独自の工夫を導入すれば入力効率が改善できるのではないか、という仮説がありました。たとえば画像中のテキストに関するアノテーションを実施する際、すでにあるOCRモデルを利用してデータ入力を効率化できるかもしれません（詳細は後述の「テキストの自動入力」にて説明します）。
そこで、これらの工夫が実用的であるかを確かめるべく、独自のアノテーションUIのPoCを実際に作成することにしました。今回は図面中のテキストを読み出すOCRモデルの学習データを作成するためのアノテーションUIを開発しました。
OCRモデルのアノテーションUIでは次の作業ができる必要があります。
- 図面中に矩形領域（バウンディングボックス）を作成する
- バウンディングボックスに対してテキストを入力するGoogle Cloud
- バウンディングボックスに対してラベル（テキストの種別となるカテゴリ値）を付与する
具体的には、次のスクリーンショットのUIです。
効率的な操作を実現する工夫
アノテーション作業において効率的にデータを作成できることは至上命題です。効率的なデータ作成のための工夫について2点紹介します。
テキストの自動入力
バウンディングボックスを作成したときにOCRモデルによってテキストを推論し、自動入力する工夫です。テキスト入力の負担を大幅に減らせます。OCRモデルの学習データを作るためにOCRモデルの推論を利用することになり、ある意味でHuman-in-the-Loopのような形になります。
この機能を提供するための適切なUIはOCRモデルの推論時間によって変わります。たとえばOCRモデルの推論に長い時間がかかる場合、複数のテキスト推論をまとめてバッチ的に推論する必要があるかもしれません。その場合、内部的にキューを用意したり、まとめて推論するためのUIを作ったりすることになります。そこで、筆者らは推論にかかる時間を任意に設定できるOCRのfakeモデルを作成し、いろいろな遅延を試しながらUIの使用感を確認しました。最終的に、我々が使いうるモデルではバッチ推論ではなく、バウンディングボックス作成時に逐次推論する方式のほうが使い勝手が優れていました。
OCRモデルも間違いうる、という点にも注意が必要です。 OCRモデルが間違えやすいものは人間も間違えやすく、たとえば「O」「0」や「I」「l」などは人間も気付きづらい間違いです。フォントの選択や文字サイズなどを工夫し、より正確性を向上できそうです。
バウンディングボックスの自動スナップ
バウンディングボックスをテキストにフィットする機能を実装しました。大雑把な操作で作業できるので非常に便利です。
この機能は白黒の図面画像ならではのヒューリスティックな、かつシンプルなアルゴリズムによって実現しています。したがって、うまくいかない場面も多々あります。たとえばテキストと重なる図形があったり、スキャン時のノイズが少しでもあるとうまくいきません。しかし多くの場合で入力効率が高くなり、スナップ機能がうまくいかないケースでもスナップ機能をオフにして通常の操作で正しいバウンディングボックスを付与できます。
使いやすさを向上する工夫
作りの悪いUIは操作に不快感があります。快適な操作性を提供し、ユーザがデータの正確さに注力できることが重要です。
アクセシビリティを考慮した配色
多くの人が効率的に作業するためには、配色に注意する必要があります。開発者にとって問題ない配色がユーザにとっても同様に問題ないとは限りません。ディスプレイ・照明などの利用環境やユーザ自身の色覚特性によって、色の見分けやすさが異なるためです。さまざまな色覚特性を持つユーザが快適に作業できるために、アクセシビリティに配慮した配色パターンを利用する必要があります。
今回のUIではバウンディングボックスに割り当てられるラベルが4種類あり、バウンディングボックスにどのラベルが割り当てられているかを一目でわかるように表示する必要がありました。これらを色ではない要素（文字や罫線など）で表現できればアクセシビリティ上も問題ありません。しかし、色以外の要素では図面に記載されている図形やテキストと重なって判別が難しくなってしまったため、ここでは色による表現を採用しました。
今回はOkabe-itoパレットと呼ばれる配色パターンを参考にUI上の配色を決めました。実際に見分けやすいかどうかはChrome DevToolsなどの色覚シミュレーション機能によって確認できます。
キーボード操作・ショートカット
基本的な操作にキーボード操作が割り当てられているのは効率化の上で重要です。しかし、ユーザビリティとしても重要な点があります。
たとえば、キーバインドの選択によって使いやすさが大幅に変わる場合があります。UIを試用してもらった際、以前が使っていたOSSのデータ入力ツールとキーバインドが異なっており使いづらい、というフィードバックが多くありました。
単に機能が揃っているだけでは不十分な場合があり、利用者の文脈に沿ったデザインも一考の余地があります。
戻るボタンの挙動・ホイールの挙動などの作り込み
キーボード操作と同じく利用者に寄り添った作り込みが必要で、かつ失念しがちな部分があります。
1つはウェブブラウザの「戻る」ボタンの処理です。「戻る」ボタンでどのようにページが遷移するのかを考慮する必要があります。今回アノテーションUIをReactで実装しており、単一ページでアノテーションUIを構成しました。利用者がページ遷移と認識したものが実装上はページ遷移ではない場合があり、「戻る」ボタンが利用者の意図せぬ挙動を生みました。たとえばアノテーション対象となる図面を切り替えたときユーザは「戻る」ボタンで前の図面に戻ることを期待していましたが、実際は別のページへの遷移となっていました。
もう1つはマウスホイールの処理です。マウスホイールによって図面の拡大・縮小ができる機能を実装していました。利用者のOSや利用しているデバイス（マウス、タッチパッドなど）の違いにより、ホイールの使用感やによるスクロール量の大きさが異なります。利用者が使っているデバイスを用いて動作検証が必要です。
まとめ
今回のアノテーションUIを試用したユーザからはおおむね好評で、特にテキストの自動入力とスナップ機能は作業効率に寄与したとの（定性的ではありますが）評価でした。現在は機械学習のためのアノテーションだけでなく、図面上にデータを入力するUIとしての活用を探求しています。今後もさまざまな角度からデータについて取り組み、サービスの改善に努めてまいります。
