【Elasticsearch】TF-IDF 和 BM25相似性算法

在 Elasticsearch 中,TF-IDF 和 BM25 是兩種常用的文本相似性評分算法,但它們的實現和應用場景有所不同。以下是對這兩種算法的對比以及在 Elasticsearch 中的使用情況:

?

TF-IDF

- 定義與原理:TF-IDF 是一種經典的信息檢索算法,用于評估一個詞語對于一個文件集或語料庫中某份文件的重要程度。它由兩部分組成:

? - TF(Term Frequency):詞頻,即詞語在文檔中出現的次數。

? - IDF(Inverse Document Frequency):逆文檔頻率,用于衡量詞語的普遍重要性。

- 優點:

? - 簡單高效,計算速度快。

? - 適用于短文本和長查詢。

- 缺點:

? - 不考慮文檔長度和查詢長度的影響,可能導致長文檔評分偏低。

? - 對高頻詞過度強調,容易受拼寫錯誤或罕見詞干擾。

? - 忽視語義,將文檔視為詞袋模型,忽略詞序。

?

BM25

- 定義與原理:BM2 是5對 TF-IDF 的改進,引入了更多因素,如文檔長度歸一化和詞頻飽和度處理。它通過調整參數 `k1` 和 `b` 來優化評分。

- 優點:

? - 更靈活地處理長文本和短文本,避免長文檔得分偏高。

? - 對詞頻的飽和度進行了優化,避免高頻詞過度影響評分。

? - 提供了更好的排名效果,特別是在大規模文檔集合中。

? - 參數可調節,能夠適應不同的信息檢索場景。

- 缺點:

? - 計算復雜度略高于 TF-IDF。

? - 在某些情況下,可能需要調整參數以獲得最佳效果。

?

Elasticsearch 中的使用

- 默認算法:Elasticsearch 5.0 之后,默認使用 BM25 作為相似度評分算法。這是因為 BM25 在處理長文檔和短查詢時表現更好,能夠提供更準確的搜索結果。

- 自定義配置:雖然 BM25 是默認算法,但 Elasticsearch 也支持自定義相似度算法。如果需要使用 TF-IDF,可以通過腳本自定義實現。

?

選擇建議

- 如果你的應用場景對文檔長度敏感,或者需要更靈活的評分調整,建議使用 BM25。

- 如果你的文檔集合較小,或者對性能要求極高且對文檔長度不敏感,可以考慮使用 TF-IDF。

?

總結來說,BM25 是 Elasticsearch 的默認選擇,因為它在大多數場景下都能提供更好的搜索結果。但在特定情況下,根據實際需求選擇合適的算法是關鍵。

在信息檢索和搜索引擎中,文檔長度和查詢長度對搜索結果的評分有很大影響。如果不考慮這些因素,可能會導致評分不準確,尤其是對于長文檔。以下是對這句話的詳細解釋:

?

1. 文檔長度的影響

文檔長度指的是文檔中包含的詞(或字符)的數量。在文本檢索中,文檔長度會影響其查詢與的相關性評分,原因如下:

?

問題:長文檔可能包含更多關鍵詞

- 背景:假設有一個查詢詞 `apple`,一個長文檔可能包含多個 `apple`,而一個短文檔可能只包含一個 `apple`。

- 問題:如果僅根據詞頻(TF)來評分,長文檔的得分可能會更高,即使它與查詢的實際相關性并不高。

- 例子:

? 文 -檔 A:包含 1000 個詞,其中 `apple` 出現了 10 次。

? - 文檔 B:包含 100 個詞,其中 `apple` 出現了 1 次。

? - 如果僅用詞頻(TF)評分,文檔 A 的得分會更高,但文檔 B 可能更相關。

?

解決方案:文檔長度歸一化

- TF-IDF 和 BM25 的處理方式:

? - TF-IDF:通過逆文檔頻率(IDF)來降低常見詞的權重,但仍然可能受到文檔長度的影響。

? - BM25:引入了文檔長度歸一化(Normalization),通過參數 `b` 來調整文檔長度對評分的影響。長文檔的評分會被適當降低,以避免僅因文檔而長得分過高。

?

BM25 的文檔長度歸一化公式

