auto-research

自動リサーチ

時間あたりの学習量を最大化します。まず、短時間で多くのことがわかるタスクを1つ実行し、競合する仮説を立て、それぞれを個別に検証して、確認済みの成果を組み合わせてから、対象範囲を広げます。長期的に残す成果は、パラメーター効果マップと、最も優れた検証済みの成果物です。実験はチェックポイントであり、終点ではありません。

ワークフロー

1. リサーチの状態を把握します。 目的、ユーザーからのフィードバック、プロジェクトの指示、既存のリサーチ記録を確認します。引き継ぎ内容を実際の成果物や実行中のジョブと照合し、新たな試行を開始する前に保留中の試行の結果を回収します。最も優れた検証済みの成果物（現行の最良候補）、アクティブなタスク、リグレッションテストセット、仮説キュー、残りの予算を特定します。既存の記録場所を再利用します。

2. 実験の前に成功条件を明確にします。 すでに合意済みの基準があれば、それを確認します。ユーザーに同じ内容を繰り返し尋ねてはいけません。評価方法、指標、比較ベースライン、または必要な改善量が不明確な場合は、候補の編集や評価の開始より先に、焦点を絞った質問をして回答を待ちます。既存の成果物を調べ、回答しやすいよう具体的な選択肢を提示します。成功の意味を独断で決めてはいけません。評価範囲、集計方法、非劣化ゲートを含め、回答によって検証可能な基準が定まるまで確認を続けます。その基準をリサーチ契約に明記します。

   正しさの合格ゲートを通過することと、最適化目標を達成することを区別します。目標が絶対スコア、絶対変化量、または明示されたベースラインに対する相対的な改善のどれであるかを指定します。「精度を5%向上させる」は曖昧です。60%から5パーセントポイント向上させるなら65%ですが、相対的に5%向上させるなら63%です。単位と方向を明確にし、必要に応じて計算式を記録します。ベースラインの値は後で測定してもかまいませんが、その識別情報と比較ルールは先に確定する必要があります。ユーザーが意図している場合に限り、終わりのない最適化を受け入れます。しきい値を捏造したり、求められた改善の代わりに、どのような改善でもよいとしたりしてはいけません。

   次に、役に立つ最小限のループを定義します。 変更可能なパラメーターと固定する評価方法を記録し、改善対象の挙動が表れる低コストのタスクを1つ選びます。実行時間を測り、内側のループから不要なセットアップ、モデル、ケース、実装作業を取り除きます。不確実性がアーキテクチャに関するものなら、アーキテクチャのスパイクを優先します。利用可能なベンチマークタスクは候補群であり、すべてを実行する必要はありません。意図する主張とユーザーの範囲を裏付けるのに必要な検証範囲を選びます。

   評価コマンド、タイムアウト、修正の許容回数、リソース制限、昇格ルール、確認計画を記録します。リサーチにかける費用と、最適化対象のコストまたは実行時間を分けて考えます。成功条件が定まり、次の試行を低コストで実行でき、判断基準が明確になれば完了です。最初の仮説を検証する前に、大規模なベンチマークマトリクスを構築してはいけません。

3. アクティブなタスクのベースラインを確立します。 変更していない成果物を1回実行するか、互換性のある記録済みの結果とトレースを再利用します。評価方法が意図した結果を測定していることを確認します。検出できることが未証明なら、既知の失敗ケースを含む対照を使用します。このタスク／モデル／ハーネスではベースラインを固定し、バリアントごとに再実行してはいけません。測定値にばらつきがある場合は、ユーザーが単一のベースラインの再利用を指示していればその指示を守り、影響を見分けるために必要な回数だけ繰り返す計画を立て、その制約を報告します。正確な入力、成果物の識別情報、生の出力を保存します。

4. 小規模な仮説バッチを計画します。 編集を始める前に、現在のボトルネックについて異なる説明と、それらを検証できるパラメーターや戦略を列挙します。集計スコアから推測するのではなく、実際の失敗トレースと対応するベースラインの挙動を調べます。各仮説について、以下を記録します。

   • パラメーター／変更内容とメカニズム：結果に影響する可能性がある理由。
   • 予測される観察結果、仮説を反証する結果、最も安価に判別できるテスト。
   • 固定する比較対象の親候補、予想される試行コスト、他の仮説との依存関係や相互作用の可能性。

   時間あたりに得られる情報量で順位を付けます。効果を解釈しやすくするため、同じ親候補に対して代替案を一つずつテストします。パラメーターを網羅的に組み合わせたグリッドは避けます。試行の順番待ちリストは短く保ち、結果に応じて見直します。計画は研究サイクルごとに行うものであり、一度だけ作るバックログでも、最初の試行を遅らせる理由でもありません。

5. アクティブなタスクで仮説を一つ検証します。 現行候補を保持し、無関係な作業から候補を切り分けます。概念的な要因を一つ変更します。相互に関連する変更の組み合わせが必要な場合は、結果をその組み合わせに帰属させます。実行前に候補の識別情報と予測を記録します。まず低コストのチェックを行い、その後、対象を絞ったタスクを実施します。すべての候補で広範なスイートを実行する必要はありません。一意に識別できる生の出力を保存し、関連するトレースを確認します。クラッシュと修復の範囲を限定します。修復した候補には新しい識別情報を割り当てます。結果がない場合はゼロではなく不明として扱います。

   後退や効果がない結果も含め、観察結果を予測と比較します。keep、discard、inconclusive、または invalid を記録し、マップを更新します。代替案の切り替え時には親候補に戻し、再現可能なスナップショットやパッチ、およびロールバックの対象外にある証拠を保持します。候補を却下しても、その戦略全体が否定されたことにはなりません。有望な部分的成功を診断し、証拠が裏付ける場合は、対象を絞った追加検証を計画します。

