https://yennj12.js.org/yennj12_blog_V4/tags/llm-engineering/Recent content in LLM Engineering on YennJ12 Engineering BlogHugo -- gohugo.ioen-usMon, 22 Jun 2026 06:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase11-part2-rag-evals-zh/Sun, 21 Jun 2026 20:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase11-part2-rag-evals-zh/大多數工程師遇到 LLM 幻覺，第一反應是把 Prompt 寫得更長、更詳細。 正確答案是：建立 RAG 管線讓模型說「我不知道」，而非瞎猜。 大多數團隊上線後才發現回答品質不穩，因為沒有評估管線。 正確答案是：在 CI/CD 中門控 Faithfulness ≥ 0.80，讓壞版本無法部署。 面試情境 你們公司的法律文件問答系統上線三個月，客服每週回報大約 15% 的回答「聽起來合理但內容有誤」。CTO 要你在四週內把幻覺率降到 5% 以下，且 P95 延遲不能超過 2 秒。請說明你會怎麼診斷現況、選擇改進方向，以及如何證明改善確實發生了。 一、核心問題：LLM 幻覺與知識截止日期的工程解法 LLM 有兩個先天限制，工程師必須正視： 幻覺（Hallucination） — 模型會以高信心度生成看起來合理但事實上錯誤的內容。根源在於訓練目標是「預測下一個 Token」，而非「陳述事實」。當問題超出訓練分布，模型不會說「我不確定」，而是繼續生成流暢但錯誤的文字。 知識截止日期（Knowledge Cutoff） — 模型訓練資料有時間邊界。2024 年底截止的模型不知道 2025 年的法規修訂、產品更新、或內部文件。無論 Prompt 寫得多好，模型都無法回答它從未見過的資訊。 RAG（Retrieval-Augmented Generation） 是主流工程解法：把外部知識庫的相關片段即時檢索出來，附加在 Prompt 中，讓模型「有所依據地回答」而非憑空捏造。 但 RAG 帶來新問題：檢索品質如何保證？回答是否忠實於檢索內容？這需要評估管線來量化和監控。 二、三個演進階段（POC / MVP / Scale） ╔══ Phase 1：POC / < 1K 文件 ══╗ 目標：兩週內驗證 RAG 在這個領域是否可行。 ┌─────────────────────────────────────────────────────┐ │ Phase 1 RAG 架構（POC） │ │ │ │ PDF / Markdown ──▶ 固定 512 Token Chunking │ │ │ │ │ ▼ │ │ ┌──────────────────┐ │ │ │ Chroma / SQLite │ (本機) │ │ │ Dense Vector │ │ │ └────────┬─────────┘ │ │ │ Top-K ANN │ │ ▼ │ │ ┌──────────────────┐ │ │ │ LLM（API） │ │ │ │ GPT-4o / Claude │ │ │ └──────────────────┘ │ └─────────────────────────────────────────────────────┘ 項目 數值 文件量 < 1K docs 向量 DB Chroma（本機，免費） Embedding text-embedding-3-small（$0.https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase19-part1-capstone-rag-system-zh/Mon, 22 Jun 2026 05:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase19-part1-capstone-rag-system-zh/大多數工程師看到 RAG 就直接 pip install langchain，把 PDF 切成 512 token，塞進 ChromaDB，呼叫 GPT-4o，然後跟老闆說「系統做好了」。 真正的答案是：RAG 是一個系統，不是一個腳本。你需要解析管線、混合索引、重排序、評估框架，以及一套讓你在生產環境裡活下去的可觀測性架構。 腳本在 demo 時可以運作。系統在三個月後的週一早上凌晨兩點還能運作。 這篇文章記錄的是後者。 面試情境 面試官：「假設你加入一家 500 人的科技公司，負責從零打造內部知識庫問答系統。有 5 萬份文件（PDF、Word、HTML 混雜），200 位同時在線用戶，SLA 要求 P95 < 3 秒，預算每月 $3,000 以內。你的第一個月怎麼規劃？第 4 週的架構長什麼樣子？最大的技術風險在哪裡？」 一、專案目標：企業知識庫問答系統的真實需求 1.1 為什麼這個題目值得深挖 這不是一個玩具問題。企業內部知識庫是 RAG 應用最高頻、也最容易出錯的場景。文件格式雜亂、安全等級各異、查詢意圖模糊、幻覺率要求嚴格——每一個細節都可以把一個「能動的 demo」變成「生產事故」。 我在 2025 年底實際交付了一個類似規模的系統（為了保密，以下數字略有調整，但技術決策完全真實）。這篇文章是那次交付的技術後記。 1.2 業務需求清單 維度 需求 文件規模 5 萬份（PDF 60%、Word 25%、HTML 15%） 並發用戶 200 人同時在線，峰值 QPS 約 40 延遲 SLA P95 < 3 秒（端對端，含 LLM 生成） 幻覺率上限 < 8%（由法務部門要求，涉及合規文件） 多租戶隔離 3 個部門，各自的文件不可互相查詢 語言 繁體中文為主，英文文件占 30% 預算 每月 $3,000（含 LLM API、向量資料庫、運算） 安全等級 L1（公開）/ L2（內部）/ L3（機密）三級 1.https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase19-part2-capstone-agent-product-zh/Mon, 22 Jun 2026 05:30:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase19-part2-capstone-agent-product-zh/大多數人做法：把 ChatGPT API 包一層 wrapper，加幾個 if-else，叫它「AI 客服 Agent」。 正確答案：ReAct 迴圈 + 工具安全閘 + 對話記憶 + Guardrails + 完整可觀測性， 缺少任何一層，上線兩週後你就會收到第一封「Agent 幫客戶退了根本沒問題的訂單」的事後報告。 本文是一個真實 Sprint 4 週期的工程回顧，紀錄哪些設計決策讓我們撐過了 100K sessions/day。 面試情境 你的公司想把電商客服從人工轉為 AI Agent，日均客服量約 30K sessions，高峰期（雙 11）可能到 80K。客服範圍包含訂單查詢、退換貨申請、產品推薦以及升級至人工。請描述你會如何設計這個系統，從 MVP 到可以承受 80K sessions/day 的生產架構，並說明關鍵的工程決策與取捨。 一、專案目標：AI 客服 Agent 的真實產品需求 這個 Capstone 專案的原型來自一個真實的電商平台改造案。業務背景很清楚： 現狀：人工客服 45 人，平均回應時間 4.2 分鐘，CSAT 3.7/5，月薪資成本 $180K USD 目標：AI 處理率 ≥ 70%，平均回應時間 < 8 秒，CSAT ≥ 4.0/5，月 AI 成本 < $35K 風險底線：不能有金融損失（錯誤退款、錯誤折扣），不能有個資外洩 拆解需求後，Agent 需要具備五種能力：https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase19-part3-capstone-multimodal-app-zh/Mon, 22 Jun 2026 06:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase19-part3-capstone-multimodal-app-zh/大多數人：把 GPT-4V 的 API 呼叫包一層，傳圖片進去，輸出文字就叫「多模態應用」。 真正的做法：從模態路由、串流融合、延遲預算分配到降級策略，每一層都有可量測的 SLA。 差距不在模型能力，而在系統設計——隨機拼接各模態模型的 P99 延遲 8.4s vs 精心設計的多模態管線 1.9s，用戶留存率相差 2.7 倍。 本文是 AI 工程從零開始系列的 Capstone 收官之作，從 POC 到 Scale，完整走完多模態 AI 平台的工程之路。 面試情境 你負責一個 B2B SaaS 的商業智慧平台，客戶需要一個 AI 助理能同時分析：PDF 財務報告中的圖表、上傳的截圖、語音指令，以及結構化的 Excel 數據。目前你們每月有 50K 活躍用戶，高峰期同時在線 3,000 人，計劃六個月後擴展到 500K 用戶。請設計端對端的多模態 AI 系統架構，說明你如何處理不同模態的延遲差異（文字 200ms、圖片 800ms、語音 1200ms）、模態融合策略選擇依據、以及當某個模態服務降級時整個系統如何維持可用性。 一、專案目標：多模態商業智慧分析平台需求 這個 Capstone 專案整合了本系列所有核心技術：語言模型（Phase 7–9）、RAG（Phase 11）、Agent（Phase 13）、效能優化（Phase 17–18）、語音處理（Phase 6）、視覺理解（Phase 19 Part 1–2），最終構建一個真實可用的多模態商業智慧分析平台。 1.1 功能需求 輸入能力 模態 具體場景 典型檔案大小 預期延遲 文字 問題查詢、上下文指令 < 4KB 200ms 圖片 截圖、圖表、掃描文件 100KB–5MB 600–1200ms PDF 財務報告、合約文件 1–50MB 2000–8000ms 語音 口頭指令、語音備忘 10–120 秒音訊 800–2000ms 結構化資料 Excel/CSV 數據 < 10MB 300–600ms 輸出能力