Elastic Stack 8.12：通過對 ES|QL 等的改進增強了向量搜索

這篇具有很好參考價值的文章主要介紹了Elastic Stack 8.12：通過對 ES|QL 等的改進增強了向量搜索。希望對大家有所幫助。如果存在錯誤或未考慮完全的地方，請大家不吝賜教，您也可以點擊"舉報違法"按鈕提交疑問。

作者：來自 Elastic?Tyler Perkins, Shani Sagiv, Gilad Gal, Ninoslav Miskovic

elasticsearch 8.12,Elasticsearch,Kibana,Elastic,elasticsearch,大數(shù)據(jù),搜索引擎,全文檢索,人工智能,數(shù)據(jù)庫

Elastic? Stack 8.12 構(gòu)建于 Apache Lucene 9.9（有史以來最快的 Lucene 版本）之上，基于我們對標(biāo)量量化和搜索并發(fā)性的貢獻，為文本、向量和混合搜索帶來了巨大進步。此版本還優(yōu)化了 Elasticsearch? 中的查詢并行化以及 Kibana? 的增強功能，包括儀表板中的 ES|QL 查詢編輯。

這些新功能使客戶能夠：

利用標(biāo)量量化和融合乘加 (FMA)，可降低成本和查詢延遲并增強矢量數(shù)據(jù)搜索的攝取性能
使用查詢并行化體驗顯著更快的搜索和聚合
直接在儀表板上編輯 ES|QL 查詢，無需在儀表板和 Discover 應(yīng)用程序之間切換，并利用對 ES|QL 應(yīng)用內(nèi)文檔的改進來幫助用戶更快地學(xué)習(xí)

Elastic Stack 8.12 現(xiàn)已在 Elastic Cloud 上推出，這是唯一包含最新版本中所有新功能的托管 Elasticsearch 產(chǎn)品。你還可以下載 Elastic Stack 和我們的云編排產(chǎn)品 Elastic Cloud Enterprise 和 Elastic Cloud for Kubernetes，以獲得自我管理的體驗。

Elastic 8.12 中還有哪些新功能？查看 8.12 公告帖子了解更多>>

更快、更高效的向量搜索，基于 Apache Lucene 9.9

在 Lucene 9.6 和 Lucene 9.9 之間，某些參數(shù)的速度提高了 7% 到 290%！我們很高興與你分享我們?yōu)?Lucene 所做的一些工作。

向量的標(biāo)量量化（scalar quantization）

執(zhí)行向量搜索是基于比較查詢向量與索引中向量的相似度，這意味著對向量的每個維度執(zhí)行操作。這意味著索引大?。ㄓ绊懗杀荆?、攝取性能和查詢延遲都是各個向量大小的函數(shù)。

許多用于生成向量的 ML 模型都輸出具有 float32 元素的向量。 float32 消耗 4 個字節(jié)的內(nèi)存，這允許很多值 (2^32)。在大多數(shù)情況下，每個維度維護如此多的信息對相關(guān)性排名的好處非常有限，因為可以通過更小的維度元素獲得相同的排序（排名）。測試很簡單：將維度值轉(zhuǎn)換為更小的數(shù)據(jù)類型，然后看看排名變化了多少。我們（和其他人）已經(jīng)做到了這一點，并發(fā)現(xiàn)，通過稍微增加正在評估的候選者數(shù)量，當(dāng)從 float32 轉(zhuǎn)換為 int8（從 4 字節(jié)到 1 字節(jié)）時，很容易實現(xiàn)排名質(zhì)量的零降低。

因此，我們在 Elasticsearch 中開發(fā)了對 int8 元素向量的支持，但到目前為止，從 float32 到 int8 的轉(zhuǎn)換都是由用戶執(zhí)行的。在 8.12 中，Elasticsearch 通過為向量添加新的索引選項類型來處理從 float32 到 int8 的線性轉(zhuǎn)換：“int8_hnsw”。其影響是降低成本、提高攝取性能和減少查詢延遲，即使不增加正在評估的候選者數(shù)量，通常也不會對排名質(zhì)量產(chǎn)生任何明顯影響。大多數(shù)向量搜索用戶都會受益于這個選項。有關(guān)更多信息，請參閱我們的 Lucene 中的標(biāo)量量化簡介和標(biāo)量量化 101 博客。

kNN 向量搜索作為查詢

使用 HNSW 算法的密集向量搜索現(xiàn)在可用作查詢。到目前為止，它必須是搜索請求中的頂級元素。這是更大變化的一部分，旨在簡化向量搜索的語法，并允許將向量搜索與其他搜索機制結(jié)合起來，以靈活地解決更復(fù)雜的用戶請求。

