中島先生/第2回　AIに“バグ”という見方をしてよいのだろうか 〜その2〜

訓練データが仕様を決める？

興味深いのは、同じ手書き数字認識でも、アラビア数字と漢数字では全く別のモデルが必要になることです。つまり、全く別のプログラムになるのです。これは、使用する訓練データが異なるからであり、訓練データそのものが、いわば“仕様”の役割を果たしていると言えます。従来のように開発者が明示的に仕様を定義するのではなく、集めたデータがシステムの挙動を決めるのです。そして、ある画像を確率的に「７」とみなしたり、「１」とみなしたりします。書き手が「７」のつもりで書いた画像を「１」と見なすことは、AIのバグなのでしょうか。

このような振る舞いをするAIをコンポーネントとしてソフトウェアに取り込んでよいのでしょうか。

“バグ”なのか、性能の限界なのか？

従来のソフトウェアでは、ある入力に対して意図しない出力が生じると、明確に“バグ”と判断できます。ところが、AIでは、たとえ想定外の出力が返ってきたとしても、それがプログラムの欠陥なのか、それとも確率的な揺らぎや、学習不足による限界なのかが判断しにくいです。このことはAIをシステムの一部として組み込む際に開発者が最も苦労するポイントの一つになります。

LLMはさらに“見えないバグ”を増やす

LLM（大規模言語モデル）は自然言語を理解し、生成する能力を持ちますが、その処理内容も、手書き数字の理解と同様に、莫大な量の自然言語で書かれた文を集めて学習をさせます。大量のテキストを元に訓練するため、学習内容が仕様そのものと言えますし、また、大規模言語モデルは確率モデルになっているわけです。したがって、バグがあるかないかを確認することができません。意図しない応答が出ても、その原因を特定することは極めて困難です。これは“バグ”というより、“曖昧な仕様からの逸脱”に近い問題とも言えるでしょう。

LLM開発における品質マネジメントの必要性

LLMの開発では、大規模な数値計算や長期的なクラウド処理が必要となるので、訓練プロセスそのものを綿密に管理することが重要です。途中で障害が発生した場合の「復旧手順」、「進行状況の記録」、「並行処理による数値誤差の蓄積への対処」など、品質を保つための工夫が求められます。

次回の予告
次回は、LLMを実際にシステムに組み込むとき、ユーザとの対話の中でどのような品質上の課題があるか、特にプロンプトの設計や文脈の理解に関する問題を解説します。