BM25 是什麼？檢索排序如何決定 AI 引用的內容

精確的產品型號、API 名稱與錯誤代碼，對字詞檢索很有用。BM25 是理解這類檢索的一個起點；但某篇文章沒有被 ChatGPT 或 Perplexity 引用，不能只憑結果就認定是 BM25 分數不足。

BM25（Best Matching 25，文獻上常寫作 Okapi BM25）是一套用來幫文件「打分數」的檢索排序函數。給定一組查詢詞，它會估算每份文件與查詢的字面相關性，再把高分文件排在前面。Lucene、OpenSearch 等搜尋基礎設施會使用 BM25；採用 BM25 或混合檢索的 RAG（檢索增強生成）系統，也可能用它挑選要放進 LLM 上下文（context window）的素材。這不代表 Google 搜尋或每一套 RAG 都使用同一套 BM25 設定。

在使用 BM25 的檢索流程裡，它可以是挑選候選素材的一道關卡；若系統還有向量檢索、重排序器或其他資料來源，最終候選名單會由多個環節共同決定。Ahrefs 在〈96.55% of Content Gets No Traffic From Google. Here's How to Be in the Other 3.45% [New Research for 2023]〉這份大規模研究中指出，超過 96% 的網頁未從 Google 取得估計自然搜尋流量。這份研究描述的是 Google 自然搜尋資料，不能直接推論 AI 搜尋的引用比例。

這一篇我要把 BM25 講到你能用、能教別人、能回頭檢查自己網站內容的程度。我不會塞一堆你看不懂的數學符號，但會把那些直接影響你內容能不能被選中的關鍵變數，一個一個翻成白話。

快速重點整理：BM25 以詞頻飽和、詞的稀有度與文件長度正規化計分。在採用 BM25 的 RAG 檢索鏈裡，它會影響哪些內容進入候選集合。精確術語與聚焦內容有助於字面檢索；標題層級主要改善閱讀與切塊品質，不是標準 BM25 的直接計分欄位。

BM25 到底在做哪一件事

BM25 根據查詢詞項與文件的匹配情況計算相關性分數。分詞與字詞正規化通常由分析器先處理，BM25 再參與候選排序；文件是否保留，仍取決於查詢條件與其他檢索流程，並非看到零分就能概括所有系統的行為。

這裡有個觀念要先講清楚，因為它跟你想像中的「搜尋引擎」可能不一樣。BM25 不是一個「懂你意思」的系統，它是一個「比對字面」的系統。你查「BM25」，它就去文件裡找有沒有「BM25」這幾個字；你查「redis connection refused」，它就去找這幾個字。它不懂「redis 為什麼連線被拒」，它只負責把字面吻合的文件找出來，再依一些規則排序。

這聽起來很笨，對吧？正因為它「笨」，所以它快、它可解釋、它對精確名詞的命中率非常高。在動輒要檢索幾百萬份文件的場景裡，這種「笨但快」的特質非常有價值。你可以把它想成一個只認字的圖書館管理員：你報上書名，他立刻告訴你哪幾本書裡有這個書名、各出現了幾次、書有多厚。他不跟你聊內容，但他找書的速度和準度，往往比一個會聊天但動作慢的店員還實用。

那個「25」來自 Best Matching 系列的版本編號，是一個歷史標記。BM25 至今仍廣泛用於搜尋基礎設施；Lucene、Elasticsearch 與 OpenSearch 的預設相似度採用 BM25，其他產品或版本則應查看各自設定。

這裡要先劃清界線：Google 沒有公開說明目前的網頁搜尋排名直接採用標準 BM25；從公開資料看，Google 的排名疊了更多機器學習模型與 Navboost 這類使用者行為訊號。BM25 常見於 Lucene、OpenSearch 等搜尋基礎設施，也可用於企業知識庫、站內搜尋與 RAG 的稀疏檢索層，但不是所有 RAG 都會使用。若你能控制自己的檢索系統，BM25 設定與語料處理直接相關；若你在做一般網頁 SEO，就不能把 BM25 公式當成 Google 排名公式。

