AIシステム開発におけるQA/QA in AI System development

by Matsu

Slide 1

Slide 1 text

AIシステム開発におけるQA 事例に学ぶ問題対処法

Slide 2

Slide 2 text

自己紹介

Slide 3

Slide 3 text

自己紹介活動: ● JaSST(ソフトウェアテストシンポジウム ) Kyushu実行委員 ● QA4AI (AIプロダクト品質保証コンソーシアム ) メンバー ● ASTER教育メンバー (ソフトウェアテスト技術振興協会 ) ● 新人さんからわかるソフトウェアテスト解説マンガ「テスターちゃん」作者

Slide 4

Slide 4 text

Quest用VRゲーム(異世界転生もの) を作っています

Slide 5

Slide 5 text

(余談。以下講演ではskip) ChatGPTを大いに利用しています ● コード生成 ● コードの修正 ○ 「以下のunityのコードを効率化できますか？」 ○ 「以下のunityのコードをもっとテストしやすいようにできますか？」 ● コードレビュー ○ 「以下のunityのコードのコードのレビューをしてください」 ● ユニットテスト (ハッピーパス) ○ 「以下のunityのコードのユニットテストを書いてください」

Slide 6

Slide 6 text

(省略) 自分のデータを学習させない設定にする学習データにしていいかどうかの設定があるため、されたくない内容を扱う場合はOFFにしておく。

Slide 7

Slide 7 text

(余談) コード生成「小さい便利コード」はChatGPTで生成。引数、戻り値が何かは指定している。納得するまでやり取りを行う。わからないコードは質問し、確かに説明があっているか調べる。

Slide 8

Slide 8 text

(余談) コードの修正 (既存コードの微修正) 実現したいことに必要な部分の説明を入れ、実現したいことを記載し、コードを渡す。修正したコードは無条件でコピペせず、レビューとテストをした方が良い。

Slide 9

Slide 9 text

(余談) コードの修正 (テスト容易性) 「テストしやすいようにできますか」とプロンプトを入れてコードを渡す。例では、依存性の注入がしやすいようなコードを返してくれている。

Slide 10

Slide 10 text

(余談) コードの修正 (効率化) 「以下を効率的に書くことはできますか」といったプロンプトを入れてコードを送る。例の場合は、ゲームでよくあるカウント処理の方法についてMax関数で書く方法が提案されている。他者がどうコードを書くのかを学ぶこともできる。 (文章生成は要は「よくあるパターン」で文字列を生成するため)

Slide 11

Slide 11 text

(余談) コードレビュー「コードレビューをしてください」といったプロンプトを入れてコードを送る。例では、Random.Rangeの上限値の指摘がされている。またクラスの分割が提案されている。かなり細かい点まで指摘してくれるので、勉強にもなる。与えられたコードでのレビューなので、人がレビューするように「他の機能との兼ね合いは大丈夫か？」といったファイルをまたぐような指摘はされない。

Slide 12

Slide 12 text

(余談) テストコード生成ハッピーパスの生成は可能。テストが十分かは考える必要がある。例では、Randomの固定を考慮しテストしている。(コード割愛) unityのtestはSetUpが面倒なことが多いので、それらの部分を書かせるということもできる。

Slide 13

Slide 13 text

本編

Slide 14

Slide 14 text

今回の発表は私の経験を織り交ぜた AIシステムのテストのチップス集です。近い将来、みなさんも AIシステムのテスト担当をすることがあるでしょう。その時のための話になれば嬉しい限りです。

Slide 15

Slide 15 text

目次 ● AIの出力に着目した3パターン ● Chapter.1 「代表値を1つだけ確認してPass/Failしていいですか!?」 ● Chapter.2 「入力値、爆発!!」 ● Chapter.3 「再学習したら変なところが壊れた!!」 ● Last Chapter 「生成した。で、俺はどうすればいい？」

Slide 16

Slide 16 text

今までのテスト対象と AIシステムの違い簡単まとめ 3つの入力→出力のパターンの話 (オレオレまとめ)

Slide 17

Slide 17 text

