本文作者：清豆 — 阿裡巴巴進階開發工程師
本文字數：2979
閱讀時間：3~6分鐘
您将了解：
1、開源向量檢索庫存在的問題
2、源自阿裡Proxima向量檢索庫的優勢
3、阿裡雲向量檢索的技術原理
4、阿裡雲向量檢索的應用場景
5、如何使用阿裡雲向量檢索
【全鍊路雲上Elastic Stack 全景圖】100%相容開源，9大獨有能力
----> 直播回顧 | 請點選觀看 ：
阿裡雲Elasticsearch向量檢索介紹尋根問源
（圖一：開源向量檢索庫面臨的問題）
我們知道，市面上有不少開源向量檢索庫供大家選擇使用，例如 Facebook 推出的 Faiss 以及 Nswlib，雖然選擇較多，但當業務上需要用到向量檢索時，依舊要面對四大共性問題。
1、離線方案，增量不可查
市面上大多向量檢索庫都是對增量資料不友好，有的需要做一次性全量資料來建構索引，有的需要使用者接受很少的增量資料，才能保證檢索準确率。在業務随時都有實時增量資料的情況下，每次都要重建全量，并利用線上低峰期來切換最新的全量索引。比如在每天晚上12點，我們做一次最新的全量索引，那麼你隻能查到前一天的增量資料。
2、無 Failover 及分布式能力
由于市面上的向量索引庫，往往不會考慮分布式場景的使用問題。在索引落盤前，任何一步出現機器故障，比如程序當機，都會導緻索引完全丢失并重新建立一遍。而且随着我們的業務增長資料越來越多，需要使用分布式來做索引建構，是無法然由這些庫來滿足。
3、性能弱
對 Elasticsearch 熟悉的同學會知道，X-pack 在 7.x 推出了 dense-vector 的向量檢索字段，但對于前兩個問題依舊沒有解決，在我們實際測試中發現，dense-vector 這個字段，或者說向量檢索，是基于線性暴力計算來實作的，基本原理是對每個文檔，計算與你 query 的相似度，延時随着資料量增長而成正比例函數關系，在實測2KW的向量資料時，dense-vector 召回時間在 10s 左右。那麼在用 X-pack 的向量字段做人臉識别時，對于10秒的響應時間，相信大家是無法接受的。
4、額外學習成本
由于大多向量檢索庫是運用 C++ 來實作的，有些也提供了 Python 的接口。二 C++ 的學習成本大家知道，且非常難上手，而且這種重用戶端的模式不管是靈活性還是可維護性，都沒有辦法跟 REST API 互動的方式相媲美
優勢介紹
（圖二：阿裡雲向量檢索優勢）
1、以阿裡雲 Elasticsearch 插件的形式使用，一鍵安裝。同時由于封裝了阿裡巴巴達摩院自研的 Proxima 高性能向量檢索庫。該向量檢索庫已經應用于阿裡集團多個大規模核心生産業務，性能和穩定性都曆經了多年考驗。
2、基于 Lucene code-c 機制無縫擴充了向量的索引，阿裡雲 Elasticsearch 分布式容災能力都與原生 Elasticsearch 完美相容，支援Failover，橫向彈性擴充、快照恢複等容災能力。
3、基于線上引擎的方案，與原生 Elasticsearch 的NRT近實時機制相同，線上的向量增量資料寫入阿裡雲 Elasticsearch 後，隻需Refresh即可查到，最快能夠做到秒級的可見性延遲。
4、封裝了與原生 Elasticsearch DSL 協定一直的向量 QueryBuilder，阿裡雲 Elasticsearch 使用者無需任何額外的學習成本即可快速上手向量檢索引擎。
實作原理
（圖三：技術原理）
方案的核心是運用 Lucene code—c機制。codec 是索引資料結構的抽象接口，可以自定義倒排/正排等索引；Lucene具體的工作流程是：當refresh刷出segment時，調用自定義 Proxima 的 Code-C，按照segment的力度，建構向量索引，即達摩院的向量索引。在查詢時，按照 segment 次元，傳回向量檢索庫 Proxima 找到的文檔和分數即可，之後上傳阿裡雲 Elasticsearch，并做全局打分的排序、召回的工作。
（圖四：測試資料）
這裡是一些測試的資料，我們可以看到，基于 hnsw 算法的向量檢索插件，召回率和延遲都比較理想，實作98%的召回率和幾十毫秒的延遲。
場景應用
（圖五：達摩院向量檢索引擎在阿裡體系的業務）
圖五例舉了部分達摩院向量檢索庫在阿裡體系的業務應用。在圖像搜尋應用領域，可以運用在拍立淘、圖搜雲、阿裡媽媽反作弊等。推薦場景應用到了首頁的猜你喜歡、推薦、廣告檢索，蝦米音樂、飛豬等核心業務，同時還包括語言、視訊之類，同時在天貓精靈、優酷核心場景均有落地。
（圖六：向量檢索應用領域）
典型場景一“人臉識别”
向量檢索的典型應用之一就是人臉識别。這個場景是比較簡單且好了解的，比如我們的刷臉支付，由于原始資料量不會特别大，但卻對召回的準确率和延遲都有非常高的要求。因為我們不會希望，别人刷了臉從我的賬戶裡扣錢。
除了刷臉支付，在安全監控場景也有運用，比如我們專有雲客戶，他們會用阿裡雲 Elasticsearch 向量檢索引擎，來做路口交通的監控系統，通過一些具體的時段、路段标簽字段作為一個協同，并根據人臉資訊、車輛資訊，抽取特征做向量字段，這些字段聯合起來做查詢，監測異常出現的軌迹。
典型場景二“商品推薦”
在商品推薦場景中，比如經常看到的淘寶“猜你喜歡”。大家都知道要做到個性化的商品推薦，使用者的行為曆史、畫像、Query 的特征，都是非常重要的一項參數，這些特征我們都可以做 Rebuilding，作為表征使用者特征的向量。然後結合使用者向量表征資料與商品側召回的向量，利用一個近似距離的計算，我們就知道這個物品與使用者特征之間，他們的相似度是怎麼樣的，那我就可以通過這個相似度的排序，作為商品的推薦的重要參考标準。
對于一些比較長尾的 Query，如果按照傳統的倒排和字典的方式，可能無法特别準确的召回文檔，甚至可能出現沒有結果的情況。這類情況下，向量檢索就可以派上用場。比如當我們搜尋“日式煎茶”這個物品時，通過精确查詢召回的商品會特别的少，甚至可能召回一個完全不同的類目，比如召回“日式煎餅”。
當我們通過提前抽取商品特征以及 Query 特征，來做向量的近似召回就不同了。由于我們抽取了這些特征，是以我在搜尋“日式煎茶”的時候，如果精确查詢沒有結果，我們也可以召回像“日式抹茶”、“日式清茶”這種實際特征相似的商品，作為補充召回的功能。不僅可以提升商品的曝光量，同時提升使用者的使用體驗。
典型場景三“智能助理”
在“智能助理”應用場景中，如天貓精靈這種智能音箱，亦或是淘寶的客服系統 — 阿裡小蜜這種智能文本客服，這類對話的場景對回報延遲的要求非常高，并且資料量較少。如果做一些 Query 類目、情感等标簽，以及多入口知識庫召回，那可能比對的知識項就非常多了。那麼到精排階段，我們向量檢索就可以派上用場，通過精排階段在向量檢索庫打分的時候，可以按照近期熱點問題、近期促銷活動等方式，通過向量近似計算，做到快速打分排序，傳回給使用者最精準的結果。
是以向量檢索應用場景還是非常多的，隻要業務上有近似需求，那我們都可以用向量檢索的方案來做。
實操—快速運用向量檢索
一、安裝aliyun-knn插件
（圖七：阿裡雲 Elasticsearch 控制台）
我們可以登入阿裡雲Elasticsearch控制台頁面，向量檢索是以插件的形式來提供服務的，從【插件配置】Tab進入後，找到Aliyun-Knn（向量檢索）安裝即可。他是作為系統的預設插件存在，需要手動安裝後使用，目前支援阿裡雲Elasticsearch 6.7、7.4版本，測試僅需2核8G就可以測試，實際線上生産，我們建議4核16G以上節點來安裝。
二、建立索引
（圖八：建立索引）
與原生索引一緻，圖八中是一個 test 索引，除了傳統的副本數、shard數以外，還有一個 proxima code-c 的 setting，這個是必須要加的。
在 mapping 的地方，由于 proxima 向量索引是字段，比如圖中向量字段叫“feature”，那麼我們需要加上feature的properties，“type”就是“proxima_vector”，這個就是指定 proxima 的向量字段，圖八中指定了次元為“2”的向量字段，另外增加了一個字段ID,是keyword，示範的時候會用到。
三、添加文檔
（圖九：添加文檔）
添加文檔與原生一樣，圖九中共寫了3個文檔，第一個文檔ID為“1”，向量是【1,2】；後兩個文檔都是ID為“2”，而feature為【3,4】、【5,6】，也就是ID為“1”的字段，ID為“2”的字段有2個。
四、近似查詢
（圖十：近似查詢）
做近似查詢時，我們可以看到 “hnsw” 這個 query，就是我們向量查詢的寫譯。他可以跟其他類型的查詢做交并。我們可以看到，向量查詢跟term查詢是可以放在同一個must，或者同一個 feature ，在這種原生布爾查詢裡同時協同工作。
如果我們想查特征字段是【5.5，6.5】，ID為“2”的文檔時，那根據圖八中第三個文檔【5,6】，那麼這個文檔是最相近的查詢結果，那麼這個文檔的打分是最高的，排在第一位。且由于指定ID為“2”，是以我的 feature 生效僅召回了兩個文檔，另一個就是【3,4】，而ID為“1”的文檔沒有被召回。
相關活動
更多折扣活動，請通路
阿裡雲 Elasticsearch 官網 • 阿裡雲 Elasticsearch 商業通用版，1核2G首月免費•
阿裡雲 Elasticsearch 日志增強版，首月六折，年付六折 阿裡雲 Logstash 2核4G首月免費