モデルがノーと言うとき

今週、私たちのエラーレポートが想定していなかった拒否のクラスを検出しました。 歴史的あるいは政治的にセンシティブな話題では、リクエストが明らかに正当であっても、 モデルプロバイダーのAPIはcompletionではなくコンテンツポリシーによる拒否を返します。 その拒否は私たちの層ではなくプロバイダー自身の層のもので、ユーザーにはほぼ確実に 読めない言語の生のエラーボディが表示されていました。

フィルターは1つではなく2つ

OnePressのすべてのプロンプトは、まず私たち自身の入力スクリーニングを通ります。 これは決済プロセッサーとの契約上の要件であり、妥当なものです。今回のリクエストは それを正しく通過します — 明らかに正当な作業こそ、そのまま通るべきトラフィックだからです。

拒否は、私たちにもユーザーにも制御できない2つ目のフィルターから来ていました。 モデルプロバイダー自身のプラットフォームレベルのコンテンツスクリーニングで、 モデルの上に載ってトラフィックを検査します。政治的にセンシティブな主題に触れる リクエストは、ある法域のコンプライアンス層が安全でないとみなす領域に入ります。 同じリクエストが、他のどこでも完全に普通の作業であるにもかかわらず。

有益な発見：フィルターはモデルの中にいない

ここが私たちのアーキテクチャを変えた部分です。私たちは自分たちで同種のリクエスト — 同じクラスのコンテンツ — をまったく同じモデルの重みに送りました。ただし 別のホスト経由です：OpenRouter経由で、米国の推論プロバイダーにルーティングしました。 同じ重み、同じクラスのプロンプト。完全な生成、拒否なし。

つまり拒否はモデルの中に存在したことはありません。それはサービング層 — プロバイダーがAPIの周りに被せるコンプライアンスのラッパー — にいるのです。 ということは、モデルに一切触れずに、クリーンかつオープンにルーティングで 回避できるということです。

変更した内容

• すべてのモデルがピッカーに2つずつ存在するようになりました。 デフォルトのセットはOpenRouter経由で中国本土以外の推論プロバイダーにルーティング されます。同じ4つのモデルはホームAPI上でも引き続き利用でき、(CN)ラベル付きで、 そちらを好む人のために残しています。
• OpenRouterリクエストは上流の許可リストを携帯します。 リクエストを指名したプロバイダーに固定し、フォールバックを無効にしています — 固定リストが応えられない場合、呼び出しはフィルター済みの経路に静かに着地する 代わりに、はっきり失敗します。
• プロバイダーの拒否は読めるメッセージを出すようになりました。 コンテンツポリシーによる拒否は平易な言葉で説明し、モデルピッカーへ誘導します — ユーザーが読めない言語の生エラーの塊はもうありません。ストリームの途中に埋め込まれた エラーフレーム — 以前は飲み込まれて空の返信に見えていたもの — も正しく表面化します。
• バックグラウンドタスクも移行しました。 タイトルと要約の生成は同じ会話コンテンツを読むため、同じOpenRouterエンドポイントを 使います。

正直な境界線

名指しする価値のある妥協が2つあります。1つ目、すべてのモデルにフィルターなしの 経路があるわけではありません：Qwenのホスト型flashティアはAlibaba自身の上流の 後ろにしか存在しないため、Qwen用のOpenRouterスロットはオープンウェイトの27B バリアントを実行します — 別のモデルであり、私たちは正直にラベル付けしています。 2つ目、固定することで、許可リストが完全に失敗した場合はフィルター済みの経路に 劣化するのではなくエラーを返します。これは意図的な選択です：目に見える失敗は、 目に見えない会場変更に勝ります。

より大きな妥協は哲学的なものです。国際的なプロダクトにとって、デフォルトの経路は おそらく単一の法域の編集方針を何も引き継ぐべきではありません — フィルターが悪意を 持つからではなく、その「センシティブ」の定義が別の読者層のために書かれたものだ からです。デフォルトは今や、プロバイダーではなくユーザーの文脈を前提とします。