  |
はてなキーワード: デバッグとは
今後数年間の野心的なアンホブリングはどのようなものになるのでしょうか？私が考えるに、3つの重要な要素がある：
GPT-4は、多くの人の仕事の大部分をこなせるだけの生の賢さを持っているが、それは5分前に現れたばかりの賢い新入社員のようなものだ：関連するコンテキストを持っておらず、会社のドキュメントやSlackの履歴を読んだり、チームのメンバーと会話したり、会社内部のコードベースを理解するのに時間を費やしたりしていない。賢い新入社員は、着任して5分後にはそれほど役に立たないが、1ヶ月後にはかなり役に立つ！例えば、非常に長いコンテクストを通じて、新しい人間の同僚を雇うようにモデルを「オンボード」することは可能なはずだ。これだけでも、大きなアンロックになるだろう。
2.テスト時間の計算オーバーハング（より長いホライズンの問題に対する推論／エラー訂正／システムII）
今のところ、モデルは基本的に短いタスクしかこなせない。しかし、これでは非常に限界がある。5分どころか、数時間、数日、数週間、数ヶ月かかるのだ。
難しい問題について5分間しか考えることができない科学者は、科学的なブレークスルーを起こすことはできない。ソフトウェア・エンジニアは、より大きな仕事を与えられ、計画を立て、コードベースや技術ツールの関連部分を理解し、さまざまなモジュールを書いて段階的にテストし、エラーをデバッグし、可能性のある解決策を検索し、最終的には数週間の仕事の集大成である大規模なプル・リクエストを提出する。などなど。
要するに、テスト時間の計算オーバーハングが大きいのだ。GPT-4の各トークンは、問題を考えるときの内部モノローグの言葉だと考えてください。各GPT-4トークンは非常に賢いのですが、現在のところ、思考の連鎖のために～数百トークンのオーダーしか効果的に使うことができません（あたかも問題やプロジェクトに数分しか内部独白／思考を費やせないかのように）。
もし数百万トークンを使って、本当に難しい問題や大きなプロジェクトについて考え、取り組むことができるとしたらどうだろう？
| トークンの数 | 私が何かに取り組むのに相当する時間... | |
| 100s | 数分 | ChatGPT (私たちはここにいる) |
| 1000s | 30分 | +1 OOMsテスト時間計算 |
| 10,000 回 | 半日 | +2 OOMs |
| 100,000ドル | 1週間 | +3 OOMs |
| 数百万回 | 複数月 | +4 OOMs |
人間が〜100トークン/分で考え、40時間/週働くと仮定して、「モデルが考える時間」をトークンで換算すると、与えられた問題/プロジェクトにおける人間の時間になる。
仮に「トークンあたり」の知能が同じだったとしても、頭のいい人が問題に費やす時間が数分なのか数ヶ月なのかの違いになる。あなたのことは知らないが、私が数ヶ月でできることと数分でできることは、はるかに、はるかに、はるかに多い。もしモデルに「数分ではなく、数カ月に相当する時間、何かを考え、取り組むことができる」という能力を与えることができれば、その能力は飛躍的に向上するだろう。ここには膨大なオーバーハングがある。
今のところ、モデルにはまだこれができない。最近のロング・コンテキストの進歩をもってしても、このロング・コンテキストのほとんどはトークンの消費にしか機能せず、トークンの生産には機能しない。しばらくすると、このモデルはレールから外れたり、行き詰まったりする。しばらくの間、離れて単独で問題やプロジェクトに取り組むことはまだできない。
しかし、テスト時間の計算を解除することは、単に比較的小さな「ホブリングしない」アルゴリズムの勝利の問題かもしれない。おそらく、少量のRLは、モデルがエラー訂正（「うーん、これは正しくないようだ、再確認してみよう」）を学習したり、計画を立てたり、可能性のある解を探索したりするのに役立つだろう。ある意味、モデルはすでに生の能力のほとんどを持っており、それをまとめるために、さらにいくつかのスキルを学習する必要があるだけなのだ。
要するに、私たちはモデルに、困難で見通しの長いプロジェクトを推論させるシステムIIのアウターループのようなものを教えればいいのだ。
この外側のループを教えることに成功すれば、2、3段落の短いチャットボットの答えの代わりに、モデルが問題を考え、ツールを使い、異なるアプローチを試し、研究を行い、仕事を修正し、他の人と調整し、大きなプロジェクトを一人で完成させるような、何百万もの言葉のストリーム（あなたが読むよりも早く入ってくる）を想像してみてほしい。
続き I.GPT-4からAGIへ：OOMを数える(9) https://anond.hatelabo.jp/20240605210357
私たちは今、基本的に人間のように会話できるマシンを手にしている。これが普通に思えるのは、人間の適応能力の驚くべき証であり、私たちは進歩のペースに慣れてしまったのだ。しかし、ここ数年の進歩を振り返ってみる価値はある。
GPT-4までのわずか4年間（！）で、私たちがどれほど進歩したかを思い出してほしい。
GPT-2（2019年）～未就学児："わあ、もっともらしい文章をいくつかつなげられるようになった"アンデス山脈のユニコーンについての半まとまりの物語という、とてもさくらんぼのような例文が生成され、当時は信じられないほど印象的だった。しかしGPT-2は、つまずくことなく5まで数えるのがやっとだった。記事を要約するときは、記事からランダムに3つの文章を選択するよりもかろうじて上回った。
当時、GPT-2が印象的だった例をいくつか挙げてみよう。左：GPT-2は極めて基本的な読解問題ではまあまあの結果を出している。右：選び抜かれたサンプル（10回試したうちのベスト）では、GPT-2は南北戦争についてある程度関連性のあることを述べた、半ば首尾一貫した段落を書くことができる。
https://situational-awareness.ai/wp-content/uploads/2024/06/gpt2_examples-1024x493.png
当時、GPT-2について人々が印象に残った例をいくつか挙げます。左: GPT-2は極めて基本的な読解問題でまあまあの仕事をする。右: 厳選されたサンプル（10回試したうちのベスト）では、GPT-2は南北戦争について少し関連性のあることを言う、半ば首尾一貫したパラグラフを書くことができる。
AIの能力と人間の知能を比較するのは難しく、欠陥もあるが、たとえそれが非常に不完全なものであったとしても、ここでその例えを考えることは有益だと思う。GPT-2は、その言語能力と、時折半まとまりの段落を生成したり、時折単純な事実の質問に正しく答えたりする能力で衝撃を与えた。未就学児にとっては感動的だっただろう。
GPT-3（2020年）～小学生："ワオ、いくつかの例だけで、簡単な便利なタスクができるんだ。"複数の段落に一貫性を持たせることができるようになり、文法を修正したり、ごく基本的な計算ができるようになった。例えば、GPT-3はSEOやマーケティング用の簡単なコピーを生成することができた。
https://situational-awareness.ai/wp-content/uploads/2024/06/gpt3_examples-1.png
GPT-3について、当時の人々が印象に残った例をいくつか挙げてみよう。上：簡単な指示の後、GPT-3は新しい文の中で作られた単語を使うことができる。左下：GPT-3は豊かなストーリーテリングを行ったり来たりできる。右下：GPT-3は非常に簡単なコードを生成できる。
GPT-3はSEOやマーケティング用の簡単なコピーを生成することができた。上：簡単な指示の後、GPT-3は新しい文章の中で作られた単語を使うことができる。左下：GPT-3は豊かなストーリーテリングを行ったり来たりできる。右下：GPT-3は非常に簡単なコードを生成できる。
繰り返しになるが、この比較は不完全である。しかし、GPT-3が人々に感銘を与えたのは、おそらく小学生にとって印象的だったことだろう。基本的な詩を書いたり、より豊かで首尾一貫した物語を語ったり、初歩的なコーディングを始めたり、簡単な指示やデモンストレーションからかなり確実に学習したり、などなど。
GPT-4（2023年）～賢い高校生：「かなり洗練されたコードを書くことができ、デバッグを繰り返し、複雑なテーマについて知的で洗練された文章を書くことができ、難しい高校生の競技数学を推論することができ、どんなテストでも大多数の高校生に勝っている。コードから数学、フェルミ推定まで、考え、推論することができる。GPT-4は、コードを書く手伝いから草稿の修正まで、今や私の日常業務に役立っている。
https://situational-awareness.ai/wp-content/uploads/2024/06/gpt4_examples-3.png
GPT-4がリリースされた当時、人々がGPT-4に感銘を受けた点をいくつか紹介しよう。上：GPT-4は非常に複雑なコードを書くことができ（中央のプロットを作成）、非自明な数学の問題を推論することができる。左下：AP数学の問題を解く。右下：かなり複雑なコーディング問題を解いている。GPT-4の能力に関する調査からの興味深い抜粋はこちら。
AP試験からSATに至るまで、GPT-4は大多数の高校生よりも良いスコアを出している。
もちろん、GPT-4でもまだ多少ばらつきがある。ある課題では賢い高校生よりはるかに優れているが、別の課題ではまだできないこともある。とはいえ、これらの限界のほとんどは、後で詳しく説明するように、モデルがまだ不自由であることが明らかなことに起因していると私は考えがちだ。たとえモデルがまだ人為的な制約を受けていたとしても、生のインテリジェンスは（ほとんど）そこにある。
https://situational-awareness.ai/wp-content/uploads/2024/06/timeline-1024x354.png
続き I.GPT-4からAGIへ：OOMを数える (3) https://anond.hatelabo.jp/20240605204704
飲み屋でビール片手に、後輩に語りかける感じで話すよ。今日は、AIがどれだけプログラマーに影響を与えてるか、特にChatGPTについて話そうと思うんだ。
まず、ChatGPTってのはすごいよ。俺たちが昔必死に学んだことを、秒で答えちゃうんだから。でも、だからって俺たちプログラマーが完全に不要になるわけじゃないんだ。実際、ChatGPTが得意なのは単純で定型的なタスクなんだよ。例えば、基本的なデータ処理スクリプトとか、テンプレートベースのコード生成、単純なデバッグやエラーハンドリング、そしてドキュメント作成なんかはChatGPTに任せられる。
じゃあ、俺たちプログラマーの役割はどうなるかって？もっと高度な問題解決とか創造性が求められるようになるんだよ。複雑なシステムの設計や高度なアルゴリズムの開発は、やっぱり人間の得意分野だ。ChatGPTにはまだそこまでの理解力や創造性はないからね。
でも、これまでインターンやジュニアプログラマーがやってきた基本的な作業がChatGPTに取って代わられると、彼らが経験を積む場所がなくなるんじゃないかって心配もあるよな。これにはどう対処すればいいか？
まず、教育の場を再定義する必要がある。メンター制度を強化して、シニアプログラマーが直接ジュニアを指導するのがいいだろう。リアルなプロジェクトに参加させて、実際の問題解決を体験させるんだ。ChatGPTはサポートツールとして使えばいい。例えば、基礎的な質問にはChatGPTが答えて、シニアはより複雑な問題や高度な質問に対応する。
次に、ソフトスキルの育成も重要だ。チームでのコミュニケーション能力やコラボレーションスキルを磨く機会を増やすんだ。ペアプログラミングやコードレビューを通じて、実際に協力して問題を解決する力をつけることが大切だ。
それに加えて、高度な技術トレーニングも必要だ。オンラインコースや社内ワークショップを活用して、最新技術を学ぶ機会を提供するんだ。ジュニアプログラマーが自分で学び続ける意欲を持つようにサポートするんだよ。
シニアプログラマーやメンターには、新しいスキルセットが求められるようになる。技術的な専門知識はもちろん、教育能力やフィードバックの提供方法、対話スキル、プロジェクト管理能力、そしてモチベーションを高める力が必要になるんだ。俺たち自身も常に学び続け、適応し続ける必要がある。
だから、ChatGPTが登場したからといってプログラマーが不要になるわけじゃない。むしろ、俺たちの役割はさらに重要になる。AIと共存し、お互いの強みを活かしながら、より高度なスキルを身につけていく必要があるんだよ。
未来のプログラミングの姿は、AIと人間が協力し合うことで成り立つ。新しい技術を学び続け、常に自己研鑽を怠らずにいれば、どんな時代でも必要とされるプログラマーでいられるはずだ。AIをうまく活用しながら、俺たちの強みを最大限に発揮していこうぜ。
多数決原理が機能するのはコミュニケーションがないときだからなぁ。
目の前に飛び出してきた子どもを避けて、横断歩道を渡る弱者男性を轢き殺すか、ハンドルを切らずそのまま子どもに当たるかを選ぶ究極の二択を迫られたとき、三体のAIの多数決ならば、あとから反省できる。
しかし、密結合になった巨大なAIが意思決定した場合、デバッグは不可能だ。
信用できるか？ 目の前に妊婦が飛び出してきたときはどうする？ ネコだったら？ シチュエーションを全て網羅して人間がチェックするなら、それはもう生成AIじゃない。エキスパートシステムだ。
ひたすら並べられたif文の条件式を応用したものに過ぎないそれは、AI 黎明期の未熟な試作品。
そこまで退化させることになってしまう。
anond:20240427075724へのアンサー
8:00 起床。フルリモートなのでこれで間に合う。二日酔いで気持ち悪いのでとりあえず茶だけ飲んで、いますよアピールのためにTeamsを立ち上げる。
8:30 気持ちが悪い。メールとチャットで爆弾回ってきてないのだけ確認。
9:00 スタンドアップ（毎朝定例）ミーティング。頭回らないので自分が何言ってるかよくわからないがとりあえず1分話してお茶を濁す。
10:00 QA(テストの人)が俺が新規に書いたコードが動かないと言ってくる。30分くらいデバッグしたら超初歩的なタイポ（打ち間違い）だった。ため息つきながら、バグだったよグッドジョブ！と空元気でチャットして一行直してまた上げる。
12:00 お昼休み、というのは無い。アメリカ人マトモに昼飯食わない。昨日の残りのカチカチのピザを齧る。ここから動かない頭でコーディング。
13:30 どういう仕様で動くのか問い合わせがくる。それはお前が俺に教えるものなのだが。仕方ないので2年前に俺が勘で書いた仕様書をコピペして送る。
14:00 まだだるいので風呂に入る。そういう時に限ってチャットがくる。スマホの防水偉い。
18:00 いつ終われば良いのかわからないからラップトップ開けたまま飲み始める。
20:00 酔っ払ったままプロダクション（本番環境）にコードをあげる。8PMに働くとか最初言ってなかったですよね。
これで貯まるのは年200万くらい
⚫︎2. 技術的なこと
コミュニケーション力とか地頭とかふんわりしたこと言われるけど、もう少し具体的に言語化したらこんな感じになるんだと思う。
エンジニアとしての身内からの評価が高いのはデバッグ能力とか設計能力とかだけど、結局マネジメントからの評価だったり社会人としての評価は年収に関係あるのは前半に書いてあるような技術とは直接関係ない能力だったりする。
テスト対象は大小さまざま。OSの保守だったり、アプリだったり。レガシーだったり、モダンだったり。個人だったりチームだったり。GUIだったりCUIだったり。
GでもCでもUIはまた別
結論としては書かないほうがいいと思った。
そういうこともある
全然小さいというか書くためと変更のコストがクソデカなら何か間違ってる
結局、テスト対象も変わってしまうし、プロジェクト設定も変わるし、Jenkinsも変わるし、人間の頭の中も変えないといけない。
まあそれはないだろう
それはデバッグの一環のような
一番よくあるやつ
そこのバランス考えないと
バックエンドのビジネスロジックを担当するがっちり仕様が決まっていて勝手に変更されてはいけないものなんかをやる
悪いね
テストコードを書くと、テストしやすいクラスの実装をするようになる。それは美徳とされているが、実際には直感的でない長くて複雑なプログラムになっている。
例えばテストコードを書くためにDependency Injectionとか言って外から内部を変更できるようにすると
メンバ関数でやるべき処理が実際にはクラスの外にある、となる。最初は面白く感じたり達成感があるかもしれないが、しばらくして見返すと酷い状態だ。
DIはSOLIDに入ってるくらいで基本だし今時のフレームワークなら普通に使うよね
上にも書いたけどパーツがでかいのでは？って「直感的でない長くて複雑なプログラムになっている」とのことなのでやっぱりでかいんだろう
テストコードを書いたほうが早い時もあったけど、トータルで考えれば、テストコードを完全にやめたほうがシンプルなコードで早く完成する。
要件が固まらない、毎週変わるようなのとか、システムが絡むテストでコストが凄く高いもの、UIのマイナーな変更なんかは書かない方がいいけど
バックエンドのビジネスロジックなど書いた方が絶対にいいものもある
ネット上ではテストコードを書かないのは低レベルな開発者という風潮だ。
10年以上、テストコードを書く開発と書かない開発の両方を経験してきた。
■前提
・テスト対象は大小さまざま。OSの保守だったり、アプリだったり。レガシーだったり、モダンだったり。個人だったりチームだったり。GUIだったりCUIだったり。
結論としては書かないほうがいいと思った。
・テストを書くためのコストが小さいなんて妄想もいいところだ。クソデカである。
結局、テスト対象も変わってしまうし、プロジェクト設定も変わるし、Jenkinsも変わるし、人間の頭の中も変えないといけない。
・100人以上かかわる巨大プロジェクトでも「テストコードを書かなかったので破綻した」、とかはなかった。
・テストコードを書くと実装の見落としが見つかってありがたいことはあった。
・git pushするたびに毎回走っても全くの無意味だった。
・テスト対象が変わるとテストを書き直さないといけないのがサイアクだった。非効率化の極みだ。人生の無駄。
・その次にサイアクだったのは、テストコードの実行が失敗したときテストコードのバグであることが大半であったことだ。
・GUIソフトとテストコードは相性が悪いが、そもそも世の中のソフトウェア開発の大半はGUI開発である。
・テストコードを書くと、テストしやすいクラスの実装をするようになる。それは美徳とされているが、実際には直感的でない長くて複雑なプログラムになっている。
例えばテストコードを書くためにDependency Injectionとか言って外から内部を変更できるようにすると
メンバ関数でやるべき処理が実際にはクラスの外にある、となる。最初は面白く感じたり達成感があるかもしれないが、しばらくして見返すと酷い状態だ。
テストコードを書いたほうが早い時もあったけど、トータルで考えれば、テストコードを完全にやめたほうがシンプルなコードで早く完成する。
