AIシステムはモデルのせいで生産で故障することはほとんどありません.

よりよく、それらは彼らの下にあるインフラが全く異なる種類のワークロードのために設計されていたからです。

本番環境では、AI処理負荷が変動遅延、再試行、並行性の急増、バックプレッシャー、マルチテナントアクセス制御問題を引き起こし、従来の同期システムがきれいにモデル化するのに苦労します。デモはHTTPのリクエスト-レスポンスチェーンで動作しても、本番はデモではありません。

同時に数千人のユーザーがクエリを提出し、LLMが8秒かけて応答する。これは埋め込みサービスがリミットに達していて、インジェストトラフィックが続いている状態である。これはリトライされたリクエストがベクトordベースデータベースで重複した埋め込みを誤って作成したものだ。これはエンタープライズユーザー、標準タイプのユーザー、無料タイプのユーザーが同時に同じシステムにクエリを実行し、承認された情報のみを見ることができることを期待している。

それらはモデルの問題ではありません。それらはインフラストラクチャの問題です.

そしてインフラストラクチャの問題にはインフラストラクチャの解決策が必要です.

AI Workloads Do Not Behave Like Traditional APIs

本番のRAGパイプラインは単一のAPIコールではありません。それは異なる遅延特性、スループット制限、失敗モードを持つ非同期操作の連鎖です。

ドキュメントのチャンクが到着し、外部API呼び出しを通じて埋め込み処理が必要です。埋め込みはベクトルデータベースに格納されます。ユーザーのクエリが別の埋め込みリクエストをトリガーし、その後類似性検索、コンテキストの組み立て、および数秒かかるLLM推論ステップが実行されます.

重要なのは、これらのステップが独立していることです。

エンコーディングが遅くなっても、インジェストが必要です。クエリ処理は文書インデックスの負荷から分離される必要があります。重複なしのリトライが必要です。正しいユーザーにストリーミングで答えを返す必要があります。

これらは単なるパフォーマンス最適化ではありません。イベント駆動システムは自然に表現できますが、同期リクエストチェーンはクリーンにモデル化できません。

カフカがAIパイプラインに自然に適している理由

カフカは、AIシステムが要求する運用行動に密接に対応しています

非連結サービス

カフカベースのアーキテクチャでは、インジェストサービスがドキュメントチャンクをトピックに書き込み、動作している埋め込みモデル、ベクトルデータベースの応答速度、または下流のコンシューマーが負荷があるかどうかを知る必要はありません。埋め込みエンディングは独自のペースで独立して消費します。埋め込みモデルが `text-embedding-3-small` からローカルでホストされた代替に変更されると、上流側は何も変更されません。

分離が重要なのは、AIシステムが絶えず進化するからです.

再生可能

AIシステムは常に派生状態を再生成します。エンコーディングモデルをアップグレードした場合、コーパス全体を再エンコードする必要があるかもしれません。Kafkaを使用すると、トピックの再生によって下流状態が再構築され、インジェスト履歴を再構築することなく再生されます。RAGパイプラインが処理中にクラッシュした場合、コンシューマーはコミットされたオフセットから再開する代わりにリクエストを失ったり、静かに作業をドロップしたりしません。

イベントログは、トランスポート層であり、記録システムでもあります。

構造的バックプレッシャー

LLMsとエンべディングAPIには厳しいスループットの上限があります。同期システムでは、遅い推論がリクエストチェーンを通じて遅延を伝播させます。負荷があると、これが連鎖的な失敗に変わることがよくあります。

Kafkaは基本的な挙動を変更します。低速のコンシューマーはプロデューサーをブロックするのではなく、レイテンシを蓄積します。トラフィックのピークは持続可能なレートで排出されるキューになります—これは、設計上レイテンシが変動するAIシステムにおいて非常に重要です.

独立したコンシューマー

AIパイプラインは単一のワークフローではありません。同じドキュメントイベントのストリームは、埋め込みサービス、分類器、評価パイプライン、監視システム、監査消費者に供給される可能性があります—それぞれが独立してスケールし、他のものと結合することなく。

Kafkaは骨格であり、クライアントインターフェースではありません

Kafkaは優れたイベント骨格です。それ自体がクライアント向けのAPIではありません。

ユーザーはまだRESTエンドポイント、JWT認証、スキーマ検証、ストリーミングレスポンス、テナント分離、ブラウザ互換性を期待しています。無知な解決策は、Kafkaの前にカスタムHTTPサービスを構築することです。

最初は動作します。しかし時間が経つにつれて、すべてのガバナンス上の懸念——認証、アイデンティティの拡散、スキーマの強制、アクセス制御、レート制限——がアプリケーションコード内の条件文となり、新しいテナントルールは別のデプロイメントとなります。ガバナンスはサービス間に散らばる代わりに、一箇所に存在せず、下流サービスはラッパーが送信するアイデンティティを単に信じる必要があります。

そのアーキテクチャは、ガバナンスが中央集権化されなくなったため、理解が困難になる。

なぜAIシステムでアイデンティティの拡散が重要になるのか

マルチテナントAIシステムは認証だけでなく、非同期ワークフローを越えた信頼できるアイデンティティの拡散が必要である。

複数の可視性レベルを持つRAGシステムを考慮してください：無料プランのユーザーは公開知識にアクセスでき、標準プランのユーザーは内部知識にアクセスでき、エンタープライズユーザーは機密知識にアクセスできます。このレベルはAPI境界で提示されるJWTから発生します。下流サービスには、検索結果をフィルタリングするため、生成コンテキストを決定するため、および配信権限を強制するためのアイデンティティ情報が必要です。

