建站
咨詢
售后
建站咨詢
新聞中心
微信掃一掃識物是典型的“離線寫，在線讀”的業(yè)務(wù)，業(yè)務(wù)數(shù)據(jù)的存儲(chǔ)和檢索庫的構(gòu)建都是在離線環(huán)節(jié)完成。我們通過爬蟲系統(tǒng)收錄了小程序生態(tài)下的商品圖片，下載后進(jìn)行檢測摳圖，提取檢索特征，最終構(gòu)建成檢索庫交付到線上環(huán)境。這篇文章將主要介紹這一部分的工作。
創(chuàng)新互聯(lián)公司是一家集網(wǎng)站建設(shè),柳北企業(yè)網(wǎng)站建設(shè),柳北品牌網(wǎng)站建設(shè),網(wǎng)站定制,柳北網(wǎng)站建設(shè)報(bào)價(jià),網(wǎng)絡(luò)營銷,網(wǎng)絡(luò)優(yōu)化,柳北網(wǎng)站推廣為一體的創(chuàng)新建站企業(yè)，幫助傳統(tǒng)企業(yè)提升企業(yè)形象加強(qiáng)企業(yè)競爭力?？沙浞譂M足這一群體相比中小企業(yè)更為豐富、高端、多元的互聯(lián)網(wǎng)需求。同時(shí)我們時(shí)刻保持專業(yè)、時(shí)尚、前沿，時(shí)刻以成就客戶成長自我，堅(jiān)持不斷學(xué)習(xí)、思考、沉淀、凈化自己，讓我們?yōu)楦嗟钠髽I(yè)打造出實(shí)用型網(wǎng)站。
0 什么是識物
識物是以圖像或視頻作為輸入，用以挖掘微信生態(tài)下商品、物品等有價(jià)值等信息。這里我們基本覆蓋了微信全量優(yōu)質(zhì)小程序電商，涵蓋上億商品 SKU，聚合了微信內(nèi)的搜一搜、搜狗等資訊，最終聚合后呈現(xiàn)給用戶。百度識圖和阿里拍立淘也是基于該技術(shù)發(fā)展而來。
工程上，識物工作主要可以分為三塊，如圖 1 所示：
圖1
1.算法模型
算法側(cè)主要是對檢測模型和多類目的檢索模型等持續(xù)煉丹，檢測模型需要返回圖片中物品的準(zhǔn)確位置;檢索模型需要保證同款物品的特征表達(dá)越近越好。
2.離線工程
識物是典型的“離線寫，在線讀”的業(yè)務(wù)，業(yè)務(wù)數(shù)據(jù)的存儲(chǔ)和檢索庫的構(gòu)建都是在離線環(huán)節(jié)完成。我們通過爬蟲系統(tǒng)收錄了小程序生態(tài)下的商品圖片，下載后進(jìn)行檢測摳圖，提取檢索特征，最終構(gòu)建成檢索庫 交付到線上環(huán)境。這篇文章將主要介紹這一部分的工作。
3.在線部署
算法模型和離線生成的檢索庫最終完成部署，對外服務(wù)。用戶識物時(shí)，檢索庫會(huì)召回一批相似物品，再經(jīng)過一系列復(fù)雜的精排、過濾邏輯，最終返回用戶看到的結(jié)果。
1 挑戰(zhàn)
1. 數(shù)據(jù)版本
數(shù)據(jù)版本主要分為兩類，一是算法模型版本，我們有 10+種業(yè)務(wù)模型，平均每周有 2-3 個(gè)模型迭代升級。二是檢索庫版本，在模型不迭代的情況下，每天有新數(shù)據(jù)的合并，即增量迭代;而每次算法模型變更，特征表達(dá)發(fā)生改變，需要根據(jù)新特征重新構(gòu)建檢索庫，即全量迭代。
在高頻的版本變更場景下，如何兼顧靈活性與安全性。
2. 數(shù)據(jù)處理性能
目前我們收錄的圖片數(shù)為 10 億左右，平均每天新增 1500w。除了圖片數(shù)量多，任務(wù)的流程也很多，如圖片下載、目標(biāo)檢測、特征提取等任務(wù)，每個(gè)任務(wù)每天都是千萬級的數(shù)據(jù)處理量。
如何高效的處理數(shù)據(jù)，提升業(yè)務(wù)的迭代效率。
3. 繁雜的流程
隨著業(yè)務(wù)的發(fā)展，簡單的業(yè)務(wù)流程已經(jīng)不能滿足我們?nèi)找鎻?fù)雜的業(yè)務(wù)需求。為了提升業(yè)務(wù)指標(biāo)，我們可能還需要圖片質(zhì)量，文本語義，死鏈、下架商品的過濾等任務(wù)。
如何在流程日益變多的情況下，不導(dǎo)致整個(gè)系統(tǒng)的臃腫。
4. 數(shù)據(jù)質(zhì)量
離線工程屬于重流程的業(yè)務(wù)，數(shù)據(jù)從產(chǎn)生和落地將經(jīng)歷九九八十一環(huán)，任何一環(huán)出錯(cuò)都會(huì)導(dǎo)致結(jié)果有問題。發(fā)現(xiàn)問題的時(shí)間越晚，修復(fù)的成本越高，對業(yè)務(wù)的影響越難以估計(jì)。
如何科學(xué)的監(jiān)控和管理數(shù)據(jù)質(zhì)量，使系統(tǒng)有良好的可維護(hù)性。
2 數(shù)據(jù)版本
這里有多種維度的數(shù)據(jù)版本，例如模型版本，特征版本，檢索庫版本等，上游環(huán)節(jié)的版本變更將引發(fā)后續(xù)環(huán)節(jié)的變更，最終都將導(dǎo)致檢索庫版本變更。
圖2 數(shù)據(jù)流程簡圖
2.1 檢索庫
在我們的業(yè)務(wù)場景下，檢索庫的迭代是高頻操作，正常情況下每天會(huì)增量更新，而模型的變更又會(huì)引發(fā)檢索庫全量更新。數(shù)據(jù)量級上，我們的全量圖像是億級別的，按類目分庫后每個(gè)類目也是千萬級。
我們調(diào)研了業(yè)界內(nèi)主要用于圖像檢索的技術(shù)，如圖 3 所示。綜合考慮后，我們選取了靈活性更強(qiáng)、相對內(nèi)存占用更小的的 faiss-ivf 作為我們的索引庫構(gòu)建算法。
圖3 圖像檢索庫選型
對于每天的增量數(shù)據(jù)，我們每天對每個(gè)類目(10+個(gè)類目)都會(huì)構(gòu)造一個(gè)對應(yīng)當(dāng)天數(shù)據(jù)檢索庫。每個(gè)類目的全量檢索庫是由N 天的檢索庫合并生成(faiss-ivf 特性)，2000w 的數(shù)據(jù)合并僅需要 4 分鐘?；谶@樣的設(shè)計(jì)，使得我們可以靈活的選取時(shí)間窗口的范圍，如圖 3 所示了窗口為 2 的合并方法。
這樣的好處是，如果某天數(shù)據(jù)發(fā)現(xiàn)有問題，只需要修復(fù)當(dāng)天數(shù)據(jù)后再進(jìn)行合并即可;如果需要丟棄某些數(shù)據(jù)，如舊數(shù)據(jù)，合并時(shí)不選取即可。
圖4 檢索庫生成
2.2 數(shù)據(jù)版本兼容
前面我們講到，模型變更最終都將引發(fā)檢索庫的全量迭代，這里的模型有檢測模型和檢索特征模型。新檢索庫上線時(shí)，本質(zhì)上是新舊數(shù)據(jù)的過渡，一般實(shí)現(xiàn)新舊數(shù)據(jù)的切換都會(huì)設(shè)計(jì)復(fù)雜的系統(tǒng)來保證數(shù)據(jù)一致性。
2.2.1 檢測模型變更
這種場景下的檢索庫變更，嚴(yán)格上來講我們并沒有實(shí)現(xiàn)新舊數(shù)據(jù)的一致性，我們只是通過簡單的方法使得即使新舊數(shù)據(jù)同時(shí)存在也不影響用戶的體驗(yàn)。
這里主要涉及到如何構(gòu)建我們的映射關(guān)系，我們?yōu)槊看螜z測出的結(jié)果都賦予一個(gè)唯一的單調(diào)遞增 id。替換模型后，同一張圖片的檢測結(jié)果會(huì)變化?？赡軗笀D的位置有變化、可能會(huì)扣取不同的物品、可能會(huì)扣取多個(gè)物品。
如圖 5 所示，檢索庫 v1 里只有上衣，對應(yīng)檢索 id 為 1;變更檢測模型后，檢索庫 v2 可以同時(shí)檢測出上衣和下衣，對應(yīng)檢索 id 為 2，3。這樣在線模塊可以逐步更新檢索庫，線上同時(shí)存在新舊檢索庫也沒有影響，如果請求落到舊庫返回 1，落到新庫返回 2，但最終都將返回正確的結(jié)果，結(jié)果上是一致的。
圖5 檢測模型變更
2.2.2 檢索特征模型變更
這種場景下的檢索庫變更則復(fù)雜許多，檢索庫存的特征來自于檢索特征模型。檢索模型變更后，同一個(gè)物品圖片的特征表達(dá)完全不同，維度甚至也發(fā)生了變化，如圖 6 所示。
我們需要同步變更檢索特征模型服務(wù)和新檢索庫，通過雙 buffer 的方式實(shí)現(xiàn)新舊數(shù)據(jù)的共存，而且要實(shí)現(xiàn)嚴(yán)格的路由協(xié)議來保證同一個(gè)請求在同版本的特征檢索服務(wù)和檢索庫中完成。
圖6 檢索特征模型變更
2.3 數(shù)據(jù)版本管理系統(tǒng)
在開發(fā)過程中，算法需要交付各種模型給離線和在線，離線生成的檢索庫也需要交付給在線，數(shù)據(jù)版本的迭代也需要考慮版本的可回退性。為了解耦多方之間的依賴，且避免在同步過程中直接操作文件帶來的風(fēng)險(xiǎn)，設(shè)計(jì)了一套數(shù)據(jù)版本管理系統(tǒng)。
如圖 7 所示，資源發(fā)布者上傳資源到該系統(tǒng)，并附帶對應(yīng)業(yè)務(wù)、版本號及 md5。資源使用者只需要理解對應(yīng)業(yè)務(wù)當(dāng)前的版本號，版本管理系統(tǒng)會(huì)返回對應(yīng)的資源文件。線上實(shí)際使用時(shí)，在線模塊會(huì)定期輪訓(xùn)某業(yè)務(wù)對應(yīng)數(shù)據(jù)版本文件的 md5 和本地文件 md5 是否一致，不一致則會(huì)拉取最新的文件，拉取完成后校驗(yàn) md5 是否一致，最終實(shí)現(xiàn)更新。
在業(yè)務(wù)模型或檢索庫需要回退時(shí)，只需修改配置文件，重啟服務(wù)即可。
圖7 數(shù)據(jù)版本管理系統(tǒng)
2.4 Docker 化
目標(biāo)檢測、檢索特征提取等是典型的圖像深度學(xué)習(xí)任務(wù)，業(yè)界內(nèi)有 caffe、pytorch、tensorflow、tensorRT 等多種深度學(xué)習(xí)框架，有的框架不能保證向上兼容。而我們負(fù)責(zé)煉丹的同學(xué)第一要?jiǎng)?wù)是追求效果指標(biāo)，在嘗試各種奇淫巧技時(shí)練出來的丹通常并不能和微信的線上環(huán)境很好的兼容。
簡而言之，在重算法的工程系統(tǒng)中，不僅有業(yè)務(wù)代碼的更新，還有工程環(huán)境的迭代。這非常適合使用 docker 來封裝和迭代業(yè)務(wù)環(huán)境。通過 docker 化部署，我們可以更方便的引入更多開源組件來支撐業(yè)務(wù)，也可以讓我們在一些框架選型上更加靈活。
就我們自己的業(yè)務(wù)場景而言，我們還可以利用微信深度學(xué)習(xí)任務(wù)平臺(tái)(yard)的計(jì)算資源，這部分屬于公用資源，需要搶占式使用。yard 也是 docker 化去執(zhí)行任務(wù)。這為我們業(yè)務(wù)可以借助 yard 公用資源作為臨時(shí)擴(kuò)容 worker 節(jié)點(diǎn)做了很好的鋪墊。
3 分布式計(jì)算
我們每天平均有 1500w 增量數(shù)據(jù)，全量為十億級別的數(shù)據(jù)。單機(jī)必然無法滿足處理的實(shí)效性，唯有分布式計(jì)算才能滿足要求。
3.1 數(shù)據(jù)拆分
正如 mapreduce，map 階段的工作我們需要對數(shù)據(jù)進(jìn)行拆分。這里對拆分原則除了平均外，還考慮了拆分后到數(shù)據(jù)的運(yùn)行時(shí)間。如果拆分太細(xì) GPU 的運(yùn)行效率會(huì)降低，拆分太粗會(huì)導(dǎo)致錯(cuò)誤修復(fù)的時(shí)間成本變大。我們讓每個(gè)拆分后的任務(wù)都盡量控制在 1 小時(shí)內(nèi)完成，最終拆分的粒度為每個(gè)包 10w 左右。
3.2 數(shù)據(jù)并行計(jì)算
拆分后的數(shù)據(jù)進(jìn)行并行計(jì)算相當(dāng)于 reduce 階段，這里的重點(diǎn)是如何將拆分后的數(shù)據(jù)分發(fā)到多臺(tái)機(jī)進(jìn)行計(jì)算。此外，我們還希望公用資源空閑時(shí)可以非常靈活的進(jìn)行擴(kuò)容接入，提高并發(fā)處理能力。
我們結(jié)合 zookeeper 的分布式鎖特性，實(shí)現(xiàn)了一套可靠分布式任務(wù)隊(duì)列。worker 采用拉模式拉取隊(duì)列的任務(wù)。這樣的優(yōu)點(diǎn)是伸縮性好，可以靈活的增加和減少 yard 的機(jī)器資源。如圖 8，當(dāng)新 worker 接入后，從隊(duì)列中拉到任務(wù)直接執(zhí)行，可以實(shí)現(xiàn)秒級的擴(kuò)容。
圖8 伸縮性好
對于我們的場景，任務(wù)需要被可靠消費(fèi)，這里的可靠包含來兩層含義。
第一是避免任務(wù)被重復(fù)消費(fèi)，我們借助 zookeeper 的?；铈i，鎖通過心跳保持活性。如圖 9 中第 1，2 時(shí)刻，worker 拿到隊(duì)列里的任務(wù)搶鎖成功才可執(zhí)行;如果出現(xiàn)機(jī)器宕機(jī)，如圖 9 第三 3 時(shí)刻，鎖會(huì)自動(dòng)釋放。
第二是完整消費(fèi)，我們在 task 被完全消費(fèi)結(jié)束后才刪掉隊(duì)列里的對應(yīng) task，如時(shí)刻 4 的 task2。時(shí)刻 3 由于機(jī)器宕機(jī)，task1 并未被完整消費(fèi)，因此依舊存在，后續(xù)可被繼續(xù)消費(fèi)。
圖9 可靠消費(fèi)
理論上講，我們的消費(fèi)模式屬于至少一次消費(fèi)(at least once)，極端情況下，如果 worker 執(zhí)行完任務(wù)還沒有回傳狀態(tài)時(shí)宕機(jī)，那任務(wù)仍處于未成功消費(fèi)，仍可能被后續(xù) worker 消費(fèi)。這里需要保證任務(wù)的冪等性。
引入公用計(jì)算資源提升了我們的處理能力，但同時(shí)也給我們帶來了一些小問題。例如，公用集群的機(jī)器配置比我們自己集群要好很多，為了使不同集群都能發(fā)揮最大的 GPU 性能，我們支持不同集群使用不同的全局參數(shù)配置。而且公用集群和文件系統(tǒng)不在同一個(gè) idc，導(dǎo)致網(wǎng)絡(luò) IO 時(shí)間過長，降低了 GPU 利用時(shí)間，我們在公用集群的同 idc 實(shí)現(xiàn)了一套文件預(yù)拉取系統(tǒng)，根據(jù)任務(wù)隊(duì)列中存在的任務(wù)，提前同步待消費(fèi)文件到同 idc 的文件緩存系統(tǒng)。
為了提高 GPU 利用率，我們還做了大量的工程優(yōu)化，這里就不展開敘述了?；诜植际接?jì)算的框架，極大提升了我們的計(jì)算效率。拿計(jì)算效率最低的目標(biāo)檢測任務(wù)舉例，目前我們集群的處理能力可達(dá)到 5600w 圖/天，如果加上公用計(jì)算資源，可以達(dá)到 1.2 億圖/天(集群 12 臺(tái) P4 雙卡，公用集群 yard-g7a 集群平均 10 個(gè)雙卡，深度學(xué)習(xí)框架使用的 tensorRT)。
4 任務(wù)調(diào)度
雖然我們每天有 1500w 左右的原始圖片，但最終符合錄入檢索庫的商品僅有一半不到。因?yàn)闉榱舜_保檢索數(shù)據(jù)的質(zhì)量，我們會(huì)在多個(gè)維度做數(shù)據(jù)過濾?，F(xiàn)在我們的圖片從下載到建庫一共會(huì)經(jīng)歷 30+種中間任務(wù)，圖 10 僅展示了主要的任務(wù)流程模型。
圖10 任務(wù)流
4.1 任務(wù)系統(tǒng)
隨著任務(wù)的增多，尤其是許多任務(wù)間存在著復(fù)雜的依賴關(guān)系，每個(gè)任務(wù)都不是一個(gè)獨(dú)立的個(gè)體，每個(gè)任務(wù)的成敗都將影響最終的結(jié)果。為了更好的管理每個(gè)任務(wù)的狀態(tài)，梳理任務(wù)間的依賴，使得工程的復(fù)雜度不隨任務(wù)變多而變大，我們自研了一套任務(wù)調(diào)度系統(tǒng)。
調(diào)度系統(tǒng)主要由以下幾個(gè)部分組成：
- 文件系統(tǒng)：文件系統(tǒng)這里使用了微信自研分布式文件存儲(chǔ)系統(tǒng)的 WFS，我們所有中間數(shù)據(jù)和結(jié)果數(shù)據(jù)都存放在這里
- 存儲(chǔ)系統(tǒng)：主要有任務(wù)存儲(chǔ)和實(shí)例存儲(chǔ)，與一般實(shí)例存儲(chǔ)不同的是，為了分布式計(jì)算，我們在數(shù)據(jù)維度和類目維度做了拆分，一個(gè)實(shí)例包含一個(gè)或多個(gè)子實(shí)例
- 調(diào)度系統(tǒng)：主要負(fù)責(zé)收集、管理任務(wù)狀態(tài)，檢查任務(wù)依賴
- 觸發(fā)器：定時(shí)輪訓(xùn)調(diào)度系統(tǒng)，找到滿足執(zhí)行條件的任務(wù)實(shí)例
- 任務(wù)隊(duì)列：存儲(chǔ)待執(zhí)行的任務(wù)實(shí)例，由 worker 獲取依次消費(fèi)
圖11 任務(wù)調(diào)度系統(tǒng)
容災(zāi)性上，調(diào)度系統(tǒng)相關(guān)的模塊均是多機(jī)多園區(qū)部署，只要不是某個(gè)模塊完全掛掉，整套任務(wù)調(diào)度都可以正常執(zhí)行。
4.2 在線服務(wù)合并部署
對于每天的例行任務(wù)，實(shí)效性并不敏感，早幾個(gè)小時(shí)或晚幾個(gè)小時(shí)對業(yè)務(wù)影響不大。但 GPU 資源是是十分寶貴的，我們將部分 GPU 機(jī)器和在線 GPU 服務(wù)合并部署。結(jié)合在線流量屏蔽策略，實(shí)現(xiàn)高峰時(shí)期資源借給在線服務(wù)，低峰時(shí)期運(yùn)行離線任務(wù)。
如圖 12 所示，其為一臺(tái)參與離線任務(wù)閑時(shí)調(diào)度的在線模塊，我們擬定每天 0 點(diǎn)-7 點(diǎn)的低峰時(shí)間為離線運(yùn)行時(shí)間，7 點(diǎn)-24 點(diǎn)的高峰時(shí)間為在線模塊服務(wù)時(shí)間。最大限度的利用了寶貴的機(jī)器資源。
圖12 分時(shí)調(diào)度運(yùn)行
5 數(shù)據(jù)質(zhì)量
前面做的工作保證了我們以任務(wù)為粒度的工程可靠性，但任務(wù)的成功并不能保證業(yè)務(wù)數(shù)據(jù)是完整的，如數(shù)據(jù)丟失、代碼邏輯有問題等。為了監(jiān)控?cái)?shù)據(jù)維度上的業(yè)務(wù)質(zhì)量，我們基于 ELK 搭建了一套數(shù)據(jù)系統(tǒng)，主要用于收集重要的基礎(chǔ)數(shù)據(jù)、業(yè)務(wù)數(shù)據(jù)、運(yùn)行結(jié)果等。
5.1 數(shù)據(jù)可視化
我們曾在幾次版本迭代過程中，發(fā)現(xiàn)數(shù)據(jù)出錯(cuò)，但發(fā)現(xiàn)時(shí)已經(jīng)付出了極高的時(shí)間代價(jià)。因此我們希望在任意時(shí)刻都能觀察離線系統(tǒng)的運(yùn)作是否正常，數(shù)據(jù)的流轉(zhuǎn)是否符合預(yù)期。出現(xiàn)問題后可以及時(shí)干預(yù)修正，降低錯(cuò)誤成本。
我們對涉及數(shù)據(jù)流轉(zhuǎn)的核心任務(wù)都做了數(shù)據(jù)結(jié)果上報(bào)，這樣子我們可以通過數(shù)據(jù)漏斗發(fā)現(xiàn)是否出現(xiàn)問題。這個(gè)問題在全量數(shù)據(jù)重跑的時(shí)候尤其重要。圖 13 展示了項(xiàng)目中核心任務(wù)的數(shù)據(jù)情況。
圖13 數(shù)據(jù)漏斗可視化
上圖看上去是每天任務(wù)級的數(shù)據(jù)監(jiān)控，但實(shí)際上我們我們的設(shè)計(jì)是擴(kuò)展到了每次任務(wù)級(這里定義為 planid)，既可以是每天，也可以是每次覆蓋多天的重跑。 我們按圖 14 的字段上報(bào)業(yè)務(wù)的運(yùn)行結(jié)果，前 4 個(gè)字段組成聯(lián)合唯一索引，planid 作為區(qū)分每次運(yùn)行的邏輯字段。這樣即使同一個(gè)任務(wù)在不同時(shí)期運(yùn)行結(jié)果是不同的，我們也能區(qū)分每一次運(yùn)行后，真實(shí)的數(shù)據(jù)結(jié)果。這個(gè)設(shè)計(jì)在保證每次大版本數(shù)據(jù)迭代時(shí)，對于把控?cái)?shù)據(jù)整體運(yùn)行質(zhì)量十分重要也十分有效。
圖14 上報(bào)字段
5.2 一致性檢查
數(shù)據(jù)可視化方便了我們檢查問題，但是還不利于我們發(fā)現(xiàn)問題。我們還需要在數(shù)據(jù)出問題時(shí)，能及時(shí)告警、迅速修復(fù)。這最最重要的就是數(shù)據(jù)一致性，這里的一致性主要是一些核心任務(wù)的數(shù)據(jù)漏斗，輸入和輸出應(yīng)該是一致的。圖 15 中展示了一些存在關(guān)聯(lián)的任務(wù)，帶顏色線段代表數(shù)據(jù)存在關(guān)聯(lián)性。
為了滿足各種維度的統(tǒng)計(jì)、校驗(yàn)，同時(shí)又能快速支持新任務(wù)的檢查。我們封裝了核心的統(tǒng)計(jì)和校驗(yàn)邏輯，配置化告警任務(wù)，確保層層流程運(yùn)轉(zhuǎn)后的結(jié)果準(zhǔn)確無誤。
圖15 一致性檢查
5.3 評測系統(tǒng)
我們在對我們的檢索庫做比較大的版本迭代，或是線上策略有比較大調(diào)整時(shí)，直接灰度上線再觀察曲線有時(shí)并不能及時(shí)發(fā)現(xiàn)問題，存在很大的隱患?；谶@種情況，我們開發(fā)了自動(dòng)化測試系統(tǒng)。我們提前收集和整理了部分帶標(biāo)簽的數(shù)據(jù)樣本，每次更新都需要在測試環(huán)境自動(dòng)化評測一次，如圖 16 所示。我們在結(jié)合具體指標(biāo)分析此次迭代是否可以安全上線(關(guān)鍵數(shù)據(jù)打碼)。
圖16 評測系統(tǒng)
5.4 數(shù)據(jù)淘汰
我們平均每天流入數(shù)據(jù)超過千萬，數(shù)據(jù)膨脹的速度非?？?，這給我們帶來了極大的存儲(chǔ)成本和迭代成本。但回顧業(yè)務(wù)本身，其實(shí)許多商品數(shù)據(jù)在隨著時(shí)間的推進(jìn)，將變成過期、死鏈、下架數(shù)據(jù)。最簡單的做法就是使用窗口期來維護(hù)我們的數(shù)據(jù)，窗口外的數(shù)據(jù)自動(dòng)淘汰，我們在 faiss 檢索庫選型時(shí)也是這樣考慮的。
但是我們也想到，直接暴力的淘汰舊數(shù)據(jù)也會(huì)有個(gè)致命問題。對于我們的業(yè)務(wù)而言，什么數(shù)據(jù)對我們是重要的，常見的熱門商品固然重要，但是相對冷門長尾商品同樣重要，后者決定來商品庫長尾的多樣性。如果刪掉某個(gè)商品，檢索庫可能就沒有這個(gè)商品了，這是十分糟糕的。
因此我們在做數(shù)據(jù)淘汰的時(shí)候，需要考慮對有價(jià)值的長尾商品做保留。 圖 17 展示了我們數(shù)據(jù)淘汰的方式，通過這種方式，我們窗口期內(nèi)的數(shù)據(jù)質(zhì)量將變得越來越高，全量數(shù)據(jù)的增長也相對可控。
圖17 窗口期為K的數(shù)據(jù)淘汰
6 總結(jié)
以上我們大致介紹了“掃一掃識物”的離線系統(tǒng)中的所涉及的一些關(guān)鍵點(diǎn)，部分模塊仍在持續(xù)優(yōu)化中。未來掃一掃識物將引入更多場景的識別，拓展更多維度的物品，追求“萬物皆可掃”的目標(biāo)。
當(dāng)前名稱：微信掃一掃識物的技術(shù)揭秘:摳圖與檢索
網(wǎng)站路徑：http://www.dlmjj.cn/article/cdeihcc.html
