7

私がこの質問をしているのは、明確な答えを与えることができるよく読まれた CS タイプがここにたくさんいることを知っているからです。

自分でコードを生成してコンパイルしてプログラムを書き、過去の反復から学習して進歩するような AI が存在するか (または研究/開発されているか) 疑問に思っています。私は、私たちプログラマーを時代遅れにするために働くことについて話している. 試行錯誤によって、プログラミング言語で何が機能し、何が機能しないかを学習するものを想像しています。

私はこれが空想のパイに聞こえることを知っているので、何が行われたかを知りたいと思っています。

もちろん、人間のプログラマーでも入力と仕様が必要なので、このような実験ではパラメーターを慎重に定義する必要があります。AI がさまざまなタイミング機能を探索する場合と同様に、その側面を明確に定義する必要があります。

しかし、洗練された学習 AI があれば、それが何を生成するのか興味があります。

私たちの判断力、好み、偏見など、コンピューターが再現できない人間の資質がたくさんあることを私は知っています。しかし、私の想像力は、1 日考えた後に Web サイトを吐き出して、それが何を思いついたのかを私に見せてくれるプログラムのアイデアが好きです。でも、1日1回、フィードバックをして学習を手伝うかもしれません。

この考えのもう 1 つの手段は、「メニュー付き Web サイト」や「画像ツール」などの高レベルの説明を提供するとよいでしょう。これにより、コード補完モジュールとして役立つ十分な深さのコードが生成され、詳細。しかし、それは非インテリジェントな静的階層コード補完スキームとして想定できると思います。

どうですか？

4

2 に答える 2

8

免責事項:私は英語を母国語とする人でも、この分野の専門家でもありません。私はアマチュアです。不正確さや誤りがあることを期待してください。したがって、stackoverflow の精神に則り、文章やコンテンツを修正および改善することを恐れないでください。また、これは自動プログラミング手法の完全な調査ではないことにも注意してください(モデル駆動型アーキテクチャ(MDA) からのコード生成(CG)については、少なくとも言及する価値があります)。

Varkhan の回答にさらに追加したいと思います (これは本質的に正しいです)。

自動プログラミングへの遺伝的プログラミング(GP) アプローチは、そのフィットネス関数と 2 つの異なる問題を混同します (「自己コンパイル」は概念的には簡単です)。

  • 自己改善/適応 - 合成されたプログラム、および必要に応じてシンセサイザー自体の。と
  • プログラム合成。

自己改善/適応に関しては、Jürgen Schmidhuber のゲーデルマシンを参照してください: (ちなみに、人工好奇心に関する彼の研究は興味深いものです。) また、この議論に関連するのはAutonomic Systemsです。

プログラム合成に関しては、確率的（確率論的-上記のGPのように）、帰納的および演繹的の3つの主要なブランチを分類できると思います。

GPは本質的に確率論的です。なぜなら、クロスオーバー、ランダム突然変異、遺伝子複製、遺伝子欠失などのヒューリスティックを使用して可能性の高いプログラムのスペースを生成するためです... (適合度関数を使用してプログラムをテストし、最適なものを生き残って再現させるよりも)。

帰納的プログラム合成は通常、帰納的プログラミング(IP)として知られており、そのサブフィールドに帰納的論理プログラミング(ILP) があります。つまり、一般に、この手法は論理プログラムの合成や論理プログラミング言語で記述されたシンセサイザに限定されません (どちらも「..自動デモンストレーションまたは言語/分類学学習」に限定されません)。

IPはしばしば決定論的です (ただし、例外もあります):不完全な仕様 (入力/出力のペアの例など) から開始し、それを使用して、そのような仕様を満たす可能性のあるプログラムの検索空間を制約し、それをテストします ( generate-and-testアプローチ）または特定の例で再発を検出するプログラムを直接合成し、それを一般化します（データ駆動型または分析的アプローチ）。全体としてのプロセスは、本質的に統計的な帰納/推論です。つまり、不完全な仕様に何を含めるかを考慮することは、無作為抽出に似ています。

生成とテストおよびデータ駆動型/分析§ アプローチは非常に高速である可能性があるため、どちらも有望ですが (これまで合成プログラムがほとんど公開されていなかったとしても)、生成とテスト(GP など) は恥ずかしいほど並列です。そして、顕著な改善 (現実的なプログラム サイズへのスケーリング) が期待できます。ただし、本質的にシーケンシャルなインクリメンタル誘導プログラミング(IIP)§ は、非インクリメンタル アプローチよりも桁違いに効果的であることが実証されていることに注意してください。

§ これらのリンクは PDF ファイルに直接リンクしています。申し訳ありませんが、アブストラクトが見つかりません。

Programming by Demonstration (PbD) とProgramming by Example (PbE) は、帰納的プログラム合成を実際に活用することが知られているエンドユーザー開発手法です。

演繹的なプログラム合成は、(推定される)完全な(正式な) 仕様 (論理条件) から始まります。手法の 1 つは、自動化された定理証明器を活用します。プログラムを合成するために、仕様を満たすオブジェクトの存在の証明を構築します。したがって、 Curry-Howard-de Bruijn 同型(プログラムとしての証明の対応と型としての式の対応) を介して、証明からプログラムを抽出します。他のバリアントには、制約解決の使用とサブルーチン ライブラリの演繹的構成が含まれます。

私の意見では、実際の帰納的合成と演繹合成は、同じ問題を 2 つの多少異なる角度から攻撃しています。なぜなら、完全な仕様を構成するものは議論の余地があるからです (さらに、今日の完全な仕様は明日には不完全になる可能性があります。世界は静的ではありません)。

これらの手法 (自己改善/適応およびプログラム合成) が成熟するとき (もし) 、宣言型プログラミングによって提供される自動化の量が増えることが約束されています (そのような設定が「プログラミング」と見なされることは時々議論されます): 私たちは集中しますソフトウェア マニュアルの設計と開発、マニュアルのデバッグ、マニュアルのシステム パフォーマンス チューニングなどよりも、ドメイン エンジニアリングと要件分析とエンジニアリングについて詳しく説明します (自己改善/適応技術ではなく、現在のマニュアルで導入されたものと比較して偶発的な複雑さが少ない可能性があります)。これにより、アジリティのレベルも向上します。現在の技術ではまだ実証されていません。

于 2009-10-16T18:17:15.550 に答える