-
-
AIスタートアップのCognitionは自立型のAIソフトウェアエンジニア、デイビンを発表しました。
デイビンは、人間が課題を与えると、自立的に情報を参照し、コーディングやデバッグ、デプロイを行い、システム構築を実現するAIソフトウェアエンジニアだと説明されています。
デイビンは人間のソフトウェアエンジニアと同様に、自身のコンソール画面、コードエディター、ウェブブラウザを持っています。
スピーカー 2
人間がプロンプトで何らかの課題を与えると、まず課題解決のためのプランを作成します。
今回デイビンは必要とするAPIの情報をウェブブラウザで参照し、情報を利用して開発を進めます。
作業の途中でエラーが出力されると、デイビンは必ずしそうなコードの場所にデバッグ用のプリント分を挿入し、出力された内容からエラーの原因を探ります。
デイビンは出力されたプリント分によるログからのエラー原因を分析し、自立的にデバッグを行います。
最終的にデイビンはビルドデプロイを行い、課題に対応したウェブサイトを作成しました。
同社によると、実世界のソフトウェアの課題に関する大規模言語モデルを評価するためのベンチマークであるリアルワールドソフトウェアエンジニアリングパフォーマンスで、デイビンは他を圧倒する成績を示したといいます。
別のデモ動画では、デイビンに大規模言語モデルを量子化により効率よくファインチューニングするクローラーを使って、LMAのファインチューニングを依頼。
デイビンはクローラーのGitHubリプトルをクローンし、Readmeを読んで、Pythonのパッケージ管理システムであるPipを使って環境を構築。
実行時にクーダ関連のエラーが起きると、NVIDIAの環境を再インストールするのとして問題は解決し、問題なくファインチューニングが完了する様子が映されています。
デイビンを発表したブログ、Introducing Debian the First AISoftware Engineerには、その他デイビンによるライフゲームの機能拡張、テストコードの作成など、デイビンによる自律的なシステム構築やプログラミングの様子が紹介されています。
デモ動画の通りであれば、少なくとも初級プログラマーよりもずっと優れているように見えるのではないでしょうか。
現時点では、デイビンはアーリーアクセス版となっており、興味ある人はWaitlistからの申し込みが必要です。
先日、GitHub Copilot Workspaceの話をしました。
今までのGitHub Copilotよりも賢くソフトウェアコーディングを手伝ってくれたりとか、GitHubのリポジトリ画面上でいろんなことを問い合わせたりということができるようになります。
スピーカー 2
話していたんですけれども、こちらはどちらかというと、もっとコード開発を依頼できますよというような話です。
このような1つ依頼するとタスクを分解してそれぞれ実行してくれるというのは今までも実はあって、
エージェントとかそういった形で呼ばれている生成AIのアルゴリズムというか依頼の仕方としてあったんですけれども、
スピーカー 2
そのエージェントのところで一番問題となっていたのが、結局今何やっているかが分からない問題ですね。
賢くやってくれるのはいいんだけど、その賢さというのがどういうふうに考えて何をやってくれているのかが分からないから、
仕事を発注した上司としてはほうれん草を断る部下は不安になるというようなことが起きちゃうんですけれども、
このDevinであれば何をやろうとしているのかというタスク分解とそれを今どこまでクリアしていて、
今どんな操作をしているのか、ブラザーで何調べたりしているのかといったような、
そういったアクションをすべて確認することができるので、依頼した側として何か不安に関したりとか、
こういうことをやっているんだなというのが分かった上で作業をお願いできるので、
そういった何だろうな、可視性の点で今までのエージェントとは違う領域に踏み込んでいるなといったところで紹介になります。
スピーカー 1
なんか素人目で見てだいぶいいですねという感じで、何がいいって、マジでその可視性。
人間がやっていることを手順を追ってやってくれるということがまさに素晴らしいなという感じですね。
かつ自律的にプログラミング生成してくれるっていう意味でも、今まで聞いてきた規模が大きくなるとなかなか難しいみたいな、
AI系を使うのは難しいみたいなところにも対応できそうな形がデモだとそう見えるので、かなり素晴らしいんじゃないかなという感じですね。
今までのAIだったら、多分この空打関連のエラーでNVIDIAの環境再インストールというところまでやってくれないと思うので、
そういう意味でかなり強力なんじゃないかなと思います。
そうですね、おっしゃる通りで、今まではタスクの分解しましたまでは言ってくれるんですけど、
スピーカー 2
そのタスクを実行中です、こうでした、実行中です、こうでしたみたいなのがCLI上で返ってくるだけで、
結局その途中でどんなことをやって何がダメだったのかみたいなのが細かく分からないから、
それってこうじゃないですか、解決してくださいみたいなやり取りしても無限ループに陥ったりとかしてしまいますし、
おっしゃるような環境構築のための追加のインストールなんてことは当然やってくれないので、
永遠と解決しない状態を続けてしまうみたいなことが起きて、
そうするとエージェントを使っている理由がなくなるというか、
エージェントのための環境構築を人間がやるみたいになるとマジで何やっているか分からなくなってくるので、
スピーカー 2
結局お任せできないとあんまり意味がないなという感覚があったんですが、
今回のこれではそこまでやってくれると。
こういう勝手にソルする系も一応あったのはあったんですけど、
それで逆に問題になるのが、ビジネスで使おうとすると、
やっていいことか悪いことかっていうのが会社の基準によって違うので、
本当に無邪気に何でもかんでもネットから引っ張って落とそうとしてこられると、
IT部的に怒られるっていう問題もあって、勝手にそういうツールはインストールできないみたいな話ですね。
とかもあるので、こういった形で何をやるのかっていうのがちゃんと表示しているものっていうのは、
非常に自分が支持している管理者であるということを維持するためには重要なのかなと思いますね。
スピーカー 1
確かに、そこ結構会社で使うときには大変そうですねという感じで、
権限をこいつに付与してしまっていいのかという話もちょっとありそうだなと思いますね。
権限っていうのは、ソフトウェアインストール権限っていうことは、
かなり高位の権限をソフトウェア、何か知らんけど自律的に動くソフトウェアに、
付与してしまうという話なので、ワンチャンウイルスとかが入れられてしまう可能性もあると。
スピーカー 2
そうですね。
そこら辺、ログが出るのはいいですけど、
スピーカー 1
そういう目で見るとかなりどうなんでしょうね。
今ウイルス入ってるみたいな状況になったらどうすればいいんですかねっていう感じもせんでもないですけど、
スピーカー 1
そこら辺も含めてうまく制御できるといいのかな。
スピーカー 2
そうですね。だからその辺がどれくらいデミンとのコミュニケーションの中でやれるかどうかかなと思ってて、
新人が入ってきたときと一緒だと思うんですよ。
ブログ記事でこれ入れろって書いてあったから入れようと思うんですけど、いいですか?聞いてくる部下か、
ブログに書いてあったんで勝手に進めてましたって言ってる部下かみたいな話で、
後者の部下の方が扱いとしては楽というか、そこまで自分で調べてやってくれたんだ、ありがとうになるんだけど、
実はその調べた際とかすごく古くて危ないことをやってたっていうことは全然あるわけで、
それって誰が責任見るんですかって言ったら、多分指示出した人というよりは、
その新人が動かしてるパソコンを管理してるIT部が責任を取ったりとか、
社内のプロ記事使ってるから安全だよねっていうことにするとか、
別のところでチェックをかけるとかにしてると思っていて、
それと同じレベルのチェック機構で十分かどうかっていう見極みになってくるのかなっていう感じですかね。
スピーカー 1
打ち上げシステムとしてもスターシップの名称で呼ばれています。
スペースXによれば両段を再利用する構成では
100から150トンのペイロードを打ち上げることが可能であり
2段目のスターシップ宇宙船は
単体でも地球上の2点間を1時間以内に結ぶ純軌道飛行が可能だとされています。
これまでに2回行われたスターシップ打ち上げシステム飛行試験は
スーパーヘビーを分離したスターシップ宇宙船は
高度100kmを超えて宇宙空間へ到達した後、
最終的にハワイ沖の太平洋へ発射90分後に着水する計画の下で行われました。
第1回飛行試験ではスーパーヘビーの分離前にコントロールが失われたため
スターシップ宇宙船とスーパーヘビー双方の
飛行中断システムが作動して機体は分解し
飛行試験は発射4分後に終了しました。
続く第2回飛行試験はスーパーヘビーを分離する直前に
スターシップ宇宙船のエンジンを点火するホットステージングを採用した初の飛行となりました。
スターシップ宇宙船はスーパーヘビーの分離に初めて成功して宇宙空間に到達しましたが
余剰分の液体酸素を放出したところ機体後部で火災が発生し
機体に搭載されているコンピューター間の通信が失われたため
高度約150kmで飛行中断システムが作動し
約8分後に飛行試験は終了しました。
また分離後のスーパーヘビーは機体を減速させるためのエンジン再始動に問題が生じ
発射約3分半後に分解して飛行を終えています。
ここから今回の話なんですけども
3月14日にスターベースの発射台から打ち上げられたスーパーシップは
スーパーヘビーに搭載されている33機のラプターエンジンによって朝の空へと上昇し
発射約2分50秒後にはホットステージングが実行されて
スターシップ宇宙船とスターヘビーが分離されました。
スーパーヘビーのエンジンは前回に続き燃焼終了まで全て稼働することに成功しています。
スピーカー 1
分離後のスーパーヘビーは計画通り13機のエンジンを再始動して減速し
着水に向けてメキシコ湾へと落下
SpaceXによると着水時に機体を減速させるためのエンジン再始動にも初めて成功したものの
発射約7分後に高度462mで機体が分解して飛行を終えました。
一方スターシップ宇宙船は発射約8分35秒後に高度約150kmでエンジン燃焼を停止し
スターシップとして初めて上昇飛行を完了した機体となりました。
最大高度234kmの準軌道飛行中に予定されていた各種テストのうち
スピーカー 1
ペイロードドア開閉と推進材移送のデモンストレーションを実施されましたが
機体の回転率を理由にラプターエンジンの再始動テストは行われませんでした。
発射約46分後スターシップ宇宙船は高度約100kmを下回って大気圏再突入を開始しました。
今回の試験飛行ではスターシップ宇宙船に取り付けられたカメラの映像が
SpaceXの衛星インターネットサービススターリンク経由で送信されており
再突入時の断熱圧縮によって機体周辺の大気がプラザマ化しているドラマチックな映像がライブ配信されました。
大気圏再突入時のスターシップ宇宙船は耐熱タイルが貼り付けられている機体の片面を進行方向へ向けることになっていますが
今回の試験飛行では機体の姿勢が安定せずに回転し続けている様子をカメラの映像が見逃していました。
SpaceXによるとスターリンク経由のテレメトリー信号は発射約49分後に最後に凍結しており
スターシップ宇宙船は再突入中に失われたとみられています。
今後の展望も書かれているんですけども
ざっくり今後アルテミスのミッションとかに使われる予定で
この大気圏再突入後に再利用するということが計画されたのでそこが今後の課題感ですねということが言われています。
スピーカー 1
単価の推進単位数を満たすためにはさらに10機以上のスターシップ宇宙船を打ち上げられなければいけないので
そこにたどり着けるかが大きな期待が寄せられていますということが書かれています。
スペースXさんは本当この映像コンテンツを出せるのが強いですよね。
スピーカー 1
そうですね。まじでドラマチックなのでこれはちょっと見てほしいなという感じなんですけども。
スピーカー 2
そうですね。この後も話出てくると思いますけど先日カイロさんの打ち上げを見たばっかりだったんで
まず大きさの差が凄まじいということで度肝を抜かされるというか
こんな巨大なものが打ち上がる、まっすぐ打ち上がって大気圏まで行けるだけで本当にすごいというか
それの実績が積み重なっているあたりが日本がやっていることとは比較にならないほどすごいなというのが思うところですけれども
その後のホットステージでしたっけ?
スピーカー 1
はい。
スピーカー 2
もうなかなか凄まじいことをやっているなと思っていて
その1段目と2段目の切り離しの時に切り離したものを捨てるんだったら分かるやり方だと思うんですが