你大概遇過這個場景：產品會議上有人說「我們加個 AI 功能吧」，然後任務落到你頭上。你打開文件一看，不就是呼叫一個 HTTP API 嗎？拿 API key、發 POST、解析 JSON，一個下午就能接完。真正的問題在兩週後上線才浮現：使用者抱怨回應要等八秒、QA 說同一個測試案例每次跑結果都不一樣、月底帳單比預估高了一個數量級。

忍喵：「八秒、每次不一樣、帳單爆掉——三個一起來，才叫正式接上 LLM。」

這個系列要處理的就是這件事：把 LLM 從「能動的 demo」帶到「能上線的後端系統」，中間缺的那段工程。

一個熟悉的類比：LLM 是一個下游服務

Backend 工程師理解新事物最快的方式是套用已知的心智模型。這裡有一個好用的起點：把 LLM 當成一個你無法控制的下游服務，像你接過的金流、簡訊、地圖 API 一樣。它會慢、會掛、會限流，所以你本來就知道要包 timeout、要處理錯誤、要監控延遲。這個類比讓你不會犯最天真的錯誤（把 LLM 呼叫直接寫在 handler 裡、不設 timeout、不記 log）。

但這個類比會在四個地方失真，而失真的地方正是 GenAI backend 工程的核心。

失真一：相同輸入，不同輸出

在相同狀態與相同參數下，金流 API 通常會回到可預期的結果；LLM API 則通常不承諾逐字相同的輸出。取樣設定、模型與服務端實作都可能影響結果，所以測試不能把 assert response == expected 當成真模型的合約。業務邏輯改用假的 LLM adapter 測（確定性、免費、毫秒級），真模型的行為另外驗證。這也是為什麼這個系列從第一天就把 fake 與 real adapter 藏在同一個介面後面，而不是等到要寫測試才補。

失真二：延遲常以秒計，輸出越長通常等越久

生成式回應的等待時間常比一般 API 長得多，而且輸出 token 越多，完成時間通常越長；但總延遲還會受到首 token、模型推理、排隊與服務負載影響，不是單純的正比關係。這改變的是整個互動模型：等到完整回應才一次送出，使用者容易以為服務壞了，所以常見做法是 streaming。Streaming 一進來，錯誤處理也跟著改變：HTTP 200 送出後模型才出錯，要怎麼告訴 client？重試又該重試什麼？Day 6 會專門處理這條邊界。

失真三：按 token 計費，成本跟著使用者輸入走

一般 API 按呼叫次數計費，貴也貴得可預測。LLM 按輸入加輸出的 token 計費：使用者貼多長的文字、模型回多長的答案，直接決定你這筆請求的成本。使用者是會貼整份 PDF 進來的。沒有輸入長度上限、沒有輸出 token 上限、沒有用量監控的 GenAI 功能，等於把一張空白支票交給流量。這個系列自己就是示範：我把實驗預算硬壓在每月 20 美元（US$20）以內（這是我設的自我約束，不是 Azure 的建議），每一筆實際花費都會記下來，在 Day 9 攤開給你看控管成本的具體做法。

忍喵：「圈這句：成本會跟輸入、輸出 token 一起變。估價若只算『每次呼叫多少錢』，至少先把長度上限和用量分布補進去。」

失真四：輸出本身就是攻擊面

傳統下游服務的回應你本來就會驗證格式與範圍，但至少它的 schema 相對穩定，驗過大致就能用；LLM 的輸出你必須當不可信的使用者輸入處理：就算通過 schema 驗證，內容在語意上仍可能出錯，還可能重現攻擊者藏在輸入裡的指令（prompt injection），因為模型可能把資料裡的自然語言誤判成該遵循的命令，而你無法只靠 prompt 保證這條界線每次都劃對。