把 BM25 拆成三個看得懂的部分

可以從詞頻飽和、逆向文件頻率與長度正規化理解 BM25。多詞查詢通常加總各詞項的貢獻；它不是三個獨立「內容品質分數」簡單相乘，也不判斷敘述是否正確。

第一部分：詞頻的「飽和」

第一個部分處理的是「這個詞在這份文件裡出現了幾次」。直覺上，出現越多次應該越相關，對吧？BM25 也這樣認為，但它加了一個關鍵限制：邊際效益會遞減。

換個方式想：你在文章裡提到「BM25」第一次，BM25 會給你不少分數；提到第二次，再加一點；提到第十次、第二十次，幾乎不再加分了。這叫「飽和」。它對應到一個叫做 k1 的參數，控制著飽和發生的速度。k1 越大，重複出現的邊際加分越多、飽和越慢；k1 越小，飽和越快，重複很快就不值錢。

詞頻飽和表示重複命中的邊際貢獻會遞減，沒有固定「第十次之後完全不加分」的門檻，也不能據此說堆砌永遠無法提高檢索分數。寫作仍應以讀者需要為準；Google 的垃圾內容政策與 BM25 的數學性質是不同層次的規則。

第二部分：詞的「稀有度」（IDF）

第二個部分是 IDF（Inverse Document Frequency，逆向文件頻率）。它問的問題是：「這個詞有多稀有？」

一個詞如果出現在幾乎每一份文件裡，例如中文的「的」、「是」、「在」，那它就沒有鑑別力，看到它你完全無法判斷這份文件在講什麼，BM25 給它的分數就很低。反過來，一個詞如果只出現在極少數文件裡，例如某個冷門的 API 名稱、某個特定的錯誤代碼，它就很有鑑別力，BM25 會給它很高的分數。

只有查詢中被匹配的詞項，才會在相應 BM25 計分中產生貢獻。若讀者查 Redis Cluster，正確使用這個名稱能避免字面漏配；插入與查詢無關的冷門術語，不能因為稀有就提高該查詢的分數。

第三部分：文件長度正規化

第三個部分是文件長度正規化，它對應到 b 參數。BM25 會把每份文件的長度與語料庫平均長度一起納入計算，避免長文件只因為字多、較容易碰到查詢詞就取得不成比例的優勢。影響大小仍取決於 b、詞頻、查詢詞與語料分布，不能簡化成「長文一定被扣分、短文一定加分」。

這個設計的用意是抵消一種不公平：長文件光因為篇幅大，就更容易「湊到」各種詞，如果不做長度懲罰，它會在分數上佔便宜。BM25 不買這個帳。它的態度很明確：你的相關性要拿出來「單位長度」比，總量大並不能保證相關。

其他條件相同時，增加未匹配的內容可能透過長度正規化降低分數；若新增段落包含重要的查詢資訊，總體效果則未必相同。BM25 不認得「灌水」或「有料」，因此篇幅應由完成回答的需要決定。

這些計分因素可以幫工程師解釋特定查詢下的排序，但不能直接當成寫作品質量表。精確用詞與刪除重複內容有閱讀價值，是否改善檢索仍要用實際語料和查詢測試。

一個具體例子：BM25 怎麼把三份文件排出名次

講了三個零件，你可能還是覺得抽象。我換一個具體到你能動手驗證的小例子。假設你有一個只有三份文件的迷你語料庫，使用者查的是「Redis」這一個詞。

文件 A 是一篇專講 Redis 快取策略的技術文，長度中等，「Redis」這個詞出現了 2 次。文件 B 是一篇泛談各種資料庫的長文，篇幅明顯超過平均，「Redis」只出現了 1 次。文件 C 是一篇 Redis 連線除錯的短筆記，篇幅很短，「Redis」出現了 1 次。

