2つの設定、同じGPU、あなたが説明できる判断。

1. バリエーションを用意する前に問いを書き出す

役立つ比較は、明確な判断に答えるものです。最大長を増やすと回答の途切れを防げるか？ ディテールのレベルは必要な輪郭を保つか？ より大きなグループはエラーなく完了するか？ 質問を1つ、パラメータを1つ選びます。「最適な設定を見つける」は最初の1回には範囲が広すぎます。

基準をA、バリエーションをBと呼びます。変更した正確な値を記録してください。モデル、dimensions、パスの数を同時に変えると、異なる結果が得られても、どの変更がそれを説明するのか分かりません。それらの試行は別々の比較のために取っておきましょう。

2. 小さなコーパスと判定ルールを固定する

AとBで同じ入力を揃えます。最初の限定的な決定には十数件で十分な場合もありますが、プロジェクトの難所を含める必要があります。画像内の細かい文字、長い文書、欠落したデータ、珍しい形式などです。この数は実用的な選択であり、統計的な保証ではありません。すでに成功していた例だけを含めるのは避けてください。

各入力について、テストの前に成功条件を書き出します。見た目の好みと、致命的な欠陥を区別してください。文書アシスタントでは、たとえより心地よい回答でも、存在しないルールをでっち上げていれば不合格とすべきです。製品のビジュアルでは、魅力的な色は重要な要素の消失を補えません。

合格とみなす最小件数、禁止される欠陥、確認の最大時間も定めます。これらのプロジェクト固有のしきい値は、結果を検討する際にも同じに保ってください。

3. 同じセッションと同じ依存関係を保つ

モデル、そのバージョン、拡張機能、計算エンジン、その他のパラメータを同一に保ってください。同じ環境と同じGPUを使用し、2つのバリエーションの間に別の処理を実行しないでください。制御できない要素も記録しておきましょう。たとえば、同時に確認できる他のアクティビティ、強制的なバージョン変更、読み込みの違いなどです。こうした変化の影響を受けた比較は、より慎重に扱う必要があります。

ツールがランダムシードを使用し、それを固定できる場合は、各パスのペアでその値を維持します。これにより比較がしやすくなりますが、すべての環境で同一の出力を約束するものではありません。PyTorchは、同じシードであっても、バージョンやプラットフォーム間で完全な再現性は保証されないと述べています。

同じ識別子リストを持つ2つのフォルダ A と B を作成します。手作業で修正する前の生の出力を保持します。後からの手直しは、最初のファイルを生成した設定に帰属させるのではなく、作業時間とともに追加の操作として記録する必要があります。

4. 確認のパスを実行し、ペアを比較する

まず、単純な入力が取得したファイルまたは応答まで到達することを確認します。このパスは方法を検証するものです。最初の読み込みや特別な準備は別途記録してください。すべての要素がすでに読み込まれたBのパスと、Aの完全な起動を比較してはいけません。

AとBで同じケースを実行します。ツールが可能であれば順序を交互にし、その後、いくつかの決定的なペアを逆の順序で再実行します。孤立した結果や順序の優位性が結論全体を左右していないことを確認します。

エラーや拒否された出力も記録します。Bが大きな入力で失敗しても、平均を良くするために表から除外してはいけません。必要であれば、別の試行B2で原因を修正します。こうすることで、困難のたびにバリアントが変わるフォルダではなく、読みやすい比較を保つことができます。

5. 受け入れられた結果と観測された時間を分ける

まず、使用サイズまたは使用ツールで品質を確認します。可能であれば、判断の際にAとBの名前を一時的に隠します。1人が混ぜた順序で出力を確認し、その後対応を戻すだけで済みます。事前に決めた基準と、各拒否に対する短い理由を保持します。

時間については、単一の定義を選びます。たとえば、起動から保存された完全な出力までなどです。次に、人の確認と修正を分けます。GPU呼び出しの周りのストップウォッチは、必ずしも計算の完了を測定するものではありません。PyTorch/CUDAでは、操作が非同期になることがあります。計算だけを分離したい場合は、ツールが文書化した測定方法を使用してください。

実行時間の重なりや計測の精度が不十分な場合は、「所要時間の差は結論に至らない」と記載してください。1回の実行でのわずかな差は、確実なものとして提示できる性能向上率の根拠にはなりません。

例：文書アシスタント向けの128または256の新規トークン

小さなチームが、12個の固定された質問に対して完全な回答を求めています。同じモデル、同じドキュメント、同じ指示、同じGPUを使います。変わるのは回答の上限だけです。Aは新しいトークンを128個まで、Bは256個まで許可します。Transformersでは、max_new_tokensが入力テキストのトークンを含めずに生成を制限します。トークンは単語ではないため、この上限は文の正確な数を定義するものではありません。

テストの前に、チームは例示的なルールを定めます。12問中少なくとも10問の回答が承認され、勝手に作られたルールが一つもないこと。以下の表は、結果を読み取るための架空のシナリオです。実際に測定されたアシスタントを描写するものではなく、これらの値があなたのモデルに与える影響を予測するものでもありません。

Aは最低基準に達し、Bはより多くの承認された回答を得ましたが、重大な欠陥が残っています。この範囲ではAを維持し、回答を再確認し、別の比較の前にBの欠陥の原因を探ることが決定です。長さが長いことは品質の証拠でも、でっち上げの確実な原因でもありません。

チームは、AとBを区別する質問と、すでに成功した2つの質問を再実行します。同じ欠陥がAでも現れた場合、判断を保留します。最初のコーパスでは安定性を確立するのに十分ではなかったのです。最も有利なものだけを保持するのではなく、両方のパスの記録を保持します。

テストで許されない結論は避ける

一方の出力が見事だからといって、他の出力が悪化しているBを選んではいけません。途中でコーパスを変えたり、2回のやり直しを2つの異なる入力として数えたり、失敗を分母から消したりしないでください。提示した12件は、たとえ一部がファイルを生成しなかったとしても、説明すべき12のケースのままです。

採用した設定は、検討した入力、バージョン、基準に対して有効です。10倍長いドキュメントや異なる画像にはもう適さないかもしれません。代表的なケースを徐々に追加していきましょう。この積み重ねは検証範囲を広げますが、小さなテストをシステムの認証に変えるものではありません。

短い決定と次の検証を残す

最終的な記録には、コーパス、2つの設定、出力、IDごとの判定、そしていくつかの結論の行が含まれます。「Aはこの12の質問では維持された。2つの回答は見直しが必要。長いドキュメントの追加分は対象外」のように、採用した設定、その理由、限界を記しておきましょう。他の人がセッションに立ち会わなくても、その選択を理解できるようにする必要があります。

次の診断のためにAを対照として残してください。どのバリアントも基準を満たさない場合は、納品用にどれも採用せず、新しい仮説を立ててください。この続きを始める前に、コピーと確認の時間を確保してください。明確な限界とともに終えた試行は、すでに一つの決定をもたらします。勝者を見つけるまで続けなければならないわけではありません。