Cloudflare Clefの意思決定モデル、オープンウェイトとRLプラットフォームでJevに挑む

Cloudflareは10月1日、2つの意思決定モデルを公開した。そのうち大規模なモデルは、すでにベンチマークでJevを上回ると主張している。Cloudflare Clefの意思決定モデルであるClefとClef-flashは、制約のないテキストを生成する代わりに、型付きの確率を返す。両モデルはWorkers AI経由で利用でき、Apache 2.0ライセンスのウェイトとしても提供される。

この組み合わせは、わずか数週間前にJevとSystem Oneモデルというカテゴリを発表したTypeSafe AIへの直接的な挑戦となる。CloudflareはJevのAPI形式を採用し、競合するベンチマーク結果を公開するとともに、画像対応も追加した。また、これらのモデルを新たに登場した強化学習サービスにも接続している。

この発表は、単なるオープンモデルの新規リリースではない。Cloudflareは、制約された意思決定をエージェント向けインフラ層に位置付け、自社ネットワークで推論、データ収集、学習、再デプロイを担わせようとしている。Jevが製品パターンを確立した一方、Cloudflareはそのパターンを完全なプラットフォームへと発展させようとしている。

この違いは重要だ。エージェントは、洗練された回答を生成するよりもはるかに多くの意思決定を行う。リクエストを分類し、ツールを選び、リスクを評価し、レコードを振り分け、支援を求めるべきタイミングを判断する。こうした選択を迅速に処理するモデルは、あらゆる自動化ワークフローの運用経路に組み込める。

Cloudflareの初期データは追加検証の価値を示しているが、市場の行方を決定づけるものではない。評価はモデルを公開した企業自身によるものであり、顧客向けファインチューニングプラットフォームも一部は手作業で、一部は計画段階にとどまる。本当の競争は、非公開で変化し続けるワークロード全体で、誰が適切に較正された意思決定を提供できるかにある。

Cloudflare Clefの意思決定モデル、選択をインフラへ変える

Clefは自由形式の生成をあえて捨て、ソフトウェアが事前定義された選択肢の確率を1回の順伝播で受け取れるようにする。

意思決定モデルは、状態、質問の集合、それぞれの質問に対する可能な回答を受け取る。状態には、サポートリクエスト、請求書、文書、ウェブサイト、あるいは提案されたエージェントの行動を記述できる。モデルはその後、許可された選択肢に確率を割り当てる。

このインターフェースは、一般的なチャットボットとは異なる。汎用大規模言語モデルはトークンを予測し、応答を組み立てる。一方、意思決定モデルは、アプリケーション開発者が選んだ制約付きの回答空間をスコアリングする。

例えば、サポートシステムでは、どの部門がリクエストを処理すべきかを尋ねられる。許可される選択肢には、請求、技術サポート、アカウントアクセス、不正調査などが含まれる可能性がある。別の質問では、そのリクエストに緊急エスカレーションが必要かどうかを尋ねることもできる。

出力はコードに直接渡せる。高信頼度の回答であればリクエストを自動振り分けし、不確実なケースはより強力なモデルまたは人間のレビュアーに回せる。

Cloudflareは両モデルをQwenのバックボーン上に構築した。ClefはQwen3.8-27Bを使用し、Clef-flashはQwen3.5-9Bを使用する。大規模モデルは精度を、小規模版はレイテンシーに敏感なワークフローを対象とする。

両モデルはベースモデルのビジョンエンコーダーを維持している。利用可能な選択肢をスコアリングする前に、テキスト、JSON、画像、動画を処理できる。Cloudflareの比較によれば、Jevは現在テキストに焦点を当てている。

また、モデルは64,000トークンのコンテキストウィンドウを提供する。Cloudflareはこの容量をJevの32,000トークンのウィンドウと対比しているが、コンテキストが長いだけで意思決定の質が向上するとは限らない。

