コードの続きの説明です。

このコードブロックは、訓練されたモデルと関連データをオンラインのリポジトリ、具体的にはHugging Face Hubへアップロードするための処理を行っています。Hugging Face Hubは、機械学習モデルを共有、探索、再利用するためのプラットフォームです。以下に、このプロセスの詳細を説明します。

コードの詳細解説

1. アップロード条件の確認:

           if args.upload_model:

この行は、モデルをアップロードするかどうかをコントロールするフラグ args.upload_model をチェックしています。このフラグが真（True）の場合のみ、モデルと関連データのアップロードが実行されます。

2. Hugging Faceのユーティリティのインポート:

           from huggingface import push_to_hub

Hugging FaceのAPIを利用するための関数 push_to_hub をインポートしています。この関数は、モデルやその他のアーティファクトをHugging Face Hubにプッシュするために使用されます。

3. リポジトリ名とIDの設定:

           repo_name = f"{args.exp_name}"
           repo_id = f"{args.hf_entity}/{repo_name}" if args.hf_entity else repo_name

• repo_name: リポジトリ名は実験名（args.exp_name）を基に設定されています。
• repo_id: 完全なリポジトリIDを生成します。ユーザーまたは組織のエンティティ名が args.hf_entity に設定されている場合、それを含めた形式でIDが構成されます。

4. モデルとデータのアップロード:

           push_to_hub(args, episodic_returns, repo_id, "DQN", f"runs/{run_name}", f"videos/{run_name}-eval")

• args: 実行時の設定やパラメータが含まれる引数オブジェクト。
• episodic_returns: 評価フェーズで得られたエピソードごとの報酬リスト。
• repo_id: リポジトリのID。
• "DQN": 使用されたアルゴリズムの名前。
• f"runs/{run_name}": 訓練されたモデルファイルが保存されているディレクトリのパス。
• f"videos/{run_name}-eval": 評価フェーズのビデオやその他のメディアファイルが保存されているディレクトリのパス。

役割と重要性

このステップは、研究者や開発者が自身のモデルを広く共有するために非常に重要です。Hugging Face Hubにモデルを公開することで、他の研究者や開発者がアクセスし、利用することが可能となります。これにより、コラボレーションが促進され、モデルの再利用や改良が容易になります。また、学習プロセスや評価結果を透明に共有することで、信頼性の高い機械学習コミュニティの構築に貢献します。

前のブログ 次のブログ

RAMS 2026のwebsiteにプログラムマトリクスのドラフトが掲載されました。弊社の論文はFault Treeのセッションで発表することになると思います。

論文はドラフトを作成中で、同時に7月末までにプレゼン資料を作成しなければならないため、そちらもこれから作成予定です。

前のブログ 次のブログ

コードの続きの説明です。

このコードブロックでは、評価フェーズで得られた各エピソードの結果（報酬の合計）を記録しています。この情報は、トレーニングされたモデルの性能を可視化し、分析するために使用されます。以下に、このプロセスについて詳しく説明します。

コードの詳細解説

1. エピソードごとの報酬の列挙:

           for idx, episodic_return in enumerate(episodic_returns):

この行では、evaluate 関数から返された episodic_returns リストをループしています。このリストには、評価フェーズの各エピソードで得られた累積報酬が含まれています。enumerate 関数を使用することで、エピソードのインデックス (idx) とそのエピソードでの報酬 (episodic_return) を取得しています。

2. 報酬の記録:

           writer.add_scalar("eval/episodic_return", episodic_return, idx)

writer.add_scalar 関数を使用して、TensorBoardなどの視覚化ツールに報酬を記録しています。ここで、"eval/episodic_return" は記録するデータの名前（タグ）、episodic_return はそのエピソードでの累積報酬、idx はエピソードのインデックスを指します。この方法で記録されたデータは、学習の監視および後の分析のために視覚的に確認できるようになります。

役割と重要性

このステップは、モデルの評価結果を詳細に記録し、モデルの性能を定量的に追跡するために重要です。各エピソードの報酬を記録することで、モデルが一貫して高いパフォーマンスを達成しているか、または一部のエピソードでのみ良好な結果が得られているかを識別できます。これにより、モデルの堅牢性や特定の状況における弱点を明らかにすることができ、さらなる改善や調整のための具体的なデータが提供されます。

