オープンソース モデルが制限された後、最初に独立させる必要があるのはモデルの中立層です。

オープンソース モデルが制限され始めると、最初に公開されるのはダウンロード エントリではなく、コード内のデフォルトの前提条件であることがよくあります。モデル名は変更されましたが、インターフェイスはそのままですが、ビジネス プロセスは古い動作と同期していません。出力形式、関数呼び出しシーケンス、拒否トーン、コンテキストの長さ、サンプリング パラメーターは、いずれも個別に表示できますが、積み重ねるとリンク全体がドラッグされます。

この種の問題は、通常、アーキテクチャ上の問題と見なすのが困難です。開発段階では「走れる」ことだけを見ていました。オンラインにアクセスした後、モデルの選択がすでにビジネス ロジックに書き込まれていることがわかりました。一部のフィールドは 1 つの戻り形式にのみ適応し、一部の再試行は 1 つの拒否メソッドのみを認識し、一部の例外フォールバックでは、詳細な説明を提供するためにデフォルトで元のモデルが使用されます。制限が課されると、これらの隠された山はすべて暴露されました。

デフォルトの動作では、モデルをビジネスに結び付けます。

アクセス段階では、SDK の追加、API の接続、プロンプト ワードの追加がモデルとして見なされることがよくあります。接続後、クリーンアップするのが最も難しいのは、呼び出し自体ではなく、デフォルトの動作を中心に成長したブランチです。出力を厳密に JSON にするかどうか、失敗後にツール呼び出しを再試行するかどうか、長すぎる入力をどこで切り詰めるか、リスク制御プロンプトをどのレイヤーに配置するか。これらの問題は多くの場合、ビジネス コードに当てはまります。

オープンソース モデルが制限されるかシェルフから削除されるか、ローカル イメージとアップストリーム バージョンがフォークし始めると、これらのデフォルトの動作は信頼できなくなります。表面的にはモデルを変更するだけですが、その内部では解析、監視、ロールバック、テストを同時に変更する必要があります。最も難しい部分は、さらに数行の適応を書くことではなく、元の一連の仮定が最初から最後まで明示的にマークされていないことです。

中立層の役割は、暗黙の仮定を広めることです

モデル中立層は、抽象化のための抽象層ではありません。その機能は非常に単純です。プロンプト ワード、スキーマ検証、ルーティング、再試行、ダウングレード、ログ、評価を 1 か所に配置して、モデルの違いが最初に同じ境界セットを通過するようにします。このようにして、モデルがクラウド、オープンソース、ローカル推論、またはその他のプロバイダーに置き換えられた場合でも、ビジネスでは依然として統一された入出力契約が得られます。

この層が確立されると、当初は不明であった多くのことが突然明らかになります。どのフィールドが必須値であるか、どのフィールドが単なるモデル設定であるか、どの失敗が再試行可能か、どの失敗がロールバックする必要があるか、どのコンテキストが切り捨てられるか、どのインジケータが実際に比較できるかなどはすべて、「経験によって記憶される」から「インターフェースによって制限される」に変わります。限定モデルによって引き起こされる影響は、ビジネス コードに直接入力されるのではなく、まず中立層に入力されます。

すべてのシーンがこのレイヤーに値するわけではありません

シーンによっては、レイヤーをそれほど厚くする必要がありません。 1 回限りのサマリー、一時的な生成、内部実験、完全に単一モデルでロックされたツール チェーンなど、これらの場所でモデルを接続するだけで十分です。短期間のプロセスのために完全な中立層を構築しても、事前にコストが過剰になるだけです。

この層は、モデルが実際にビジネス上の判断に関与する場合に必要です。抽出、ルーティング、ツールの実行、顧客サービスの応答、レビュー支援、バッチの書き換えなど。これらのシナリオでは、モデルはおもちゃではなく、プロセスの一部です。モデルが変更される可能性があるか、外部制約によって特定の入り口が不安定になる可能性がある限り、中立層は装飾ではなく、境界内で変化を維持する壁です。

オープンソース モデルを実際に制限せざるを得なくなるのは、特定のサプライヤーの代替ではなく、チームが「モデルの違い」を第一級市民として扱うかどうかです。コード内のデフォルトの動作が早く分散されるほど、後でモデルを変更するときに受動的ではなくなります。モデルは変更できますが、境界は追従できません。