このアーキテクチャは、モデルがトークンを順番に生成する通常の自己回帰デコーディングを回避している。Cloudflareによれば、ClefはQwenバックボーンを通じてprefillのみのパスを実行し、その後、有効なすべてのスキーマ選択肢を並列にスコアリングする。

特化したルーティングヘッドが、入力状態を各質問および選択肢に接続する。モデルが最終スコアを生成する前に、質問同士で情報をやり取りすることもできる。この設計により、複数の関連する意思決定が同じエンコード済みコンテキストを共有できる。

公開されたClefモデルのウェイトには、バックボーン、統合スキーマヘッド、設定、補助コードが含まれる。より小規模なClef-flashモデルも同じ基本構造に従い、Apache 2.0ライセンスで提供される。

オープンウェイトは競争の構図を変える。開発者はファイルを検査し、自社インフラ上でモデルを実行し、量子化版を作成し、すべての入力をCloudflareに送信せずに機密性の高いワークロードをテストできる。

ただし、ローカル運用には依然として相当なハードウェアが必要となる。Cloudflareのモデルカードによると、Clef-flashは単一のH200 GPUでテストされた。このリリースはセルフホスティングを可能にするが、90億パラメータのマルチモーダルモデルをすべての組織にとって軽量にするわけではない。

Workers AIはマネージドな利用経路を提供する。Cloudflareは両モデルをホストし、JevのSystem One APIと互換性のあるインターフェースを公開している。そのため、既存のJev実験では、リクエスト形式全体を再設計せずにClefを試せる。

この互換性は戦略上重要である。Cloudflareは、開発者にまったく新しいカテゴリやプログラミングモデルの採用を求めているわけではない。Jevが最近定義したカテゴリに参入し、プロバイダー比較に必要な作業を軽減している。

Cloudflareは、具体的な社内ユースケースも提示している。同社のThreat Intelligenceチームは、モデルが評価する前にBrowser Runでウェブページを取得・レンダリングし、Clefをウェブサイト分類にテストした。

Cloudflareの例では、Clefはファッション、eコマース、フィッシングなどのカテゴリに対する確率を返した。ワークフロー全体は2.2秒で完了し、gpt-oss-120bでは4.7秒だった。

このテストでは、汎用モデルが返した分類は2つだけだった一方、Clefは事前定義されたカテゴリを評価した。この比較は意図された利点を示すものだが、ワークロード全体における普遍的な速度比を確立するものではない。

2つのシステムは、異なる出力メカニズムでタスクを解いていた。入力サイズ、スキーマ設計、提供条件、要求された出力はいずれも結果に影響し得る。

より妥当な結論は限定的だ。制約付き選択肢をスコアリングするよう設計されたモデルは、不要な文章の生成を避けられる。これは、遅延が積み重なる反復的な意思決定において、信頼できるコンポーネントになり得ることを意味する。

Clef対Jevはエージェント制御層をめぐる戦い

Cloudflareは、Jevのインターフェースを模倣しつつ、オープン性、マルチモーダル入力、ベンチマークスコア、インフラ配信で競争することでJevに圧力をかけている。

TypeSafe AIは9月15日、初のSystem OneモデルとしてJevを発表した。同社はこのモデルを、会話的な応答ではなく、型付き出力と較正された信頼度を備えた、ソフトウェア向けの高速な意思決定エンジンと説明した。

Jevは、Cloudflareが現在使う語彙の確立に寄与した。そのAPIは構造化された質問を受け取り、選択肢、スコア、または確率を返す。ワークフローには、分類、ルーティング、評価、自動分岐が含まれる。

TypeSafeのJev発表は、汎用言語モデルが人間向けの応答に最適化されていると主張する。これに対しJevは、自由形式の生成が遅延やパースの問題を生む、頻繁なソフトウェア上の意思決定を対象としている。

Cloudflareはその影響を明確に認めている。同社のモデルは互換APIを実装し、ベンチマークスイートにはJev Decision IndexとTypeSafeのワークフロー評価が含まれる。

