https://yennj12.js.org/yennj12_blog_V4/tags/bm25/Recent content in BM25 on YennJ12 Engineering BlogHugo -- gohugo.ioen-usTue, 30 Jun 2026 10: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-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/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: ".