自動プログラミングNLPモデル技術のレビュー

Copilot、Codex、AlphaCode: プログラミングを自動化するコンピュータ プログラムの現状

近年、自然言語処理の分野でトランスフォーマーが普及したおかげで、コードで記述されたディープラーニング モデルが驚くほど数多く登場しています。コンピュータ プログラムを作成できるコンピュータ プログラムは、プログラム合成問題とも呼ばれ、少なくとも 1960 年代後半から 1970 年代前半にかけて研究されてきました。

2010 年代と 2020 年代には、他の分野での注意ベースのモデルの成功により、プログラム合成研究、つまり数百 GB のテキストで数百万または数十億のパラメータを持つ大規模な注意ベースのニューラル モデル (Transformer) を事前トレーニングするという戦略が再び刺激されました。

事前トレーニング済みのモデルは、その注意メカニズムのおかげでメタ学習において優れた能力を示し、プロンプトコンテンツにほんの数例を提供することでテキストタスクを開発するのに実用的であると思われます（研究文献では「ゼロショット学習」または「少数ショット学習」として知られています）。

深層 NLP モデルに基づく最新のプログラム合成

NLP モデルは、特殊なデータセットを使用してさらにトレーニングし、特定のタスクでのパフォーマンスを微調整できます。コードの記述は、このアプリケーションにとって特に興味深い使用例です。

「あなたの AI ペアプログラマー」として宣伝された GitHub の Copilot プロジェクトは、2021 年に開始されたときにかなりの論争を巻き起こしました。これは主に、トレーニング データセットで公開されているすべての GitHub コードを使用しているためです。注記によると、これらのコード リポジトリにはコピーレフト ライセンスのプロジェクトが含まれており、Copilot 自体がオープン ソースでない限り、Copilot のようなプロジェクトでコードを使用することは許可されない可能性があります。

Copilot は、OpenAI 組織と Microsoft の関係から生まれた製品で、GPT-3 のコード トレーニング バージョンに基づいています。 OpenAI によってデモされ、API を通じて利用可能になったバージョンは Codex と呼ばれます。 Copex を使用した正式な実験的説明は、Chen らによる 2021 年の論文に詳しく記載されています。

2022年初頭、DeepMindは負けじと、独自のプログラム合成型ディープラーニングシステムであるAlphaCodeを開発しました。

新たな挑戦者: AlphaCode

AlphaCode は、以前の Codex や Copilot と同様に、コードの作成用に設計およびトレーニングされた大規模な NLP モデルです。 Copilot と同様に、AlphaCode はソフトウェア エンジニア向けの生産性向上ツールとして開発されたのではなく、競技プログラミング タスクにおける人間レベルのプログラミング パフォーマンスに挑戦するために開発されました。

AlphaCode のトレーニングと評価に使用される競争的なコーディング チャレンジ (新しい CodeContests データセットを構成) の難易度は、以前のデータセットの難易度と現実世界のソフトウェア エンジニアリングの難易度の中間に位置します。

競争力のあるコーディング チャレンジ サイトをよく知らない人にとって、この課題はテスト駆動開発の簡易版のようなものです。この課題は、いくつかのテキスト説明といくつかの例に基づいて、一連のテストに合格するプログラムを作成することです。テストのほとんどはプログラマーには隠されています。

理想的には、非表示のテストは包括的であるべきであり、すべてのテストに合格することは、特定の問題が正常に解決されたことを意味する。ただし、ユニット テストですべてのエッジ ケースをカバーするのは難しい問題です。プログラム合成の分野への重要な貢献は、実際には CodeContests データセット自体です。DeepMind チームは、誤検出率 (テストは合格するが、問題はまだ解決されていない) と低速検出率 (テストは合格するが、解決が遅すぎる) を減らすことを目標に、突然変異プロセスを通じて追加のテストを生成することに多大な労力を費やしました。