このため、Jevは汎用的な大規模言語モデル群ではなく、主たる競合相手となる。ClefとJevは、決定論的なルールと自由度の高い推論の間にある同じ立ち位置を目指している。

意思決定を正確に表現できる場合、ルールは有効に機能する。タスクに計画、説明、統合が必要な場合には、汎用モデルが役立つ。意思決定モデルは、言語理解は有用である一方、出力の選択肢は既知であるという曖昧な中間領域を対象とする。

Cloudflareによると、BFCLのcase-exact評価ではClefが98.47、Clef-flashが98.76、Jevが95.75に達した。API-Bankの精度では、Clefが91.93、Clef-flashが93.11、Jevが88.19だった。

結果はテストごとに異なった。報告された請求書処理ワークフローでは、Clefが64.7でJevの61.8を上回った。カスタマーサービスでは、Clef-flashが77で、Jevの76をわずかに上回った。

エージェントトレースの可観測性では、Jevが依然として先行した。Jevは71.6を記録し、Clef-flashは69.8、Clefは68.5だった。すべてのワークロードで首位となったモデルはなかった。

レイテンシーは、最も明確に主張された差を生んだ。43の評価全体で、CloudflareはClefの中央値レイテンシーを209.3ミリ秒、Clef-flashを38.8ミリ秒と報告した。Jevは524.1ミリ秒と測定された。

そのため、Clef-flashは高速な制御モデルとして特に積極的な存在に見える。報告された中央値はJevの10分の1未満だったが、Cloudflareが評価環境を管理し、その比較を公開している。

Layaは報告上5.8ミリ秒でより高速だったが、掲載された複数のテストでは品質スコアが大幅に低かった。この結果は、このカテゴリの中心的なトレードオフを裏付ける。モデルの確率が信頼できる場合にのみ、レイテンシーは価値を持つ。

Cloudflareはインフラ面での優位性も主張している。Workers AIは、ネットワーク上で稼働するアプリケーションの近くに推論を配置でき、モデル呼び出しを取り巻く通信時間を短縮できる。

ネットワークの近接性は、計算時間、コールドスタート、混雑、地域ごとのハードウェア制約をなくすわけではない。それでも、意思決定が対話型製品のクリティカルパスに組み込まれる場合には重要になり得る。

請求書を処理するエージェントを考えてみよう。文書を分類し、担当チームを特定し、ポリシー例外をフラグ付けし、人間による承認が必要かを判断するかもしれない。ワークフローが目に見える行動を実行する前に、複数のモデル呼び出しが発生する可能性がある。

同じパターンはセキュリティにも見られる。エージェントは、ツールリクエストがユーザーの目的に合致するか、機密情報に触れるか、承認された境界の外部へデータを送信するかを確認できる。

各チェックは限定的だが、合計数は大きくなり得る。高速なモデルは、すべてのステップでフロンティア推論モデルを使うよりも、継続的なレビューを実用的にする。

これは、ClefがJevを置き換えることや、オープンウェイトの勝利を証明することを意味しない。TypeSafeはモデル、学習データ、提供スタックを改善できる。また、ソフトウェアが信頼度しきい値に基づいて行動する場合、較正は生の精度よりも重要であるため、較正によって差別化することもできる。

CloudflareのAPI互換性は、双方向の切り替えコストを下げる。開発者は同じ概念的ワークフローを複数のプロバイダーで実行し、非公開データで結果を測定できる。

この可搬性はJevに圧力をかける。また、顧客がアプリケーションを作り直さずに意思決定の質を比較できるため、Cloudflareが配信力だけに依存することも防ぐ。

OpenAIとAWSは補足的な文脈を提供する。OpenAIは事前定義された選択肢向けの限定プレビュー版Decisions APIを導入し、AWSは実験的なStrands Deciderモデルを公開した。

