AGIのアラインメントには大幅な開発時間が加わる

定義

投票対象の命題は、次の二つについて、合理的に達成可能な開発経路を比較したときに真となる。

• プロジェクト経路1：責任あるプロジェクトが作る、アラインされた 高度なAI。可能なところでは急ぐが、成功確率を25%より高く保てるだけの慎重さは維持する。
• プロジェクト経路2：可能な限り手順を省くプロジェクトが生み出す、アラインされていない無制限の超知能

それ以外については、両プロジェクトがAGI能力分野の同じアイデアや発見と同程度の計算資源を利用できるものとする。以上のすべての仮定で条件づけた後、既定・通常・最頻の事例として、次が成り立つ。

プロジェクト経路1の完了には、プロジェクト経路2より少なくとも50%長い逐次時間、または2年長い時間の、いずれか短いほうが必要となる。

目的

このページは、私の理解が正しければ、直交性テーゼは受け入れたように見えるが、アラインされていないAGIよりアラインされたAGIの開発に大幅に長い時間がかかることは依然としてほぼ信じていない、複数の質問者に答えるために書かれた。

現在、このページは意見が食い違いうる箇所の概観であり、後に全面的ではなく選択的に詳述されるかもしれない。

論拠

関連する命題

この命題の前提となる命題には次が含まれる。

• （1a）価値の複雑性（最小限の決定的タスクに適用した場合さえ）
• （1b）（狭い）価値学習のためのメタ規則は、いまだ未解決である

質問者がこのいずれかの否定を信じるなら、無制限の超知能に適した意思決定関数を容易に指定できることを意味する。そうであれば、たとえば次の必要性を大幅に減らせる。

• （2a）非敵対的な設計
• （2b）最小限の設計
• （2c）AGIの能力の制限
• （2d）最上位の選好（およびAGI内でのそれらの選好の実際の有効性）以外の設計面について、理解可能な設計または透明な要素

時間を要するこれらの開発原則のいずれかが、価値アラインメントは必要であり、自明には解けないという基本的な考えから導かれる重要な原則ではないように質問者には見えるのか、確かめる価値がある。

外部視点

私の知る限り、次のどれか一つに対する最低限の要求と強い要求を比べたとき、開発時間が少なくとも50%増える必要があるのは、普通・通常・驚くに値しないことである。

• （3a）何らかの種類の安全性
• （3b）事前に試験できない、一度限りの新しい状況における堅牢な振る舞い
• （3c）強い力を受けるときの堅牢な振る舞い
• （3d）一度の破局的失敗を確実に回避すること
• （3e）システムに異例な実行経路を通らせうる強い最適化圧力に直面した際の回復力
• （3f）利用者が望むシステムの振る舞いの複雑な細部への適合

私には明白に思える類例には次がある。

• 打ち上げ後には修正できない宇宙探査機を打ち上げること。通常は、事前の格別な追加確認と試験が求められる行為である。
• 最も単純な実用航空機の製造と比べ、異例に大きな加速度と力を受ける、最も単純な実用ロケットを打ち上げること。
• 「ロケットが爆発する」ことが問題でなければ、ロケットの設計ははるかに安く済む。ロケットの費用の大半は、ロケットを爆発させないための費用である。
• NASAは、一行当たり100倍の費用をかけ、システムのあらゆる側面と要素について複数回のレビューと慎重な組織的承認を伴う手段を使い、一部のプロジェクトでほぼ完全にバグのないコードを書くことに成功した。
• 安全なオペレーティングシステムを作るOpenBSDプロジェクトは、より大規模なLinuxプロジェクトよりコードを最小限に制約する必要があり、コードの各要素を承認するために、おそらく一機能点当たり50%をはるかに超える時間を加えた。
• 安全だと思う暗号化システムを書く素人の努力と、チャネルの安全性を保証しようとする暗号学のエコシステムの努力との差。
• 病院設備の安全性にかかる真の割増費用は、官僚的な割増分とは別に考えても、おそらくなお50%を超える。患者を死なせないために、正当な追加試験を実際に伴うからである。
• 10%の確率で死なせても構わない大型植物に、同程度に複雑な手術を施す場合と比べ、外科医が人間を手術するには、正当な理由で少なくとも50%長い時間が必要だろう。
• 規制上の負担が一切なくても、石炭火力発電所と比べ、通常は炉心溶融しない原子力発電所を建設するほうが、正当な意味で難しいように思える（ソ連の経験で確認できるだろうか）。

（3*）の性質について最低限の要求ではなく強い要求を課すシステムが、追加の開発時間を通常必要とする標準的な理由には、次がある。

