ゲートウェイがプロンプトとcompletionをログに残した瞬間から、そこにはカスタマーサービスエージェントのユーザーがチャットボックスに打ち込んだものすべてが保持される。住所かもしれず、口座番号かもしれず、自分の健康についての苦情かもしれない。このシリーズの他のすべての決定は、コストとレイテンシ、あるいは制御と利便性を天秤にかけてきた。この決定はデバッグ可能性とデータ保護義務を天秤にかける。そして最後に置かれているのは、他のすべてがすでに揃っていることを必要とする決定だからだ。第9回でプラットフォームは出荷できるようになった。本稿でシリーズを締めくくる。何を記録するか、何を監視するか、規制は何を問うか、そして第1回の数字は実際に動いたのか。

3つのレイヤーと、自分で作るしかない1つ

プラットフォームはいま3つの場所からテレメトリを発しており、それらを混同することこそ、互いに食い違う3つのダッシュボードをチームが抱え込む経緯だ。

  • Gateway telemetry。第5回のtenant、モデルalias、環境のディメンションを付けたtokenメトリクスをApplication Insightsへ、リクエストログをAzure Monitorへ。誰が何を呼び、いくらかかったかについての正式なビューであり、すべての同期リクエストを見る唯一のレイヤーだ。
  • アプリケーションのテレメトリ。orchestrationレイヤー自身のトレース。どのツールが実行されたか、ループが何回まわったか、どの取得ドキュメントがプロンプトに入ったか。LangSmithやOpenlayerのようなLLM特化のツールはここに属し、すでにDataikuを使っているデータサイエンスチームは同じデータへの独自のビューを欲しがるだろう。これらはどれも、それを発するアプリケーションを通らないトラフィックを見ない。誰かがこれをプラットフォームの信頼できる唯一の情報源として提案するたびに、声に出して言う価値のある点だ。
  • モデルと安全性のシグナル。content safetyのブロック、拒否、発火したフィルターカテゴリ。これらはゲートウェイポリシーから来るものであり、アプリケーションレイヤーではなくゲートウェイレイヤーに属する。アプリケーションが誤動作してもなお効くことこそが眼目だからだ。

プラットフォームチームが所有し、他の誰も作らないレイヤーがjoinだ。1つのcorrelation IDがユーザーインタラクションを3つのレイヤーすべてにわたって追いかけ、4つのツール呼び出しと1つのcontent safetyブロックを引き起こした1つの質問が、6つの無関係なレコードではなく、クエリの中で1つのものになる。第8回はそのIDをログレコードに入れた。これがその目的だった。

何をログに残し、何を残さないか

プロンプトとcompletionのログは純粋に有用だ。悪い回答をデバッグする手段であり、実トラフィックからgolden setを構築する手段であり、誰かが異議を唱えたときにシステムが何を言ったかを証明する手段だ。同時にそれはログストアを、機微性が不明なユーザー生成コンテンツのリポジトリに変え、ログの行き先すべてに複製する。

成り立つ立ち位置はグローバルではなくプロダクト単位であり、プラットフォームが全員に代わって下す決定ではなく、コンシューマーチームがプラットフォームとともに下す決定だ。

  • 常にログに残すのはメタデータだ。tenant、alias、解決済みのdeploymentとバージョン、tokenカウント、レイテンシ、ステータス、キャッシュヒット、content safetyの結果、correlation ID。どれもユーザーコンテンツではなく、そのすべてが運用上の問いに答える。
  • コンテンツは例外としてログに残す。retentionはメタデータより短くし、オプトインしたプロダクトに限定し、第5回が要求した通りsubscription keyをリクエストから取り除いた上で。
  • コンテンツログが有効な場所では、全量キャプチャではなくsamplingを。代表的なサンプルはほとんどの目的で全量キャプチャと同等にデバッグの役に立ち、露出をその分だけ減らす。

retention期間と法的根拠は、chargebackモデルと同じドキュメントに書くこと。何を、どれだけの期間、なぜ保持しているかを正確に言えるプラットフォームはデータ保護レビューを生き残る。言えないプラットフォームはログを丸ごと止めるよう命じられ、その方がはるかに高くつく。

pipelineの中だけでなく、本番でのeval

第9回のeval gateが答えるのは「この変更は出荷して安全か」だ。「システムはいまも良い状態か」には答えない。本番トラフィックはgolden setではなく、そこから継続的に離れていくからだ。

メカニズムは2つあり、答える問いが違う。スケジュールされたevalはgolden setをタイマーで本番構成に対して実行し、誰もデプロイしていないもののドリフトを捕まえる。ピン留めにもかかわらず動いたモデルバージョン、違うかたちで再インデックスされたインデックス、遅くなったretrieval経路。サンプリングされたオンライン評価は実トラフィックの小さな割合を、通常はmodel-as-judgeでスコアリングする。golden setに一度も含まれなかった種類の失敗に気づける唯一の方法だ。golden setは定義上、すでに知っていた失敗でできているのだから。

