オートリサーチ、Claude、および制約付き最適化

はじめに AIが数十人分の仕事をこなしているという主張を見つけるのに、遠くまで探す必要はありません。私は証拠なしに改善を議論するあらゆる主張に懐疑的になる傾向があります。この懐疑心を活かすことにしました。 ここ数週間、私はKaparthayの「オートリサーチ」のテーマでプロジェクトをまとめてきました。私は、伝統的な機械学習や数値最適化の問題ではないが、それでも成功の客観的な尺度を持つ問題を選びたいと思いました。 私はこのような種類の問題を選びました。なぜなら、私が取り組んできた多くのプロジェクトや製品はそのように構造化されているからです。変更したいメトリック（増減）があり、理想的にはそれを測定する方法があります。おそらく制約もあります。例えば、この機能ではページ読み込み時間を500ミリ秒以上にすることはできません。 成功への道筋が、機械学習のような明確な勾配最適化であるような問題に取り組んだことはまだありません。多くの場合、作業を完了し、「実世界」でテストし、そのパフォーマンスを見て、次のステップを決定します。すべての変更が肯定的な結果をもたらすわけではなく、局所的に最適化された結果をもたらすパスに深く入り込むのは簡単です。 私は、AIエージェントに、ほとんど監視なしで、より大きな作業を任せる方法について、直感を得られるような実験をしたかったのです。この結果を達成しようとする他のメカニズム、例えばRalph LoopsやClaude Codeに現在搭載されている/goalコマンドなどがすでに存在します。このセットアップの違いは、成功の主要な尺度として定量化可能な数値を選択し、合格/不合格の制約で問題を制限することです。 物事を複雑にしすぎたくなかったので、ファイル圧縮の問題を選びました。目標と制約が単純だったからです。圧縮アルゴリズムは、最終的なファイルサイズが小さいほど優れています。私は問題に2つの制約を追加しました。1つは、非圧縮ファイルが完全に一致する必要があること、もう1つは、圧縮または解凍が300秒を超えることはできないことです。意図的に速度を最適化していたわけではありませんが、時間を制限し、タイムアウトが無限ループを捕捉してくれることを知って、プロセスがほとんど監視なしで実行できることを確認したかったのです。 ファイル圧縮のもう1つの良い点は、最終的なベンチマークに使用できる既存のツールがたくさんあることです。これが小規模な概念実証であったため、最先端のアルゴリズムを作成することは期待していませんでした。 それにもかかわらず、この自家製のバージョンが既存のツールに対してどれだけうまく機能したかを知ることは、ライブラリや既製のソリューションからどれだけ離れる可能性があるかについてのデータポイントを提供することにも役立ちます。エージェントが外部依存関係によって解決されていた問題を迅速かつ確実に解決できる場合、内部ソリューションの価値が、サプライチェーン攻撃のようなリスクを上回る時点があるはずです。これは単一の実験で解決できるものではありませんが、これ以上調べる価値があるかどうかを判断するのに役立つでしょう。 方法論 問題設定 まず、このアプローチが実行可能かどうかを確認することが目標であり、特定のモデルをベンチマークすることではないことを思い出してください。 次に、始める前に、このプロジェクトのすべてのコードはここにあります: https://github.com/smitec/agent-compression この作業では、Sonnet 4.6 のデフォルト設定で Claude Code を使用しました。異なるモデルなら違うことをしただろうと確信していますが、それはまた別の日の課題です。 エージェントが関与する前に、プロジェクトの基本的な骨組みを設定しました。Rust を選んだのは、「関数のシグネチャを変更しない」といった暗黙的な制約が型システムによって容易に強制できるためです。圧縮関数と解凍関数のスタブを作成しましたが、これらは単にバイトをコピーするだけでした。これは「機能」しましたが、データに対しては全く圧縮を提供しませんでした。 次に、基本的な単体テストをいくつか配置して、文字列と単純なファイルの両方で圧縮・解凍のラウンドトリップをテストしました。これらのテストは網羅的ではありませんでしたが、圧縮関数と解凍関数がビット単位で正確なラウンドトリップを維持するという目標に準拠していることを検証しました。 そこから、ベンチマークスクリプトを作成しました。このスクリプトは、パブリックドメインのファイルサンプル（ビデオ、オーディオ、テキスト）を取得し、さまざまなサイズのランダムデータで満たされたファイルも作成しました。これらのファイルの多くはすでにいくらか圧縮された形式でしたが、圧縮率の低い形式に変換するステップを追加しました。これにより、全体的な圧縮ベンチマークに加えて、ファイルごとの良いベンチマークが得られます。 このサンプルセットがあったため、高エントロピーと低エントロピーのファイル形式の混合がありました。良い圧縮アルゴリズムは、低エントロピー形式を縮小し、高エントロピー形式はほとんど変更しません。フォーマット固有のバイトによりファイルサイズのわずかな変化が予想されますが、全体としてファイルサイズが意味のある方法で増加しないことを望みます。 サンプルセットの中で最も大きいファイルは約150MBでした。圧縮はさらに大きなファイルでより意味があるかもしれませんが、特に後続のステップでは、非常に遅いテストループにつながるでしょう。 ベンチマークスクリプトは、各ファイルをループ処理し、個別に圧縮してから解凍しました。スクリプトは、解凍されたファイルが元のファイルとビット単位で一致するかどうかを確認し、サイズの変化と圧縮・解凍にかかった時間を記録しました。各ファイルのステップには300秒のタイムアウトが適用されました。これは主に偶発的な無限ループをチェックするためです。 スクリプトは debug.csv ファイルを生成し、ファイルごとの変更を概説し、改善があった場合は、主要なメトリックを results.csv ファイルに書き込みました。注目すべき点として、結合圧縮メトリックは（合計圧縮バイト数）/（合計元のバイト数）でした。サンプルセット全体の平均圧縮率を取ることも検討しました。この選択の違いと影響については後で詳しく説明します。 これらすべてがセットアップされた後、スタブ実装のベンチマークを実行し、実験の準備ができたと見なしました。 イテレーション 比較的よく制御された状態を保つために、各イテレーションの前に Claude のコンテキストをクリアし、「現在のコードベースを確認し、別の改善イテレーションを試してください。」というプロンプトでモデルに指示しました。Claude Code はデフォルトでプランモードに設定されているため、プランが表示されるのを待ち、簡単なレビューの後、プランを受け入れてエージェントに自分で実行させました。 この実験では、エージェントに完全に自律的な選択をさせるために、意図的にプランを変更しませんでした。介入が役立ったと思われることが何度かありましたが、それは教訓です。 10回のイテレーションを実行し、その後、一般的な圧縮ツールに対する最終的な拡張ベンチマークと、データ固有の最適化を制御するための新しいデータセットに対するベンチマークを実行しました。これらのイテレーションは、約2週間にわたって実行され、通常は他の作業をしている間に実行を開始して放置しました。この長い期間は、トライアルのデザイン上の特徴ではなく、主に他の作業中に Claude Code の制限を使い果たさないようにするためでした。 結果 イテレーション 最初のイテレーション中に、エージェントはカスタム LZSS 実装を生成しました。これは比較的標準的でよく知られた圧縮方法です。次の9回のイテレーションは、この方法の拡張であり、エントロピーチェックやエンコーディング技術を追加してエントロピーを削除しようとしました。 各ループは、かかった時間と使用されたトークンが大きく異なりました。Claude Code の /usage コマンドに基づくと、平均して、単一のイテレーションのコストは約4ドルでした。これもデフォルト設定での話なので、モデルによって大きく変動することを考えると、価格からあまり多くを読み取るつもりはありません。 興味深いことに、モデルは1回のイテレーションで一度に1セット以上の変更を行うことはありませんでした。仮説を立て、コードを追加し、ベンチマークを実行し、それを「完了」と見なしました。これは、/goal コマンドを使用しないプロンプト設定によるものかもしれません。 以下の結果は、モデルが圧縮の改善を継続できたことを示しています。