2020.08版（メジャーアップデート版）が公開されました
本書についてまとめ記事を鋭意作成中です。
シリーズ一覧
概要
この資料は、QA4AIコンソーシアムが作成するAIプロダクト品質保証ガイドライン(2019.5)を短くまとめたものです。
元のドキュメントは読み物としては良いのですが、典型的な逆茂木型文章であり、分かりづらいのでまとめました。
本稿の使い方
- AIプロダクト品質保証ガイドラインの概要をざっと把握
- 気になったところや詳細を知りたいところは公式の資料を見る
といった使い方をしていただければと思います。
※AIプロダクト：AI技術を用いた製品やサービス
免責事項
本稿は学習の成果物の一つとして作成したものであり、記載内容の正確さは担保致しません。
したがって、本稿に記載した内容に基づくあらゆる事項について一切の責任を負いかねますので、予めご了承ください。
目次
-
目的とスコープ
本稿のターゲット -
AIプロダクトの品質保証の枠組み 本稿のターゲット
- 技術カタログ
- 生成系システム
- スマートスピーカー
- 産業用プロセス
- 自動運転
- AIプロダクト品質保証コンソーシアムについて
1. 目的とスコープ
1.1. 背景と目的
- 機械学習など帰納的に振る舞いが決まるAIプロダクトの品質保証（把握・評価・説明・管理）は従来型ソフトウェアやハードウェアに比べて非常に困難である
- AI技術の技術的特質を無視して、AIプロダクトが過度に期待されることで、品質圧力が過度に上昇してしまうことも懸念すべきである
- 上記の課題に対応する為に、AIプロダクトの品質保証の為のガイドラインを発行することとした
以下、本ガイドラインの目指す形についての引用です。
このガイドラインは、各組織において AI 技術への過度の期待を予防し、
適切な活用や適時のリリースを行うための、
AIプロダクトの品質保証に対する共通的な指針を与えるものである。
更新は年一ペースを予定しているようです。
機械学習に代表される AI技術は著しく速く進化しているため
本ガイドラインは年次程度に定期的に更新される。
1.2. AIプロダクトの品質保証上の課題と本ガイドラインのスコープ
（１）演繹的開発と帰納的開発（言葉の説明）
- 演繹的開発とは 【従来のタイプ】
- 定義された仕様に対して内部設計や実装を明示的に関連づけることができ、それらに基づいて検証を行う
- 帰納的開発とは 【新しいタイプ】
- 定義された仕様に対して内部設計や実装を明示的に関連づけることができないので、小規模かつ反復的に開発・テスト・試験稼働・実運用を行う（ことが多い）。
（２）AI技術の種類と概観
AI技術は大きく分けて二つ(開発スタイルの観点から)
| AI技術の分類 | 開発スタイル |
|---|---|
| ルールベース技術 | 演繹的 |
| 機械学習技術 | 帰納的 |
機械学習技術は大きく分けて二つ(数学的な観点から)
| 線形性や分布の仮定 | 対処方法 |
|---|---|
| 仮定できる | 網羅的でなく典型的な条件のみを考慮し、 小規模なコンポーネントの 品質保証成果を積み上げる |
| 仮定できない | CACE(※1)という性質のために 全体全数高頻度検証(※２)が必要 因果関係(※３)の説明や理解は非常に困難 |
※1：Change Anything Change Everything
※2：全コンポーネント全条件で高頻度のテスト
※3：eXplainable AIなどの研究が盛んだが、本ガイドラインのスコープ外とする
（３）AIプロダクトの品質保証における課題
- AIコンポーネントの核であるモデルとデータの質が重要ではあるが、ミッションクリティカルなドメインにおいては基本的にモデルの精度は100％にならないことを理解しておく
- AIプロダクトの開発組織はデータサイエンスとソフトウェア開発という２つの側面を持っており、組織によってどちらの色が強いかは変わる
-
データサイエンス色が強い組織
- 「モデルの精度こそ品質や！」
- 演繹的開発の品質保証の考え方が役立つことを認識せよ！
-
ソフトウェア開発色が強い組織
- 「プロセスやメトリクスこそが品質保証や！」
- 開発チームの納得感の共感があってこそメトリクスの達成があることを認識せよ！
-
データサイエンス色が強い組織
- AIプロダクトの特性について理解の乏しい顧客のプロダクトに対する理解を適切に制御する
(4)本ガイドラインのスコープ
- 以下、５つの軸で論ずる
- Data Integrity
- Model Robustness
- System Quality
- Process Agility
- Customer Expectation
- 上記の軸をベースに、以下４つのドメインについて個別ガイドラインを提示する
- コンテンツ生成系システム
- スマートスピーカー
- 産業用プロセス
- 自動運転
以下、引用
同様に AI の技術はいまだ発展途上のため、本ガイドラインは網羅性や完全性を企図したものではない。したがって各組織では、本ガイドラインを指針として自ドメインや自社、自組織の状況などを熟慮、反映し、自組織の責任の下において活用する必要がある。
2. AIプロダクトの品質保証の枠組み
2.1. AIプロダクトの品質保証において考慮すべき軸
それぞれの軸でどういったことが重要なのか、もう少し詳しく述べると
-
Data Integrity
- 質・量ともに適切かつ充分なデータを確保していること
- 学習用データと検証用データが独立していること
- 統計学や機械学習の分野での知見を利用するべき
-
Model Robustness
- 正答率や適合率、再現率、F値、AUROCなどモデルの良さを示す指標を適切に考慮すること
- 学習の度に適切な頻度で精度や汎化性能を検討すること
- ノイズに対して頑健であるか、十分に（数理的・意味的・社会的・文化的に）多様なデータでモデルの検証を行うこと
- 統計学や機械学習の分野での知見を利用するべき
-
System Quality
- AIプロダクトの演繹的開発部分と帰納的開発部分の見極めを適切に行うこと
- AIプロダクト全体として提供しようとしている価値を検討すること
- 起こり得る品質事故の致命度が許容範囲内に抑えられているか検討すること
- 自分たちが行う品質保証活動の意味と品質向上への寄与度を理解すること
- 品質保証の担当者や組織は、管理やではなく技術者であるという意識を持たなくてはならない
-
Process Agility
- 納得感を共感した開発者集団が自動化された開発環境を駆使して臨機応変に探索的開発を進めること
- データ収集の速度とスケーラビリティが十分であること
- 十分短い反復単位で機能追加・品質向上・運用状況のフィードバックが行われること
- リリースロールバックを迅速に行えるようにしておくこと
- データ・モデル・環境・ソースコード・出力を適切に構成管理することで開発・探索・検証・リリースなどを自動化すること
-
Customer Expectation
- AIプロダクトに関する顧客の理解を深めるような活動を行うことで、顧客の期待を適切に制御すること
- AIプロダクトが確率的に動作する（※4）ことを理解してもらうことで、過学習や無駄な作業の発生を抑制すること
- PoC（Proof of Concept）やβリリースに実運用レベルの指摘をされ、解決を求められることで品質の低下や開発の停滞に繋がる可能性がある
- 顧客自身が集めることのできるデータ量・質がどれほどかを十分認識してもらうこと
- 顧客・開発者・チームの間で納得感を共感する風土や雰囲気、仕事の進め方ができなければならない
※4：コンピュータプログラムである以上、確定的に動く（同じ状態で同じ入力を与えると同じ出力を返す）が、想定される入力群に対しては精度100%にならないし、人間にとっては同じように見える入力でも異なる出力を返すことがある為、確率的に動くように見える
2.2. AIプロダクトの品質保証の分類軸ごとのチェックリスト
省略
2.3. AIプロダクトの品質保証の構築・評価
- 5つの軸のバランスがとれていること
- 開発段階に合わせて適切な品質保証を行うこと
- Customer Expectationを他の4軸で上回った状態は「過剰品質」ではなく「余力」である
2.3.1. バランスに着目した構築・評価
- 5つの軸に不足がないこと
- 顧客の期待（Customer Expectation）に対して残り4軸の値が上回っていること
5つの軸のバランスを考える場合
顧客の期待と4つの軸を比較する場合
2.3.2. 開発段階に着目した構築・評価
各開発段階で各軸の値がどの程度であるべきか、については開発・品質保証・顧客の三者を中心として、議論すること。
2.3.3. 余力と過剰品質
下記の状況は、「過剰品質」ではなく「余力」と捉えるのが適切である。将来的に開発段階が進んだり運用範囲が広がったりすると顧客の期待が高まる為、その時に備えた活動を事前に行っていると解釈すべき。
次章につづく