どちらも結果の置き場所が必要で、それは他のすべてと同じ場所だ。tenantとaliasのディメンションを持つスコアを、支出やレイテンシと同じダッシュボードに置く。別のツールに住む品質の数字は、インシデントの間だけ見られ、それ以外の時間は無視される。

ガバナンス、そして規制が実際に問うもの

EU AI Actの下では、この会社が運用しているものの大半はhigh-riskではなくlimited-riskであり、それに伴う義務は認証よりも透明性とトレーサビリティに関するものが中心だ。だからといってガバナンスをドキュメント作成の演習として扱ってよいわけではない。監査人が尋ねる問いは、プラットフォームが記録しているか、していないかのどちらかであるものに、ほぼ正確に対応するからだ。

  • どのモデルが、どのアプリケーションで、どのバージョンで使われているか? model catalogとaliasマップが答える。それらがなければアンケート調査になる。
  • どのデータがどのプロバイダーへ行き、どこで処理されたか? backend poolの構成とリクエストログがリクエスト単位で答える。これは特定リージョンについてのデータレジデンシーの問いへの答えでもある。
  • どの安全性コントロールが有効で、それは発火したか? content safetyポリシーはリポジトリでバージョン管理され、その結果はリクエスト単位でログに残る。
  • 誰が何を呼べたか、それはいつ変わったか? tenant設定はTerraformなので、答えは記憶ではなくgit履歴だ。
  • 特定のインタラクションを再構成できるか? そのプロダクトでコンテンツログが有効だった場合に限る。まさにこれが、あの決定がプロダクト単位であり、暗黙ではなく文書化される理由だ。

持ち帰るべき要点はこうだ。これらの問いをそもそも答えうるものにしているのがゲートウェイだ。5つのアプリケーションが5つのモデルエンドポイントを直接呼んでいれば、各問いに5つの異なる答えが生まれうる。それらを突き合わせる労力こそ、プラットフォーム投資が取り除いたコンプライアンスコストだ。

スコアカード

第1回は5つの目標を掲げた。きれいに着地しなかったものも含めて、正直に採点する。

  • すべてのプロダクトオーナーが自分のtoken支出を1日以内に見られる。達成。ただし第3回の精度クラスをレポートに明記した上でだ。非ストリームとバッチは正確、ストリームは推定で、残差は公表されている。
  • どのアプリケーションも長命なモデルクレデンシャルを保持しない。達成。アプリケーションが持つのはEntra IDのclient credentialとプロダクトのsubscription keyで、どちらもモデルエンドポイントには届かず、失効は設定変更だ。
  • 引退通知は調査ではなくクエリを生む。達成。ただし必要だったのはツールではなく、3つの先行する決定だ。ピン留めされたバージョン、alias、そして解決済みdeploymentのリクエスト単位のログ。
  • あるtenantが別のtenantのquotaを使い果たすことはできない。同期トラフィックについては、subscription単位のカウンターキーで達成。バッチはコントロールプレーンが唯一の投入者であることで抑えられているが、これは強制されたコントロールではなくプロセス上のコントロールであり、そのギャップは取り繕うのではなく名指しすべきだ。
  • 非キャッシュ呼び出しのゲートウェイレイテンシが95パーセンタイルで60ms未満。これは仮定ではなく測定すべき数字であり、別の理由で行われた選択に最も敏感な数字だ。content safetyチェックはモデルの前に1回の呼び出しを足し、semantic cacheのルックアップはembedding呼び出しを足す。どちらも正当な理由で採用され、どちらもミリ秒を費やす。すべてを足したまま再測定しなかったプラットフォームは、静かに自分自身のSLOを変えている。

これに何がかかったか、そして割に合わないのはいつか

この節がなければシリーズは不誠実だろう。中央ゲートウェイとは、プラットフォームチームであり、負荷ではなくスキーマのために選ばれたtierのAPI Managementインスタンスであり、後から追加できないモジュールを積んだRedisキャッシュであり、2つの目的を担うembeddings deploymentであり、本物のオンコールを伴う本物のサービスであるコントロールプレーンだ。これは固定費であり、その対価として帰属、ガバナンス、そしてライフサイクルの物語を買う。

コンシューマーアプリケーションがおよそ3つを下回るなら、割に合わない。ゲートウェイが取り除くはずの調整コストがまだ存在せず、同じ規律は共有Terraformモジュールと取り決めで手に入る。しきい値はtoken数ではない。モデルへのアクセス方法の変更に複数のチームの行動が必要になる時点だ。そこが、2つ目の扉が最初の扉より高くつき始める場所だ。

次に読む

これを大規模に運用する際のインフラおよびプラットフォーム側の話はercan.cloudのフィールドノートに、ハブはercanermis.comにある。

参考資料