https://yennj12.js.org/yennj12_blog_V4/tags/embedding/Recent content in Embedding on YennJ12 Engineering BlogHugo -- gohugo.ioen-usTue, 30 Jun 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part3-ml-fundamentals-zh/Sat, 30 May 2026 11:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part3-ml-fundamentals-zh/有人覺得 FDE 只需要會包 API。 這個判斷在面試中會死得很難看。 基礎不紮實，一旦系統出問題，你沒有能力診斷。 閱讀建議： 這篇是 ML 基礎概要。想要更完整的深度版本，參考 第八篇（ML 完整版） 和 第九篇（LLM 核心）。 面試情境 面試官：「解釋一下 Transformer 的 Self-Attention 機制。然後告訴我：Fine-tuning 和 RAG 在你的客戶場景下你怎麼選？如果 Fine-tuning 出現 Overfitting，你怎麼偵測？」 ML 基礎題通常是「過濾用的」——答不出來直接扣分，答得好不會讓你脫穎而出。但這些概念在實際工作中真的有用。 一、Transformer 架構：面試要說清楚的程度 Self-Attention 的核心機制 傳統 RNN 的問題：句子越長，開頭的資訊到句尾就已經被稀釋了，遠距離依賴很難學。 Self-Attention 的解法：每個 token 直接和所有其他 token 計算相關性，不管距離。 句子：「這家公司的 CEO 昨天宣布了一項重大決策」 Self-Attention 讓「決策」直接「看到」「CEO」， 不需要一步步從前面傳遞資訊。 數學直觀（面試可能問到 Q/K/V 的意思）： Q（Query）：這個 token 在「問」什麼資訊？ K（Key）： 其他 token「能提供」什麼資訊？ V（Value）：實際要「傳遞」的內容是什麼？ 計算流程： Q × Kᵀ（相關性分數）→ Softmax（變成機率分布）→ × V（加權求和） 不需要手推公式，但要知道： └── √d_k 是縮放因子，避免點積值過大導致梯度消失 Positional Encoding：為什麼要加位置資訊 Self-Attention 本身沒有位置概念。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/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/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: ".