BM25 的文檔長度歸一化部分可以表示為:

\[ \text{norm} = \frac{1}{1 + b \times \left( \frac{\text{doc.length}}{\text{avg.doc.length}} \right)} \]

- `doc.length` 是當前文檔的長度。

- `avg.doc.length` 是所有文檔的平均長度。

- `b` 是一個可調節參數(通常在 0 到 1 之間),用于控制文檔長度對評分的影響。

?

2. 查詢長度的影響

查詢長度指的是查詢中包含的詞的數量。查詢長度也會影響評分,原因如下:

?

問題:長查詢可能包含多個關鍵詞

- 背景:假設查詢是 `apple banana`,一個文檔可能只包含 `apple`,而另一個文檔同時包含 `apple` 和 `banana`。

- 問題:如果僅根據單個詞的匹配來評分,可能會忽略文檔與查詢的整體相關性。

- 例子:

? - 文檔 A:包含 `apple`,但不包含 `banana`。

? - 文檔 B:同時包含 `apple` 和 `banana`。

? - 如果僅用單個詞的匹配來評分,文檔 A 可能會得到較高的評分,而文檔 B 實際上更相關。

?

解決方案:查詢長度歸一化

- BM25 的處理方式:BM25 在計算評分時會考慮查詢長度,通過詞頻飽和度(Saturation)來調整評分。即使文檔中某個詞的頻率很高,其對評分的貢獻也會逐漸飽和,避免因單個詞的高頻率而導致評分過高。

- 詞頻飽和度公式:

\[ \text{tf} = \frac{K + 1}{K + \text{term.freq}} \]

- `term.freq` 是詞在文檔中的頻率。

- `K` 是一個與 `k1` 和文檔長度歸一化相關的參數。

?

3. 總結:為什么長文檔評分可能偏低

如果不考慮文檔長度和查詢長度的影響,可能會導致以下問題:

- 長文檔評分偏高:因為長文檔可能包含更多的關鍵詞,僅根據詞頻(TF)來評分會導致長文檔得分過高。

- 短文檔評分偏低:即使短文檔與查詢的相關性很高,也可能因為詞頻較低而得分較低。

?

BM25 的優勢:

- BM25 通過文檔長度歸一化和詞頻飽和度處理,避免了長文檔僅因長度而得分過高,同時考慮了查詢長度對評分的影響,能夠更準確地評估文檔與查詢的相關性。

?

4. 實例對比

假設我們有兩個文檔:

- 文檔 A:包含 1000 個詞,其中 `apple` 出現了 10 次。

- 文檔 B:包含 100 個詞,其中 `apple` 出現了 1 次。

?

僅用 TF-IDF 評分

- 文檔 A 的 TF-IDF 評分可能更高因為它,包含更多的 `apple`。

- 文檔 B 的 TF-IDF 評分可能較低,因為它較短且詞頻較低。

?

用 BM25 評分

- BM25 會考慮文檔長度歸一化,文檔 A 的評分會被適當降低。

- 文檔 B 的評分可能會更高,因為它雖然短,但詞頻相對較高,且文檔長度歸一化會調整其評分。

?

5. 結論

如果不考慮文檔長度和查詢長度的影響,長文檔可能會因為包含更多關鍵詞而評分偏高,而短文檔可能會因為詞頻較低而評分偏低。BM25 通過文檔長度歸一化和詞頻飽和度處理,能夠更公平地評估文檔與查詢的相關性,避免僅因文檔長度而導致評分不準確。

在信息檢索和搜索引擎中,對高頻詞過度強調以及容易受拼寫錯誤或罕見詞干擾是與文本相似度計算算法(如 TF-IDF 和 BM25)相關的問題。以下是對這句話的詳細解釋:

1. 對高頻詞過度強調
在文本檢索中,高頻詞是指在文檔中出現頻率較高的詞語。例如,“的”、“是”、“在”等詞在中文文本中出現頻率很高,而在英文中,“the”、“and”、“is”等詞也是高頻詞。這些詞通常被稱為停用詞(stop words),因為它們對文本的內容意義貢獻較小。