これまでのシステム AIではないシステムの場合、ルール(仕様)にそった入力に対し、ルール通りに処理され出力を返す。ルールにそっていない出力の場合は誤りとなる。仕様にそった入力パターンルール仕様にそった出力パターン入力に対する期待結果がわかる

Slide 18

Slide 18 text

AIシステム3パターン　パターン1 (期待結果がある) 無限に近い入力パターン (フリースタイル) AIコンポーネント仕様にそった出力パターン犬の画像猫の画像「犬」「猫」「鳥」今日の天気は占って、かに座天気API 占いAPI エラー応答 NISAしたい解約どうやる? NISA説明解約説明オペレーター案内 Q&Aボットスマートスピーカー画像判定入力に対して期待結果はある

Slide 19

Slide 19 text

AIシステム3パターン　パターン2 (期待結果不明) 無限に近い入力パターン (フリースタイル) AIコンポーネント仕様にそった出力パターンだけど、どうなればいいかわからない株価データ上がる? 下がる? 履歴データオススメ1 オススメ2 オススメ3 画像データグループ1 グループ2 グループ3 教師なし学習によるグループ分け (クラスタリング) レコメンド (オススメ) 株価判定入力に対して期待結果がわからない

Slide 20

Slide 20 text

AIシステム3パターン　パターン2 (期待結果不明) 今回は時間の都合上テストオラクル問題の話はしません。松谷のJaSST’22 Shikokuの「今までのテストとAIを含んだプロダクトのテストの違い」の「メタモルフィックテスティング」をご参照ください。株価データ上がる? 下がる? 履歴データオススメ1 オススメ2 オススメ3 レコメンド (オススメ) 株価判定レコメンド系はA/BテストでCVRを見て調整したりする画像データグループ1 グループ2 グループ3 教師なし学習によるグループ分け (クラスタリング)

Slide 21

Slide 21 text

AIシステム3パターン　パターン3 (期待する方向性はある) 無限に近い入力パターン (フリースタイル) AIコンポーネント無限に近い出力パターン (フリースタイル) 芝の上の子猫芝&子猫の画像画像生成入力に対しての期待する方向性はあるハンバーグの作り方用意するものはひき肉、パン粉文章生成芝&おじさんの画像

Slide 22

Slide 22 text

代表値を1つだけ確認して Pass/Failしていいですか!？同値分割の考え方は通用しない話性能テストの話 Chapter.1

Slide 23

Slide 23 text

代表値を1つだけ確認してPass/Failしていいですか!? 例えば、ねこ判定AIがあったとして…… ねこ判定 AI システム猫猫ではない猫の画像とそうでない画像それぞれ大丈夫だったから OK!

Slide 24

Slide 24 text

今までのテストでは同値分割法で考えていた同値分割法は、入力値や出力値を同じ特徴をもつグループにわけて、その代表値でテスト（設計）する方法である。「同じ処理がされるならどれか代表値で確認しましょう」という考え方。 6歳以下 7歳以上13歳以下 14歳以上入場料無料入場料300円入場料500円 3歳で確認しよう 10歳で確認しよう 18歳で確認しよう

Slide 25

Slide 25 text

AIのテストは同値分割ができない！ AI(機械学習)においては、様々なニューロン（ノード）を通り複雑な計算がされる。我々からすると同じ猫に分類されるデータでも、少しでも違うデータの場合は活性化するニューロンも変わり、全く同じ処理がされることがない。猫猫ではない

Slide 26

Slide 26 text

代表値を1つだけ確認してPass/Failしていいですか!? A. 期待結果があるパターンのAIでも、同値分割の考え方は通用しません。

Slide 27

Slide 27 text

代表値を1つだけ確認してPass/Failしていいですか!? といいますか、AIシステムがどれくらいできるかは「性能テスト」です ※AIの精度は研究(開発)チームで保証かQAチームでも確認すべきかは確認すること！精度＋「こういうデータだと誤認識した」という情報も欲しい

Slide 28

Slide 28 text

4つの評価指標 Accuracy (正解率) Recall (再現率) Precision (適合率) F1スコア

Slide 29

Slide 29 text