在攝取時保存范數(shù)（norm）以獲得更有效的余弦相似度

在 Elasticsearch中，我們支持四種向量相似度方法（歐幾里得、曼哈頓、余弦和點積），但在實踐中，大多數(shù)模型輸出的向量應(yīng)該通過余弦相似度進行比較。我們一直建議用戶使用點積而不是余弦，但為了做到這一點，用戶必須對 ML 模型在推理時生成的向量進行歸一化（即，將它們除以范數(shù)，使其長度變?yōu)?1）。當(dāng)向量被歸一化時，它們按照歸一化查詢向量的點積的排序順序?qū)⑴c它們在歸一化之前按照余弦的排序順序相同。我們建議使用點積的原因是它在查詢時需要更少的操作，從而允許更好的查詢延遲。如果你檢查點積和余弦的運算，一切都會變得清晰：

elasticsearch 8.12,Elasticsearch,Kibana,Elastic,elasticsearch,大數(shù)據(jù),搜索引擎,全文檢索,人工智能,數(shù)據(jù)庫

換句話說，計算點積需要多次乘法運算和多次加法運算，其數(shù)量等于向量中的維數(shù)，而對于余弦，你首先執(zhí)行點積，然后在此基礎(chǔ)上執(zhí)行兩倍的點積。計算點積所需的操作（加上一些小的開銷），以便計算分母。現(xiàn)在請記住，這是根據(jù)被視為潛在結(jié)果的每個向量計算的。附帶說明一下，大量乘法和求和運算是 8.12 中引入的 FMA 增強功能（見下文）如此重要的原因。

然而，你可能已經(jīng)注意到分母，范數(shù)......

elasticsearch 8.12,Elasticsearch,Kibana,Elastic,elasticsearch,大數(shù)據(jù),搜索引擎,全文檢索,人工智能,數(shù)據(jù)庫

…實際上每個向量都是恒定的，因此我們不是在每次查詢時重復(fù)計算它，而是在攝取時計算一次并保留歸一化向量和范數(shù)（每個向量增加的開銷可以忽略不計）。這意味著使用余弦時的查詢延遲與使用點積時一樣高效，因為我們只是對歸一化向量執(zhí)行點積。我們保留范數(shù)，以便我們可以根據(jù)需要計算原始向量，以供腳本訪問。最重要的是，不需要對向量進行歸一化，這使得使用向量相似度變得更容易。

對于從 8.12 開始創(chuàng)建的任何索引，查詢延遲都會自動得到改善。

用于向量搜索的 FMA 指令

向量比較（例如，通過點積或余弦運算）涉及重復(fù)將兩個數(shù)字相乘并將結(jié)果與第三個數(shù)字相加（這就是計算點積的方式）

elasticsearch 8.12,Elasticsearch,Kibana,Elastic,elasticsearch,大數(shù)據(jù),搜索引擎,全文檢索,人工智能,數(shù)據(jù)庫

其中 n 是維數(shù)，并且對每個評估的向量重復(fù)它，這是很多）。

在這些情況下，我們更改了 Lucene 向 CPU 提供的指令，以便如果 CPU 支持（ARM 和 x86 CPU 支持），則乘法和加法運算將作為單個 CPU 運算（融合乘加）執(zhí)行。此更改改進了向量索引性能以及點積和余弦相似度的查詢延遲。 Lucene 級別的點積改進約為 5%，余弦相似度索引可以達到兩位數(shù)的影響（Elasticsearch 中的影響較小，因為 Elasticsearch 執(zhí)行了一些額外的操作，但這些操作不受影響）。

為了從中受益，你唯一需要做的就是升級到 8.12。改善自然會發(fā)生。有關(guān)此更改的更多信息，請參閱我們的向量相似性計算 FMA 風(fēng)格的博客。

當(dāng)我們做出在 Lucene 中開發(fā)向量相似性并使 Lucene 成為向量搜索的最佳基礎(chǔ)設(shè)施的戰(zhàn)略決策時，關(guān)鍵考慮因素之一是我們希望用戶從這種不斷優(yōu)化和改進引擎的細致工程工作中受益， FMA 優(yōu)化就是這種持續(xù)改進的完美例子。

地理搜索和聚合

ES|QL 中的地理查詢

Elasticsearch 已開始引入一種新的查詢語言，它具有許多超越簡化語法的優(yōu)點。作為新語言工作的一部分，我們現(xiàn)在通過 ES|QL 引入對 geo_point 和 point 數(shù)據(jù)類型的支持。此功能仍處于技術(shù)預(yù)覽階段，并允許基本功能 - 主要是對這些地理空間數(shù)據(jù)類型執(zhí)行選擇操作。這是我們將繼續(xù)擴展的基礎(chǔ)，因為我們看到諸如 join 之類的功能在地理場景中可以通過 ES|QL 獲得大量使用。請嘗試一下并提供你的反饋。

