はじめに
はじめまして、株式会社HACARUSの宇佐見と申します。HACARUSはいわゆるAIスタートアップでして、お客様から頂いたデータを分析したり、外観検査パッケージであるHacarus Checkの販売などを行ったりしています。
私も普段はお客様から頂いたデータ分析を行っていたり、最近はチーム異動して社内の知見を生かしたプロダクト開発を行ったりしています。
さて、この度はMLOpsに関するアドベントカレンダーということで、タイトルにあるとおり「AIプロダクト品質保証ガイドライン」という機械学習を使ったプロダクトの品質のマネジメントを行うためのガイドラインの紹介と、弊社での利用方法などをお伝えします。AIを使ったサービスの運用・評価方法というところで、大きくはMLOpsの文脈で捉えられるかと思います。
プロダクトの品質とは
皆さんはAIを使ったサービス・プロダクトの品質と聞いて何を思い浮かべるでしょうか？パッと思いつくのは使用している機械学習モデルの精度を測るのに用いられる指標（Precision, Recall, Specificity, F値など）が挙げられるでしょう。しかし、このような指標は機械学習を使ったコンポーネントを評価するのには使えますが、プロダクトの品質を全てカバーしているわけではありません。機械学習を使ったコンポーネントはあくまでプロダクトの一部でしかなく、もちろん重要な部品ではありますが全てではありません。
つまり機械学習を使った「プロダクト」として継続的に改善をし続けられる仕組みなのか、システム全体として価値があり事故耐性が高いのか、なども品質を構成する重要な要素として考える必要があります。
例えば、弊社が開発しているプロダクトとして犬用の心電図測定装置があります。
このプロダクトに関して言えば、データがクラウド上にアップロードされるため、継続的に性能が著しく変化していないか、また取得しているデータがおかしくなっていないかなどを監視していく仕組みが構築されています。このようにシステムの入力、出力がおかしくなっていないことを担保する仕組みというのも一つの品質として挙げられるでしょう。
突き詰めていけば、プロダクトを評価する品質については膨大な観点から見ていかなければならないと感じるかもしれません。それを1個人、もしくは1チームで考えていくのは不可能ではありませんが非常に骨の折れる作業になります。そこで、指針としてガイドラインを活用していくことが非常に有効になります。
指針としてのガイドライン
世の中には既に様々なガイドラインが存在していて、ソフトウェア開発の分野で有名なものとしてはJIS X 0160という規格をベースにした共通フレームというものがあります。これはIPAが制定したフレームで、ソフトウェアのライフサイクルに関する企画になります。こういったガイドラインを指針として開発することで各個人間での認識の違いによるトラブルを抑えることが出来るだけでなく、品質の高さをお客様にアピールすることもできます。また、品質が契約に適合しない場合ユーザーに対してベンダーの責任が発生しうるが、品質に定めがない場合責任が生じる基準が曖昧になる場合があります。結果トラブルが発生する可能性がありますが、ガイドラインに沿って開発すればそのようなリスクを回避することもできます。
ただ、こちらは一般的なソフトウェアに関して適用されるものであり、機械学習を用いたプロダクトにも適用できる部分はありますが、機械学習特有の課題に関しては言及されていません。機械学習を用いたプロダクトは往々にして探索的な開発になり、データの質なども考慮しないといけませんし、精度100%ということも達成は不可能だという点も考慮しないといけません。
AIプロダクト品質保証ガイドラインはその部分を考慮した、AIをコンポーネントとして持ったプロダクトに対するガイドラインとなっています。
AIプロダクト品質保証ガイドライン
AIプロダクト品質保証ガイドラインはQA4AIコンソーシアムが発行するガイドラインになります。
AIプロダクト品質保証ガイドラインはAIプロダクトの品質保証に対して共通の指針を与えることを目標として制定され、Data Integrity, Model Robustness, System Quality, Process Agility, Customer Expectationの5つの軸でAIプロダクトの品質を評価します。それぞれにの軸に対してチェックリストが用意されていて、そのチェックリストを確認できる実施項目を遂行できているかどうか確認することでプロダクトの品質を評価します。まずは、各軸について考慮されている点についてお話ししていきたいと思います。
Data Integrity
Data Integrityは簡単にいうとデータがちゃんとしているかどうかを評価する軸になります。例えば学習、テストに十分な量のデータを確保できているのかや、学習、テストデータがちゃんと独立になっているかなどを考慮します。量の観点で言えば、データオーグメンテーションによってかさ増しされた画像によって汎化性能が低下していないかなども確認します。
また、データの利用に制約があるかどうかも考慮します。場合によっては著作権などの第三者の権利によってデータ利用が制限されることもあるからです。
Model Robustness
Model Robustnessは文字通り機械学習モデルの頑健性を評価する軸です。
この軸では先述の機械学習モデルを評価する指標による精度検証はもちろんのこと、汎化性能の検証なども行います。それぞれの検証は適切な頻度で、かつ適切に進行したか、また交差検証も十分に行なったのかも考慮します。
ここまではプロダクトリリース前の検証にあたりますが、プロダクトがリリースされてからも検証は必要です。新たにモデルを更新するとなった場合、以前のモデルで達成できていた性能を損なっていないかは検証しなくてはいけません。例えモデルを更新しない場合でも性能は監視し続ける必要はあります。なぜなら、入力データの傾向が変化してしまう場合があるからです。従って、データの傾向が変化してしまったことや、モデルの性能が低下したことを検知する機能はもちろん、それに対応できる仕組み作りが必要です。（このあたりはAndrew Ng氏の提唱するData centric AIの概念が非常に参考になります）
この辺りの対策として、弊社ではMLOpsの導入を進めています。具体的には、DVCを用いたデータ管理を導入していて、データの同一性の確認と、あるデータセットに対する実験結果の保持、およびデータ更新した際に性能が著しく変化していないかの確認を自動的に行えるようにしています。また、データが同一であってもコードの更新によって生成される特徴量も変わりうるので、それも合わせての性能の追従を行うようにしています。
System Quality
System Qualityでは機械学習モデルのみならず、システム全体の品質を考慮します。まず考えることはシステム全体によって適切に価値を提供できているかどうかです。AIを導入してみたいからとりあえずやってみたというものではなく、ビジネスやシステム全体の観点からKPIを定義していて、AIの導入によってそのKPIが上昇/下降したかによって評価します。そして、その評価がシステム全体または意味のある単位で行われているかを考慮します。
もう一つ大きな観点として、起こりうる品質事故についてしっかりと考慮できているかという点があります。品質事故自体の頻度や致命度が許容できる範囲に収まると見積もれているかどうか、事故到達度が抑制されているか（異常出力がないようにされているか）などです。事故というと身体や生命への危害をイメージしますが、他にも経済的なものや社会環境への影響など様々なものが考えられます。ことAIプロダクトにおいては、誤判別のような機能的な品質事故や、性能低下によるユーザビリティの低下も挙げられます。
また、システム全体を見た時に、システムがAIコンポーネントに寄与しすぎていないかというところも考慮しないといけません。AIコンポーネントの挙動がおかしいときに非AIコンポーネントでオーバーライドできるのかや、AIコンポーネントや非AIコンポーネントにそれぞれ変更があった場合に迅速に反映できるかなどを考えて、AIコンポーネントに依存しすぎない設計を考える必要があります。
最後に、ステークホルダーがプロダクトの品質が保証されていることを納得しているかどうかも確認します。いくら品質保証に時間をかけたとして、納得してもらえていなければ意味がありません。これを達成するためには説明可能AIや統計的手法で根拠を示すことはもちろんですが、そもそもAIの性能に対する考え方について初めにステークホルダーに理解してもらっておかなければなりません。（いつでも精度100%なんて不可能であることを納得してもらっていなければ後々大変です。）
このあたりはプロジェクトを進める中でお客様にはよく聞かれるところで、どういう根拠でこの結果が出ているのか？とかは頻出の質問です。分析過程での中間データの可視化はもちろん、木構造のモデルにはFeature ImportanceやSHAPを用いた特徴量の重要度の可視化、画像に対しては異常検知を行うことが多いのでHeatmapによる可視化など、多くはお客様に理解しやすい形で結果を可視化して納得感を持たせることが多いです。
Process Agility
Process Agilityは開発チームが自動化された開発環境を用いて機動的に開発をしているかを評価する軸です。この軸では自動リリース/デプロイや迅速なロールバック、カナリアリリースなど現代のシステム開発では当たり前に行われるような点についての評価はもちろん、AIプロダクトでは他にはモデルの実験管理による性能の追跡や、データ収集の速度やスケーラビリティが十分かなども考慮します。
弊社では実環境に導入する前にはカナリアリリースの他にShadow modeという方法を取ることもあります。これは今の環境の裏で同時にAIプロダクトを動かして、同時に結果を生成するというものです。カナリアリリースよりももっと保守的なやり方になります。
変わった評価項目としては開発チームに適切な専門家がいるか？という項目があります。これは納得感の信頼度を高めるために必要とされている項目で、AIプロダクトを導入するにあたってはAIの知識はもちろんのこと、対象となるドメイン知識を有していなければ迅速かつ納得感のある開発ができないために設けられています。
Customer Expectation
最後に、Customer Expectationです。顧客との良い関係性を築けているかを考慮する軸になります。他の4つとは少し毛色が違った評価軸になっていて、顧客の期待感や、顧客の特性について評価する項目が多くなっています。なぜこのような軸が必要かというと、過度に期待感の高い顧客に対しては品質保証が困難になるリスクがあるからです。特に先述のような「100%正解するAIを作ってくれ」あるいは「AIプロダクトを開発するベンダーがうまいことやってくれ」などというようにAIに対して過度な期待を持つ顧客に対しては、初期段階から期待感を上手く制御していかなければ、品質保証に関するコミュニケーション自体が破綻しかねません。AIはその特性上、同じ入力には同じ結果を返すとはいえ、入力全体に対しては精度100%になり得ませんし、非線形なモデルだと一見して理解し難い結果を返すこともあります。また、より良いAIプロダクトを作るためにはベンダー丸なげではなく、顧客との密な連携によって、ドメイン知識を補完したり、結果の解釈の助けを行ったりして協力することが不可欠です。従ってこういった理解があるかどうか？などがCustomer Expectationの評価項目に含まれています。
これだけ書くと碌でもない顧客は相手にするなと言っているように見えるかもしれませんが、そうではなくてこのあたりの啓蒙も含めて、AIプロダクトを提供する会社が行うべきことではないかなと思っています。また、System Qualityの項でも述べたAIの判断根拠を顧客に見せるところも深く関わるところで、わかりやすく見せつつ顧客のAIに対する理解度を上げて共に良い関係性をつくっていくことも大事なところです。
AIプロダクト品質保証ガイドラインの適用例
さて、ここまで各軸の説明をしてきましたが、ここからは実際にAIプロダクトに適用しているかというところを、HACARUSでの実例を元にお話していきます。
HACARUSでは様々なプロジェクトにおいて、AIが実運用されていく段階に入る前にAIプロダクト品質保証ガイドラインを用いてプロダクトを評価するということを行なっています。（理想的にはプロジェクト初期から運用していきたいのですが、今は取組が始まって間もないため、このタイミングになっています。）
上図は株式会社べリサーブ様と共同で作成したAIプロダクト品質保証ガイドラインの評価シートになります。項目に関してはAIプロダクト品質保証ガイドラインのチェックリストを参考につくっていますが、実施項目案に関してはこの項目から実際に行うべきアクションを書いています。（ここは社外秘なのでモザイクをかけさせてもらっています）そして、そのアクションをどれだけ達成できたか？などで各項目の最高点に対しての評価点を記入します。こうして各軸に対して合計点を算出し、各項目ごとに1になるようスケールしてその軸の点数とします。そうすると以下のような図を生成できます。
この図を見ることで、どの軸が不足していて、どこをもっと考慮すべきなのかがわかります。また、Customer Expectationとの比較を行うことで、顧客の期待に対していずれが不足しているか？ということが一見してわかります。ただし、Customer Expectationは顧客の理解度が高いと高くなる場合もあるので、一概に過度に期待度が高いと言い切れませんが、全体のバランスを見るには役立つでしょう。
HACARUSではある実際のプロジェクトに適用してみたところ、Data integrityとModel Robustnessが期待よりも低いことがわかりました。具体的にはモデルの性能のモニタリングをしっかりとできていなかったところが問題でした。お客様側でモデルを作ることができるシステムなのですが、その精度をお客様側で上手く評価することができない仕組みになっていたのです。よって非常に手離れが悪くなっていました。そこで作成したモデルのレポートを簡単に作成できるようにすることで、お客様側でモデルの精度を正当に評価する機能を追加することになりました。また、同様にモデルの劣化に対しても検知して管理できるようになっています。合わせて、このレポートをお客様側で分析して頂くことで、AIに対する基本的な知識を得られるようにする啓蒙活動のような面もあります。
まとめ
AIプロダクトの品質保証について、AIプロダクト品質保証ガイドラインを元に弊社の使用例を挙げながら説明させて頂きました。AIプロダクト開発者としてはどうしてもAIの精度に拘ってしまうこともありがちですが、あくまでAIはプロダクトのコンポーネントの一部でしかなく、プロダクト全体として価値あるものを提供できているかという観点から見ていきたいものです。
この記事と、AIプロダクト品質保証ガイドラインを活用いただいて皆さんのプロダクト品質保証の一助となると幸いです。
なお、HACARUSでは社内的な活用のみならずAIプロダクト品質保証ガイドラインを活用したサービスも展開してますので、興味ある方はぜひホームページからお問い合わせください。