Accuracy (正解率) 一番よく使われる指標 Accuracyは正解率。推論した結果全てがどれくらい当たったか。一番よく使う指標と言える。この例の場合、10回中7回当たったので、70%となる。例：株を買った方がいいか買わない方がいいか推論するシステム買うな買うな買うな買い買うな買うな買い買うな買い買うな実際買うなだった実際買うなだった実際買いだった実際買うなだった実際買うなだった実際買うなだった実際買うなだった実際買うなだった実際買うなだった推論実際実際買いだった推論 : 10回正解 : 7回 7 / 10 = 0.7 70%

Slide 30

Slide 30 text

Accuracy (正解率) Accuracyが高ければいいかというとそうとも言い切れない。起こる確率が低い場合は、全て「買うな」と予測しておけば正解率は90%となる。 Accuracyはデータセットのバランスがいいものに使う。例：株を買った方がいいか買わない方がいいか推論するシステム買うな買うな買うな買うな買うな買うな買うな買うな買うな買うな実際買うなだった実際買うなだった実際買うなだった実際買うなだった実際買うなだった実際買うなだった実際買うなだった実際買うなだった実際買うなだった推論実際実際買いだった正解率 90% 全部「買うな」推論

Slide 31

Slide 31 text

Recall (再現率) 当たりをどれだけ拾えていたか？ Recallは、「実際に当たり」を推論でどれだけ拾えていたか、である。例の場合まずは「実際」に注目。「実際に買いだった」は2回。それを推論で当てられたのは1回。よってRecallは 1 / 2 = 0.5 50% 例：株を買った方がいいか買わない方がいいか推論するシステム買うな買うな買うな買い買うな買うな買い買うな買い買うな実際買うなだった実際買うなだった実際買いだった実際買うなだった実際買うなだった実際買うなだった実際買うなだった実際買うなだった実際買うなだった推論実際実際買いだった Recall = 実際に買いだった数買いの推論で当たった数

Slide 32

Slide 32 text

Recall (再現率) は見逃しを少なくしたいとき「見逃しを少なくしたい」とき、Recallが高くなるように学習を行うのが良い。例えばガンの検出など。ただ上記の例のように、今度は全部当たりを推論しておけば「見逃し」はなくなるため Recallは100%となる。例：株を買った方がいいか買わない方がいいか推論するシステム買い買い買い買い買い買い買い買い買い買い実際買うなだった実際買うなだった実際買いだった実際買うなだった実際買うなだった実際買うなだった実際買うなだった実際買うなだった実際買うなだった推論実際実際買いだった全部「買い」推論

Slide 33

Slide 33 text

Precision (適合率) 当たり推論の正確性 Precisionは「当たり」と推論したときに、実際にどれだけ当たったか。例の場合まずは「推論」に注目。「買い」推論は3回。それで「実際に買いだった」は1回。よってPrecisionは 1 / 3 = 0.33… 約33% 例：株を買った方がいいか買わない方がいいか推論するシステム買うな買うな買うな買い買うな買うな買い買うな買い買うな実際買うなだった実際買うなだった実際買いだった実際買うなだった実際買うなだった実際買うなだった実際買うなだった実際買うなだった実際買うなだった推論実際実際買いだった Precision = 買いの推論の数買いの推論で当たった数

Slide 34

Slide 34 text

Precisionは誤検知を抑えたいとき「誤検知を抑えたいとき」はPrecisionが高くなるように学習させるのが良い。例えば迷惑メール判定など。(めったやたらと迷惑メールフォルダに入ってほしくない……) 例：株を買った方がいいか買わない方がいいか推論するシステム買うな買うな買うな買い買うな買うな買うな買うな買うな買うな実際買うなだった実際買うなだった実際買いだった実際買うなだった実際買うなだった実際買うなだった実際買うなだった実際買うなだった実際買うなだった推論実際実際買いだった

Slide 35

Slide 35 text

F1スコア(F-measure) RecallとPrecisionの調和平均先ほどの例では、Recallは全部「買い」と推論しておけばあがる。対してprecisionは「買い」推論を減らしピンポイントで当てにいった方があがった。この二つはトレードオフである。 F1スコアはRecallとPrecisionの調和平均(率の時に使う平均のこと)である。 0 ~ 1の間になり、1に近いほどRecallとPrecisionともに効率よくバランスが取れているといえる。 F1スコア = Recall + Precision 2 × Recall × Precision 先ほどの例： Recall(再現率) : 0.5 Precision(適合率) : 0.33 F1スコア = 0.5 + 0.33 2 × 0.5 × 0.33 = 0.83 0.33 = 0.3975…..

