正しい出力と、説明できる判断の間
AIが高い精度で分類や予測を行っても、仕事で使えるとは限らない。なぜその候補を選んだのか、別の条件なら判断が変わるのか、どの場面では使うべきでないのか。人が責任を持つ現場では、結果を受け取るための説明が必要になる。
1月8日のイノベトピアのインタビューでは、横浜国立大学の長尾智晴氏が、説明可能AI、浸透学習、人とAIの共生について語っている。本記事は、その取材報道と本人の公開研究資料を基に、技術と業務上の判断を整理したものだ。当サイトが長尾氏へ新たに取材した報告でも、紹介する技術を実験して効果を再現した報告でもない。
誰に、何のために説明するのか
説明可能AI、XAIは、単に出力へ文章を付けることと同義ではない。開発者が誤りを探すための説明、現場担当者が採用を判断するための説明、影響を受ける人が理由を理解するための説明では、必要な内容が違う。
NISTの説明可能AIに関する四原則は、根拠を示すこと、対象者が理解できること、説明が実際の処理を反映すること、知識や適用条件の限界を守ることを区別している。読みやすい説明であっても、モデルの処理と無関係な後付けなら、判断根拠としては不十分だ。
例えば工場の検査で、不良と判定した画像のどの領域を参照したかを示す方法は、誤検出を調べる助けになる。しかし、色が付いた場所だけで、本当に欠陥が原因だったと断定できるわけではない。照明、背景、撮影装置の違いに反応していないかを、別のデータや試験で確認する必要がある。これは技術の用途を説明するための仮想例である。
長尾氏が重視する、使う側からの研究
元インタビューで長尾氏は、画像処理や機械学習の成果を社会へつなぐ活動を説明している。大学発ベンチャーのマシンインテリジェンスでの取り組みも、その延長にある。研究対象は一つの深層学習モデルに限定されず、画像、言語、制御などを横断し、人と共に使うAIを目指すという位置付けだ。
横浜国立大学の研究者情報にも、説明できるAI、深層学習・浸透学習、画像処理などの研究活動が掲載されている。ここから確認できるのは研究と連携の対象であり、個別企業での導入効果や、あらゆる課題への有効性を保証するものではない。
業務へ接続する研究では、正答率だけでなく、使うために必要な計測、機器、費用、人の理解が問題になる。高い性能を出すために多くの情報が必要でも、運用時にはその情報が手に入らないことがある。浸透学習は、この学習時と運用時の条件差へ向き合う方法の一つとして紹介されている。
浸透学習は、学習時だけの情報をどう使うか
長尾氏のNEDO公開の講演資料は、浸透学習法をPLM、Percolative Learning Methodと記し、常に使えるMainの情報と、学習時だけ利用できるAuxの情報を区別している。事前学習の後、補助入力との結合を弱めながら別の結合を調整し、運用ではMainだけを使うという考え方だ。
通常の学習でも運用でも、同じ数の入力を必ず用意する方法とは異なる。学習段階で得られる豊かな情報を利用し、その一部がなくても動く回路へ近づける。元インタビューでは、センサー数を抑えることや、将来の情報を学習に使う可能性などが説明されている。
ただし、入力を減らせることと、あらゆる情報を正確に推定できることは違う。Main側に関連する手がかりが乏しければ、補助入力の情報を十分に代替できない可能性がある。新しい場所や条件で関係が変わる場合もある。具体的な効果は課題、データ、評価方法を見て判断する必要がある。
また、学習時に将来の情報を用いる設計では、評価データの扱いを慎重に分けたい。未来の結果を学習用の情報として利用することと、運用時にもその情報を参照できる前提で精度を測ることは異なる。実際に入手できる情報だけで最終試験を行わなければ、実用時の性能を過大に見積もりかねない。
軽量化と説明性は、一緒に確認する
入力する変数や機器が少なくなれば、センサーの設置、保守、通信の負担を減らせる可能性がある。端末での実行へ近づく場合も考えられる。ただし、入力数を減らすだけで処理全体が端末内へ収まるとは限らない。モデルの大きさ、実行時間、メモリー、必要な更新も関係する。
同じく、入力が少ないことだけで判断が説明できるとは限らない。少数の入力から複雑な処理を行う回路もあり、逆に変数が多くても理解しやすい関係を示せる場合もある。軽量化、精度、説明性はそれぞれ測り、どの改善を確認したかを分けて報告したい。
長尾氏の著書『説明可能AI入門』の出版社公開ページには、特徴量や内部状態の可視化、判断根拠の解析、回路構造の軽量化、浸透学習などが並ぶ。手法が一つではないことが分かる。本記事は同書の公開目次と紹介を確認したもので、書籍全体の実践結果を紹介しているわけではない。
モデルへ質問することと、内部を説明すること
対話型AIに「なぜそう答えたのか」と聞くと、整った理由が返ることがある。利用者の理解を助ける場合はあるが、その文章だけで、実際の計算や参照の経路が正しく再現されたとは限らない。説明の生成と、処理の検証を同じものとして扱わないことが重要になる。
業務では、回答へ至る文章のほかに、どの資料のどの版を参照したか、どのツールを呼んだか、何を変更したかという記録が役に立つ。これもモデルの全内部を説明するものではないが、人が確認できる外部の事実として利用できる。説明した内容と実際の操作が一致しているかを照合できるからだ。
説明を求める側も、知りたいことを具体的にするとよい。「理由を説明して」だけでなく、「使ったデータの範囲」「判断を変える条件」「確信が持てない部分」「適用できない例」を分けて聞く。答えが返らない部分を推測で埋めず、確認待ちとして残す設計が必要になる。
一つの強いAIから、多様な専門性へ
元インタビューでは、長尾氏が提唱する「八百万AI」も取り上げられる。さまざまな専門性を持つAIが関与し、一つの強いAIへ判断を集中させないという構想だ。公開講演資料でも、人の専門家がAIの教育や評価へ関わる方向と結び付けて説明されている。
これを、モデルを複数並べて多数決すれば正しくなるという方法に単純化してはいけない。同じ資料や偏りを共有するモデルであれば、全員が同じ誤りを返す可能性もある。異なる意見がどの根拠から生まれたかを確かめ、人が対立を判断できる必要がある。
例えば設備の修理案を検討する仮想場面なら、安全、費用、納期の観点を分ける意味はある。ただし、安全上の必須条件を多数決で覆すことはできない。守るべき条件と、比較して選べる条件を先に分けたうえで、専門性の違う提案を使うことが重要だ。
人の経験を取り込むときに残すもの
熟練者の判断をAIへ反映するという方向にも、説明可能性が関わる。結果だけを正解データにすると、その判断がどの状況で成立したのかが失われることがある。現場では、例外、保留、やらない選択にも知識がある。
以下は当サイトの考察である。経験を記録する際は、入力と結論に加え、確認した条件、迷った理由、他の案を退けた根拠を残すとよい。全件を長文で記録する必要はないが、特殊な状況を一般的なルールへ変えてしまわない工夫が必要だ。
また、経験の提供者が、どこへ使われるかを理解し、内容を訂正できることも重要になる。人の仕事を形式へ変える際には、表現されなかった部分が必ず残る。AIが再現した結果を、その人自身の判断として無条件に紹介しないことが、本人と利用者の双方の信頼につながる。
教育では、出力を点検する経験を作る
取材記事には、長尾氏が学生へAIを実際に使わせる課題に触れる場面もある。便利な道具を禁止するだけでなく、回答を確かめ、自分で判断する経験を作るという問題意識として読める。一方、AIの意見に自分の考えが寄っていくことへの懸念も語られている。
この懸念を、AIを使った人は必ず思想を操作されるという実証結果として紹介するべきではない。研究者の問題提起と、影響を測った調査結果は違う。実務上は、異なる情報源を確認できるか、出力の前提へ異議を出せるか、自分の結論を別の言葉で説明できるかといった具体的な能力に落とし込める。
学習でも仕事でも、AIの答えと人の答えが一致したことだけを成功としない方がよい。違ったときに理由を比較し、どちらの前提が誤っていたかを調べる工程が必要だ。説明可能性は、AIを信じさせるための機能ではなく、人が検討を続けるための材料として使いたい。
導入時に、説明の有用性を試す
説明に使う資料にも版を付ける必要がある。モデルを更新した後に、以前の判定例の説明だけが残ると、現行の処理を説明しているように見えてしまう。モデル、解析手法、画面に表示する文面を一緒に管理し、どの組み合わせを確認したかを追えるようにしたい。
元取材には、画像処理の研究が、特徴を人が組み立てる方法から、データを通して特徴を学ぶ方法へ移ったという長尾氏の回顧もある。深層学習が多くの課題へ広がった背景を、入出力の対応を大規模に学べるようになった変化として説明している。過去の方法がすべて不要になったという意味ではなく、説明の仕方が難しくなる一つの背景として読める。
人が特徴を定義する場合にも、その定義が現場の現象を正しく捉えているかという問題はある。一方、データから学習する方法では、人が予想していなかった手がかりを使う可能性がある。どちらの方法でも、出力が合っている例だけでなく、条件を変えた際の挙動を確かめる必要がある。
このため、説明可能性を求めることは、必ず昔の小さなモデルへ戻すことと同義ではない。用途によっては理解しやすい手法で十分な性能が得られ、別の用途では複雑なモデルと補助的な解析が必要になる。新しさやモデル規模から選ぶより、必要な性能と説明を同時に満たす構成を比較する方がよい。
事業側と開発側で、この比較の前提を共有することも重要だ。営業担当が「理由を説明できる」と案内する場合、それが重要な入力の表示なのか、ルール全体の開示なのか、個別の判定の再現なのかを明確にする。機能の呼び名が同じでも、利用者が期待する説明と実装が一致していなければ、導入後の不信につながる。
企業がXAIを検討する際は、まず誰のどの判断を助けたいかを決める。開発者のための詳細な図を、そのまま利用者へ見せても理解を助けるとは限らない。一方、分かりやすくしようと情報を削り過ぎると、誤った判断を見抜けなくなることがある。
試験では、正しい例だけでなく誤りや曖昧な例を用意し、説明があることで担当者が問題に気付けるかを確かめる。説明を読んだ人の納得度だけを測ると、もっともらしい誤説明が高く評価される恐れがある。実際の処理との一致、理解、判断の改善を分けて見る必要がある。
運用後には、入力データや製品が変わった際に説明も更新されるかを確認する。以前は重要だった変数が別の意味を持つようになれば、過去の説明を再利用できないこともある。記録にはモデルと資料の版、確認した範囲を残し、人が再検討できるようにしたい。
説明できるAIを仕事へつなぐ課題は、技術の内部を見ることと、人が理解して行動できることを結び付ける仕事である。浸透学習や多様な専門AIの構想は、そのための選択肢として検討できるが、用途ごとの検証が欠かせない。当サイト運営のRO合同会社では、AIの判断材料、確認工程、人が担う最終判断の整理について相談を受け付けている。
PR
文賢 →