これらの参入は、独立した意思決定層への需要を裏付けている。ただし、両製品が密接に整合したインターフェースを通じて型付き確率を公開しているため、Clef対Jevの比較が最も明確な競争であり続ける。

勝者は、発表初週のベンチマーク平均で決まるものではない。本番環境の導入企業が重視するのは、誤った承認、不必要なエスカレーション、応答の一貫性、ハードウェア要件、そしてドメイン固有の学習後の挙動だ。

RLファインチューニングこそCloudflareのより大きな賭け

モデルは注目を集めるが、Cloudflareのより大きな目的は、ワークフローデータからカスタマイズされた意思決定モデルに至る完全な経路を支配することにある。

汎用的な意思決定モデルには、避けられない限界がある。公開モデルは、ある企業固有の承認ルール、不正利用のパターン、顧客カテゴリ、運用上の例外を把握していない。

小売企業とセキュリティプロバイダーでは、同じ言葉でも意味が異なることがある。ある組織では緊急に見えるリクエストが、別の組織では日常的なものかもしれない。適切に調整された公開確率であっても、こうした分布シフトの後には信頼性を失い得る。

Cloudflareの答えは、Clef向けの強化学習サービスだ。初期版では、顧客にフォワードデプロイされたエンジニアリングチームを組み合わせる。Cloudflareは、これらの取り組みを基にセルフサービスプラットフォームを開発する計画だ。

この違いには注意を払う必要がある。モデルはすでに利用可能だが、完全自動化されたトレーニング製品は、まだ成熟したセルフサービスの提供形態ではない。Cloudflareは複数の要素を開発中だと説明している。

提案されたシステムは、同社がすでに運用しているサービスを接続する。AI Gatewayはリクエストとレスポンスを取得し、顧客が実トラフィックからワークロードデータセットを構築できるようにする。

Workers AIはベースモデルに対するロールアウトを生成する。強化学習においてロールアウトとは、報酬や望ましい結果に照らしてスコアリングできる、一連のモデル挙動を指す。

Cloudflare Containersは、アクションの再現とスコア算出のための隔離環境を提供する。Trainerと呼ばれる新しいコンポーネントが、モデルの重みを更新する。

Workers AIとBring Your Own Modelは、その後の想定されたデプロイ先を提供する。Cloudflareは、顧客がデータを取得し、特化モデルをトレーニングして、そのまま同社プラットフォーム内で本番環境へ戻せるようにしたい考えだ。

したがって、完全なRLサービス設計は、オブザーバビリティ、コンピュート、隔離実行、重みの更新、サービングを結び付ける。Clefは、このスタックに特化した最初のワークロードである。

Cloudflareは、そのトレーニング目標をReinforcement Learning for Calibrated Decisions、略してRLCDと呼ぶ。TypeSafeもJevのトレーニング手法に同じ名称を使っており、競争関係はいっそう直接的になる。

Cloudflareによれば、その手法は予測が正しい順序尺度の選択肢に近い場合、部分的な評価を与える。重大度を「major」と評価した場合、モデルが「no impact」を選んだ場合よりも、正解が「critical」であった場合のほうが高く評価される可能性がある。

トレーニングプロセスでは、完全に正しい構造化レコードにも報酬を与える。参照ペナルティは、元のモデルの挙動から過度に離れることを抑える目的だ。

そのRL段階の前に、Cloudflareはラベルスムージング付きクロスエントロピーとBrier lossでモデルをトレーニングした。Brier lossは予測確率と観測結果の差を測定するため、キャリブレーションに関連する。

同社は、rank-256の低ランクアダプターとルーティングヘッドを最適化する一方で、主要なQwenバックボーンを固定した。低ランク適応では、すべてのモデル重みを更新するのではなく、追加された少数のパラメーターを変更する。

Cloudflareは、プロンプト表現、フィールド順、スキーマ構造にバリエーションを持たせた合成データも使用した。こうした置換は、モデルが一つの固定されたリクエストレイアウトに依存するのを防ぐことを狙う。

