在正式動手寫程式前，必須先將整個中台系統的模組邊界、資料流向與交互拓撲定義清楚。一個具備生產級能力的企業 AI 中台，絕不是單純打一個 client.chat.completions.create()，而是要兼顧安全性（Security）、成本控制（Cost Governance）、知識準確性（RAG）與高可用性（Reliability）。

今天我們將系統性拆解中台的四大核心模組與整體的資料流轉路徑。

系統整體拓撲架構

整個中台系統在邏輯上劃分為四個層級：

四大核心模組詳細職責

1. API Gateway 核心層

• 統一接入標準：相容 OpenAI Chat Completion API 格式，讓內部開發工具或 IDE 插件（如 VS Code 外掛、Continue、Cline）能無縫切換端點。
• 認證與租戶隔離：依據 API Key 識別呼叫者所屬部門與權限組，並對接 Redis 進行即時 Token 配額扣減與滑動窗口限流。

2. 智慧安全與路由引擎（Dynamic Router）

• 即時敏感度掃描：在 Prompt 進入模型前，透過本機 Guardrails 掃描是否包含內部 API Token、金鑰、資料庫連線字串或 PII（個人識別資訊）。
• 動態分流決策：
  • 高機敏 / 內部專有規範 → 強制分流至地端開源模型，確保資料不出內網。
  • 低機敏 / 複雜架構設計 → 脫敏後分流至雲端商業模型，獲取最佳推論品質。

3. 開發規範 RAG 與 Skill 控制

• 規範 RAG 管線：將內部 Coding Style、Git Flow、API Schema 進行切塊與向量化。透過「BM25 關鍵字 ＋ Dense Vector 向量」混合檢索與 Rerank，精準將規範注入上下文。
• Skill / Tool 白名單：嚴格限制模型可調用的工具清單（如：查閱架構圖、執行靜態代碼檢查），並在執行前進行嚴格的 Schema 校驗，阻斷 Prompt Injection 攻擊。

4. 推論管理與治理後台

• 多 Provider 抽象層：地端（vLLM / Ollama）與雲端（OpenAI / Anthropic / Google）統一封裝，支援自動 Fallback。
• Token 消耗與日誌可觀測性：即時回傳 Prompt / Completion Token 數量，寫入鏈路追蹤系統（Langfuse），並在後台儀表板呈現各部門成本與機敏攔截率。

核心資料流向：一次完整的請求生命週期

1. Client 發起請求：工程師於開發工具輸入問題（包含 API Key）。
2. Gateway 攔截與鑑權：檢查 Key 有效性與 Redis 剩餘 Token 配額；若超額則回傳 429 Too Many Requests。
3. 安全檢查與路由判定：
   • Guardrails 掃描輸入內容。
   • Router 依據敏感度決定發往本地或雲端推論引擎。
4. 知識增強（RAG）：若問題涉及內部規範，向 Qdrant 進行混合檢索並經由 Reranker 取出關聯度最高的規範條款，組裝成完整 Prompt。
5. 模型推論與 Tool 執行：調用目標模型，若觸發 Tool Calling 則進行權限檢查後執行並回填結果。
6. Token 結算與追蹤記錄：統計實際消耗 Token，扣減配額並將 Request/Response 與延遲數據非同步寫入 Langfuse。
7. 回傳結果：將最終生成的規範建議與引用來源返回 Client 端。

明日預告

明確了系統拓撲與各模組職責後，明天 Day 03 我們將從最底層的推論基建開始，實際動手搭建地端推論環境，利用 Ollama / vLLM 部署本機開源模型並驗證推論延遲與資源消耗。