化学者は汚れた物質を純粋な方法で研究し、物理学は汚れた方法で純粋な物質を研究し、 物理化学は汚れた方法で汚れた物質を研究すると言うのが好きです。 伝統的に人工知能に関連する領域またはそれらに関連する領域（パターン認識、NP困難問題の解決、ワードプロセッシングなど）では、ほとんどのタスクが汚れています。 つまり 正式な説明を十分に受け入れられず、ソリューションの正確性に関する明確な基準がない。 化学者がどうやって出て行くのか私にはわかりませんし、プログラマーはそのような問題を汚さずに解決することはめったにありません。 汚いタスクのプログラミングも汚いです。ここで汚いということは悪いことではありません。 この記事は、清潔で無菌状態を保つ方法についてではありません。 この記事は、 そのため、複雑な動作を示すシステムを開発する必要があるとします（たとえば、祖母を道路に通したり、エキゾチックな方法で画像内のテキストを認識したりする）。 タスクが十分に汚れていないように思われる場合は、作業システムを作成し、作業の品質を可能な限り改善してから、さらに改善してください。 パフォーマンスが低下しない場合、理想的には-改善された場合に推奨されます。
科学には多くのオタクがいますか？
不完全に形式化された種類の複雑な問題を解決する方法については、2つの根強い神話があります。
神話1.数学の大きな力。
複雑な問題の世界では、すべてが数学の強力なハリケーンによって考慮されているというのは一般的な誤解です。 多くの人の見方では、AIのような問題の解決に関与するプログラマーは、スレートボードの背後でほとんどすべての時間を費やし、猛烈な曲線積分を解く白衣の卵頭の科学者です。 数学的方法は、おもしろい場合には非常に便利ですが、イライラするほど限られた範囲しか持っていないので、急いでいます。 むしろ、正しいアプローチは、最先端の科学のサブタスクを分離し、それらのソリューションをシステムの個別のコンポーネントとして使用することです。
たとえば、単純な場合、オブジェクトのクラスタリングの問題はよく研究されています。 それらをグループに分割し、確率論/数学統計の基礎に基づく方法が、スレートボード上で魅力的に見える式が見つかる解決策のために開発されました。 同じ理論的基盤の上に、最近有望で集中的に研究された複雑なシステムを構築するための最近の方法論、 ベイジアンネットワークがあります 。 しかし、一般に、数学的な歯車はあまりにも美しく、互いにぴったりとフィットしているため、それらが入った大きな土塊から詰まることはありません。 遅かれ早かれ、ローブを脱いで静かなオフィスを離れる必要があります。
神話2.すべてがビッグニューラルネットワークによって決定される
適切なレイヤー数とそのアーキテクチャを選択するだけです。 将来的には、ネットワークのトレーニングのみが残り、賢明なシナプス自体がTrue Pathを示します。 遺伝的アルゴリズムが代替手段として提供されることもあります。それらには内部に思想家もいると考えられています。 ここでの状況は、数学について言われたことに非常に似ています。 はい、限られた場合にこれらの方法は役立ちますが、一般的には万能薬ではありません。 ニューラルネットワークのセットアップは、いまだに苦痛であり、必要であれば芸術でもあります。 もう1つの問題は、最終的にブラックボックスに非常によく似たものになり、その動作が予測または変更されることが深刻な問題になることです。 もちろん、動作の変更が必要になります。「美しい」アプローチの基本的な制限は、それらがすべてかなりの仮定に依存しすぎていることです。 たとえば、 分類問題の場合、仮定は、オブジェクトの多くの特徴が混合ガウス分布に従う、またはこれらの特徴が互いに独立しているという事実から成ります。 ニューラルネットワークの場合、特徴が少なくともほぼ線形に分離可能であれば素晴らしいでしょう。 最悪の場合、 暗黙的に定義された空間ではありますが 、 別の記号を線形に分離できるようにします 。
実生活では、何らかの理由で、オブジェクトは実際に私たちの話を聞きたくなく、常に何らかの方法で割り当てられた制限を超えています。 理論的な美しさを過酷な現実に適応させるために、非常に激しく脳を緊張させ、システムを苦痛に調整するか、選択した解法を修正する必要があります。 そして、最初の前提が継ぎ目で割れ始めると、あなたは長年の苦しみのシステムに愛されているネイティブの人を捨て、競争的なアプローチに頼らなければなりません。
発見的プログラミング
現実を明らかにするとき、少しの血液で新しい条件に適応することが可能であるということを何らかの形で達成する必要があることがわかります。 現実を表現し、プロセッサの命令でこの現実を表示するには、表現力豊かな言語が必要です。 残念なことに、この目的に対して汎用プログラミング言語ほど柔軟で効率的なものはまだありません。 したがって、コードを記述する必要があります。
したがって、開発の特定の段階で、本当に汚いタスクを解決するプログラムは、実際には汎用プログラミング言語で書かれたエキスパートシステムに変わります（専門言語でうまくいくことができれば、用語の古典的な意味でのエキスパートシステムについて話しますが、推論の本質はこれは変わりません）。 このようなプログラムの不可欠な機能-エキスパートシステムは、コードで明示的に表現される豊富なヒューリスティックです。 ヒューリスティックとは、if（word.LettersCount（）> = 4）{...}のような科学的妥当性の観点から疑わしいアクション、ルール、および基準です。 プログラムの一部は、ヒューリスティックで構成されており、それ自体が次のレベルのヒューリスティックであり、システム全体のレベルまで同様です。 このようなコードは、変数、メソッド、およびクラスの名前によって簡単に認識できます。 あらゆる種類のsuspiciousImage、looksLikeTable（）、GoodTextExtractor。 コメントも記載されています。
« : », « , »
。
ヒューリスティックを書くことは、珍しいように思えるかもしれませんが、魅力的な活動であり、興味深い芸術です。 文字がほぼ正方形であるという事実を発見し、これを使用して、画像内の暗い部分の高さに基づいてテキストのギャップの幅を推定します（幅は文字の間よりも線の内側に接着されることが多いため、幅を取ることの信頼性は低くなります）。 汚いですね。
この記事の残りの部分では、プログラミングに適用される「ヒューリスティック」と「ダーティ」という特性を同じ意味で使用します。
生きる
複雑な特定の段階では、システムを記述する最良の方法はシステム自体です。 自然界では、非常に複雑なシステムの例で十分です：経済学、ゲノム、生物群集。 プログラミングにおいても、ヒューリスティックプログラミングの場合、コントロールの喪失感、特に明るい感覚があります。
画像を分析し、画像、テキスト、表などを表示するシステムを作成するとします。 特定のオブジェクトがテキストであるという確実性の尺度を考慮したヒューリスティックを使用することは理にかなっています。 したがって、 分類子が必要です。 分類子を作成するタスクが十分に研究されていることは素晴らしいことです。 問題は、彼の作品の品質の基準として何をとるかです。 常識では、実際の画像のデータベースを作成する必要があり、正しく分類されたオブジェクトの大部分と、それに応じて誤検出のごく一部が必要であると言われています。 分類器が生きている大規模なシステムで使用される場合、すべてがそれほど単純ではありません。 分類器の品質を改善すると、システム全体の品質が悪化することがわかります。
これはどのように起こりますか？ おそらく、画像でよく見られる特定の種類のフォントの分類が大幅に改善されました。これは、まれなフォントの分類がわずかに劣化したためです。 問題は、これらのまれなフォントがヘッダーでより頻繁に使用されることです。 また、見出しのテキストは、ページ全体のテキストよりもはるかに小さいため、システムが分類子の1つのエラーを識別して修正することはより困難になります。 さらに、ヘッダーは異常に大きくなる可能性があるため、画像と間違われる可能性が高くなります。 その結果、分類器の変更による弱いマイナスの影響は、強いプラスの影響を上回ります。 分類器の品質の基準を複雑にする必要があることがわかりましたか？ 一般的な場合、システムコンポーネントの作業品質の最も単純な基準は、システム全体の品質であることがわかります。
状況は進化ゲノムと非常に似ています。 特定の遺伝子が抽象的な推論に基づいて有害であるかどうかを調べることは意味がありません。 遺伝子が生存する可能性を高めるかどうかは重要です。 プログラムでは、ゲノムのように、複雑で重要なヒューリスティック/遺伝子相互作用が必然的に発生します。 最初の血液型が存在すると、コレラになる可能性が高くなるが、マラリアに対する感受性は低下することが知られています。 したがって、血液型遺伝子のセットの有用性は、その人の居住地に依存します。 ヒューリスティックなソフトウェアシステムでは、奇妙で予想外の依存関係が遍在しています。
そのため、システムは恐ろしく複雑になります。 それをそのまま受け入れ、進化がゲノムで行われるように、一般的な有用性の原則に従って排他的に開発する誘惑があります。 地球規模の数十億年の在庫とリソースがある場合、このアプローチは非常に適切であり、記事の第2部は読むことができません。 複雑さの成長を何らかの形で克服する方法があるかどうかは、単なる人間にとって興味深いかもしれません。 簡単な答え：普遍的なレシピはありませんが、試してみる必要があります。 より詳細な議論は第2部にあります。
ドミトリー・リュバルスキー（現在はアブレ： MityaLsky ）
技術開発局
UPD from 0:42 05/31/2012： 2番目の部分が表示されました 。