このアプローチは技術的に整合しているが、公的な証拠はなお不十分だ。Cloudflareは、ファインチューニング後の報告された信頼度が実世界での正確性をどの程度追跡するかを示す独立監査を公開していない。

このサービスはデータガバナンスの問題も生む。AI Gatewayはトレーニングを有用にするまさにそのトラフィックを取得できるが、リクエストには機密文書、顧客メッセージ、セキュリティイベント、個人情報が含まれる可能性がある。

Cloudflareは、通常のClefリクエストやレスポンスを閲覧、保存、トレーニングには使用しないとしている。ファインチューニングを選択する顧客には、事例がトレーニング素材になる必要があるため、必然的に別のデータ経路が必要となる。

組織には、同意、保持、アクセス、削除、地域内処理に関する精密な管理が必要となる。また、受け入れ可能なトレーニング事例と、決して再現してはならないインシデントを分離しなければならない。

Cloudflareのネットワーク事業の歴史は、関連する経験をもたらしている。同社によれば、不正利用、ボット、サポート、脅威インテリジェンスなどの領域で、15年以上にわたるラベル付き意思決定データを持つ。

その社内データが顧客のワークロードへ自動的に移転できるわけではない。しかし、ラベル収集や特化モデルの再デプロイに関する運用メカニズムをCloudflareが検証できる環境にはなる。

同社は、Trust and Safetyのレビュー、サポートのトリアージ、good botの分類を社内候補として挙げている。これらは既知のカテゴリに対する反復的な判断を伴うため、意思決定モデルの強力なユースケースだ。

ファインチューニングにはトレードオフがある。モデルは一つの領域で精度を高める一方、汎用性能の一部を失う場合がある。デプロイ境界が明示され、測定されているなら、この交換は許容可能だ。

特化モデルが静かに新しい責任を担うようになると、危険性が生じる。どちらのタスクも確率を返すというだけの理由で、ボット分類器がアクセス制御の権限主体になるべきではない。

チームには、バージョン管理されたデータセット、評価ゲート、ロールバック計画が必要となる。検索可能な技術ナレッジベースは、各モデルバージョンをポリシー、テスト、既知の制約へ結び付ける助けとなる。

したがって、RLプラットフォームはこの発表におけるより重要な部分である。Cloudflareが特化トレーニングを再現可能なものにできれば、Clefは継続的なインフラ関係への入口となる。

サービスがコンサルティング依存のままであれば、トレーニングプラットフォームよりもオープンモデルのほうが広く採用されるかもしれない。今後数か月で、開発者がローンチのどちらの側面を最も重視するかが明らかになるはずだ。

ベンチマークではキャリブレーションと制御への疑問が残る

高速な型付き出力はフォーマット上の失敗を減らすが、エージェントが選択されたアクションを信頼すべきことの証明にはならない。

意思決定モデルは、与えられたスキーマ外の値を生成できない。この性質により、不正なJSON、想定外のラベル、コードが小さな回答を期待する場面での長い説明を防げる。

しかし、モデルが許可された回答のうち誤ったものを選ぶことまでは防げない。完全に構造化された誤りも、やはり誤りである。

信頼度が自動化を制御する場合、この違いは重大になる。たとえば、ワークフローが信頼度90パーセント超のアクションを実行し、それ以外をすべてエスカレーションするとする。この閾値が意味を持つのは、類似の予測が10回中およそ9回正しいと証明される場合だけだ。

集計精度はその関係を確立しない。モデルは高い平均成績を達成しながらも、まれで重大なケースでは過信している可能性がある。

公開されたClefの評価は、多くのタスクにわたり品質とレイテンシを比較している。実験に有用な証拠を提供する一方、顧客ドメイン全体における各モデルのキャリブレーション曲線をすべて明らかにするものではない。

