作者丨gongyouliu
編輯丨zandy
來源 | 大資料與人工智能（ID: ai-big-data）
推薦系統是一種資訊過濾技術，通過從使用者行為中挖掘使用者興趣偏好，為使用者提供個性化的資訊，減少使用者的找尋時間，降低使用者的決策成本，讓使用者更加被動地消費資訊。
推薦系統是随着網際網路技術的發展及應用深入而出現的，并在目前得到廣泛的關注，它是一種軟體解決方案，是toC網際網路産品上的一個子產品。使用者通過與推薦子產品互動，推薦系統通過提供的web服務，将與使用者興趣比對的标的物篩選出來，組裝成合适的資料結構，最終展示給使用者。推薦系統web服務是前端和後端溝通的橋梁，是推薦結果傳輸的最後通道，資訊傳輸是否通暢，傳輸是否足夠快速，對使用者體驗是有極大影響的。
本文我們就來講解推薦系統提供web服務的兩種主要方式，這兩種方式是企業級推薦系統最常采用的兩種形式。
具體來說，這篇文章我們會從什麼是推薦系統web服務、推薦系統提供web服務的兩種方式、事先計算型web服務、實時裝配型web服務、兩種web服務方式的優劣對比、影響web服務方案的因素及選擇原則等6個部分來講解。通過本文的介紹，期望讀者可以深刻了解這兩種web服務方式的具體實作方案以及它們之間的差别，并具備結合具體的業務場景來決策采用哪種方式的能力。
什麼是推薦系統web服務
作者在《建構優質的推薦系統服務》第一節中已經對推薦系統web服務進行了簡單介紹，這裡為了讓讀者更好地了解本文的知識點，以及為了内容的完整性，對推薦系統web服務進行簡略介紹。
使用者與推薦系統互動的服務流程見下面圖1，使用者在使用産品過程中與推薦子產品(産品上提供推薦能力的功能點)互動，前端(手機、PC、Pad、智能電視等)請求推薦web服務，推薦web服務擷取該使用者的推薦結果，将推薦結果傳回給前端，前端通過适當的渲染将最終的推薦結果按照一定的樣式和排列規則在産品上展示出來，這時使用者就可以看到推薦系統給他的推薦結果了。
圖1：使用者通過推薦web服務擷取推薦結果的資料互動流程
上圖中的綠色虛線框中的資料互動能力就是推薦web服務的範疇，它是前端(也叫終端)與後端的互動，圖中藍色方塊(推薦web服務子產品)是部署在伺服器上的一類軟體服務，它提供HTTP接口，讓前端可以實時與之互動。使用者與終端的互動屬于視覺及互動設計範疇，雖然與推薦web服務無直接關系，但是是整個推薦服務能力完整實作必不可少的一環，也是使用者可以肉眼直接感覺到的部分，在整個推薦系統中非常重要，對推薦系統發揮價值有極大影響，不過不在我們這篇文章的讨論範圍，對這一塊感興趣的讀者可以參考《推薦系統的UI互動與視覺展示》這篇文章。
為了給前端提供個性化推薦服務，上圖中的推薦web服務子產品需要完成3件事情。首先需要獲得該使用者的推薦結果(直接獲得已經計算好的推薦結果，這就是第三節要講的，或者通過臨時計算獲得推薦結果，這就是第四節要講的)，其次是将結果組裝成前端最終需要的資料結構(第一步獲得的推薦結果一般是标的物id的清單，實際展示給前端還需要标的物的各種metadata資訊，如名稱，價格，海報圖等，這些資訊的組裝就是在這一步完成的，這些資訊一般會存放到關系型資料庫中，或者采用json的形式組織存放到Redis、文檔型NoSQL中，是以這裡至少還有一次額外的資料庫通路)，最後是響應前端的HTTP請求(一般是GET請求)，将最終推薦結果傳回給前端。本文我們講解的推薦系統提供web服務的兩種方式，就是這裡講的第一件事情，即推薦web服務怎麼獲得給使用者的推薦結果。
推薦web服務子產品是最終為使用者提供推薦能力的部分，它設計得好不好直接影響使用者體驗，一般來說，該子產品需要滿足穩定、響應及時、容錯、可以随着使用者規模線性擴容等多個條件，具體的細節讀者可以參考《建構優質的推薦系統服務》這篇文章。這裡提一下，随着Docker等容器技術及kubernetes等容器管理軟體的發展和成熟，推薦web服務中的各個子子產品都可以分别部署在容器中，采用微服務的方式進行資料互動，這樣就可以高效管理這些服務，更好地進行服務的監控、錯誤恢複、線性擴容等。
上圖隻是一種簡化的互動模型，在實際企業級服務中，往往比這個更加複雜，在前端和後端之間往往存在一層CDN層做緩存加速，以減輕前端服務對後端并發通路的壓力(在使用者量大的情況下，推薦系統屬于高并發服務)，并且一般推薦web服務中還存在一層Nginx代理層，通過Nginx代理，讓推薦web服務可以水準擴容，以滿足推薦系統高并發的要求。下面圖2就是一種可行的完整推薦系統服務方案。
圖2：完整的推薦系統業務架構圖
如前面所講，雖然推薦web服務包含前端與後端的互動，前端與後端一般還會有CDN層和Nginx代理層，但本文我們着重關注的是後端真正提供Web服務接口子產品及資料存儲子產品的實作方案，也即上圖中紅色子產品怎麼擷取推薦結果的架構實作方案。該子產品的實作方案可以多樣，主流的實作方式有兩種，我們在下面分三節來進行介紹。
推薦系統提供web服務的兩種方式
推薦系統提供web服務一般有兩種方式，一種是事先計算型，另一種是實時裝配型。在具體介紹之前，這裡我先舉一個比較形象的例子，讓大家更好地了解這兩種實作方式。
假設我們開了一家餐廳專門送外賣，餐廳提供10種不同的備選套餐。在午市或者晚市叫餐高峰時段，餐廳可以采用如下兩種方案來準備套餐：第一種方案是事先将這10種套餐每種都做若幹份，當有客戶叫外賣時，将該客戶叫的這個套餐(已經做好了)直接送出去；第二種方式是将這10種套餐需要的原材料都準備好，部分材料做成半成品(比如比較花時間的肉類)，當有使用者叫餐時，将該套餐需要的原材料下鍋快速做好再送出去。
通過上面非常簡化的案例介紹，大家應該不難了解，上面提到的第一種準備套餐的方式就是“事先計算型”，事先将套餐做好，而第二種方式就是“實時裝配型”，當使用者叫餐時，臨時做并快速做好。
現在讓我們回到推薦web服務上，來介紹兩種推薦web服務方案。事先計算型就是将使用者的推薦結果事先計算好，放到資料庫中存放起來，當該使用者在使用産品過程中通路推薦子產品時，推薦web服務子產品直接将該使用者計算好的推薦結果取出來，進行适當加工(比如過濾掉使用者已經看過的視訊)，将最終推薦結果展示給使用者。實時裝配型是将計算推薦結果需要的資料(一般是各種特征)提前準備好，當使用者通路推薦子產品時，推薦web服務通過簡單的計算群組裝(利用前面準備好的各種特征灌入推薦模型)，生成該使用者的推薦結果，再将推薦結果傳回給前端并展示給使用者。
了解了這兩種不同的web服務方式的基本原理，我們在接下來的兩節中分别對它們的實作細節進行詳細介紹，讓讀者更好地了解它們的特性及技術實作細節。
事先計算型web服務
這一節我們來講解推薦系統事先計算型web服務的架構實作與基本原理(參見下面圖3)。這種方式可能是業界比較多地采用的一種推薦web服務架構實作方式，作者所在公司的所有推薦服務基本都是采用的該模式。
圖3：事先計算型web服務架構(綠色虛線框中的子產品即是圖2中的紅色子產品的細化)
該模式最大的特點是事先将每個使用者的推薦結果計算出來，存到資料庫(一般是NoSQL，如Redis、CouchBase等NoSQL資料庫，采用key-value的方式存儲，key就是使用者id，value就是給使用者的推薦結果，如果是用Redis存，value的資料結構可以使Sorted Sets，這種資料結構比較适合推薦系統，Sorted Sets中的element可以是推薦的标的物id，score是标的物的預測評分或者預測機率值等，還可以根據Sorted Sets中的score進行分頁篩選等操作)中，當有使用者請求時，前端通路web接口伺服器(前端會帶上使用者的唯一識别id進行HTTP請求，這樣就知道是哪個使用者，友善找到該使用者的推薦結果)，web伺服器從推薦結果庫中擷取該使用者的推薦結果(推薦結果一般隻存儲給使用者推薦的标的物id清單及部分需要的其他資訊，比如算法辨別，友善後面做AB測試。
下面圖4就是一種推薦結果存儲的資料格式，其中id就是标的物的唯一識别id)，同時還需要通路标的物metadata資料庫(一般存放在關系型資料庫中)，将前端展示需要的其他資訊(如标的物的名稱、價格、縮略圖等)拼接完整，最終以json的形式(下面圖5就是視訊推薦系統最終拼接好的json格式，網際網路企業一般采用的資料互動協定，也可以是其他協定，Google内部就采用protobuf協定)傳回給前端展示給使用者。
圖4：推薦結果存儲的資料結構(json形式存儲)
圖5：最終傳回給使用者的推薦結果(json格式)
該架構既可以支援T+1推薦模式和實時推薦模式，對于T+1型推薦産品形态，每天為使用者生成一次推薦結果，生成推薦結果時直接替換昨天的推薦結果就可以了。而對于實時推薦，情況會複雜一些，實時推薦可能會調整使用者的推薦結果(而不是完全替換)，對使用者推薦結果進行增删形成新的推薦結果，這時可行的方法有兩個。
一是從推薦結果存儲資料庫中讀出該使用者的推薦結果，按照實時推薦算法邏輯對推薦結果進行修改，再将推薦結果存進去替換掉，另外一種做法是，增加一個中間的鏡像存儲(可以采用HBase等，現在業界很多推薦算法都基于Hadoop/Spark平台實作，用大資料生态系的HBase是比較好的選擇)，所有的算法邏輯修改隻對鏡像存儲進行操作，操作完成後，将鏡像存儲中修改後的推薦結果同步到最終的推薦庫中，這跟T+1更新就保持一緻了，隻不過現在是實時推薦，同一個使用者可能一天會更新多次推薦結果。作者公司的短視訊實時推薦更新就是采用後面的這種方案，感興趣的讀者可以參考《基于标簽的實時短視訊推薦系統》這篇文章第三節1中的介紹。
實時裝配型web服務
本節我們來講解實時裝配型web服務的實作原理與架構(參考下面圖6)。這種方式事先不計算使用者的推薦結果，當有使用者請求時，web接口伺服器從特征資料庫(一般也是存放在Redis、HBase這種非關系型資料庫中)中将該使用者需要的特征取出來，并将特征灌入推薦模型，獲得該使用者的推薦結果，跟事先計算型一樣，還需要加載推薦标的物的metadata資訊，拼接成完整的推薦結果，并傳回給前端展示給使用者。
圖6：實時裝配型web服務架構(web接口服務加載推薦模型)
該web服務架構需要将推薦模型加載到web接口服務中，可以實時基于使用者特征獲得推薦結果，這就要求推薦模型可以在極短的時間(毫秒級)内獲得推薦結果，計算一定要快，否則會影響使用者體驗。當然另外一種可行的方案是，将推薦模型做成獨立的web模型服務，web接口服務通過HTTP或者RPC通路模型服務獲得推薦結果。具體架構如下面圖7，這種方式的好處是推薦模型服務跟web服務解耦，可以分别獨立更新模型服務和推薦接口服務，互相之間不會影響，隻要保證它們之間資料互動的協定不變就可以了。
圖7：通過推薦模型服務來擷取推薦結果的實時裝配型web服務架構
實時裝配型架構在實際提供推薦服務時就與具體的推薦範式是T+1推薦還是實時推薦沒有關系了，因為在任何時候web接口服務都是臨時調用推薦模型為使用者生成推薦結果，隻不過T+1推薦的模型可以一天訓練一次，而實時推薦的模型是實時訓練的(使用者的每一次操作行為都會産生日志，通過實時日志處理，生成實時特征，灌入實時模型訓練流程中，最終完成對模型的實時訓練，讓實時模型得到更新)。
業界流行的TensorFlow Serving就是一種實時裝配型服務架構，它提供web服務的架構模式類似上面圖6的形式，下面對其進行簡單介紹，讓讀者更好地了解這種模式。讀者可以檢視參考資料1、2、3對TensorFlow Serving進行更深入的了解。
TensorFlow Serving是一個靈活的、高性能的機器學習模型線上服務架構，設計用于生産系統，可以與訓練好的TensorFlow模型高效整合，将訓練好的模型部署到線上，使用gRPC作為接口接受外部調用。TensorFlow Serving支援模型熱更新與自動模型版本管理。
下圖為TensorFlow Serving整個架構圖。Client端會不斷給Manager發送請求，Manager會根據版本管理政策管理模型更新，并将最新的模型計算結果傳回給Client端。
圖8：TensorFlow Serving架構，圖檔來源于TensorFlow Serving官方文檔
FaceBook開源的FAISS(見參考資料4)架構也是業界用的比較多的一款用于實時裝配型web服務的架構。FAISS包含幾種相似性搜尋方法，它假設使用者或者标的物被表示為向量并由整數辨別(使用者和标的物用整數來唯一辨別，即使用者id和标的物id)，可以在海量向量庫中搜尋出按照某種相似性計算的最相似的向量清單。FAISS提供了向量之間計算L2（歐幾裡德）距離或點積距離的方法，與查詢向量最相似的向量是那些與查詢向量具有最小L2距離或最大點積的向量。FAISS具備在極短的時間(毫秒級)内計算某個向量最相似的一組向量的能力。它還支援cosine餘弦相似性查詢，因為cosine餘弦隻不過是向量内積的歸一化。
FAISS之是以能夠用于推薦系統提供實時推薦服務，主要是因為很多推薦算法最終将使用者和标的物都表示為向量，通過使用者向量與标的物向量的内積來衡量使用者對标的物的偏好程度，典型的矩陣分解算法就是這種形式。FAISS所起的作用相當于圖7中的推薦模型服務，利用它進行推薦的web服務架構就是圖7這種架構。最終的推薦模型用數學公式表示就是
是内積計算，u、v分别是使用者和标的物标向量，它們之間的内積表示使用者對标的物的偏好程度。FAISS提供計算使用者最相似的标的物的能力，并基于該相似度降序排列，取TopN最相似的标的物作為最終的推薦結果。
兩種web服務方式的優劣對比
前面兩節已經對推薦系統兩種提供web服務方案的技術細節進行了詳細介紹，在真實業務場景中可能比這個更複雜，可能不是單純的某種方案，會有一些變體，在這兩種方案的基礎上做适當調整與變化，可能同一産品的不同推薦形态采用不同的方式，同一種推薦方案也可能會融合這兩種方式。
在這一節我們對比一下這兩個方案的優缺點，讓大家更好地了解這兩種web服務方案，同時也為大家在具體推薦業務中進行選擇提供參考。
1.事先計算型web服務的優缺點
事先計算型最大的優勢是提前将推薦結果準備好了，這樣在提供推薦服務時可以直接擷取推薦結果，是以大大提升了接口服務的響應速度，減少了響應時間，對使用者體驗是有極大幫助的。另外，事先計算好了，當模型出現問題(比如排程模型計算的服務挂了)，最壞的情況是不更新推薦結果(這時無法插入最新推薦結果)，使用者通路時還是可以獲得推薦的，隻不過給使用者的是過去一天的推薦結果。如果是實時計算推薦結果(實時裝配型)，當模型出現問題時就無法獲得推薦結果，如果接口沒做保護，這時接口可能會挂掉，導緻前端出現無法展示任何推薦結果的故障，出現開天窗現象(不過好的推薦系統web服務一般會增加保護，在這種極端情況下，給定一組預設資料作為推薦結果，預設推薦是提前緩存在前端的，不受短期網絡故障影響)，是以，有更好的魯棒性。
事先計算型另一個優點是架構更加簡單，web接口服務跟生成推薦過程解耦，可以分别對web接口和推薦結果計算優化更新，而不會互相影響。
事先計算型最大的缺點是，由于要事先為每個使用者生成推薦，實際上很多使用者不是每天都通路的，真正日活使用者占總活躍使用者(比如月活使用者)的比例是很低的(當然像微信這類國民級APP除外)，推薦子產品通路使用者數一般也遠小于當天日活數，這就浪費了很多計算和存儲資源，特别是有海量使用者的APP，這時有大量的使用者沒有登入反而需要每天為其計算推薦結果，這時浪費是非常明顯的。
事先計算型另外一個缺點是，事先計算好了，這就失去了靈活性，要調整修改使用者的推薦結果成本代價更高(資訊流推薦等實時推薦産品是需要對推薦結果進行近實時調整的)。就像前面的案例講的，套餐做好了，沒法滿足使用者特定的口味了，比如使用者想要重辣，那也沒辦法了。
2.實時裝配型web服務的優缺點
實時裝配型跟事先計算型基本是對稱的，事先計算型的優點是它的缺點，事先計算型的缺點反而是它的優點。
實時裝配型需要臨時為使用者生成推薦結果，是以web接口服務需要多做一步處理，對接口性能有一定負面影響。另外，當推薦模型需要更新調整或者模型服務出現問題時(實時裝配型另一種實作方案是推薦模型作為一個獨立web服務)，會有短暫時間的不可用，這時會導緻推薦web接口無法計算出推薦結果，進而無法給前端提供回報資訊。這兩種情況都會影響使用者體驗(當然做得好的系統會有熱更新，模型更新不會導緻無法響應的情況出現，TensorFlow Serving就具備這種能力)。
實時裝備型的架構也更加複雜，耦合度更高(在推薦web接口整合了推薦模型這種實時裝配型中，推薦web接口跟推薦結果計算是完全耦合在一起的，參見圖6)。
實時裝配型由于是實時為使用者計算推薦結果，是以相比事先計算型不會占用太多的存儲、計算資源，對于節省費用是有極大幫助的，特别是在海量使用者場景下，這種節省更加明顯。它的另一個優點是對推薦結果調整空間大，因為是臨時計算，可以在計算過程中增加一些場景化的處理邏輯，對推薦算法有更好的幹預能力，更加适合實時推薦場景。
上面介紹完了這兩種方案的優缺點，我們用一個表格整理一下，友善對比檢視它們之間的異同點。
表1：事先計算型和實時裝配型的優缺點對比六、影響web服務方案的因素及選擇原則
影響web服務方案的因素及選擇原則
在上一節中，我們對兩種推薦web方案的優缺點進行了對比介紹，每種方案都有各自的優缺點，沒有哪一個方案是完全勝于另一個方案的。那麼在實際業務落地時，有哪些因素是會影響我們選擇具體的方案呢？我們應該怎樣選擇？有什麼判斷依據和準則嗎？在這一節中我們試圖從多個角度來回答這些問題。
1.推薦産品形态的實效性對推薦web服務選擇的影響
如果推薦産品形态是T+1型推薦，由于每天隻更新一次推薦結果，可以選擇事先計算型先将推薦結果計算出來。如果産品形态是實時資訊流推薦，需要整合使用者的實時興趣變化，使用者的每一次行為都會觸發更新推薦結果，這時采用臨時裝配型是更好的選擇。當然這也不是絕對的，作者所在公司的短視訊資訊流推薦，就采用的事先計算型，事先計算型也可以做到近實時更新使用者推薦結果，前面已經提到，對實作細節感興趣的讀者可以參考《基于标簽的實時短視訊推薦系統》這篇文章。
2.團隊架構能力、工程實作能力對推薦web服務選擇的影響
實時裝配型架構相對複雜，耦合度相對更高，在推薦時需要處理的邏輯更多，是以各個子子產品都需要相當穩定，并且需要具備較高的性能，是以對整個推薦軟體系統的要求更高。是以，如果推薦團隊架構能力強，人力比較充足的情況下可以選擇實時裝配型方案。
為了更好地整合使用者的實時行為，為使用者提供可見即所得的推薦服務，很多資訊流推薦需要對推薦算法進行實時訓練，比如Google在2013年推廣的FTRL算法就是對logistic在實時推薦場景下的工程實作，具備更高的工程實作難度，是以，對推薦團隊的工程實作能力是有較高要求的。實時裝配型一般需要處理使用者的實時行為日志，用于挖掘使用者實時興趣，建構實時模型，這就要求整個系統有更高的實時性，需要一套完善的實時處理架構體系的支撐， 這也增加了建構這類系統的複雜性。
前面也提到實時計算型一般需要有一套類似FAISS這樣的實時比對庫，為使用者在極短的時間内搜尋到最喜歡的标的物。而搭建這樣一套系統，需要将推薦模型做成獨立的服務，并且保證推薦模型web服務具備穩定性、高并發能力、可拓展性等能力，這也對架構能力有極高要求。如果希望采用容器等新技術來更好地管理推薦模型服務，這也需要新的學習成本和運維成本。
3.推薦階段對推薦web服務選擇的影響
我們知道企業級推薦系統生成推薦結果的過程一般分為召回和排序兩個階段(參考《推薦系統産品與算法概述》這篇文章第一節的介紹)，先使用召回推薦算法從海量标的物中篩選出一組(一般幾百上千個)使用者可能感興趣的标的物，然後在排序階段利用更加精細化的推薦算法對結果進行重排序。
由于召回是從所有标的物中篩選使用者可能感興趣的，當标的物數量龐大時(比如今日頭條有千億級文本、淘寶有上億級商品)，即使召回算法簡單，計算量也是非常大的，一般可以采用事先計算型召回政策(為了整合使用者最近的行為，也可以基于使用者的興趣标簽或者使用者最近浏覽的标的物進行近實時召回，這類召回政策也屬于事先計算型，比如根據使用者最近浏覽的标的物召回相似的标的物，每個标的物相似标的物是事先計算好的)。而對于排序推薦算法，隻需要從有限的(成百上千)的标的物中過濾出使用者最喜歡的幾十個，可以在較短時間内計算完，是以排序算法可以采用實時裝配型政策。
當然，排序階段也是可以采用事先計算型的，這就相當于先召回，再排序将推薦結果計算好，隻不過整個推薦過程将事先計算拆解為召回和排序兩個階段來進行了。
其實，直接跟推薦接口銜接的是排序階段，召回階段是不直接參與web服務的，是以根據第二節的定義，嚴格意義上事先計算型、實時裝配型是不能用于描述召回階段的。不過有些産品的标的物數量不大(比如電影隻有幾萬個)，也可以将召回排序融合為一個階段，隻用一個算法就可以獲得推薦結果，或者排序可以采用簡單的規則和政策，這時排序邏輯可以整合到推薦web接口中，這兩種情況召回階段所起的作用就相當于排序階段的作用了，這時可以說召回直接跟web接口進行了互動，是以也可以用事先計算型、實時裝配型來描述召回階段。
4.算法形态對推薦web服務選擇的影響
推薦算法種類繁多，從簡單的KNN、item-based協同過濾到複雜的深度學習、強化學習推薦算法，不同的算法實作方式、需要的資料來源、計算複雜度等都不一樣。這也導緻了算法的使用場景不一樣。
像深層深度學習這種模型結構非常複雜的推薦算法，即使為單個标的物打分(即計算出使用者對标的物的偏好度)，計算時間也是簡單算法的若幹倍，這時在短時間内(比如100毫秒之内)為大量的标的物打分是不現實的，是以這類算法一般用于排序階段(排序階段隻對成百上千的标的物打分)，是以比較适合實時裝配性的政策。
簡單的推薦算法，如item-based協同過濾、矩陣分解，由于計算複雜度低，一般用于召回階段，是以是比較适合事先計算型的。
總結
本文講解了推薦系統提供web服務的兩種主要方式，一種是事先計算型，提前将使用者的推薦結果計算出來并存放到NoSQL中，當使用者使用推薦子產品時，推薦web服務直接将該使用者的推薦結果取出來并組裝成合适的資料結構最終在前端展示給使用者，另一種是實時裝配型，我們需要将計算推薦結果需要的原材料準備成“半成品”(就是各種特征)，将這些中間結果事先存起來，當使用者使用推薦服務時，推薦web服務通過簡單的組裝與計算(調用封裝好的推薦模型)，将“半成品”加工成該使用者的推薦結果，并最終給到使用者。
這兩種提供web服務的推薦方案各有優缺點，我們需要根據公司現在的技術儲備、人員能力、團隊規模、産品形态等多個次元進行評估和選擇。不管采用哪種方式，最終的目的是一樣的，我們需要為使用者提供個性化的、響應及時的優質推薦服務。
參考資料
- [基于TensorFlow Serving的深度學習線上預估] https://zhuanlan.zhihu.com/p/46591057
- [手把手教你使用TF服務将TensorFlow模型部署到生産環境] https://zhuanlan.zhihu.com/p/60542828
- https://www.tensorflow.org/serving
- https://github.com/facebookresearch/faiss
【end】