Meilisearch v1.6
Meilisearch 1.6 帶來混合搜尋功能,並在索引速度方面取得重大進展。

我們宣布 Meilisearch 1.6 版本發布。讓我們深入探討一些最重要的變更。您也可以在 GitHub 上查看完整變更日誌。
Meilisearch 1.6 也可在 Meilisearch Cloud 上使用,包括所有實驗性功能。
實驗性功能:混合搜尋
Meilisearch 推出混合搜尋。它結合了全文和語意搜尋,以提高搜尋結果的準確性和全面性。想像一下像 where2watch 這樣的電影應用程式。現在,您的使用者將能夠找到他們不太能說出名字但記得情節的那些電影。
此外,Meilisearch 現在簡化了向量嵌入的建立。選擇您偏好的嵌入器,Meilisearch 將為您處理與外部工具的所有互動。
設定嵌入器
您可以在索引設定中設定嵌入器。從三種類型的嵌入器中選擇以滿足您的需求
openAI
:
- 使用 OpenAI API 來計算嵌入
- 需要 OpenAI API 金鑰才能運作
huggingFace
:
- 透過從 HuggingFace Hub 下載模型,啟用嵌入的本機計算
- 在您的 CPU 上運作,而不是 GPU,這可能會影響索引效能
userProvided
:
- 與 Meilisearch v1.3 的功能類似,但主要區別在於:您必須定義特定的嵌入器
- 允許您將預先計算的嵌入加入到您的文件中。您可以使用向量而不是文字來執行搜尋。
要使用混合搜尋,請在索引設定中定義至少一個嵌入器
{ "embedders": { "default": { "source": "openAi", "apiKey": "<your-OpenAI-API-key>", "model": "text-embedding-ada-002", "documentTemplate": "A movie titled '{{doc.title}}' whose description starts with {{doc.overview|truncatewords: 20}}" }, "image": { "source": "userProvided", "dimensions": 512 }, "translation": { "source": "huggingFace", "model": "sentence-transformers/paraphrase-multilingual-MiniLM-L12-v2", "documentTemplate": "A movie titled '{{doc.title}}' whose description starts with {{doc.overview|truncatewords: 20}}" } } }
documentTemplate
欄位作為建立文件嵌入的藍圖。它使用 Liquid 範本語言。雖然它的加入是選擇性的,但強烈建議使用,尤其是在嵌入模型針對簡潔文字進行最佳化的情況下。它只保留必要的內容,排除 id
等非必要資料,並有助於新增上下文以提高相關性。
混合搜尋
要執行混合搜尋,請在 POST /index/:index_uid/search
路徑中使用混合欄位。
{ "q": "Plumbers and dinosaurs", "hybrid": { "semanticRatio": 0.9, "embedder": "default" } }
embedder
:索引設定中設定的選項中的一個嵌入器。
semanticRatio
:範圍從 0
到 1
的浮點值;1
是完全語意搜尋;0
是以精確匹配為重點的全文搜尋;預設值為 0.5
,它混合了這兩種方法。
您對語意比率的控制會直接影響搜尋結果的排名方式。較高的語意比率會將重點轉向您查詢背後的上下文和含義,對語意上更相關的結果進行較高的排名。
另一方面,較低的語意比率會增加排名過程中給予關鍵字準確性的權重,將與您特定搜尋詞彙密切匹配的結果放在最前面。
實驗性向量搜尋 API 中的重大變更
Meilisearch v1.6 在向量搜尋 API 中引入了一些重大變更。
先前,您可以傳送向量而不指定模型。現在,您必須在設定中定義模型
"embedders": { "default": { "source": "userProvided", "dimensions": 512 } }
由於 Meilisearch 現在支援多個嵌入器,因此已將向量提交格式從陣列更新為 JSON 物件。
- 預覽格式:
“_vectors”: [[0.0, 0.1]]
- 新格式:
“_vectors”: {“image2text”: [0.0, 0.1, …]}
如需這些更新的詳細資訊,請參閱文件。
如需深入的技術資訊,請瀏覽 [一系列文章](/blog/spotify-inspired-hybrid-search-and-rust/?utm_campaign=release-v1-6&utm_source=blog 關於 Arroy,這是一個基於 Spotify 的 Annoy 並以 Rust 開發的開源儲存庫。這個由 Meilisearch 引擎團隊建立和維護的程式庫,專門用於在空間中搜尋接近指定查詢向量的向量。
效能最佳化
改善索引速度
我們很高興分享 Meilisearch 索引效能的重大改進。我們最近的測試,包括頻繁和部分文件更新的情境,顯示出令人印象深刻的結果:索引時間最多減少了 50%,在某些情況下,甚至高達 75%。
由於我們最新的最佳化,Meilisearch 現在儲存和預先計算較少的資料。此外,在文件更新期間,它只會重新索引或刪除必要的資料。例如,在電子商務資料集中,更新產品的庫存量只會重新索引「庫存」欄位,而不是整個產品文件。
減少磁碟空間使用量
Meilisearch 減少內部資料儲存,從而使磁碟上的資料庫大小更精簡。對於大約 15Mb 的資料集,我們觀察到資料庫大小減少了 40% 到 50%。
此增強功能不僅減少了資料庫大小,還提高了其穩定性,隨著文件數量的增加,空間節省將更加明顯。
新功能:自訂鄰近度精確度
為了進一步降低索引速度,Meilisearch 現在允許您根據您的特定需求調整鄰近度排名規則的準確性。
鄰近度排名規則在計算上要求很高,可能導致索引時間更長。降低其準確性可以大大提高效能,而且在大多數情況下,它不會大幅影響結果的相關性。
要調整其影響,請設定 proximityPrecision
設定
curl -X PATCH 'http://127.0.0.1:7700/indexes/books/settings/proximity-precision' -H 'Content-Type: application/json' --data-binary '{ "proximityPrecision": "byAttribute" }'
預設的 proximityPrecision
設定為 byWord
,它根據精確的字詞距離計算鄰近度。
byAttribute
設定會將同一個屬性中的字詞視為鄰近,而不論它們的確切距離如何。
使用 byAttribute
可以提高索引速度,但可能會稍微改變結果的相關性。在字詞彼此鄰近非常重要的搜尋中,這會變得更加明顯。
例如,當您瀏覽歌詞或長篇文章時,例如嘗試在一堆維基百科頁面中找到「世界大戰」,您可能會得到包含這些字詞的結果,但不一定彼此鄰近或按所需順序排列。對於 詞組搜尋以及涉及多字詞同義字的搜尋,其中字詞的特定組合至關重要,也是如此。
新功能:工作佇列 Webhook
Meilisearch 現在提供 Webhook 功能,當非同步工作完成(成功、失敗或取消)時,會通知自訂 URL。
此功能對於簡化工作流程特別有用,可讓您不必輪詢工作路徑。
在啟動時使用這些環境變數設定您的 Webhook
MEILI_TASK_WEBHOOK_URL=https://mywebsite.com/my-super-webhook?user=1234&number=8 MEILI_TASK_WEBHOOK_AUTHORIZATION_HEADER='Bearer 12340987546wowowlolol'
您也可以使用各自的命令列選項。
設定完成後,Webhook 會以 JSON Lines (ndjson) 格式將包含已完成工作清單的有效負載傳送到您指定的 URL
//POST HTTP request to https://myproject.com/mywebhook?common=people {"uid":4,"indexUid":"movie","status":"failed","type":"indexDeletion","canceledBy":null,"details.deletedDocuments":0,"error.message":"Index `movie` not found.","error.code":"index_not_found","error.type":"invalid_request","error.link":"https://docs.meilisearch.com/errors#index_not_found","duration":"PT0.001192S","enqueuedAt":"2022-08-04T12:28:15.159167Z","startedAt":"2022-08-04T12:28:15.161996Z","finishedAt":"2022-08-04T12:28:15.163188Z"} {"uid":5,"indexUid":"movie","status":"failed","type":"indexDeletion","canceledBy":null,"details.deletedDocuments":0,"error.message":"Index `movie` not found.","error.code":"index_not_found","error.type":"invalid_request","error.link":"https://docs.meilisearch.com/errors#index_not_found","duration":"PT0.001192S","enqueuedAt":"2022-08-04T12:28:15.159167Z","startedAt":"2022-08-04T12:28:15.161996Z","finishedAt":"2022-08-04T12:28:15.163188Z"}
實驗性功能:限制批次處理工作的數量
為了加快索引處理速度,Meilisearch 會以大型批次處理相似的工作。但是,過多的排隊工作有時可能會導致崩潰或停滯。
若要控制批次處理工作的數量,請使用命令列引數 --experimental-max-number-of-batched-tasks
、MEILI_EXPERIMENTAL_MAX_NUMBER_OF_BATCHED_TASKS
環境變數或設定檔,在啟動時設定限制。
感謝貢獻者
我們非常感謝所有參與本次發布的社群成員。我們要感謝 @Karribalu 和 @vivek-26 對於 Meilisearch 的幫助。我們也想特別感謝我們的 SDK 維護者 🦸
這就是 v1.6 的全部內容!此發布文章重點介紹最重要的更新。如需完整列表,請閱讀 Github 上的變更日誌。
訂閱電子報,隨時掌握 Meilisearch 的一切動態。若要深入了解 Meilisearch 的未來並協助塑造它,請查看我們的路線圖,並參與我們的產品討論。
如有其他問題,請加入我們在 Discord 上的開發人員社群。