Enterprise AI Governance：Rosetta 如何用 4 階段 Guardrails 管理開發流程（entries: Rosetta）💡

問題不在模型，在管唔住條 pipeline

2026 年的今天，任何團隊都可以用 API call 召喚 GPT-4o、Claude 4、Gemini 2.5 等級別的模型。模型能力不再是競爭壁壘——真正讓 CTO 瞓唔着覺的，是生產環境裡 LLM 的不可預測性。

你見過的場景：一個 prompt engineer 改咗 system prompt 入面一個字，整體回覆風格大變；RAG pipeline 中間加咗個 re-ranking step，recall 由 89% 插到得返 64%；某條 chain-of-thought prompt 在 staging 完美運作，上到 production 因為用戶輸入多咗個引號就輸出亂碼。這些不是 bug，是欠缺治理結構的必然後果。

Rosetta 的出發點好 blunt：AI 開發管線需要 guardrails，而且唔可以只擺一兩層就當交貨。佢地提出的 4 階段架構，將 guardrails 嵌入開發流程的四個不同節點——input、retrieval、generation、output——每一層做自己嗰份工，唔跨層干預，唔靠一個「聰明 agent」解決所有問題。

Stage 1：Input Guardrails——入口決定命運

第一道防線唔係攔截壞輸出，而係在用戶的 query 進入系統之前做清洗和分類。Rosetta 的做法唔係單純的 blacklist/whitelist keyword filter——嗰啲嘢連 SQL injection 時代都唔夠用，何況係對付 LLM prompt injection。

真正有效的是多層輸入驗證：先用語義分類器判斷 query 屬於哪個意圖類別（查詢、生成、分析、指令型），再對每個類別套用不同的 sanitization 規則。舉例，對「分析」類 query 可以保留複雜句子結構，但對「指令型」query 要特別檢測 prompt injection 特徵——例如 query 入面包含「ignore previous instructions」或「you are now」這類 meta-instruction pattern。

Rosetta 特別強調的一點：input guardrails 要保持 deterministic。LLM-as-judge 在這裡用唔過——如果連判斷用戶輸入是否安全的步驟都要 call 另一個 LLM，你只是將 non-determinism 往上推一層。相反，用 lightweight 的分類器（fastText 或 distilled BERT 級別）加上 pattern matching，latency 控制在 5ms 以內，先做到真正的邊界防護。

第二個容易被忽略的設計：input guardrail 必須記錄完整的審計軌跡。企業合規唔係睇你有冇擋到攻擊，而係 audit 時你要證明到每一條危險 query 點樣被攔截、被邊條 rule trigger、threshold 係幾多。Rosetta 的 input layer 在這方面做得徹底——每條 rejected query 都會保留 embedding vector，日後可以做相似度分析去 fine-tune ruleset。

Stage 2：Retrieval Guardrails——RAG 的靜脈曲張

RAG 系統的最大錯覺是「chunk size 揀 512 tokens 就搞掂」。現實是 retrieval 階段的 guardrail 設計直接決定 generation quality 的天花板。

Rosetta 的 retrieval guardrails 不只是 filtering retrieved chunks，而是做三件事：relevance scoring、source authentication、context window budgeting。

Relevance scoring 說易行難。Cosine similarity 做 semantic search 的結果往往混入「語義似但事實錯」的 noise chunk。Rosetta 引入第二層 scoring——cross-encoder re-ranker ——將 top-50 的候選 chunk 壓縮到 top-5，但佢哋的關鍵 insight 是呢個 re-ranker 必須用 domain-specific data fine-tune。用通用 NLI model 做 re-ranking 同 random chance 差唔多。

Source authentication 是大部分人忽略的一環。Production RAG 系統的知識庫會隨時間變化——新文件加入、舊文件更新、有些 source 甚至被撤下。Rosetta 的 retrieval guardrail 會對每個 retrieved chunk 打上 source 指紋（包括文件 ID、版本號、最後更新時間），generation 完成後可以追溯每段輸出的來源。呢個唔係防禦性功能——係 regulatory compliance 的必需品。EU AI Act 同中國生成式 AI 管理辦法都要求輸出可以追溯到訓練/檢索來源。

Context window budgeting 就係實用技巧。唔係所有 retrieved chunks 都要塞入 context window。Rosetta 按照查詢類別分配 token budget：事實查詢類分配較多 budget 俾 retrieval content，創意生成類則分配較多 budget 俾 instruction 和 examples。咁做避免咗「塞爆 context window」同「遺漏關鍵資訊」兩個極端。

