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

你寫了一篇技術含量很高的文章，裡面提到的產品型號、API 名稱、錯誤代碼一字不差，結果讀者在 ChatGPT 或 Perplexity 問問題時，AI 引用的卻是另一篇講得更攏統、但剛好命中關鍵字的內容。這種「我明明寫得更專業，卻沒被選上」的挫折，背後經常是一個你沒聽過、卻在決定生死的東西：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」這幾個字；你查「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」第一次，BM25 會給你不少分數；提到第二次，再加一點；提到第十次、第二十次，幾乎不再加分了。這叫「飽和」。它對應到一個叫做 k1 的參數，控制著飽和發生的速度。k1 越大，重複出現的邊際加分越多、飽和越慢；k1 越小，飽和越快，重複很快就不值錢。

這個設計直接打臉了一種老派的 SEO 直覺：「關鍵字塞越多遍越好」。在 BM25 的世界裡，重複堆砌關鍵字從某個次數之後，分數幾乎不再成長，你只是在浪費字數、還把文章讀感搞砸。這也是為什麼黑帽的關鍵字堆砌手法在現代搜尋系統裡早就失效，它們連第一關的檢索分數都騙不到。

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

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

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

這對內容創作者是很重要的訊號：你用的詞越精確、越有指名度，越容易被 BM25 認定為「高鑑別力詞彙」而拉高整體分數。你寫「我們提供一套很好用的後端快取方案」，跟寫「我們用 Redis Cluster 解決了高併發下的快取一致性問題」，後者因為帶了具體、稀有、有指名度的詞，在 BM25 眼裡價值高得多。這不是要你堆專有名詞，而是要你「把話講精確」。

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

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

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

翻成內容面的白話：一份又臭又長、為了湊字數而灌水的文章，會被 BM25 的長度懲罰往下拉。一份緊湊、密度高、每一句都跟主題相關的文章，反而佔優勢。這跟我常講的一個原則完全一致：寫五千字每一句都有料，比寫八千字空洞的長文好太多了。BM25 的數學，其實就是在懲罰後者。

把這三部分擺在一起看，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 一定勝出。

這個例子要傳達的不是精確數字，而是一個觀念：在 BM25 的世界裡，「短而精準」跟「長而全面」從來不是等價的，密度會被獎勵，虛胖會被懲罰。你回頭看自己網站上那些為了衝字數而灌水的長文，就知道它們在這套評分裡處於什麼位置了。

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

BM25 跟 TF-IDF 差在哪裡

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

兩者最大的差別，就一個字：飽和。TF-IDF 的詞頻是線性的，出現十次就是出現一次的十倍分量（在乘上 IDF 之後）；BM25 把這條線折彎了，讓它變成一條越爬越平的曲線。光這一個改動，就解決了 TF-IDF 最被詬病的問題：鼓勵關鍵字堆砌。

比較維度	TF-IDF	BM25
詞頻處理	線性，出現越多分數越高	飽和曲線，重複的邊際效益遞減
文件長度	不考慮	有長度懲罰，受 b 參數控制
可調旋鈕	幾乎沒有	k1 與 b 兩個參數可調
抗關鍵字堆砌	弱，容易被灌水騙分	強，重複很快就飽和
典型用途	特徵抽取、粗略排序、機器學習前置處理	搜尋引擎排序、RAG 的檢索階段

BM25 多出來的那兩個旋鈕（k1、b）非常實用。實務上工程師可以根據不同語料庫的特性去微調它們：一個全是短推文的資料庫，跟一個全是長篇技術文件的知識庫，最適合的 k1 跟 b 不會一樣。這種「可調」的彈性，是 TF-IDF 完全沒有的，也是 BM25 三十年來還沒被淘汰的原因之一。幫你建立一點直覺：

參數	控制的是	調大會怎樣	調小會怎樣
k1	詞頻飽和的速度	重複出現的加分變多，飽和變慢	重複很快就不值錢，飽和變快
b	文件長度懲罰的強度	長文件被壓得更兇	長度影響變小，幾乎不懲罰長文件

這張表你不用背，但有個情境感很值得記：當你的語料庫裡文件長度差異很大（例如同時有兩百字的短筆記跟一萬字的長報告），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 是他們最常用的那一支準尺。

把這段記下來：在 AI 搜尋的鏈路上，你的對手不是旁邊那篇文章，而是「有沒有擠進上下文窗口」這條門檻。BM25 就是那條門檻的計分員。

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

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

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

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

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

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

這裡順帶補一個很實用的技術細節：兩邊的結果到底是怎麼融合的？最常見的做法叫 RRF（Reciprocal Rank Fusion，倒數排名融合）。它的邏輯很直觀：不管 BM25 跟向量各自給的分數尺度差多少，只看每份文件在兩邊的「排名」。一份文件如果在 BM25 排第三、在向量排第十，RRF 就把這兩個排名倒數相加，給它一個融合後的新分數。這種做法的好處是不用費心調兩套分數的權重，實作簡單，而且對「只有一邊選中、另一邊完全漏掉」的文件特別友善。對內容創作者來說，這意味著一個好消息：你不用在 BM25 跟向量兩邊都拿第一名，只要在其中一邊夠前面，就有機會靠融合擠進候選名單。重點是「至少被一邊看見」，而 BM25 那一邊，往往是精確查詢裡最容易被看見的。

