人工智慧系統很少因模型而在生產中失敗.
更常見的是，它們失敗是因為它們底下的基礎設施是為完全不同的工作類型而設計的。
在生產環境中，AI工作負載會引入變動延遲、重試、並發尖峰、反向壓力以及多租戶訪問控制問題，這些問題傳統的同步系統難以清晰地模擬。示範可能能在HTTP請求-響應鏈中運作，但生產環境並非示範。
生產是成千上萬使用者同時提交查詢，而大型語言模型需要八秒鐘才回應。它是嵌入服務觸及速率限制，而匯入流量持續到來。它是重試請求意外在向量資料庫中創建重複的嵌入。它是企業使用者、標準層使用者及免費層使用者同時查詢同一系統，而期望只能存取他們被授權查看的資訊。
那些都不是模型問題。它們是基礎設施問題.
而基礎設施問題需要基礎設施解決方案.
一個生產 RAG 管線不是單一 API 調用。它是一連串具有不同延遲特性、吞吐量限制和失敗模式的非同步操作。
一份文件片段到達，需要透過外部API呼叫進行嵌入。嵌入結果存儲在向量數據庫中。用戶查詢觸發另一個嵌入請求，接著是相似性搜索、上下文組裝以及可能需要數秒時間完成的LLM推理步驟.
關鍵在於，這些階段是獨立的。
即使嵌入處理變慢，您仍需要資料採集以繼續進行。您需要將查詢處理與文件索引負載隔離。您需要無重複的重試機制。您需要將答案流式傳送給正確的使用者，而無需進行輪詢。
這些不僅僅是性能優化。它們是事件驅動系統自然表達的架構要求，但同步請求鏈無法清晰地模擬。
Kafka 與 AI 系統所需的操作行為高度契合
在一個基於Kafka的架構中，採取服務會將文件塊寫入主題，而無需知道正在運行的嵌入模型是什麼、向量數據庫的反應速度如何，或下游消費者是否負載過重。嵌入器會獨立地按照自己的節奏進行消費。如果嵌入模型從`text-embedding-3-small`改變為本地主機的替代方案，上游無需進行任何更改。
解耦是重要的，因為人工智慧系統不斷進化.
人工智慧系統不斷重新產生衍生狀態。如果您升級您的嵌入模型，您可能需要重新嵌入整個語料庫。使用 Kafka，重放主題可以無需重建攝取歷史記錄的情況下重建下游狀態。如果一個 RAG 管道在處理中途崩潰，消費者從已提交的偏移量恢復，而不是丟失請求或默默地丟棄工作。
事件日誌變成了傳輸層和記錄系統。
大型語言模型與嵌入API有其硬體通量上限。在同步系統中，緩慢的推論會將延遲傳播回請求鏈。在負載下，這通常會轉變成連鎖失效。
Kafka 改變了其行為本質。慢速消費者累積延遲，而不是阻礙生產者。流量尖峰變成隊列，以可持續的速率排出——這在設計上延遲可變的 AI 系統中極為重要.
AI 管線並非單一跳工作流程。相同的文件事件串流可能會輸入嵌入服務、分類器、評估管線、監控系統，以及審計消費者 — 每個獨立擴展而不與其他相互耦合。
Kafka 是一個優秀的事件主幹。它本身並非面向客戶的 API。
您的用戶仍然期望REST端點、JWT認證、模式驗證、串流回應、租戶隔離和瀏覽器相容性。天真的解決方案是在Kafka前面建立一個自訂的HTTP服務。
一開始是可行的。但隨著時間推移，每個治理關注點——身份驗證、身份傳播、模式執行、訪問控制、速率限制——都變成了應用程式碼中的條件語句，而每個新的租戶規則都變成了另一個部署。治理分散到各個服務中而不是集中在一處，下游服務只能信任包裝器轉發的任何身份。
該架構變得難以理解，因為治理不再集中。
多租戶人工智能系統需要的不只是驗證。它們需要跨非同步工作流程的受信任身分傳播。
考慮一個有多個可見性層級的 RAG 系統：免費層級使用者可以存取公開知識，標準層級使用者可以存取內部知識，而企業使用者可以存取機密知識。這個層級源自於在 API 界限處提交的 JWT。下游服務需要這些身分資訊來篩選回傳結果、決定產生語境，並執行傳送權限。
Kafka 本身不驗證 JWT 或將受信任的用戶身分傳播到消息頭部。沒有中央治理，開發者通常透過編寫自訂中間件來解決這個問題，驗證令牌並將元數據傳送至 Kafka — 但現在信任邊界位於應用程式碼內，每個下游服務都依賴於那個中間件實現的正確性.
這就是 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 服務演進，治理層仍然穩定。
更換大語言模型。替換向量資料庫。新增消費者。重放歷史數據。
界線仍然堅守。
想了解更多有關Zilla Platform和事件驅動型AI基礎設施的資訊，請申請示範。
此內容由慣性聚合(RSS閱讀器)自動聚合整理，僅供閱讀參考。 原文來自 — 版權歸原作者所有。