Semantic Firewall（實驗）
Semantic Firewall（實驗性設計）
Semantic Firewall 係一個放喺邊緣端（Edge）的語義閘門，用嚟先做風險分流，再決定要唔要把請求交畀雲端大模型生成敘事。
設計目標係：提升安全與隱私，同時維持正常用戶體驗。
1) 乜嘢係 Semantic Firewall
傳統做法通常直接把請求送去雲端模型，再由雲端判斷可唔可以答。
Semantic Firewall 反過來：先喺本機做語義檢查，再決定是否放行。
核心原則：
- 先分流，後生成。
- 先保護敏感上下文，後輸出敘事內容。
- 風險判斷同內容敘事分層，不混在同一引擎。
2) Edge Gateway 點樣運作
Edge Gateway 會使用 on-device 小模型（例如 WebGPU / WebLLM 路線）去判斷語義一致性與風險等級：
- 正常情況：請求可進入雲端敘事流程。
- 可疑情況：系統自動降級，只保留較保守的處理路徑。
- 高風險情況：停止傳送敏感語境到雲端，回退到本地安全模式。
整個過程重點係「最小暴露」：
即使需要降級，亦優先保留可用性，而唔係直接讓系統失效。
3) 點解 Move 3 放雲端，但要由 Edge 控制
雲端大模型擅長敘事同表達（Move 3），但唔適合單獨做最終安全判斷。
因此架構上會把兩者拆開：
- Edge：負責風險判斷同開關控制。
- Cloud：只在安全前提下負責高質量敘事輸出。
好處係可以同時得到：
- 更穩定的安全邊界；
- 更清晰的審計路徑；
- 更可控的成本與降級策略。
4) 對一般用戶有咩實際好處
- 安全性：敏感內容唔會無條件直送雲端。
- 隱私性：高風險場景優先本地收斂，減少外送範圍。
- 穩定性：可疑流量會被隔離，正常查詢可維持主流程品質。
- 成本可控：風險分流後，雲端推理資源用得更精準。
另外，針對疑似 scraping 流量，系統可採用「高保真但低價值」防禦回應策略。
此策略只針對可疑請求，唔應該影響正常用戶的答案質素。
5) 實驗性質聲明
本頁描述的是 Kernel 級安全實驗設計，不等同最終固定規格。
相關機制會按 Anchor Registry、審計結果同實測數據持續調整。
任何未通過審核的研究構想，不會直接進入 production 流程。