Kafka 自体は JWT を検証したり、信頼できるユーザー ID をメッセージヘッダーに伝播したりしません。中央集権的な統治がなければ、開発者は通常、トークンを検証し、メタデータを Kafka に転送するカスタムミドルウェアを書いて解決します——しかし、今や信頼の境界はアプリケーションコードの内部にあり、すべての下流サービスはそのミドルウェア実装の正確性に依存しています.

それが Zilla が埋めるギャップです。

Zillaがギャップを埋める方法

ZillaプラットフォームはクライアントとKafkaの間に位置し、一方ではHTTPを、もう一方ではKafkaプロトコルを使います。アプリケーションサービスに統治ロジックを組み込む代わりに、Zillaは統治をエッジに移動させます.

リクエストの流れはこんな感じです：

POST /queries
Authorization: Bearer <jwt>
  → Zilla validates JWT
  → extracts user tier claim
  → injects trusted Kafka headers
  → writes event to rag.queries
  → RAG pipeline consumes asynchronously→ result written to rag.results
  → client receives streamed response over SSE

‍

AIサービス自体は、転送の問題ではなくAIのロジックに集中しています。

エッジでのアイデンティティインジェクション

クライアントがJWTを送信すると、Zillaはトークンを検証し、Kafkaメッセージに信頼できるアイデンティティヘッダーをインジェクションします—例えば、`user-tier: enterprise`。下流サービスはヘッダーを直接消費します。埋め込み層、取得層、RAGチェーンはJWTを個別に検証する必要はありません。アクセス決定はエッジで一度行われ、その決定の証拠はイベントと共に移動します。

スキーマ強制

不良なペイロードは境界で失敗すべきであり、非同期処理パイプラインの深いところで失敗すべきではない。ZillaはイベントがKafkaに入る前にJSONスキーマを検証する。`doc_id`が必須でないリクエスト、または`question`が文字列でないクエリはすぐに`400`レスポンスを受け取る。無効なイベントは骨格に到達しない。

ネイティブストリーミングレスポンス

AIシステムは基本的に非同期であるが、ブラウザクライアントは依然としてリアルタイムのインタラクションを期待している。Zillaはサーバーセンティッドイベントを通じてこのギャップを埋める：クライアントが`GET /results/{queryId}`を開き、ZillaがKafkaの結果トピックにサブスクリプトし、レスポンスが到着した瞬間にブラウザにストリーミングされる——ポーリングインフラがなく、カスタムSSEサービスを書いたり運用したりする必要はない。

サブスクリプタごとのフィルタリング

複数のユーザーが同時に同じ結果トピックにサブスクリプションを申し込むことができます。ZillaはJWTから抽出したサブスクリプターアイデンティティを使用してストリーミングイベントをフィルタリングするため、エンタープライズユーザーはエンタープライズレベルの結果を受け取り、標準レベルのユーザーは承認された範囲内のものだけを受け取ります。この強制はゲートウェイレベルで行われ、各下流サービスの内部ではなく行われます.

実際のアーキテクチャの様子：デモ

ZillaプラットフォームのRAGデモはこれらのパターンを一貫して実装しています。単一の`docker compose up`コマンドでKafka、Qdrant、埋め込みサービス、RAGチェーンサービス、Zillaが起動し、すべて`zilla.yaml`を通じて設定されます。

フローはこのようになります：

Client (JWT)
  │
  ├── POST /chunks   →  Zilla validates JWT + schema → write to rag.chunks
  ├── POST /queries  →  Zilla injects user-tier header → write to rag.queries
  └── GET /results   →  Zilla subscribes to rag.results → SSE to client

rag.chunks  →  Embedder → Qdrant
rag.queries →  RAG Chain:
                  → embed query
                  → search Qdrant with visibility filter
                  → call LLM
                  → write result to rag.results

‍

アクセスモデルは構造的なもので、アプリケーション定義的なものではなく。無料プランのユーザーのクエリは公開コンテンツのみを検索し、標準プランのユーザーは公開および内部コンテンツにアクセスし、エンタープライズユーザーは機密コンテンツにもアクセスします。可視性レベルはJWTから始まり、イベントストリームを通じて信頼できるメタデータとして拡散されます — どのレベル値も決してクライアント自体からは起源しません.

‍

‍

ZillaプラットフォームRAGデモを実行して、https://github.com/aklivity/zilla-platform-demos/tree/main/rag-projectを参照してください。デモにはブラウザインターフェース、多層のJWTトークン、そして上記で説明したアーキテクチャの完全なウォークスルーが含まれています

後で再構築する必要のないアーキテクチャ

イベント駆動型AIインフラの中心的な議論は、それがより洗練されているからではない。それは、既存のAIシステムが持つ運用行動をモデル化するからだ。

エンコーディングモデルが変わったら、トピックを再プレイします。インジェストトラフィックがピークしたら、コンシューマーがレイグを蓄積する代わりにリクエストパスを縮小します。ガバナンスルールが進化したら、アプリケーションロジックを書き直す代わりに中央政策を更新します。コンプライアンスチームがどのユーザーがどの答えを受け取ったかを尋ねたとき、イベントログにはすでに履歴が含まれています。

Zillaは、エッジでガバナンスを中央集権化することでこれらの利点をさらに強化します——アイデンティティの伝播、スキーマ検証、レートリミット、配信フィルタリング、ストリーミングAPI。その背後にあるAIサービスが進化しても、ガバナンスレイヤーは安定しています.

LLMを交換し。ベクトルデータベースを置き換え。新しいコンシューマーを追加。歴史データを再生します.

境界はまだ維持されています。

Zilla Platformとイベント駆動型AIインフラについてさらに学ぶにはデモをリクエストしてください