2024年5月、デジタル庁から『テキスト生成 AI 利活用におけるリスクへの対策ガイドブック（α版）』が公開されました。
本書自身が「α版」として以下のように注記している通り、生成AIについて特に詳しいわけではもないわたしから見ても、記述に不十分と感じられましたが、「叩き台を作る人はえらい」派の人間なので、このようなものを公開してくれたことに感謝したいです。
実践的なフレームワークやチェックリストによるガイドブックを作成できるまでの知見が蓄積されていないため、留意点の紹介にとどめる。
この記事では、本書の中の特にテスト・品質保証について感じたことを書きたいと思います。本書の概要や構成などについてはすっ飛ばします。
「４ 調達実施前時のテキスト生成AI固有の留意点」について
「４ 調達実施前時のテキスト生成AI固有の留意点」*1では、
AIの利活用を計画しているシステム管理者が、サービスの期待品質を具体的に理解し、これを適切に盛り込んだ調達要件を作成できるようにすることをスコープとする
としています。２でサービスの効果の考え方、３でコストの話をしており、続く４で品質の話、という流れです。
ただ、導入の文章で「非機能要件」という言葉を使っている一方で、各章ではほぼ回答精度の話にのみフォーカスしており、またその実現方法も「テストケースを充実させる」と、いきなりテストに依拠する形になっています。
最初に定められたスコープでは、「期待品質をどのように定めるか」が語られるかと思ったのですが、「期待品質を下回るリスクを、テストでカバーしよう」という論調になっているように見えます。
本書は
- 既存の別ドキュメントを前提としたうえで、リスク軽減の方策についてフォーカスしたものであること
- 特にこの４は、生成AIの開発ではなく、事業者の調達を議論していこと
から、あえて記述を薄くしているのかもしれません。
「５ 設計・開発時のテキスト生成AI固有の留意点」について
４が「調達」であったのに対し、「５ 設計・開発時のテキスト生成AI固有の留意点」は、設計・開発における品質保証です。
本章の目的は、テキスト生成AIを用いたシステムの開発において、生成物の品質を保証し、その評価に関するリスクを軽減するための方法論を提供することである
とあるのですが、5.1では「十分な品質でなかった場合のリスクとその軽減策について述べる」となっています。「品質をどう評価するか」の話のはずが、「品質を評価してダメだったらどうするか」の話になっているように見えるのが気になります。。
QAエンジニア目線では、本書の一番の読みどころは「5.2 テキスト生成AIによる生成物の品質評価・品質保証についてのリスクとその軽減策」です。
この章も構成がややこしい*2ので、5.2.の4)の「この手法には以下のものがある」の部分から読むことをお勧めします。正直、このまとめをまず書いて、この分類に沿って解説していけばいいと思うのですが‥。
このまとめでは、テキスト生成AIを品質保証するための方針と具体策が述べられています。
以下にこれを紹介しますが、分類が一部しっくりこないところがあったので、勝手ながら再構成しています。
方針1: テスト対象のケースを増やす
従来のソフトウェアテストでは、テスト技法の目的の1つは「テストケースを絞り込む」でした。一方機械学習系ソフトウェアにおけるテストでは、「テストケースを増やす」必要性が出てきます。
テストケースの有効な増やし方について、以下の2つを説明しています。
(1) 過去に実際にあったやりとりをそのままテストケースに含める
コールセンター業務のように、過去のやりとりが蓄積されている場合に、その質問をそのままテストデータにするというものです。FAQなどで整理されているようであれば、文字通り頻度高く問われる質問として、テストケースの優先度を上げたりもできそうです。
(2) 作成したテストケースの入力文の言い換え処理をテキスト系生成AIに実施させる
本書では具体的なテスト技法への言及はないのですが、メタモルフィックテスティングの発想に近いと思います。1つのテストケースから多数のテストケースを派生させることで、テストオラクル問題を軽減できます。
メタモルフィックテスティングだと入力側も出力側も変化の対象になりますが、このケースは「入力に多少の変化を加えても、出力が変わらないこと」を期待しているので、限定的な使い方と言えるかもしれません。
「テストケースを増やす」話や、メタモルフィックテスティングについては、こちらの記事でも言及しています。 www.kzsuzuki.com
方針2: 大量のテストケースを評価する
方針1でがんばってテストケースを増やしたとして、結果の妥当性はどう評価すればいいでしょうか。物量と戦うには腕力ということで、評価を機械に肩代わりさせるための策が提案されています。
(1) 知識の有無を選択問題によって評価する
知識が正しく反映されているかを確認する用途であれば、自由回答させるのではなく選択式にすることで、回答の妥当性の確認を機械が代替しやすいです。
(2) 機械的な品質評価手法を導入する
自分の理解に自信がありませんが、「期待値」としての文章を事前に用意したうえで、実際の回答の文章を比較し、その類似度が一定以上であれば正解であると見なす、という考えかと思います。既存の技術も流用できます。
(3) 人間の評価者が行うテストケースを絞り込む
上のような具体策をとったうえで、特定の条件を満たすもののみ人間が評価を行うというものです。
方針3: 主観をできるだけ排除する
生成AIにはバイアスが入り込むリスクがあると言われますが、それは評価側の人間も同様。主観をできるだけ排除するために、以下の2つの策が提案されています。ちょっとレビューと似ていますね。
(1) 評価観点や基準を明確にする
(2) 複数人により独立に実施する
方針4: 生成物のばらつきに対処する
機械学習の話題が盛んになったころから、出力が非決定論的であることは課題の1つとされていました。が、生成AIにおいてはその非決定性がむしろ利点ともなりえます。そして、テストにおける悪夢ともいえます。
提示される方策は以下。
(1) ばらつきに関するパラメータを調整する
テスト以前に「そもそも、ばらつかせない」という方針ですね。GPTでいうところの temperature にあたるパラメターでしょう。temperature は、「値が大きいとランダム性が大きく、小さければより決定論的になる」としています。
(2) 同じテストを繰り返し行う
個人的には、ここに一番興味を持っています。
見た目は同じ条件・同じ入力であっても、原則として出力は同一でない。このような特徴をもったシステムに対して複数回のテストを行って妥当性を判断するというのは、単純なのになぜか面白さを感じています。
次回は、ここにフォーカスした記事を書きたいなと思っています。
おわりに
テキスト生成AIを利用したシステムの開発とそれに伴う調達において、どのようなリスク・留意点があるのかについて、現時点の知識でできるだけ網羅的に記載しようという試みに感謝です。特に、品質評価における具体策は参考になるものでした。