Cloudflare自身の結果にもばらつきが見られる。Clef-flashは一部タスクでより大きなモデルを上回る一方、エージェントトレースのオブザーバビリティではJevが先行した。こうした差は、モデル規模が普遍的な順位を生み出すわけではないことを示唆している。

プライベートなワークフローでは、さらに大きな変動が生じる。業界用語、多言語メッセージ、曖昧なカテゴリ、敵対的入力はいずれも、性能を公開結果から乖離させ得る。

スキーマ設計も別の誤差要因となる。二つの選択肢が重複していれば、モデルはそれらに確率を分散させる可能性がある。正しい選択肢が存在しない場合でも、残りの選択肢に確率を配分しなければならない。

明示的な棄権経路が役立つ可能性がある。開発者はunknown、insufficient context、require human reviewのような選択肢を含め、それらをモデルが適切に使うか検証できる。

周辺アプリケーションは、アクションの重大度も評価すべきだ。公開ウェブページの閲覧には、レコードの削除や私的情報の送信と同じ信頼度閾値は必要ない。

決定論的な制御は依然として必要である。権限、支出上限、宛先制限、不可逆な操作は、学習された確率だけに依存すべきではない。

意思決定モデルは、ポリシーシステム内のシグナルとして機能するときに最も力を発揮する。乱雑な入力を解釈し、不確実性をルーティングできる一方で、コードは動かしてはならない境界を強制する。

プロンプトインジェクションも依然として重要だ。エージェントは、読むモデルを操作しようとする文書に遭遇する可能性がある。Clefの制約された出力はレスポンスの形式を制限するが、悪意のあるコンテンツは依然として最高スコアを得る選択肢に影響を与え得る。

信頼できる指示、信頼できないコンテンツ、提案アクション、ツールメタデータは、構造的に分離されたままであるべきだ。影響の大きい意思決定には、敵対的事例を含む評価が必要となる。

マルチモーダル入力は有用性と攻撃対象領域の両方を広げる。Clefはスクリーンショット、文書、動画を分類できるが、視覚的な指示にも誤解を招く、あるいは隠されたコンテンツが含まれる可能性がある。

Cloudflareの64,000トークンのコンテキストウィンドウは、より大きな状態を扱えるようにする。長い入力は必要な証拠を提供できる一方、決定的な事実からモデルの注意をそらす無関係な情報も増やし得る。

オープンリリースは、開発者がこうした問題を調査する助けとなる。実装を検査し、プライベート評価を作成し、ローカル結果をホスト型推論と比較できる。

オープンウェイトは完全なトレーニング透明性を提供しない。Cloudflareは目標と合成データ戦略を説明しているが、あらゆる挙動を再現するために必要な完全なトレーニングデータセットは公開していない。

セルフホスティングでは責任も移転する。組織はモデルサーバーを保護し、ハードウェアを選定し、レイテンシを監視し、更新を管理し、量子化バリアントを検証しなければならない。

マネージドWorkers AIは、その運用負担を軽減する。その代わり顧客は、Cloudflareのサービング環境と可用性保証を信頼する必要がある。

どちらの選択肢も、評価の必要性をなくすものではない。チームは入力状態、スキーマ、モデルバージョン、確率、選択されたアクション、エスカレーション経路、最終結果を記録すべきだ。

こうしたログはドリフト検出を支える。デプロイ時に優れた性能を示したモデルでも、製品、ポリシー、ユーザー行動が変化するにつれて信頼性が低下する可能性がある。

ファインチューニングはドリフトを修正できるが、直近の事例へ過剰適合する可能性もある。評価セットはトレーニングデータから分離したままにし、通常のトラフィックでは十分に表れないまれな失敗を含めるべきだ。

したがって、Cloudflareのベンチマーク上の優位性は出発仮説にすぎない。同社はClefがJevとの比較に値することを示したのであって、すべてのエージェントアクションを制御する準備ができていることを示したわけではない。

