web-dev-qa-db-ja.com

Pythonでオブジェクト指向プログラミングを使用して機械学習プロジェクトを構築するにはどうすればよいですか?

Python(または他の言語)を使用する場合、静的学者と機械学習科学者は通常、ML /データサイエンスプロジェクトのOOPSに従わないことを観察しました。

ほとんどの場合、本番用のMLコードを開発する際に、oopsでのソフトウェアエンジニアリングのベストプラクティスを理解していないことが原因であるはずです。彼らは主にコンピュータサイエンスよりも数学と統計学の教育のバックグラウンドから来ているからです。

MLの科学者がアドホックなプロトタイプコードを開発し、別のソフトウェアチームがそれを本番環境に対応させる時代は、業界で終わりました。

enter image description here

質問

  1. MLプロジェクトでOOPを使用してコードを構造化するにはどうすればよいですか?
  2. データクリーニング、機能変換、グリッド検索、モデル検証などのすべての主要なタスク(上の写真から)を個別のクラスにする必要がありますか? MLに推奨されるコード設計手法は何ですか?
  3. 参照用に適切に構造化されたコードを含む適切なgithubリンク(適切に記述されたkaggleソリューションである可能性があります)
  4. データクレンジングのようなすべてのクラスに、fit()transform()のようなすべてのプロセスに対してfit_transform()remove_missing()outlier_removal()関数が必要です。 ?これが行われると、なぜscikit-learn BaseEstimatorが通常継承されるのですか?
  5. 本番環境のMLプロジェクトの一般的な構成ファイルの構造はどうあるべきですか?
17
GeorgeOfTheRF

MLの特別な点の1つは正しいです。データサイエンティストは一般的に賢い人なので、コードでアイデアを提示することに問題はありません。問題は、ソフトウェア開発の職人技が不足しているため、ファイアアンドフォーゲットコードを作成する傾向があるということですしかし、理想的にはそうではないはずです

コードを書くとき、コードの目的に違いはありません。1MLは他のドメインと同じように別のドメインであり、クリーンなコード原則に従う必要があります。

最も重要な側面は常に [〜#〜] solid [〜#〜]である必要があります。保守性、可読性、柔軟性、テスト性、信頼性など、多くの重要な側面が直接続きます。この機能の組み合わせに追加できるのは、変更のリスクです。コードの一部が純粋なMLであるか、銀行のビジネスロジックであるか、補聴器の聴覚アルゴリズムであるかは関係ありません。すべて同じです-実装は他の開発者によって読み取られ、修正するバグが含まれ、テストされ(うまくいけば)、場合によってはリファクタリングおよび拡張されます。

あなたの質問のいくつかに対処しながら、これをより詳細に説明しようと思います:

1,2)OOP自体が目標であると考えるべきではありません。クラスとしてモデル化できる概念があり、これにより他の開発者が簡単に使用できるようになる場合は、 読み取り可能拡張しやすいテストしやすいバグを回避しやすいそしてもちろん-作りますただし、必要な場合を除いて、 [〜#〜] bduf [〜#〜] アンチパターンに従うべきではありません。無料の関数から始めて、必要に応じてより優れたインターフェイスに進化させてください。

4)このような複雑な継承階層は、通常、実装を拡張できるようにするために作成されます( [〜#〜] solid [〜#〜] の「O」を参照)。この場合、ライブラリユーザーはBaseEstimatorを継承でき、オーバーライドできるメソッドと、これがscikitの既存の構造にどのように適合するかを簡単に確認できます。

5)コードの場合とほぼ同じ原則ですが、これらの構成ファイルを作成/編集する人を念頭に置いています。彼らにとって最も簡単なフォーマットは何でしょうか?製品を使い始めたばかりの初心者でも、パラメータ名が何を意味するのかがわかるように、パラメータ名を選択する方法は?

これらすべてをguessingと組み合わせる必要があります。このコードは、将来変更/拡張される可能性がどの程度ありますか?何かを石で書く必要があると確信している場合は、すべての側面についてあまり心配する必要はなく(たとえば、読みやすさだけに焦点を当てる)、実装のより重要な部分に努力を向けてください。

要約すると:あなたが作成したものと相互作用する人々について考えてください将来。製品/設定ファイル/ユーザーインターフェースの場合、常に「ユーザーファースト」である必要があります。コードの場合は、コードを修正/拡張/理解したいと思う将来の開発者の立場になってみてください。


1 もちろん、正式な規制のために正式に正しいことを証明したり、広範囲に文書化する必要があるコードなど、いくつかの特殊なケースがあり、この主な目標はいくつかの特定の構成/実践を課します。

4
BartoszKP