維基百科頁面的Elasticsearch查詢-有解無憂

我已經索引了 elasticsearch 上的所有維基百科頁面，現在我想根據我創建的關鍵字串列來搜索它們。elasticsearch 上的檔案只有三個欄位：id頁面 id、title頁面標題和content頁面內容（已經清除了 wikipedia 標記）。

我的目標是盡可能地重現 mediawiki 查詢 api，帶有引數action=query和list=search. 例如，給定關鍵字“非黎曼度量空間”，呼叫

https://en.wikipedia.org/w/api.php?action=query&list=search&format=json&srlimit=10&srprop=&srsearch=non riemannian metric spaces

給出與這些關鍵字最相關的頁面串列。

到目前為止，我一直在使用相當簡單的彈性搜索搜索查詢，例如

POST _search
{
  "query": {
    "bool" : {
      "must" : {
        "match" : {
          "content": {
            "query": "non riemannian metric spaces"
          }
        }
      },
      "should" : {
        "match" : {
          "title": {
            "query": "non riemannian metric spaces",
            "boost": x
          }
        }
      }
    }
  }
}

對于 boost 的幾個值，1例如2或0.5。這已經給出了一些不錯的結果，因為我獲得的頁面與關鍵字相關，但有時它們與我使用 mediawiki api 獲得的并不完全相同。

我很高興聽到一些關于如何微調彈性搜索查詢以更準確地模仿 mediawiki api 行為的建議。甚至，由于 mediawiki api 本身是用 elasticsearch 和cirrussearch 構建的，我想知道上面帶有這些特定引數的入口點的實際 elasticsearch 查詢是否是公開可用的。

先感謝您！

更新（在 Robis Koopmans 的回答之后）：查看實際查詢cirrusDumpQuery確實非常有用。但是，我確實對查詢有一些后續問題：

該查詢有一組類似的multi_match子句在fieldslike中搜索我的關鍵字["title.plain^1", "title^3"]。雖然我理解^n提升，但我忽略了.plain所指的內容。它是否與elasticsearch本身有關（即它是從title索引時間派生的欄位？）還是與他們使用的特定mediawiki映射有關？無論如何，我將不勝感激有關此的更多資訊。
在查詢的其他點，有一個{"match": {"all": {...}}}子句。all這里的關鍵是什么？它是一個檔案欄位嗎？跟match_all條款有關系嗎？
suggest查詢中出現的欄位是什么？在分數解釋中，它似乎與同義詞有關。在這種情況下如何處理？
要在搜索之后執行，有一個rescore帶有另外兩個評分函式的子句。其中一個使用popularity_score維基百科頁面。那是什么？
最后，最終對頁面進行排名的最相關分數是sltr子句的輸出。在其中，有一個"model": "enwiki-20220421-20180215-query_explorer"，并且在分數解釋中它被標識為LtrModel: naive_additive_decision_tree。我知道這個模型是一些存盤的LTR模型。但是，由于它似乎是結果最終排序中最相關的數字，那么該模型到底是什么？它是否公開可用？

請隨時回答您知道答案的任何問題，再次非常感謝！

uj5u.com熱心網友回復：

該查詢有一組類似的 multi_match 子句在 ["title.plain^1", "title^3"] 等欄位中搜索我的關鍵字。雖然我了解 ^n 提升，但我忽略了 .plain 所指的內容。它是否與 elasticsearch 本身有關（即它是在索引時從標題派生的欄位？）還是與他們使用的特定 mediawiki 映射有關？無論如何，我將不勝感激有關此的更多資訊。

.plain 欄位是作為彈性搜索映射的一部分生成的。當前的設定和映射可用于查看它們的作業原理。mediawiki.org 在普通欄位中也包含一個搜索詞匯表條目。一般來說，頂級欄位包含高度處理的文本形式，而普通欄位使用最少的分析。

在查詢的其他點，有一個 {"match": {"all": {...}}} 子句。這里的所有關鍵到底是什么？它是一個檔案欄位嗎？它與 match_all 子句有關嗎？

mediawiki.org 還包含一個（不完整的）CirrusSearch 模式，它簡要描述了這些欄位和使用的各種分析鏈組件。all 欄位是一種優化，可針對搜索索引提供強大的首次通過過濾器。

查詢中出現的建議欄位是什么？在分數解釋中，它似乎與同義詞有關。在這種情況下如何處理？

Suggest 欄位包含文章標題和重定向的shingles（單詞 ngram），本質上是短語查詢的預計算。建議可能看起來像解釋輸出中的同義詞，并且它們通常包含這些同義詞，但它還包括拼寫錯誤、翻譯以及編輯器創建重定向的許多其他原因。重定向匹配通常是一個很強的相關性信號。

要在搜索之后執行，有一個帶有其他兩個評分函式的 rescore 子句。其中一個使用維基百科頁面的流行度評分。那是什么？

這是 wiki 上訪問該文章的頁面瀏覽量的一部分。

最后，最終對頁面進行排名的最相關分數是 sltr 子句的輸出。其中，有一個“模型”：“enwiki-20220421-20180215-query_explorer”，在分數解釋中，它用 LtrModel 標識：naive_additive_decision_tree。我知道這個模型是一些存盤的 LTR 模型。但是，由于它似乎是結果最終排序中最相關的數字，那么該模型到底是什么？它是否公開可用？

該模型由mjolnir生成，基本上覆寫了其余查詢的分數。wikitech中有一些資訊（在那里找到，因為它比 mediawiki 本身更特定于 mediawiki 的 WMF 部署），還有一個名為From Clicks to Models的幻燈片可能會深入了解該代碼庫中發生的事情。也許重要的是要知道 mjolnir 僅適用于詞袋查詢、呼叫短語的查詢或其他專家功能跳過 ML 模型。

以前沒有人要求過模型，如果它們可能有用，我會從排名插件中洗掉當前模型。這包含使用的特征定義和 xgboost 生成的決策樹。

我沒有找到在上面鏈接它的借口，但也許CirrusSearch/Scoring的草稿頁面提到了檢索和評分的一些因素，特別是對于無法通過 mjolnir 模型運行的查詢，可能會有所幫助好。

uj5u.com熱心網友回復：

您可以添加cirrusDumpQuery到您的查詢

例子：

https://en.wikipedia.org/w/index.php?title=Special:Search&cirrusDumpQuery=&search=cat dog chicken&ns0=1

更多資訊：

https://www.mediawiki.org/wiki/Extension:CirrusSearch#API

uj5u.com熱心網友回復：

您不能直接對 Wikipedia 進行 Elasticsearch 查詢，但 CirrusSearch 可以生成除全文搜索之外的多種型別的查詢。從您的問題中不清楚您正在尋找哪種型別的查詢，但如果您更喜歡僅通過文本相似性而不是頁面瀏覽量等方式對結果進行加權，則可能值得查看排序選項。

轉載請註明出處，本文鏈接：https://www.uj5u.com/caozuo/477670.html

標籤：弹性搜索全文搜索媒体维基 mediawiki-api

上一篇：在elasticsearch中按分數和日期排序

下一篇：如何將此輸入框居中