Note 当文書はChapter Summariesを日本語に翻訳したものです。
この文書は書籍の各章のまとめです。章の本来の内容を読まないと、まとめだけでは伝わりづらいものがあるかもしれませんが、本書の大体の内容を感じ取って頂ければと思います。
- 1章.機械学習システムの概要
- 2章.機械学習システム設計の概要
- 3章.データエンジニアリングの基礎知識
- 4章.訓練データ
- 5章.特徴エンジニアリング
- 6章.モデル開発とオフライン評価
- 7章.モデルのデプロイと予測サービス
- 8章.データ分布のシフトと監視
- 9章.実現場での継続学習とテスト
- 10章.MLOpsにおけるインフラとツール
- 11章.機械学習の人的側面
最初の章となる本章では、機械学習モデルを実世界に導入する上で必要な事柄を読者に理解してもらうことを目的としました。まず今日の実現場における幅広い機械学習のユースケースを見ることから始めました。多くの人はコンシューマー向けのアプリケーションで機械学習に触れていますが、機械学習のユースケースの大半はエンタープライズ向けです。また、どのような場合に機械学習ソリューションが適しているのかについても説明しました。機械学習は多くの問題をとてもうまく解決できますが、すべての問題を解決できるわけではありませんし、すべての問題に適しているわけではないことは明らかです。しかし、機械学習が解決できない問題に対しても、その一部を機械学習で解決できる余地があります。
また本章では、研究分野での機械学習と実現場での機械学習との違いについても触れました。この違いは、利害関係者の関与、計算の優先順位、使用するデータの特性、公正さの課題の重要性、説明能力の重要性などが挙げられます。本節は学術分野から機械学習の現場に移る人にとって最も役に立ちます。また、機械学習システムが従来のソフトウェアシステムとどのような違いがあるかについても説明し、本書の必要性を動機付けました。
機械学習システムは、多くのさまざまな要素から構成される複雑なものです。データサイエンティストや機械学習エンジニアが実現場で機械学習システムを扱う場合、機械学習アルゴリズムの部分だけに注目していてはまったく十分でないことが分かります。それ以外のデータスタック、デプロイ、監視、メンテナンス、インフラなどのシステムの他の側面について理解しておくことが重要です。本書では、機械学習システムの開発にシステムアプローチを採用しており、機械学習アルゴリズムだけを見るのではなく、システムを構成するすべての要素を包括的に捉えて考えます。この全体論的アプローチが何を意味するのかについては次章で詳しく説明します。
本章では機械学習システム設計の概要と機械学習システムを設計する際に念頭に置くべき検討事項について説明しました。
すべてのプロジェクトは、そのプロジェクトがなぜ必要なのかという理由があってこそ開始できるものであり、機械学習プロジェクトも例外ではありません。本章は、ほぼすべてのビジネスにおいて、ビジネスの指標に影響を与えない限りは機械学習の指標に関心を持たないという前提を説明するところから始めました。ですから、何らかのビジネス向けに機械学習システムを構築するのであれば、ビジネス目標に基づく必要があり、そのビジネス目標を機械学習の目標に変換して機械学習モデルの開発を導く必要があります。
機械学習システムを構築する前に、そのシステムの良し悪しを判断する上で満たすべき要件を理解する必要があります。具体的な要件はユースケースによって異なりますが、本章では最も一般的な4つの要件（信頼性、拡張性、保守性、適応性）にフォーカスしました。これらそれぞれの要件を満たすテクニックについては本書全体を通して説明していきます。
機械学習システムの構築は一度きりのタスクではなく反復的なプロセスであると言えます。本章では、前述した要件を満たす機械学習システムを開発する反復型プロセスについて説明しました。
本章の最後では、機械学習システムにおけるデータの役割についての哲学的な議論を取り上げました。依然として多くの人が、インテリジェントなアルゴリズムがあれば最終的には大量のデータに勝利できると考えています。しかし、AlexNet、 BERT、 GPTなどのシステムの成功は、過去10年間の機械学習の進歩が大量のデータにアクセスしたおかげであることを示しています。データがインテリジェントな設計に勝利できるかどうかに関係なく、機械学習におけるデータの重要性は誰も否定することはできません。本書の見どころは、データにまつわるさまざまな問題に光を当てることに力を入れている点です。
複雑な機械学習システムもシンプルな構成要素から成り立っています。実運用されている機械学習システムの俯瞰的な概要をこれまでに説明しました。以降の章では、この構成要素を詳しく見ていきます。次章ではデータエンジニアリングの基礎知識について触れます。本章で述べた内容を抽象的に感じたとしても以降の章で具体的に述べていくので、理解できるようになると思います。
本章は、2章で確立した基礎知識をベースとして、機械学習システムの開発におけるデータの重要性に触れました。データを後で簡単に使用できるように適切なフォーマットで格納することが重要であることを学びました。また、行優先と列優先、テキスト形式とバイナリ形式などのさまざまなデータフォーマットの長所や短所について説明しました。
それから、リレーショナルモデル、ドキュメントモデル、グラフモデルの3つの主要なデータモデルについて説明しました。SQLが普及したことでリレーショナルモデルが最もよく知られていますが、今では3つのモデルすべてが広く使用されており、それぞれに適したタスクがあります。
リレーショナルモデルとドキュメントモデルを比較する際、前者が構造化されたもので後者が構造化されていないものだと多くの人が考えがちですが、構造化データと非構造化データの境界はとても流動的です。肝心な点はデータの構造に関する責務がどこにあるのかということです。構造化データではデータを書き込む側のソースコードが構造に関する責務を担う必要があり、非構造化データではデータを読み込む側のソースコードがその責務を担う必要があります。
続けて本章ではデータストレージエンジンと処理に触れ、トランザクション型処理と分析型処理というデータ処理を最適化する2種類のデータベースについて学びました。データストレージエンジンと処理とをまとめて学んだ理由は、従来のストレージは処理と一体となっており、トランザクションデータベースはトランザクション型処理に、分析データベースは分析型処理に使われるためです。しかしながら近年では多くのベンダーがストレージと処理を分離すべく取り組んでおり、現在では分析クエリーを扱えるトランザクションデータベースやトランザクションクエリーを扱える分析データベースが誕生しています。
データフォーマットやデータモデル、データストレージエンジンとその処理などについて議論する場合、データがひとつのプロセス内にあることが前提になります。しかし、実現場では複数のプロセスで動作することになるため、プロセス間でデータの受け渡しが必要になることが多いでしょう。データの受け渡しには3つの形態があることを説明しました。最もシンプルなのは、データベースを経由した受け渡しです。プロセス間のデータの受け渡しで最も一般的なものは、サービスを経由したデータの受け渡しです。この形態では、あるプロセスをサービスとして公開し、別のプロセスからデータのリクエストを送信してもらいます。このデータの受け渡しの形態は、アプリケーションの各コンポーネントがサービスとして設定されるマイクロサービスアーキテクチャーと密接に関係しています。
ここ最近の10年間でますます一般的になってきたデータの受け渡し方法はApache KafkaやRabbitMQのようなリアルタイム伝送を介したデータの受け渡しです。この方法は、データベース経由のデータの受け渡しとサービスを経由したデータの受け渡しとの中間に位置するもので、非同期なデータの受け渡しをかなり低いレイテンシーで実現できます。
「バッチ処理 vs. ストリーム処理」の節で説明したように、リアルタイム伝送のデータはデータベースのデータとは異なる特性があるため、処理するには別の技術が必要です。データベースのデータは多くの場合バッチジョブで処理され、静的な特徴を生成するのに対し、リアルタイム伝送のデータはストリーム計算エンジンを使用して処理され、動的な特徴を生成します。バッチ処理はストリーム処理の特殊なケースであるため、ストリーム計算エンジンを使用して両方の処理パイプラインを統合できると主張する人も存在します。
今日の機械学習アルゴリズムの基礎を形作るものは、やはり訓練データです。いかにアルゴリズムが優れていても、訓練データの質が悪ければアルゴリズムはよいパフォーマンスを発揮できません。アルゴリズムに意味のあることを学習させるには、時間と労力をかけてデータを整備することが重要です。
本章では、データの作成に関連する様々な手順について取り上げました。まず、目的に合わせてデータを選択する手段として、非確率サンプリングやランダムサンプリングなどのサンプリング手法を紹介しました。
今日の機械学習アルゴリズムの大半は教師あり機械学習アルゴリズムであるため、訓練データの作成にはラベルを得ることが不可欠です。配送時間の予測やレコメンドシステムなどのような多くのタスクに天然のラベルがあります。天然のラベルが得られるまでには時間がかかりますが、予測を提供してからこのフィードバックが得られるまでの時間がフィードバックループの長さになります。天然のラベルがあるタスクは業界では非常に一般的なので、企業は天然のラベルがないタスクよりも天然のラベルがあるタスクから優先して取り組もうとする傾向があります。
天然のラベルが存在しないタスクに対しては、多くの企業では人間のアノテーターを使ってデータのアノテーションを行っています。しかしながら手作業によるラベル付けにはコストも時間もかかり、さまざまな問題点があります。弱教師学習、半教師学習、転移学習、能動学習などのさまざまな手法を用いてこのような手作業によるラベルの不足を解消する方法を説明しました。
機械学習アルゴリズムは、データが均等に分布していればうまく動作しますが、クラスの不均衡が激しい状況ではうまく動作しません。しかしながら現実世界ではクラスの不均衡はよくある問題です。以降の節では、なぜクラスの不均衡が機械学習アルゴリズムの学習を困難にさせるのかについて説明しました。それから、正しい評価指標の選択方法やデータの再サンプリング方法、損失関数を修正して特定のサンプルに注意を向ける方法など、クラスの不均衡を対処するさまざまな手法についても説明しました。
本章の最後では、データオーグメンテーションの手法がコンピュータビジョンや自然言語のタスクの両方でモデルのパフォーマンスと一般化を向上させることを述べました。
今日の機械学習システムの成功は依然としてその特徴に依存しているため、実際の現場で機械学習を使用する組織にとっては特徴エンジニアリングに時間と手間をかけることが重要です。
優れた特徴を設計する方法は確実な答えのない複雑な問題であり、経験から学ぶことが最善の方法です。さまざまな特徴を試して、それがモデルのパフォーマンスにどのような影響を与えるかを観察しましょう。専門家から学ぶこともできます。私にとっては、Kaggleコンペティションで勝者となったチームが特徴をどのように設計したかを読むことが、彼らのテクニックや考え方を知る上でとても役に立ちました。
特徴エンジニアリングには対象分野の専門家の関与が求められますが、その専門家が必ずしもエンジニアであるとは限りません。非エンジニアの人もプロセスに貢献できるようにワークフローを設計することが重要です。
ここに特徴エンジニアリングのベストプラクティスをまとめました。
- データを訓練用・検証用・テスト用のデータセットに分割するする際に、ランダムに分割するのではなく時間で分割する
- データをオーバーサンプリングする場合は分割後に実施する
- データを分割してからスケーリングや正規化を行いデータリークを防止する
- 特徴のスケーリングや欠損値の対処にはデータ全体ではなく分割した訓練データのみから得られる統計量を使用する
- データの生成方法、収集方法、処理方法を理解する。可能であればドメインの専門家の関与を促す
- データのソースを追跡し続ける
- モデルに対する特徴の重要度を理解する
- 特徴をうまく汎化して使用する
- 不要になった特徴はモデルから削除する
優れた特徴を得たので、ワークフローの次の工程である機械学習モデルの訓練に移りましょう。実際に移る前に、モデリングの工程に移ったからといって、データの処理や特徴エンジニアリングが完了したわけではないということを繰り返し念を押しておきたいと思います。データや特徴に対する作業が完了することは決してありません。現実世界の機械学習プロジェクトほぼすべてで、データを収集するプロセスと特徴エンジニアリングはモデルが実際に稼働している限り続きます。新たに得たデータを使ってモデルを継続的に改善する必要があります。これについては9章で説明します。
本章では、機械学習システムの一部である機械学習アルゴリズムについて取り上げましたが、機械学習を実践している人々の多くが、機械学習プロジェクトのライフサイクルの中で最も面白い部分だと感じています。データや特徴エンジニアリングに費やした重労働の集大成に（予測という形で）生命を吹き込み、ついに最初のモデルで仮説を評価できる（入力を与えて出力を予測できる）ようになります。
本章では、私たちのタスクに最適な機械学習モデルを選択するにはどうすればよいかということから取りかかりました。具体的なモデルやアーキテクチャーの長所と短所を説明することは差し控えましたが、世の中に存在するモデルの数が日々続々と増え続けていることを考えれば当然のことです。よって、その代わりに、自分たちの目的・制約・要件に最適なモデルを選択する上で考慮すべき事項に焦点を当てました。
続けて、モデル開発のさまざまな側面を説明しました。単独のモデルだけでなくコンペティションやリーダーボード形式の研究の中で幅広く使用されているモデルのアンサンブルも取り上げました。
モデルの開発フェーズの中では、さまざまなモデルを実験することになりますが、大量の実験を徹底的に追跡してバージョンを管理することの重要性は皆が認めるものの、多くの機械学習エンジニアはこの作業にやりがいを感じておらずいまだに省略しようとします。そのため、追跡とバージョン管理のプロセスを自動化するツールと適切なインフラが不可欠です。機械学習開発のツールやインフラについては10章で取り扱います。
今日のモデルはますます巨大化しており、さらに多くのデータが必要となっています。機械学習モデル開発者にとって分散訓練は必須のスキルになりつつあるので、データの並列化、モデルの並列化、パイプラインの並列化などの並列化手法について説明しました。大規模な（数十億とは言わないまでも数億のパラメーターを持つモデルを実行するような）分散システムでモデルを動作させることは難易度が高く、システムエンジニアリングの高度な専門知識が求められます。
本章の最後では、デプロイに最適なモデルを評価する方法について述べました。評価指標は、比較対象となるベースラインが存在しなければあまり意味がありません。評価のために検討すべきさまざまなタイプのベースラインについて説明しました。また、本番の環境で実際でモデルを評価する前にモデルの健全性を確認するために必要なさまざまな評価手法についても説明しました。
オフラインでの評価がいかに優秀であったとしても、実際にデプロイしてみない限り実環境でのモデルのパフォーマンスに確証が持てません。次章では、モデルをデプロイする方法について説明します。
本章はおそらく本書の中で最も技術色が濃い章のひとつです。本章の技術色が濃い理由は、機械学習モデルのデプロイが機械学習の課題ではなくエンジニアリングの課題であるためです。
これまで、オンライン予測とバッチ予測、エッジ上の機械学習とクラウド上の機械学習を比較しながら、モデルのさまざまなデプロイ方法について説明してきました。それぞれの方法にはそれぞれの課題があります。オンライン予測によってユーザーの嗜好の変化に対してモデルが迅速に反応できるようになりますが、推論のレイテンシーを気にしなければなりません。また、バッチ予測はモデルの予測の生成に時間がかかりすぎる場合の回避策になりますが、モデルの柔軟性が低下します。
同様に、クラウドで推論することは簡単ですが、ネットワークのレイテンシーやクラウドのコストによっては実用的ではなくなります。エッジで推論するには、十分な計算能力、メモリ、バッテリーを備えたエッジデバイスが必要です。
ただし、これらの課題のほとんどは機械学習モデルを実行するハードウェアの限界に起因するものだと私は考えています。今後ハードウェアの性能が向上し、機械学習向けに最適化されれば、機械学習システムはオンデバイスでのオンライン予測に移行していくでしょう。
かつて私は、機械学習プロジェクトはモデルをデプロイしたら終わりと考えていましたが、それが大きな誤りであったことを本章で明らかにしておきたいと思いました。モデルを開発環境から実環境に移すとまったく新しい問題が生じます。まず何よりもモデルをどうやって実環境で維持するかということです。次章では、モデルが実環境でどのような障害を引き起こすのか、そして問題を検出し、できる限り早く対処するためにモデルを継続的に監視する方法について説明します。
本書を執筆する中でも本章は最も難しい章だったかもしれません。その理由は、システムが実環境で障害を起こす仕組みや理由を理解することは重要であるにもかかわらず、そのことを扱った文献があまりないからです。我々が考えるときには実際の現場よりも研究のほうが先を行っていることが多いものですが、この機械学習の領域ではいまだに実際の現場に研究が追いつこうとしている最中です。
機械学習システムの障害を理解するために、障害をソフトウェアシステムの障害（機械学習システムではないシステムにも発生する障害）と機械学習システム特有の障害の2つに区別しました。現在の機械学習の障害の大部分は機械学習特有のものではありませんが、MLOpsを取り巻くツールやインフラが成熟するにつれて、この状況は変わっていくかもしれません。
また、機械学習に特有な3つの主要な障害の原因である、訓練データと実環境のデータとの差異、エッジケース、フィードバックループの悪化を説明しました。前者2つは原因がデータに関連するものであるのに対し、最後の3つ目はシステムの出力がシステムの入力に影響を与える場合に生じるため、原因がシステム設計に関連するものです。
さらに、近年大きな注目を集めている「データ分布の変化」に着目し、共変量シフト、ラベルシフト、コンセプトドリフトの3つの種類のシフトを見ていきました。分布シフトは、機械学習の研究領域のひとつとして盛んに研究が進められていますが、研究者のコミュニティではまだ見解が分かれているところです。同じ現象が論文によっては別の名称で呼ばれていることもあります。また、依然として大半の研究は、分布がどのようにシフトするか事前に分かっている、またはソース分布とターゲット分布のいずれもデータにラベルが付けられているという前提で行われていますが、現実的には将来のデータがどうなるか分かりませんし、新しいデータのラベルを得るにはコストや時間がかかるか、あるいはそもそも実現が不可能なこともあります。
シフトを検出できるようにするには、デプロイしたシステムを監視する必要があります。監視は、機械学習に限らず実際に稼働しているあらゆるソフトウェアエンジニアリングシステムにとって重要な取り組みであり、機械学習の領域においてはDevOpsの世界からできる限り多くのことを見倣う必要があるでしょう。
監視には指標がすべてです。あらゆるソフトウェアシステムで監視すべき動作指標（レイテンシー、スループット、CPU使用率）や機械学習特有の指標などの監視する必要があるさまざまな指標について説明しました。また監視は、精度に関する指標、予測、特徴、生の入力などに適用できます。
なぜ監視が難しいかというと、指標を簡単に計算できたとしてもその指標の意味を理解することはそう簡単な話ではないからです。グラフを表示するダッシュボードは簡単に構築できますが、グラフの意味、そのグラフがドリフトの兆候を示しているかどうか、ドリフトが見られる場合にそれがベースのデータ分布の変化によるものかパイプラインのエラーによるものか、などを理解することははるかに難易度が高いものです。数値やグラフの意味を理解するには統計の知識が必要になるかもしれません。
実環境でのモデルのパフォーマンスの劣化を検出できることは最初の一歩です。次の一歩は環境の変化に対してシステムを適応させることです。これについては次章で説明します。
本章では、最もエキサイティングなトピックのひとつでありながら今だに十分な研究が行われていないトピックである、実稼働中のモデルを継続的に更新してデータ分布の変化に適応する方法について触れました。また、継続学習のインフラを最新化する過程で経験するであろう、手動でのゼロからの訓練から自動化されたステートレスな継続学習に至るまでの、4段階のステージについて説明しました。
それから、業態や規模を問わずあらゆる企業の機械学習エンジニアの頭痛の種である「どのくらいの頻度でモデルを更新すべきか」という疑問に対して、モデルに対するデータの鮮度の価値や、モデルイテレーションとデータイテレーションとの間にあるトレードオフを考慮することの重要性を説明しました。
7章で触れたオンライン予測と同様に、継続学習には成熟したストリーミングインフラを必要とします。継続学習の訓練の部分はバッチ処理で行えますが、オンライン評価の部分はストリーミングが必須です。ストリーミングは難易度が高くコストがかかるのではないかと多くのエンジニアが危惧しています。3年前はそうでしたが、その頃と比べると今ではストリーミング技術が著しく成熟しています。さまざまな企業が、Spark Streaming、Snowflake Streaming、Materialize、Decodable、Vectorizeなどのような、ストリーミングへの移行を容易に実現するソリューションを次々に提供しています。
継続学習は機械学習に特有の問題ですが、インフラのソリューションを必要とする面が大きく、イテレーションサイクルを高速化し、新たなモデルの更新時の失敗を迅速に検出するには、適切な方法でインフラを構築しなければなりません。これにはデータサイエンスチームと機械学習チーム、そしてプラットフォームチームが手を取り合う必要があります。次章では機械学習のインフラについて説明します。
ここまでの内容にお付き合い下さった方は、機械学習モデルを実現場に導入することはインフラの課題であるとご理解頂けていることでしょう。データサイエンティストが機械学習モデルを開発・デプロイできるようにするには、ツールやインフラを正しく整備することが極めて重要です。
本章では、機械学習システムに必要となるインフラのさまざまなレイヤーについて説明しました。まず初めに、ストレージ層とコンピューティング層に触れました。これらの層では機械学習プロジェクトのようにデータとコンピューティングリソースを膨大に必要とするエンジニアリングプロジェクトに不可欠なリソースを提供します。ストレージ層とコンピューティング層はコモディティ化が進んでいるため、ほとんどの企業では自社でデータセンターを構築するのではなく、その代わりに使用するストレージ量と計算量に即した金額をクラウドサービスに支払っています。ただし、クラウドプロバイダーのおかげで企業が簡単に使い始められるようになる一方で、企業の成長に伴いそのコストは法外なものになることから、クラウドからプライベートデータセンターへの回帰を検討する大企業の数が日々増加しています。
続けて、データサイエンティストがコードを書き本番環境とやり取りをする場所である開発環境について説明しました。開発環境はエンジニアが最も多くの時間を費やす場所であるため、開発環境を改善することは生産性の向上につながります。開発環境を改善するために企業ができることの第一歩は、同じチームで作業するデータサイエンティストと機械学習エンジニアの開発環境を標準化することです。本章では、標準化が推奨される理由とその方法について説明しました。
それから、近年データサイエンティストとの関連性が盛んに議論されているインフラのテーマであるリソース管理について説明しました。リソース管理はデータサイエンスのワークフローにおいて重要なものですが、問題はデータサイエンティストがそれを期待しているかどうかです。本節ではcronからスケジューラー、オーケストレーターまでのリソース管理ツールの進化をなぞってきました。また、機械学習ワークフローと他のソフトウェアエンジニアリングワークフローとの違いや、独自のワークフロー管理ツールが必要となる理由についても説明し、Airflow、Argo、Metaflowなどのさまざまなワークフロー管理ツールを比較しました。
機械学習プラットフォームチームは近年機械学習の採用が進むにつれて新たに誕生したチームであると言えます。まだ登場して間もない概念であるため、何をもって機械学習プラットフォームを構成するのかについては依然として見解が分かれるところです。そこで、大半の機械学習プラットフォームに不可欠なデプロイ、モデルストア、特徴ストアの3つのツールセットに焦点を当てることにしました。機械学習プラットフォームの監視については8章ですでに説明しましたので本章では割愛しています。
インフラに取り組む際には、エンジニアリングマネージャーやCTOは必ず「構築するか購入するか」という問題に頭を悩ませることになります。このような難しい判断が下せるだけの十分なコンテキストを皆さんや皆さんのチームに提供できていることを願いながら、いくつかの考慮すべきポイントを本章の末尾で説明しました。
機械学習ソリューションは技術的な性質を持つものであるにもかかわらず、機械学習システムの設計を技術的な領域のみに限定することはできません。なぜなら機械学習システムは人が開発し、人が使用し、社会にその足跡を残すものでもあるからです。本章では、直近の8つの章で触れた技術的なテーマから離れて機械学習の人間的な側面に焦点を当てました。
まず初めに、確率論的であること、ほぼ正しいこと、および高レイテンシーであることという機械学習システムの性質が、さまざまな形でユーザー体験に影響を及ぼすという点にフォーカスしました。確率論的な性質は、ユーザー体験から一貫性を失わせることがあり「おい、選択肢がさっきまでここにあったのに、いったいどこにいったんだ！」と言ったような苛立ちの原因になります。機械学習システムの ほぼ正しい という性質は、ユーザーが容易に予測を正しく変更できなければ、機械学習システムを使い物にならなくしてしまうかもしれません。これに対処するには、少なくともどれかひとつが正解であると期待して、同じ入力に対して「最も正しい」と思われる予測を複数表示させるという方法があります。
機械学習システムを構築するにはさまざまなスキルセットを必要とするため、組織にとっては必要なスキルをどのように分散させるかが悩みどころです。異なるスキルを持つチームを複数関与させる方法と、同じチーム（データサイエンティストなど）がすべてのスキルを持つ方法、この両者の長所と短所を考えます。前者の短所は、コミュニケーションの負担が大きくなることで、後者の短所は、一貫してエンド・ツー・エンドに機械学習システムを構築できるデータサイエンティストを採用することが難しいことです。もしそのような人材を採用できたとしても、進んでやりたがらないかもしれません。しかし、必要なツールやインフラを十分に提供すれば後者の方法も実現できる余地があります。これについては10章で扱いました。
おそらく本書の最も重要なトピックである、 責任あるAI で本章を締めくくりました。責任あるAIは、もはや単なる抽象的概念ではなく、今日の機械学習産業において必須の活動であり、早急に取り組むべきものです。あなたが倫理原則をモデルや組織の活動の中に取り入れると、プロフェッショナルとして、そして最先端のデータサイエンティストや機械学習エンジニアとして差別化を図ることになるだけでなく、組織が顧客やユーザーからの信頼を得ることにもつながります。また、市場では顧客やユーザーが責任あるAIのプロダクトやサービスの必要性を求める風潮がますます高まっているため、組織が市場での競争力を獲得するのにも役に立ちます。
重要なことは、責任あるAIを、組織のコンプライアンス要件を満たすために行う単なるチェックボックスにチェックをする作業のように扱わないことです。本章の中で提案したフレームワークが組織のコンプライアンス要件を満たす上で役に立つことは事実ですが、そのプロダクトやサービスを構築すべきかという、そもそものクリティカルシンキングの代わりにはならないでしょう。