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

これまで私がAIに対するテストで経験したことから得た知見です。
どういった問題があって、どういった対応をしたかを4つのChapterで説明しています。
This is the knowledge I have gained from my experience with testing AI thus far. I will explain the types of problems I encountered and how I responded to them in four chapters.

その他資料 / Appendix
「今までのテストとAIを含んだプロダクトのテストの違い」
https://speakerdeck.com/mineo_matsuya/jin-madenotesutototoaiwohan-ndapurodakutonotesutonowei-i

「Smart Speaker QA」
https://www.slideshare.net/mineomatsuya/smart-speaker-qa

Transcript

1. AIシステム開発におけるQA 事例に学ぶ問題対処法
2. 自己紹介
3. 自己紹介 活動: • JaSST(ソフトウェアテストシンポジウム ) Kyushu実行委員 • QA4AI (AIプロダクト品質保証コンソーシアム ) メンバー • ASTER教育メンバー (ソフトウェアテスト技術振興協会 ) • 新人さんからわかるソフトウェアテスト解説マンガ「テスターちゃ ん」作者
4. Quest用VRゲーム(異世界転生もの) を作っています
5. (余談。以下講演ではskip) ChatGPTを大いに利用しています • コード生成 • コードの修正 ◦ 「以下のunityのコードを効率化できますか？」 ◦ 「以下のunityのコードをもっとテストしやすいようにできますか？」 • コードレビュー ◦ 「以下のunityのコードのコードのレビューをしてください」 • ユニットテスト (ハッピーパス) ◦ 「以下のunityのコードのユニットテストを書いてください」
6. (省略) 自分のデータを学習させない設定にする 学習データにしていいかどうかの設定があるため、されたくない内容を扱う場合はOFFに しておく。
7. (余談) コード生成 「小さい便利コード」はChatGPTで生 成。 引数、戻り値が何かは指定している。 納得するまでやり取りを行う。 わからないコードは質問し、確かに説明 があっているか調べる。
8. (余談) コードの修正 (既存コードの微 修正) 実現したいことに必要な部分の説明 を入れ、実現したいことを記載し、コー ドを渡す。 修正したコードは無条件でコピペせ ず、レビューとテストをした方が良い。
9. (余談) コードの修正 (テスト容易性) 「テストしやすいようにできますか」とプ ロンプトを入れてコードを渡す。 例では、依存性の注入がしやすいよう なコードを返してくれている。
10. (余談) コードの修正 (効率化) 「以下を効率的に書くことはできます か」といったプロンプトを入れてコード を送る。 例の場合は、ゲームでよくあるカウント 処理の方法についてMax関数で書く 方法が提案されている。他者がどう コードを書くのかを学ぶこともできる。 (文章生成は要は「よくあるパターン」 で文字列を生成するため)
11. (余談) コードレビュー 「コードレビューをしてください」といっ たプロンプトを入れてコードを送る。 例では、Random.Rangeの上限値の 指摘がされている。またクラスの分割 が提案されている。かなり細かい点ま で指摘してくれるので、勉強にもなる。 与えられたコードでのレビューなの で、人がレビューするように「他の機能 との兼ね合いは大丈夫か？」といった ファイルをまたぐような指摘はされな い。
12. (余談) テストコード生成 ハッピーパスの生成は可能。テストが 十分かは考える必要がある。 例では、Randomの固定を考慮しテス トしている。(コード割愛) unityのtestはSetUpが面倒なことが多 いので、それらの部分を書かせるとい うこともできる。
13. 本編
14. 今回の発表は 私の経験を織り交ぜた AIシステムのテストのチップス集 です。 近い将来、みなさんも AIシステムのテスト担当をすることが あるでしょう。 その時のための話になれば 嬉しい限りです。
15. 目次 • AIの出力に着目した3パターン • Chapter.1 「代表値を1つだけ確認してPass/Failしていいですか!?」 • Chapter.2 「入力値、爆発!!」 • Chapter.3 「再学習したら変なところが壊れた!!」 • Last Chapter 「生成した。で、俺はどうすればいい？」
16. 今までのテスト対象と AIシステムの違い 簡単まとめ 3つの入力→出力のパターンの話 (オレオレまとめ)
17. これまでのシステム AIではないシステムの場合、ルール(仕様)にそった入力に対し、ルール通りに処理され 出力を返す。ルールにそっていない出力の場合は誤りとなる。 仕様にそった入力パターン ルール 仕様にそった出力パターン 入力に対する期待結果がわかる
18. AIシステム3パターン　パターン1 (期待結果がある) 無限に近い入力パターン (フリースタイル) AIコンポーネ ント 仕様にそった出力パターン 犬の画像 猫の画像 「犬」 「猫」 「鳥」 今日の天気は 占って、かに座 天気API 占いAPI エラー応 答 NISAしたい 解約どうやる? NISA説明 解約説明 オペレーター 案内 Q&Aボット スマートスピーカー 画像判定 入力に対して期待結果はある
19. AIシステム3パターン　パターン2 (期待結果不明) 無限に近い入力パターン (フリースタイル) AIコンポーネ ント 仕様にそった出力パターン だけど、どうなればいいかわからない 株価データ 上がる? 下がる? 履歴データ オススメ1 オススメ2 オススメ3 画像データ グループ1 グループ2 グループ3 教師なし学習によるグループ分け (クラスタリング) レコメンド (オススメ) 株価判定 入力に対して期待結果がわからない
20. AIシステム3パターン　パターン2 (期待結果不明) 今回は時間の都合上テストオラクル問題の話はしません。 松谷のJaSST’22 Shikokuの「今までのテストとAIを含んだプロダクトのテストの違い 」の「メタモルフィックテスティ ング」をご参照ください。 株価データ 上がる? 下がる? 履歴データ オススメ1 オススメ2 オススメ3 レコメンド (オススメ) 株価判定 レコメンド系はA/BテストでCVRを 見て調整したりする 画像データ グループ1 グループ2 グループ3 教師なし学習によるグループ分け (クラスタリング)
21. AIシステム3パターン　パターン3 (期待する方向性はある) 無限に近い入力パターン (フリースタイル) AIコンポーネ ント 無限に近い出力パターン (フリースタイル) 芝の上の子猫 芝&子猫の画像 画像生成 入力に対しての期待する方向性はある ハンバーグの 作り方 用意するものはひ き肉、パン粉 文章生成 芝&おじさんの画像
22. 代表値を1つ だけ確認して Pass/Failして いいですか!？ 同値分割の考え方は通用しない話 性能テストの話 Chapter.1
23. 代表値を1つだけ確認してPass/Failしていいですか!? 例えば、ねこ判定AIがあったとして…… ねこ判定 AI システム 猫 猫ではない 猫の画像とそうでない画像それぞ れ大丈夫だったから OK!
24. 今までのテストでは同値分割法で考えていた 同値分割法は、入力値や出力値を同じ特徴をもつグループにわけて、その代表値でテ スト（設計）する方法である。 「同じ処理がされるならどれか代表値で確認しましょう」という考え方。 6歳以下 7歳以上13歳以下 14歳以上 入場料無料 入場料300円 入場料500円 3歳で確認しよう 10歳で確認しよう 18歳で確認しよう
25. AIのテストは同値分割ができない！ AI(機械学習)においては、様々なニューロン（ノード）を通り複雑な計算がされる。我々か らすると同じ猫に分類されるデータでも、少しでも違うデータの場合は活性化するニュー ロンも変わり、全く同じ処理がされることがない。 猫 猫ではない
26. 代表値を1つだけ確認してPass/Failしていいですか!? A. 期待結果があるパターンのAIでも、 同値分割の考え方は通用しません。
27. 代表値を1つだけ確認してPass/Failしていいですか!? といいますか、AIシステムがどれくらいできるかは 「性能テスト」 です ※AIの精度は研究(開発)チームで保証かQAチームでも確認すべきかは確認すること！ 精度＋「こういうデータだと誤 認識した」という 情報も欲しい
28. 4つの評価指標 Accuracy (正解率) Recall (再現率) Precision (適合率) F1スコア
29. Accuracy (正解率) 一番よく使われる指標 Accuracyは正解率。推論した結果全てがどれくらい当たったか。 一番よく使う指標と言える。 この例の場合、10回中7回当たったので、70%となる。 例：株を買った方がいいか買わない方がいいか推論するシステム 買うな 買うな 買うな 買い 買うな 買うな 買い 買うな 買い 買うな 実際 買うな だった 実際 買うな だった 実際 買い だった 実際 買うな だった 実際 買うな だった 実際 買うな だった 実際 買うな だった 実際 買うな だった 実際 買うな だった 推論 実際 実際 買い だった 推論 : 10回 正解 : 7回 7 / 10 = 0.7 70%
30. Accuracy (正解率) Accuracyが高ければいいかというとそうとも言い切れない。 起こる確率が低い場合は、全て「買うな」と予測しておけば正解率は90%となる。 Accuracyはデータセットのバランスがいいものに使う。 例：株を買った方がいいか買わない方がいいか推論するシステム 買うな 買うな 買うな 買うな 買うな 買うな 買うな 買うな 買うな 買うな 実際 買うな だった 実際 買うな だった 実際 買うな だった 実際 買うな だった 実際 買うな だった 実際 買うな だった 実際 買うな だった 実際 買うな だった 実際 買うな だった 推論 実際 実際 買い だった 正解率 90% 全部「買うな」推論
31. Recall (再現率) 当たりをどれだけ拾えていたか？ Recallは、「実際に当たり」を推論でどれだけ拾えていたか、である。 例の場合まずは「実際」に注目。「実際に買いだった」は2回。それを推論で当てられたの は1回。よってRecallは 1 / 2 = 0.5 50% 例：株を買った方がいいか買わない方がいいか推論するシステム 買うな 買うな 買うな 買い 買うな 買うな 買い 買うな 買い 買うな 実際 買うな だった 実際 買うな だった 実際 買い だった 実際 買うな だった 実際 買うな だった 実際 買うな だった 実際 買うな だった 実際 買うな だった 実際 買うな だった 推論 実際 実際 買い だった Recall = 実際に買いだった数 買いの推論で当たった数
32. Recall (再現率) は見逃しを少なくしたいとき 「見逃しを少なくしたい」とき、Recallが高くなるように学習を行うのが良い。 例えばガンの検出など。 ただ上記の例のように、今度は全部当たりを推論しておけば「見逃し」はなくなるため Recallは100%となる。 例：株を買った方がいいか買わない方がいいか推論するシステム 買い 買い 買い 買い 買い 買い 買い 買い 買い 買い 実際 買うな だった 実際 買うな だった 実際 買い だった 実際 買うな だった 実際 買うな だった 実際 買うな だった 実際 買うな だった 実際 買うな だった 実際 買うな だった 推論 実際 実際 買い だった 全部「買い」推論
33. Precision (適合率) 当たり推論の正確性 Precisionは「当たり」と推論したときに、実際にどれだけ当たったか。 例の場合まずは「推論」に注目。「買い」推論は3回。それで「実際に買いだった」は1回。 よってPrecisionは 1 / 3 = 0.33… 約33% 例：株を買った方がいいか買わない方がいいか推論するシステム 買うな 買うな 買うな 買い 買うな 買うな 買い 買うな 買い 買うな 実際 買うな だった 実際 買うな だった 実際 買い だった 実際 買うな だった 実際 買うな だった 実際 買うな だった 実際 買うな だった 実際 買うな だった 実際 買うな だった 推論 実際 実際 買い だった Precision = 買いの推論の数 買いの推論で当たった数
34. Precisionは誤検知を抑えたいとき 「誤検知を抑えたいとき」はPrecisionが高くなるように学習させるのが良い。 例えば迷惑メール判定など。(めったやたらと迷惑メールフォルダに入ってほしくない……) 例：株を買った方がいいか買わない方がいいか推論するシステム 買うな 買うな 買うな 買い 買うな 買うな 買うな 買うな 買うな 買うな 実際 買うな だった 実際 買うな だった 実際 買い だった 実際 買うな だった 実際 買うな だった 実際 買うな だった 実際 買うな だった 実際 買うな だった 実際 買うな だった 推論 実際 実際 買い だった
35. 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…..
36. Chapter.1 まとめ • AIでは同値分割の考え方はできない • AIの精度の評価指標 ◦ Accuracy (正解率) ◦ Recall (再現率) ◦ Precision (適合率) ◦ F1スコア
37. 入力値、 爆発!! API自動テストの話 入力値を絞る話 Chapter.2
38. 入力値、爆発!! 天気は? 天気知りたい 今日の天候は? 天気を知りたい 青森の天気 青森市の天気どう? 今、晴れてる? 天気が知りたい スマート スピーカー 自然言語 処理AI 天気API 占いAPI 音楽API 童話API etc… etc… 同値分割は使えない !! 明日、明後日の場合、 場所が違う時もある！ 占いや音楽機能もテストし なきゃ！
39. API自動テストでゴリ押した (自動テストは必須) 音声認識 自然言語処理 天気API 占いAPI etc API 音声合成 Test Automation Test Data 言葉を 組合せて量産 「Smart speaker QA」16P参照 他事例： 「今までのテストとAIを含んだプロダクトのテストの違い」 メタモルフィックテスティングを使った バグを見つけるための自動テスト 97P参照 音声→テキスト テキスト→コマンド テキスト→音声 コマンド実行
40. 入力値を絞りたい! ログを活用する バグを活用する SNSを活用する マニュアル等にある例は必須 (例) 社内テストをやったら 「今日の天気」が多い (例) 社内テストをやったら 子どもの使う機能は丁寧語が多い (例) 「てにはを」の違い/有無に弱い (例) 体の一部が入ると誤認識があった ・目黒、足利など Twitter / Discordで情報収集 公式が出してるドキュメントの例は通らないと 信用が下がる
41. ニューロンカバレッジを高めるデータ ニューロンカバレッジは、ホワイトボックステストのカバレッジと同じ考えである。 多くのノード(ニューロン)が活性化するデータセット（まだ活性化していないノードを活性化させる ようなデータ)で確認する方法もある。 猫 猫ではない (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)
42. Chapter.2 まとめ • AIのテストでは入力値が爆発する ◦ 確認量が多くなる。自動化できる部分はないか検討 ▪ 期待結果があるパターンではAPI自動テストを行った ▪ 他、テストデータ生成など • 入力値を絞るなら以下が考えられる ◦ ログを活用する ◦ バグを活用する ◦ SNSを活用する ◦ マニュアルにある例を使う ◦ (ニューロンカバレッジを活用 する)
43. 再学習したら 変なところが 壊れた!! Changing Anything Changes Everything Chapter.3
44. 再学習したら変なところが壊れた!! 魚座の運勢は? 天気API 占いAPI 音楽API Before うお座の 運勢は… 魚座の運勢は? 天気API 占いAPI 音楽API After ～♪ AIが学習したら おバカになっちゃった !! そういう名前の アーティストが 入ってきてた!
45. Changing Anything Changes Everything (CACE性) AIの学習＝パラメーターを調整することである。パラメーターは全体が調整される。狙っ たところの精度は上がるかもしれないが他の精度が落ちる可能性がある。何か変えると全 部変わる性質をCACE性といったりする。 猫 犬 犬の精度が悪いからデータ を追加して再学習させよう 学習時は全てのパラメー ターが調整される
46. おしゃべりチャット (生成系)の例 おはよう🌞ドーナッ ツって食べ始めたら止 まらなくなるよね～ わかるー どうして、あんなにお いしいんだろうね～ 甘い物食べた～い☆ 学習 おはようございます おはよう はい 今日は目玉焼きです えっと… あ、はい… Before (Jasst Shikoku’22 資料再現) After
47. AI同士の会話のログを出力し確認していた ※再現データです 期待結果があるパターンは自動テストがある程度可能だが、生成系は難しい。 これはAI同士を自動で会話させそのログを取っていた例。自動で異常検知は出来ない が、毎日目を通していると「ちょっとした変化」に気づく。
48. ログで様々な異変に気づくことができる ※再現データです 経験ベースになってしまうが、工数がかからないわりに多くの問題を発見しやすい。再学習後は結構な割 合でおかしな部分が発生していた。 問題はハイパーパラメータの調整のほか、ロジックで回避などを行う時もある。 文章が 破綻している 短い文章が 多い 長すぎる 文章が 多い 私の経験ではあるが、生成は 壊れるときは全体的におかしな振 る舞いになる傾向があり、気づき やすい
49. 生成系 (期待する方向性があるもの) の出力について 俯瞰、一覧できるような工夫をした
50. Chapter.3 まとめ • AIにはCACE性という問題が存在する • できるモノは自動リグレッションテストがいい ◦ API自動テスト (Chapter.2) ◦ 全体リグレッションテスト Smart speaker QA 24P • できない場合 ◦ 効率化の工夫 ▪ 俯瞰できる、一覧できるような工夫 ▪ 生成が自動で量産できるなら行う • それらをログ等で確認
51. (余談) プロンプトエンジニアリングは学習毎では… おしゃべりチャットもベースはプロンプトです。再学習の度に既存のプロンプトで妙な挙動をしていないか確認し ていました。学習のたびに毎度です。毎度リセットされるので賽の河原テストです。 プロンプトエンジニアリングが流行りですが、プロンプトは 学習ごとに精度見直し になるでしょう。 LLM ver1.0 呪文を調べま くったぞ！ 精度などなど 書き残すぜ！ LLM ver1.1 すごい 呪文集 (ver1.0 調査) 最新の知識を入れ てチューニングした よ！ てへぺろ！ すごい 呪文集 (ver1.0 調査) あれ？ なんか前と動きが違 う呪文が… ナンデェ!? もうツールに組み込 んでるんスけど!! Open
52. 生成した。 で、俺は どうすれば いい? n段階評価の話 定性評価の話 Last Chapter
53. 生成した。で、俺はどうすればいい? 例：商品説明生成AI タグ : #ポテチ #コンソメ #厚切り 説明 (AI自動生成) この絶妙なお菓子は、クリスピーな食感と濃厚な 塩味が奇跡のハーモニーを奏でます。一度食べ たら止まらない、その魅力にあなたも虜になるこ と間違いなし。極上の味わいをぜひ体験してくだ さい！ 説明文の自動生成AIシステムだけど…… どう評価すればいいんだ？ 見た感じ良さそうな気がする。
54. n段階の基準を設けて評価 例：商品説明生成AI タグ : #ポテチ #コンソメ #厚切り 説明 (AI自動生成) この絶妙なお菓子は、クリスピーな食感と濃厚な 塩味が奇跡のハーモニーを奏でます。一度食べ たら止まらない、その魅力にあなたも虜になるこ と間違いなし。極上の味わいをぜひ体験してくだ さい！ 1 : 商品と明らかに異なる説明が入っている、また は文章が破綻している 2 : 文章が成立しているが、商品の特徴となるワー ドが含まれていない 3 : 文章が成立し、商品の特徴となるワードが 1つ 含まれている 4 : 文章が成立し、商品の特徴となるワードが 2つ 含まれている 5 : 文章が成立し、商品の特徴となるワードが 3つ 以上含まれている (例) 5段階評価 (例) “1”は最低限満たすべきことが満たされていない状態。 商品説明で異なる説明をした場合は法律に関わる…など。 (例) 100サンプルとって グラフを書いて傾向を見る…など
55. おしゃべりチャットの例 おはようございます おはよう はい 今日は目玉焼きです えっと… あ、はい… 評価は、 1 : 言ってはいけないワードが含まれる 2 : 1文において文章が成立している 3 : nターンにおいて文章が成立している 4 : nターンにおいて会話の内容が成立して いる…… まつさん、キャラクター性が大事です!! まつさん、会話からストーリーが 想像できるかですよ まつさん、会話の続きが見たいか…そ れが大切なんです
56. 問題はないかの確認の他、 そのシステムで提供したいことは 何か を考えなければならない 目的や用途、要求に あっているか (例) 自分の理想のキャラク ターを作っておしゃべりを 楽しむ
57. 調査は各社やってきた知見が使える ゲームが狙った通り 「楽しめる」かを 確かめたい！！ 社内テスト クローズドβテスト アプリのアップデートで 「使いやすい」くなったか 知りたくて震える ユーザーテスト ABテスト ※これら調査は別チームが行うのか、 QAチームでも行うのか確認すること ! ユーザーがAIで 「理想のキャラ」を 作れるか知りたい！ クローズドβテスト ユーザーテスト
58. (例) エキスパートによる「らしさ」の評価 社内には何人か「自分のキャラ クター」を持っているメンバーが いた。 そのメンバーによるキャラクター 性、会話に「らしさ」が出ている かの評価を行っていた。 (某映画の制作の方もアプリの確認をしていた)
59. (例) クラウドワーカーによる定性評価 クラウドワーカーの方々に、用意したキャラクターによる会話をお見せして評価してもらうこと も行っていた。お金がかかる、結果回収まで時間がかかるというデメリットがある。 データサイエンティストチームが用意したキャラ クラウド ワーカーの みなさんによる 定性評価
60. (例) 一部にモデル適用、Discordで情報収集 クリティカルな問題がないのであればリリースをしてユーザーの様子を確認し調整を行う。 ただモデルを一気にリリースするのではなく、Discordにいらっしゃる一部のユーザーの 協力を得てその人たちに公開、生成結果（会話やキャラクター性がよくなったか悪くなっ たか）をアンケートやヒアリングで確認といった方法も行っていた。 Discordという”つどいの場”を 用意
61. Release -> Monitoring -> Turning の Agilityが重要 AIは使ってもらわなければわからないことが非常に多い。リリースを行いユーザーの満足 度やニーズの差の把握、または問題を収集し、またPlanningしAIの再学習を行いリリース …という流れとそのAgilityが重要である。MLOpsの体制構築が重要となってくる。 MLOps 出典 : https://blogs.nvidia.co.jp/2020/09/29/what-is-mlops/
62. Last Chapter まとめ • 期待する方向性を表すような条件を見つけ出して基準をつくる • 問題がないかの確認の他、要求にあったものを作れているかの調査 ◦ 調査は今までの知見が使える(大きく変わりはない) ▪ (例) 定性評価 • エキスパート • クラウドワーカー ▪ (例) 一部ユーザーにだけ提供し確認 • フィードバックからの精度向上のAgilityが重要 ◦ MLOpsの体制作りの重要性
63. みなさまにも AIシステムのテストを行う日が きっと訪れるでしょう。 そのとき、参考になったのなら 嬉しいです!!
64. おわり
65. Appendix
66. AIシステムに対する品質保証について書かれたもの • 書籍 ◦ AIソフトウェアのテスト　答のない答え合わせ [4つの手法] • ドキュメント ◦ ISTQBテスト技術者資格制度 Foundation Level Specialist シラバス AIテスティング日本語版 ◦ AIプロダクト品質保証ガイドライン ◦ 機械学習品質マネジメントガイドライン
67. 資料 • JaSST’22 Shikoku ◦ 「今までのテストとAIを含んだプロダクトのテストの違い」 • IT検証フォーラム2018 ◦ 「Smart Speaker QA」