這對內容創作者是很實際的啟示：你的內容會同時被 BM25 跟向量兩套系統檢視，你沒辦法只討好其中一邊。只討好語意、把所有專有名詞都改寫成攏統的白話，向量檢索也許還找得到你，但 BM25 會漏掉你；只討好字面、把關鍵字塞得死死的，BM25 選上你了，向量檢索可能覺得你語意發散而不推薦你。真正會被 AI 穩定引用的內容，是兩邊都照顧到的：用精確的詞、講清楚的事、同時維持通順可讀。

查詢類型	BM25 表現	向量檢索表現
精確錯誤代碼、產品型號	強，字面命中即高分	弱，容易回傳語意相近但無關的文件
同義詞、換句話說的問題	較弱，字面不同時可能漏掉	較強，能跨詞彙對齊語意
冷門、罕見專有名詞	強，IDF 給高分	不穩定，取決於該詞有沒有好的向量表示
開放式、概念性問題	普通，靠字面重疊	強，能抓到深層語意關聯

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

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

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

這對繁體中文內容創作者有一個很實際的啟示：當一個專有名詞是新詞、冷門詞，分詞器很可能不認得它，會把它硬拆成幾個沒意義的片段。你能做的補救，是在標題、小標這類關鍵位置，讓那個專有名詞以「完整、獨立、前後有標點或空格包夾」的形式出現，降低被誤切的機率。例如把「我們導入了RAG架構」寫成「我們導入了 RAG 架構」，前後留白，分詞器就更可能把 RAG 當成一個獨立詞來處理，BM25 也才有機會算到完整的命中。

再往深一層想，繁體中文還有一個分詞器選擇的問題。多數開源分詞工具是簡體中文優先的，套到繁中內容上，常會把詞的邊界切錯，例如把一個台灣慣用的複合詞硬拆成兩半。這會讓你以為寫到了的詞，BM25 根本沒算到。如果你在建自己的 RAG 或站內搜尋，值得花一點力氣確認分詞器對你的繁中詞庫友善，必要時自建詞典把核心術語固定下來；如果你只是內容創作者、沒有控制系統的能力，那退一步，把核心術語寫得前後留白、獨立成詞，至少能降低被誤切的風險。這條路很瑣碎，但在中文的 AI 搜尋賽局裡，它往往是決定你能不能被精準召回的隱形分水嶺。

讓 BM25 選上你的五個內容動作

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

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

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

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

常見誤解	BM25 眼中的實際情況
關鍵字出現越多遍，分數越高	詞頻飽和後，第十次出現幾乎不加分，重複只浪費篇幅
文章越長、資訊越多，越容易被選中	長度懲罰會把明顯超過平均長度的文件分數往下壓
把專有名詞全換成白話同義詞，讀起來更友善	BM25 是字面比對，同義詞不算命中，精確查詢會直接漏掉你
所有 RAG 都是固定的混搭檢索	有些系統混合稀疏與向量檢索，有些只用其中一種，必須依實作與評測判斷

第一個習慣是關鍵字堆砌。這在 BM25 飽和曲線下完全無效，還會被長度懲罰進一步連累：你多塞了一堆重複的字，把文章拉長了，飽和沒賺到分，長度懲罰倒先扣了一筆。等於賠了夫人又折兵。那些教人「關鍵字密度要衝到幾％」的過時建議，在 BM25 的數學面前是反向操作。

第二個習慣是「為了 SEO 把文章灌長」。這幾年很流行一種說法，認為長文等於權威、等於好排名。在 BM25 的數學裡，這個直覺是錯的。長度本身不加分，超過平均反而扣分。真正該追求的是「資訊密度」：同樣的主題，你能不能用更少的字講得更清楚。如果你的文章有三分之一是在重複同一個論點、換句話說，又說一遍，那段內容在 BM25 眼裡是負資產。

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

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

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

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

1. 挑出一篇主力文章，圈出裡面所有「精確名詞」。產品名、技術名、規格、錯誤代碼、人物、地點都算。確認這些詞是用「讀者會查的那個原始寫法」出現，避免被改寫成同義詞。被改寫掉的，挑幾個關鍵的改回來。
2. 刪掉重複的論述。找出文章裡「同一段話換三種方式講」的地方，挑講得最好的一版留下來，其餘刪掉。這一步同時改善了 BM25 的長度懲罰與讀者的閱讀體驗，一石二鳥。
3. 檢查標題層級。確認每一個 H2、H3 都對應一個清楚的主題，段落之間有明確的邏輯順序。這在文件被切塊餵給 LLM 時特別重要，結構越清楚，切出來的素材品質越高。
4. 補一篇針對精確長尾詞的內容。從你的領域裡找一個夠具體、目前沒有專門文章回答的長尾問題，寫一篇深度回答。讓 BM25 在那個稀有的高鑑別力查詢上，把你選進候選名單。

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

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

把 BM25 搞懂，等於在這場「被選中」的競賽裡，先幫自己拿到一張入場券。接下來，就看你內容本身的真本事了。如果你想知道 AI 引用內容時，除了檢索還看哪些訊號，可以延伸讀Grounding 介紹跟AI 搜尋引擎這兩篇，把整張地圖補齊。願你成為那個被 AI 穩定選上的答案。