世界を動かす技術を、日本語で。

古い研究アイデアに関する自己調査

概要

  • Autoresearch は、LLMエージェントを活用した自動研究最適化ループの実践記録。
  • Claude Codeを使い、eCLIPの旧研究コードを新しいデータセットで自動実験。
  • Ukiyo-eVG データセットを用い、ヒートマップによる注目領域の制御。
  • 42回の実験で 評価指標(Mean Rank)を大幅改善
  • LLMの限界やサンドボックス運用の重要性も明らかに。

Autoresearchによる自動研究実験の試み

  • Autoresearch は、LLMエージェントを中心としたシンプルな制約付き最適化ループ
  • エージェントは train.py を逐次修正し、 program.md の指示に従い評価指標を改善
  • ワーキングメモリとして scratchpad.md を追加し、思考過程や実験履歴を記録
  • 探索フェーズ を明確に分け、ハイパーパラメータ調整→小規模アーキテクチャ変更→大胆なアイデアへと段階的に展開
  • 最終フェーズではウェブアクセスを許可し、論文検索や新規アイデア探索も実施

実験のワークフローとサンドボックス化

  • 仮説立案→編集→学習→評価→コミットorリバート→繰り返し のタイトなループ
  • 1実験あたり約5分で完結、迅速な試行錯誤とノイズへの過学習防止を両立
  • セキュリティ対策として コンテナ化+ネットワーク遮断、編集可能ファイルも厳格に限定
  • run.sh による実験オーケストレーション、直接的なPython実行やpip install、git push等は禁止

データセットとモデル構成

  • 元論文の医療X線データが未入手のため、 Ukiyo-eVG (約1.1万枚の浮世絵+フレーズ→バウンディングボックスアノテーション)を採用
  • バウンディングボックスをガウスヒートマップ化し、 eCLIP の注目機構を模倣
  • モデル構成: ViT-Small(22M)+DistilBERT(66M)+HeatmapProcessor、約90Mパラメータ
  • 学習ステップ:800(1実験あたり約3分、RTX 4090使用)
  • 評価指標: Mean Rank (主要)、 Recall@K (サニティチェック)

Claude Codeの活躍と評価指標の変遷

  • Claude Codeが Python環境のアップグレード、データセット取込、実験ループ構築 を自動化
  • CV分割、評価ロジック、program.mdの初期案 も整備
  • 評価指標は Mean Rank (直感的で変化が分かりやすい)が、後から考えるとMedian Rankの方が頑健
  • ベースライン:Val mean rank 344.68、img→txt R@1 17.2%、txt→img R@1 16.5%

実験結果と改善内容

  • 1日で 42回の実験(13コミット、29リバート) を実施
  • Mean Rankは344.68→157.43(54%削減) へ大幅改善
  • 最終的なテストセットでのスコアもバリデーションより良好
  • 最大の改善要因 :温度パラメータのクランプ解除(−113 Mean Rank)、コードのバグ修正
  • ハイパーパラメータ最適化(Optuna++) でさらに−30 Mean Rank
  • アーキテクチャ変更や大胆なアイデア(Phase 4, 5)はほぼ効果なし、成功率が低下

LLMエージェントの限界と運用上の注意

  • フェーズ後半では 仮説の成功率が低下、新規性の高い変更はほぼ不発
  • Claude Codeが サンドボックス権限を忘れる ・bashコマンドを誤発行する等の挙動も観察
  • 完全な自律運用はまだ難しく、 人間の監督が必須

考察と今後の展望

  • LLMを用いた自動研究は 明確な探索空間とコミットorリバートループ があれば非常に効果的
  • 未知の領域や複雑な最適化には 計画フェーズやサブエージェントの導入 が有効かもしれない
  • しかし、1日の実験としては十分な成果であり、 人間とLLMの協調作業の可能性 を実感

謝辞・参考情報

  • Ukiyo-eVG :CIGAr論文(ECCV 2024 VISART)より、浮世絵とバウンディングボックスアノテーション
  • Autoresearch :Andrej Karpathyによるオリジナルアイデア

Hackerたちの意見

そうなんだ…ちゃんと機能したんだね。彼が知らなかったバグを見つけて、彼がやってなかった最適化もしてくれた。

