# タイトルコール テスティングジャーニーへようこそ。 このチャンネルでは、ソフトウェアテストの世界を探索する、をコンセプトに、 エンジニアリングマネージャー兼QAリーダーのサミーが、 ソフトウェアテストのコツや品質保証の奥深さ、そして日々考えていることをお話します。 # 3.1 Hallucinations, Reasoning Errors and Biases こんにちは、さみぃです。今日もテストしていますか? 本編の毎日公知らせなんですけれども、 3月28日の土曜日の午後にですね、 渋谷でアウトプットの第一歩というイベントを行います。 このチャンネルのオフ会という位置づけでまったりするんですけれども、 ありがたいことに、ついでに半分ほどお申し込みいただいておりますので、 発信してみたいけどネタがないとか、 登壇してみたいけど自分の話なんて価値があるのって思っている方に 参加していただきたいワークショップでございます。 あとはですね、発信だったり登壇だったり慣れているよという方も いつもの黙々会の代わりにですね、 今回グループワークで問いかけながら 自分だったらこのことを話せるかもみたいな感じに ネタとかをブラッシュアップしていく時間になりますので、 登壇慣れているよという方もよかったら参加していただけると嬉しいです。 放送の概要欄にリンクを貼っております。 気になる方はお申し込みを忘れないようにお願いします。 はい、ということで本編入っていきます。 今回はISTQBのシラバス、Testing with Generative AIのシラバスを読んでいきます。 今日取り扱うのは3.1、Hallucinations, Reasoning Errors, and Biasesを扱っていきます。 昨日の次回予告で3.1と話したんですけど、 まとめてですね、3.1がっと読んでいこうと思います。 まずはノートブックLMで訳した和訳を読んでいきます。 3.1、ハルシネーション、推論エラー、およびバイアス。 Generative AIシステム、特にLLMは、 ハルシネーション、推論エラー、およびバイアスを含む特定の欠陥が発生しやすい傾向があります。 これらの欠陥はテストタスクにおけるGenerative AIの出力品質を低下させ、 結果としてテスターの期待を満たさないテストウェアが生成されることになります。 テスターはLLMの出力に含まれる、これらのハルシネーション、推論エラー、およびバイアスを特定する必要があり、 これらのリスクを軽減するための措置を講じる必要があります。 LLMの非決定的Non-Deterministicな動作は、この種の欠陥の修正を困難にします。 あるLLM出力では、修正されたように見えても、 同じLLMと別の会話で再発する可能性があります。 一旦ここで切りますが、割と一般的なことが言われています。 ハルシネーション、推論エラー、バイアスなどが入っているから、 気を付けなければいけないというか、自分たちの期待を満たしていないようなアウトプットが出てくることがあるというところと、 非決定的Non-Deterministicな動作、あるLLM出力で修正できたように見えても、 他の会話でまた元に戻ってしまうというのはよくあることかなと思います。 続いて、3.1.1を読んでいきます。 3.1.1、生成AIにおけるハルシネーション、推論エラー、バイアス。 ハルシネーションは、LLMが事実として誤っている、 特定のタスクとは無関係に見える出力を生成したときに発生します。 そしてテストにおいて、ハルシネーションは、LLMが架空のあるいは無関係なテストケースを作成したり、 不正確または機能しないテストスクリプトを生成したり、 存在しない受入れ基準を検証するテストケースを提案したりする形で現れることがあります。 これはテスターを誤導し、誤った方向に導き、テスト出力の妥当性を損なう可能性があります。 推論エラーは、LLMが因果関係、条件付き論理、または段階的な問題解決プロセスなどの論理構造を誤認し、 誤った結論を導き出したときに発生します。 人間とは異なり、LLMは真の論理的推論を書いており、パターンマッチングに依存しているため、 数学的推論などのタスクを実行する際に論理的な誤りを犯す可能性があります。 テスト計画やテストケースの優先順位付けは論理的推論を必要とし、 LLMが推論エラーを犯す可能性があるテストタスクの例です。 LLMのバイアスは、モデルがトレーニングされたデータに由来します。 これらのバイアスは、特定の種類の情報、アプローチ、または仮定を優遇する出力につながる可能性があります。 例えば、主に英語のデータでトレーニングされたLLMは、英語以外の視点を過小評価する可能性があります。 ソフトウェアテストにおいてバイアスは、例えばテストデータの生成や テストケースの受入れ基準の整地化を行う際のLLMの改動に影響を与える可能性があります。 Generative AI出力におけるハルシネーション、推論エラー及びバイアスは、 トレーニングデータの性質とトランスフォーマーモデル固有の制限に起因します。 これらの課題を認識して対処することで、テストプロセスにおける生成AIの結果の変数が向上します。 またここで切りましょう。 1.1では、生成AIにおけるハルシネーション、推論エラー及びバイアスはどういうものなのか、 特にソフトウェアテストにおいてどういうものなのかという説明でした。 それぞれの実例を自分の経験からお話ししていこうと思います。 まず1個目、ハルシネーションですね。 よくあるのが、テスト観点だったり、テスト設計やテストケースを提案してもらうときに、 既存のプロダクトの仕様を知らない、そのコンテキストがないので、 その仕様と異なった期待結果を出すということがよくありますね。 2つ目、推論エラーについては、 テスト計画を生成させたときに出てくる優先度、プロダクトリスクの影響度、発生頻度、優先度 みたいなところの値は結構当てにならないなというのはあったりしますね。 もちろんこちらが渡している情報が少ないというのはあるんですけれど、 結構自分でちゃんとチェックして直しちゃっているなというふうに思います。 バイアスについてはちょっとわからない、気づいたことがないなという感じですかね。 続いて3.1.2を読んでいきます。 3.1.2、LLMストロークにおけるハルシネーション、推論エラー及びバイアスの特定。 生成AIシステムをソフトウェアテストに効果的に統合するには、 LLMストロークにおけるハルシネーション、推論エラー及びバイアスを検出する能力が必要です。 問題のタイプに応じて異なる検出アプローチを適用できます。 以下はレビュー、またはレビューと児童検証を組み合わせて適用される一般的なアプローチです。 まずハルシネーションの検出として3つ書かれています。 1つ目、相互検証。AIが生成した出力を既存のドキュメント、要件及び基地のシステム動作と比較します。 自動化ツールは、確立されたデータソースと出力を相互参照し、不一致にフラグを立てるのに役立ちます。 2つ目、ドメイン専門家の助言。生成されたコンテンツの正確性を検証するために、主題専門家を関与させます。 彼らの専門知識は、自動化システムが見落とす可能性のある微妙な洞察を捉えるために不可欠です。 3つ目、一貫性チェック。生成された出力動詞及び基地の情報との間で一貫性があることを確認します。 自動化システムは、パターンの特定や不一致のフラグ立てに役立ちます。 続いて、推論エラーの検出の方法2つです。 1つ目、論理的妥当性確認。AIが生成したコンテンツの論理的な流れ、 例えば、生成されたテキスト内の論理的一貫性、守備一貫性、構造化された推論をレビューサイクルを通じて一貫性と正しさについて評価します。 自動化ツールが役立つ場合はありますが、複雑なケースでは人間の判断が必要になる場合があります。 2つ目、出力テスト。例えば、生成されたテストケースやテストスクリプトをテスト対象に対して実行し、テスト結果を検証します。 これは、生成されるテストウェアのタイプに応じて部分的または完全に受領ができます。 続いて、バイアスの検出の方法が2つ。 1つ目が、合成テストデータなどの生成されたテストウェアがテスト戦略に対して公平かつ正確に表現されているかをレビューすること。 2つ目、LLMの生成された出力において、過小評価されている非機能テストなどテストタイプに関連するバイアスを評価すること。 最後、これらの検出方法の実際の実施は、生成エイアを活用して実行されるテストデスクにおけるハルシネーション推論エラーまたはバイアスの推定ディスクレベルに依存します。 ということで、3.1.2は、LLMの出力したもの、アウトプットからハルシネーションだったりするエラー、バイアスを見つける能力、見つける方法について、アプローチについて書かれておりました。 自分のコードを振り返ってみると、相場検証とかドメイン専門家の従業員みたいなところにある意味自分で確認をしている。 テスト計画書だったりとかは自分が考えていたのと違うなとかずれてるなみたいなところはチェックしているので、ここでハルシネーション一部見つけられているのかなと思う一方で、 推論エラーとかはできているのかな? 推論エラーのチェックは検出とかあまりできていないし、バイアスの検出というところも感覚的に必見のテスト少ないなとかは思っているかもしれないんですけど、評価みたいなところもできていないし、 ちゃんと検出とか、それを直していくスクリプトを直していくみたいなことにはつながっていないかなというところですね。 まだちょっと難しいなと思いながら読んでおりました。 次のチャプターいきましょう。 # 3.1.3から 3.1.3 ソフトウェアテストタスクにおける 先制AIのハルシネーション・推論エラー及びバイアスの軽減処方 ソフトウェアテストにおける先制AIの望ましくない結果を最小限に抑えるために ハルシネーション・推論エラー及びバイアスを減らすためのいくつかの戦略を採用できます。 これらの問題は、プロンプトが適切に設計されていない場合や 特定のテストタスクに対して関連するコンテキスト入力データが不足している場合に発生しやすくなります。 リスクを軽減するための主な処方には、以下のものが含まれます。 1、2、3、4、5個紹介されています。 1つ目、完全なコンテキストの提供 プロンプトに全ての関連情報が含まれていることを確認し 正確な結果を生成するようにAIを導くための包括的なコンテキストを提供します。 2つ目、プロンプトを管理可能なセグメントに分割 プロンプトチェーン技法を使用して複雑なプロンプトをより小さなステップに分割し 各出力を耐久的に検証してから次のステップに進みます。 この段階的なアプローチは、生成プロセスの早い段階で推論エラーを検出するのに役立ちます。 3つ目、明確で解釈可能なデータ形式の使用 生成AIにとって曖昧であったり、解釈が困難であったりする可能性のある形式を避けます。 構造化された単純な形式は、モデルがタスクの本質的な側面に集中するのに役立ちます。 4つ目、タスクに適した生成AIモデルの選択 このタスクのために特別にトレーニングされたLLMを使用します。 最後5つ目、モデル間での結果の比較 適切な場合、複数のLLMでプロンプトを評価し、出力を比較することで 出力エラーの検出や最も信頼性の高い結果の選択に役立ちます。 第4章では、LLMの結果を改善するための2つの効果的な手法である 検索拡張生成、ラグと微調整、ファインチューニングを紹介します。 ということで、ここでまた切りましょう。 なるほどね、どういう風にハルシネーションするエラーが バイアスを減らしていくかというところで そうですね、自分がやっているのは やっているのはかな、チームも含めてなんですけど やったことあるのは、完全なコンテキストの提供みたいなところで 最初にプロンプトを投げるときに チャット型っていうかチャット形式デッキで投げるときに その中に前提情報とかを全部入れちゃう ボイシートはこういうプロダクトで テストではこういうところを大事にしていて でね、今回のテストだけどこんな感じでみたいなのを 全部プロンプトに入れてしまうっていうのはやったことがあります。 で、2つ目のプロンプトを 管理可能なセグメントに分けるっていうのも 一応意識はしているつもりなんですけどね なんでテスト計画書?違うな 前に一回やったのはテスト完了報告書を作ろうってなったときに そもそも社内にフォーマットがなかったので 今回これこれのプロジェクトで テスト完了の報告書を作りたいと思ってます まずはフォーマットを作ってくださいみたいな で、フォーマットを作るところまでチェックをして その後、じゃあこのプロジェクトのテストケースを インプットを入れてこれでテストの報告書を作ってください みたいな感じで セグメントに分割で合ってるかな 分割をしてちょっとずつ 次のステップに進んでいくっていうのはやってたりします あと明確で解釈可能なデータ形式の使用は まだちょっとやりきれてない感じがありますかね どうしても最初ってちょっと抽象的な言葉とか 曖昧な言葉を使っちゃったりして なかなか自分の欲しい形式でアトプットが出てこない っていうのは本当によくありますよね あとモデル間での結果の比較っていうのは 結構最初の方やってたかな 今は結構クロードのスキル図でやっちゃうので 基本クロードでテスト関連のドキュメント作成は やってたりするんですけど 最初どれ使ったらいいのかなっていうのを考えるときは GPTとGeminiとクロード化とかで 同じようにプロンプトを投げて どういう風に返ってくるかっていうのを見て 比較をしてどれを使うのがいいのかなっていうのは 簡単な評価はしましたという感じですかね ちょっと今日もりもりですね 最後よ3.1.4やっていきましょう 3.1.4 LLMの非決定的動作の軽減 LLM固有の非決定的Non-Deterministicな動作は 同じ入力が提供された場合でも 出力にバリエーションをもたらす可能性があります これは推論中に使用される 確率的なサンプリングプロセスから生じます その結果 LLMを使用する際に 一貫性があり再現可能な結果を得ることは 特に長い出力の場合に困難になる可能性があり 変動のリスクが高まります 完全な再現性は保証できませんが 特定の戦略によって変動を減らすことができます 2つ紹介されています 1つ目 LLMの温度、テンプレートやパラメーター設定の調整 回答生成、過去推論時の温度を下げることで 確率分布を狭めランダム性を減らし より一貫した出力を得ることができます ただしこれにより回答の創造性や多様性も制限され 出力がより反復的または過度に決定的になります 2つ目 ランダムシードの設定 一部のLLMの実装では 乱数ジェネレーターにシード値を設定することができ 同じ基地乱数シーケンスが使用されるようにすることで 再現性を向上させることができます LLM出力におけるハルシネーションや 推論エラーのリスクを減らすには この非決定的動作に対処することが含まれます 例えば出力減少の一部の側面を自動化するなど ということでこの3.1.4のところは そうなんだというふうに読んでました うーんそうなんだでもちょっとよくわかんないな 概要は理解したつもりではいるんですけど じゃあどうやってやるのみたいな具体は ちょっとわかってないなという感じですね 個人的にもと言いますか この非決定的動作 同じプロンプトを投げたとしても 出てくるものが変わってくるっていうのが 自動化っていう文脈だと嫌じゃないですか それって自動化じゃないというか とか学習していく中で じゃあこういうふうにテストケースを作って ってなっても出てくるものが 変わってきちゃうっていうのは 嫌だなでもどうしたらいいんだろうな という感じですね ちょっと可決策はないんですけど この非決定的動作っていうものを 減らしていくことは非常に重要だなという風に考えています # 次回予告 本編が長かったので、お送り話は簡単にします。 今回も最後までお聞きいただきありがとうございました。 明日の放送は語学学習を継続するコツについてお話をしていこうかなと思います。 今回の放送が役に立ったという方は、ぜひハートマーク、いいねをしてください。 それではまた明日、お会いしましょう。ごきげんよう。