最も安全な初期デプロイは、可逆的な選択を伴うものだ。チケットルーティング、文書トリアージ、関連性フィルタリング、モデル選定は、分類器に不可逆な権限を与えずに測定可能な成果を提供する。

Cloudflare Clefで次に注目すべきこと

Clefが持続的なエージェントインフラになるのか、あるいは短命なモデルリリースの一つに終わるのかは、三つのシグナルが示す。

第一のシグナルは、独立したベンチマークの再現だ。研究者や開発者は、未知のデータ、一貫したハードウェア、同一のリクエストスキーマで比較を再実行する必要がある。

その作業では、平均精度以上のものを測定すべきだ。キャリブレーション誤差、誤った承認、エスカレーション率、多言語性能、敵対的入力下での挙動は、運用用途ではより重要になる。

安定した結果は、Clefがより優れた品質とレイテンシのバランスを提供するというCloudflareの主張を補強するだろう。同社が公開したスイートの外で大幅に性能が落ちれば、トレーニング品質こそが依然として難しい優位性だとするJevの主張に有利となる。

第二のシグナルは、フォワードデプロイ支援からセルフサービスRLプラットフォームへの移行だ。Cloudflareは、顧客が長期のコンサルティングプロジェクトなしにデータセットを作成し、報酬を定義し、安全にトレーニングし、バージョンを評価し、再デプロイできることを示す必要がある。

信頼できるプラットフォームは、データリネージ、評価ゲート、プライバシー管理、ロールバック支援、モデルバージョン履歴を公開すべきだ。結果として得られる確率がビジネスアクションを制御する以上、トレーニングを単一のボタンとして扱うことはできない。

顧客事例は重要になるが、測定可能な成果を含めるべきだ。有用な証拠としては、ファインチューニング前後のエラー率、レイテンシ、エスカレーション件数、パフォーマンスを比較する必要がある。

3つ目のシグナルは競合の反応だ。TypeSafeは、より強力なキャリブレーションの証拠、高速な推論提供、改善されたマルチモーダル対応、あるいはプライベートデプロイメントの選択肢によってJevを守ることができる。

OpenAIとAWSもまた、Cloudflareの優位性を狭められる。主要なエージェントプラットフォームに直接統合された意思決定サービスは、別のモデルが単独のベンチマークでより優れた性能を示した場合でも、開発者を引き付ける可能性がある。

Cloudflareの強みは垂直統合にある。AI Gatewayはワークフローを観測でき、Containersは制御されたロールアウトを支え、Trainerは重みを更新し、Workers AIは結果を提供できる。

同じ統合は集中リスクも生み出す。顧客は、トラフィックの取得、トレーニング、デプロイメント、エージェントを統制する実行時の意思決定を、1つのプロバイダーに依存することになるかもしれない。

オープンモデルは逃げ道を提供するが、組織がそれらを効果的に運用できる場合に限られる。したがって、ファインチューニング済み重みの実務上の可搬性は、ベースリリースのApache 2.0ラベルと同じくらい重要になる。

開発者は決定的な勝者を待つ必要はない。繰り返し発生し、元に戻せる意思決定を1つ選び、Clef、Clef-flash、Jev、従来型の分類器、小規模な生成モデルを、同じ非公開の例でテストできる。

有用なパイロットには、明示的なエスカレーションの選択肢と、より強力なフォールバックモデルを含めるべきだ。チームは、カテゴリーの変更、欠落したコンテキスト、誤解を招く入力、そして提示された回答のどれも当てはまらないケースをテストすべきである。

Cloudflare Clef decision modelsは、ホスト型とオープンウェイトの両方の経路が利用できるため、この実験を容易にする。そのより大きな意義は、Cloudflareが期待される確率を信頼できる運用上の成果へと変えられるかどうかにかかっている。

エージェントのワークフローにおいて、専用モデルを正当化できるほど頻繁に発生する意思決定はどれであり、その確率にアクションを起こさせる前に、どのような証拠を求めるだろうか？