6. 組み合わせて昇格させます。 互換性のある勝者を組み合わせ、最も有力な単独候補と比較してテストします。効果が加算されると決めつけず、相互作用を確認します。原因を特定しにくい場合は、変更を一つずつ取り除きます。より単純な候補に負ける組み合わせは、現行候補にしません。

   対象を絞ったテストでの勝利は暫定的なものです。昇格させる前に、蓄積した回帰テストセット内の過去の解決済みタスクに対し、保存済みのベースラインと宣言済みの許容範囲を使って候補を確認します。回帰を平均値に隠すのではなく、却下するか修正します。ノイズの多い勝利は、計画した試行とコストをすべて含め、予定していた証拠で確認します。検証済みの候補を確保し、相互作用とタスク固有の制限を反映してパラメーター効果マップを更新します。

7. 進展があった後にのみ拡張します。 アクティブなタスクがそのローカル基準を満たし、過去のタスクも引き続き問題なく通過したら、新しい失敗モード、またはマップ内の不確かな効果を調べるタスクを一つ、あるいは小規模なバッチで追加します。不足しているベースラインは、それらのタスクについてのみ用意します。新しいタスクが失敗したら、それをアクティブなタスクとし、仮説の計画に戻ります。以前のタスクは回帰チェックとして保持します。その一つの失敗をデバッグしている間、拡張したスイートを繰り返し実行しないでください。

   このカリキュラムで変えるのは発見範囲であり、全体の成功基準ではありません。より広範な評価は、対象範囲を拡張するチェックポイントと最終確認のために取っておきます。単一タスクでの勝利だけでは、より広い目的を達成したことにはなりません。

8. 学んだことに基づいて計画を立て直します。 仮説バッチの実施後、新たな失敗の発生後、または改善しない試行が数回続いた後に、マップを整理し、次に最も多くの情報が得られるバッチを選びます。証拠が仮説に反する場合は、想定するメカニズムや実験設計を変更します。同じ変更群を延々と調整したり、同じテストを再実行したりしないでください。却下したアイデアを再検討するのは、前提が変わった場合に限ります。各実験の後に続行するか尋ねずに進めます。

永続的な調査記録

プロジェクトで既に使われている形式を使用し、各ビューは簡潔にまとめ、根拠にリンクしてください。

• 契約： 目的、固定された評価ルール、予算、現在のタスクと回帰テストセット、最終検証の範囲。プロトコルの変更にはバージョンを付け、互換性のないスコアを混在させたり、結果を合格させるためにユーザーの基準を緩めたりしないでください。
• 仮説キュー： 計画中のバッチ、優先順位、依存関係、予測、テスト済み／却下／次のステータス。全体像が改善されたら、古くなった項目を整理してください。
• パラメーター効果マップ： 意味のあるパラメーターまたは戦略ごとに1行を設け、テストした設定／範囲、品質／コスト／実行時間への観測された影響、適用可能なタスクの種類、トレードオフ、相互作用、確信度、根拠へのリンク、残る不確実性を記録します。測定された影響と推定されたメカニズムを区別し、悪影響や影響なしの結果も含めてください。この統合は主要な成果物であり、単なるリーダーボードや時系列の実験ログではありません。
• 試行台帳： 仮説、親／候補の識別情報、プロトコルのバージョン、タスク、コマンド／設定、メトリクス、ゲートの結果、リソース使用量、判定、根拠のパス。該当する場合はモデル／プロンプト／データのバージョンとシードを記録してください。
• 引き継ぎ： 現行の最良候補、アクティブなタスク、保留中のジョブ／出力場所、残りの予算、そして理由を添えた次の具体的なテスト。各判定の後、およびターンの切り替わり前に更新してください。「最適化を続ける」だけの状態を残してはいけません。

根拠の取り扱い

• 実際の成果を最適化してください。出力の小型化やマイクロベンチマークの高速化は、エンドツーエンドの品質とコストのゲートを通過するまでは診断材料です。調査対象の動作を維持したまま試行範囲を縮小し、タスクの答えをハードコードしないでください。
• 比較条件を一致させてください。コホート内では候補を固定し、リソース競合を避け、スコアを見てから都合のよいベースラインを選んだり、再試行したりしないでください。
• 開発と確認を分けてください。繰り返し調整したケースは開発時の根拠です。一般化を主張する際は未使用のケースを使い、候補の作業では隠された答えや評価者専用の入力を使わないでください。
• 失敗した試行や再試行も調査コストに含めてください。コストに含める項目と除外する項目を明示し、節約を主張する前に未確定の請求額を照合してください。インフラストラクチャの障害は成功でも、測定された候補の性能低下でもありません。
• 重要な知見は直ちに開示してください。ワークフローの順序を理由に開示を遅らせてはいけません。

停止

対象が必要な検証に合格する、ユーザーが作業を停止する、予算を使い切る、または有用な進捗を妨げる真の外部ブロッカーが発生するまで、許可されたセッションと制限の範囲内で続行してください。改善が頭打ちになった場合は計画を練り直すべきであり、最適であるという根拠のない主張をしてはいけません。継続時も調査の状態を保持してください。このスキル自体が将来の作業をスケジュールすることはありません。

停止時には、現行の最良候補を復元可能な状態にし、保留中のジョブを整理してください。パラメーター効果マップ、ベースラインと最良の検証済み結果、対象範囲と制限、消費した予算、停止理由、および未完了の場合は次に実施する正確な実験を提示してください。スコアを達成しても、実験で明らかになった内容の記録に代わるものではありません。実行が未完了でも、判明していることをまとめた有用なマップを残してください。