先看 IDF。Redis 在 A、B、C 都出現，因此這個詞的 IDF 對三份文件相同；同一個詞在同一語料庫裡，不會因文件不同而改變 IDF。真正拉開差距的是詞頻與長度正規化。

再看詞頻飽和。A 出現了 2 次，B 跟 C 都只有 1 次。直覺上 A 應該贏，對吧？但因為飽和，A 第二次出現「Redis」只多帶來一點點分數，遠不到兩倍。所以 A 在詞頻上的領先，沒有你想像的那麼大。

長度正規化也會影響排序。B 是三者裡最長的，在其他條件相近時較難只靠一次命中取得優勢；A 有較高詞頻，C 則較短。實際排序仍取決於 k1、b、平均文件長度與分詞結果，不能只憑這段描述斷定 A 或 C 一定勝出。

這個例子顯示詞頻與長度會共同影響分數。它沒有提供足夠數值來確定三份文件的名次，也不能推出「短文一定勝過完整長文」；實作時應檢查分析器輸出的詞項與實際分數。

把這個例子再加一個變化：如果使用者查的不是單一個詞，而是「Redis 連線錯誤」這串多詞查詢呢？這時 BM25 會把每個詞各自的分數加總。文件 C 就算同時提到 Redis 跟連線，但若完全沒出現「錯誤」這個字，它在「錯誤」這個詞項上就是零分；反過來，如果有一份文件三個詞都提到了，就算每一個只出現一次，加總起來也很可能勝出。這就是為什麼「把你回答的問題裡每個關鍵詞都實際寫出來」這件事，在 BM25 的數學裡有直接的回報：每一個命中的詞項都是真金白銀的分數。那些喜歡用代名詞、把核心詞省略掉的寫法，等於在 BM25 面前主動放棄分數。

BM25 跟 TF-IDF 差在哪裡

講到 BM25 就一定會提到 TF-IDF，因為 BM25 基本上是 TF-IDF 的「進化版」。如果你對 TF-IDF 還不熟，可以先去看我之前寫的TF-IDF 介紹，把「詞頻」跟「逆向文件頻率」這兩個地基觀念先打好，再回來這裡會輕鬆很多。

TF-IDF 有多種定義與實作，詞頻不一定線性，也可以包含長度或向量正規化。例如 Lucene ClassicSimilarity 使用平方根詞頻與長度正規化。BM25 的特色是以可調的飽和及長度正規化項處理匹配，不能把所有 TF-IDF 都描述成「出現十次就給十倍」。

k1 與 b 能調整飽和和長度正規化，適合用代表性查詢與相關性標註來評估。不同語料可能需要不同設定，但不能預設一定要偏離預設值；TF-IDF 系統也有可選的加權與正規化方式。

這張表你不用背，但有個情境感很值得記：當你的語料庫裡文件長度差異很大（例如同時有兩百字的短筆記跟一萬字的長報告），b 的設定就特別敏感，設錯了會系統性地偏好某一種長度。當你的內容主題高度重複（例如一堆都在講同一個產品），k1 的設定會決定「多提幾次」到底還有沒有用。這也是為什麼拿別人現成的 RAG 配方直接套用，常常效果不如預期：你的語料特性跟人家的不一樣，最適合的旋鈕位置就不會一樣。

不同 BM25 實作的 IDF 公式可能略有差異。以 Lucene 的 BM25Similarity 為例，常見詞的權重會趨近低值，但其公式不會因此給出負 IDF。對內容創作者來說，重點仍是：常見詞鑑別力低，精確術語在字面檢索中通常更有辨識度。

在 RAG 鏈裡，BM25 是那個守門人

現在進到這篇真正要回答的問題：BM25 怎麼決定你餵給 LLM 的素材？答案藏在 RAG 這套架構裡。如果你還不熟悉 RAG，可以先讀這篇RAG 介紹，把整體流程看過一次。