問題:對高頻詞過度強調
- 背景:在 TF-IDF 算法中,詞頻(TF)是一個重要的因素。詞頻越高,該詞對文檔的貢獻被認為越大。然而,這種假設并不總是合理的。
- 問題:高頻詞(如停用詞)可能在幾乎所有文檔中都出現,它們對文檔的實際內容貢獻很小,但卻會在評分中占據較大權重。
- 例子:
? - 假設查詢是“蘋果”,文檔 A 中包含“蘋果”1 次,文檔 B 中包含“蘋果”1 次,但文檔 B 中還包含大量高頻詞(如“的”、“是”等)。
? - 如果僅根據詞頻(TF)來評分,文檔 B 可能會因為包含更多高頻詞而得分更高,即使這些高頻詞與查詢無關。

2. 容易受拼寫錯誤或罕見詞干擾
拼寫錯誤和罕見詞(即在語料庫中出現頻率極低的詞)也會對文本相似度計算產生影響。

問題:拼寫錯誤
- 背景:用戶在輸入查詢時可能會出現拼寫錯誤。例如,用戶可能將“apple”誤寫為“aple”。
- 問題:如果搜索引擎嚴格匹配查詢詞,拼寫錯誤會導致查詢詞與文檔中的詞不匹配,從而影響搜索結果的相關性。
- 例子:
? - 文檔中包含“apple”,但用戶查詢的是“aple”。
? - 如果搜索引擎沒有拼寫糾正機制,文檔將無法匹配到查詢,導致搜索結果為空。

問題:罕見詞
- 背景:罕見詞是指在語料庫中出現頻率極低的詞。這些詞可能因為拼寫錯誤、專有名詞或生僻詞匯而出現。
- 問題:罕見詞的逆文檔頻率(IDF)值會很高,因為它們在文檔中出現的頻率很低。這可能導致包含罕見詞的文檔在評分中獲得過高權重,即使這些詞與查詢的實際意圖無關。
- 例子:
? - 假設查詢是“apple”,文檔 A 中包含“apple”1 次,文檔 B 中包含“apple”1 次,但文檔 B 中還包含一個罕見詞“xylophone”。
? - 由于“xylophone”是一個罕見詞,其 IDF 值很高,可能會導致文檔 B 的評分過高,即使它與查詢“apple”并不更相關。

3. 解決方案
為了解決這些問題,現代搜索引擎和信息檢索系統采用了多種技術:

停用詞過濾
- 方法:在文本處理階段,過濾掉常見的停用詞(如“的”、“是”、“the”、“and”等)。
- 效果:減少高頻詞對評分的影響,提高搜索結果的相關性。

拼寫糾正
- 方法:使用拼寫糾正算法(如 Levenshtein 距離)來識別和糾正拼寫錯誤。
- 效果:即使用戶輸入了拼寫錯誤的查詢詞,搜索引擎也能找到正確的匹配項。

詞頻飽和度
- 方法:BM25 算通過法詞頻飽和度(Saturation)來調整詞頻的影響。即使某個詞的頻率很高,其對評分的貢獻也會逐漸飽和。
- 效果:避免因高頻詞而導致評分過高。

平滑處理
- 方法:對 IDF 值進行平滑處理,避免罕見詞的 IDF 值過高。
- 效果:減少罕見詞對評分的干擾。

4. 總結
- 對高頻詞過度強調:高頻詞(如停用詞)可能會在評分中占據較大權重,但它們對文檔的實際內容貢獻較小。
- 容易受拼寫錯誤或罕見詞干擾:拼寫錯誤會導致查詢詞與文檔中的詞不匹配,罕見詞可能會因為其高 IDF 值而影響評分。
- 解決方案:通過停用詞過濾、拼寫糾正、詞頻飽和度和平滑處理等技術,可以有效減少這些問題對搜索結果相關性的影響。

通過這些方法,搜索引擎能夠更準確地評估文檔與查詢的相關性,提高搜索結果的質量。

這句話描述的是傳統文本檢索和信息檢索系統(如基于 TF-IDF 或 BM25 的搜索引擎)的一個重要局限性:它們通常將文檔視為“詞袋模型”,而忽略了詞序和語義信息。以下是對這句話的詳細解釋:

