目に見える製品の成果について合意する
有用な回答、抽出、またはコードの提案がどのようなものかを定義します。機能を中止する必要がある場合、または詳細情報を要求する必要がある場合を含めます。
これらの要件を小さな評価セットに変えます。結果として得られる受け入れ基準は、特定のプロバイダーを優先するのではなく、モデルの選択の指針となるはずです。
安定したアプリケーションインターフェイスを構築する
TextCortex クライアントを、アプリケーションのタスク入力を受け入れるサーバー側関数の背後に配置します。キー、モデル識別子、および生成設定をブラウザーに入れないようにしてください。
この境界により、開発者は機能のパブリック インターフェイスを維持しながら、選択したモデルを切り替えることができます。また、制限、ログ記録、エラー処理のための場所も提供します。
共有された証拠を使用してモデルを比較する
同じ TextCortex 接続を通じて独自の候補とオープンウェイトの候補を評価します。製品チームの代表的な出力、失敗率、待ち時間、および承認された結果ごとのコストを表示します。
有用な場合はモデル名をブラインド品質スコアリングから除外し、そのスコアを EU ホスティングや使用コストなどの運用上の制約に再関連付けします。
機能を展開し、モデルの選択肢を拡大する
小規模で観察可能なワークロードと明確なロールバック ルートから始めます。新しいモデルによって機能が改善されたり、新しい機能が有効になったりする証拠がある場合は、新しいモデルを追加します。
統合構造には ソフトウェアベンダーAPIページ を使用し、生産準備には ロールアウトガイド を使用します。