Slide 36

Slide 36 text

Chapter.1 まとめ ● AIでは同値分割の考え方はできない ● AIの精度の評価指標 ○ Accuracy (正解率) ○ Recall (再現率) ○ Precision (適合率) ○ F1スコア

Slide 37

Slide 37 text

入力値、爆発!! API自動テストの話入力値を絞る話 Chapter.2

Slide 38

Slide 38 text

入力値、爆発!! 天気は? 天気知りたい今日の天候は? 天気を知りたい青森の天気青森市の天気どう? 今、晴れてる? 天気が知りたいスマートスピーカー自然言語処理AI 天気API 占いAPI 音楽API 童話API etc… etc… 同値分割は使えない !! 明日、明後日の場合、場所が違う時もある！占いや音楽機能もテストしなきゃ！

Slide 39

Slide 39 text

API自動テストでゴリ押した (自動テストは必須) 音声認識自然言語処理天気API 占いAPI etc API 音声合成 Test Automation Test Data 言葉を組合せて量産「Smart speaker QA」16P参照他事例：「今までのテストとAIを含んだプロダクトのテストの違い」メタモルフィックテスティングを使ったバグを見つけるための自動テスト 97P参照音声→テキストテキスト→コマンドテキスト→音声コマンド実行

Slide 40

Slide 40 text

入力値を絞りたい! ログを活用するバグを活用する SNSを活用するマニュアル等にある例は必須 (例) 社内テストをやったら「今日の天気」が多い (例) 社内テストをやったら子どもの使う機能は丁寧語が多い (例) 「てにはを」の違い/有無に弱い (例) 体の一部が入ると誤認識があった・目黒、足利など Twitter / Discordで情報収集公式が出してるドキュメントの例は通らないと信用が下がる

Slide 41

Slide 41 text

ニューロンカバレッジを高めるデータニューロンカバレッジは、ホワイトボックステストのカバレッジと同じ考えである。多くのノード(ニューロン)が活性化するデータセット（まだ活性化していないノードを活性化させるようなデータ)で確認する方法もある。猫猫ではない (ReLU関数の場合)ノードは入力を計算し、それが閾値以上で値を出力する (活性化する) まだ活性化していないノードを活性化させるようなデータで確認していく Kexin Pei, Yinzhi Cao, Junfeng Yang, Suman Jana : DeepXplore: Automated Whitebox Testing of Deep Learning Systems, The 26th ACM Symposium on Operating Systems Principles, ACM, pp.1-18 (Oct. 2017)

Slide 42

Slide 42 text

Chapter.2 まとめ ● AIのテストでは入力値が爆発する ○ 確認量が多くなる。自動化できる部分はないか検討 ■ 期待結果があるパターンではAPI自動テストを行った ■ 他、テストデータ生成など ● 入力値を絞るなら以下が考えられる ○ ログを活用する ○ バグを活用する ○ SNSを活用する ○ マニュアルにある例を使う ○ (ニューロンカバレッジを活用する)

Slide 43

Slide 43 text

再学習したら変なところが壊れた!! Changing Anything Changes Everything Chapter.3

Slide 44

Slide 44 text

再学習したら変なところが壊れた!! 魚座の運勢は? 天気API 占いAPI 音楽API Before うお座の運勢は… 魚座の運勢は? 天気API 占いAPI 音楽API After ～♪ AIが学習したらおバカになっちゃった !! そういう名前のアーティストが入ってきてた!

Slide 45

Slide 45 text

Changing Anything Changes Everything (CACE性) AIの学習＝パラメーターを調整することである。パラメーターは全体が調整される。狙ったところの精度は上がるかもしれないが他の精度が落ちる可能性がある。何か変えると全部変わる性質をCACE性といったりする。猫犬犬の精度が悪いからデータを追加して再学習させよう学習時は全てのパラメーターが調整される

Slide 46

Slide 46 text