僕が理解した限りでは、あまりそうでもないかな。ほとんどの成果はバグを修正したり、Optunaでハイパーパラメータを調整することから来ていて、これはすでにかなり自動的なはずなんだ(試したい値のリストを設定すれば、あとはおしまい)。シンプルなClaudeコードのセッションで数分で修正できると思う。僕にとって、Autoresearchの主な価値は、さまざまなアーキテクチャを試すことだと思う。何を選ぶべきかを知るのは時々難しいから、いい概要を提供してくれるかもしれない。誰か探究的モデリングに使った人いる?

LLMを使って過去のアイデアを探ったり、問題を考える別の方法を見つけたりすることが多いよ。言ってしまえば、90%は技術的な理由で自分の分野には役に立たないことばかりだけど、残りの10%は良い情報で、新しいことを学ぶのに役立ってる。LLMチャットボットが勧めたことを全部試すなんて考えられないな($$$)。よく出てくるおすすめには、メンテナンスが悪いニッチなライブラリが多くて、内容はたくさん書かれてるけど、実際の生産環境では使い道が限られてるんじゃないかと思う。一方で、リーダーシップの耳元で同じくらいおかしな提案をしてるドメイン専門の「コンサルタント」もいるから、そいつらをエージェントが占めてくれたら、私たちは平和に仕事できるかもね。

エージェントがLLMチャットボットが勧めたことを全部試す($$$) それが高いかどうかによるよね。私はちょっとした気まぐれでClaude Codeを使うけど、Maxプランではトークンが切れることはほとんどないよ。

LLMは、覚えるのが面倒なワンライナーや、間違ってても大丈夫なことを再現するのに役立つと思ってる。MCPサーバーやAGENTS.mdなどを設定するのに多くの時間とエネルギーを使ってる人たちには、LLMがAIブースターによって売られているようには機能しないってことを示してると思う。目標を達成するには極端な指導が必要だし、果たしてそれができるかどうかも怪しい。この技術に価値がないって言ってるわけじゃないよ。特定の状況では明らかに役立つけど、OpenAIやAnthropic、Perplexityが売ってるものとは違うし、実際のユースケースには持続可能なビジネスモデルがないと思う。自分のワークフローに合わせてLLMを調整して成功させるためにエネルギーを使う人たちは素晴らしいけど、これがスケールするのか?大規模なトレーニングやインフラを支えるために大量のお金がないとどうなるのか?このお金がなければ、実際の価値提案は何になるの?

主な価値は、あなたが働いていない間(寝ている時や他の活動をしている時)にエージェントがいろいろ試せることだと思う。たとえ多くのテストが役に立たなくても、たくさんの試行を重ねることで、あなたの手を煩わせずに何か良いものを見つけられるかもしれない。もちろん、単一のテストが比較的早く終わる場合に限るけど。私の仕事では、単一のテストに半日かかることもあるから、エージェントに一晩中無駄なテストをさせるのは避けたいな。

メインリンクが反応しない場合はこれを試してみて - https://archive.is/6xLiU

「エージェントは基本的な推論が組み込まれたハイパーパラメータ最適化アルゴリズムのように振る舞った。」いい視点だね。自動研究リポジトリの要は基本的に一つのファイル - program.md で、要約すると「これをループでやる:train.pyを改善して、トレーニングを実行し、評価を行い、結果を記録する。シンプルさを優先する」って感じ。その他のファイルは、訓練中の任意のMLモデルだよ。

うん、コミットログを見てみたけど[1]、「ムーンショットアイデア」の実装がどうなってるかに興味があったんだ。基本的には全部ハイパーパラメータの調整ばかりだね。いいことだけど、トークンにかけたお金には見合わないかも。何か見落としてるかな? [1] https://github.com/ykumards/eCLIP/commits/main/autoresearch

オートリサーチの指示を変更して、まず計算コストを厳密に見積もってから、人間のレビュー用に提案を整理・比較するのが賢いと思う。それに、実際に実行した試みごとにLoRaアダプターで計算コストをフィードバックするのもありかも。つまり、オートリサーチに最小限の変更を加えることで、コスト効率の良い研究ができるようになるかもしれないね。

Optunaやskoptはオープンソースで、GPUの時間を全く使わずにできるよ。

ハイパーパラメータ最適化にはもっと良い手法があるよね?重要なことを見落としてる気がするけど、なぜAutoresearchがこんなに注目されてるの?AI/ML/DLのボトルネックは常にデータ(量と質)か計算能力だよね。Autoresearchは大規模データセットの改善に役立つの?人間よりも計算効率がいいの?

ハイパーパラメータの最適化にはもっといい手法があるよね?いつもそうだし。だけど、それが何かを考えないとね。オートリサーチはその考える部分をLLMに任せてる。

