数ヶ月前、私はデータ分析のバックグラウンドからデータエンジニアリングへの移行という旅に挑戦しようとしました。これまでに、実際に役立つことを教えてくれたインパクトのある現実世界のプロジェクトを合計2つ構築しました。Git Hub リポジトリを抽出して SQLite データベースにロードする Git Hub ET L パイプラインを構築しました — これは Git Hub Actions を使用してスケジュールで実行されていました。また、RSS フィードから記事を抽出して Kestra データベースに保存する RSS パイプラインも構築しました — Kestra によってオーケストレーションされ、毎時スケジュールで実行されます。ET L をある程度理解した今、新しいことに挑戦したくなりました。過去に学んだことをすべて実践し続けながら、新しいものを構築したいと思いました。私は常に機械学習の分野に魅了されていましたが、複雑な数学があると思っていたため、踏み出す勇気がありませんでした。もうそうではありません。最近、Northline Mobile という架空の通信会社の顧客離脱予測モデルを構築しました（追記：現実世界のシナリオで最もよく理解できるので、架空の会社を使用しています）。7043人の顧客データを提供し、1年契約か月額プランに加入したかどうか、顧客の長さ、月額料金、アドオンなどを伝えました。さらに、最終的に Northline Mobile を離れた人を伝えました。モデルがまだ見たことのない顧客でクロスバリデーションを行いました。81%の精度を達成しました。これにより、モデルの構築に何が関わるかをすべて学びました。当然ながら、私は直感的なドラッグアンドドロップインターフェースを好むため、複雑なコードをすべて理解したわけではありません。しかし、モデル構築の重要な構成要素は理解しました。簡略化されたアーキテクチャで以下にさらに説明します。ですから、このモデルの構築は機械学習の観点から勝利のように感じました。私のモデルは機能しました。しかし、まだ一つの問題がありました。それはまだ本当に有用ではなかったということです。予測が必要な Northline の従業員が私のところに来たと仮定すると、Jupyter を開き、正しいノートブックを読み込み、正しい順序でセルを実行し、predict_churn() を手動で呼び出す必要があります。はい、モデルは存在しますが、使い方を知っているのは私だけでした。Northline の他の誰も、顧客の情報をモデルに送信して予測を取得することはできず、他のアプリケーションと通信することもできませんでした。この記事でこれを取り上げます。最近、モデルを持つこととサービスを持つことの違いがあることを学びました。モデルがノートブックの中にあるだけなら、それを構築した人だけが使用できます。しかし、それをサービスにすることで、他のチーム、アプリ、ダッシュボード、システムなど、予測がどのように行われるかを知る必要や関心がないすべての人が使用できるようになります。機械学習モデルの構築が最も簡単な部分であることがわかりましたが、それを有用にすることは探求する価値のあるもう一つの重要な要素です。APIの前に「完了」とはどういう意味だったかモデルの構築はおおよそ次のようなものでした：だいたいそれだけです。あまり派手なものはありません。それが終わる頃には、訓練されたチャーン分類器、生データをクリーンアップしてエンコードする前処理パイプライン、そして私が満足できる評価数値（これらの数値については後述しますが、完璧ではありませんし、完璧だと偽るつもりもありません）がありました。しかし、前述の通りです。Northline のリテンションチームがダッシュボードを構築し、リスクのある顧客を自動的にフラグ付けしたいと仮定します。彼らのダッシュボードは私の Jupyter ノートブックを開いてセルを実行することは合理的にはできません。全く別のものが必要です。次のようなものです：これがこの記事が取り上げるシフトです。ただし、簡単な免責事項があります：これは Fast API のチュートリアルではありません。Fast API は単に私がモデルを...として公開するために使用したツールです