おしゃべりチャット (生成系)の例おはよう🌞ドーナッツって食べ始めたら止まらなくなるよね～わかるーどうして、あんなにおいしいんだろうね～甘い物食べた～い☆ 学習おはようございますおはようはい今日は目玉焼きですえっと… あ、はい… Before (Jasst Shikoku’22 資料再現) After

Slide 47

Slide 47 text

AI同士の会話のログを出力し確認していた ※再現データです期待結果があるパターンは自動テストがある程度可能だが、生成系は難しい。これはAI同士を自動で会話させそのログを取っていた例。自動で異常検知は出来ないが、毎日目を通していると「ちょっとした変化」に気づく。

Slide 48

Slide 48 text

ログで様々な異変に気づくことができる ※再現データです経験ベースになってしまうが、工数がかからないわりに多くの問題を発見しやすい。再学習後は結構な割合でおかしな部分が発生していた。問題はハイパーパラメータの調整のほか、ロジックで回避などを行う時もある。文章が破綻している短い文章が多い長すぎる文章が多い私の経験ではあるが、生成は壊れるときは全体的におかしな振る舞いになる傾向があり、気づきやすい

Slide 49

Slide 49 text

生成系 (期待する方向性があるもの) の出力について俯瞰、一覧できるような工夫をした

Slide 50

Slide 50 text

Chapter.3 まとめ ● AIにはCACE性という問題が存在する ● できるモノは自動リグレッションテストがいい ○ API自動テスト (Chapter.2) ○ 全体リグレッションテスト Smart speaker QA 24P ● できない場合 ○ 効率化の工夫 ■ 俯瞰できる、一覧できるような工夫 ■ 生成が自動で量産できるなら行う ● それらをログ等で確認

Slide 51

Slide 51 text

(余談) プロンプトエンジニアリングは学習毎では… おしゃべりチャットもベースはプロンプトです。再学習の度に既存のプロンプトで妙な挙動をしていないか確認していました。学習のたびに毎度です。毎度リセットされるので賽の河原テストです。プロンプトエンジニアリングが流行りですが、プロンプトは学習ごとに精度見直しになるでしょう。 LLM ver1.0 呪文を調べまくったぞ！精度などなど書き残すぜ！ LLM ver1.1 すごい呪文集 (ver1.0 調査) 最新の知識を入れてチューニングしたよ！てへぺろ！すごい呪文集 (ver1.0 調査) あれ？なんか前と動きが違う呪文が… ナンデェ!? もうツールに組み込んでるんスけど!! Open

Slide 52

Slide 52 text

生成した。で、俺はどうすればいい? n段階評価の話定性評価の話 Last Chapter

Slide 53

Slide 53 text

生成した。で、俺はどうすればいい? 例：商品説明生成AI タグ : #ポテチ #コンソメ #厚切り説明 (AI自動生成) この絶妙なお菓子は、クリスピーな食感と濃厚な塩味が奇跡のハーモニーを奏でます。一度食べたら止まらない、その魅力にあなたも虜になること間違いなし。極上の味わいをぜひ体験してください！説明文の自動生成AIシステムだけど…… どう評価すればいいんだ？見た感じ良さそうな気がする。

Slide 54

Slide 54 text

n段階の基準を設けて評価例：商品説明生成AI タグ : #ポテチ #コンソメ #厚切り説明 (AI自動生成) この絶妙なお菓子は、クリスピーな食感と濃厚な塩味が奇跡のハーモニーを奏でます。一度食べたら止まらない、その魅力にあなたも虜になること間違いなし。極上の味わいをぜひ体験してください！ 1 : 商品と明らかに異なる説明が入っている、または文章が破綻している 2 : 文章が成立しているが、商品の特徴となるワードが含まれていない 3 : 文章が成立し、商品の特徴となるワードが 1つ含まれている 4 : 文章が成立し、商品の特徴となるワードが 2つ含まれている 5 : 文章が成立し、商品の特徴となるワードが 3つ以上含まれている (例) 5段階評価 (例) “1”は最低限満たすべきことが満たされていない状態。商品説明で異なる説明をした場合は法律に関わる…など。 (例) 100サンプルとってグラフを書いて傾向を見る…など