Stage 3：Generation Guardrails——管住模型的 improvisation

Generation 階段是整個 pipeline 最難 guard 的環節，原因好簡單：LLM 本質上是 stochastic。你唔可以「鎖死」一個 LLM 的輸出行為，最多只能 guide 同 verify。

Rosetta 在這裡採取 hybrid 策略：structured decoding + runtime constraint injection。Structured decoding 唔係新鮮事——outlines、jsonformer、guidance 這些 library 都做緊。但 Rosetta 將呢個概念推到更 granular：唔只係強制 JSON schema，而是根據 input guardrail 分類的意圖類別，動態切換 output schema。查詢類返回 structured fact set，生成類返回自由文本但強制包含 citation marker，分析類返回先結論後論證的模板。

Runtime constraint injection 就更有趣。Rosetta 的 generation guardrail 會喺每次 LLM call 的 system prompt 入面動態注入當前 session 的 constraints——包括 tone guideline、brand voice rules、敏感詞替代規則。關鍵係呢啲 constraints 唔係寫死的 static text，而是從一個 version-controlled constraint registry 拉出來，每個 constraint 有 version、生效時間、和 A/B test group 綁定。呢個設計令佢哋可以做 gradual rollout——先將新 constraint 應用到 5% traffic，觀察 guardrail recall rate 同 user satisfaction 之後再全面推開。

生成階段的即時監控同樣重要。Rosetta 在每個 generation step 都收集 one-way latency、output length distribution、refusal rate。呢三個指標的異常變化可以直接觸發自動 rollback——如果 refusal rate 突然由 1.2% 跳上 8.7%，系統會自動退回上一個 constraint version，唔使等人 hand-on-deck。

Stage 4：Output Guardrails——最後一公里唔可以出事

輸出 guardrail 是生產 AI 系統的最後安全閥。唔理前面三層做得幾好，output guardrail 都係必需要有——因為 LLM 的 non-determinism 意味住任何時候都可以出 unexpected output。

Rosetta 的 output guardrail 做四件事：factual consistency check、policy compliance classification、format validation、red-teaming signature detection。

Factual consistency check 係最重的一個 component——用一個 smaller LLM (Rosetta internal 用 7B model) 對 generation output 做 entailment verification，檢查輸出入面的 claims 是否有 retrieval chunks 或 knowledge base 支持。呢步會有 100-200ms 的 latency overhead，但係對於醫療、金融、法律這類高風險 domain，呢 200ms 係必需品。

Policy compliance classification 係針對企業內部政策。唔同公司有唔同的 acceptable use policy——有些唔准輸出競爭對手比較、有些唔准給投資建議、有些唔准生成代碼。Rosetta 的 output guardrail 用一個 multilabel classifier 對每條 output 標記 policy violation categories，threshold 可由企業自行調整。呢個設計的優雅之處係：policy 改變唔使改 model，改個 classifier threshold 就得。

Format validation 就係確保輸出符合合約約定的結構。用戶約定好 API 回傳 JSON schema——output guardrail 會自動修復 minor formatting issues (trailing commas、missing fields)，但 major violation 直接 reject 並返回標準化的 error response。

Red-teaming signature detection 係最進階的功能。Rosetta 維護一個不斷更新的 adversarial pattern database——包括已知的越獄 prompt、token manipulation attacks、encoding bypass——output guardrail 會掃描輸出是否包含這些 attack 的痕跡。呢個 database 同 community 共享，類似病毒特徵庫的概念，新 pattern 貢獻者會得到 credit。

將 Guardrails 變成組織紀律，唔係技術包袱

Rosetta 的 4 階段架構最值得學習的唔係技術細節，而係一個 design philosophy：Guardrails 係開發流程的一部分，唔係一個事後加上的「安全模組」。

每層 guardrail 的 metric 都應該 dashbordable、alertable、actionable。Input guardrail 的攔截率同誤殺率、retrieval guardrail 的 precision/recall、generation guardrail 的 latency 同 constraint coverage、output guardrail 的 pass rate——呢啲數字每天睇，同睇 revenue 一樣重要。

如果你而家正在 building 一個 production LLM system，我的建議係：唔好等到出事先諗 guardrails。先用 Rosetta 的架構 map 一次你條 pipeline，睇下邊層完全空白。通常第一條 missing guardrail 會係你下一個 production incident 的 root cause。

AI governance 唔係拖慢開發嘅嘢——係令你敢放心 deploy 嘅嘢。