Geo_shape 運行時字段

現(xiàn)在可以為 geo_shape 創(chuàng)建運行時字段。運行時字段是通過運行輕松的腳本在查詢時計算的，也可以臨時定義為查詢的一部分。能夠為 geo_shapes 形成運行時字段開啟了許多新的可能性，例如能夠從一個坐標(biāo)系投影到另一個坐標(biāo)系。

查詢并行化

直到最近，Elasticsearch 仍會使用每個分片一個線程來運行每個查詢。當(dāng)你同時運行多個查詢時，這種方法非常有效，但當(dāng)查詢負載低于集群資源可以處理的水平時，計算資源的利用率可能不是最佳的，并且有可能改善查詢延遲。

在 8.10 中，我們?yōu)橄蛄克阉魈砑恿瞬樵儾⑿谢@在適當(dāng)?shù)臈l件下顯著改善了查詢延遲。我們現(xiàn)在為大多數(shù)其他查詢和聚合添加類似的并行化。有一些例外，最值得注意的是術(shù)語聚合（因為增加術(shù)語聚合的并行化會對它們的準(zhǔn)確性產(chǎn)生負面影響）。對聚合的影響尤其顯著，有時會將延遲減少到以前的一半以下。如果有可用線程，新的并行化機制將為每個查詢的每個段（segment）分配最多一個線程，并限制每個查詢分配的最大線程數(shù)。你可以在我們的公開夜間基準(zhǔn)測試中見證結(jié)果。

elasticsearch 8.12,Elasticsearch,Kibana,Elastic,elasticsearch,大數(shù)據(jù),搜索引擎,全文檢索,人工智能,數(shù)據(jù)庫 — 取自 NOAA 夜間基準(zhǔn)

隨著最近添加的重新路由攝取處理器（在 8.11 中正式發(fā)布），Elasticsearch 中的攝取管道變得更加靈活。重新路由允許你根據(jù) data_stream.dataset 和 data_stream.namespace 字段或你指定的其他字段和條件將日志分離到適當(dāng)?shù)臄?shù)據(jù)流中。唯一的缺點是，這在開發(fā)或調(diào)試攝取管道時增加了神秘感 —— 在不重新路由的情況下，在攝取單個文檔期間可以執(zhí)行的攝取管道的最大數(shù)量為兩個（指定管道或默認(rèn)管道，以及最終的管道）。

Elasticsearch 長期以來一直能夠模擬執(zhí)行給定文檔的管道，因此你可以快速嘗試新的管道或管道更改，而無需實際存儲任何數(shù)據(jù)。現(xiàn)有的 simulate pipeline API 可用于測試管道并查看生成的文檔是什么樣子。使用重新路由時，每個文檔執(zhí)行的管道數(shù)量是無限的，因為每個管道都可以重新路由到另一個管道。我們需要一種新的方法來模擬覆蓋整個管道鏈的執(zhí)行。

新的模擬攝取 API 提供了此功能，模擬將數(shù)據(jù)攝取到索引中。它針對請求正文中提供的一組文檔執(zhí)行該索引的默認(rèn)和最終管道。

模擬例子：

POST /_ingest/_simulate
{
  "docs": [
    {
      "_index": "my-index",
      "_id": "123",
      "_source": {
        "foo": "bar"
      }
    },
    …
  ]
}

如果管道包含重新路由處理器，它將遵循該重新路由處理器到新索引，同時執(zhí)行該索引的管道（與非模擬攝取的方式相同）。沒有數(shù)據(jù)被索引到 Elasticsearch 中。相反，將返回轉(zhuǎn)換后的文檔，以及已執(zhí)行的管道列表以及如果不是模擬則文檔將被索引的索引名稱。

模擬示例響應(yīng)：