• （4a）次のための追加作業。
  • 丸ごと追加されるモジュール
  • 普遍的に強制される性質
  • 多数の小さな局所的機能点
• （4b）複雑な目標へ適合させるため、より長期の対話的な形づくり過程を必要とすること
• （4c）アイデア、変更、コミットを承認するため、正当な理由で組織内の経路が長くなること
• （4d）システム全体、局所部品、機能点に対する、より長く深い試験段階
• （4e）高速または容易な解決策を導入できないこと（ロケットの爆発を懸念する必要がなければ、特定の選択時点で使えたはずの解決策）

AI問題についての外部視点

私にとって関連を感じる別の参照クラスは、AIに関係することは予想より難しい場合が多い、というものである。たとえばコンピュータービジョンが、夏の間に取り組む課題として学部生2人へ割り当てられた逸話がある。これは、「補正されていない直観には、AIに関係するものの実装に必要な作業量を過小評価する方向の偏りがあり、見積もりを上方修正してその方向性の偏りを補正すべきである」という主張の、関連する実例に思える。

十分に高度な汎用人工知能があれば、コンピュータービジョン程度の狭い問題は、いわば無料で得られるかもしれない。しかし直交性の要点そのものが、汎用知能を得てもAIアラインメントは無料では得られないということである。同じく、価値を帯びた概念の特定や、価値を帯びた振る舞いの実行は、自然な経験的概念の特定と一緒に無料で得られるものではない。アラインメントのためには、別個の基礎的AI研究を行う必要がある。したがって、まだ誰も問題に直面していなかった初期に狭いAI問題を過小評価したこととの類推は、いまも関連するように思える。

内部視点

100%理解されていない新しいシステムを構築し、それを機能させることは可能だが、成功した設計は通常、大幅な過剰設計になっていた。一部のローマ橋は2000年後の今日まで立っている。これはおそらく設計要件にはなく、その意味で橋は結果的に極端な過剰設計だったが、彼らを責めることはできない。「優れた工学を要するのは、ぎりぎり立ち続ける橋を架けることである」。

余分な部分や問題のない、正確に正しいAGIを構築する方法について本当に深い理解を持たずに、アラインされたタスクAGIを目指すとする――比較的短い時間尺度を伴うシナリオでは、その理解は必ず欠けているはずである――。その場合、生き残る可能性を少しでも得るには、多数の安全対策を行わなければならない。システムのどの部分が危うく失敗しかけるか、事前には分からないからである。スペースシャトルのOリングが突如として予想外の振る舞いをする部分だとは事前に分からず、工程のその部分だけを強化するために追加の努力を注ぐことはできない。結局はそれほど「過剰設計」でなかったと判明する少数の側面を確実に捉えるため、すべてを過剰設計しなければならない。

これは、以下に挙げる私の具体的な細目一覧を信じないとしても、この問題を通り抜ける者は、最終的に生き残るという条件の下では、費用のかかる予防策を含む何らかの予防策一覧を携えて現れることを示唆する。そして彼らは、「最低限必要な」予防策で生き残れるとは（正しくも）考えないだろう。

必要になりうると私が想像する、具体的な追加時間コストには次がある。

• AGIが内部最適化を適用できるのは、自らのうち、比較的安全で、完全な理解が不可欠ではないほど小さい部分だけである。
  • 言い換えれば、手順を省くプロジェクトならAGIがさらに自己改善することで得られる機能を、慎重なプログラマーは一般に追加作業によって得なければならない。
• 真の価値アラインメントに関するすべては、追加の機能点一式である（AIが報酬ボタンを持つことや、何らかのチャネル上の「命令に従う」ことを強化訓練されることとは異なる）。
• 透明性と監視のために、システムの新しい部分を構築する必要がある。
  • たとえば、「最初のAIを検査して問題を確認するために構築した、こちらのやや独立したAIが実際にある。安全性に関する概念については、この別のAIを異なるデータで訓練する」といった、費用はかかるが重要な考えも含む。
• その機能点における透明性や明示可能性の要件を満たさないため、巨大なディープネットをただ放り込むことはできない、信頼される機能点が多数ある。
• 誰かが新しい最適化用の仕掛けを提案すると、たとえば上から下まで貫くタスク性の要件を満たすように作り直さなければならず、何らかの形で世界を爆発させないか全員が注視しなければならない。
• コードについてAmazonを信用せず、AIをインターネットと因果的に近接させたくないため、AWS上でジョブを実行できない。
• システム設計の一部は、すべての「重大な」出来事が監視され、目に見えない出来事はすべて「軽微」であることを前提とし、監視される重大な出来事は人間参加型の過程を通る。その人間が律速要因となるので、その過程の「レバーを最大まで押し上げる」ことはできない。
  • たとえば「重大な」目標だけが、既知のすべての領域にまたがって下位目標を動員でき、「軽微な」目標は常に、限られた認知資源を使って単一の領域内で動作するのかもしれない。