偏偏它的輸出會被你的系統拿去渲染、查資料庫，甚至呼叫工具，所以不能因為「是模型產生的」就自動取得這些權限。GenAI 多出來的風險是：自然語言可能同時是資料，也可能被模型誤判成指令；模型輸出因此不能直接繼承資料庫或工具權限。Day 19–22 會用四篇處理身分驗證、secret 管理、prompt injection 與 audit log。

那 Backend 工程師的角色是什麼？

看完四個失真點，角色就清楚了：模型能力是 AI 團隊或雲端供應商的事，但把不可靠的模型包進可靠的系統，是後端工程。你本來就熟悉下面這些工作，只是工程條件變了：

• API 設計與版本策略：streaming 讓 HTTP 200 之後的錯誤也成為合約的一部分
• 可靠性工程：timeout、重試與降級要面對秒級、可能重複計費的推論
• 測試策略：核心邏輯與真模型行為必須拆開驗證
• 成本與監控：請求內容與輸出長度會直接影響 token 花費
• 安全：自然語言資料可能影響模型決策與後續工具呼叫

三個常見的誤解順便在這裡拆掉。「GenAI 開發就是 prompt engineering」？prompt 只是其中一個輸入參數，決定系統能不能上線的是上面那五件事。「等模型更強這些問題就消失了」？就算下一代模型更快、更便宜，token 計費、秒級延遲與非確定性仍然會以某種形式留在系統設計裡。「這是 ML 工程師的事」？用 API 接模型的專案裡通常根本沒有 ML 工程師，模型訓練確實不關你的事，但模型以外的一切都是。

這個系列的範圍與路線

接下來 30 天，用 Python 3.13 + FastAPI 在 Azure 上把一個 GenAI backend 從零帶到可部署、可監控、可控成本。整個系列圍繞同一個系統長出來，全景如下：

七個 Part 的路線：

1. Part 1（Day 1–5）：心智模型與地基——參考架構、可測試的專案骨架、Azure OpenAI、第一個 Chat API
2. Part 2（Day 6–10）：API 設計進階——streaming、conversation state、prompt 版本管理、成本控管、API gateway
3. Part 3（Day 11–15）：RAG——用 Azure AI Search 讓模型回答你自己的資料，含多租戶權限
4. Part 4（Day 16–18）：Agent——什麼時候需要、什麼時候 Chat API 就夠了
5. Part 5（Day 19–22）：安全——認證、secret 管理、prompt injection、audit log
6. Part 6（Day 23–26）：部署——Docker、Container Apps、CI/CD、infra 演進
7. Part 7（Day 27–30）：營運——監控、evaluation、上線檢查表

所有程式碼都在公開的 GitHub repo：azure-genai-backend-lab。有對應程式碼的文章會綁定一個不可變的 git tag（day-NN），tag 上的 CI 是綠的，「照著做能重現」這句話有 CI 背書。文章裡只貼關鍵片段，完整程式碼一律看 tag。

明確不做的事：不教 prompt 技巧（這個領域變動太快，而且不是後端工程）、不做模型評比、不當 Azure 產品目錄（每篇只談當天真正用到的一到三個服務）。

小結

今天只做一件事：換掉心智模型。LLM 不是又一個要接的 API。不確定性你以前就處理過（搜尋排序、推薦系統、eventual consistency），但它們各自待在系統的角落；LLM 把這些不確定性集中進同一條 request path，一次打破確定性輸出、毫秒級延遲、按次計費、輸出可信四個你賴以工作的假設。這個系列就是把這四個洞一個一個補回來的過程。

明天（Day 2）從全景開始，看一個 GenAI backend 的參考架構：從使用者請求進來，到模型回應出去，中間到底該有哪些層、每一層在防什麼。先看懂地圖，Day 3 再動手把專案骨架建起來。

（本篇為系列總覽，無新增雲端資源；服務對照表從實作篇開始附上。）

本文由作者規劃與撰寫，AI（Claude）協助草稿整理與程式碼驗證；技術內容與觀點由作者確認並負責。