ディスカッション (11件)
昔思いついたまま眠らせていた古い研究のアイデアを、AIなどの最新ツールを使って「自動リサーチ(Autoresearch)」してみようという試みです。過去のインスピレーションを現代の技術で掘り下げたらどうなるのか、そのプロセスや可能性に注目が集まっています。
つまり…ちゃんと動いたんだな。本人が気づかなかったバグを見つけて、手つかずだった最適化までやってのけたってわけか。
俺もよくLLMを使って先行事例を調べたり、問題への別の切り口を探したりするよ。言ってくることの9割は、LLMが知り得ない技術的な制約のせいで役に立たなかったり、自分のドメインには適用できなかったりするけど、残りの1割は素晴らしくて、新しい学びがある。
ただ、LLMのチャットボットが勧めてくることを全部エージェントに試させるなんて、コスト的に考えられないな($$)。推奨されるライブラリの中には、解説記事は多いけどメンテが最悪だったり、本番環境で使われてるのか怪しいニッチなやつがよく混ざってるし。
一方で、上層部に吹き込んでくる「ドメインエキスパートのコンサル」も同じくらい無茶な提案をしてくるから、こっちはその否定に追われてる。いっそエージェントがそのコンサルたちの相手をして、俺たちを静かに仕事させてくれないかな。
メインのリンクが開かないときは、こっちを試してみて。 - https://archive.is/6xLiU (https://archive.is/6xLiU)
「エージェントは、基本的な推論機能を組み込んだハイパーパラメータ最適化アルゴリズムのように振る舞った」
いい着眼点だね。
この自動リサーチ・リポジトリの核心は、実質1つのファイル「program.md」にある。これはシステムプロンプトで、「train.pyを改善し、学習を実行し、評価を行い、結果を記録する。これをループで回せ。シンプルさを優先しろ」って要約できる内容だ。他のファイルは、単に学習対象の適当な機械学習モデルにすぎない。
コミットログ[1]を見てみたんだけど、「ムーンショット(大胆な)アイデア」がどう実装されてるかに興味があったのに、結局のところ、ほとんどただのハイパーパラメータ・チューニングなんだよね。まあ悪くないけど、トークンに費やしたコストに見合うほどかな? 何か見落としてる?
[1] https://github.com/ykumards/eCLIP/commits/main/autoresearch (https://github.com/ykumards/eCLIP/commits/main/autoresearch)
ハイパーパラメータ最適化なら、もっと良い手法が他にあるよね? 何か大事なことを見逃してる気がするんだけど、なんでAutoresearchがこんなに話題になってるの?
AI/ML/DLのボトルネックって、いつだってデータ(量と質)か計算リソースでしょ。
Autoresearchは大規模データセットの改善に役立つのか? それとも人間より計算効率が良いってこと?
動いてるコードを用意して、LLMにバグ修正を頼む。パフォーマンスとテストカバレッジを測定して、その結果をまたLLMにフィードバックする。これの繰り返し。
うちの現場じゃ、複雑なLLMデプロイメントの標準的なアプローチとして定着してるよ。
イテレーションごとに別のモデルを使うのも、自分の実験では有効だったな。別の視点を取り入れる感じ。
これって「自動リサーチ」というより、まともなフィードバックループを備えた「構造化された試行錯誤」って感じがする。便利だけど、本当のボトルネックは評価指標(eval metric)の質だと思う。ここが甘いと、ループ全体が間違った方向に全力で最適化しちゃうからね。
「元の論文ではいくつか医療用X線データセットを使っていたが、もうアクセスできない。だから、エキスパート・アテンション・メカニズムをテストするために空間アノテーション付きの新しいデータセットが必要になり、Ukiyo-eVG(約1.1万点の浮世絵)を選んだ」
これ、めちゃくちゃ変な切り替えだな。ネットには無料の医療画像データなんていくらでもあるのに。例えばここ。
https://www.cancerimagingarchive.net/ (https://www.cancerimagingarchive.net/)
かなり面白い実験だね。誰かこういうことやらないかなって思ってたから、このやり方で形にしてくれて嬉しいよ。記事もよく書けてる。特に「ある時点で学習が終わるのを待つのに飽きたのか、勝手に対話を終了してしまった。まだ全権を任せるのは早そうだ(笑)」ってところ、ちょっと笑っちゃった。
結果とそこに至るまでの過程を共有してくれてありがとう!