• 導入には、「Xを行った後、何が起こると予想するか？」についてAIとの長い対話が必要であり、その対話中にほかのプログラマーはAIを減速させ、AIの内的思考についての受動的に透明な解釈を調べる。
• プロジェクトが、「待て、いったい今何が起きたんだ。再び動くように見えるまで別のパッチを試すだけでなく、止まって根本的に作り直す必要がある」と判断するしきい値は、はるかに低い。
• 優良なプロジェクトは、おそらくほんの少し多く試験をする。

上の具体的な一覧とは独立に、これは結論がEliezer特有の細部へ大きく依存する事例だとは思えない。AIをアラインする具体的な計画を持つ者は誰でも、安全のための計画や手法の一覧を携えてくる。その一部は各部の入念な検査を必要とし、許容できる設計を制約し、端的に多くの作業を要する。重要なアイデアの一つが必要な作業量を500%増やす、または深いAI問題を解く必要があると判明するだろうが、それも彼らにとって驚きではないだろう。

メタ視点

直交性と、アラインメントが完全に自明ではないことを認めたうえで、「ほかの条件が同じなら、アラインメントには少なくとも50%多い時間がかかる」を受け入れる妨げとなる反論が何なのか、私には心から少し想像しにくい。議論がこの特定の段階で行き詰まるとは予想していなかった。私は何か基本的な前提を見落としているのか、質問者の主張全体を誤解しているのだろうか。

私が誤解していない、または私の耳に聞こえたままの主張を額面どおり考えるなら、「アラインメントにはおそらくそれほど長くかからない」という判断は、私が認知的現実主義の基本原則だと考えるものを無視することでしか生まれないと想像する。心理分析の危険はあるが、あえて共有しすぎるため、何が欠けている必要があると私に感じられるかを述べる。

• （5a）あるプロジェクトについて直観的に楽観していても、すぐには明らかでない困難に遭遇すると事前に予想すべきである。明日の驚きが、好ましいものより不快なものである可能性のほうがはるかに高い心境にいてはならない。これは予測可能な更新だからである。希望に満ちたソフトウェアプロジェクトには2週間より長くかかると告げる者が、何らかの特定の遅延が起こると事前に認めさせるため、あなたを論証で説得する必要があってはならない。「楽観バイアスの標準的な補正」という通常の技能が適用されていないように感じられる。
• （5b）これは「ソフトウェア開発プロジェクト」ではなく「未来的なシナリオ」という心的な箱へ入れられ、悲観的な未来対通常の未来、といった形で処理されているのかもしれないと感じる。そうではなく、「ソフトウェアプロジェクトのあらゆる側面に影響し、高水準の信頼性で実装する必要がある、ミッションクリティカルで深い機能をプロジェクト管理者へ依頼した場合、その機能を排除し、あらゆる手順を省くプロジェクトよりわずか10%長い時間で実現できるだろうか」と考えるべきである。
• （5c）同様に、学生が「すべてが合理的に可能な限りうまく進む」「最良の場合」のシナリオを挙げるか、「平均的な場合」のシナリオを挙げた昔の実験を思い出す。二通りの聞き出し方は区別できない結果を生み、現実は通常、「最悪の場合」のシナリオよりわずかに悪かった。必要なAIアラインメント作業の「通常の場合」が、「最良の場合／個々の出来事すべてが、既定で私の想像どおりうまく進む場合」とほぼ同じ線に沿って評価されているのではないかと思う。

AIアラインメントは理論上容易でも、実際には開発時間が50%多くかかりうる。極めて新規なソフトウェアが、事前に完全には試験できない新条件下で初めて実行されるとき、「容易な」性質を実際に実装するよう保証せよと誰かがプロジェクト管理者に求めたなら、それはごく普通に起こることである。

「アラインされたAIプロジェクトには、手順を省くプロジェクトより少なくとも50%多い開発時間がかかる。ただし、それ以外では両プロジェクトが同じ一連のアイデア、手法、計算資源を利用できると仮定する」は、採用すべき極めて確からしく普通の作業前提に思える。私は何を見落としているのか。