Slide 55

Slide 55 text

おしゃべりチャットの例おはようございますおはようはい今日は目玉焼きですえっと… あ、はい… 評価は、 1 : 言ってはいけないワードが含まれる 2 : 1文において文章が成立している 3 : nターンにおいて文章が成立している 4 : nターンにおいて会話の内容が成立している…… まつさん、キャラクター性が大事です!! まつさん、会話からストーリーが想像できるかですよまつさん、会話の続きが見たいか…それが大切なんです

Slide 56

Slide 56 text

問題はないかの確認の他、そのシステムで提供したいことは何かを考えなければならない目的や用途、要求にあっているか (例) 自分の理想のキャラクターを作っておしゃべりを楽しむ

Slide 57

Slide 57 text

調査は各社やってきた知見が使えるゲームが狙った通り「楽しめる」かを確かめたい！！社内テストクローズドβテストアプリのアップデートで「使いやすい」くなったか知りたくて震えるユーザーテスト ABテスト ※これら調査は別チームが行うのか、 QAチームでも行うのか確認すること ! ユーザーがAIで「理想のキャラ」を作れるか知りたい！クローズドβテストユーザーテスト

Slide 58

Slide 58 text

(例) エキスパートによる「らしさ」の評価社内には何人か「自分のキャラクター」を持っているメンバーがいた。そのメンバーによるキャラクター性、会話に「らしさ」が出ているかの評価を行っていた。 (某映画の制作の方もアプリの確認をしていた)

Slide 59

Slide 59 text

(例) クラウドワーカーによる定性評価クラウドワーカーの方々に、用意したキャラクターによる会話をお見せして評価してもらうことも行っていた。お金がかかる、結果回収まで時間がかかるというデメリットがある。データサイエンティストチームが用意したキャラクラウドワーカーのみなさんによる定性評価

Slide 60

Slide 60 text

(例) 一部にモデル適用、Discordで情報収集クリティカルな問題がないのであればリリースをしてユーザーの様子を確認し調整を行う。ただモデルを一気にリリースするのではなく、Discordにいらっしゃる一部のユーザーの協力を得てその人たちに公開、生成結果（会話やキャラクター性がよくなったか悪くなったか）をアンケートやヒアリングで確認といった方法も行っていた。 Discordという”つどいの場”を用意

Slide 61

Slide 61 text

Release -> Monitoring -> Turning の Agilityが重要 AIは使ってもらわなければわからないことが非常に多い。リリースを行いユーザーの満足度やニーズの差の把握、または問題を収集し、またPlanningしAIの再学習を行いリリース …という流れとそのAgilityが重要である。MLOpsの体制構築が重要となってくる。 MLOps 出典 : https://blogs.nvidia.co.jp/2020/09/29/what-is-mlops/

Slide 62

Slide 62 text

Last Chapter まとめ ● 期待する方向性を表すような条件を見つけ出して基準をつくる ● 問題がないかの確認の他、要求にあったものを作れているかの調査 ○ 調査は今までの知見が使える(大きく変わりはない) ■ (例) 定性評価 ● エキスパート ● クラウドワーカー ■ (例) 一部ユーザーにだけ提供し確認 ● フィードバックからの精度向上のAgilityが重要 ○ MLOpsの体制作りの重要性

Slide 63

Slide 63 text

みなさまにも AIシステムのテストを行う日がきっと訪れるでしょう。そのとき、参考になったのなら嬉しいです!!

Slide 64

Slide 64 text

おわり

Slide 65

Slide 65 text

Appendix

Slide 66

Slide 66 text

AIシステムに対する品質保証について書かれたもの ● 書籍 ○ AIソフトウェアのテスト　答のない答え合わせ [4つの手法] ● ドキュメント ○ ISTQBテスト技術者資格制度 Foundation Level Specialist シラバス AIテスティング日本語版 ○ AIプロダクト品質保証ガイドライン ○ 機械学習品質マネジメントガイドライン

Slide 67

Slide 67 text

資料 ● JaSST’22 Shikoku ○ 「今までのテストとAIを含んだプロダクトのテストの違い」 ● IT検証フォーラム2018 ○ 「Smart Speaker QA」