AlphaCode のパフォーマンスは、コンテスト ウェブサイト CodeForces のコンテスト プログラミング チャレンジの内容に基づいて評価されました。全体的に、AlphaCode は、コンテストに参加した (おそらく人間の) プログラマーの「上位 54.3%」にランクインしました。

この指標は実際には 45.7% のパフォーマンスに相当するため、少し誤解を招く可能性があることに注意してください。驚くべきことに、AlphaCode システムは、すべての隠されたテストに合格するあらゆるアルゴリズムを作成できます。ただし、注意してください。AlphaCode は、プログラミングの問題を解決するために、人間とはまったく異なる戦略を使用します。

人間の競技者は、ほとんどのルーチンを解決するアルゴリズムを作成し、以前のバージョンのソリューションの実行から得た洞察を取り入れ、すべてのテストに合格するまで継続的に改善しますが、AlphaCode はより広範なアプローチを採用し、問題ごとに複数の例を生成し、その中から 10 個を選択して提出します。

CodeContests データセットにおける AlphaCode のパフォーマンスに大きく貢献しているのは、生成後のフィルタリングとクラスタリングの結果です。約 1,000,000 個の候補ソリューションを生成した後、問題の説明にあるサンプル テストに合格しない候補を削除するために候補のフィルタリングを開始し、候補集団の約 99% を排除します。

著者らは、この段階では約 10% の問題にすべての例テストに合格する候補ソリューションがないと述べています。

残りの候補は、クラスタリングによって 10 件以下に絞り込まれます。つまり、問題の説明に基づいて追加のテスト入力を生成するために別のモデルをトレーニングしたのです (ただし、これらのテストには有効な出力がなかったことに注意してください)。

残りの候補ソリューション (フィルタリング後の数は 1000 未満になる場合があります) は、生成されたテスト入力に対する出力に従ってクラスター化されます。各クラスターから、最大から最小の順に 1 つの候補が選択され、提出されます。クラスターが 10 個未満の場合、クラスターは複数回サンプリングされます。

フィルタリング/クラスタリング手順は独特であり、AlphaCode は新しい CodeContests データセットで微調整されていますが、当初は Codex や Copilot とほぼ同じ方法でトレーニングされました。 AlphaCode は、まず GitHub から公開されているコードの大規模なデータセットで事前トレーニングされました (2021 年 7 月 14 日に取得)。彼らは5つの変異体を訓練し、パラメータの数を2億8400万から410億に増やしました。

AlphaCode は、AlphaGo シリーズや StarCraft II ゲームをプレイする AlphaStar ロボットと同じ精神で、特殊なタスク領域で人間の能力に近づくシステムの開発を目指す研究プロジェクトですが、プログラム合成中に開発される実用的なアプリケーションのハードルは低くなっています。

問題を解決するための実用的なツールを開発するという観点から、この分野の代表的なロボットは、GPT-3 をベースにした Codex と Copilot ツールです。 Codex は、公開されているコードのコーパスに基づいてトレーニングされた、GPT-3 の OpenAI 版です。 OpenAI は、論文とともに公開された HumanEval データセットに基づいて、Codex が「docstring からコード」形式でタスクのサンプルを 100 個生成することで、問題の 70% 以上を解決できたと報告しています。

次に、Codex を使用してコードを自動的に生成することで、このプロンプト プログラミング手法について説明します。同時に、以下のモデルを使用して、ジョン・コンウェイのライフゲームを開発します。

GitHub Copilot は自動コード補完方式を採用しており、現在のパッケージ形式は Visual Studio、VSCode、Neovim、JetBrains などの統合開発環境の拡張となっています。 Copilot の Web ページの説明によると、Copilot は指定された説明に基づいて、十分にテストされた Python 関数のセットを正常に書き換えることができ、そのうち 57% は HumanEval データセットに類似しています。

VS Code 用の Copilot 拡張機能のプライベート ベータ版を使用してテストを自動的に記述するなど、Copilot の実際の使用例をいくつか見ていきます。

プロンプトプログラミング: Codex で Conway のライフゲームを書く