このようなフィードバックは、モデルの調整や、将来的なトレーニング戦略の計画に不可欠です。また、実際のアプリケーションや異なる環境でのモデルの振る舞いを予測するための重要な手がかりを提供します。

前のブログ 次のブログ

4.3. 確率計算の統合

規格Part 10ではSMの診断率DCを$K_\text{IF,RF}$、SM2の診断率DC2を$K_\text{SM,MPF}$としています。それらを用いれば(988.1)は、 $$ \Pr\{\text{VSG}\}=\Pr\{\text{VSG.RF}\}+\Pr\{\text{VSG.DPF'}\}\\ =\Pr\{\overline{\text{IF}}\cap\overline{\text{DC}}\}+\frac{1}{2}\Pr\{\overline{\text{IF}}\}\Pr\{\overline{\text{SM}}\cap\text{DC}\}\\ =(1-\text{DC})\Pr\{\overline{\text{IF}}\}+\frac{1}{2}\text{DC}\Pr\{\overline{\text{IF}}\}\Pr\{\overline{\text{SM}}\}\\ =(1-K_\text{IF,RF})\lambda_\text{IF}T_\text{lifetime}+\frac{1}{2}K_\text{IF,RF}\lambda_\text{IF}T_\text{lifetime}\left[(1-K_\text{SM,MPF})\lambda_\text{SM}T_\text{lifetime}+K_\text{SM,MPF}\lambda_\text{SM}\tau\right]\\ =(1-K_\text{IF,RF})\lambda_\text{IF}T_\text{lifetime}+\frac{1}{2}K_\text{IF,RF}\lambda_\text{IF}\lambda_\text{SM}T_\text{lifetime}\left[(1-K_\text{SM,MPF})T_\text{lifetime}+K_\text{SM,MPF}\tau\right]\tag{990.1}\label{eq:990-1} $$ よって、PMHFは\eqref{eq:990-1}の両辺を$T_\text{lifetime}$で割って求められるので、 $$ M_\text{PMHF}=\frac{1}{T_\text{lifetime}}\Pr\{\text{VSG}\}\\ =(1-K_\text{IF,RF})\lambda_\text{IF}+\frac{1}{2}K_\text{IF,RF}\lambda_\text{IF}\lambda_\text{SM}\left[(1-K_\text{SM,MPF})T_\text{lifetime}+K_\text{SM,MPF}\tau\right]\tag{990.2}\label{eq:990-2} $$

4.4 規格式との比較

これは規格第1版のPMHF式と正確に一致します。規格式は両辺を$T_\text{lifetime}$で割ることをわざわざ明示しています。

ただし、以下のように読み替えます。$\text{m}\rightarrow\text{IF}$、$\text{sm}\rightarrow\text{SM}$、他の定数はPart 10で定義されています。 $$ \begin{eqnarray} \begin{cases} \lambda_\text{m,RF}&=(1-K_\text{IF,RF})\lambda_\text{IF}\\ \lambda_\text{m,DPF}&=K_\text{IF,RF}\lambda_\text{IF}\\ \lambda_\text{sm,DPF,latent}&=(1-K_\text{SM,MPF})\lambda_\text{SM}\\ \lambda_\text{sm,DPF,detected}&=K_\text{SM,MPF}\lambda_\text{SM}\\ \end{cases} \end{eqnarray}\tag{990.3}\label{eq:990-3} $$ 図104.2で示すように規格初版のPMHF式には0.5という定数がありましたが、実は「SMが先に故障した場合に限る」ことから0.5が掛かっていたわけでした。

前のブログ 次のブログ

4.2.1 IFが先に故障する場合

ひとつずつ確率を求めます。まず(988.5)を用いると式(988.6)の第1項は $$ \Pr\{\overline{\text{IF}}\ \vec{\cap}\ \overline{\text{SM}}\cap\text{DC}\}=\Pr\{\overline{\text{IF}}\cap\overline{\text{SM}}\cap\text{DC}\cap(T_\text{IF}\lt T_\text{SM})\}\\ =\Pr\{\overline{\text{IF}}\cap\overline{\text{SM}}\}\cdot\text{DC}\cdot\frac{1}{2}=\frac{1}{2}\text{DC}\Pr\{\overline{\text{SM}}\ |\ \overline{\text{IF}}\}\Pr\{\overline{\text{IF}}\} \tag{989.1}\label{eq:989-1} $$ \eqref{eq:989-1}はIFの故障が起き、カバレージ範囲内なので通常はSMでFTTI中にカバーされるものの、さらにFTTI中にSMが故障するDPFの確率を表します。

• IFの暴露時間と故障率
  IFの暴露時間は車両寿命であり、故障確率は(988.2)から$\lambda_\text{IF}T_\text{lifetime}$となります。 $$ \Pr\{\overline{\text{IF}}\}\approx\lambda_\text{IF}T_\text{lifetime}\tag{989.2}\label{eq:989-2} $$

• SMの暴露時間と故障率
  SMの暴露時間は上記からFTTI未満でありゼロとみなせます。 $$ \Pr\{\overline{\text{SM}}\ |\ \overline{\text{IF}}\}\tag{989.3}\approx0\label{eq:989-3} $$ 従って\eqref{eq:989-1}の値は0となります。

4.2.2 SMが先に故障する場合

次に式(988.6)の第2項は $$ \Pr\{\overline{\text{SM}}\ \vec{\cap}\ \overline{\text{IF}}\cap\text{DC}\}=\Pr\{\overline{\text{SM}}\cap\overline{\text{IF}}\cap\text{DC}\cap(T_\text{SM}\lt T_\text{IF})\}\\ =\Pr\{\overline{\text{IF}}\cap\overline{\text{SM}}\}\cdot\text{DC}\cdot\frac{1}{2}=\frac{1}{2}\text{DC}\Pr\{\overline{\text{IF}}\ |\ \overline{\text{SM}}\}\Pr\{\overline{\text{SM}}\}\\ \tag{989.4}\label{eq:989-4} $$

• SMの暴露時間と故障率
  SMのフォールトの暴露時間は以下のように場合分けが必要です。

• 2nd SMがカバーできずに露出時間が車両寿命となる場合、もしくは
• 2nd SMがカバーできるが露出時間が検査周期となる場合

よって、 $$ \Pr\{\overline{\text{SM}}\} =\Pr\{\overline{\text{SM}}\cap\overline{\text{DC2}}\}+\Pr\{\overline{\text{SM}}\cap\text{DC2}\}\\ =\Pr\{\overline{\text{DC2}}\}\Pr\{\overline{\text{SM}}\}+\Pr\{\text{DC2}\}\Pr\{\overline{\text{SM}}\}\\ =(1-\text{DC2})\int_0^{T_\text{lifetime}}f_\text{SM}(t)dt+\text{DC2}\int_0^{\tau}f_\text{SM}(t)dt\\ =(1-\text{DC2})F_\text{SM}(T_\text{lifetime})+\text{DC2}F_\text{SM}(\tau)\\ \approx(1-\text{DC2})\lambda_\text{SM}T_\text{lifetime}+\text{DC2}\lambda_\text{SM}\tau \tag{989.5}\label{eq:989-5} $$

• IFの暴露時間と故障率
  IFのフォールト事象の暴露時間はSMのフォールトとは独立であることから車両寿命となり、故障確率は(988.2)から$\lambda_\text{IF}T_\text{lifetime}$となります。 $$ \Pr\{\overline{\text{IF}}\ |\ \overline{\text{SM}}\}=\Pr\{\overline{\text{IF}}\}\approx\lambda_\text{IF}T_\text{lifetime}\tag{989.6}\label{eq:989-6} $$ 従って\eqref{eq:989-4}の値は\eqref{eq:989-7}となります。 $$ \eqref{eq:989-4}\approx\frac{1}{2}\text{DC}\lambda_\text{IF}T_\text{lifetime}\left[(1-\text{DC2})\lambda_\text{SM}T_\text{lifetime}+\text{DC2}\lambda_\text{SM}\tau\right]\tag{989.7}\label{eq:989-7} $$

前のブログ 次のブログ

4. 確率計算

排他事象の和が求められたので、式(987.6)は次のように確率式になおすことができます。 $$ \Pr\{\text{VSG}\}=\Pr\{\text{VSG.RF}\}+\Pr\{\text{VSG.DPF'}\}\\ =\Pr\{\overline{\text{IF}}\cap\overline{\text{DC}}\}+\Pr\{\overline{\text{IF}}\cap\overline{\text{SM}}\cap\text{DC}\}\tag{988.1}\label{eq:988-1} $$ ちなみに、2017年論文のPMHF式はこの排他事象が考慮されておらずダブルカウントしています。一方で2020年論文のPMHF式は正確です。

4.1 RFの確率計算

ここで、 $$ \Pr\{\overline{\text{IF}}\}=\int_0^{T_\text{lifetime}}f_\text{IF}(t)dt=F_\text{IF}(T_\text{lifetime})=1-e^{-\lambda_\text{IF}T_\text{lifetime}}\approx\lambda_{\text{IF}}T_{\text{lifetime}}\tag{988.2}\label{eq:988-2} $$ であることから、\eqref{eq:988-1}式第1項のVSG.RFの確率は、

$$ \Pr\{\text{VSG.RF}\}=\Pr\{\overline{\text{IF}}\cap\overline{\text{DC}}\} \approx(1-\text{DC})\lambda_\text{IF}T_\text{lifetime}\tag{988.3}\label{eq:988-3} $$ ただし、$f(t)$はPDF (Probability Density Function)、$F(t)$はCDF (Cumulative Distribution Function)です。

4.2 DPFの確率計算

同様に(987.1)のVSG.DPF確率を計算します。 $$ \Pr\{\text{VSG.DPF’}\}\equiv\Pr\{\overline{\text{IF}}\cap\overline{\text{SM}}\cap\text{DC}\}\tag{988.4}\label{eq:988-4} $$

ここで問題はIFとSMの故障が同時には起きないので、IFが先に故障するか、SMが先に故障するかのいずれかとなります。これは論理式では表せないので、新たに時制論理$\ \vec{\cap}\ $を導入します。例えば、IFが故障し、かつその後SMが故障する事象は以下のように表せます。$T_\text{IF}$及び$T_\text{SM}$は無故障運転時間(Failure Free Operating Time)を表す確率変数です。 $$ \{\overline{\text{IF}}\ \vec{\cap}\ \overline{\text{SM}}\}\equiv\{\overline{\text{IF}}\cap\overline{\text{SM}}\cap(T_\text{IF}\lt T_\text{SM})\}\tag{988.5}\label{eq:988-5} $$

これを用いれば、式\eqref{eq:988-4}は、IFが先に故障する場合とSMが先に故障する場合のそれぞれの確率の和として表せます。両方が同時に故障する確率は、数学的には「ほぼ確実に(a.s.)0」です。 $$ \eqref{eq:988-4}=\Pr\{(\overline{\text{IF}}\ \vec{\cap}\ \overline{\text{SM}}\cap\text{DC})\sqcup(\overline{\text{SM}}\ \vec{\cap}\ \overline{\text{IF}}\cap\text{DC})\}\\ =\Pr\{\overline{\text{IF}}\ \vec{\cap}\ \overline{\text{SM}}\cap\text{DC}\}+\Pr\{\overline{\text{SM}}\ \vec{\cap}\ \overline{\text{IF}}\cap\text{DC}\}\tag{988.6}\label{eq:988-6} $$ ただし、$\sqcup$は互いに素な和を示す。

\eqref{eq:988-6}式第1項のIFが先に故障する場合と、第2項のSMが先に故障する場合の2パターンを順番に計算していきます。

前のブログ 次のブログ

1. はじめに

PMHF公式を別の方法で導出します。本来は過去記事にもあるようにマルコフ図を用いて確率微分方程式を建て、それを解いて求めるのが王道のやり方ですが、ここでは主に論理式だけでVSG確率からPMHFを求めます。

2. 前提条件

PMHFの対象となるサブシステムは冗長系ではなく、IFUモデルとします。IFUモデルとはSMはIFの代替機能を持たず、従ってIFが非修理系、SMが修理系となるものです。前提としてIFの故障とSMの故障は独立事象とします。

3. VSGの表現

IFのフォールトがVSGとなる事象は、IFが故障し、かつSMがカバーできる場合を除く場合です。一方、SMがカバーできるのはSMが動作し、かつSMのカバレージ範囲内です。これを差集合を表す論理式で表せば次のようになります。 $$ \{\text{VSG}\}\equiv\{\overline{\text{IF}}\setminus(\text{SM}\cap\text{DC})\}\tag{987.1}\label{eq:987-1} $$ 式\eqref{eq:987-1}は次のように書き換えられます。 $$ \eqref{eq:987-1}=\{\overline{\text{IF}}\cap\overline{(\text{SM}\cap\text{DC})}\}=\{ \overline{\text{IF}}\cap(\overline{\text{SM}}\cup\overline{\text{DC})}\}=\{ (\overline{\text{IF}}\cap\overline{\text{SM}})\cup(\overline{\text{IF}}\cap\overline{\text{DC})}\}\tag{987.2}\label{eq:987-2} $$ 説明の順番を入れ替え、式\eqref{eq:987-2}の第2項は、IFの故障かつSMのカバー範囲外を示すため、RFを意味します。よって、VSG.RFを次のように定義します。 $$ \{\text{VSG.RF}\}\equiv\{\overline{\text{IF}}\cap\overline{\text{DC}}\}\tag{987.3}\label{eq:987-3} $$ 次に式\eqref{eq:987-2}の第1項は、IFの故障かつSMの故障を示すため、DPFを意味します。よって、VSG.DPFを次のように定義します。 $$ \{\text{VSG.DPF}\}\equiv\{\overline{\text{IF}}\cap\overline{\text{SM}}\}\tag{987.4}\label{eq:987-4} $$

ところがVSG.RFとVSG.DPFの事象は排他ではないので、新たにVSG.RFと排他になるような事象VSG.DPF'を考える$\dagger$と $$ \{\text{VSG.DPF'}\}\equiv\{\overline{\text{IF}}\cap\overline{\text{SM}}\cap\text{DC}\}\tag{987.5}\label{eq:987-5} $$

よって、式\eqref{eq:987-3}及び\eqref{eq:987-5}を用いてVSG事象を表せば、総合的なVSGは以下のように表せます。 $$ \{\text{VSG}\}\equiv\{\text{VSG.RF}\sqcup\text{VSG.DPF'}\}\\ =\{(\overline{\text{IF}}\cap\overline{\text{DC}})\sqcup(\overline{\text{IF}}\cap\overline{\text{SM}}\cap\text{DC})\}\tag{987.6}\label{eq:987-6} $$ ただし、$\sqcup$は互いに素な和を示します。

$\dagger$後で確率計算に移る場合に事象にダブりがあると、確率がダブルカウントとなるためです。

前のブログ 次のブログ

コードの続きの説明です。

このコードブロックは、訓練されたDeep Q-Network (DQN) モデルを評価するプロセスを実行する部分です。ここで、evaluate 関数を使用して、保存されたモデルを特定の環境において複数のエピソードにわたってテストし、そのパフォーマンスを測定しています。以下、コードの各部分について詳しく説明します。

コードの詳細解説

1. 評価関数のインポート:

           from dqn_eval import evaluate

この行では、DQNモデルを評価するための関数 evaluate をインポートしています。この関数は通常、モデルのパフォーマンスをテストするために設計されたモジュールに定義されています。

2. モデル評価の実行:

           episodic_returns = evaluate(
               model_path,
               make_env,
               args.env_id,
               eval_episode=10,
               run_name=f"{run_name}-eval",
               Model=QNetwork,
               device=device,
               epsilon=0.05,
           )

• model_path: 評価するモデルのファイルパス。
• make_env: 環境を生成する関数。テスト時に使用する環境をセットアップするために必要です。
• args.env_id: 評価に使用する環境のID。これは具体的なゲームやタスクを指定するために使用されます。
• eval_episode: 評価を行うエピソードの数。ここでは10エピソードでモデルを評価しています。
• run_name: 評価のための実行名。ログや結果の保存に使われる名前を指定しています。
• Model: 使用するモデルクラス。ここでは QNetwork を指定しています。
• device: 評価を行うデバイス（CPUまたはGPU）。
• epsilon: 探索率。評価時には低い探索率（ここでは0.05）を設定することが一般的です。

役割と重要性

この評価プロセスは、訓練されたモデルが実際の環境でどれだけ効果的に機能するかを測定するために重要です。訓練中に得られた知見が新しい、未見の状況にどれだけ一般化できるかを確かめるために、通常、訓練環境とは異なる環境や設定で評価を行います。evaluate 関数は、特定のパラメータ（探索率など）の下でモデルの振る舞いを試験し、得られた報酬（episodic returns）を返します。これにより、モデルの性能を定量的に評価し、さらなる改善の方向性を定めることができます。

前のブログ 次のブログ

コードの続きの説明です。

このコードブロックは、訓練されたモデルの状態（パラメータ）を保存するための処理を行っています。ここでは、条件に基づいてモデルをファイルシステムに保存し、保存が完了したことを確認するメッセージを表示しています。これにより、後でモデルを再利用したり、さらなる評価を行ったりすることが可能になります。

コードの詳細解説

1. モデル保存の条件チェック:

           if args.save_model:

この条件は、コマンドライン引数や設定ファイルから指定されたフラグ（args.save_model）に基づいて、モデルを保存するかどうかを判断します。このフラグが真（True）の場合のみ、次のステップでモデルが保存されます。

2. 保存ファイルパスの設定:

          model_path = f"runs/{run_name}/{args.exp_name}.pth"

保存するモデルのファイルパスを指定します。このパスは、実行名 (run_name) と実験名 (exp_name) を含むディレクトリ構造に基づいて動的に生成されます。ファイルの拡張子は .pth で、これはPyTorchのモデルファイルで一般的に使用されます。

3. モデルの保存:

          torch.save(q_network.state_dict(), model_path)

torch.save 関数を使用して、Qネットワークのパラメータ（state_dict()で取得）を指定したパスに保存します。state_dict()は、モデルの各層におけるパラメータ（重みとバイアス）を辞書形式で保持しており、これによりモデルの完全な状態が保存されます。

4. 保存確認のメッセージ表示:

          print(f"model saved to {model_path}")

モデルの保存が完了したことをユーザーに通知するメッセージをコンソールに表示します。これは、プロセスの進行状況を追跡し、デバッグや確認のために有用です。

役割と重要性

この機能は、長時間にわたる訓練後に得られたモデルを保持し、将来的に同じモデルを再利用したり、さらに評価や微調整を行ったりするために重要です。モデルを保存することで、訓練プロセスが中断された場合にも、中断時点から再開することが可能になり、計算資源の節約にもつながります。また、モデルの性能を異なるデータセットや環境で評価する際にも、保存された状態から容易にテストを開始できます。

前のブログ 次のブログ

コードの続きの説明です。

このコードブロックは、Deep Q-Network (DQN) で使われる重要なテクニックであるターゲットネットワークのパラメータ更新に関するものです。具体的には、ソフトアップデート手法を用いてターゲットネットワークの重みを徐々に元のQネットワークの重みに近づける処理を行っています。

ソフトアップデートの概要

DQNでは、学習を安定化させるために、二つのネットワークを使用します：一つは学習に使われるQネットワークで、もう一つはターゲットネットワークです。ターゲットネットワークは、Qネットワークの学習が進むにつれて定期的にそのパラメータを更新することで、学習プロセス中の価値推定の変動を緩和します。この更新は、完全なコピー（ハードアップデート）か、徐々にパラメータを移動させるソフトアップデートのどちらかで行われます。

コードの詳細解説

1. 更新頻度のチェック:

           if global_step % args.target_network_frequency == 0:

この条件は、指定された頻度（args.target_network_frequency）ごとにターゲットネットワークのパラメータを更新するタイミングを決定します。

2. パラメータのソフトアップデート:

           for target_network_param, q_network_param in zip(target_network.parameters(), q_network.parameters()):
               target_network_param.data.copy_(
                   args.tau * q_network_param.data + (1.0 - args.tau) * target_network_param.data
               )

• zip(target_network.parameters(), q_network.parameters())を使用して、ターゲットネットワークとQネットワークの各パラメータを組み合わせます。
• ソフトアップデート式はargs.tau * q_network_param.data + (1.0 - args.tau) * target_network_param.dataです。ここでargs.tauは[0, 1]の範囲の値で、ターゲットネットワークのパラメータをどの程度Qネットワークに近づけるかを決定します。tauが1に近いほど、ターゲットネットワークはQネットワークに迅速に追従します。

役割と重要性

このソフトアップデートは、DQNの学習過程において重要な役割を果たします。ターゲットネットワークのゆっくりとした更新は、学習中の過大な価値推定の振動や発散を防ぎ、全体の学習プロセスの安定性を保ちます。このメカニズムにより、エージェントはより確実に効果的なポリシーに収束することができます。

前のブログ 次のブログ