{
   "docs": [
      {
         "doc": {
            "_id": "123",
            "_index": "my-index",
            "_version": -3,
            "_source": {
               "field1": "value1",
               "field2": "value2",
               "foo": "bar"
            },
            "executed_pipelines": [
               "my-pipeline",
               "my-final-pipeline"
            ]
         }
      },
   …

這與現(xiàn)有的 simulate pipeline API 不同，因為你為該 API 指定單個管道，并且它僅運行該管道。模擬管道 API 對于開發(fā)單個管道更有用，而新的 simulate ingest?API 對于對攝取到索引時應(yīng)用的各種管道的交互進行故障排除更有用。

你還可以在請求正文中提供替代管道定義，以代替系統(tǒng)中已有的管道定義。管道替換僅在此請求中使用，以顯示文檔的外觀以及它們將遵循哪些管道。

simulate ingest?API 是對 simulate pipeline?API 的補充，讓你可以跨多個索引測試多個管道的集成，這是以前在不實際索引數(shù)據(jù)的情況下不可能實現(xiàn)的。

出于同樣的原因，我們還向 bulk API 添加了一個選項 (list_execulated_pipelines=true)，以使其包含在響應(yīng)中的每個文檔上執(zhí)行的管道列表。

更方便地訪問遠程搜索的狀態(tài)

Kibana 8.12 是我們追求更好的大規(guī)模分布式搜索的又一步（當(dāng)然是 CCS！）。在 8.11 中，我們通過 Kibana 檢查器中的新集群和分片選項卡添加了觸手可及的跨集群搜索響應(yīng)信息。在 8.12 中，我們?yōu)?Inspector 添加了一些不錯的新功能，并使其在更多情況下可用。

如果你有很多遠程集群（我們有超過 170 個），現(xiàn)在可以更快、更輕松地找到具有特定狀態(tài)的子集或特定集群的狀態(tài)。你現(xiàn)在可以按搜索狀態(tài)進行過濾：

elasticsearch 8.12,Elasticsearch,Kibana,Elastic,elasticsearch,大數(shù)據(jù),搜索引擎,全文檢索,人工智能,數(shù)據(jù)庫

如果你只想顯示與特定名稱匹配的集群，只需在搜索框中輸入遠程集群名稱的一部分，我們就會過濾遠程集群列表。

elasticsearch 8.12,Elasticsearch,Kibana,Elastic,elasticsearch,大數(shù)據(jù),搜索引擎,全文檢索,人工智能,數(shù)據(jù)庫

你還可以按名稱、狀態(tài)或響應(yīng)時間對列表進行排序，以便在需要時輕松找到最慢的遠程集群。

所有這些更好地了解遠程搜索的好方法現(xiàn)在也可以在 Kibana 的更多地方使用。在 8.12 中，集群和分片檢查器將與 Discover 和 Maps 鏈接，而不僅僅是儀表板。除了像 8.11 中那樣進行部分搜索之外，我們還將在搜索失敗時提供指向它的鏈接。

Kibana 警報

維護窗口

安排單個或定期維護時段以減少警報噪音并抑制通知。例如，如果你有計劃的停機或事件，維護時段可以防止在此期間出現(xiàn)誤報。在此版本中，用戶將能夠根據(jù)時間創(chuàng)建和定義窗口并設(shè)置基于查詢的警報。

例如：作為用戶，我想抑制每個星期一早上 9:00 至 10:00 的警報，并且僅針對與此查詢匹配的警報：App: “Billing” and cluster: “X123” and project: “Prod”

elasticsearch 8.12,Elasticsearch,Kibana,Elastic,elasticsearch,大數(shù)據(jù),搜索引擎,全文檢索,人工智能,數(shù)據(jù)庫

連接器改進

PagerDuty 警報操作現(xiàn)在由兩個新字段支持： links 和 custom_details。
ServiceNow ITSM 警報操作允許用戶在警報恢復(fù)時定義事件解決方案，以確保 Elastic 警報和 ServiceNow 事件之間的雙向同步。

在儀表板中編輯 ES|QL 查詢

我們引入了直接通過儀表板編輯 ES|QL 查詢的功能。此視圖還允許用戶在不同的圖表建議中進行選擇。這是非常強大的，因為用戶不需要返回 “Discover” 頁面來編輯查詢并重新創(chuàng)建圖表 - 他們可以簡單地在儀表板上調(diào)整查詢！

在儀表板中編輯 ES|QL 查詢

Elastic Stack 8.12 是一個重大版本。標(biāo)量量化、融合乘加 (FMA) 和其他 Lucene 9.9 增強功能可降低成本和查詢延遲，同時提供更快的向量搜索性能。引入 kNN 向量搜索作為查詢可以帶來更好的開發(fā)人員體驗。查詢并行化的進步通過加速各種搜索和聚合功能來減少查詢延遲。對于 ES|QL 用戶來說，儀表板中直接提供的新查詢編輯功能可帶來更簡單的用戶體驗，無需離開即可實現(xiàn)無縫調(diào)整。這些升級，再加上地理搜索、攝取管道模擬、遠程搜索狀態(tài)訪問和連接器增強方面的改進，所有這些加起來使 Elastic Stack 8.12 值得快速升級！