1. 詞袋模型(Bag of Words, BoW)
詞袋模型是一種簡化的方法,用于將文本表示一組為單詞的集合,而忽略這些單詞在文檔中的順序。具體來說:
- 文檔表示:文檔被表示為單詞的集合,每個單詞的出現次數(或權重)被記錄下來,但單詞的順序被忽略。
- 例子:
? - 文檔 A:`"自然語言處理是人工智能的一個領域"`
? - 文檔 B:`"人工智能是自然語言處理的一個領域"`
? - 在詞袋模型中,這兩個文檔會被表示為相同的集合:`{自然語言處理, 是, 人工智能, 的, 一個, 領域}`。

2. 忽視語義
語義指的是文本的實際意義,而不僅僅是單詞的集合。詞袋模型的一個主要問題是它無法理解單詞之間的關系和上下文含義。例如:
- 例子:
? - 查詢:`"自然語言處理的人工智能應用"`
? - 文檔 A:`"自然語言處理是人工智能的一個領域"`
? - 文檔 B:`"自然語言處理和人工智能的交叉應用"`
? - 詞袋模型將會這兩個文檔視為相似,因為它們包含相同的單詞,但實際上文檔 B 更符合查詢的語義。

3. 忽略詞序
詞序指的是單詞在文檔中的排列順序。詞袋模型忽略了詞序,這可能導致以下問題:
- 例子:
? - 查詢:`"自然語言處理的人工智能應用"`
? - 文檔 A:`"自然語言處理是人工智能的一個領域"`
? - 文檔 B:`"人工智能在自然語言處理中的應用"`
? - 文檔 C:`"自然語言處理和人工智能的交叉應用"`
? - 袋詞模型無法區分文檔 A 和文檔 B,因為它們包含相同的單詞。但實際上,文檔 B 和文檔 C 更符合查詢的語義。

4. 問題總結
- 忽視語義:詞袋模型無法理解單詞之間的關系和上下文含義,可能導致不相關的文檔被檢索出來。
- 忽略詞序:詞袋模型忽略了單詞的排列順序,可能導致語義不同的文檔被錯誤地認為是相似的。

5. 解決方案
為了解決這些問題,現代自然語言處理和信息檢索技術引入了以下方法:

基于詞序的模型
- N-gram 模型:將文本表示為連續的單詞序列(如 bigram、trigram 等),從而考慮詞序信息。
? - 例子:對于文檔 `"自然語言處理是人工智能的一個領域"`,其 bigram 表示為:`{自然語言, 語言處理, 處理是, 是人工智能, 人工智能的, 的一個, 一個領域}`。
- 優點:可以捕捉到詞序信息,但隨著 n 的增大計算,復雜度和存儲需求也會增加。

基于語義的模型
- 詞嵌入(Word Embeddings):將單詞映射到高維向量空間,使得語義相似的單詞在向量空間中更接近。
? - 例子:使用 Word2Vec 或 GloVe,可以將單詞 `"自然語言處理"` 和 `"人工智能"` 映射到接近的向量。
- 句子嵌入(Sentence Embeddings):將整個句子或文檔映射到向量空間,從而捕捉到語義信息。
? - 例子:使用 BERT 或其他預訓練語言模型,可以將文檔和查詢映射到語義向量空間,并通過向量相似度計算相關性。

預訓練語言模型
- BERT、GPT 等:這些模型通過預訓練大量文本數據,能夠捕捉到單詞之間的復雜關系和上下文信息。
? - 例子:BERT 可以理解 `"自然語言處理的人工智能應用"` 和 `"人工智能在自然語言處理中的應用"` 的語義相似性。
- 優點:能夠理解更好地語義和詞序,提供更準確的搜索結果。

6. 總結
- 詞袋模型:將文檔視為單詞的集合,忽略詞序和語義,可能導致不準確的搜索結果。
- 問題:忽視語義和詞序,無法區分語義不同的文檔。
- 解決方案:通過 N-gram 模型、詞嵌入、句子嵌入和預訓練語言模型等方法,可以更好地捕捉詞序和語義信息,從而提高搜索結果的相關性。

通過這些技術,現代搜索引擎能夠更準確地理解用戶查詢的意圖,并提供更相關的結果。

