https://yennj12.js.org/yennj12_blog_V4/tags/rag/Recent content in RAG on YennJ12 Engineering BlogHugo -- gohugo.ioen-usTue, 30 Jun 2026 12:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-core-concept-1-context-management-zh/Mon, 08 Jun 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-core-concept-1-context-management-zh/Context Management 的本質是：在有限的 Token 預算內，決定哪些資訊值得保留、哪些必須壓縮或捨棄——這是所有長對話 AI 系統的核心資源排程問題。 一、為什麼面試官問這個 面試官測試的核心能力： 系統資源意識：你是否理解 LLM 的上下文視窗是有限的硬性限制，而非軟性建議？能否量化每個元件的 Token 消耗？Token waterfall 問題若不主動管理，100 輪對話後必然觸發截斷或 OOM。 Trade-off 判斷力：截斷策略的選擇（FIFO vs. 重要性加權 vs. 摘要壓縮）直接影響對話品質，面試官想看你能否說清楚「何時選哪種、代價是什麼」，而不是背誦一個萬用答案。 生產可操作性：理論上知道「要做 context trimming」很容易，但能否描述 LangGraph MemorySaver 的週期摘要節點、如何做 tenant-level 成本歸因，才是資深工程師的標誌。 弱答案長這樣：「我們用滑動視窗，把最舊的訊息刪掉就好。」——沒有量化 Token 預算、沒有解釋為什麼 FIFO 在長對話中會丟失關鍵系統指令。 強答案長這樣：「128K context 視窗中，system prompt 佔 8K、tools schema 佔 12K，剩餘 108K 給 history + answer。我們設 history ceiling 為 80K、answer reserve 為 28K。超過 history ceiling 時觸發階層式摘要：先壓縮最舊的 20 輪，~6K tokens 壓成 ~500 tokens，然後再做 FIFO。這樣能維持對話連貫性同時控制成本。壓縮比約 13:1，每次摘要呼叫用 Gemini Flash，成本不到主對話的 5%。」https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part1-rag-zh/Sat, 30 May 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part1-rag-zh/我在 Google 做 AI 工程，也是面試官。 這是一份寫給準備 FDE 面試的人看的系列。 不是教科書，是我站在白板前問過你才懂的那種。 面試情境 面試官：「解釋一下 RAG 的架構，以及你會怎麼設計一個生產可用的 RAG 系統。如果 RAG 的回答品質不好，你怎麼診斷和改善？」 這是 FDE 第一關幾乎必出的題。 能把這題說清楚的人，比你想像中少。 一、RAG 是什麼 用一句話說完： RAG = 讓 LLM 在回答前，先去查資料。 不讓它憑空捏造，而是給它上下文，再要求它根據上下文回答。 完整流程，五個步驟 使用者問題 ↓ ① Embedding（把問題變成向量） ↓ ② Retrieval（從向量資料庫搜尋相關文件） ↓ ③ Context Injection（把文件塞進 Prompt） ↓ ④ Generation（LLM 根據 Prompt 生成回答） ↓ 回答（附來源引用） 二、RAG 在完整系統中的位置 面試官問系統設計，RAG 不是一個獨立存在的 Pipeline，而是整個 AI 系統的一個子系統。你要能說清楚它和誰互動、它的邊界在哪裡。 ┌──────────────────────────────────────────────────────────────┐ │ 完整 RAG 系統架構 │ │ │ │ 用戶 Query │ │ │ │ │ ▼ │ │ ┌─────────────┐ ┌──────────────────────────────────┐ │ │ │ Query Layer │ │ Knowledge Base │ │ │ │ │ │ │ │ │ │ ├─ 意圖分類 │ │ 原始文件 → Chunking → Embedding │ │ │ │ └─ 改寫 │ │ → Vector DB Index │ │ │ └──────┬──────┘ └──────────────────────────────────┘ │ │ │ ↑ 離線建立 │ │ ▼ 線上查詢 │ │ │ ┌──────────────────────────────────────────────────┐ │ │ │ Retrieval Layer │ │ │ │ │ │ │ │ Query Embedding → Vector DB → Top-K Candidates │ │ │ │ ↓ │ │ │ │ Reranker（可選） │ │ │ │ ↓ │ │ │ │ Final Context（3-5 chunks） │ │ │ └──────────────────────────────────────────────────┘ │ │ │ │ │ ▼ │ │ ┌──────────────────────────────────────────────────┐ │ │ │ Generation Layer │ │ │ │ │ │ │ │ System Prompt + Context + Query → LLM → 回答 │ │ │ └──────────────────────────────────────────────────┘ │ └──────────────────────────────────────────────────────────────┘ 三、RAG vs Fine-tuning：面試必考對比題 這是我最愛問的對比題。很多人答得很模糊。https://yennj12.js.org/yennj12_blog_V4/posts/rag-series-part1-foundations-zh/Sat, 16 May 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/rag-series-part1-foundations-zh/前言 如果你曾經問過 ChatGPT 最新的新聞，它會告訴你它的知識有截止日期（knowledge cutoff）。 如果你問它你公司內部的文件，它完全不知道。 這是大型語言模型（LLM）的根本限制：訓練資料是靜態的。 RAG（Retrieval-Augmented Generation） 就是解決這個問題的主流方法。它讓 LLM 在回答前先「查資料」，就像一個學生考試時可以翻開參考書——而不是完全靠記憶。 這個系列共五篇，帶你從基礎到進階，完整掌握 RAG 的設計與優化。 為什麼 LLM 需要 RAG？ LLM 的三大知識限制 問題 說明 知識截止日期 模型只知道訓練時間點之前的資訊 無法存取私有資料 公司內部文件、資料庫、個人筆記都不在訓練集裡 幻覺（Hallucination） 對不確定的問題，模型會「編造」聽起來合理的答案 解法比較 方案 A：Fine-tuning（微調） 優點：模型真正「學會」知識 缺點：成本高、資料需要大量、難以更新、模型大小增加 方案 B：RAG（檢索增強生成） 優點：即時更新、成本低、可追溯來源 缺點：需要維護向量資料庫、回答品質受檢索品質影響 結論：對大多數企業應用，RAG 是更實際的選擇。Fine-tuning 適合改變模型「風格」或「推理方式」，不適合注入大量知識。 RAG 的核心架構 一個標準的 RAG 系統分成兩個主要流程： 1. 索引流程（Indexing Pipeline）— 離線執行 原始文件（PDF、Word、網頁） ↓ 文字擷取（Text Extraction） ↓ 切塊（Chunking）— 將長文件切成小片段 ↓ 向量化（Embedding）— 將文字轉成數字向量 ↓ 存入向量資料庫（Vector Store） 2. 查詢流程（Query Pipeline）— 即時執行 使用者問題（Query） ↓ 向量化（Query Embedding） ↓ 向量搜尋（Similarity Search）— 找出最相關的文件片段 ↓ 組合 Prompt（Context + Question） ↓ LLM 生成答案（Generation） ↓ 回傳給使用者 這個最基本的架構被稱為 Naive RAG（樸素 RAG）。https://yennj12.js.org/yennj12_blog_V4/posts/rag-series-part2-chunking-vectordb-zh/Sun, 17 May 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/rag-series-part2-chunking-vectordb-zh/前言 上一篇我們建立了一個最基本的 RAG pipeline。 但實際上，Chunking 策略和向量資料庫的選型會直接決定你的 RAG 系統品質。 這篇深入討論這兩個核心基礎建設。 Part 1：Chunking 策略 Chunking 是把長文件切成小片段的過程。切法不對，後面的搜尋再精準也救不了。 為什麼 Chunking 很重要？ 想像你有一篇 10,000 字的技術文章，如果直接整篇丟進去，問「Python 的優點是什麼」，向量搜尋要在 10,000 字的「語意海洋」裡找到準確答案，難度極高。 好的 Chunking 原則： 每個 chunk 應該是語意完整的單元（不要切斷句子、段落中間） 大小適中：太小 → 資訊不夠完整；太大 → 搜尋精準度下降 有適度重疊（overlap）：避免邊界上的資訊遺漏 策略 1：固定大小切塊（Fixed-Size Chunking） 最簡單的方法，按字元數或 token 數切割。 1from langchain_text_splitters import CharacterTextSplitter 2 3splitter = CharacterTextSplitter( 4 chunk_size=500, 5 chunk_overlap=50, 6 separator="\n", # 優先在換行處切割 7) 8 9text = "你的長文字..." 10chunks = splitter.split_text(text) 優點：簡單、可預測、實作快速 缺點：可能把語意相關的句子切開 適合：快速原型、結構單純的文件 策略 2：遞迴字元切塊（Recursive Character Chunking） 這是最常用的預設策略。它會依照優先順序嘗試不同分隔符： \n\n → \n → .https://yennj12.js.org/yennj12_blog_V4/posts/ai-fde-essential-guide-part3-zh/Tue, 26 May 2026 17:01:52 +0900https://yennj12.js.org/yennj12_blog_V4/posts/ai-fde-essential-guide-part3-zh/前言 企業級 AI 整合與部署是 AI FDE 最具挑戰性的工作之一。需要處理複雜的企業架構、安全合規要求、數據整合與系統可靠性問題。本文將深入探討雲端平台部署策略、企業安全框架、RAG 架構設計與數據管道建構等核心技術。 1. 雲端平台部署策略 Google Cloud Platform (GCP) 深度整合 Vertex AI 生產部署： 1from google.cloud import aiplatform 2from google.cloud.aiplatform import gapic 3import yaml 4 5class GCPAIDeploymentManager: 6 def __init__(self, project_id: str, region: str = "us-central1"): 7 self.project_id = project_id 8 self.region = region 9 10 # 初始化 Vertex AI 11 aiplatform.init( 12 project=project_id, 13 location=region, 14 staging_bucket=f"gs://{project_id}-ml-staging" 15 ) 16 17 def deploy_custom_model(self, model_config: dict): 18 """部署客製化模型到 Vertex AI""" 19 20 # 創建容器映像 21 container_spec = { 22 "image_uri": model_config["container_image"], 23 "env": [ 24 {"name": "MODEL_NAME", "value": model_config["model_name"]}, 25 {"name": "MODEL_VERSION", "value": model_config["version"]}, 26 {"name": "BATCH_SIZE", "value": str(model_config.https://yennj12.js.org/yennj12_blog_V4/posts/ai-accuracy-evaluation-part3-zh/Mon, 18 May 2026 11:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-accuracy-evaluation-part3-zh/前言：RAG 帶來了新的評估挑戰 在第一篇和第二篇中，我們分別探討了傳統機器學習任務與 LLM 的評估方法。 現在，許多企業級 AI 應用走向了 RAG（Retrieval-Augmented Generation）架構： 用戶問題 ↓ [檢索器] → 從知識庫取出相關文件段落（Context） ↓ [LLM] → 根據 Context 生成回答 ↓ 最終答案 RAG 的評估比純 LLM 更複雜，因為它有兩個可能出錯的環節： 檢索器：有沒有找到正確的資料？ 生成器（LLM）：有沒有忠實地根據資料回答，而不是憑空幻想？ 本文將系統性地介紹 RAG 的評估框架，包括核心指標、評估工具（RAGAS），以及企業實際落地時的最佳實踐。 一、RAG 評估的三個核心維度 評估一個 RAG 系統，需要從三個維度同時切入： ┌─────────────────┐ │ 用戶問題 (Q) │ └────────┬────────┘ │ ┌──────────────▼──────────────┐ │ 檢索器 │ └──────────────┬──────────────┘ │ ┌──────────────▼──────────────┐ │ 檢索到的 Context (C) │ ← 評估維度 1：檢索品質 └──────────────┬──────────────┘ │ ┌──────────────▼──────────────┐ │ LLM 生成 │ └──────────────┬──────────────┘ │ ┌──────────────▼──────────────┐ │ 最終答案 (A) │ ← 評估維度 2：生成品質 └─────────────────────────────┘ │ ← 評估維度 3：端到端品質（Q→A） 二、核心指標詳解 2.https://yennj12.js.org/yennj12_blog_V4/posts/rag-series-part3-advanced-retrieval-zh/Mon, 18 May 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/rag-series-part3-advanced-retrieval-zh/前言 Naive RAG 的核心問題：搜尋品質決定了答案品質。 一個常見的現象是，明明知識庫裡有答案，但因為使用者的問題措辭跟文件不同，向量搜尋就找不到。或者，找到的 Top-5 結果裡，真正相關的其實排在第 4 位，LLM 因此被無關資訊干擾。 這篇介紹四個能顯著提升搜尋品質的技術。 技術 1：混合搜尋（Hybrid Search） 核心問題 純向量搜尋（Semantic Search）擅長找「語意相近」的內容，但對精確術語、專有名詞、縮寫效果差。 問題：「GPT-4o 的 context window 是多少？」 純向量搜尋找到：「大型語言模型通常有輸入長度限制...」（語意相近但沒答案） BM25 關鍵字搜尋找到：「GPT-4o 支援 128K token 的 context window」（精確命中） 混合搜尋 = 語意搜尋 + 關鍵字搜尋，兩者結果用 RRF 或加權融合。 BM25 簡介 BM25 是 TF-IDF 的改進版，計算關鍵字與文件的相關度： Score(D, Q) = Σ IDF(qi) * (tf(qi, D) * (k1 + 1)) / (tf(qi, D) + k1 * (1 - b + b * |D| / avgdl)) 不需要理解公式，只需知道：BM25 對精確詞彙匹配非常靈敏。https://yennj12.js.org/yennj12_blog_V4/posts/knowledge-graph-part4-llm-graphrag-zh/Mon, 29 Jun 2026 12:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/knowledge-graph-part4-llm-graphrag-zh/大多數人遇到 RAG 答不準，第一反應是換更強的 embedding 模型。 正確答案是：多跳問題的瓶頸不在召回相似度，而在缺少「關係結構」。 大多數人以為知識圖譜和 LLM 是兩個世界。 正確答案是：LLM 負責語言理解，知識圖譜負責事實與推理，合起來才完整。 接續前文 Part 3 我們確立了「知識圖譜與向量庫互補」。這一篇把它落地到 LLM 系統：解釋 GraphRAG 為什麼出現、它如何運作、以及用 LangChain + Neo4j 寫出可跑的程式碼。 一、核心問題：純向量 RAG 在哪裡失敗？ 標準 RAG（Retrieval-Augmented Generation）流程是：把文件切塊（chunk）→ 算 embedding → 存向量庫 → 查詢時找最相似的塊 → 塞進 prompt。這對「事實型單跳問題」很有效，但有兩個致命弱點： 弱點一：多跳推理（multi-hop） 問題：「全面啟動的配樂家，還為哪位導演的哪部片配過樂？」 純向量 RAG 的困境： Query embedding ──▶ 找最相似的塊 │ ▼ 只會召回「提到全面啟動配樂」的段落 但「配樂家 → 其他作品 → 那部片的導演」這條關係鏈 分散在不同文件、不同塊裡，相似度檢索串不起來 ✗ 向量檢索本質是「單跳相似」。它無法沿著「實體 A → 關係 → 實體 B → 關係 → 實體 C」的鏈條走，因為這需要的是結構，不是相似度。https://yennj12.js.org/yennj12_blog_V4/posts/fde-core-concept-4-hybrid-search-rrf-zh/Mon, 08 Jun 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-core-concept-4-hybrid-search-rrf-zh/單一檢索模態最多只能取得 72% 的 Recall；混合 Dense + Sparse 搭配 RRF 融合，可將 Recall@10 推至 84%——多 12 個百分點就是 RAG 系統品質的分水嶺。 一、為什麼面試官問這個 面試官透過這個題目在測試三個層次的能力，每個層次都有明確的弱答案與強答案之分： 測試點一：你是否理解「向量相似度 ≠ 文字匹配」的本質差異 純 Dense 搜尋對「GPT-4o」、「CVE-2024-1234」、「iPhone 16 Pro Max」這類精確字串幾乎無效。Bi-encoder 把這些字串編碼到連續向量空間後，拼寫上的微小差異可能造成 cosine similarity 大幅下降，但語意上確實是同一件事。反過來，純 BM25 對「汽車」vs「轎車」、「機器學習」vs「ML」的語意等價完全失明——詞彙不交疊，BM25 分數為零。沒有一種模態可以獨立超越 75% 的 Recall。 測試點二：你是否能量化 tradeoff，而非只說「混合比較好」 弱答案：「我會把兩個結果合併起來，這樣召回率會更高。」 強答案：「dense-only recall@10 = 72%，sparse-only recall@10 = 68%，hybrid RRF = 84%。關鍵在 k=60 的平滑常數讓兩個信號貢獻均衡；若某個模態明顯更優（差距 > 15pp），改用 k=10–20 放大強模態影響力。」 測試點三：你是否了解雲端具體實作路徑 能說出「Vertex AI Search 內建 hybrid mode」和「BigQuery Vector Search 可用 VECTOR_SEARCH() + SEARCH() 在 SQL 層組合」的候選人，遠比只談演算法理論的人有說服力。這說明你真的在生產環境中做過，而不是只讀過論文。https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part4-system-design-zh/Sat, 30 May 2026 11:30:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part4-system-design-zh/System Design 是 FDE 面試最能展現工程深度的地方。 面試官不是要你「寫出可以跑的程式碼」， 他想看的是：你在有限資訊下，怎麼做設計決策、怎麼說清楚 trade-off。 面試情境 面試官：「請你設計一個供企業內部使用的 AI 知識庫問答系統，員工可以用自然語言查詢公司政策、產品說明和技術文件。第二題：設計一個 AI Copilot，讓員工用自然語言查詢公司內部數據，例如『今年 Q3 的營收比 Q2 成長了多少？』」 一、System Design 面試的本質 面試官考系統設計，不是要標準答案，是要看三件事： 考點 1：釐清問題的習慣 你有沒有在設計前先問問題？ → 不假設，先問。沒有釐清需求就開始畫圖是大扣分。 考點 2：Trade-off 思維 你說的不是「最好的方案」，而是： 「在這個場景下，我選 X 而不是 Y，因為...」 考點 3：生產環境的現實感 Auth、RBAC、Scale、Cost、Failure Mode—— 有沒有考慮到，是高手和普通人的分水嶺。 二、第一題：企業知識庫 Chatbot 步驟一：釐清需求（你要主動問） 你應該問的問題： 需求面： ├── 同時使用的用戶數量級？（100 人 vs 10 萬人，架構差很多） ├── 文件量多大？（1GB vs 1TB） ├── 回答需要引用文件來源嗎？ └── Latency 要求？（秒級 vs 毫秒級） 安全面（這是 FDE 常被忽略的）： ├── 不同部門能看的文件不同嗎？→ 決定要不要 RBAC ├── 有合規要求嗎？（GDPR、SOC 2） └── 資料能放在公有雲嗎？ 這些問題決定你的架構複雜度。 先問，再設計。 步驟二：完整系統架構 ┌─────────────────────────────────────────────────────────────┐ │ 用戶層 │ │ Browser / Slack Bot / Mobile App │ └───────────────────────────┬─────────────────────────────────┘ │ HTTPS ┌───────────────────────────▼─────────────────────────────────┐ │ API Gateway 層 │ │ ├── SSO Token 驗證（Google Workspace / Okta） │ │ ├── Rate Limiting（防止濫用） │ │ └── 請求日誌（Audit Log 起點） │ └───────────────────────────┬─────────────────────────────────┘ │ 已驗證的用戶 context ┌───────────────────────────▼─────────────────────────────────┐ │ Chatbot Service 層 │ │ │ │ ┌────────────────────┐ ┌─────────────────────────────┐ │ │ │ Query Processor │ │ RBAC Module │ │ │ │ ├── 意圖分類 │ │ 「這個用戶能看哪些文件？」 │ │ │ │ └── Query Rewrite │ │ 在查詢前過濾，不是查完再過濾 │ │ │ └────────────────────┘ └─────────────────────────────┘ │ │ │ │ ┌──────────────────────────────────────────────────────┐ │ │ │ RAG Engine │ │ │ │ Query → Embedding → [Vector DB + RBAC Filter] │ │ │ │ → Reranker → Context Injection → LLM │ │ │ └──────────────────────────────────────────────────────┘ │ └───────────────────────────┬─────────────────────────────────┘ │ ┌───────────────┬───────────▼──────────┬──────────────────────┐ │ Cache Layer │ Response Generator │ Logging & Monitoring│ │ （相同問題） │ （加入引用來源） │ （審計 + 成本追蹤） │ └───────────────┴───────────────────────┴──────────────────────┘ 設計決策一：Authentication 的選型 選項比較： API Key JWT + SSO ──────────────────────────────────────────────────────── 適合場景 機器對機器 人類用戶登入 身分追蹤 無（共用 key） 有（每個 token 帶用戶身分） RBAC 支援 無（要額外設計） 原生（token payload 帶角色） Token 輪換 麻煩 自動（SSO refresh） 企業整合 困難 直接接 Google Workspace / Okta 結論：企業知識庫選 JWT + SSO token payload 帶 user_id、department、roles， 後面所有服務直接讀，不需要每次去查資料庫 面試官最想聽到的一句話：https://yennj12.js.org/yennj12_blog_V4/posts/rag-series-part4-optimization-zh/Tue, 19 May 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/rag-series-part4-optimization-zh/前言 前兩篇解決了「搜尋」的問題。這篇要解決兩個更深層的問題： 問題本身就難以直接搜尋：複雜問題需要先轉換或拆解 Context 品質不夠純粹：塞給 LLM 的資訊裡有太多噪音 這裡介紹三個技術：Step-Back Prompting（退一步提問）、Self-RAG（自我反思 RAG）、Context Compression（上下文壓縮）。 技術 1：查詢轉換（Query Transformation） 問題：複雜問題無法直接搜尋 有些問題不適合直接拿來做向量搜尋： ❌ 直接搜尋困難的問題類型： 「為什麼我們公司的 API 最近變慢了？」 → 問題太具體，知識庫不可能有這個答案 「除了 Redis，還有哪些快取方案？」 → 包含否定條件，搜尋容易找到 Redis 的文章 「比較 PostgreSQL 和 MySQL 的優缺點，然後說明哪個適合我們的場景」 → 多個子問題，一次搜尋無法全部覆蓋 Step-Back Prompting（退一步提問） 核心思想：先把具體問題「退一步」抽象化，搜尋更通用的背景知識，再回答具體問題。 具體問題：「Estrogen 會影響 BRCA1 的 transcription 嗎？」 退一步：「BRCA1 基因的調控機制是什麼？」 → 先搜尋通用知識，再回答具體問題 1import openai 2 3client = openai.OpenAI(api_key="your-api-key") 4 5 6def step_back_query(original_query: str) -> str: 7 """生成一個比原始問題更抽象的退一步問題""" 8 prompt = f"""你是一個搜尋查詢優化助手。 9將以下具體問題「退一步」，改寫成一個更通用、更基本的問題， 10這個更通用的問題可以幫助找到回答原始問題所需的背景知識。 11 12具體問題：{original_query} 13 14更通用的退一步問題（只輸出問題，不要解釋）：""" 15 16 response = client.https://yennj12.js.org/yennj12_blog_V4/posts/fde-core-concept-5-reranking-cross-encoder-zh/Mon, 08 Jun 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-core-concept-5-reranking-cross-encoder-zh/核心定義：Re-ranking 是「先用 Bi-Encoder 快速縮小候選集，再用 Cross-Encoder 精準評分」的兩階段架構——用 10ms 的粗召回換取可接受的候選集，再用 150ms 的深度交互換取 LLM 真正需要的高品質上下文。 一、為什麼面試官問這個 面試官實際測試的能力： 你知道「快」和「準」之間的工程取捨嗎？ Bi-Encoder 可預計算、延遲低，Cross-Encoder 不可預計算但精準——能不能說清楚這兩者的差異，是區分背了課文還是真正理解原理的關鍵。 你能把數字說出來嗎？ 弱答：「Re-ranking 可以提升準確率。」強答：「ANN-only MRR@5 約 0.61，加上 Cross-Encoder 重排後升至 0.79，提升約 30%，幻覺率同步下降約 40%。」 你知道什麼時候不該用嗎？ 盲目加 Cross-Encoder 在延遲 SLA < 200ms 的場景會直接違反 SLA。強答必須包含 skip 條件。 弱答 vs 強答對比： 維度 弱答 強答 定義 「對搜索結果重新排序」 解釋 Bi-Encoder 獨立編碼 vs Cross-Encoder 聯合編碼的機制差異 數字 無 MRR@5 +30%、幻覺 -40%、延遲 +150ms、成本 +$0.002/query 取捨 「有點慢」 說明延遲預算分配：ANN 10ms + CE 150ms + LLM 800ms ≈ 960ms 跳過條件 未提及 明確指出 <200ms SLA 應改用 ColBERT 或接受 ANN 品質 二、核心原理與技術深度 Bi-Encoder 與 Cross-Encoder 的本質差異 兩種模型架構解決同一個問題（語意相關性），但用完全不同的方式：https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part5-rag-deep-dive-zh/Sun, 31 May 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part5-rag-deep-dive-zh/第一篇講了 RAG 是什麼。 這篇講你在面試中被追問到第三層時，你能不能答上來。 面試官最喜歡的問法是：「那你為什麼這樣設計？有沒有考慮過別的方案？」 面試情境 面試官：「你的 RAG 系統 Chunking 怎麼設計的？為什麼？你的 Embedding 模型怎麼選的？如果純向量搜尋找不到正確答案，你怎麼改善？Context Window 滿了怎麼辦？」 這四個問題是 RAG 系統設計的完整追問鏈。每一層都要能說清楚選擇背後的 trade-off。 一、Chunking 策略：不是切越小越好 Chunking 是 RAG 最常被輕描淡寫的環節，但它直接決定你的檢索品質。 面試官問法通常是： 「你的 RAG 系統 Chunking 怎麼設計的？為什麼？」 Fixed-Size Chunking（固定大小切分） 最簡單的做法：每 N 個 token 切一塊，加上一點 overlap。 chunk_size = 512 chunk_overlap = 50 優點： 實作簡單 預測性高，每塊大小一致 Embedding 成本可控 缺點： 完全不管語意邊界 一個句子可能被切成兩半 段落邏輯可能斷裂 適用場景： 文件格式高度結構化（例如：財報、合約） 快速原型，先跑起來再優化 Semantic Chunking（語意切分） 根據語意相似度決定切分點。計算相鄰句子的 embedding 距離，距離突然變大的地方就是自然的段落邊界。 優點： 保留語意完整性 每塊的內聚度更高，向量品質更好 特別適合長文、報告、文章 缺點： 計算成本更高（每個句子都要先 embed） Chunk 大小不固定，向量 DB 設計要考慮 實作複雜度較高 工具： LangChain 的 SemanticChunker、llmsherpahttps://yennj12.js.org/yennj12_blog_V4/posts/rag-series-part5-production-zh/Wed, 20 May 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/rag-series-part5-production-zh/前言 你的 RAG 系統「感覺」不錯，但你能量化它有多好嗎？ 這是生產環境中最常見的盲區：工程師花大量時間優化 Chunking、調整 Reranker，卻沒有客觀的指標來驗證改動是否真的有效。 這篇是系列的最後一篇，涵蓋三個主題： RAG 評估（RAGAS）：如何量化 RAG 品質 GraphRAG：當向量搜尋不夠用時的替代方案 Agentic RAG：RAG + Agent，讓 AI 自己決定如何搜尋 Part 1：RAG 評估——RAGAS 框架 為什麼評估很難？ RAG 的輸出是自然語言，沒有標準答案可以直接比對。 「這個答案好不好」，需要從多個維度判斷。 RAGAS 的四個核心指標 RAGAS（RAG Assessment） 是目前最流行的 RAG 評估框架，定義了四個指標： 1. Faithfulness（忠實度） 答案是否只根據 context，沒有幻覺？ 計算方式： Step 1: 把答案分解成一組陳述句（claims） Step 2: 對每個陳述，判斷 context 是否支持它 Step 3: Faithfulness = 有 context 支持的陳述數 / 總陳述數 理想值：接近 1.0 2. Answer Relevancy（答案相關性） 答案是否真的回答了問題？ 計算方式： Step 1: 讓 LLM 根據答案生成 N 個「可能的問題」 Step 2: 計算這些問題與原始問題的向量相似度 Step 3: Answer Relevancy = 平均相似度 理想值：接近 1.https://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/fde-interview-guide-part9-llm-core-zh/Sun, 31 May 2026 11:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part9-llm-core-zh/這篇是 FDE 面試系列的最後一篇基礎知識篇。 LLM 的這三塊——Token、Prompt Engineering、Embedding—— 是你每天都在用的工具，但能說清楚的人比你想像中少。 說得清楚，就是專業的訊號。 面試情境 面試官：「你的 RAG 系統的 context budget 怎麼設計的？如果你要讓 LLM 做複雜推理，你用什麼 Prompting 技法？為什麼選 text-embedding-004 而不是 OpenAI 的 embedding？」 這三個問題把 Token、Prompt Engineering、Embedding 串在一起問，測的是你有沒有把這些工具整合進系統設計的意識。 一、Token：不是字，是 LLM 的計量單位 面試官問： 「Context Window 是什麼？對你的系統設計有什麼影響？」 Token 是什麼 LLM 不是以字元或單詞為單位處理文字，而是以 Token 為單位。 Token 是 Tokenizer 切出來的文字片段，大小不固定： "Hello world" → ["Hello", " world"] → 2 tokens "LLM" → ["L", "LM"] → 2 tokens（或 1 token，取決於 tokenizer） "不可思議" → ["不", "可", "思", "議"] → 4 tokens（中文通常 1 字 = 1 token） 粗略換算（GPT/Gemini 系列）：https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part12-agent-evaluation-zh/Wed, 03 Jun 2026 11:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part12-agent-evaluation-zh/你怎麼知道 Agent 可以上線？ 直覺不算，「感覺還不錯」不算。 FDE 的工作是把感覺轉成數字，把數字轉成信心——讓客戶的工程團隊能基於證據做決定。 一、核心問題：「夠好」的標準是什麼 Agent 評估的難點不是「怎麼算分」，而是「對誰問什麼問題，要達到什麼分才算夠好」。 三個不同維度的「夠好」： 評估的三個維度（缺一不可） ┌───────────────────┐ ┌───────────────────┐ ┌───────────────────┐ │ 效能（Performance）│ │ 品質（Quality） │ │ 業務（Business） │ │ │ │ │ │ │ │ 快不快？ │ │ 對不對？ │ │ 有沒有用？ │ │ 貴不貴？ │ │ 準不準？ │ │ 用戶滿不滿意？ │ │ │ │ │ │ │ │ tokens/sec │ │ Faithfulness │ │ Task completion │ │ p95 latency │ │ Relevance │ │ User retention │ │ cost/request │ │ Groundedness │ │ Escalation rate │ └───────────────────┘ └───────────────────┘ └───────────────────┘ ↑ ↑ ↑ 系統層關心 工程師關心 客戶關心 只看品質、不看效能：上線後延遲爆炸。https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part14-memory-architecture-zh/Wed, 03 Jun 2026 13:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part14-memory-architecture-zh/LLM 是無狀態的，但用戶是有狀態的。 Memory 系統要解決的問題只有一個： 讓無狀態的 LLM 表現得像是「記得你」。 怎麼設計這個橋樑，以及這個橋樑的代價——是這篇的核心。 一、核心問題：為什麼需要不同類型的 Memory 沒有 Memory 的 Agent 每次對話從零開始： Session 1： User: "我主要用 Python，偏好簡短的回答" Agent: "好的！" （記不住） Session 2（三天後）： User: "幫我寫一個排序函數" Agent: "您好！請問您用哪種程式語言？" ↑ 明明說過了，還在問 但「把所有對話都記住」也不可行： 問題 1：儲存量 10K 用戶 × 每天 10 輪 × 365 天 = 3,650 萬條對話記錄 問題 2：Context 限制 把所有歷史塞進 LLM context → 超過 context window 問題 3：相關性 3 年前討論的內容，現在可能完全不相關 結論：需要多種記憶類型，各自解決不同的問題。 二、四種記憶類型：各解決什麼問題 問題 解決方案 ───────────────────────────────────────────────────── 當前對話的臨時狀態？ → Working Memory（工作記憶） LLM context window 生命週期：當次對話 記得過去發生過什麼？ → Episodic Memory（情節記憶） 向量化的對話歷史 生命週期：跨 session，可衰減 記得這個人是什麼樣的人？→ Semantic Memory（語意記憶） 結構化的 user profile 生命週期：持久化，主動更新 知道怎麼做某件事？ → Procedural Memory（程序記憶） Few-shot examples / Fine-tuning 生命週期：模型層，最持久 三、完整 Memory 架構圖 用戶請求 │ ▼ ┌──────────────────────────────────────────────┐ │ Memory Retrieval Layer │ │ │ │ ┌──────────────────────┐ │ │ │ Semantic Memory │ ← 用戶偏好、profile │ │ │ (Structured DB) │ 每次對話都載入 │ │ └──────────────────────┘ │ │ + │ │ ┌──────────────────────┐ │ │ │ Episodic Memory │ ← 相關歷史片段 │ │ │ (Vector DB) │ 按語意相似度召回 │ │ └──────────────────────┘ │ └──────────────────┬───────────────────────────┘ │ 組合成 Working Memory ▼ ┌──────────────────────────────────────────────┐ │ Working Memory │ │ (LLM Context Window) │ │ │ │ [System Prompt] │ │ [User Profile from Semantic Memory] │ │ [Relevant History from Episodic Memory] │ │ [Current Conversation] │ │ [Current Query] │ └──────────────────┬───────────────────────────┘ │ ▼ LLM │ ▼ 回應 │ （對話結束後，非同步） ▼ ┌──────────────────────────────────────────────┐ │ Memory Update Layer │ │ │ │ ┌────────────────────────────┐ │ │ │ 提取重要資訊 │ │ │ │ → 更新 Semantic Memory │ ← 偏好、事實 │ │ └────────────────────────────┘ │ │ ┌────────────────────────────┐ │ │ │ 壓縮對話摘要 │ │ │ │ → 存入 Episodic Memory │ ← 做了什麼 │ │ └────────────────────────────┘ │ └──────────────────────────────────────────────┘ 關鍵設計決策：Memory Update 是非同步的https://yennj12.js.org/yennj12_blog_V4/posts/fde-core-concept-15-vector-drift-blue-green-zh/Mon, 08 Jun 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-core-concept-15-vector-drift-blue-green-zh/核心定義：向量索引的「健康度」不等於資料存在，而是指 HNSW 圖的連結品質——增量插入累積後圖結構失衡，recall 靜默下滑；Blue-Green 重建搭配 Lambda 雙索引架構，是兼顧零停機與高精度的唯一根治手段。 一、為什麼面試官問這個 RAG 系統上線後，工程師最容易忽略的問題不是「向量有沒有進去」，而是「向量索引精度是否隨時間穩定」。向量資料庫不像關聯式資料庫——寫入成功不等於查詢品質維持。面試官問這個，實際在測試三個層次的判斷力： 你是否理解 ANN 索引的內部結構：HNSW 不是 B-Tree，插入操作不做全域重平衡，因此 recall 會隨增量操作靜默衰退。候選人若只知道「向量存進去就能查」，代表從未在生產規模下操作過 RAG。 你是否能設計「寫入友好 + 讀取高精度」的分層架構：Lambda 架構在向量場景的應用屬於進階知識。弱答案只說「定期重建索引」卻無法說明如何做到零停機；強答案會畫出 Base + Delta 雙索引，並描述夜間管線的每一個驗證步驟。 你是否有刪除場景的務實方案：向量資料庫普遍不支援就地刪除後的圖修復，黑名單過濾是業界慣例。候選人若不知道，代表缺乏真實生產維運經驗。 弱答案特徵：「我們每週排程重建索引，重建期間暫停寫入。」沒有說明 recall 衰退速率、重建後如何驗證、流量如何切換、舊索引如何回滾。 強答案特徵：點出 HNSW 圖失衡的具體機制（節點鄰居數不均、長尾節點導致搜尋路徑加長），提出 Base + Delta 雙索引架構及查詢合併策略，描述 recall@10 golden-set 驗證閾值（≥ 90%），以及 10% → 50% → 100% 漸進流量切換與 24 小時回滾窗口的完整流程。 面試情境：「你的 RAG 系統上線六個月後，客服團隊反映搜尋到的文章越來越舊、越來越不相關，但後台顯示知識庫文件每天都有新增。你的 vector search 服務的 QPS 和錯誤率都正常。你怎麼診斷，又怎麼解決？」 這個情境的陷阱在於——所有「系統健康」指標都正常，問題是隱性的精度衰退。正確的診斷路徑是： 先查 delta_index_size：若六個月來持續增量、從未重建，Delta 可能已累積數十萬筆——HNSW 圖嚴重漂移。 對 golden test set 執行 recall@10 採樣，確認數字（如：發現 recall 已從 94% 跌至 71%）。 執行緊急全量重建，驗證通過後 Blue-Green swap，並建立夜間排程防止再次發生。 補建監控：delta_index_size 超過 40K 時告警，每小時採樣 recall。 二、核心原理與技術深度 HNSW 圖為什麼會漂移（Drift） HNSW（Hierarchical Navigable Small World）是目前最主流的 ANN 索引結構。它在建構時為每個節點在各層維持固定的鄰居數（參數 M，通常 16–64），搜尋時從最頂層貪心向下導航，每層選取距離 query 最近的鄰居繼續往下，直到 Layer 0 收集候選集。理論上在 M=16, efConstruction=200 的設定下，靜態資料集的 recall@10 可達 95%–97%。https://yennj12.js.org/yennj12_blog_V4/posts/fde-core-concept-20-rag-triad-metrics-zh/Mon, 08 Jun 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-core-concept-20-rag-triad-metrics-zh/RAG 系統沒有「準確率」這個單一指標——你需要三把尺同時量：檢索對了嗎？答案有根據嗎？答案回答了問題嗎？少量其中任何一把，幻覺或廢話就悄悄進入生產。 一、為什麼面試官問這個 面試官問 RAG 評估指標，真正在測試的是以下三件事： 你能否把「LLM 答得好不好」拆解成可量化的子問題。 弱答案：「我們用 ROUGE 或 BLEU 評估。」——這是序列生成指標，對 RAG 完全不適用，暴露了對 RAG 工作流程的根本誤解。 你是否理解幻覺的成因與偵測手段。 弱答案：「幻覺是 LLM 的問題，換模型就好。」——強答案會指出 Groundedness（忠實度）是反幻覺的核心指標，並說明如何用 NLI 模型逐句驗證。 你能否把評估指標接進可觀測性管道（OTel → Prometheus → Grafana），讓它在生產中持續追蹤而非一次性評測。 弱答案只談離線評測；強答案談 span attributes、rolling average dashboard、以及 alert threshold。 二、核心原理與技術深度 RAG 三角指標的數學基礎 RAG Triad 由 TruEra（現為 Snowflake 旗下）提出，對應 RAG pipeline 的三個環節： 使用者查詢 (Query) │ ▼ ┌──────────────────────┐ │ Retriever │ ← 指標 1：Context Relevance │ 向量搜尋 / BM25 │ retrieved chunks 與 query 的相似度 └──────────┬───────────┘ │ retrieved context ▼ ┌──────────────────────┐ │ LLM Generator │ ← 指標 2：Groundedness（忠實度） │ Gemini / GPT-4o │ answer 中每個宣稱是否有 context 支撐 └──────────┬───────────┘ │ generated answer ▼ ┌──────────────────────┐ │ Answer Evaluation │ ← 指標 3：Answer Relevance │ Embed / LLM Judge │ answer 是否真正回答了 query └──────────────────────┘ 指標 1：Context Relevance（上下文相關度） 定義：檢索到的 chunks 中，真正與查詢相關的比例。https://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/fde-interview-guide-part44-hybrid-context-rag-zh/Mon, 08 Jun 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part44-hybrid-context-rag-zh/大多數工程師看到 200 萬 Token 的 Context Window，第一反應是：「RAG 已死，直接塞文件就好。」 正確答案是：長文本是一把昂貴的瑞士刀，不是所有任務都值得用它。 優秀的 FDE 設計的不是「選長文本還是 RAG」， 而是一個能在 Runtime 動態決策的混合路由器，把 80% 的查詢成本降低 2500 倍。 面試情境 你的客戶是一家擁有 50,000 名財務分析師的大型投資銀行。他們剛取得了 Gemini 的 200 萬 Token Context Window 存取權，興奮地計劃把整年的財務報表（約 100 萬 Token/份）直接塞給 LLM。當系統上線第一週，並發查詢量衝到 50,000 QPS，P99 延遲爆到 35 秒，TPU Cluster 飽和，成本在 72 小時內燒掉了月度預算。你被緊急召入，如何設計一個「動態混合路由器（Dynamic Hybrid Router）」來同時解決成本、延遲和吞吐量三個問題？ 一、核心問題：為什麼 200 萬 Token 不是銀彈 1.1 長文本的物理限制 200 萬 Token 的 Context Window 是工程奇蹟，但它的成本結構決定了它無法成為通用方案。 關鍵成本不對稱性： 1M Token 長文本請求（Gemini Pro）： 輸入成本：$2.50 / 1M tokens 每次請求輸入：1,000,000 tokens 單次請求成本：$2.https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part49-vector-drift-pipeline-zh/Mon, 08 Jun 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part49-vector-drift-pipeline-zh/大多數工程師的直覺：「索引過期了？重新跑一次 Re-indexing 就好。」 資深 FDE 的直覺：「Re-indexing 要數小時，這期間服務怎麼辦？Re-indexing 之後 HNSW 圖會不會因此失衡？」 大多數工程師的直覺：「那就頻繁做增量更新，隨時保持最新。」 資深 FDE 的直覺：「增量更新累積到一定程度，Graph Drift 會讓 RECALL@10 從 95% 跌到 70%，這才是真正的定時炸彈。」 面試情境 面試官：「你們的企業客戶每天會在 GCS 上新增、修改、刪除數千份 PDF 文件。你們的 AI Agent 需要即時查詢這些知識庫，但現在常常給出已被刪除或過期的內容，讓客戶非常不滿。我知道 Vertex AI Vector Search 支援增量更新，但我聽說大規模頻繁更新會造成 HNSW 圖退化，進而影響搜尋精準度。請告訴我，你會如何設計一套既能即時響應文件變更、又能長期維持向量索引健康度的自動化管線？在系統規模達到百萬向量時，你的設計會有哪些具體調整？」 一、核心問題：為什麼向量索引的「即時性」與「精準度」天生對立？ 1.1 RAG 系統的資料新鮮度危機 在企業 RAG（Retrieval-Augmented Generation）場景中，知識庫並非靜態的。法規文件每週更新、產品手冊每月改版、內部 SOP 隨業務調整。當 AI Agent 仰賴向量檢索來回答問題時，索引延遲（Index Lag）直接等同於「AI 在說謊」。 典型的痛點數字： 文件刪除後，向量索引平均滯後 4–8 小時才能同步 在此期間，Agent 回答基於已廢棄文件的機率高達 23% 企業客戶每月因 AI 給出過期資訊而提交的客訴工單：平均 340 件 1.2 三重矛盾的根本原因 矛盾一：即時性 vs. 批次效率 ┌────────────────────────────────────────────┐ │ 即時更新：每次文件變更立即寫入向量索引 │ │ 優點：延遲 < 30 秒 │ │ 缺點：HNSW 圖節點連結逐漸失衡（Graph Drift）│ │ 每 10K 次增量更新後，RECALL@10 下降約 8%│ └────────────────────────────────────────────┘ 矛盾二：完整重建 vs.https://yennj12.js.org/yennj12_blog_V4/posts/finance-data-ai-pipeline-how-it-works-zh/Tue, 30 Jun 2026 12:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/finance-data-ai-pipeline-how-it-works-zh/多數人做股票分析:打開券商 App,看 K 線、查財報、Google 新聞,然後自己下判斷。 finance_data 的做法:讓 42 個機器人每天定時自己抓數據、自己讀財報、自己寫成繁中研究報告、自己發佈上線——全程沒有人手介入。 這篇就拆解這條「零人工」pipeline 的每一個齒輪是怎麼咬合的。 一、它到底是什麼 finance_data 是一個全自動的 AI 投資研究平台。它覆蓋 30+ 家公司(AAPL、MSFT、NVDA、TSLA、PLTR、台股 0050、2330.tw……),每天自動產生: 個股基本面分析(fundamental analysis) 個股技術面分析(technical analysis) 每日市場新聞摘要(market news) 配合 SEC 申報文件(10-K / 10-Q / 13-F / 6-K)、investor day 簡報、研究 notebook 關鍵字是「全自動」:從定時觸發、抓數據、餵 LLM、生成報告、到建置部署上線,整條鏈沒有任何一步需要人手操作。 整體 pipeline 長這樣: ┌──────────────┐ 每天定時觸發 │ GitHub Actions│ ◀────── cron schedule │ Cron │ └──────┬───────┘ │ 1. 排程把「某支股票 + 某種分析」丟給腳本 ▼ ┌──────────────────────┐ │ 資料蒐集層 │ yfinance + Finviz + StockAnalysis + Roic.https://yennj12.js.org/yennj12_blog_V4/posts/chatpdf-rag-optimization-part3-observability-eval-zh/Tue, 30 Jun 2026 11:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/chatpdf-rag-optimization-part3-observability-eval-zh/多數 RAG 專案上線後,優化全憑「感覺答案變好了」。 但你說不出 faithfulness 是 0.6 還是 0.9,也不知道上次調 alpha 是讓 nDCG 上升還是下降。 這篇講的就是把「感覺」換成「數字」:追蹤每一次 LLM 呼叫、持久化每一次評估、即時評每一個答案——讓優化變成可被驗證的循環。 一、為什麼可觀測性是 RAG 的最後一哩 第一篇解決切塊與檢索品質,第二篇補上 production 防線。但還缺一塊:你怎麼知道這些優化真的有效? RAG 的恐怖之處在於它「永遠會給出一個看起來合理的答案」。沒有量測,你根本分不清: 調了 hybrid_alpha,到底是變好還是變壞? 某個答案是基於檢索內容,還是 LLM 自己編的(hallucination)? 這次改動,整體 nDCG@k 的趨勢是上升還是下降? PR #4 補上三層可觀測性: ┌──────────────────────────────────────────────────────┐ │ 三層可觀測性 │ ├──────────────────────────────────────────────────────┤ │ 1. 即時聊天 每個回答附信心分數(faithfulness 等) │ │ 2. 評估工具 每次評估的彙總指標持久化,追蹤趨勢 │ │ 3. Langfuse 所有 LLM 呼叫被追蹤(延遲/token/成本) │ │ ── 設定才開,不設定零開銷 │ └──────────────────────────────────────────────────────┘ 二、Langfuse 追蹤:opt-in 且零開銷 設計原則:不設定 = 完全無感 可觀測性工具最怕的就是「為了觀測而拖慢主流程」。chatPDF 的 Langfuse 整合是完全 opt-in:沒設定環境變數時,它是一個 no-op,零開銷、零風險。https://yennj12.js.org/yennj12_blog_V4/posts/chatpdf-rag-optimization-part2-backend-hardening-zh/Tue, 30 Jun 2026 10:30:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/chatpdf-rag-optimization-part2-backend-hardening-zh/多數 RAG 專案的生命週期:demo 驚艷 → 上線 → 第一個惡意上傳把記憶體吃爆 → 第一個含程式碼的 PDF 讓檢索掛掉 → 緊急修補。 這篇講的就是「在出事之前」把那些防線一次補齊。 核心不是新功能,而是把每一個「會出事的環節」都加上邊界、退路、與防呆。 一、為什麼 demo 跟 production 是兩回事 上一篇解決了 RAG 的品質核心:切塊與檢索。但品質好不等於能上線。PR #2 的主題是 hardening(強化)——把這套系統從「在我電腦上能跑」推到「面對真實使用者、惡意輸入、長時間運行都不會倒」。 它涵蓋兩條主線: ┌─────────────────────────────────────────────────────┐ │ 後端強化(165 測試,+30 新增) │ │ ├─ 安全:上傳驗證、輸入邊界、刪除順序、錯誤訊息淨化 │ │ ├─ 資源:檔案大小限制、BM25 LRU 快取、歷史視窗 │ │ └─ 進階 RAG:多查詢擴展、檢索評分、頁碼引用、去重 │ ├─────────────────────────────────────────────────────┤ │ 前端現代化(+10 Vitest 測試) │ │ ├─ 集中式 typed API client、Toast 通知 │ │ └─ 進階 RAG 設定面板、搜尋、暗色模式、匯出 │ └─────────────────────────────────────────────────────┘ 下面挑最有代表性的幾個防線拆解。https://yennj12.js.org/yennj12_blog_V4/posts/chatpdf-rag-optimization-part1-chunking-retrieval-zh/Tue, 30 Jun 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/chatpdf-rag-optimization-part1-chunking-retrieval-zh/多數 RAG 教學的做法：把文件每 1000 字切一刀，丟進向量資料庫，cosine 相似度 top-k 撈回來。 但實務上 80% 的爛答案，不是 LLM 不夠強，而是「切錯地方」或「撈錯段落」。 chatPDF 這次的優化，核心就兩件事：讓切塊跟著「語意」走，讓檢索同時懂「語意」和「字面」。 一、為什麼切塊與檢索是 RAG 的命門 一個 RAG 系統的流程很單純： PDF ──▶ 切塊(Chunking) ──▶ 向量化 ──▶ 檢索(Retrieval) ──▶ LLM 生成 ▲ ▲ │ │ 決定「知識的最小單位」 決定「撈回哪些單位」 LLM 生成是最後一步，但它能講什麼，完全取決於前面撈回了什麼。而撈回什麼，又取決於當初怎麼切。所以這條鏈裡，切塊與檢索才是真正的瓶頸——它們決定了 LLM 能「看到」的內容。 chatPDF 原本的問題很典型： 切塊是寫死的:不管 RAGConfig 設定什麼,都用固定字數硬切。一個句子、一張表、一段論證,常常被攔腰切斷。 檢索只有 dense 一種:純向量相似度。遇到「精確關鍵字」(產品型號、縮寫、法條編號)時,語意向量反而抓不準。 PR #1 就是針對這兩點:Semantic Chunking 與 Hybrid Retrieval。 二、固定切塊的問題:把意思切碎了 固定切塊(fixed-size chunking)是這樣的: 原文: "本季營收成長 18%。主因是雲端業務擴張。│ 另一方面,匯率造成 切在這 ▲ 3% 的逆風。展望下季,管理層預期..." 問題在於:它在「字數到了」就切,完全不管那裡是不是一個語意邊界。結果常常: 把一個完整論點切成兩半 → 兩個 chunk 都殘缺,檢索時誰都撈不全 把兩個無關主題塞進同一塊 → 向量被「平均」掉,語意模糊 固定切塊的失敗模式 ────────────────────────────────── chunk A: ".https://yennj12.js.org/yennj12_blog_V4/posts/langgraph-langchain-intro-zh/Sat, 11 Apr 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/langgraph-langchain-intro-zh/全面介紹 LangChain 和 LangGraph 的核心概念、架構和實戰應用，涵蓋從簡單的 Chain 到複雜的多 Agent 工作流，幫助開發者快速掌握現代 AI 應用開發框架。https://yennj12.js.org/yennj12_blog_V4/posts/prompt-caching-practical-guide-rag-vector-db-zh/Thu, 12 Mar 2026 14:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/prompt-caching-practical-guide-rag-vector-db-zh/多 Agent Token 優化系列 pt.2：深入探索 Prompt Caching 的實際應用，從 Claude API 原生快取、應用層記憶體快取、到 RAG 系統整合，提供完整程式碼範例，幫助你打造高效低成本的 AI 應用。