scenario-model-comparison

シナリオモデルの比較

概要

比較とは、同じ内容を変更せずに複数のモデルで短時間実行し、最初の有料リクエストを行う前に書き留めた基準に基づいて評価するものです。候補ごとに契約が異なるため、比較の要は正規化にあります。つまり、何を固定し、各スキーマのどの要素によって差が生じ、各数値の出所がどこかを明確にします。recommendで候補を絞り込み、dry_runで料金を見積もり、jobs_waitの行から請求額を確認し、グリッドツールで結果を並べて表示し、表にまとめます。接続と基本的なループについてはscenarioスキルを、概要に照らして出力を評価するためのルーブリックについてはscenario-refine-loopを参照してください。ここに記載した関連スキルが利用可能なスキルにない場合は、ユーザーにインストールを依頼してください（npx skills add scenario-labs/skills --skill <name>）。無人で進める場合は、ツールのスキーマに基づいて作業し、不足しているスキルがあることを明示してください。

クイックリファレンス

手順	内容
1. 条件を定める	1つの概要とその入力（プロンプトテキスト、参照アセット ID）、3～5個の合否基準を、実行前にすべて書き留める
2. 候補を絞り込む	概要をpromptとしてrecommendを実行する（limitは最大10）。ユーザーが指定した候補はsearchで検索し、3～5個に絞る
3. 正規化する	各候補についてmodel_schema_getを実行し、共通フィールド、異なる上限値、プロンプトを書き換えるフラグを確認する
4. 料金を見積もる	候補ごと、およびユーティリティモデルに対してmodel_runをdry_run: true（最上位に指定し、model_idの隣に置く。parametersの内側には入れない）で実行し、予算ゲートを適用する
5. 実行する	候補ごとに最上位のwait: falseを指定してmodel_runを連続して実行し、その後、すべてのジョブ ID をまとめて1回のjobs_waitに渡す
6. 測定する	コストはjobs_waitの行にあるcuCostを、秒数はjob_getのcreatedAtからupdatedAtまでを使用する
7. 評価する	model_scenario-grid-makerのシートを使い、各アセットをフルサイズで確認して基準に照らして評価する
8. 提出する	候補ごとに表の行を1つ用意する。アセットは1つのコレクションにまとめ、モデル ID をタグ付けする

正規化

• 簡潔な指示文は固定します。同じプロンプトテキストをバイト単位で一致させ、同じ参照アセット ID を使い、出力数も同じにします（すべての候補で同じバッチフィールドが使える場合を除き、1 つです。デフォルトのサンプル数が 1 を超えるモデルではコストが倍増するため、明示的に指定する必要があります）。
• スキーマの違いは、必要な箇所だけにします。サイズはモデルごとに列挙値またはピクセルのペアです。簡潔な指示文の目標に最も近い、各モデルで許容されるサイズを選び、結果の横に asset_get から取得した width と height を記録します。出力が大きいほどコストが高く、より鮮明に見えるためです。プロンプトの上限（max_length）はモデルによって異なります。超過すると 400 エラーになり、暗黙に切り詰められることはありません。ユーザーの指示文は正確に維持します。上限が小さすぎる候補は入れ替えるか、すべての候補で指示文を変更する前に確認します。
• プロンプトを書き換える機能はオフにします。プロンプト拡張または最適化のフラグを 1 つの候補だけオンにしたままにすると、指示文ではなく書き換え後のテキストを比較することになります。オフにできないフラグがある場合は、表にその旨を記載します。
• シード値はモデル間で比較できません。シード値で再現できるのは、各モデル固有のサンプリングだけであり、ほかのモデルには引き継がれません。seed は未設定のままにするか、同じ候補を再実行する場合に限って設定します。
• 1 つのファミリーに属する Turbo と Quality は、別々の候補として扱います。LoRA はベースモデルを通じて実行され（runs_as と run_with については scenario を参照）、コストと所要時間はベースモデルの実行に準じます。
• あるファミリーのスキルで調整（参照タグの構文や強度ダイヤルなど）が指定されている場合、公平に比較するには、その候補についてデフォルト設定と調整済み設定の 2 行を用意し、調整済み候補と未調整の候補を比較する必要があります。

予算

生成と、必要なグリッド作成、抽出、分析の各ステップにかかる費用を見積もります。合計に厳密な上限がある場合は、実行中のジョブを含め、起動した各ジョブを 1 回として数えます。最初の有料呼び出しの前、およびその後の各有料呼び出しの前に、次の条件を満たす必要があります。確定済み支出 ＋ 次の呼び出しの見積額 ＋ 残りの必須作業に対する検証済み予約額 ≤ 上限。代替入力での見積もりは、記載された料金体系によって実際のペイロードの上限額であると証明できない限り、予約額の検証には使えません。シートにまだ存在しない出力が必要で、検証済みの上限額もない場合は、生成を開始せず、段階的な支出または修正した計画を提案して、ユーザーの同意を待ちます。要望された候補や成果物を、予算に合わせるために黙って省略してはいけません。usage が報告するのは消費済み CU であり、残りのクレジットではないため、この予算確認の根拠にはできません。

測定

