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
   事例に学ぶ問題対処法
   

   View Slide

2. 自己紹介
   

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

    View Slide

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

    View Slide

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

    View Slide

13. 本編
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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…..
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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)
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

64. おわり
    

    View Slide

65. Appendix
    

    View Slide

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

    View Slide

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

    View Slide