年だと聞けば、驚く方もいるでしょう(時間が経つのは早いものです!)。よって実現しています)。驚くべきことに、このスタイルで書かれたコードは、別のフレームワークであってもとてもよく似たものになります。違いを見つけるのが難しいほどです!このスタイルは非常に柔軟ですが、ユーザビリティやメンテナンスの面で、明らかではない代償も発生します。詳細は、もう少し後で説明します。つの方法でトレーニングを行うことができます。ループ(独自の勾配クリッピングを行うコードを記述したい場合など)や損失関数が必要な場合は、次のような方法も簡単に利用できます。両方のアプローチが利用できることは重要です。コストを減らすことにもつながります。基本的に、複雑にすることで有用になる場合は、複雑にすることができます。それが不要な場合は、ビルトインの手法を使い、リサーチやプロジェクトに時間をかけることができます。スタイルと命令型スタイルの概要はお分かりいただけたかと思います。次は、トレードオフに注目してみましょう。モデルはグラフ的なデータ構造になります。この場合、モデルのインスペクションやサマライズが可能です。利用したり、レイヤー、重み、形状の説明を確認することもできます。同様に、レイヤーを組み合わせる際、ライブラリの設計者はさまざまなレイヤー互換性チェックを実行できます(モデルの構築中と実行前)。コンパイラによる型チェックと同じで、デベロッパーのエラーを大幅に削減してくれます。デバッグの大半は、モデルの実行フェーズではなく定義フェーズで行います。コンパイルできるモデルは、実行できることが保証されます。これにより、反復作業を高速に行えるようになり、デバッグも簡単になります。提供するため、再利用や共有が容易になります。次のようにすると、転移学習で中間レイヤーの活性化関数にアクセスし、既存のモデルから新しいモデルを構築することができます。model.predict(image)シンボリックなモデルは、モデルを自然にコピーまたはクローンできるようにしているデータ構造によって定義されます。提供されており、データ構造のみから同じモデルを再作成することができます(モデルの定義やトレーニングに使ったオリジナルのコードにアクセスする必要はありません)。ネットワークのメンタルモデルに一致するべきですが、プログラマーのメンタルモデルに一致することも同じくらい重要です。「シンボリックなテンソル」(まだ何の値も保持していないテンソル)を操作してグラフを構築します。命令的な「感覚」で使うことができます。シンボリックにモデルを定義していることを多くのデベロッパーに気づかれないように設計されています。レイヤーの有向非巡回グラフで表されるモデルを開発するのに最も適しています。これは、実際のユースケースの大半に対応できますが、一部の特殊なケースでは、このような整然とした抽象化を行うことはできません。ような動的ネットワークや、再帰的なネットワークなどがこれに該当します。Subclassing)も提供しているのは、そのためです。一般的なレイヤー、イニシャライザ、オプティマイザはすべて使うことができます。つのスタイルは完全に相互利用できるので、組み合わせて使うことも可能です(たとえば、あるタイプのモデルに別のタイプのモデルをネストさせることができます)。サブクラス化したモデル内のレイヤーでシンボリックなモデルを使うことも、その逆も可能です。)を簡単に独自の実装と取り替えることができます。ラーニングの仕組みを深く追求する上で優れた方法でもあります。この点は、特に研究者には便利です。使ってモデルのフォワードパス内の任意の制御フローを簡単に指定することもできます。使うと、最大限の柔軟性を実現できますが、代償が発生します。私は、このスタイルを使ってコードを書くことも好きですが、ここでは、制限事項についてじっくりとお伝えしたいと思います(トレードオフについて認識しておくのはよいことです)。使う場合、モデルがクラスメソッドの本体で定義されることです。モデルは透過的なデータ構造ではなくなり、不透明なバイトコードの一部になります。このスタイルを使うと、ユーザビリティと再利用性を失う代わりに、柔軟性を得ることになります。デバッグは、モデルを定義するときではなく、実行時に行うことになります。入力やレイヤー内の互換性については、ほとんどチェックが行われません。そのため、このスタイルを使う場合、デバッグの負荷の大半がフレームワークからデベロッパーに移ることになります。命令型モデルは、再利用がはるかに難しくなります。使って中間レイヤーや活性化関数にアクセスすることはできません。活性化関数を抽出したい場合、新しく呼び出せる(転送できる)メソッドを持つ新しいクラスを書くことになります。最初は書くのが楽しく、簡単にできるかもしれませんが、標準化されていない技術的負債が生じるかもしれません。命令型モデルは、インスペクション、コピー、クローンも難しくなります。サブクラス化されたモデルでは動作しません。レイヤーのリストを出力するだけです(どのように接続されているかについては、アクセスできないため、何の情報も提供されません)。システムの技術的負債モデル構築は、実際の機械学習に伴う作業のごく一部に過ぎないと覚えておくことが大事です。この点について、私が特に気に入っている図を紹介しましょう。ループなどを指定するコードにあたる部分)は、中ほどにある小さなボックスでしかありません。コードでできている部分はほんのわずかしかない。Systems(機械学習システムの隠れた技術的負債)から実行可能。シンボリックに定義したモデルは、再利用性、デバッグ、テストの面でメリットがあります。使っていれば、すぐにコードをデバッグすることができます。サブクラス化したモデルを使っている場合は、(フレームワークに関係なく)時間がかかります(バグはわかりにくくなるうえ、さまざまな種類のものが考えられます)。以上で説明した両方のスタイルをすぐに利用できます。そのため、プロジェクトに適したレベルの抽象化(と複雑さ)を選べます。ループを使いましょう。ほとんどの問題に対しては、これが適切な対処方法です。使うのがよいでしょう。この概要を役立てていただけるとありがたく思います。スタックの詳細については、こちらの記事をご覧ください。関係について詳しく知りたい方は、こちらをご覧ください。ForumGooglePrivacyTerms。