recommend が報告するのはモデル上のコストとレイテンシであり、ショートリストには適していますが、結果としては不適切です。dry_run では正確なペイロードの料金が算出され、jobs_wait の行にある cuCost が請求額です。所要時間は job_get から取得する createdAt と updatedAt で求めます。完了したジョブでは、その差がキュー時間を含む実際のレイテンシになります。同じ 1 分以内に起動した候補間であれば比較できます。候補はすべて、チームの同時実行上限内で、いずれかを待つ前に起動します（scenario の 429 行を参照）。同時実行数の上限を超えて 429 が返された場合は、返された actionLimit を使います。この比較のバッチサイズから上限を推測してはいけません。すべての行が終端状態になるまで、pending_job_ids を指定して jobs_wait を再度呼び出します。候補ごとに、モデル ID、送信した正確な parameters、cuCost、秒数、実際に出力されたサイズ、アセット ID、適用を余儀なくされた正規化処理（サイズ、上限、フラグ）を記録します。

動画の候補は最初のフレームではなく、コンタクトシートで比較します。各クリップを model_scenario-video-to-image-seq で走査します（これは固定されたファーストパーティ ID で、Scenario の決定論的な唯一のフレーム抽出器です。検出を行っても再導出になるだけです）。抽出ジョブの完了を待ってから、候補ごとにフレームをシートにまとめます。抽出器のフレーム順序とストライドの仕様、およびシートの画像上限 100 枚については scenario-video-editing を参照してください。音声と 3D の候補は、asset_display を使ってアセットそのものを比較します。

評価

事前登録された基準は、出力に関する合否判定の文です（「ラベルの文字が判読できる」「傷跡が左頬にある」「余分な指がない」「背景が無地」など）。そのため、結果は評価されるのであって、称賛されるのではありません。また、意外な勝者が後からテストを書き換えることもできません。基準を文字どおりに評価してください。関連する特徴や部分的な一致は合格ではなく、証拠が曖昧な場合は未確認とします。シートは model_scenario-grid-maker で作成します（固定されたファーストパーティ ID であり、Scenario の唯一の決定論的なグリッドツールなので、検索しても同じものを再特定するだけです）。images には候補順に画像を指定し、1 つの場合も配列で囲みます。配列の順序が凡例となるためです（このツールにはラベルがありません）。columns は候補数と同じ値にして、1 行が 1 つのブリーフになるようにし、cellRatio は出力に合わせ、padding は余白に使います。その後、各出力を asset_display で原寸表示します。シートでは細かい文字、輪郭のハロー、小さな解剖学的特徴が見えにくくなるためです。すべての候補について、すべての基準を評価し、コストと秒数も同じ表に記載して、トレードオフが一目でわかるようにします。候補が多い場合は、asset_analyze（カタログ掲載、コストが発生、書き込みクラス。scenario を参照して scenario_tools_search、次に scenario_tool_execute_write を実行）で一括評価できます。基準のリストをそのまま instruction に、出力を images に指定し、画像ごとに基準ごとの判定を 1 つずつ行います。出力解像度では判定できない基準（小さな文字や細い輪郭など）は、決して合格とせず未確認として記録します。その instruction は基準とともに事前登録してください。

実例：1 つの小道具のブリーフで 3 つの画像モデルを比較

1. ブリーフを設定します。「錆びた鉄の鍵。頭部はドクロ形。手描き風。無地の背景」、1024 の正方形。基準は、ドクロ形の頭部があること、鍵がちょうど 1 本であること、文字がないこと、背景が無地であることです。
2. このブリーフを prompt として recommend を limit: 5 で実行し、次に target="models"、public=true を指定して、ユーザーが名前を挙げた 2 つのモデルを search します。候補は 3 つにします。カタログはチームごとに異なるため、ID をハードコードしてはいけません。
3. 各モデルで model_schema_get を実行し、プロンプトの上限、サイズ関連フィールド、サンプル数フィールド、プロンプト拡張フラグの有無を確認します。
4. 各モデルで、トップレベルに dry_run: true を指定して model_run を実行します。同じプロンプトを使い、数を指定するフィールドは 1 にし、各モデルで可能な最も近い 1024 の正方形を選び、拡張フラグはオフにします。3 つの価格を記録し、必要なシートの費用も含めて、予算ゲートを適用します。
5. wait: false を指定して model_run を 3 回実行し、その後 3 つのジョブ ID を指定して jobs_wait を 1 回実行します。タイムアウトした場合は pending_job_ids を指定して再度呼び出します。各行の cuCost を読み取り、各ジョブについて job_get から createdAt と updatedAt を確認します。
6. images に候補順の 3 つのアセット ID を指定し、columns: 3 として model_scenario-grid-maker を実行します。シートを asset_display で表示した後、各アセットも表示し、4 つの基準を評価します。
7. 表（モデル、異なるパラメーター、コスト、秒数、寸法、合格した基準、メモ）を提出し、3 つの出力とシートをコレクションに保存します（collection_create、続けて collection_add_assets）。asset_add_tags で各出力にモデル ID のタグを付けます。

よくある間違い

• recommend の数値を結果として引用すること。これらは推定値です。料金は jobs_wait から、所要時間は job_get から取得します。
• 候補ごとにサイズやサンプル数を変えること、または候補の 1 つだけプロンプト拡張を有効にしたままにすること。この場合、比較対象はペイロードの差になってしまいます。
• 出力が大きく変動するブリーフで、候補ごとに 1 サンプルしか生成しないこと。予算が許せば 2～3 個生成し、表に個数を記載します。
• 勝者が常に同じだと考えること。順位はブリーフごと、チームのカタログごとに異なります。どちらかが変わったら再実行し、勝者の ID をスキルやパイプラインに固定値として決して書き込まないでください。
• 動画を最初のフレームや静止画 1 枚だけで比較すること。クリップをコンタクトシートにまとめて比較します。
• シートを成果物として提出すること。結果はコストと基準を記載した表であり、シートは証拠です。
• 署名付きダウンロード URL をレポートに貼り付けること。アセットを保存し、アセット ID を共有します。