本文來自互聯網用戶投稿,該文觀點僅代表作者本人,不代表本站立場。本站僅提供信息存儲空間服務,不擁有所有權,不承擔相關法律責任。
如若轉載,請注明出處:http://www.pswp.cn/diannao/87963.shtml
繁體地址,請注明出處:http://hk.pswp.cn/diannao/87963.shtml
英文地址,請注明出處:http://en.pswp.cn/diannao/87963.shtml

如若內容造成侵權/違法違規/事實不符,請聯系多彩編程網進行投訴反饋email:809451989@qq.com,一經查實,立即刪除!

相關文章

【QT】控件二(輸入類控件、多元素控件、容器類控件與布局管理器)

文章目錄 1.輸入類控件1.1 LineEdit1.2 Text Edit1.3 Combo Box1.4 SpinBox1.5 Date Edit & Time Edit1.6 Dial1.7 Slider 2. 多元素控件2.1 List Widget2.2 Table Widget2.3 Tree Widget 3. 容器類控件3.1 Group Box3.2 Tab Widget 4. 布局管理器4.1 垂直布局4.2 水平布局…

【Docker基礎】Docker鏡像管理:docker pull詳解

目錄 1 Docker鏡像基礎概念 1.1 什么是Docker鏡像? 1.2 鏡像與容器的關系 1.3 鏡像倉庫(Registry) 2 docker pull命令詳解 2.1 基本語法 2.2 參數解釋 2.3 拉取鏡像的基本流程 2.4 鏡像分層結構解析 3 docker pull實戰指南 3.1 基本使用示例 3.2 指定鏡…

PixPin:一個強大且免費的截圖貼圖工具

PixPin 是一款國產免費的截圖工具,支持屏幕截圖、屏幕錄制(GIF)、文字識別(OCR)以及貼圖等功能。 高效截圖 PixPin 支持自由選擇或自動檢測窗口,自定義截圖區域,像素級精確捕捉,延時…

【測試報告】論壇系統

一、項目背景 1.1 測試目標及測試任務 測試目標旨在保障功能無漏洞、流程順暢,實現多端顯示交互一致,達成高并發場景下響應時間<2 秒等性能指標,抵御 SQL 注入等安全攻擊,提升 UI 易用性與提示友好度; 背…

30天pytorch從入門到熟練(day1)

一、總體工作思路 本項目采用“從零構建”的策略,系統性地開展了深度學習模型的開發與優化工作。其目標在于通過全流程自研方式,深入理解模型構建、訓練優化、推理部署的關鍵技術環節。整體路徑分為以下核心階段: 模型初步構建:以…

Subway Surfers Blast × 亞矩陣云手機:手游矩陣運營的終極變現方案

引爆全球:Subway Surfers Blast的流量紅利?? 隨著Sybo Games最新力作《Subway Surfers Blast》全球上線,這款休閑消除游戲迅速席卷各大應用商店榜單。對于手游推廣者而言,如何高效獲取這波流量紅利???亞矩陣云手機專業手游推…

mysql join的原理及過程

連接過程 每獲得一條驅動表記錄,就立即到被驅動表尋找匹配的記錄。 對于兩表連接來說,驅動表只會被訪問一遍,但被驅動表卻要被訪問好多遍;具體訪問幾遍取決于對驅動表執行單表查詢后的結果集中有多少條記錄。 ? 對于內連接來說&#xff0…

Hologres的EXPLAIN和EXPLAIN ANALYZE簡介

文章目錄 一、執行計劃1、概念簡介2、使用方式①、EXPLAIN②、EXPLAIN ANALYZE 二、算子解讀1、SCAN2、Index Scan和 Index Seek3、Filter4、Decode5、Redistribution6、Join7、Broadcast8、Shard prune和Shards selected9、ExecuteExternalSQL10、Aggregate11、Sort12、Limit1…

49-Oracle init.ora-PFILE-SPFILE-啟動參數轉換實操

一早出現EMCC掛了,之后發現EMCC依賴的instance 掛了,重啟startup后發現spfile無法啟動。還是和小伙伴把基礎問題搞清。spfile是動態文件、動態文件、動態文件,linux下vi看起來部分亂碼部分是可編輯的,vi即使可以編輯也需要轉換成p…