RAG 的運作可以拆成三步。第一步是檢索（retrieval）：系統拿使用者的問題，去你的文件庫裡找出最相關的幾份內容。第二步是組裝：把這幾份內容塞進 LLM 的上下文窗口。第三步是生成：LLM 根據這些素材，組出一段回答。

如果這套 RAG 使用 BM25，它會在第一步參與候選文件排序。沒有進入生成上下文的內容，這次通常不會直接使用；但候選集合還可能經過向量檢索、過濾、融合與重排序，因此 BM25 分數不是唯一門檻。這跟傳統 SEO 的公開網頁排名也不是同一套問題。

也因此，我會把「檢索」這個環節獨立拉出來看。可把候選檢索理解為索引之後、精細重排序之前的一個環節；檢索本身也可能包含排序，我在另一篇檢索介紹裡有更完整的說明。你一旦理解「檢索決定素材、素材決定回答品質」，就會開始用一個全新的角度看自己的內容：它能不能被檢索到，比它寫得多漂亮更重要。

BM25 在這條鏈裡的影響力，還會被兩個現實條件放大。第一是上下文窗口的長度限制。LLM 能裝進去的素材是有限的，這跟Token 的計算直接相關，每塞一份文件就吃掉一部分額度。所以檢索階段的重點是「精準挑」，通通塞進去只會壞事。BM25 可以是候選檢索方法之一。第二是成本。每多塞一份不相關的文件進去，不只浪費 token、浪費錢，還會稀釋 LLM 對真正相關素材的注意力，讓回答品質變差。所以從系統設計的角度，工程師有很強的動機把檢索調得很準，而選用哪種檢索方法，需要比較相關性、延遲與成本。

若回答需要外部資料，候選檢索會影響模型可用的素材；BM25 只是其中一種方法。素材被取回也不保證出現在最後答案或附帶引用連結。

還有一個常被看漏的細節：切塊（chunking）。不少 RAG 會先把長文件切成多個區塊，再以區塊為單位檢索；也有系統使用整份文件、階層式索引或其他策略。切塊後，長度比較的單位與平均值也會改變，不能說短區塊就一定不受正規化影響。段落與小標若主題清楚，通常較有利於切出保有上下文的區塊，但具體效果仍需用實際查詢集測試。

為什麼向量檢索沒有把 BM25 淘汰

這幾年向量檢索（dense retrieval、embedding 檢索）很紅，很多人以為它會把 BM25 這種「老派字面比對」整個淘汰掉。事實並沒有。這裡有一個常見的誤區值得指出。

很多軟體公司跟 SaaS 工具在建置站內搜尋時，第一版幾乎都直覺上只用向量檢索，結果上線才發現：使用者查一個精確的產品型號、API 名稱或錯誤代碼，那種字面一個字都不能差的詞，向量反而召回不回來。系統回傳的是「語意相近」但根本沒提到那個代碼的文件，使用者點進去發現文不對題，跳出率當場飆高。

這不是向量檢索爛，是它跟 BM25 擅長的本來就不一樣。向量檢索強在「語意相近」，它能把「資料庫連不上」跟「DB connection failed」當成同一件事；但它弱在「精確命中」，遇到代碼、編號、專有名詞這種一字都不能差的東西，它反而會因為「語意太近」而把不相關的東西排前面。BM25 剛好相反，它強在精確命中、弱在語意聯想。

許多正式上線的 RAG 會採用混合檢索：同時跑 BM25 等稀疏檢索與向量檢索，再融合兩邊結果，以兼顧字面命中與語意相近。但這不是所有系統的固定架構；是否需要 BM25，要看查詢是否包含型號、代碼、專有名詞，以及實際評測結果。