私の知る限りでは、これはハイパーパラメータの調整以上のもので、非パラメトリック(構造的)な変更もできるよ。非パラメトリック最適化は新しいアイデアじゃないし、今の盛り上がりは、みんながもう少し力任せじゃなくなることを期待してるからだと思う。

ハイパーパラメータ最適化にはもっと良い手法があるよね? うん、例えば「スウォーム最適化」とかね。「オートリサーチ」との違い(HPOの観点に限定すると)って、LLMが各試行のためにもっと良い推測をして、従来のアルゴリズム最適化を超えてくれることを期待してるってことだよ。例えば、問題には過去に研究された最適化の多様体があって、LLMがその研究をトレーニングセットに持っているか、検索して見つけて、全てのハイパーパラメータの重要性を学ぶかもしれない。そうすると、重要じゃない軸はあまり変えずに、重要な軸に集中することを「知っている」ってわけ。過去に誰かが問題を理解するために頑張ったから、LLMはそれを活用するんだ(また、そうなることを期待してる)。

自動機械学習(AutoML)という分野があって、専門的な学術文献やライブラリがあって、こういうことを達成しようとしたけど、実際にはあまりうまくいかなかったんだ。何年か前には、ベイズ的ハイパーパラメータ最適化や、ガウス過程での性能予測、hyperoptライブラリに大きな期待が寄せられてたけど、パラメータが何をするのか全然わからずに無駄な実験を始めることが多かった。人々は主に直感や経験で設定した構成でグリッドサーチやランダムサーチを行うことが多い。一方で、LLMは各ハイパーパラメータが何をするのかを見て、文献でうまくいった技術や設定を確認できるし、十分な効果があるかどうかの常識に近いこともできる。例えば、トレーニングカーブが本当に平坦になった時を正確に定義するのは意外と難しいんだ。理論的には多くの非LLMアプローチがあるけど、あまり良くない。もしかしたら、これもまだあまり良くないかもしれない。でも、もしかしたら将来的には良くなるかも。

AI/ML/DLのボトルネックは常にデータ(量と質)か計算能力だ。 全然違うよ。MLの本質は、同じXに対してもYへのより良いマッピングを見つけることだからね。多くのベンチマークは、問題に対して単に計算能力を増やすだけでは解決できない。より良い関数を学ぶ必要があって、これは伝統的に人間が必要なんだ。そして時には、アルゴリズムがより多くのデータにアクセスできるようにしてくれることもある。例えば、トランスフォーマーはLSTMよりも並列処理が得意だから、計算効率が良いんだ。

動作するコードを用意して、LLMにバグを直させる。パフォーマンスとテストカバレッジを測定する。結果をLLMにフィードバックする。これを繰り返す。これが、私たちのショップでのより複雑なLLM展開の標準的なアプローチになってる。異なるモデルを使うのも、自分の実験で役立つことがあるよ。新しい視点を得るような感じだね。

このアプローチを修正して、特定のプログラミング言語やフレームワークに特化したLLMを作ることはできるかな?それが、ローカルLLMが本当に輝くところかもしれないね。

元の論文ではいくつかの医療用X線データセットを使用していて、もうアクセスできないから、専門家の注意メカニズムをテストするために空間的注釈のある新しいデータセットが必要だったんだ。だから、浮世絵VGデータセットを選んだ: 約11Kの日本の版画。なんか変な切り替えだね。オンラインにはたくさんの無料医療画像があるよ。例:https://www.cancerimagingarchive.net/

確かにそうだね!医療データをエージェントに渡すのはちょっと軽率に感じた。あと、モデルが他のドメインでも機能するか見たかったんだ!

すごく面白い実験だね、誰かがこれをやるかもって思ってたから、こういう形でやってくれて嬉しいよ。書き方も良かった!これにはちょっと笑っちゃったよ:「ある時、トレーニングが終わるのを待つのに疲れて、会話を終わらせちゃった。まだ完全な自律性は与えない方がいいね :)」結果とその過程をシェアしてくれてありがとう!

ありがとう、気に入ってもらえて嬉しいよ!

僕の経験では、イテレーションがバグで壊れちゃうことがあるよ。例えば、.shift(1)の代わりに.shift(-1)を使ったりするとね。もし時系列データなら、すべての下流のイテレーションが未来を見てしまって、完璧な結果を生み出しちゃう。これって、エージェントがやることの多くが幻覚みたいなもんだから。