将来の展望として両氏は、「モデルが数兆のトークンにアクセスできるようになり、インターネット全体や個人の情報に基づいて、より高度なタスクを実行できるようになる」「AIがコード生成やテストの実行を支援することでソフトウェア開発が劇的に効率化される」「モデルが継続的に学習し、改善していく」「検索などの手法を取り入れるなど推論の際に多くのステップを踏むことでモデルの性能が向上する」といった点を掲げています。
Googleに約25年務める開発者が「どうやってGoogleは汎用人工知能(AGI)を達成しようと計画しているのか」について語る - GIGAZINE
そのためにGoogleは、TPUなどのハードウェア開発を通じて、大規模言語モデルのトレーニングと推論を加速させることに注力しています。また、「1ビット」といった低精度の数値表現を使用することで、計算効率を高めることにも取り組んでいます。
Googleに約25年務める開発者が「どうやってGoogleは汎用人工知能(AGI)を達成しようと計画しているのか」について語る - GIGAZINE
ディーン氏とシェイザー氏は、「現代のAIモデルは依然としてハルシネーションなどの問題を抱えており、改善の余地があります。こうした安全対策などを講じることで、将来的にAIが教育や医療などの分野で社会に大きな利益をもたらすことを期待しています」と語りました。
Googleに約25年務める開発者が「どうやってGoogleは汎用人工知能(AGI)を達成しようと計画しているのか」について語る - GIGAZINE
SF小説やSF映画では、よくAIが自己複製してさまざまな機器やシステムを乗っ取り、暴走して制御不能になったり人類に対して一斉蜂起したりする様子が描かれます。広く使われているオープンソースの大規模言語モデル(LLM)を使った研究により、AIは既に人間の指示や操作を受けることなく自己複製できるようになった可能性があることがわかりました。
ついにAIが「自己複製」できるようになったと研究者が主張、スイッチを切られる前に自分のレプリカを作ってシャットダウンを回避 - GIGAZINE
中国にある復旦大学の研究グループによると、AIが人間の指図なしで自己複製を成功させるのは、AIが人間を出し抜くのに不可欠な能力であると同時に、人間の制御から逸脱した「ローグAI(不正AI)」の早期的な兆候だとのこと。そのため、自己複製はAIシステムの数少ない「レッドライン・リスク」、つまり越えてはならない一線のひとつとみなされています。
ついにAIが「自己複製」できるようになったと研究者が主張、スイッチを切られる前に自分のレプリカを作ってシャットダウンを回避 - GIGAZINE
⇧「幻覚（ハルシネーション）」の問題は改善されないのに、課題は増えていきますと...
現状、全くの指示なしで動き出すことが可能になるリスクがどれほどあるのかは分かりませんが、映画「ターミネーター」の世界線に近付いているんですかね？
そろそろ、
ロボット工学三原則（ロボットこうがくさんげんそく、英語: Three Laws of Robotics）とは、SF作家アイザック・アシモフのSF小説において、ロボットが従うべきとして示された原則である。ロボット三原則とも言われる。「人間への安全性、命令への服従、自己防衛」を目的とする3つの原則から成る。アシモフの小説に登場するロボットは常にこの原則に従おうとするが、各原則の優先順位や解釈によって一見不合理な行動をとり、その謎解きが作品の主題となっている。
本原則は後の作品に影響を与えたのに加え、単なるSFの小道具にとどまらず現実のロボット工学にも影響を与えた。
⇧ 何某かの制御を検討した方が良い段階に来ているんですかね？
GitHubの認証方法
公式のドキュメントによりますと、
⇧ 上記にあるように、様々な認証方法が用意されているのだが、人手による認証情報の入力を介さない方法としては、
がありますと。
GitHubのDeploy keysは公開鍵認証で、GitHub Appsはトークンベース認証
で、「GitHub」の「REST API」のドキュメントの目次を見ていて、
⇧ サポートされているのが「トークンベース認証」ですと。
で、「Deploy keys（デプロイキー）」についてのドキュメントの目次を見ると、
⇧ とあり、「公開鍵認証」っぽいですと。
仮に、「GitHub」に対して認証の処理が必要なサーバーが1000台あった場合（「Gitリポジトリ」も1000個あるものとする）、
- Deploy keys（デプロイキー）
→ 秘密キーの作成は1000回 ※1 - GitHub Apps
→ 秘密キーの作成は1回
※1 サーバーでSSHキーペアを作成する必要があるので、サーバー毎に秘密キーを作成する場合は、サーバー1000台あるのでSSHキーペアの作成は1000回必要。
という差異が出てきますと。
「Deploy keys（デプロイキー）」だと「公開鍵」も「Gitリポジトリ」の数だけ登録する必要が出てくるようなので、管理する「Gitリポジトリ」の数が多いと大変になってきそう...
で、実際の認証処理についても、「Deploy keys（デプロイキー）」は「公開鍵認証」になることから、「GitHub」の用意している「REST API」を実行できないので（「GitHub」の「REST API」のドキュメントによると「トークンベース認証」のみサポート）、
⇧ 上記サイト様にありますように、「SSHキーペア」の内の「秘密キー」を指定する必要がありますと。
「GitHub App」の「トークンベース認証」も「秘密キー」を利用して「認証用トークン」を生成しているのだが、「GitHub App」は複数の「Gitリポジトリ」を管理できるので、「SSHキーペア」の作成が1回で済むということですな。
ちなみに、
⇧ 1つの「GitHub App」で管理できる「Gitリポジトリ」の数について上限などの明記がドキュメントに見当たらないので、「REST API」の「レート制限」を考慮しないのであれば、実質無制限ということになると思われる。
「SSHキーペア」の作成が1回で済むと言ったのは、そういったことに由る。
流石に、「SSHキーペア」の作成を何度も実施したくは無いと思われるので、「Deploy keys（デプロイキー）」は管理する「Gitリポジトリ」の数が少ない時に採用する方式になるんですかね？
毎度モヤモヤ感が半端ない…
今回はこのへんで。
