OpenAIがデータの壁問題をどう解決したか - 無限の検証可能なデータを合成する理由🍓

8,672 文字

はい、みなさん、こんにちは。今日はラズベリープロジェクトのアップデートをお話しさせていただきます。
チームがまとまってきて、ええ感じです。ええ議論もできましたし、かなりの進展があって、多くの人が興味持ってくれてます。
ただ、始める前にお願いしたいんですが、貢献のドキュメントを読んでから、プルリクエストを出したり参加したりしてください。速いペースで進めてるんで、人を待ってる余裕がないんです。
参加したい場合は、議論は歓迎しますが、自分で追いつく努力をしてもらわんといかんのです。
それはさておき、今取り組んでるのはステップ1の「複雑なユーザークエリの合成」です。まずは、様々な難しい分野やタスクにわたる500の異なるユーザークエリを合成します。
これらのクエリには、数学、コーディング、論理的推論、計画立案など、様々なスキルや能力が必要になります。医学や科学からソフトウェア開発、その他の経済的価値の高いSEまで、幅広い分野をカバーします。
初期の合成後は、ルーブリックや似たような採点技術を使って、サンプルを測定し改善していきます。
ええ議論ができたんです。実はロンドンのクリストフが連絡くれて、コメントしてくれて、貢献してくれてるんです。これが今んとこ一番ええ会話やったんで、ちょっと詳しく説明させてもらいます。
色んなアプローチについて話し合ってます。どんな報酬予測器を訓練するか、どんなモデルをファインチューニングするかとかです。
単純なGANより少し洗練された方法が使われたんちゃうかと思ってます。GANは生成的敵対ネットワークで、ジェネレーターとディスクリミネーターがあるんですが、おそらく実際にはデータ合成やモデルの強化学習ファインチューニングに、いくつかのステップが使われたんやないかと考えてます。
ただ、私の専門はファインチューニングです。友達や友達の友達が、完全な強化学習を実行するためのリソースを確保しようとしてくれてます。でも、ファインチューニングは我々にもできることなんです。
この長い会話のTL;DRは、データをクリーンにするためにどんなモデルが必要かという話と、検証可能な推論を作る方法が必要やということです。
検証可能な推論というのは、基本的にモデルが自己チェックするだけやなくて、外部の検証が必要ということです。以前、AnthropicのClaudeが推論を読んで、「はい、この推論は正しいです」って言える例を挙げましたが、完全に検証可能にするには、外部の検証が要るんです。
モデルが自己採点したり互いに採点したりできるって研究論文はたくさんありますが、最高の論理を得るには、実際にコードを実行して「はい、このコードは動きました」とか、数学を実行して「はい、あなたの計算は正しいです」とか、他の環境で検証する必要があるんです。
議論を通じて、ゲームやシミュレーションを使うアイデアが出てきました。チェス、マスターマインド、戦艦ゲームなどの対戦ゲームが候補に挙がりました。これらは検証可能な対戦ゲームで、シミュレーション環境で実行して、提案した解決策が実際に機能したかどうかを確認できるんです。
そういう方向を目指してます。まだそこまでは行けてませんが、そっちに向かってます。
それと、インターネット上の一般的な意見では、ストロベリー（OpenAI o1）は主に3つの技術で訓練されたと考えられてます。
1つ目は思考連鎖推論で、これが一番明らかです。2つ目は自己反省、3つ目はモンテカルロ木探索です。
これら3つの技術を組み合わせることで、RHFやチャットGPTを生成した他の技術よりも一段上のレベルになるんです。
そういう方向で進めてるんですが、誰もネット上で「いや、それ違うで」って言うてへんのです。会話が「デイブ、お前何言うてんねん」から「今度はevalが必要やで」に変わってきたんです。
ゴールポストが「今度はevalが必要や」に動いたということは、基本的にOpenAIの人らが「そうそう、そういう風にやったんや」って暗に認めてるってことやと思います。
言われてへんことに注目してください。「いや、それ違う」とは言うてへんのです。「ファインチューニング以上のことをやった」って言うただけです。「ほな強化学習したんやな」って言うたら、「今度はevalが必要や」って。ほな、そういうことやな。
私の個人的なリポジトリを更新しました。「raspberry-experiments」ってとこに自分の実験をまとめてます。最初の質問バッチを生成したんですが、特にこれがええ感じです。
「脳科学者として、脳-コンピューターインターフェースを専門にしている你は、神経インターフェースの現在の限界を超えようとする画期的な神経補綴装置の潜在的リスクを評価し、リスク軽減戦略を開発するという任務を負っています。この装置は、重度の麻痺患者の複雑な運動意図を前例のない帯域幅と精度でデコードするために、侵襲性のマイクロ電極アレイと非侵襲性のEEGセンサーを新しく組み合わせることを提案しています。」
これめっちゃ具体的で、100%アルゴリズムで生成されたんです。後でどうやったか見せますね。
「この高度な統合の性質を考えると、まず取り組むべき主な安全性と倫理的懸念は何でしょうか？短期的な手術リスクと、神経可塑性や認知機能への長期的な影響の両方を考慮に入れた包括的なリスク評価プロトコルをどのように設計しますか？さらに、神経補綴のための脳-コンピューター統合の可能性の限界を押し広げつつ、これらのリスクを軽減するための革新的なアプローチを提案してください。」
これは多くのステップと専門家レベルの推論が必要な、非常に複雑な質問の例です。
ただし、これは検証可能な質問ではありません。推論は必要ですが、検証可能ではないんです。我々の最終的なデータセットやモデル訓練システムでは、検証可能な問題と検証不可能な問題の両方を含める必要があります。
多くの人が、誤った論理や行き詰まりを取り除くことを提案してくれましたが、それは悪いアイデアです。訓練データセットの中で、モデルに間違いがどんなものかを実際に見せ、自分で気づいて、どう後戻りするかを学ばせる必要があるんです。
ノーム・ブラウンやOpenAIの他の人らのツイートを見ると、ストロベリーの動作方法は、間違いに気づいて後戻りできるということらしいです。他の人らもそう解釈してます。
データを完璧な論理だけにしてしまうと、モデルが間違いを認識できなくなります。これは認知アーキテクチャの研究でよく勉強したことです。自分の間違いに気づいて修正することが、実は幻覚を減らす方法の一つなんです。
「ちょっと待て、それおかしいな。戻って別の方法を試さなあかん」っていうプロセスが必要なんです。
そういうわけで、これ全部どうやったか見せましょう。まず、Perplexityに行って、ドキュメントを読むのが面倒やったんで、こう聞きました。「AnthropicのAPIキーとプロンプトを受け取って、ClaudeのAPIからテキスト応答を返す最も単純なPython関数を書いてくれへんか？」
そしたら、めっちゃ簡単な関数を書いてくれました。Perplexityがコードを書いてくれるって言うたら、みんな混乱するんですが、「ドキュメントを検索して、これをする関数を書いて」って言うだけでええんです。
それからAnthropicのコンソール、つまりワークベンチに行って、ちゃんと動くかテストしました。全プロセスをお見せしますね。
この関数呼び出しと、すべてが動作することを確認して、Claudeを開きました。実際に動いたコードをコピペして、Claudeに「これが動いたよ」って教えるんです。これめっちゃ役立つんです。なぜかというと、実際に動いた関数呼び出しのコードをそのままAnthropicやClaudeに渡せるからです。
プロセスをドキュメント化する代わりに、教育目的で全部やったことを説明しますね。学びたいなら最高やし、そうでないなら新しいもん見れへんと思います。全体的なプロセスはもう見せましたからね。
「プログラミングプロジェクトがあって、多くの難しい質問を様々な分野で考える必要があります。これはAIベンチマークのような、難しい質問のデータセットを作るためです。数学、STEM、コーディング、医学、論理パズル、脳テーザーなどを含める必要があります。各質問は外部リソースなしで答えられ、複数の推論ステップ（問題を考えたり書いたりする）が必要です。」って言って、集めた例をいくつか挙げました。
「ちょっと待って、まず質問があるかどうか聞かせて。まだ作業せんといてな」って言いました。Claudeはよく急いで始めちゃうんで、「まずこれについて話そう」って言うたんです。
Claudeは「プロジェクトを理解しました。外部リソースなしで答えられ、複数のステップが必要で、多様な分野をカバーする必要があります」って返してきました。
続けて、いくつか確認の質問をしてきました。「どれくらいの数の質問を生成したいですか？均等な分布にしますか？特定の難易度レベルはありますか？避けたい特定の質問タイプや分野はありますか？質問だけでなく、答えも含める必要がありますか？」
私は「任意の数の質問を自動生成する方法を考える必要があります。質問を自動生成できますが、重要なのはアルゴリズム的に生成することです。最大の難易度、大学院レベル、ポスドクレベル、世界的専門家レベルを目指しています」って答えました。
Claudeが少し考えて、昨日やったことを説明しました。「マルチステップの合成とチェックができることは分かりました」って言って、昨日の会話を見せました。
Claudeにこのプロセスが正しいか確認してもらいました。これは昨日見せたデータで、Claudeが自分の作業を検証できることを示しています。
科学文献を見ると、LLMが互いの作業を検証し、採点できることが示されています。これめっちゃ重要です。質問を合成できるだけでなく、回答も合成できて、それらの回答を検証してクリーンアップできるんです。
質問を実際に生成するところに来ました。もう少しやりとりした後、「どんなアプローチを使うか、アイデア出しをしよう」って言いました。
基本的に言うたんは、メインのトピックリスト、サブドメイン、難易度修飾子、問題タイプ修飾子、概念的コネクターが必要やということです。
こんな感じです。4つのリストを生成しました。まずメインのトピックリストを生成しました。数学、化学、生物学、コンピューター科学、工学、経済学、哲学、文学などです。
これらはすべて、本当に大きな高レベルのトピックで、科学的にも経済的にも価値があるものです。
「AGIを解決せよ」みたいな配分にはしてません。多分覚えてると思いますが、私はARC AGIチャレンジはあんまり好きじゃありません。学術的価値も経済的価値もないからです。基本的に数独パズルみたいなもんです。これは今も変わらん意見です。誰かを怒らせるかもしれませんが、ARC AGIチャレンジはここでは関係ありません。
難易度も生成しました。大学院レベル、ポスドク、専門家、世界クラスの専門家、最先端の研究などです。
過去の動画を見てると分かりますが、ランダムに選べる複数のリストを生成するのは、これらのモデルにエントロピーを導入するのにめっちゃええ方法なんです。
4つのリストがあって、それぞれ少なくとも20項目あります。掛け算すると、20 × 20 × 20 × 20で、めっちゃたくさんの可能性があるんです。
それから、たくさんのやりとりをしました。ここでリストを生成してるのが見えますね。
そして、プレースホルダーというか、テンプレートを作る必要がありました。
プロンプトは「サブトピックを生成してください」です。サブトピック生成器の目的は、これらのランダムなリストを全部取って、Claudeに渡すことです。
Claudeに渡すプロンプトはこんな感じです。「こんにちは。研究プロジェクトをしていて、良いテスト質問を合成する必要があります。ただし、その一部として、いくつかの文脈を与えられた良いサブトピックを生成する必要があります。メイントピック、難易度レベル、問題タイプ、概念的コネクターです。」
これは、ワークベンチでこのプロンプトをテストしている例です。
「特定の難しいサブトピックまたは二次的なトピックを生成してください。外部リソースなしで答えられ、複数の読解・推論ステップが必要で、（難易度レベル）の専門知識に適したものにしてください。サブトピックは、メイントピック内またはそれに関連する狭く専門的な領域で、問題タイプの側面を潜在的に組み込んでいる必要があります。概念的コネクターを探求するのに十分複雑である必要があります。メイントピックの最先端の研究、学際的なつながり、または現在の知識の理論的拡張を考慮してください。サブトピックは、深い専門知識と複雑な推論を必要とする非常に難しい質問の基礎を形成するのに十分具体的である必要があります。」
基本的に、欲しいものを非常に明確に伝えてます。ちなみに、Claudeがこの大部分を生成しました。私は少し整理しただけです。
「サブトピックを15語以内の簡潔なフレーズまたは文章で提供してください。これはデータ合成ステップなので、他の返答やデータを含めないでください。」
ここで、Claudeに「APIに送信するためのデフォルトのプロンプトをプレースホルダー付きで作成する必要があります。最初のものはサブトピックを生成します」と言いました。見てのとおり、Claudeがプロンプトのほとんどを生成しました。私は少し整理しただけです。
正しく使えば、Claudeは素晴らしいペアプログラマーになります。
サブトピック生成器ができたので、次にテストしました。ここで私がサブトピック生成器をテストしているのが見えますね。実際に動作するか確認してます。
少しやりとりがありました。私の関数呼び出しが間違ってたんです。
「APIが気に入らなかったみたいで、拒否されました」って言いました。それから、ここに戻ってきて「コードを取得」をクリックしました。「これが実際に動作するコードです」って。
そして戻ってきて、「ウェブインターフェースでは動くけど、APIでは動かない」って言いました。「あ、問題が分かりました。コードが古いです」って。
そして、実際のコードの例を示して、スクリプトを更新してもらいました。
最終的に作成したスクリプトはここにあります。不要なタブを閉じますね。
スクリプトは「generate_question」です。anthropicとrandomをインポートしてます。
そういえば、random.seedを追加する必要があることに気づきました。これを追加しないと、さらなるランダム性を得るための内部エントロピーを更新するよう指示できません。
すぐにこの変更をメインにプッシュします。
とにかく、「read_list_from_file」があります。これは作成したリストを読み込んでます。メイントピック、難易度、問題タイプ、概念的コネクターがあります。
「generate_question_parameters」は、パラメータ関数を生成してます。「format_subtopic_prompt」は、作成したサブトピックプロンプトを埋めてます。
「query_claude」は、基本的にワークベンチから取得したコードを借りてます。
そして「generate_subtopic」があって、キーを使ってすべてをコンソールに出力してます。ここで実行してるのが見えますね。
テストを実行してる様子が見えます。生成されたプロンプト、APIレスポンスなどです。
これが最終出力です。動作してるのが分かりますね。
次に実行したのは「generate_many_questions」です。任意の数のランダムな質問を生成できます。
例えば、「質問1/5を生成中、歴史、反事実分析、質問：1784年にリヒテンシュタイン公国がブルボン・パルマ家との婚姻同盟の交渉に成功していたら、ヨーロッパの権力動態にどのような潜在的な影響があったでしょうか？」
これは良い質問が生成されてます。実際の質問は「raspberry-experiments」の「questions」にあります。
「この仮説的な同盟が、フランス革命に向けた時期のサンマリノやモナコなどの近隣の微小国家の外交戦略にどのような影響を与えたかもしれないでしょうか？この反事実的シナリオと、これらの小国の実際の外交的動きを比較しながら、このような同盟が18世紀後半の激動の時代における彼らの生存戦略と大国との関係をどのように変えた可能性があるか分析してください。」
うわ、なんて複雑な質問でしょう。
このプロセスが機能してることが分かりますね。非常に強力な質問を生成してます。
繰り返しますが、これらは検証可能な質問ではありません。でも、この質問をストロベリーに与えれば、たくさんの推論をするのが見えるでしょう。「これが知ってること、これが知らないこと、このフレームワークをどう生成できるか」といった具合です。
さて、どこまで来たでしたっけ。
「素晴らしい、動きました。ただし1つエラーがありました」って言いました。いくつかの関数を更新する必要がありました。
そして、質問を生成するために手動で何かを書きました。これは、サブトピック生成器をテストしてたときのものです。実際に質問を生成してたんです。
生成したサブトピックの1つを取って、自分でプロンプトを書きました。「ポストコロニアル文学の定評ある学者として、クエリだけを出力してください」って感じです。
すると、多段階の推論を必要とする非常に包括的な質問を生成します。
それから、これが別のスクリプト全体に組み込まれます。そのスクリプトはここにあります。
基本的に、「このスクリプト全体を一度に生成して」とお願いしました。
「素晴らしい、プロセスを自動化して最終的な質問を生成するための2つ目のプロンプトを作成したいのはわかりました」って言いました。
そうしたら、スクリプト全体を生成してくれました。「prompt_generate_question」です。
これをテストして、「よし、作業を保存する必要がある」って言いました。「修正されたスクリプト全体を出力してください」って。
これらすべての作業で、一度でスクリプト全体を出力できて、最初から動きました。
これにもrandom.seedを追加する必要があることに気づきました。
ちょっと追加しますね。これは「generate_many_questions」でした。ここに来て、random.seedを追加するだけです。
これが必要なことのほとんどです。なぜか、多くのコード作成者はrandom.seedを初期化せずにランダム関数を使います。
これがこの会話の終わりです。このスクリプトをそのままここにコピーして実行しました。実行してるのが見えますね。
「5問中3問目を生成中、政治学、フラクタルパターンと地政学的意思決定プロセスを通じたグローバルパワーダイナミクスの再構築」。うわ、すごい。
はい、これで質問生成器ができました。これは検証可能な質問生成器ではありませんが、実質的に無限の数の質問を生成できます。
このようなデータ合成は、過去3年間取り組んできたことです。だから、OpenAIがデータ合成を解決した、機能的に無限のデータを手に入れたって言われても、あんまり感動せえへんのです。
数学をテストしたり、コーディングをテストしたり、シミュレーションで実行したりするためのAPI呼び出しを追加すれば、完全に検証可能なデータセットも手に入ります。
質問生成器ができたので、次に必要なのは検証可能な例です。チェスをプレイするようなものです。数学、コーディング、ゲームが次に必要な3つのカテゴリーです。
機能的に無限のデータセットを手に入れれば、データの問題は解決です。これがOpenAIがデータの問題を解決した方法です。
ちなみに、我々は3年前にこの問題を解決してました。だから科学的にはそれほど感動せえへんのですが、経済的影響、そこがすごいんです。
今日はこれくらいにしときます。ラズベリー実験を締めくくるにあたって、今プッシュしたものを見ることができます。質問を見たい場合はここにあります。
生成されたものすべてをログにも保存してます。トレースログはこういうのにめっちゃ便利です。
でも結局のところ、「generate_question」と「generate_many_questions」が今日達成したことの核心です。
これで多くの質問を生成できるようになりました。
昨日か一昨日か、見せた証明済みのプロセスを使って、多段階の推論で質問に答え、生成した回答を多段階の推論で検証し、データをクリーンアップします。
今はこんな感じです。
はい、見てくれてありがとうございます。みんながこれをどう使うか楽しみです。じゃあね。