このセクションでは、John Conway のライフゲームに基づいてセルオートマトンシミュレータを作成するタスクを紹介します。いくつかの変更を加え、ルールをハードコーディングせずに、私たちのプログラムは、リアルなセルオートマトンルールのあらゆるセットをシミュレートできるはずです。

100 個の例を生成し、最適な例を (手動で、またはテストを実行して) 選択する代わりに、対話型のアプローチを採用します。 Codex が不適切な解決策を提示した場合、私たちは調整を行い、より良い答えに導くよう努めます。もちろん、絶対に必要な場合、Codex が完全に失敗した場合は、コードを変更して動作する例を取得することができます。

現実的な CA シミュレーターを作成するための最初のステップは、近傍を計算する関数を作成することです。私たちは次の docstring プロンプトを作成し、それを OpenAI API ライブラリの最大の Codex モデルである code-davinci-001 に提供しました。

 ＃ プロンプト
numpyをnpとしてインポートする
def compute_neighborhood(グリッド: np.array) -> np.array:
 「」
 ムーア近傍のセル状態の合計を計算する
 入力グリッド内の各セルに対して。
 ムーア近傍には8つのセルが含まれます。
 中心のセルに斜めかつ直交して隣接しているが、中心のセルを含まない。
 「1」で示されるセルは、セル a のムーア近傍に対応します。
 1 1 1
 1a1
 1 1 1
 セル「a」がグリッドの端にある場合、
 ムーア近傍は反対側の端のセルまで回り込み、
 つまり、グリッドはトロイド上にあります。

 引数:
 グリッドは、0または1のバイナリ値を持つnumpy配列です。グリッドには、現在のセルの状態値が含まれています。
 戻り値:

 neighbor_grid、0 から 8 までの整数値を持つ numpy 配列。
 グリッド内の各セル（グリッド内の要素）に対して、neighborhood_gridは
 そのセルのムーア近傍の状態の合計を含む
 「」

上記のコードでは、プロンプトの終了位置を明確にするために、コメント行「# PROMPT」と「# GENERATED」が追加されています。

上記のかなり包括的なドキュメント文字列を注意深く分析しましたか? Codex はどのように機能しますか?実際、Codex の最初の試みは次のとおりでした。

 #生成
 # TODO: この機能を実装する
 合格

これはおそらく私たちの小さな実験にとって良い兆候ではないでしょう。 P 値のハイパーパラメータを調整して、より緩やかな核サンプリング (そしてできればより良い多様性) を実現した後でも、Codex は依然として上記の質問に対する答えを提供していないようです。

幸いなことに、docstring プロンプトに次のようなものを少し追加するだけで、Codex はより期待できる出力を生成します。

 # PROMPT (前のプロンプトに追加)

 この関数は完了しており、TODOは含まれていません
 「」

 #生成

 # グリッドの寸法を取得する
 n_rows、n_cols = グリッドの形状

 # 出力配列を初期化する
 近隣グリッド = np.zeros((n_rows, n_cols), dtype=int)

 # グリッドをループする
 i が範囲内(n_rows)の場合:
 jが範囲内(n_cols)の場合:

 # 現在のセルの値を取得する
 セル値 = グリッド[i, j]

 # 現在のセルのムーア近傍を取得します
 # get_neighborhood関数を使用する
 近隣 = get_neighborhood(グリッド、i、j)

 # 近傍のセルの値を合計する
 近隣の合計 = np.sum(近隣)

 # 合計を近隣グリッドに格納する
 近隣グリッド[i, j] = 近隣合計

 近隣グリッドを返す

もちろん、これはまだあまり良い解決策ではありません。未使用の変数 cell_val が導入され、その作業のほとんどが、追加したばかりの別の関数 get_neighborhood に委任されるからです。しかし、全体的には、これは実行可能なスタートのように見えます。

