JaSST nano vol.19で『ISO/IEC/IEEE 29119-11からAIシステムのブラックボックステストについてメモってみたの』というタイトルで発表しました #jasstnano

　タイトル長すぎてすみません。
　発表資料はこちらです。

　vol.19は、わたしが発表予定を確認した時点では石川冬樹先生の「画像生成AIのQAを考えてみる」しかエントリーされておらず、「専門家の話を聞く前の前座として、AIのテストについての初歩的な話をするのはいい考えなのでは！？」と思って準備し始めたのですが、当日に準備が間に合う自信がもてたのが2日前で、あまりに遅すぎました・・・。

jasst-nano.connpass.com

　ということで、石川先生のご発表と、JaSST実行委員会メンバーたちによる熱いディスカッションの間に堕ちた謎のおみそ発表になってしまいました。
　が、イベントドリブンで勉強できたのでいいとしましょう！

　将来の（自分の）検索性のため、中身の一部をリサイクルして、ブログ記事にしておきます。
　以下の情報は、ISO/IEC/IEEE 29119-11の第5章「5. AIシステムの特徴」、第6章「6.1.12. AIベースシステムのテストオラクル問題」、第8章「8. AIベースシステムのブラックボックステスト」の一部を参考にし、自分の解釈を追加したものです。

テストオラクル問題

　AIベースのソフトウェアではしばしば、「テストオラクルがない」ことが問題になります。
　そもそもテストオラクルとは何で、それが欠けるというのはどういうことなのでしょうか。

テストオラクル

　ざっくりいうと、テストにおいて「この結果は正しいね」と判断するための根拠のことです。
　わかりやすいのは「仕様書」ですが、それだけではありません。

　ISTQB用語集から引用します。

テスト対象のソフトウェアの実行結果と比較する期待結果のソース。
オラクルは、実在する（ベンチマーク用の）システム、他のソフトウェア、ユーザマニュアル、個人の専門知識の場合があるが、コードであってはならない。
（ISTQB用語集）

　テストオラクルの種類の例は、以下の通りです。

そのソフトウェアをふるまいを記述したドキュメント: 仕様書、ユーザーマニュアルなど
比較対象にできるソフトウェア: 競合製品など
過去の履歴: 過去のテストケース実行結果など
人間の知識: 「専門家がOKと判断すればOK」など。
その他

www.kzsuzuki.com

テストオラクルが不足しがちな理由

　6.1.12では、5章は6章で述べられたAIシステムの特徴や課題から、テストオラクルが欠落してしまう原因について説明しています。

仕様がない！

仕様の記述が、従来以上に不完全・非形式的になりがちで、期待値を決めるのが難しい。
「未知の洞察」を得ることが目的のシステムであれば、本質的に期待値は未知となる。

　「今まで誰も知らなかった特徴を見出す」といったことを目的としていた場合、その期待値を「誰も知らない」のは必然ですよね。

複雑！

典型的なニューラルネットワークでは、一つの判断を行うだけでもパラメタの数が1億超えだったりする。

　規格策定時でこれなので、今だともっと多いのかもしれません。

確率的・非決定的

AIベースシステムの多くは確率的（probabilistic）な実装をしているため、非決定的（non-deterministic）になる。
非決定性にともなう変動を考慮に入れた、「賢い期待値」（smarter expected result）が必要。

　たとえばある位置から別の位置へのルートが複数ある状況で「最短ルート」を求める*1場合、厳密な解を見つけることが困難であるため、初期値を元に選ばれたルートから導かれる「準・最適な解」（sub-optimal）をヨシとすることがあります。この初期値をランダムに与えている場合、実行のたびに別の結果が出ることになり、出力の再現性の欠如がもたらされます。

自己学習する！

システムが新しいデータを学ぶことでふるまいが変化していく。

　新たな学習データをモデルに取り込むことで、精度を上げたりデータの新しい傾向に追随していったりするので、当初うまく通ったテストが、後のシステムでは通用しないかもしれません。

29119-11で説明しているブラックボックステスト

　Part11では、以下の5つについて説明しています。
　ただし、このすべてがテストオラクル問題を解決できるわけではありません。

8.1. 組み合わせテスト
8.2. バックツーバックテスト
8.3. A/Bテスト
8.4. メタモルフィックテスト
8.5. 探索的テスト

組み合わせテスト (Combinatorial Testing)

　要件に合致していることを完全に証明するには「全数テスト」が必要ですが、非現実的です。ペアワイズなどの組み合わせテストの技法によって、システマティックかつ効果的に、テストケースを大きく削減できます。テストケースを合理的に減らすことが目的であり、テストオラクル問題は解決できません。

　組み合わせテストの技法は既存のソフトウェアテストでも利用されていますが、AIベースシステムにおいて適用する場合には特に、以下の2つの課題があるとしています。

AIベースシステムではパラメタの数自体が膨大で、組み合わせテスト技法を使ってもなおテストセッが巨大なので、自動化と、仮想的なテスト環境が必要である。
そもそも、ペアワイズ（2因子間網羅）で十分なのかも議論の余地がある。

バックツーバックテスト (Back-to-back testing)

　そのシステムの「代替バージョン」*2を、擬似的なオラクルとして用いる方法です。
　過去のJaSSTで、あまりに複雑なJR料金計算の答え合わせをするために、このような手法を取ったことが報告されています。

www.publickey1.jp

テスト対象となる実機用の運賃ソフトウェアと、検証用の運賃ソフトウェアは別のチーム、別のアルゴリズム、別のプログラミング言語で作ります。実機用はC++ですが、検証用はJavaで言語特有のバグをなくそうとしています。

　2つのシステムの独立性が高いことがこの手法の条件なのですが、AIベースシステムの場合、利用するOSSが似たり寄ったりになり、独立性を保つのが難しいとしています。

A/Bテスト (A/B testing)

　WebサービスのUIデザインの優位性を評価する、統計的な手法としてよく聞くものです。
　2つを比較するという意味で、バックツーバックテストに少し似ているようにも思えますが、バックツーバックテストは2つのシステムの実行結果を比較するのに対し、A/Bテストはモデル全体の性能を比較するものです。

　AIで何かを判定する場合の「性能」については、以下の記事に書きました。

www.kzsuzuki.com

メタモルフィックテスト (Metamorphic testing)

　正しいとわかっている元テストケースから、後続テストケースを生成する手法です。
　これだけでは全然意味不明なので、2018年に書いた記事を載せておきます。

www.kzsuzuki.com

　ある入力と出力のセットに対し、「入力をこう変えれば、出力はこう変わる（あるいは変わらない）」ということの関係を、「メタモルフィック関係」といっています。これを利用して、1つのメタモルフィック関係から、複数の後続テストケースを得ることができます。
　新しいテストケースの期待出力まで生成することができるので、テストオラクル問題を解決する方法の1つと言えます。

　規格では、「従来のテストオラクルを使うことで検出できるバグの90%が、3～6種類のメタモルフィック関係でカバーされるとの研究がある」としています。にわかには信じられず誤訳の可能性もあるので、ちょっと原典を当たってみようと思います。

探索的テスト (Exploratory testing)

　みんな大好き探索的テストです。
　テストケースや手順を事前に記述しておくのではなく、対象のソフトウェアを触って学習しながら、次に行うべきテストをその場で定め、実行していくものです。
　得られた結果が妥当かどうかは都度、人間が判断するので、ある意味ではテストオラクル問題を解決している・・・と言えるかもしれません。