PyTorchやTensorFlow throughなどのフレームワークTensorFlow Fold動的計算グラフをサポートし、データサイエンティストから注目を集めています。
ただし、動的計算グラフの理解に役立つリソースが不足しているようです。
動的計算グラフの利点には、入力データのさまざまな量に適応する機能が含まれているようです。トレーニング中の各入力セットインスタンスに応じて、レイヤー数、各レイヤーのニューロン数、活性化関数、およびその他のNNパラメーターが自動的に選択されるようです。これは正確な特性評価ですか？
静的モデルに対する動的モデルの利点は何ですか？それがDCGが注目を集めている理由ですか？要約すると、DCGとは何ですか、またDCGの長所と短所は何ですか？
回答:
2つの短い答え
理論的な観点からの短い答えは...
動的計算グラフは、操作間のデータフローの有向グラフとして表される可変システムです。矢印で接続されたテキストを含む図形として視覚化できます。これにより、頂点（図形）は、エッジ（矢印）に沿って流れるデータの操作を表します。
このようなグラフは、データフローの依存関係を定義しますが、必ずしも操作の適用の時間的順序を定義するわけではないことに注意してください。
アプリケーション開発の観点からの短い答えは...
Dynamic Computational Graphフレームワークは、柔軟でプログラム可能なランタイムインターフェイスを提供するライブラリ、インターフェイス、およびコンポーネントのシステムであり、有限ではあるが拡張可能な操作のセットを接続することにより、システムの構築と変更を容易にします。
PyTorchフレームワーク
PyTorchは、TorchフレームワークとPython言語およびデータ構造化の統合です。トーチは、Theano、TensorFlow、およびその他の動的な計算システム構築フレームワークと競合しています。
——— 理解への追加アプローチ ———
任意の離散テンソルの任意の計算構造
計算システムの構築に使用できるコンポーネントの1つは、相互接続してニューラルネットワークを作成するように設計された要素です。これらの可用性は、構築ディープラーニングとニューラルネットワークの逆伝播をサポートします。任意に定義された計算構造内の潜在的に多次元のデータを扱うコンポーネントのアセンブリを含む他のさまざまなシステムも構築できます。
データは、浮動小数点数、整数、文字列などのスカラー値、またはベクトル、行列、キューブ、ハイパーキューブなどのこれらの直交集合です。これらのデータ形式の一般化の操作は離散テンソルであり、テンソル操作の作業システムへのアセンブリから作成された構造はデータフローです。
動的計算の概念を理解するための参照点
動的計算グラフは、比較的新しい用語ですが、特に新しい概念ではありません。コンピューター科学者の間でのDCGへの関心は、データサイエンティストという用語ほど新しいものではありません。それにも関わらず、質問には、コードの例以外に利用可能な十分に記述されたリソースがほとんどないため、それらの出現と使用に関する全体的な概念を学習できることが正しく述べられています。
DCGを理解し始めるための参照の1つの可能なポイントは、オブジェクト指向設計の支持者によって普及した多くの設計パターンの1つであるコマンド設計パターンです。コマンドデザインパターンは、操作を計算ユニットと見なし、その詳細は、それらをトリガーするコマンドオブジェクトから隠されます。コマンドデザインパターンは、通訳者デザインパターンと組み合わせてよく使用されます。
DCGの場合、CompositeおよびFacadeの設計パターンも関与しており、システムを形成するためにパターンで一緒にアセンブルできる定義プラグアンドプレイの離散テンソル操作を容易にします。
システムを形成するデザインパターンのこの特定の組み合わせは、実際には、今日のほとんどのコンピューターの中心であるフォンノイマンアーキテクチャの出現につながった急進的なアイデアにほぼ似たソフトウェアの抽象化です。コンピューターの出現に対するフォンノイマンの貢献は、ブールロジック、算術演算、および分岐を含む任意のアルゴリズムをデータ（プログラム）として表現および格納できるようにするという考え方です。
DCGのもう1つの先駆者は式エンジンです。式エンジンは、算術エンジンのように単純なものから、Mathematicaなどのアプリケーションのように複雑なものまであります。ルールエンジンはDCGに少し似ていますが、ルールエンジンは宣言型であり、ルールエンジンのメタルールはこれらの宣言を操作する点が異なります。
プログラムを操作するプログラム
これらがDCGと共通しているのは、適用するデータと操作のフローを実行時に定義できることです。DCGと同様に、これらのソフトウェアライブラリとアプリケーションの一部には、機能の詳細に操作を適用できるようにするAPIまたはその他のメカニズムがあります。基本的に、プログラムが別のプログラムの操作を許可するという考え方です。
プリミティブレベルでこの原則を理解するためのもう1つの基準点は、一部のコンピューター言語で使用できるswitch-caseステートメントです。これは、プログラマーが本質的に「何をしなければならないのかわからないが、この変数の値はリアルタイム実行モデルに一連の可能性から何をすべきかを伝える」というソースコード構造です。
switch-caseステートメントは、計算の方向に関する決定を実行時まで延期するという考え方を拡張する抽象概念です。これは、現代のCPUの制御ユニット内で行われているもののソフトウェアバージョンであり、アルゴリズムの詳細を延期するという概念の拡張です。Cのファンクター（関数ポインター）の表、またはC ++、Java、Pythonのポリモーフィズムは、他のプリミティブな例です。
動的計算は、抽象化をさらに進めます。これらは、計算の仕様とそれらの間の関係のすべてではないにしても、ほとんどを実行時まで延期します。この包括的な一般化により、実行時の機能変更の可能性が広がります。
計算の有向グラフ表現
それが動的計算モデルです。次に、グラフ部分について説明します。
実行するまで実行する操作の選択を延期することを決定したら、操作、それらの依存関係、およびおそらくマッピングパラメーターを保持する構造が必要です。このような表現は、構文ツリー（ソースコードの階層を表すツリーなど）以上のものです。アセンブリ言語プログラムまたはマシンコードとは異なり、簡単かつ任意に変更可能でなければなりません。データフローグラフよりも多くの情報と、メモリマップよりもはるかに多くの情報を含める必要があります。計算構造を指定するデータ構造はどのように見える必要がありますか？
幸いなことに、任意の有限の有界アルゴリズムは、指定された操作間の依存関係の有向グラフとして表すことができます。このようなグラフでは、頂点（表示されるとさまざまな形状のノードとして表されることが多い）はデータに対して実行される操作を表し、エッジ（表示されるとしばしば矢印として表される）は何らかの操作（またはシステム入力）から生じる情報のデジタル表現です他の操作（またはシステム出力）に依存します。
有向グラフは、アルゴリズム（正確な一連の操作が指定されるという点）でも宣言（データを明示的に保存でき、ループ、ブランチ、関数、およびモジュールを定義およびネストできる）ではないことに注意してください。
これらのDynamic Computational Graphフレームワークとライブラリのほとんどは、コンポーネントが機械学習をサポートするコンポーネント入力で計算を実行できるようにします。有向グラフの頂点は、微分計算をサポートするニューラルネットまたはコンポーネントを構築するためのニューロンのシミュレーションです。これらのフレームワークは、より一般的な意味でディープラーニングに使用できる構造の可能性を示します。
コンピュータ履歴のコンテキストで
繰り返しになりますが、これまでに言及したものはコンピューターサイエンスにとって新しいものではありません。LISPでは、計算回路図を他のアルゴリズムで変更できます。そして、一般化された入力の次元と数は、多くの長年にわたるプラグアンドプレイのインターフェースとプロトコルに組み込まれています。学習のフレームワークのアイデアは、20世紀の同じ中期にもさかのぼります。
新しくて人気が高まっているのは、統合された機能と関連する用語の特定の組み合わせ、各機能の既存の用語の集合であり、ソフトウェア業界ですでに勉強し、働いている人が理解するための幅広い基盤につながります。
これらのフレームワークの多くは、変化する入力次元（次元の数とそれぞれの範囲）への適応性をサポートしています。
コンパイラの抽象シンボルツリーとの類似性
操作の入力と出力の依存関係グラフも抽象シンボルツリー（AST）内に表示されます。ASTは、ソースコード構造の解釈中に、より進歩的なコンパイラの一部が構築します。次に、ASTを使用して、ライブラリとリンクし、実行可能ファイルを形成するプロセスで、アセンブラー命令またはマシン命令を生成します。ASTは、データの構造、実行された操作、およびソースコードで指定された制御フローを表す有向グラフです。
データフローは単に操作間の依存関係のセットであり、ソースコードで指定されたアルゴリズムに正確に従うアセンブラーまたはマシンコードで実行命令を作成するために使用されるASTのASTに固有でなければなりません。
動的計算グラフフレームワークは、コンパイラのswitch-caseステートメントやASTモデルとは異なり、リアルタイムで操作、最適化、調整（プラスチック人工ネットの場合のように）、反転、テンソルによって変換、デシメーション、追加または削除のために変更できますエントロピー、一連のルールに従って突然変異、または派生形式に変換されます。ファイルまたはストリームとして保存し、それらから取得できます。
これは、LISPプログラマや、運用仕様をデータとして保存するというジョンフォンノイマンの推奨事項の性質を理解しているプログラマにとって簡単な概念です。この後の意味では、プログラムは、コンパイラーとオペレーティングシステムを介して、VLSIデジタル回路に実装された動的計算システムに指示するデータストリームです。
順応性のある次元と数値性の実現
問題は、「データセットが必要です-その中のすべてのインスタンスが同じ固定数の入力を持っている」というコメントではありません。その声明は正確な理解を促進しません。入力の適応性について本当のことを言うより明確な方法があります。
DCGとシステム全体のその他のコンポーネントとの間のインターフェイスを定義する必要がありますが、これらのインターフェイスには動的な次元または数値が組み込まれている場合があります。それは抽象化の問題です。
たとえば、離散テンソルオブジェクトタイプは特定のソフトウェアインターフェイスを表しますが、テンソルは動的な数学的概念であり、その周りで共通のインターフェイスを使用できます。離散テンソルはスカラー、ベクトル、行列、立方体、またはハイパーキューブであり、各次元の従属変数の範囲は可変です。
動的計算グラフで定義されたシステムのレイヤー内のノードの量は、特定のタイプの入力数の関数である可能性があり、それも実行時まで延期される計算である可能性があります。
フレームワークは、層構造（スイッチケースパラダイムの拡張）を選択するか、構造サイズと深さまたは活性化を定義するパラメーターを計算するようにプログラムできます。ただし、これらの高度な機能は、フレームワークを動的計算グラフフレームワークとして認定するものではありません。
動的計算グラフをサポートするためのフレームワークを修飾するものは何ですか？
Dynamic Computational Graphフレームワークとしての資格を得るには、フレームワークは、実行時のアルゴリズムの決定の延期をサポートするだけでよいので、実行時の計算依存性とデータフローに対する多数の操作への扉が開かれます。延期される操作の基本には、操作のシステムを表す有向グラフの仕様、操作、実行、および格納が含まれている必要があります。
アルゴリズムの仕様が実行時まで延期されず、特定のオペレーティングシステム向けに設計された実行可能ファイルにコンパイルされ、if-then-else、switch-case、polymorphism、ファンクタ、および可変長文字列、静的アルゴリズムと見なされます。
操作、それらの間の依存関係、データフロー、フロー内のデータの次元、および入力数と次元に対するシステムの適応性がすべて、高度な適応システムを作成する方法で実行時に可変である場合、アルゴリズムはこれらの方法で動的です。
繰り返しますが、LISPプログラムで動作するLISPプログラム、メタルール機能を備えたルールエンジン、式エンジン、個別のテンソルオブジェクトライブラリ、さらには比較的単純なコマンドデザインパターンはすべて、何らかの意味で動的であり、いくつかの特性を実行時まで遅らせます。DCGは柔軟で包括的な機能を備えており、任意の計算構造をサポートして、ディープラーニングの実験とシステム実装のための豊富な環境を作成します。
動的計算グラフを使用する場合
DCGの長所と短所は完全に問題固有です。上記のさまざまな動的プログラミングの概念や、関連する文献でそれらに密接に関連している可能性のある他の概念を調査すると、動的計算グラフが必要かどうかが明らかになります。
一般に、DCGパラダイムに適切にマッピングされる深層学習システム、数学的操作システム、適応システム、またはその他の柔軟で複雑なソフトウェア構成の実装を促進するために、任意の変化する計算モデルを表す必要がある場合は、証明Dynamic Computatonal Graphフレームワークを使用する概念の概念は、問題の解決のためにソフトウェアアーキテクチャを定義する最初の良いステップです。
すべての学習ソフトウェアがDCGを使用するわけではありませんが、任意の計算構造の体系的かつ継続的な操作が実行時の要件である場合、多くの場合、これらは良い選択です。
要するに、動的な計算グラフは、静的な問題では解決できない問題、またはバッチでのトレーニングを許可しないために非効率な問題を解決できます。
具体的には、最新のニューラルネットワークトレーニングは通常、 バッチでます。つまり、一度に複数のデータインスタンスを処理します。32、128などのバッチサイズを選択する研究者もいれば、10,000を超えるバッチサイズを使用する研究者もいます。通常、単一インスタンスのトレーニングは、ハードウェアの並列処理の恩恵を受けられないため、非常に遅くなります。
たとえば、自然言語処理では、研究者は異なる長さの文でニューラルネットワークをトレーニングしたいと考えています。静的計算グラフを使用すると、通常は最初に行う必要がありますパディングをます。つまり、短い文の最初または最後に無意味な記号を追加して、すべての文を同じ長さにします。この操作は、トレーニングを非常に複雑にします（たとえば、マスキングの必要性、評価指標の再定義、これらの埋め込まれたシンボルの計算時間の大幅な浪費）。動的な計算グラフを使用すると、パディングは不要になります（または各バッチ内でのみ必要になります）。
より複雑な例は、構文解析ツリーに基づいて文を処理する（ニューラルネットワークを使用する）ことです。各文には独自の解析ツリーがあるため、それぞれに異なる計算グラフが必要です。つまり、静的計算グラフを使用したトレーニングでは、単一インスタンスのトレーニングのみが許可されます。これに似た例は、再帰ニューラルネットワークです。
多くのディープニューラルネットワークには静的なデータフローグラフがあります。これは、その計算の構造（その計算グラフ）が異なる入力に対して安定していることを大まかに意味します。この機能は、ミニバッチ処理（大量の入力を一度に処理するなど）などのパフォーマンスのために活用できるため、優れています。
ただし、一部のニューラルネットワークでは、入力ごとに異なる計算グラフを使用できます。これはいくつかの問題を引き起こし（バッチ処理の困難性、グラフの構築は計算コストが高い）、これらのネットワークは少し使いにくいです。
リンクする論文は、複数の計算グラフを1つにまとめることができる方法を提案することにより、この問題を克服しています。その後、通常のNNテクニックを実行できます。
利点はスピードアップであり、これは研究者が異なる構造を探求し、私が推測するより創造的になることを奨励します。
動的計算グラフの利点には、入力データのさまざまな量に適応する機能が含まれているようです。トレーニング中の各入力セットインスタンスに応じて、レイヤー数、各レイヤーのニューロン数、活性化関数、およびその他のNNパラメーターが自動的に選択されるようです。これは正確な特性評価ですか？
これは間違っています。