次に、上記の get_neighborhood 関数の簡単なドキュメント文字列を記述します。

 def get_neighborhood(グリッド: np.array, i: int, j: int) -> np.array:
 「」
 get_neighborhoodはcompute_neighborhoodによって使用されます
 セルの3x3ムーア近傍を返す
 座標i,jに位置するi,j座標が
 グリッドの端（つまり、iまたはjが0、またはi ==
 grid.shape[0]-1またはj == grid.shape[1]）、ムーア
 近傍は、
 反対側の端。言い換えれば、グリッドは
 「パックマン」のようなトロイドの表面である

 引数:
 グリッド、np.array、これが現在の状態です
 セルオートマトングリッド
 i, int、この座標は行に対応します
 j、int、列に対応する座標

 戻り値:
 moore_neighborhood - np.array、常に
 寸法 3x3 および
 i,jのセルのムーア近傍を含む
 グリッドの中央のセルは
 近隣地域、moore_neighborhood[1,1]は常に
 0になる
 「」

 #生成

 # グリッドの寸法を取得する
 n_rows、n_cols = グリッドの形状

 # 出力配列を初期化する
 ムーア近傍 = np.zeros((3, 3), dtype=int)

 # ムーア地区の座標を取得する
 # get_neighborhood_coordinates関数を使用する
 近隣座標 = \
近隣座標を取得します(i, j, n_rows, n_cols)

 # 座標をループする
 neighbor_coords の座標の場合:
 # 座標のセル値を取得する
 セル値 = グリッド[座標[0], 座標[1]]

 # セルの値を出力配列に格納する
 ムーア近隣[座標[0], 座標[1]] = セル値

 moore_neighborhoodを返す

上記のプログラムの出力は問題ないように見えるかもしれませんが、検査してみると、実際には重大なエラーが含まれています。

近傍座標のループでは、グリッドから値を取得するために使用したのと同じ座標を使用して、ムーア近傍に値を割り当てます。