融合字詞與向量結果時，可以使用 RRF。它加總文件在各結果清單中的 1 / (k + rank)，其中 k 是排名常數，並不是直接把名次倒數相加。RRF 避開原始分數尺度不同的問題，但候選窗口、常數與後續重排序仍會影響結果，也可採用其他融合方法。

對未知實作的公共搜尋服務，無法確定每篇內容是否同時經過 BM25 和向量檢索，更不能保證兼顧兩者就會穩定被引用。內容作者能做的是保留必要術語、把條件與答案寫清楚；自建系統則可直接評測不同檢索與融合方案。

中文的 BM25 多了一道關卡：分詞

中文 BM25 有一道特別關鍵的前處理：分詞（tokenization）。BM25 本身接收的是詞項，不規定只能處理以空格分詞的語言；真正影響結果的是分析器如何把「redis連線被拒」切成「redis」「連線」「被拒」或其他組合。

在中文場景裡，BM25 上場之前，系統會先用一套分詞工具（例如 jieba 或各廠商自建的詞庫）把整段文字切成詞。切得好不好，直接決定 BM25 的計分品質。同一句「大型語言模型」，切成「大型／語言／模型」跟切成「大型語言模型」一整個詞，會算出完全不同的詞頻與 IDF。如果你的核心術語剛好被分詞器拆散了，BM25 就算想給你高分也找不到完整的命中。

英文縮寫周圍適度留白有助閱讀，但不保證任何分析器都會產生同樣詞項。若能控制系統，應用分析器測試 API 檢查查詢與文件的實際切詞，再調整字典、同義詞或正規化；只寫網頁內容時，不宜為猜測分詞器而犧牲自然語句。

繁體中文應以自己的術語與查詢測試分詞結果，不宜假定所有開源工具都只適合簡體。索引與查詢使用的分析方式也可能不同；同義詞展開能在 BM25 計分前建立額外匹配，所以「字面不同必然完全找不到」只適用於沒有相應前處理的情境。

適合字詞檢索的五個內容整理動作

觀念講完了，接下來換你能動手做的事。接下來這五個動作，都是從 BM25 的數學行為直接反推回來的內容策略，不是空話。

1. 用讀者真正會查的詞，別用你覺得漂亮的詞。BM25 是字面比對，你寫「Redis」，它就找「Redis」；你改寫成「記憶體資料庫」，它就只找「記憶體資料庫」，若分析器沒有做同義詞展開，兩者可能不會互通。在你的領域裡，那些精確的產品名、技術名、錯誤代碼、規格編號，就是讀者會打進搜尋框的字，也是 BM25 給高分的高鑑別力詞。把它們寫出來，不要過度改寫成同義詞。
2. 把核心詞放進能描述內容的位置。標準 BM25 不看詞的位置；若系統採欄位式索引，工程師可以提高標題欄位權重。對內容作者而言，讓標題與首段清楚說明主題，主要價值仍是幫助讀者與切塊後的上下文辨識。
3. 刪掉灌水，保留完成回答所需的篇幅。BM25 會做長度正規化，但不能據此訂出固定字數或要求一律拆文。該拆成多篇、保留長文或改成主題區塊，應看搜尋意圖、內容邊界與實際檢索測試。可搭配資訊增益檢查重複論述。
4. 建立清晰的標題層級與段落結構。在 RAG 場景裡，文件常被切成一塊一塊（chunk）再餵給 LLM。你的 H2、H3、條列如果層級清楚，切出來的每一塊才會帶著足夠的上下文與關鍵詞，不會變成斷頭斷尾的碎片。結構有助保留語境，但是否改善檢索品質仍取決於切塊器與實際評測。
5. 為具體問題寫聚焦內容。BM25 的 IDF 作用在語料中的詞項，不等於「長尾查詢必然高分」。針對具體問題提供完整回答，並使用讀者會查的精確詞，才可能提高該查詢下的字面相關性。

四個會害你被 BM25 扣分的習慣

