https://yennj12.js.org/yennj12_blog_V4/tags/cost-control/Recent content in Cost Control on YennJ12 Engineering BlogHugo -- gohugo.ioen-usMon, 22 Jun 2026 00:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part6-rag-eval-zh/Sun, 31 May 2026 09:30:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part6-rag-eval-zh/RAG 跑起來很容易。 讓它在生產環境穩定運行、能量化效果、還要控制成本——這才是難的。 面試官想知道你有沒有這層意識。 面試情境 面試官：「你的 RAG 系統上線後，客戶反映回答品質下降了。你怎麼診斷問題在 Retrieval 還是 Generation？你用什麼指標量化 RAG 的品質？如果成本超出預算，你怎麼優化？」 這是 FDE 最貼近生產現實的考題——不是設計新系統，而是診斷一個已上線系統的問題。 一、檢索失敗：你的 RAG 為什麼沒找到正確答案 這是 RAG 系統最常見的實際問題，也是面試官最愛問的： 「你的 RAG 系統回答品質不好，你怎麼 debug？」 檢索失敗的五大原因 1. Query 和 Document 的語意空間不對齊 用戶問的方式和文件寫的方式不同。 用戶問：「這個功能怎麼用？」 文件寫的是：「操作說明 3.2.1 節」 向量搜尋找不到，因為語意距離太遠。 修復方式： HyDE（Hypothetical Document Embeddings）：先讓 LLM 根據 query 生成一個假設答案，用假設答案的 embedding 去搜尋，而不是 query 本身 Query Rewriting：讓 LLM 把用戶的問題改寫成更像文件的表述 Query Expansion：生成多個 query 變體，分別搜尋後合併結果 2. Chunk 切壞了 答案跨越了 chunk 邊界。 修復：調整 chunk overlap，或改用 Parent-Child chunking。https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase14-part4-production-zh/Mon, 22 Jun 2026 00:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase14-part4-production-zh/大多數團隊把 Agent 推上生產後就等著看它出問題； 正確的做法是在部署前設計可觀測性、預算上限、Guardrails； 差別不在於 Agent 多聰明，而在於系統多可靠； 沒有監控的 Agent，是一顆定時炸彈，不是產品。 面試情境 「你們的 AI Agent 在 staging 表現很好，但上線兩週後 token 費用暴增 400%，還出現幾次無限迴圈。你作為 tech lead，怎麼設計一個生產級的 Agent 系統架構來防止這些問題？請從可觀測性、成本控制、安全護欄三個維度說明，並說明你會如何科學地評估新 Agent 策略的效果。」 一、核心問題：Agent 生產化為什麼比模型部署難十倍 一般的 API 服務失敗模式很簡單：請求進來、計算、回應。延遲 p95 > 500ms 就告警，error rate > 1% 就回滾。背後的心智模型是「函數式」的：相同輸入，相同輸出，相同成本。 Agent 的失敗模式完全不同，它是「狀態機式」的：每一步的輸出決定下一步走哪條路。 問題一：非確定性執行路徑。 同一個輸入，Agent 可能走 3 步或 15 步。一個客服 Agent 回答「退貨政策」應該 2 步搞定，但如果 LLM 判斷需要查訂單狀態再查庫存再查物流，就變成 12 步、花了 $0.08 而非 $0.01。乘以每天 5,000 個請求，這個差距是 $350 vs $50，每月差 $9,000。 問題二：無限迴圈風險。 Agent 的 ReAct 迴圈沒有硬性上限時，一個錯誤的工具呼叫結果可能讓 Agent 不斷重試同一個動作。真實案例：一個資料分析 Agent 因為 SQL 工具回傳空結果，誤判為「需要更多查詢」，觸發 87 次 LLM 呼叫，花費 $23 才被手動停止。