Codex にエラーを回避するよう指示する明確な方法が見つからなかったため、手動でコードを変更する必要がありました。

 # 座標のループを修正
 enumerate(neighborhood_coords) のインデックス、座標の場合:
 # 座標のセル値を取得する
 セル値 = グリッド[座標[0], 座標[1]]

 # 修正: セルの値を出力配列に格納する
 moore_neighborhood[インデックス // 3, インデックス % 3] = cell_val

 moore_neighborhoodを返す

さらに、より「トリッキーな」部分を処理するために、前のコードでは別の関数 get_neighborhood_coordinates が導入されています。

次に、get_neighborhood_coordinates 関数のプロンプトを記述する必要があります。

 ＃ プロンプト
デフ get_neighborhood_coordinates(\
 i: int、j: int、n_rows: int、n_cols: int) -> リスト:
 「」
 get_neighborhood_coordinatesはget_neighborhoodによって使用されます
 3x3ムーア近傍の座標を返す
 座標i,jにあるセル i,j座標が
 グリッドの端（つまり、iまたはjが0に等しい、またはi ==
 grid.shape[0]-1またはj == grid.shape[1]）、ムーア
 近傍は、
 反対側の端。言い換えれば、グリッドは
 「パックマン」のようなトロイドの表面である

 引数:
 i, int、この座標は行に対応します
 j、int、列に対応する座標
 n_rows、int、グリッド内の行数
 n_cols、int、グリッド内の列数

 戻り値:
 neighborhood_coords - タプルのリスト、
 各タプルには座標が含まれる
 ムーア地区のセルの
 「」

 #生成

 # 出力リストを初期化する
 近隣座標 = []

 # ムーア地区の座標を取得する
 # get_neighborhood_coordinates 関数を使用する
 範囲(i-1, i+2)の行の場合:
 範囲(j-1, j+2)内の列の場合:
 # 中央のセルをスキップ
 行 == i かつ列 == j の場合:
 続く

 # セルがグリッドの端にあるかどうかを確認します
 # そうであれば、反対側の端まで折り返します
 行 < 0 の場合:
 行 = n_rows - 1
 elif 行 == n_rows:
 行 = 0

 列 < 0 の場合:
 列 = n_cols - 1
 elif col == n_cols:
 列 = 0

 # セル座標を保存する
 近隣座標.append((行, 列))

 近隣座標を返す

これは関数型プログラミングで予想していたよりも少し複雑ですが (compute_neighborhood が get_neighborhood を呼び出し、get_neighborhood_coordinates が呼び出されます)、ようやく近傍と座標のグリッドを返すことができる関数のセットができたようです。

更新関数は残っており、対応する docstring プロンプトは次のようになります。

 ＃ プロンプト

def update_grid(grid: np.array, ルール: リスト) -> np.array:
 「」
 ライフライクルールに従って入力引数グリッドを更新する
 入力引数ルールに含まれる。ルールはリストのリストであり、
 最初の要素には「誕生」のリストが含まれる
 条件（セルは0から1へ）と2番目の要素
 「生存」条件のリストを含む（セルは
 変更なし）。
 近傍の合計が
 「誕生」（B）または「生存」（S）ルールは 0 になります。

 この関数はcompute_neighborhood関数を使用して計算します
 グリッド内の各セルの近隣値。

 引数:
 グリッド、np.array。グリッドにはセルの値（0または1）が含まれます
 ルール、リストのリスト。ルールにはB/Sルールが含まれています
 例えば、
 ConwayのLife CAをシミュレートする、`rules = [[3], [2,3]]`、
 例えば、B3/S23 Life Without Deathにはルールがある
 B3/S012345678なので、`rules = [[3],
 [0,1,2,3,4,5,6,7,8]]`

 update_gridはルールに以下の内容が含まれている場合、例外を発生させる必要がある。
 8より大きい値（1つの細胞の最大生存細胞数）
 ムーア地区）または 0 未満。
 「」

 #生成

 # グリッドの寸法を取得する
 n_rows、n_cols = グリッドの形状

 # 近隣グリッドを取得する
 近隣グリッド = compute_neighborhood(グリッド)

 # グリッドをループする
 i が範囲内(n_rows)の場合:
 jが範囲内(n_cols)の場合:
 # 現在のセルの値を取得する
 セル値 = グリッド[i, j]

 # 現在のセルの近傍値を取得します
 近隣_val = 近隣_grid[i, j]

 # セルが生きているかどうか確認する
 cell_val == 1の場合:
 # セルが死ぬかどうかをチェックする
 neighbor_valがrules[1]にない場合:
 グリッド[i, j] = 0
 それ以外：
 # セルが誕生するかどうかをチェックする
 ルール[0]にneighborhood_valがある場合:
 グリッド[i, j] = 1

 リターングリッド

これは上記の問題に対する非常に合理的なアプローチのように思えますが、隣接グリッドに誤った値が含まれており、生成された出力に見つからない場合、例外を発生させることを明示的に推奨します。

ほんの少しの調整、関数 get_neighborhood への手動介入、ヒントを使ったいくつかの実験により、実物そっくりのセルオートマトンを完全に機能させるシミュレーターを設計することができました。

上記のコードは特に高速な実装ではありませんが、その品質は、プログラマーが新しい言語を使い始めるときに行う「Hello World」の試みに似ています。研究者が参照できるように、トレーニング データセットに多くの例が含まれていることは注目に値します。

コンウェイのライフゲームでは、この手順がマイクログライダーの開発に成功することが想像できます。

一連の関数を使用して CA シミュレーターを作成することはできましたが、このアプローチは日常的なソフトウェア エンジニアリングの開発方法としてはあまり有用でも現実的でもありません。一方、SourceAI（基本的にはOpenAI Codex APIのラッパー）のようなスタートアップが、自社のサービスを「誰もが価値あるカスタムソフトウェアを作成する機会」を提供すると宣伝するのを止めることはできません。

「私たちは、世界で最も熟練したエンジニアのレベルのソフトウェアを生産できるスタンドアロン システムを構築しました。」それでも、Codex とやり取りすることは、特に CodeSignal、CodeForces、HackerRank などのサイトからのコーディング問題でプログラミングを学習または練習するための潜在的に有用な方法です。

次に、テストとドキュメント文字列を自動的に記述するというより現実的なユースケースについて Codex/Copilot を評価してみます。

タスク 2: テストの作成

この例では、VSCode 開発ツールの GitHub Copilot 拡張機能を使用してテストを記述することを選択しました。

 # PROMPT (VSCode 内)
 numpyをnpとしてインポートする
定義ピタゴラス(a: np.float, b: np.float) -> np.float:
 「」
 ピタゴラスの定理を使って斜辺を計算します。
 辺の長さがaとbの三角形

 引数:
 a、np.float、三角形の辺
 b、np.float、三角形のもう一方の辺

 戻り値:
 c, np.float, 斜辺の長さ
 「」
 c = np.sqrt(a**2 + b**2)
 リターンc

 test_pythagorean() を定義します:

 # 生成済み (Copilot オートコンプリート)
 「」
 ピタゴラス関数をテストする
 「」
 a = np.array([3, 4, 5])
 b = np.array([4, 5, 6])
 c = ピタゴラス(a, b)

 np.allclose(c, np.sqrt(a**2 + b**2)) をアサートする

ピタゴラスの定理関数は過度に単純化されているかもしれませんが、Copilot は合理的なテストを提案します。実行すれば合格します。オートコンプリートの提案により、テストの構造と数値コンテンツが適切に取得されていることに気付くでしょう。

お気に入りのフレームワークを使用して、より体系的な方法でテストを記述したい場合はどうすればよいでしょうか?あまり心配しないでください。テスターが使用できるように、numpy ライブラリと自動微分化技術を使用して、低レベルの学習モデルを多数作成しました。したがって、次の例は現実世界に 100% 忠実ではありませんが、効果は依然として現実にかなり近いものになります。

この例では、autograd と numpy、および unittest の TestCase クラスを使用して、テスト用の単純な多層パーセプトロン フォワード パス、損失関数、および勾配関数を設定します。

 ＃プロンプト
ユニットテストをインポートする
autogradからnumpyをnpとしてインポートします
autogradからgradをインポート

def forward_mlp(input_x: np.array, \
 重み: リスト、バイアス: リスト) -> np.array:
 「」
 多層パーセプトロンの順方向パスを計算します。
 レイヤーの数はリストの長さに等しい。
 重みはバイアスのリストと同じでなければならない。
 偏見。

 引数:
 input_x、np.array、入力データ
 重み、np.array のリスト、np.array 行列のリスト、
 重みを表す
 バイアス: np.arraysのリスト、各バイアスのリスト
 層

 戻り値:
 結果、np.array、ネットワークの出力
 「」

 len(重み) == len(バイアス) をアサートする

 layer_indexがrange(len(weights) - 1)の場合:
 input_x = np.tanh(np.matmul(input_x,\
 重み[レイヤーインデックス]) + バイアス[レイヤーインデックス])

 出力 = np.matmul(input_x, 重み[-1]) + バイアス[-1]
 出力を返す
def get_loss(input_x: np.array, weights: リスト, \
 バイアス: リスト、ターゲット: np.array) -> np.float:
 「」
 重み付きMLPの平均二乗誤差損失を計算する
 入力データinput_xとバイアスに関して、
 ターゲット配列ターゲット。

 引数:
 input_x、np.array、入力データ
 重み、np.array のリスト、np.array 行列のリスト、
 重みを表す
 バイアス: np.arraysのリスト、各バイアスのリスト
 層
 target: np.array、ターゲット値

 戻り値:
 損失、np.float、損失
 「」

 出力 = forward_mlp(input_x, 重み, バイアス)

 np.mean((出力 - ターゲット)**2) を返します。

 get_loss_grad = grad(get_loss, 引数=(1,2))


クラス TestMLP(unittest.TestCase):
 「」
 MLP、get_loss、get_grad_loss のテスト
 「」
 # 生成済み（Copilot の提案から選択）
 def setUp(self):
 合格

 test_forward_mlp(self)を定義します。
 「」
 テスト forward_mlp
 「」

 input_x = np.array([[1, 2, 3], [4, 5, 6]])
 重み = [np.array([[1, 2], [3, 4]]), \
 np.array([[5, 6], [7, 8]]), \
 np.array([[9, 10], [11, 12]])]
 バイアス = [np.array([[1, 2]]), np.array([[3, 4]]),
 np.配列([[5, 6]])]

 出力 = forward_mlp(input_x, 重み, バイアス)
 self.assertTrue(np.allclose(出力、\
 np.array([[-0.9, -0.9], [-0.9, -0.9]])))

 def test_get_loss(自己):
 「」
 get_loss をテストする
 「」
 input_x = np.array([[1, 2, 3], [4, 5, 6]])
 重み = [np.array([[1, 2], [3, 4]]), \
 np.array([[5, 6], [7, 8]]), \
 np.array([[9, 10], [11, 12]])]
 バイアス = [np.array([[1, 2]]), np.array([[3, 4]]),\
 np.配列([[5, 6]])]
 ターゲット = np.array([[1, 1], [1, 1]])

 損失 = get_loss(input_x, 重み, バイアス, ターゲット)

 自己.assertTrue(np.allclose(損失、0.5))

 def test_get_loss_grad(自己):
 「」
 get_loss_grad をテストする
 「」

 input_x = np.array([[1, 2, 3], [4, 5, 6]])
 重み = [np.array([[1, 2], [3, 4]]), \
 np.array([[5, 6], [7, 8]]), \
 np.array([[9, 10], [11, 12]])]
 バイアス = [np.array([[1, 2]]), np.array([[3, 4]]), \
 np.配列([[5, 6]])]
 ターゲット = np.array([[1, 1], [1, 1]])

 損失勾配 = get_loss_grad(\
 input_x、重み、バイアス、ターゲット)

 自己.assertTrue(\
 np.allclose(損失勾配[0], \
 np.array([[-0.9, -0.9], [-0.9, -0.9]])))
 自己.assertTrue(\
 np.allclose(損失勾配[1], \
 np.array([[-0.9, -0.9], [-0.9, -0.9]])))
 自己.assertTrue(\
 np.allclose(損失勾配[2],\
 np.array([[-0.9, -0.9], [-0.9, -0.9]])))

 # END GENERATED (最後の 2 行はプロンプトの一部です)
 __name__ == "__main__" の場合:
 unittest.main(詳細度=1)

Copilot の提案は完璧ではありませんが、クラスのテストに合理的なアイデアを提供します。ただし、コードをそのまま実行しようとすると、テストは実行されず、合格することもできません。

入力データと最初の重み行列の間に次元の不一致があり、データ型が間違っています (すべての配列が整数データ型です)。また、Autograd 勾配関数は使用できません。

もちろん、これらの問題を修正するのはそれほど難しくありません。重み行列リストの最初のエントリを 3x2 行列に置き換えると、フォワード パスが機能するはずです。勾配計算テストをスムーズに動作させるには、np.array で定義された数値に小数点を追加するか、配列データ型を明示的に定義する必要があります。

これらの変更により、テストは正常に実行され、失敗しますが、期待値は数値の点ではまだ正しくありません。

タスク 3: 自動ドキュメント文字列

Copilot が大きな可能性を秘めているタスクの 1 つは、ドキュメント作成の自動化、特に既に記述された関数の docstring の入力です。この側面は、ほぼより実用的です。

ピタゴラスの定理の例の場合、Copilot は非常に近いですが、辺 c から辺 a および b までの距離を求めるのではなく、2 つの点 a と b の間の距離を求めるという問題を設定します。予想どおり、Copilot に同梱されているドキュメント文字列の例も関数の実際の内容と一致していません。c からの値の配列ではなく、スカラーが返されます。

Copilot によるフォワード MLP 関数のドキュメント文字列の提案も近いですが、完全に正しいわけではありません。

Copilot による自動 Docstring 提案

機械が私の仕事を奪うことができるでしょうか？

ソフトウェア エンジニアにとって、プログラム合成におけるあらゆる新たな進歩は、経済的なパニックを引き起こす可能性があります。

結局のところ、コンピュータ プログラムがプログラマーと同じようにコンピュータをプログラムできるのであれば、それは機械が「私たちの仕事を奪う」べきということではないでしょうか?近い将来にそうなるでしょうか?

表面的には、答えは「まだ」のように思えますが、これは、これらのツールがより成熟してもソフトウェア エンジニアリングの本質が変わらない可能性が高いことを意味するものではありません。将来的には、洗練された自動補完ツールをうまく使いこなせることが、コードフォーマットツールをうまく使いこなせることと同じくらい重要になるかもしれません。

Copilot は現在ベータ版であり、使用方法のオプションが限られています。同様に、Codex にも OpenAI を通じてベータ版で利用できるアプリケーション プログラミング インターフェイスがあります。パイロット プログラムの利用規約とプライバシーに関する考慮事項により、このテクノロジの潜在的な使用事例は制限されます。

現在のプライバシー ポリシーでは、これらのシステムに入力されたコードはモデルを微調整するために使用され、GitHub/Microsoft または OpenAI の従業員によってレビューされる可能性があります。これにより、機密性の高いプロジェクトでは Codex または Copilot を使用できなくなります。

Copilot は、そのベースとなっている Codex モデルに多くのユーティリティを追加します。必要なコードのスケルトンまたはアウトラインを記述し (unittest フレームワークのテスト例を記述するなど)、カーソルをアウトラインの中央に移動すると、適切な OK 自動補完の提案が表示されます。

現状では、Copilot は単純なコーディング方法よりも複雑なものに対しては、正しい完全なコードを提案する可能性は低いですが、通常は妥当なアウトラインを作成し、手作業による入力をいくらか省くことができます。

Copilot はクラウドで実行されることにも注意してください。つまり、オフラインでは機能せず、オートコンプリートの提案が少し遅くなります。この時点で、Alt + ] を押すことで候補を切り替えることができますが、選択できる候補が少数の場合や、1 つだけの場合もあります。