知道該做什麼之後，也得知道什麼會扯後腿。接下來四個習慣，是很多內容團隊反覆犯、而且自己完全沒意識到的地雷。

第一個習慣是堆砌關鍵字。詞頻飽和不表示重複絕對無效或必然扣分；它表示增益受限，還要與長度及其他因素一起看。沒有適用所有語料的最佳關鍵字密度，對公開網頁而言也不應把公式當成操縱排名的方法。

第二個習慣是為了湊篇幅重複論點。刪掉重複內容可改善閱讀，但不能宣稱所有超過平均長度的文件都較差；長度正規化只是相關性計算的一部分，完整回答所需的資訊仍應保留。

第三個習慣是最隱晦的：過度改寫專有名詞。有些內容處理者為了「行文流暢」，會把所有英文術語都翻成中文、把產品名都換成泛稱。出發點是好的，但代價是 BM25 抓不到你。讀者查「Kafka consumer group」，你寫的是「訊息佇列的消費群組」，兩者在向量空間裡也許很近，但在 BM25 的字面比對裡是完全不同的字串，在未做同義詞或查詢展開的純字面檢索中，可能因此漏配。我的做法是：專有名詞第一次出現時中英並列，之後保留原文或最通用的寫法，讓字面、語意兩邊都對得上。

第四個習慣，是把 BM25 與向量檢索當成二選一。字詞檢索較容易保留專有名詞與精確查詢，向量檢索則能補足同義表達與語意相近的內容；實務系統常把兩者組成混合檢索。內容端不需要猜測特定模型的分數，只要保留必要術語、避免關鍵字堆疊，並把問題、條件與限制寫清楚。

收尾：一份你能今天就開始的清單

我把整篇濃縮成四個你可以今天就動手的步驟。不需要任何工具，只要打開你自己流量最高、或你最在乎的那篇內容，照著走一遍。

1. 挑出一篇主力文章，圈出裡面所有「精確名詞」。產品名、技術名、規格、錯誤代碼、人物、地點都算。確認這些詞是用「讀者會查的那個原始寫法」出現，避免被改寫成同義詞。被改寫掉的，挑幾個關鍵的改回來。
2. 刪掉重複的論述。找出文章裡「同一段話換三種方式講」的地方，挑講得最好的一版留下來，其餘刪掉。這能改善閱讀；對 BM25 分數的影響還要看被刪內容是否包含查詢詞項。
3. 檢查標題層級。確認每一個 H2、H3 都對應一個清楚的主題，段落之間有明確的邏輯順序。這在文件被切塊餵給 LLM 時特別重要，結構越清楚，切出來的素材品質越高。
4. 補一篇針對精確長尾詞的內容。從你的領域裡找一個夠具體、目前沒有專門文章回答的長尾問題，寫一篇深度回答。保留必要術語與適用條件，增加字面匹配的機會；是否進入候選仍由系統決定。

BM25 不是新潮的 AI 黑科技，而是一套成熟、可解釋的字面檢索方法。當你建置或分析一套採用 BM25 的搜尋、知識庫或 RAG 系統時，理解它能幫你改善分詞、欄位權重與候選召回；對未知實作的公共 AI 搜尋，則不能假設引用結果由 BM25 分數決定。

Backlinko 分析超過四百萬筆 Google 搜尋結果的研究（2025 年 4 月）發現，排名第一的結果能拿下將近三成的點擊，排名越往後點擊率下滑得越快，到了第二頁幾乎無人聞問。在傳統搜尋裡，排名落差直接換算成流量落差。在 AI 搜尋裡，落差更早就開始了：在檢索這一關被刷掉，你連被引用的入場券都拿不到。

理解 BM25 有助於檢查採用字詞檢索的系統如何處理術語、分詞與候選結果；對未知實作的公共 AI 搜尋，無法保證內容因此被引用。如果想延伸認識 AI 答案與來源的關係，可以讀〈Grounding 介紹〉與〈AI 搜尋引擎〉。