spring碎片

包的掃描過程 判斷當前是否是文件夾獲取文件夾里面的所有內容判斷文件夾是否為空,為空的話直接返回如果文件夾不為空,則遍歷文件夾里面的所有內容 遍歷得到每個file對象,繼續進行判斷,如果還是文件,則進一步進行遞歸遍歷得到的file對象不是文件夾,是文件得到包路徑類名稱-字符…

如何形成項目經驗在多個項目間的高效復用?

要實現項目經驗的跨項目高效復用,核心在于建立系統化總結機制、標準化知識表達、平臺化共享工具。其中,標準化知識表達尤為關鍵,它通過統一模板和分類體系,確保不同項目的經驗可以被快速理解、輕松匹配到新場景,從而提…

目標檢測之YOLOV11談談OBB

引言:從軸對齊到定向邊界框的范式轉變 在計算機視覺領域,目標檢測算法長期受限于軸對齊邊界框(AABB)的固有缺陷——當面對航拍圖像中的艦船、遙感影像中的建筑物或工業質檢中的傾斜零件時,傳統邊界框會包含大量背景噪…

Vue2之生命周期

文章目錄 Vue生命周期Vue生命周期鉤子生命周期鉤子小案例在created中獲取數據在mounted中獲取焦點 Vue生命周期 思考:什么時候可以發送初始化渲染請求?(越早越好)什么時候可以開始操作dom?(至少dom得渲染出…

Web 架構之多租戶(SaaS)系統設計要點

文章目錄 一、多租戶系統概述定義應用場景 二、設計要點1. 數據隔離獨立數據庫共享數據庫,獨立 Schema共享數據庫,共享 Schema數據訪問控制 2. 資源分配計算資源存儲資源 3. 租戶管理租戶注冊與注銷租戶信息管理 4. 安全與合規身份驗證與授權數據加密 三…

【Clickhouse系列】索引

目錄 1. 主鍵索引 (Primary Key Index) - 核心是稀疏索引 2. 跳數索引 (Data Skipping Indexes) - 二級索引 3. 關鍵總結與最佳實踐: ClickHouse的索引設計哲學與其他傳統OLTP數據庫(如MySQL)有顯著不同,它更側重于高效掃描大數…

445場周賽

第一題:檢查元素頻次是否為質數 給你一個整數數組 nums。 如果數組中任一元素的 頻次 是 質數,返回 true;否則,返回 false。 元素 x 的 頻次 是它在數組中出現的次數。 質數是一個大于 1 的自然數,并且只有兩個因數…

【SQL語法匯總】

讀音:MySQL —— 賣舌口 MySQL 實際上是DBMS軟件系統, 并非數據庫。通過系統管理維護數據庫,DBMS相當于用戶和數據庫之間的橋梁。 MySQL是一種關系型數據庫, 類似excel,用行和列的關系組織數據數據。 操作關系型數據庫的DBMS系統大多數用SQL來管理數據。 SQL是編程語言…

C++法則10:引用本身是一個“別名”(alias),一旦綁定到一個對象后,就不能再重新綁定到其他對象。

C法則10:引用本身是一個“別名”(alias),一旦綁定到一個對象后,就不能再重新綁定到其他對象。 在C中,引用(reference)是一個已存在對象的別名。一旦引用被初始化綁定到一個對象&…

PHP 生成當月日期

一:按日期順序排列的數組,而不是按周分組的二維數組 /*日期生成 *day: 日期數字 *date: 完整的日期字符串 (YYYY-MM-DD) *is_current_month: 是否屬于當前月份 *is_prev_month: 是否是上個月的日期 *is_next_month: 是否是下個月的日期 *is_today: 是否是…

vue3+elementPlus實現無縫滾動表格封裝

vue3+elementPlus+css+js 模擬liMarquee插件,實現無限滾動效果 功能:1、表格數據大于一定數量之后,開始向上滾動 2、當鼠標移入的時候,動畫停止,鼠標移出,繼續動畫 3、滾動動畫的速度可以自定義 4、表格的高度固定 5、向上滾動時,無限滾動,不存在卡頓 <template>…