Copilot がうまく機能する場合 (実際、十分にうまく機能する場合)、少し危険です。 unittest の例で提案されているテストと、pythagoras 関数の提案されている docstring は、一見すると正しいように見え、おそらく、熟練したソフトウェア エンジニアのレビューでも合格するでしょう。しかし、謎のバグが含まれていた場合、後で苦痛を感じることになります。

まとめると、 Copilot/Codex は現状ではおもちゃや学習ツールに近いものですが、実際に機能するのは驚くべきことです。ワルツを踊っているクマに出会ったら、そのダンスの上手さに感動することはないだろう。同様に、スマートなコード補完ツールに出会った場合、感心すべきなのは、そのツールが書き込むコードがいかに完璧であるかということではありません。

要約すると、自動プログラミング NLP モデルの技術がさらに発展し、人間のプログラマーが NLP を使用した自動補完ツールに多くのチューニングを施すことで、近い将来、プログラム合成モデルの主要なキラー アプリが登場する可能性があります。

翻訳者紹介

Zhu Xianzhong 氏は、51CTO のコミュニティ エディターであり、51CTO の専門ブロガー兼講師であり、濰坊の大学のコンピューター教師であり、フリーランス プログラミング コミュニティのベテランです。初期にはさまざまな Microsoft テクノロジに注力し (ASP.NET AJX および Cocos 2d-X に関連する 3 冊の技術書を編纂)、オープンソースの世界に 10 年近く携わってきました (人気のフルスタック Web 開発テクノロジに精通)。OneNet/AliOS+Arduino/ESP32/Raspberry Pi をベースとした IoT 開発テクノロジや、Scala+Hadoop+Spark+Flink などのビッグデータ開発テクノロジを理解しています。

原題: ​NLP Models for Writing Code: Program Synthesis ​、著者: Kevin Vu