オープンウェイトAIモデルがフロンティアに追いついている。安全性のギャップは残る。

1年前、クローズドなフロンティアモデルとオープンウェイトの対応物との間のギャップは乗り越えられないように感じられていました。今日、そのギャップはほとんどの研究者の予測よりも速く縮まっており、オープンウェイトAIモデルはベンチマーク後ベンチマークでパックの最前線に追いついています。しかし、機能的な同等性が近づくにつれて、より難しい質問が浮かび上がります。安全性は同じペースで進んでいるのでしょうか？

何が起きたのか

オープンウェイトモデルの軌跡は劇的にシフトしました。クローズドモデルを狭いコーディングまたは推論ベンチマークで一致させるための競争として始まったものは、より広いものへと進化しました。米国、ヨーロッパ、中国全体の研究機関とテクノロジー企業からの最近のリリースは、オープンウェイトモデルが命令追従、多段階推論、そして一度は最も高価な独占的システムの排他的領域に感じられたある種の創造的なタスクで競争できることを実証しています。

パターンは一貫しており、十分に文書化されています。フロンティアラボがクローズドモデルを出荷し、新しい機能の上限を確立し、数ヶ月以内に（時には数週間で）、同様のアーキテクチャとテクニックで訓練されたオープンウェイトモデルがほとんどの距離を閉じます。その後、コミュニティはそのモデルを微調整、量子化、デプロイし、研究クラスターからコンシューマーラップトップまで、あらゆる場所に展開します。

同じペースで進んでいないのは安全性インフラストラクチャです。クローズドモデルは広範なレッドティーミング、憲法的AI技術、害回避のために特別に調整された人間からのフィードバックからの強化学習、および継続的な監視パイプラインを備えて出荷されます。オープンウェイトモデルは、その性質上、それらのガードレールが付属していない状態で出荷されます。重みが製品です。それで何をするか、そしてそれをどのように安全にデプロイするかは、完全にオペレーターに任されています。

これはオープンウェイト開発の批判ではありません。これは構造的な現実です。モデルの重みを公開でリリースする場合、ダウンストリームで発生する微調整を制御することはできません。研究者は、オープンウェイトモデルに適用された安全性微調整が、比較的控えめなコンピュートと小さな敵対的例のデータセットで取り除かれることができることを繰り返し示しています。機能はそこにあります。安全性レイヤーはオプションであり、したがって脆弱です。

その結果、最も有能なオープンモデルが本当に印象的であり、同様の機能レベルでのクローズド同等物よりも不注意にデプロイするのに本当に危険である風景です。

アジアにとって重要な理由

このストーリーにおけるアジアの位置は周辺的ではありません。流通している最も有能なオープンウェイトモデルの一部は、中国のテクノロジー企業と研究機関から出ています。東南アジア、インド、日本、韓国全体の開発者は、これらのモデルの最も活発な微調整者とデプロイヤーの中にいて、数億人のユーザーにサービスを提供する製品を構築しています。

これは地域に固有のいくつかの理由で重要です。まず、アジアの規制枠組みは断片化されています。EU AI法は、ヨーロッパのデプロイメントのための比較的統一された（不完全ですが）ベースラインを確立しています。アジアには同等のものがありません。シンガポールの開発者は、インドネシア、ベトナム、または日本の開発者とは異なる期待の下で運営されています。その断片化は、オープンウェイトモデルの安全性ギャップがあなたが構築している場所に応じて異なる方法で着地することを意味します。そして、最も危険なデプロイメントをキャッチするための共通の床はありません。

第二に、アジアの開発者エコシステムは、基礎研究よりも実践的なデプロイメントに不釣り合いに焦点を当てています。地域の創業者とエンジニアが尋ねている最も一般的な質問は「より安全なモデルをどのように訓練するか？」ではなく、「利用可能な最良のモデルを使用してより速く出荷するにはどうすればよいか？」です。オープンウェイトモデルはこのユースケースに非常に魅力的です。APIコストなし、レート制限なし、スタック全体の完全な制御、および第三者のサーバーに送信することなく独自データで微調整する機能。

