モデルは、じっとしていない依存先です
バージョンを固定したソフトウェアライブラリは、中身を調べて再実行できる成果物です。出力が変わったのに自分は何も変えていないなら、読み取れる何かが変わったのであり、それが何かを突き止められます。モデルはそれを壊します。変わらない名前の裏で中身がずれ、予告なく容量が減り、傾向がドリフトします。そのため回帰は、指させる原因のないまま訪れ、あなたは自分のプロンプトを疑って一週間を無駄にします。信頼する土台ではなく、計測する依存先として扱いましょう。バージョンを固定して、それが変わる瞬間を自分のものにし、安価な指標を少数、前もって決めておくことで、ベンダーのドリフトを自分のドリフトと区別できます。
スケジュールされたジョブの一つが、あるときから前より悪い結果を返すようになりました。そこでまずやったのは、自分の config を開くことでした。
これはほとんどの場合、正しい直感です。自分が作ったものが劣化したとき、バグはたいてい境界のこちら側、つまり自分の側にあります。編集したプロンプト、変えたことを忘れていたデフォルト。そこで探してみて、一つ見つけました。その週に、古いフォーマット規則を元に戻していたのです。それが見えている症状を明白に説明するわけではなく、しかも下で動くモデルも、ほぼ同じ時期に新しいバージョンへ切り替わっていました。二つの変更、一つの症状。そして正直な立場は、どちらが原因なのかまだ言えない、というものでした。
言いたかったのは、モデルが悪くなった、ということでした。ベンダーが新しいバージョンを出して出力がずれると、どの開発者もこの感覚を抱きます。しかし、自分の変更がまさに同じ週にそこにあるのに、モデルを犯人として持ち出すのは、以前に一週間を払わせた手です。ここで話しているのは、推測せずに済むように作った計器のことです。
というのも、モデルは他のどの依存先もしないことをするからです。土台とは、その上に築いたあとは考えるのをやめる部分のことで、それは動かないからそうできます。モデルは動きます。自分の名前のまま、他人のスケジュールで動き、自分が所有していないコードに依存することを生き延びられるものにする、たった一つの性質を奪います。出力が変わったときに、依存先が変わったのか自分が変わったのかを見分けられる能力です。
固定したライブラリはじっとしている。モデルはしない
自分が書いていないコードに頼ることのすべては、一つの推論の上に成り立っています。出力が変わって自分の側を変えていないなら、依存先が変わったのであり、それがどう変わったのかを正確に突き止められる。というのも、固定したライブラリは調べられる成果物だからです。そのバイトを読み、依存グラフをたどり、制御された環境で再実行できます。ロックファイルとハッシュでバージョンを固定すれば、頼っている対象は動く標的でなくなります。ライブラリが魔法のように決定論的だという話ではありません。クロックや乱数シードやネットワーク呼び出しに寄りかかることは、依然としてありえます。そうではなく、それが何であるかを固定して確かめられる、ということです。だから驚くような出力にも、隠れられる場所は短いリストしかありません。
ホスト型モデルは、そのほとんどを与えてくれません。名前から始めましょう。可変のエイリアスを指していると、ベンダーはあなたのバージョン文字列をまったく変えないまま、それを新しいスナップショットへ付け替えられます。しかも固定したスナップショットの周りでも、ルーティング、サービングスタック、セーフティフィルターは、ある実行と次の実行のあいだで動きえます。次に、出力そのものがあります。それは値ではなく分布なので、温度をゼロに設定しても救われません。ホスト型の推論では、バッチの構成やカーネルの非決定性が漏れ出てきて、「悪くなった」と「運の悪いサンプルを引いた」は、よく見るまで同じ観測です。この二つを合わせると、劣化したジョブは、指させる原因のない変化をあなたに手渡します。普段なら手を伸ばす唯一のつまみであるバージョン文字列すら、じっとしていないかもしれないのです。
だから固定は、安定のためではなく、原因の帰属のため
そこで、スケジュールされた作業が走るすべての場所で、モデルのバージョンを固定します。そしてそれが何を買ってくれるのかについては、正確でありたいと思います。それはモデルが動かずにいることを保証しません。固定したスナップショットも、ベンダーが動かすサービングインフラの上に依然として乗っているからです。それが取り除くのは、容疑者です。何かがドリフトして、バージョンには一度も触れていないなら、「アップグレードを入れた」という説明は消えます。そして固定は、各レスポンスから配信されたバージョンを読み戻すことにはできない、一つのことをします。バージョンが変わる瞬間を自分で選ばせてくれるのです。だから前と後は、自分で引いた線の両側に落ち、ほかのすべては保たれます。そのきれいなベースラインが、勝負の大部分です。
固定だけではまだ足りません。モデル自身のノイズが、小さな回帰を実行ごとのばらつきの中に隠し続けるからであり、一つの数字では同時に起きた二つの変更を引き離せないからです。自分が元に戻した規則も、モデルの変化も、どちらも「出力が変わった」を動かします。だからもう半分は、何かに触れる前に決めておく、安価な指標の小さなセットです。一つの数字ではなく、感度の異なる二つか三つ。そのどれが動くかが、何が動いたのかを教えてくれます。冒頭のあのジョブ、悪い結果を返してきた短いステータスまとめの束が、まさに使いたい例です。各まとめについて計算できる二つの数字を見ていました。実行にどれだけかかったか、そしてステータスをいくつの箇条書きに分けたか。元に戻したフォーマット規則は項目ごとに一つの箇条書きを求めるので、それが箇条書きの数を動かします。実行がどれだけ長いかは、モデルが動かすもののままです。バージョンを固定したものへ戻したとき、長さは元の帯域まで下がり、一方で箇条書きの数は上がり続けました。長さはモデルを追い、箇条書きは自分の規則を追っていたのです。二つの容疑者、二つの数字。そしてそれらが分かれたのは、分かれるような数字を選んでいたからです。
これはどれも証明ではなく、ゆるく握っています。分布に対する一握りの実行では、確信は買えません。しかしそれは矢印を指しました。膨らんだ長さはモデルのもの、余分な構造は自分のもの。そして、間違った原因に対してプロンプトを書き直す代わりに、まずどこを見ればよいかがわかりました。それが価値のすべてです。前もって固定した数字がなければ、「モデルが悪くなった」は示すことも退けることもできず、あなたは人間らしいことをして、自分のプロンプトをまた開き、見えない交絡と戦うことになります。最初にこれに出くわしたとき、まさにそれをしました。そして新しいモデルは単に悪いのだという、きれいな筋書きは、懐疑的な読み手に耐えられませんでした。その読み手は、自分自身の変更をモデルのせいにしていたことを示してくれたのです。この指標のセットは、次の交絡がレビュアーの手を借りずにほどけるように作ったものです。
容量も安定していない。同じように崩れる
振る舞いについてはすべて認めたうえで、それでも、得られるモデルの量は決まっていると思うかもしれません。その部分はプランに書かれているからです。決まってはいません。自分の計測器と照らし合わせられなかったコミュニティの報告は、宣伝された容量の変更が削減として着地したさまを描いています。告知は「増える」と言い、人々が見た処理量は「減った」と言った、と。ベンダーが数字を動かしたかどうかは脇に置きましょう。その下にある帰属の問いは、前と同じもので、一段深いだけです。処理量が落ちたとき、向こうの供給が縮んだのか、それとも自分の負荷が増えたのか。これは一つの症状に対する二つの生きた原因で、時間をかけて取った自分の負荷の記録以外に、それらを見分けるものはありません。それらのスレッドの誰も確かなことは言えず、それこそが手がかりです。自分の計測器がなければ、ベンダーの説明があなたの持つ唯一の説明であり、その説明は保証ではなく宣伝文句です。
アップグレードの判断は、同じ問題がより優しい顔をしているだけです。新しい世代が出て、移行ノートは、より安い設定でも前のバージョンと同等かそれ以上の結果になる、と告げます。そうかもしれません。しかし「同等かそれ以上」は、集約されたベンチマークについての主張であって、あなたが眠っているあいだに走らせる、あの一つの狭いジョブについての主張ではありません。あなたのジョブにとってどちらなのかを知る唯一の道は、あの指標のセットを保ち続け、切り替えをまたいで走らせておくことです。回帰を診断することと、アップグレードを受け入れるかを決めることは、同じ計測を二つの向きから問うているのだと、結局わかります。
依存先として捉えることが実際に何をもたらすか
モデルを土台と呼ぶのをやめ、完全には制御できない依存先として扱い始めると、設計の残りは、そうしたどの依存先についてもそうであるように、自然と出てきます。インターフェースの裏に隔離すれば、エンジンの差し替えはリビルドではなく設定変更になります。単一のモデルではなく、ジョブに合わせたポートフォリオを走らせれば、実際に経験するまでは逆さまに見えるあの事例に出会います。モデルを無人の作業者としては劣ったものにする傾向が、鋭いレビュアーにするのと同じ傾向だ、という事例です。高価なモデルなど必要としなかった機械的な量には、より安いものが差し込まれたままになります。そして、予告なく縮みうる供給は、固い依存を築く相手ではないので、削減が着地する前に縮退モードを設計しておき、あとから慌てないようにします。
それはすべて本当で、すべてがあとから来ます。ポートフォリオ、ルーティング、フォールバック。ポートフォリオのどのメンバーが変わったのか、そもそも変わったのかを言えなければ、どれも助けにはなりません。計測が先に来ます。それは、モデル自身が拒む土台だからです。
土台は忘れていてよいものです。それがこの言葉の全眼目です。この依存先は忘れさせてもらえません。設定していないスケジュールで、自分の名前のまま動くからです。そして大人の対応は、それをまさにそのものとして扱うことです。スタックの中で最も重要で、最も当てにならないもの、として。固定して、それが変わる瞬間を自分のものにする。変わる前に指標を決めておき、変化が来たときに読み取れるままにしておく。そして記録は自分でつける。バージョン番号はアイデンティティについてのベンダーの約束であり、それは彼らが完全には守らない約束だからです。