Seven AI Best Practices for Closing the Gap Between Dev and Machine Learning - The Databricks Blogの翻訳です。
本書は抄訳であり内容の正確性を保証するものではありません。正確な内容に関しては原文を参照ください。
「...機械学習を会社のアプリケーション開発に組み込むことは難しい...」
Marc Andreesenがソフトウェアが世界に浸透していることを歓迎して以来、約10年が経過し、それに合わせて多くの企業はアジャイルなソフトウェア開発を取り入れ、それを自身の企業のコアの競合優位性としています。「遅い」企業がどうにかアジャイル開発チームをうまく導入し、これらのチームは、オペレーショナルデータストア、レガシーシステム、APIによる「as-a-service」やイベントベースのインタフェースによるサードパーティのデータプロダクトから自身を分離しました。これらのチームはビジネス要件と成果をサポートするソリューションのデリバリーと、彼らのデータの課題に打ち勝つことによる成果にフォーカスしています。
もちろん、少数のものだけが世界のテクノロジーにとどまり続けます。クラウドコンピューティング、大ボリューム、新たなタイプのデータ、10年以上の研究とビジネスの間の密接なコラボレーションのインパクトによって、新たな波を作り出しました。この新たな波をAIの波と呼びましょう。
人工知能(AI)は単に人々の働き方を自動化する以上の可能性を提供します。より効果的、タイムリーな意思決定のためのアクションのために、予測、分類を自動化するためにデータを活用し、レスポンシブな顧客体験のように皆様のビジネスのあり方を一変させます。機械学習(ML)は要件に応えるためにオフザシェルフのモデルのトレーニングを推進し、コーディングだけでこれに対応するには複雑すぎることを証明しました。
しかし、悩ましい点があります：MLを企業のアプリケーション開発に組み込むことが困難であるということです。現在のMLは、従来型のコーディングよりも遥かに複雑なアクテビティとなっています。Databricksの共同創始者であり、チーフテクノロジストであるMatei Zahariaはこの理由を3つ挙げています。
- 最初に、MLに依存するソフトウェアコンポーネントの機能は、現在の多くのソフトウェア開発に当てはまるように単にコーディングされたロジックを用いて構築されるものではありません。これは、ロジック、トレーニングデータ、チューニングの組み合わせに依存します。
- 2つ目として、このフォーカスは、いくつか適切な機能的仕様を表現することではなく、出力の精度を最適化し、デプロイした後も精度を維持することとなります。
- そして最後に、MLエンジニアが頼りとするフレームワーク、モデルアーキテクチャ、ライブラリは通常、急速に進化し変化し続けます。
これらの3つのポイントのそれぞれが、それぞれの課題をもたらしますが、本書ではエンジニアリングプロセス自身にデータが必要であるという事実を強調する最初のポイントにフォーカスします。これまでは、アプリケーション開発チームは、テストや運用においてどのようにデータに接続するのかに注意を払ってきており、上述したようにAPIを構築することでこの問題を解決しました。しかし、これら同様のAPIは開発時にチームがデータを活用する役に立ちません。だとしたら、どのようにして皆様のプロジェクトは、少量のコードと大量のトレーニングデータを皆様の開発サイクルに組み込むのでしょうか？
答えは、データ管理組織とアプリケーション開発チームの密接なコラボレーションとなります。現在、このことを反映するような多くの議論が多く行なわれており、おそらくデータメッシュ(Dehghani 2019)のアイデアに特に集中していると言えます。数十年に渡りアプリケーションとデータの世界を行ったり来たりした私の経験から、皆様がこの分断を超えてチームを割り当てる際に検討すべき7つのプラクティスを位置付けました。
-
構築すべき最も重要なデータ製品を特定するためにデザインファーストアプローチを活用します
デジタルトランスフォーメーションの成功は通常、カスタマーエンゲージメントの変革によってもたらされます。デザインファースト、お客様の目を通じて世界を見ることで、アプリケーション開発チームに何かしらの情報を提供します。例えば、Clayton Christensenらによって導入された「Jobs to be Done」のようなフレームワークは、お客様が最終的には何を成し遂げようとしているのかに対するデザインにフォーカスしています。このようなフレームワークは、お客様のゴールを達成するために提供すべきインパクトに基づいて、開発チームが機能を特定、優先度付け、構築する役に立ちます。
同様に、デザインファーストアプローチは、どのデータ成果物を構築すべきかの特定にも役立ち、AIがお客様に最大のインパクトをどのように与えるのかに基づいて、企業が挑戦することを可能にします。 「お客様のすべきことをサポートするために、どのような意思決定が必要なのか？」 のような質問に答えることで、このような意思決定をサポートするために必要となるデータと予測、さらに重要なこととして、分類や回帰MLモデルのように必要とされるデータ成果物の特定に役立ちます。
データサイエンティスト、データアーキテクト、通常のビジネスステークホルダー、アプリケーションアーキテクトが参加する同じデザインファーストのエクササイズからアプリケーション機能とデータ成果物のバックログの両方を作成することができます。エクササイズの後は、機能とデータ成果物のバックログ間の依存関係を効果的に管理できるように、より広い範囲のペルソナが継続的な方法でコラボレーションしていく必要があります。これは、次のプラクティスに繋がっていきます。
-
データとアプリケーションチームを効果的に組織します
データチームとアプリケーションチームの密接なコラボレーションによって、データサイエンスのバックログ(研究のゴール)とデータサイエンティストによって実行されるべき関連MLモデル開発に支持を与えることができます。ゴールを設定したら、独立して作業を進めることに抵抗することが重要になります。Caffoらによる書籍Executive Data Scienceでは、コラボレーションにおける一般的な難しさに対応するために導入されるチーム構造を説明する2つの一般的な組織的アプローチ、埋め込み型と専任型がハイライトされています。専任型モデルでは、データサイエンティストのようなロールはビジネス領域のアプリケーションチーム(機能横断チーム)の永久的なメンバーとなります。一方、埋め込みモデルでは、これらのデータロールは集中化されたデータ部門のメンバーとなり、ビジネスアプリケーション領域に埋め込まれます。
図1 統合された組織におけるCOE複数のラインオブビジネスを持つ大規模な組織においては、多くのアジャイル開発ストリームがMLモデルの開発を必要とする可能性があるので、この開発を専任のセンターオブエクセレンス(CoE)に分離することは魅力的な選択肢となります。Shellのユースケースにおいては、どのようにCOEがAIの導入を成功させ、COEが埋め込みモデルとうまく組み合わせられたのか(上の図1を参照ください)を説明しています。このケースでは、COEのメンバーはAIバックログのデリバリーのタスクを負っています。しかし、緊急事態、理解とコラボレーションをサポートするために、何人かのチームメンバーはアプリケーション開発チームの中で直接作業するようにアサインされています。結局のところは、ベストなオペレーティングモデルは、企業の成熟度に依存し、アーリーアダプターは「ハブ」でより多くのスキルを維持し、成熟したアダプターは「スポーク」でより多くのスキルを活用します。
-
データ成果物のオーナーシップと可視性を分散されたビジネスフォーカスチームに移譲し足元のデータサイエンスをサポートします
検討すべき重要な組織的な別の観点は、データのオーナーシップです。データプライバシー、同意、使用に関するリスクが存在する場合、データの特性と適切性を最も理解しているビジネス領域で、オーナーシップの説明責任とこれらのリスクの管理を受け入れることが理にかなっています。AIは、バイアス、説明可能性、倫理的意思決定の保証など新たなデータリスクをもたらします。これは、コントロールの考え方とオーナーシップが確立されたサイロ化されたデータ管理ソリューション構築のプレッシャーとなり、コラボレーションを阻害するサイロにつながります。これらの障壁は必然的に企業に低品質のデータをもたらし、例えば、重複し、不完全、一貫性のない属性を用いて開発されたサイロ化されたデータセットを通じた顧客データの精度への影響などを引き起こします。そして、データ品質の低下は、そのデータでトレーニングされるモデルの中で永続化されます。
図2: データメッシュにおけるデータ成果物のローカルのオーナーシップデータメッシュのコンセプトは、サイロ化のアプローチを導入してしまうという落とし穴を回避しつつも、データ成果物のオーナーシップを維持するためにローカルのビジネス領域に対するアプローチとして人気を得ています。データメッシュにおいては、図2に示すようにデータセットをローカルに所有することができます。そして、コントロールされた方法と、データ成果物のオーナーによって決定されたリスクパラメーターを用いて、より広い範囲の組織でデータを共有するためのメカニズムが動作します。レイクハウスは、データメッシュアプローチを最初からサポートしているアーキテクチャを提供します。ここでは、組織のデータがモデル、データセット、BIダッシュボード、パイプラインのような複数のタイプのデータ成果物を統合された一つのプラットフォーム上でサポートし、ビジネスを横断するローカルビジネスの独立性を実現します。レイクハウスを用いることで、チームは自身がコントロールできるストレージと計算資源を用いて、自身の整理されたデータセットを作成します。これらの成果物はカタログに登録され、容易に検索してセルフサービスで利用できるようになりますが、広範な組織において許可されたグループのみがアクセスできるように適切なセキュリティコントロールを適用します。
-
一貫性のあるDataOpsを用いてアイデアからソリューションに至る時間を最小化します
バックログが定義され、チームを構成したら、バックログに表示されているモデルのようなデータ成果物をどのように開発するのか...そしてどのようにそれらを迅速に構築できるのかに対応しなくてはなりません。データ取り込みとデータ準備はモデル開発で最大の労力を必要とし、効果的なDataOpsはそれらを最小化する鍵となります。例えば、Starbucksは、規模、エンジニアリングの成熟度に関係なく、いかなるチームが、すでに企業内に配備されているベストプラクティスに流れ込むパイプラインを構築することにフォーカスしたBrewkitという分析フレームワークをAzure Databricks上で構築しました。このフレームワークのゴールは、全体的なデータ処理の効率を改善するというものでした。彼らは50-100倍の速度でデータ処理を行う1000以上のデータパイプラインを構築しました。このフレームワークの鍵となる要素として、特定のデータ問題を解決するためにローカルチームがスタート地点として使用できる一連のテンプレートがあります。テンプレートはストレージとしてDelta Lakeをベースとしているので、このテンプレートを用いて構築したソリューションでは、パイプラインの信頼性や性能といった、クラウドストレージのデータを操作する際の課題を解決する必要がありません。
効果的なDataOpsには別の重要な側面があります。名前が示しているようにDataOpsは、自動化に非常に重きを置くことで成功したDevOpsと密接な関係にあります。以前のブログ記事Productionize and Automate your Data Platform at Scaleでは、この観点での素晴らしいガイドを提供しています。
生のデータを取得し、モデル開発に適したフォーマットに変換するための全体的な変換のチェーンが必要になることは一般的なことです。Starbucksに加え、多くのお客様がデータパイプライン構築を加速するために同様のフレームワークを構築しているのを目撃しています。このことを踏まえ、我々は信頼性のあるプロダクションのデータパイプラインの構築をシンプルなものにし、開発やオペレーションに関する問題の根源を解決するためにDelta Live Tablesを発表しました。
-
コーディングと比較してモデル開発のスプリントに対して現実的になりましょう
アプリケーション開発の世界の全てのプラクティスが容易にデータソリューションの構築に転用できるというのは魅力的なアイデアです。しかし、Matei Zahariaが指摘するように、従来型のコーディングとモデル開発のゴールは異なるものです。コーディングのゴールは、明確に定義された機能仕様を充足するために、既知の機能のいくつかを実装することです。一方、モデル開発のゴールは、予測や分類のようなモデルの出力精度を最適化し、精度を維持し続けるというものです。アプリケーションのコーディングにおいて、隔週のスプリントを行なっている場合、最低限の製品を提供し、製品に対してインクリメンタルに、スプリントごとに機能を追加するというゴールを達成するために、機能をより小さいユニットにブレークダウンするということが起こり得ます。しかし、モデル開発において
ブレークダウンとは何を意味するのでしょうか？究極的には、妥協点として最適化されていない、すなわち精度の低いモデルが要求されるかもしれません。ここでの最低限のモデルは、最適化されていないモデル、最適化されていないモデルに至る前に精度が低すぎると、ソリューションに十分な価値を提供しませんし、場合によってはお客様が激怒することでしょう。このため、ここで理解すべきことは、いくつかのモデル開発は、アプリケーション開発に関連づけられたスプリントにきちんとフィットしないであろうということです。だとしたら、この現実に対する理解は何を意味するのでしょうか？コーディングの時間通りのスピードと、モデル開発の間にはインピーダンスのミスマッチがあるかもしれませんが、許容できる精度で最初のバージョンのモデルが到着するまでの時間を短縮するか、許容できる精度が達成できず救済手段が必要かどうかを判断することで、少なくとも可能な限りMLライフサイクルとデータサイエンティスト、MLエンジニアを効果的、効率的にできるということです。どのように実現できるのかを次で見ていきましょう。
-
データサイエンティストを活気付ける一貫性のあるMLOpsと自動化を導入します
プラクティス4で説明した効率的なDataOpsは自身の最適化をモデル構築の前提条件にも活用することができるので、MLモデルの開発、必要となるデータ収集、データ準備、データ探索に対して多大なるメリットをもたらします。MLを支えるためのレイクハウスアプローチの役割を説明するブログ記事データを中心とした機械学習プラットフォームに対するニーズで、この点をさらに議論しています。さらに、ML開発におけるユニークなプラクティス、ツールにフォーカスした固有のステップが存在します。最後に、モデルを開発したら、DevOpsにインスパイアされたベストプラクティスを用いてモデルをデプロイする必要があります。これら全ての可動品は、図3のDatabricksプラットフォームで示されているように、MLモデルライフサイクルを通じてのモデル開発、デプロイ、モニタリングの全てのステップの最適化にフォーカスしているMLOpsでキャプチャーされます。
図3: DatabricksによるMLOpsのコンポーネント新機能のデリバリーを加速するためにCI/CDパイプラインの自動化と、一貫性のある開発メソッド、フレームワークを用いることは、アプリケーション開発の世界では一般的なものとなっています。過去2、3年で、より効果的なMLOpsをサポートするために、同様のプラクティスがデータ部門でも活用され始めています。この成熟度の成長に寄与している人気のあるコンポーネントが、MLライフサイクルを管理するためのオープンソースフレームワークであり、Databricksではマネージドサービスとして提供しているMLflowです。H&MのようなDatabricksのお客様は、獅子のモデルオペレーションの中心にMLflowを位置付けることで、より多くのモデルを迅速に構築する自身の組織のMLを産業化しました。自動化はトラッキングやモデルパイプラインの先まで適用されます。AutoMLは、特定のユースケースにおけるベストモデルの開発に関わる膨大な量の実験を自動化することで、データサイエンティストの生産性を劇的に改善します。
-
大規模AIを真に成功させるためにはデータチームだけではなく、アプリケーション開発部門も変化する必要があります
これら7つのポイントに関する変化の多くは、明らかにデータ部門にインパクトを与えるものです。これは、アプリケーション開発チームは変化する必要がないと言っているのではありません。確かに、コラボレーションに関するすべての側面は両方のサイドのコミットメントに依存しています。しかし、レイクハウス、DataOps、MLOps、データとAIのプラクティスをサポートするツール、メソッドの急激に進化するエコシステムの出現により、データ部門の変更が必要であることを認識することは容易です。このような考えは急激な変化につながらないかもしれません。チームがどのように再配置され、これまでと異なるコラボレーションを行うのかを動機づけるには、教育と布教が重要な役割を果たします。組織全体の文化を浸透させるためには、データのリテラシーとスキルプログラムが必要となり、アプリケーション開発チームを含む企業の観衆それぞれのニーズに合わせて仕立てられる必要があります。
優れたデータリテラシーの布教と連携して、アプリケーション開発のプラクティスとツールを再検証する必要もあります。例えば、倫理的な問題は。機能に対するビルディングブロックとしてAPIを再利用するようなアプリケーションコーダーの一般的なプラクティスにインパクトを与えます。MLで実装される「融資する価値の評価」機能を考えてみます。APIの実動を提供するモデルのエンドポイントが、富裕層の個人とやりとりを行う銀行のデータでトレーニングされた場合、そのモデルが低所得層とやりとりを行う銀行で再利用されると重大なバイアスを持つことになるかもしれません。このケースでは、アプリケーション開発者やアーキテクトがAPIの向こうにあるモデルのトレーニングデータのリネージュやコンテキストを検証することを確実にするための事前定義済みのプロセスが必要となります。これにより、再利用する意思決定を行う前にいかなる問題も明らかにすることができ、この検討をサポートするために、検索ツールはAPIの文脈とデータリネージュに関する情報を提供すべきです。
まとめると、アプリケーション開発チームとデータチームがシームレスに協働したときのみ、AIが組織に浸透すると言えます。通常これら2つの世界はサイロ化されていますが、企業は効果的なコラボレーションのための条件を設定するためのパズルを組み合わせ始めています。ここで説明した7つのプラクティスは、Databricksのお客様がこの割り当てを達成するために導入したベストプラクティスと技術的選択肢をカバーしています。これらを適用し、ソフトウェアが浸透した我々の世界を、機械学習がソフトウェアに浸透する世界に変えることで、企業はAIの波に乗ることができます。
データ駆動組織を構築するためのベストプラクティスを説明するEnabling Data and AI at Scale strategy guideをチェックして、どのように皆様の企業がAIの波に乗れるのかを見出してください。また、Databricksが唯一のクラウドネイティブベンダーとして、クラウドデータベース管理システムとデータサイエンス、機械学習プラットフォームの両方のMQのリーダーとして選定されたガートナー MQ DBMS & DSML 2部門のリーダーもチェックしてみてください