これらは実際の利点です。しかし、それらはアジアのテック企業が真剣に対処し始めたばかりの実際の責任を伴います。ジャカルタやホーチミンシティのスタートアップが消費者向け製品で微調整されたオープンウェイトモデルをデプロイする場合、そのデプロイメントの安全性プロパティは完全に彼らの責任です。フロンティアラボの安全チームが微調整とユーザーの間に立っていません。

第三に、言語と文化的文脈は問題を複雑にします。オープンウェイトモデルのほとんどの安全性研究とレッドティーミングは英語で実施されています。英語の敵対的プロンプトで合理的に動作するのと同じモデルは、バハサインドネシア語、タイ語、またはベトナム語でプロンプトされた場合、非常に異なる動作をする可能性があります。これらの言語では安全性微調整データが少なく、評価をより厳密に実施することが難しくなります。

開発者にとってこれが意味すること

ローカル推論を実行している場合、クラウドインフラストラクチャにデプロイしている場合、または特定のドメイン用に微調整している場合、オープンウェイトモデルで構築している開発者の場合、安全性ギャップはあなたが解決する問題であり、他の誰かの問題ではありません。これはクローズドモデルパラダイムからの大きなシフトであり、スタックについてどのように考えるかについて異なるメンタルモデルが必要です。

具体的に内面化する価値のあることがいくつかあります。

安全性微調整は1回限りのステップではありません。オープンウェイトベースモデルにRLHFまたは憲法的AI技術を適用する場合、機能の微調整を続けると、それらのプロパティが低下する可能性があります。タスクパフォーマンスのために最適化するすべてのトレーニング実行は、アライメントプロパティを侵食する可能性があります。初期デプロイメント時だけでなく、継続的に安全性プロパティをテストする評価パイプラインが必要です。

システムプロンプトは安全性レイヤーではありません。システムプロンプトを介して「有害なトピックについて議論しない」ようにモデルに指示することは、ガードレールではなく速度低下です。控えめなプロンプトエンジニアリングスキルを持つ敵対的ユーザーは、システムプロンプトベースの制限を回避できます。アプリケーションに意味のある安全要件がある場合、それらは出力フィルタリング、レート制限、および動作監視を含む複数のレイヤーで実装される必要があります。

機能と安全性のギャップはモデルサイズでスケーリングされます。コンシューマーハードウェアで効率的に実行される小さな量子化モデルは、一般的に完全精度の対応物よりもジェイルブレイクしやすくなります。安全性微調整は低いパラメータ数でより脆弱になる傾向があるためです。推論コストを削減するために量子化モデルをデプロイしている場合、それを脅威モデルに組み込んでください。

ターゲット言語での評価は譲歩できません。ユーザーが主に英語以外の言語で製品と対話する場合、安全性評価はその言語で行われる必要があります。英語のレッドティーミング結果は確実に転送されません。これはより広いオープンソースコミュニティが重大な盲点を持っている領域であり、アジア市場向けに構築している開発者が独自の努力に投資する必要がある領域です。

MonstarXで構築しているチームの場合（アジアのAIネイティブ開発プラットフォーム）、これらの考慮事項は、本番デプロイメントがどのように構造化されるかについてますます中心的です。プラットフォームのコネクタにより、モデル出力をエンドユーザーに到達する前に外部安全分類器またはコンテンツモデレーションAPIを通じてルーティングすることが簡単になり、開発者にスタック全体を再構築することなくオープンウェイトデプロイメントの上に安全レイヤーを追加するための実用的なメカニズムを提供します。

より広い点は、オープンウェイトモデルが同時に力と責任を与えるということです。これらのモデルの上に最も耐久性のある製品を構築する開発者は、安全性インフラストラクチャを一流のエンジニアリング上の懸念として扱う人です。事後的ではなく、モデルプロバイダーが解決するのを待っていません。

主要なポイント

オープンウェイトの収束