https://yennj12.js.org/yennj12_blog_V4/tags/hybrid-search/Recent content in Hybrid Search on YennJ12 Engineering BlogHugo -- gohugo.ioen-usSun, 31 May 2026 09:00:00 +0800https://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/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、llmsherpa