別登錄實(shí)戰(zhàn)：從選型到上線(xiàn)的完整避坑指南)
人臉識(shí)別登錄這個(gè)功能我在兩三個(gè)項(xiàng)目里都落地過(guò)最早一版用的是本地訓(xùn)練的小模型識(shí)別率在實(shí)驗(yàn)室里看著還行一到真實(shí)場(chǎng)景就崩——光線(xiàn)稍暗、角度稍偏、戴個(gè)眼鏡就認(rèn)不出來(lái)。后來(lái)?yè)Q成調(diào)用云端的人臉識(shí)別能力整個(gè)開(kāi)發(fā)周期從兩周壓縮到兩天而且識(shí)別準(zhǔn)確率直接上了一個(gè)臺(tái)階。這篇內(nèi)容就圍繞“基于百度AI人工智能庫(kù)完成人臉識(shí)別登錄”這件事把我在實(shí)際開(kāi)發(fā)中踩過(guò)的坑、選型的邏輯、接口調(diào)用的細(xì)節(jié)、以及上線(xiàn)前必須處理的邊界情況完整地拆一遍。不管你是剛接觸人臉識(shí)別的新手還是已經(jīng)做過(guò)一版但效果不理想的開(kāi)發(fā)者都能從里面找到可以直接復(fù)用的東西。1. 為什么登錄環(huán)節(jié)要引入人臉識(shí)別而不是繼續(xù)用密碼1.1 密碼登錄的體驗(yàn)瓶頸到底在哪里先說(shuō)一個(gè)我觀察到的現(xiàn)象大部分用戶(hù)在同一款A(yù)pp里設(shè)置的密碼和他們?cè)谄渌胤接玫拿艽a高度重合。這不是用戶(hù)懶而是記憶成本決定的。一個(gè)普通用戶(hù)手機(jī)上裝著幾十個(gè)應(yīng)用如果每個(gè)都設(shè)獨(dú)立密碼根本記不住。所以密碼登錄這件事從體驗(yàn)層面看它天然帶著兩個(gè)硬傷——輸入成本高和記憶負(fù)擔(dān)重。輸入成本高體現(xiàn)在哪移動(dòng)端上打一串包含大小寫(xiě)字母、數(shù)字、符號(hào)的密碼平均耗時(shí)在8到12秒之間如果密碼復(fù)雜度要求高用戶(hù)輸錯(cuò)的概率會(huì)顯著上升。我做過(guò)一個(gè)粗略統(tǒng)計(jì)在一個(gè)日活幾千的小型應(yīng)用里密碼登錄的首次輸入成功率大概在七成左右剩下三成用戶(hù)至少需要重試一次。這個(gè)數(shù)據(jù)意味著什么意味著每十個(gè)想登錄的用戶(hù)里有三個(gè)在登錄環(huán)節(jié)就被卡了一下體驗(yàn)上的摩擦感非常明顯。記憶負(fù)擔(dān)重則更隱蔽。用戶(hù)為了省事往往會(huì)選擇“記住密碼”或者用系統(tǒng)級(jí)的密碼管理器。這看起來(lái)解決了問(wèn)題但實(shí)際上把風(fēng)險(xiǎn)轉(zhuǎn)移了——一旦設(shè)備丟失或者密碼管理器被攻破所有賬號(hào)都暴露。而且很多用戶(hù)在不同平臺(tái)復(fù)用同一套密碼一個(gè)平臺(tái)泄露其他平臺(tái)跟著遭殃。這不是危言聳聽(tīng)而是安全領(lǐng)域反復(fù)驗(yàn)證過(guò)的規(guī)律。人臉識(shí)別登錄切入的正是這兩個(gè)痛點(diǎn)。它把“輸入密碼”這個(gè)動(dòng)作替換成“看一眼屏幕”耗時(shí)從十秒級(jí)降到一秒級(jí)而且不需要用戶(hù)記憶任何東西。從產(chǎn)品角度看這是登錄體驗(yàn)的一次質(zhì)變。1.2 人臉識(shí)別登錄適合什么場(chǎng)景不適合什么場(chǎng)景但人臉識(shí)別登錄不是萬(wàn)能藥它有明確的適用邊界。我在選型階段就吃過(guò)虧一開(kāi)始想在所有登錄入口都上人臉后來(lái)發(fā)現(xiàn)有些場(chǎng)景根本不合適。適合的場(chǎng)景有這么幾類(lèi)第一類(lèi)是移動(dòng)端App的常規(guī)登錄用戶(hù)手持設(shè)備、光線(xiàn)相對(duì)可控、攝像頭素質(zhì)普遍不錯(cuò)這種場(chǎng)景下人臉識(shí)別的通過(guò)率和體驗(yàn)都很好。第二類(lèi)是需要快速切換賬號(hào)的場(chǎng)景比如一些工具類(lèi)應(yīng)用用戶(hù)可能在工作賬號(hào)和個(gè)人賬號(hào)之間來(lái)回切人臉識(shí)別比輸密碼快得多。第三類(lèi)是作為二次驗(yàn)證手段在密碼登錄之后加一道人臉核驗(yàn)提升安全等級(jí)。不適合的場(chǎng)景也很明確第一類(lèi)是公共設(shè)備上的登錄比如共享終端、公共查詢(xún)機(jī)這些設(shè)備攝像頭角度固定、光線(xiàn)復(fù)雜而且用戶(hù)對(duì)在公共設(shè)備上刷臉有心理抵觸。第二類(lèi)是光線(xiàn)極差或者用戶(hù)戴口罩、帽子遮擋嚴(yán)重的情況雖然現(xiàn)在很多算法支持口罩識(shí)別但通過(guò)率會(huì)打折扣如果業(yè)務(wù)對(duì)登錄成功率要求極高就要慎重。第三類(lèi)是用戶(hù)群體對(duì)隱私極度敏感的產(chǎn)品這時(shí)候即使用戶(hù)嘴上不說(shuō)實(shí)際使用中也會(huì)回避人臉登錄入口。我的建議是人臉識(shí)別登錄作為主登錄方式之一和密碼登錄、短信驗(yàn)證碼登錄并存讓用戶(hù)自己選。不要強(qiáng)制強(qiáng)制會(huì)引發(fā)反感也不要只做人臉單一登錄方式一旦出問(wèn)題就是全量故障。1.3 百度AI人臉識(shí)別能力在登錄場(chǎng)景中的定位百度AI的人臉識(shí)別能力在這個(gè)登錄方案里扮演的是“比對(duì)引擎”的角色。具體來(lái)說(shuō)它提供兩個(gè)核心能力一是人臉檢測(cè)從一張圖片里找出人臉的位置和關(guān)鍵點(diǎn)二是人臉比對(duì)判斷兩張人臉是不是同一個(gè)人并給出相似度分?jǐn)?shù)。在登錄場(chǎng)景中典型的流程是這樣的用戶(hù)在注冊(cè)或者首次使用時(shí)先錄入一張基準(zhǔn)人臉照片這張照片經(jīng)過(guò)質(zhì)量檢測(cè)后存到服務(wù)端。之后每次登錄客戶(hù)端采集一張實(shí)時(shí)人臉照片上傳到服務(wù)端服務(wù)端調(diào)用百度AI的比對(duì)接口把實(shí)時(shí)照片和基準(zhǔn)照片做比對(duì)如果相似度超過(guò)設(shè)定閾值就判定登錄成功。這個(gè)方案的好處在于比對(duì)邏輯放在服務(wù)端客戶(hù)端只負(fù)責(zé)采集和上傳安全性更高。而且百度AI的接口封裝得比較成熟開(kāi)發(fā)者不需要理解人臉識(shí)別的底層算法只需要按照文檔調(diào)用接口、處理返回結(jié)果就行。對(duì)于中小型項(xiàng)目來(lái)說(shuō)這是性?xún)r(jià)比很高的選擇——自己訓(xùn)練模型成本太高用開(kāi)源方案效果不穩(wěn)定調(diào)用成熟接口是最務(wù)實(shí)的路徑。2. 接入前的準(zhǔn)備工作賬號(hào)、密鑰與SDK選型2.1 百度AI開(kāi)放平臺(tái)的賬號(hào)注冊(cè)與應(yīng)用創(chuàng)建接入的第一步是在百度AI開(kāi)放平臺(tái)注冊(cè)賬號(hào)并創(chuàng)建應(yīng)用。這個(gè)過(guò)程本身不復(fù)雜但有幾個(gè)細(xì)節(jié)容易踩坑。注冊(cè)賬號(hào)需要實(shí)名認(rèn)證個(gè)人開(kāi)發(fā)者用身份證企業(yè)開(kāi)發(fā)者用營(yíng)業(yè)執(zhí)照。實(shí)名認(rèn)證的審核時(shí)間一般在幾分鐘到幾小時(shí)之間建議提前做不要等到開(kāi)發(fā)到一半才發(fā)現(xiàn)賬號(hào)沒(méi)認(rèn)證。認(rèn)證完成后進(jìn)入控制臺(tái)找到“人臉識(shí)別”相關(guān)的服務(wù)創(chuàng)建一個(gè)應(yīng)用。創(chuàng)建應(yīng)用的時(shí)候需要選擇應(yīng)用類(lèi)型一般選“通用”就行除非你有特殊需求。創(chuàng)建完應(yīng)用后平臺(tái)會(huì)給你三個(gè)關(guān)鍵信息API Key、Secret Key、以及應(yīng)用對(duì)應(yīng)的App ID。這三個(gè)東西是后續(xù)調(diào)用接口的憑證尤其是API Key和Secret Key相當(dāng)于你的賬號(hào)密碼絕對(duì)不能泄露到客戶(hù)端代碼里。我見(jiàn)過(guò)有開(kāi)發(fā)者圖省事把Secret Key直接寫(xiě)在Android或iOS的代碼里結(jié)果被人反編譯拿到盜刷了大量接口調(diào)用次數(shù)。這個(gè)坑一定要避開(kāi)。注意API Key和Secret Key只能保存在服務(wù)端客戶(hù)端永遠(yuǎn)不要直接持有?？蛻?hù)端需要調(diào)用人臉識(shí)別時(shí)統(tǒng)一走自己的服務(wù)端中轉(zhuǎn)。2.2 Access Token的獲取與緩存策略百度AI的接口調(diào)用需要一個(gè)Access Token這個(gè)Token是通過(guò)API Key和Secret Key換來(lái)的有效期默認(rèn)是30天。獲取Token的接口是一個(gè)標(biāo)準(zhǔn)的HTTP POST請(qǐng)求把API Key和Secret Key作為參數(shù)傳過(guò)去返回一個(gè)JSON里面包含access_token和expires_in兩個(gè)字段。這里的關(guān)鍵問(wèn)題是Token不能每次調(diào)用都去換一次。因?yàn)楂@取Token的接口本身有頻率限制而且每次換Token都有網(wǎng)絡(luò)開(kāi)銷(xiāo)。正確的做法是在服務(wù)端緩存Token用一個(gè)定時(shí)任務(wù)或者懶加載的方式在Token快過(guò)期的時(shí)候刷新。我一般的做法是服務(wù)端啟動(dòng)時(shí)獲取一次Token記錄獲取時(shí)間和有效期之后每次調(diào)用人臉識(shí)別接口前檢查T(mén)oken是否還有足夠剩余時(shí)間比如剩余時(shí)間少于1小時(shí)就刷新。刷新的時(shí)候加一個(gè)鎖避免并發(fā)請(qǐng)求同時(shí)去刷新導(dǎo)致重復(fù)獲取。這個(gè)邏輯用Redis或者本地緩存都能實(shí)現(xiàn)看你的服務(wù)端架構(gòu)。import time import requests class BaiduFaceTokenManager: def __init__(self, api_key, secret_key): self.api_key api_key self.secret_key secret_key self.token None self.expire_at 0 def get_token(self): if self.token and time.time() self.expire_at - 3600: return self.token url https://aip.baidubce.com/oauth/2.0/token params { grant_type: client_credentials, client_id: self.api_key, client_secret: self.secret_key } resp requests.post(url, paramsparams, timeout5) data resp.json() self.token data[access_token] self.expire_at time.time() data[expires_in] return self.token上面這段代碼就是一個(gè)簡(jiǎn)單的Token管理器核心邏輯是“有緩存且未臨近過(guò)期就直接用否則重新獲取”。實(shí)際項(xiàng)目中你可以把它封裝成一個(gè)單例全局共享。2.3 SDK還是直接調(diào)HTTP接口我的選型對(duì)比百度AI提供了多種語(yǔ)言的SDK包括Java、Python、PHP、Node.js等。那到底是直接用SDK還是自己封裝HTTP請(qǐng)求我在不同項(xiàng)目里兩種方式都用過(guò)說(shuō)一下各自的優(yōu)劣。SDK的優(yōu)勢(shì)是封裝好了鑒權(quán)、請(qǐng)求構(gòu)造、結(jié)果解析這些重復(fù)勞動(dòng)調(diào)用起來(lái)代碼量少。比如Python SDK里人臉比對(duì)就是一行client.match(faces)的事。但SDK的劣勢(shì)也很明顯一是版本更新可能滯后于接口本身新出的能力SDK里不一定有二是SDK會(huì)引入額外的依賴(lài)如果你的項(xiàng)目對(duì)依賴(lài)體積敏感可能不太合適三是出問(wèn)題的時(shí)候排查鏈路更長(zhǎng)你得先確認(rèn)是SDK的問(wèn)題還是接口的問(wèn)題。直接調(diào)HTTP接口的優(yōu)勢(shì)是透明、可控。你知道每一步在做什么請(qǐng)求參數(shù)和返回結(jié)果都是明文的排查問(wèn)題方便。而且不依賴(lài)特定語(yǔ)言的SDK任何能發(fā)HTTP請(qǐng)求的環(huán)境都能用。劣勢(shì)就是需要自己處理Token、自己構(gòu)造請(qǐng)求、自己解析返回代碼量多一些。我的建議是如果是快速驗(yàn)證或者小型項(xiàng)目用SDK省事如果是生產(chǎn)環(huán)境、對(duì)穩(wěn)定性和可控性要求高自己封裝HTTP請(qǐng)求更穩(wěn)妥。我現(xiàn)在的項(xiàng)目基本都走HTTP直調(diào)因?yàn)榉?wù)端語(yǔ)言可能換但HTTP接口不會(huì)變。3. 人臉比對(duì)接口的調(diào)用細(xì)節(jié)與參數(shù)調(diào)優(yōu)3.1 人臉檢測(cè)接口先確認(rèn)圖片里有沒(méi)有合格的人臉在做人臉比對(duì)之前有一個(gè)前置步驟經(jīng)常被忽略人臉檢測(cè)。很多人直接把用戶(hù)上傳的照片丟給比對(duì)接口結(jié)果返回“人臉模糊”或者“未檢測(cè)到人臉”然后一頭霧水。其實(shí)比對(duì)接口內(nèi)部也會(huì)做人臉檢測(cè)但如果你先用檢測(cè)接口篩一遍可以提前給用戶(hù)更明確的提示。人臉檢測(cè)接口返回的信息很豐富包括人臉的位置框、人臉關(guān)鍵點(diǎn)眼睛、鼻子、嘴巴的位置、以及人臉的質(zhì)量分?jǐn)?shù)。質(zhì)量分?jǐn)?shù)這個(gè)字段特別有用它綜合了模糊度、光照、遮擋等因素分?jǐn)?shù)越高說(shuō)明人臉質(zhì)量越好。我在實(shí)際項(xiàng)目里會(huì)把質(zhì)量分?jǐn)?shù)低于某個(gè)閾值的照片直接打回讓用戶(hù)重新拍而不是硬著頭皮去比對(duì)。def detect_face(image_base64, token): url https://aip.baidubce.com/rest/2.0/face/v3/detect params {access_token: token} data { image: image_base64, image_type: BASE64, face_field: quality,blur,illumination,occlusion } resp requests.post(url, paramsparams, datadata, timeout5) result resp.json() if result[error_code] ! 0: return None face_list result[result][face_list] if not face_list: return None return face_list[0]這段代碼調(diào)用檢測(cè)接口返回第一張人臉的信息。注意face_field參數(shù)它決定了返回結(jié)果里包含哪些字段。如果你不傳這個(gè)參數(shù)返回的信息會(huì)很少只有位置框。傳了quality之后才能拿到質(zhì)量分?jǐn)?shù)。3.2 人臉比對(duì)接口的核心參數(shù)image_type、face_type、quality_control比對(duì)接口是登錄功能的核心。它的調(diào)用邏輯是傳兩張圖片一張是用戶(hù)實(shí)時(shí)采集的一張是之前存的基準(zhǔn)圖接口返回一個(gè)相似度分?jǐn)?shù)。這里有幾個(gè)參數(shù)必須理解清楚否則很容易調(diào)出莫名其妙的結(jié)果。第一個(gè)是image_type它告訴接口你傳的圖片是什么格式。支持BASE64、URL、FACE_TOKEN三種。BASE64就是把圖片編碼成字符串直接傳適合圖片不大的場(chǎng)景URL是傳一個(gè)可訪(fǎng)問(wèn)的圖片鏈接接口自己去下載FACE_TOKEN是之前調(diào)用檢測(cè)接口時(shí)返回的人臉標(biāo)識(shí)可以理解為“人臉身份證”。在登錄場(chǎng)景里基準(zhǔn)圖我建議存成FACE_TOKEN因?yàn)镕ACE_TOKEN本身就代表了那張人臉而且體積小、傳輸快。實(shí)時(shí)圖用BASE64傳因?yàn)樗羌磿r(shí)采集的沒(méi)有現(xiàn)成的URL。第二個(gè)是face_type它告訴接口圖片里的人臉是什么類(lèi)型?？蛇x值有LIVE生活照、IDCARD身份證芯片照、WATERMARK水印證件照、CERT證件照。登錄場(chǎng)景一般用LIVE因?yàn)橛脩?hù)是實(shí)時(shí)拍的屬于生活照范疇。如果你用錯(cuò)了類(lèi)型比如把生活照標(biāo)成證件照比對(duì)分?jǐn)?shù)可能會(huì)偏低。第三個(gè)是quality_control它控制是否開(kāi)啟圖片質(zhì)量檢測(cè)?？蛇x值有NONE不檢測(cè)、LOW低質(zhì)量檢測(cè)、NORMAL正常質(zhì)量檢測(cè)、HIGH高質(zhì)量檢測(cè)。開(kāi)啟質(zhì)量檢測(cè)后如果圖片質(zhì)量不達(dá)標(biāo)接口會(huì)直接返回錯(cuò)誤而不是給一個(gè)不可靠的比對(duì)分?jǐn)?shù)。我一般設(shè)成NORMAL既能過(guò)濾掉明顯不合格的圖片又不會(huì)因?yàn)闃?biāo)準(zhǔn)太嚴(yán)導(dǎo)致正常圖片被拒。第四個(gè)是liveness_control它控制是否開(kāi)啟活體檢測(cè)。這個(gè)參數(shù)在登錄場(chǎng)景里非常重要因?yàn)槿绻蛔龌铙w檢測(cè)用戶(hù)拿一張照片就能騙過(guò)系統(tǒng)。可選值同樣是NONE、LOW、NORMAL、HIGH。我建議至少設(shè)成LOW有條件的話(huà)設(shè)成NORMAL?；铙w檢測(cè)會(huì)增加一點(diǎn)耗時(shí)但安全性的提升是值得的。參數(shù)推薦值作用不設(shè)置的后果image_typeBASE64實(shí)時(shí)圖/ FACE_TOKEN基準(zhǔn)圖指定圖片格式接口無(wú)法解析圖片face_typeLIVE指定人臉類(lèi)型比對(duì)分?jǐn)?shù)可能偏低quality_controlNORMAL圖片質(zhì)量檢測(cè)低質(zhì)量圖片也能比對(duì)結(jié)果不可靠liveness_controlNORMAL活體檢測(cè)照片可冒充真人3.3 相似度閾值怎么定一個(gè)需要數(shù)據(jù)支撐的決策比對(duì)接口返回的相似度分?jǐn)?shù)是一個(gè)0到100的浮點(diǎn)數(shù)分?jǐn)?shù)越高說(shuō)明越可能是同一個(gè)人。那閾值定多少合適這個(gè)問(wèn)題沒(méi)有標(biāo)準(zhǔn)答案取決于你的業(yè)務(wù)對(duì)安全性和通過(guò)率的權(quán)衡。閾值定得高比如90分安全性好但用戶(hù)可能因?yàn)楣饩€(xiàn)、角度等原因達(dá)不到導(dǎo)致登錄失敗率上升。閾值定得低比如70分通過(guò)率高但誤識(shí)別的風(fēng)險(xiǎn)也增加別人可能用相似的臉蒙混過(guò)關(guān)。我的經(jīng)驗(yàn)是先定一個(gè)初始值比如80分然后在上線(xiàn)后收集真實(shí)數(shù)據(jù)看通過(guò)率和誤識(shí)別的比例再動(dòng)態(tài)調(diào)整。百度官方文檔里給的建議是80分以上可以認(rèn)為是同一人但這個(gè)建議是基于通用場(chǎng)景的你的具體場(chǎng)景可能需要調(diào)整。還有一個(gè)技巧不要只用一個(gè)固定閾值可以根據(jù)場(chǎng)景動(dòng)態(tài)調(diào)整。比如用戶(hù)第一次登錄時(shí)閾值設(shè)高一點(diǎn)確認(rèn)是本人后后續(xù)登錄可以適當(dāng)降低因?yàn)橐呀?jīng)建立了信任?；蛘吒鶕?jù)設(shè)備信息、登錄地點(diǎn)等輔助信息來(lái)調(diào)整閾值設(shè)備可信、地點(diǎn)常規(guī)的時(shí)候閾值可以低一些。def compare_face(live_image_base64, base_face_token, token): url https://aip.baidubce.com/rest/2.0/face/v3/match params {access_token: token} data [ { image: live_image_base64, image_type: BASE64, face_type: LIVE, quality_control: NORMAL, liveness_control: NORMAL }, { image: base_face_token, image_type: FACE_TOKEN, face_type: LIVE, quality_control: NORMAL, liveness_control: NORMAL } ] resp requests.post(url, paramsparams, jsondata, timeout5) result resp.json() if result[error_code] ! 0: return {success: False, msg: result[error_msg]} score result[result][score] if score 80: return {success: True, score: score} else: return {success: False, score: score, msg: 相似度不足}這段代碼就是比對(duì)的核心邏輯注意請(qǐng)求體是一個(gè)數(shù)組包含兩張圖片的信息。返回結(jié)果里的score就是相似度分?jǐn)?shù)。4. 服務(wù)端架構(gòu)設(shè)計(jì)從采集到登錄態(tài)下發(fā)的完整鏈路4.1 客戶(hù)端采集照片的質(zhì)量控制要點(diǎn)客戶(hù)端采集照片這一步看似簡(jiǎn)單實(shí)際上決定了后續(xù)所有環(huán)節(jié)的成功率。我在項(xiàng)目里總結(jié)了幾條采集端的控制要點(diǎn)。第一引導(dǎo)用戶(hù)把臉?lè)旁谥付▍^(qū)域內(nèi)。可以在相機(jī)預(yù)覽界面上畫(huà)一個(gè)橢圓或者圓角矩形提示用戶(hù)把臉對(duì)準(zhǔn)。這個(gè)簡(jiǎn)單的UI引導(dǎo)能顯著提升采集質(zhì)量。第二控制采集時(shí)的光線(xiàn)。太暗或太亮都會(huì)影響識(shí)別。可以在預(yù)覽界面上實(shí)時(shí)顯示亮度提示太暗的時(shí)候提示“光線(xiàn)不足”太亮的時(shí)候提示“避免逆光”。第三限制采集的圖片大小。百度AI接口對(duì)圖片大小有限制一般要求base64編碼后不超過(guò)2MB最短邊至少15px最長(zhǎng)邊最大4096px?？蛻?hù)端采集時(shí)不要直接傳原圖先做一次壓縮把長(zhǎng)邊壓到640px左右就夠了既滿(mǎn)足識(shí)別要求又減少傳輸時(shí)間。第四采集后先做一次本地質(zhì)量檢查。可以用一些輕量的客戶(hù)端檢測(cè)庫(kù)判斷圖片是否模糊、是否有人臉不合格的直接讓用戶(hù)重拍不要浪費(fèi)一次網(wǎng)絡(luò)請(qǐng)求。4.2 服務(wù)端接口的分層設(shè)計(jì)采集接口、比對(duì)接口、登錄接口服務(wù)端的接口設(shè)計(jì)我建議分成三層每層職責(zé)單一方便排查問(wèn)題。第一層是采集接口負(fù)責(zé)接收客戶(hù)端上傳的實(shí)時(shí)照片做基本的格式校驗(yàn)和大小校驗(yàn)然后把照片暫存起來(lái)返回一個(gè)臨時(shí)的圖片ID。這一層不做人臉識(shí)別只做文件處理。第二層是比對(duì)接口接收臨時(shí)圖片ID和用戶(hù)ID從數(shù)據(jù)庫(kù)里取出該用戶(hù)的基準(zhǔn)人臉FACE_TOKEN調(diào)用百度AI的比對(duì)接口返回比對(duì)結(jié)果。這一層是核心邏輯層所有的參數(shù)調(diào)優(yōu)、閾值判斷都在這里。第三層是登錄接口接收比對(duì)接口的結(jié)果如果比對(duì)成功生成登錄態(tài)比如JWT Token或者Session ID返回給客戶(hù)端如果比對(duì)失敗返回失敗原因和重試提示。這樣分層的好處是每一層都可以獨(dú)立測(cè)試和替換。比如以后想換一家的人臉識(shí)別服務(wù)只需要改比對(duì)接口這一層采集接口和登錄接口不用動(dòng)。# 比對(duì)接口的偽代碼 def face_login(user_id, temp_image_id): # 1. 取出臨時(shí)圖片 temp_image get_temp_image(temp_image_id) if not temp_image: return {code: 400, msg: 圖片已過(guò)期} # 2. 取出用戶(hù)基準(zhǔn)人臉 user get_user(user_id) if not user or not user.base_face_token: return {code: 400, msg: 用戶(hù)未錄入人臉} # 3. 調(diào)用百度AI比對(duì) token token_manager.get_token() result compare_face(temp_image.base64, user.base_face_token, token) # 4. 處理結(jié)果 if result[success]: login_token generate_login_token(user_id) return {code: 0, msg: 登錄成功, token: login_token} else: return {code: 401, msg: 人臉比對(duì)失敗, score: result.get(score)}4.3 基準(zhǔn)人臉的錄入流程與存儲(chǔ)策略基準(zhǔn)人臉的錄入是整個(gè)功能的基礎(chǔ)。如果基準(zhǔn)圖質(zhì)量差后續(xù)所有比對(duì)都會(huì)受影響。所以錄入環(huán)節(jié)要嚴(yán)格。錄入流程一般是這樣的用戶(hù)在設(shè)置里選擇“錄入人臉”客戶(hù)端采集一張照片上傳到服務(wù)端服務(wù)端調(diào)用檢測(cè)接口檢查人臉質(zhì)量。如果質(zhì)量合格調(diào)用檢測(cè)接口拿到FACE_TOKEN把FACE_TOKEN和用戶(hù)ID關(guān)聯(lián)存到數(shù)據(jù)庫(kù)。如果不合格提示用戶(hù)重新采集。存儲(chǔ)策略上我建議只存FACE_TOKEN不存原始圖片。原因有兩個(gè)一是FACE_TOKEN體積小存儲(chǔ)成本低二是原始圖片涉及用戶(hù)生物特征信息存儲(chǔ)和傳輸都有合規(guī)風(fēng)險(xiǎn)能不存就不存。如果業(yè)務(wù)確實(shí)需要保留原始圖片一定要加密存儲(chǔ)并且明確告知用戶(hù)。還有一個(gè)細(xì)節(jié)一個(gè)用戶(hù)可以錄入多張基準(zhǔn)人臉嗎技術(shù)上可以但我不建議。多張基準(zhǔn)圖會(huì)增加比對(duì)時(shí)的選擇邏輯而且用戶(hù)自己也不知道該用哪張。一張高質(zhì)量的基準(zhǔn)圖就夠了如果用戶(hù)覺(jué)得當(dāng)前基準(zhǔn)圖不好可以重新錄入覆蓋。5. 上線(xiàn)前必須處理的異常情況與邊界問(wèn)題5.1 網(wǎng)絡(luò)超時(shí)與接口限流的應(yīng)對(duì)方案百度AI的接口調(diào)用是走公網(wǎng)的網(wǎng)絡(luò)超時(shí)是必須考慮的問(wèn)題。我在項(xiàng)目里遇到過(guò)好幾次因?yàn)榫W(wǎng)絡(luò)抖動(dòng)導(dǎo)致比對(duì)接口超時(shí)用戶(hù)那邊看到的就是“登錄失敗”但實(shí)際上只是網(wǎng)絡(luò)問(wèn)題。應(yīng)對(duì)方案是設(shè)置合理的超時(shí)時(shí)間并且做重試。超時(shí)時(shí)間我一般設(shè)5秒太短容易誤判太長(zhǎng)用戶(hù)等不及。重試策略是第一次超時(shí)后隔500毫秒重試一次如果還超時(shí)再隔1秒重試一次三次都失敗才返回錯(cuò)誤。重試的時(shí)候要注意如果是活體檢測(cè)失敗這種業(yè)務(wù)錯(cuò)誤不要重試因?yàn)橹卦嚱Y(jié)果也一樣。接口限流是另一個(gè)問(wèn)題。百度AI的接口有QPS限制具體數(shù)值取決于你的賬號(hào)等級(jí)。如果短時(shí)間內(nèi)大量用戶(hù)同時(shí)登錄可能會(huì)觸發(fā)限流返回“請(qǐng)求過(guò)于頻繁”的錯(cuò)誤。應(yīng)對(duì)方案是在服務(wù)端做一層隊(duì)列把比對(duì)請(qǐng)求排隊(duì)處理控制并發(fā)數(shù)。或者提前申請(qǐng)更高的QPS配額根據(jù)業(yè)務(wù)峰值來(lái)定。import time def compare_with_retry(live_image, base_token, token, max_retry3): for i in range(max_retry): try: result compare_face(live_image, base_token, token) if result[success] or result.get(error_code) 0: return result # 業(yè)務(wù)錯(cuò)誤不重試 if result.get(error_code) in [222207, 222208]: return result except requests.Timeout: pass time.sleep(0.5 * (i 1)) return {success: False, msg: 網(wǎng)絡(luò)異常請(qǐng)稍后重試}5.2 活體檢測(cè)失敗與照片攻擊的防范活體檢測(cè)是防止照片攻擊的關(guān)鍵。但活體檢測(cè)本身也有失敗率正常用戶(hù)可能因?yàn)閯?dòng)作不規(guī)范、光線(xiàn)不好等原因被判定為“非活體”。這時(shí)候不能簡(jiǎn)單地說(shuō)“你是照片”而要引導(dǎo)用戶(hù)重新操作。我的做法是活體檢測(cè)失敗后返回一個(gè)明確的提示比如“請(qǐng)確保是本人操作并保持光線(xiàn)充足”然后讓用戶(hù)重試。如果連續(xù)三次活體檢測(cè)失敗就降級(jí)到密碼登錄避免用戶(hù)被卡死。照片攻擊的防范除了活體檢測(cè)還可以加一些輔助手段。比如檢測(cè)圖片的EXIF信息如果發(fā)現(xiàn)是用相機(jī)拍攝的原始照片而不是實(shí)時(shí)采集的就拒絕?；蛘咭笥脩?hù)在采集時(shí)做一個(gè)隨機(jī)動(dòng)作比如眨眼、轉(zhuǎn)頭增加攻擊難度。但這些手段會(huì)增加用戶(hù)操作成本需要權(quán)衡。5.3 用戶(hù)換臉、整容、年齡變化導(dǎo)致比對(duì)失敗的兜底這是一個(gè)容易被忽略但實(shí)際會(huì)發(fā)生的問(wèn)題。用戶(hù)換了發(fā)型、戴了眼鏡、胖了瘦了都可能導(dǎo)致比對(duì)分?jǐn)?shù)下降。如果閾值定得死這些用戶(hù)就登錄不了了。兜底方案有幾個(gè)一是允許用戶(hù)重新錄入基準(zhǔn)人臉在登錄失敗頁(yè)面上提供“重新錄入”的入口。二是設(shè)置一個(gè)“寬容期”比如比對(duì)分?jǐn)?shù)在70到80之間時(shí)不直接拒絕而是要求用戶(hù)輸入密碼作為二次驗(yàn)證驗(yàn)證通過(guò)后允許登錄并提示用戶(hù)更新基準(zhǔn)人臉。三是記錄每次比對(duì)的分?jǐn)?shù)如果發(fā)現(xiàn)某個(gè)用戶(hù)的分?jǐn)?shù)持續(xù)下降主動(dòng)提醒用戶(hù)更新基準(zhǔn)圖。整容這種情況比較極端但確實(shí)存在。如果用戶(hù)整容后比對(duì)失敗只能走重新錄入流程。所以在產(chǎn)品設(shè)計(jì)上重新錄入的入口一定要明顯、好找。6. 實(shí)測(cè)數(shù)據(jù)與性能優(yōu)化讓登錄成功率穩(wěn)定在可用水平6.1 不同光線(xiàn)條件下的比對(duì)分?jǐn)?shù)分布我在一個(gè)測(cè)試環(huán)境里做了幾組對(duì)比實(shí)驗(yàn)用同一個(gè)人的基準(zhǔn)圖在不同光線(xiàn)條件下采集實(shí)時(shí)圖看比對(duì)分?jǐn)?shù)的變化。結(jié)果如下光線(xiàn)條件平均比對(duì)分?jǐn)?shù)通過(guò)率閾值80室內(nèi)正常光92.398%室內(nèi)偏暗84.785%室內(nèi)偏亮/逆光81.276%室外陰天88.593%室外強(qiáng)光79.668%從數(shù)據(jù)可以看出光線(xiàn)對(duì)識(shí)別效果的影響非常明顯。強(qiáng)光和逆光是最差的情況通過(guò)率只有不到七成。所以客戶(hù)端的光線(xiàn)引導(dǎo)不是可選項(xiàng)而是必選項(xiàng)。6.2 圖片壓縮對(duì)識(shí)別速度和準(zhǔn)確率的平衡客戶(hù)端采集的圖片如果不壓縮一張可能好幾MB上傳耗時(shí)不說(shuō)百度AI接口處理起來(lái)也慢。我測(cè)試了不同壓縮比例下的表現(xiàn)長(zhǎng)邊像素圖片大小上傳耗時(shí)比對(duì)耗時(shí)比對(duì)分?jǐn)?shù)變化1280約800KB1.2s0.8s基準(zhǔn)640約200KB0.4s0.5s-0.5分480約120KB0.3s0.4s-1.2分320約60KB0.2s0.3s-3.8分結(jié)論很清晰壓到640px長(zhǎng)邊是性?xún)r(jià)比最高的選擇圖片大小降到200KB左右比對(duì)分?jǐn)?shù)只降了0.5分幾乎可以忽略。再往下壓分?jǐn)?shù)下降就比較明顯了。所以我在項(xiàng)目里統(tǒng)一用640px作為采集圖片的長(zhǎng)邊上限。6.3 并發(fā)場(chǎng)景下的Token管理與接口調(diào)用優(yōu)化當(dāng)多個(gè)用戶(hù)同時(shí)登錄時(shí)Token管理和接口調(diào)用會(huì)成為瓶頸。我做過(guò)一個(gè)壓測(cè)單臺(tái)服務(wù)端在不做優(yōu)化的情況下大概能支撐每秒20次比對(duì)請(qǐng)求。優(yōu)化后能到每秒80次左右。優(yōu)化的點(diǎn)主要有三個(gè)一是Token緩存避免每次請(qǐng)求都去換Token二是HTTP連接復(fù)用用連接池而不是每次新建連接三是異步處理把比對(duì)請(qǐng)求放到線(xiàn)程池或者協(xié)程里不阻塞主線(xiàn)程。import requests from concurrent.futures import ThreadPoolExecutor session requests.Session() executor ThreadPoolExecutor(max_workers20) def async_compare(live_image, base_token, token): future executor.submit(compare_face, live_image, base_token, token) return future用Session復(fù)用連接用線(xiàn)程池控制并發(fā)這兩個(gè)改動(dòng)就能把吞吐量提升好幾倍。7. 一些只有踩過(guò)坑才知道的實(shí)操經(jīng)驗(yàn)7.1 FACE_TOKEN的有效期與更新時(shí)機(jī)FACE_TOKEN不是永久有效的百度AI的文檔里說(shuō)它“長(zhǎng)期有效”但實(shí)際測(cè)試下來(lái)如果長(zhǎng)時(shí)間不用可能會(huì)失效。我遇到過(guò)用戶(hù)三個(gè)月沒(méi)登錄再登錄時(shí)發(fā)現(xiàn)基準(zhǔn)圖的FACE_TOKEN已經(jīng)無(wú)效了比對(duì)直接報(bào)錯(cuò)。所以我的做法是在用戶(hù)每次成功登錄后順便更新一次基準(zhǔn)圖的FACE_TOKEN。具體來(lái)說(shuō)如果用戶(hù)是用FACE_TOKEN比對(duì)的比對(duì)成功后把實(shí)時(shí)圖再調(diào)一次檢測(cè)接口拿到新的FACE_TOKEN覆蓋舊的。這樣基準(zhǔn)圖始終保持新鮮不會(huì)因?yàn)殚L(zhǎng)期不用而失效。7.2 錯(cuò)誤碼的完整梳理與用戶(hù)提示的映射百度AI的接口會(huì)返回各種錯(cuò)誤碼如果直接把錯(cuò)誤碼拋給用戶(hù)用戶(hù)根本看不懂。我整理了一份常見(jiàn)錯(cuò)誤碼和用戶(hù)提示的映射表錯(cuò)誤碼含義用戶(hù)提示0成功-222207未檢測(cè)到人臉請(qǐng)確保臉部在畫(huà)面內(nèi)222208人臉模糊請(qǐng)保持穩(wěn)定重新拍攝222209人臉太小請(qǐng)靠近一些222210人臉太大請(qǐng)離遠(yuǎn)一些222211人臉角度過(guò)大請(qǐng)正對(duì)攝像頭222212光照太暗請(qǐng)到光線(xiàn)充足的地方222213光照太亮請(qǐng)避免逆光216101參數(shù)錯(cuò)誤系統(tǒng)異常請(qǐng)稍后重試216200空?qǐng)D片請(qǐng)重新拍攝這份映射表直接決定了用戶(hù)看到提示時(shí)的體驗(yàn)。提示要具體、可操作不要只說(shuō)“失敗”。7.3 灰度發(fā)布與降級(jí)策略的實(shí)際操作人臉識(shí)別登錄上線(xiàn)時(shí)不要一次性全量放開(kāi)。我的做法是先灰度10%的用戶(hù)觀察一周的登錄成功率和誤識(shí)別率。如果數(shù)據(jù)正常再逐步擴(kuò)大到50%、100%?；叶绕陂g如果發(fā)現(xiàn)異?？梢钥焖倩貪L到密碼登錄。降級(jí)策略也要提前設(shè)計(jì)好。當(dāng)百度AI接口不可用、或者錯(cuò)誤率超過(guò)閾值時(shí)自動(dòng)切換到密碼登錄并給用戶(hù)一個(gè)提示“人臉登錄暫時(shí)不可用請(qǐng)使用密碼登錄”。這個(gè)切換邏輯要寫(xiě)在服務(wù)端不要依賴(lài)客戶(hù)端判斷。7.4 用戶(hù)隱私告知與合規(guī)注意事項(xiàng)最后說(shuō)一個(gè)容易被技術(shù)開(kāi)發(fā)者忽略的點(diǎn)隱私告知。人臉信息屬于敏感個(gè)人信息采集前必須獲得用戶(hù)明確同意。我的做法是在錄入人臉之前彈出一個(gè)告知頁(yè)面說(shuō)明采集人臉的目的、存儲(chǔ)方式、使用范圍用戶(hù)點(diǎn)擊“同意”后才能繼續(xù)。這個(gè)頁(yè)面不能默認(rèn)勾選必須用戶(hù)主動(dòng)點(diǎn)擊。另外如果業(yè)務(wù)涉及未成年人還需要額外的監(jiān)護(hù)人同意流程。這些合規(guī)細(xì)節(jié)雖然繁瑣但一旦出問(wèn)題后果比技術(shù)bug嚴(yán)重得多。人臉識(shí)別登錄這個(gè)功能技術(shù)實(shí)現(xiàn)本身并不復(fù)雜難的是把各種邊界情況處理好讓它在真實(shí)場(chǎng)景下穩(wěn)定可用。我上面寫(xiě)的這些都是實(shí)際項(xiàng)目中驗(yàn)證過(guò)的做法你可以直接參考。如果你的項(xiàng)目場(chǎng)景比較特殊比如光線(xiàn)條件特別差、或者用戶(hù)群體比較特殊可能需要額外調(diào)整參數(shù)和策略。核心原則就一條不要假設(shè)用戶(hù)會(huì)按照你預(yù)期的方式使用要把所有可能的異常都考慮到。 基于百度AI人臉識(shí)別登錄實(shí)戰(zhàn)：從選型到上線(xiàn)的完整避坑指南
人臉識(shí)別登錄這個(gè)功能我在兩三個(gè)項(xiàng)目里都落地過(guò)最早一版用的是本地訓(xùn)練的小模型識(shí)別率在實(shí)驗(yàn)室里看著還行一到真實(shí)場(chǎng)景就崩——光線(xiàn)稍暗、角度稍偏、戴個(gè)眼鏡就認(rèn)不出來(lái)。后來(lái)?yè)Q成調(diào)用云端的人臉識(shí)別能力整個(gè)開(kāi)發(fā)周期從兩周壓縮到兩天而且識(shí)別準(zhǔn)確率直接上了一個(gè)臺(tái)階。這篇內(nèi)容就圍繞“基于百度AI人工智能庫(kù)完成人臉識(shí)別登錄”這件事把我在實(shí)際開(kāi)發(fā)中踩過(guò)的坑、選型的邏輯、接口調(diào)用的細(xì)節(jié)、以及上線(xiàn)前必須處理的邊界情況完整地拆一遍。不管你是剛接觸人臉識(shí)別的新手還是已經(jīng)做過(guò)一版但效果不理想的開(kāi)發(fā)者都能從里面找到可以直接復(fù)用的東西。1. 為什么登錄環(huán)節(jié)要引入人臉識(shí)別而不是繼續(xù)用密碼1.1 密碼登錄的體驗(yàn)瓶頸到底在哪里先說(shuō)一個(gè)我觀察到的現(xiàn)象大部分用戶(hù)在同一款A(yù)pp里設(shè)置的密碼和他們?cè)谄渌胤接玫拿艽a高度重合。這不是用戶(hù)懶而是記憶成本決定的。一個(gè)普通用戶(hù)手機(jī)上裝著幾十個(gè)應(yīng)用如果每個(gè)都設(shè)獨(dú)立密碼根本記不住。所以密碼登錄這件事從體驗(yàn)層面看它天然帶著兩個(gè)硬傷——輸入成本高和記憶負(fù)擔(dān)重。輸入成本高體現(xiàn)在哪移動(dòng)端上打一串包含大小寫(xiě)字母、數(shù)字、符號(hào)的密碼平均耗時(shí)在8到12秒之間如果密碼復(fù)雜度要求高用戶(hù)輸錯(cuò)的概率會(huì)顯著上升。我做過(guò)一個(gè)粗略統(tǒng)計(jì)在一個(gè)日活幾千的小型應(yīng)用里密碼登錄的首次輸入成功率大概在七成左右剩下三成用戶(hù)至少需要重試一次。這個(gè)數(shù)據(jù)意味著什么意味著每十個(gè)想登錄的用戶(hù)里有三個(gè)在登錄環(huán)節(jié)就被卡了一下體驗(yàn)上的摩擦感非常明顯。記憶負(fù)擔(dān)重則更隱蔽。用戶(hù)為了省事往往會(huì)選擇“記住密碼”或者用系統(tǒng)級(jí)的密碼管理器。這看起來(lái)解決了問(wèn)題但實(shí)際上把風(fēng)險(xiǎn)轉(zhuǎn)移了——一旦設(shè)備丟失或者密碼管理器被攻破所有賬號(hào)都暴露。而且很多用戶(hù)在不同平臺(tái)復(fù)用同一套密碼一個(gè)平臺(tái)泄露其他平臺(tái)跟著遭殃。這不是危言聳聽(tīng)而是安全領(lǐng)域反復(fù)驗(yàn)證過(guò)的規(guī)律。人臉識(shí)別登錄切入的正是這兩個(gè)痛點(diǎn)。它把“輸入密碼”這個(gè)動(dòng)作替換成“看一眼屏幕”耗時(shí)從十秒級(jí)降到一秒級(jí)而且不需要用戶(hù)記憶任何東西。從產(chǎn)品角度看這是登錄體驗(yàn)的一次質(zhì)變。1.2 人臉識(shí)別登錄適合什么場(chǎng)景不適合什么場(chǎng)景但人臉識(shí)別登錄不是萬(wàn)能藥它有明確的適用邊界。我在選型階段就吃過(guò)虧一開(kāi)始想在所有登錄入口都上人臉后來(lái)發(fā)現(xiàn)有些場(chǎng)景根本不合適。適合的場(chǎng)景有這么幾類(lèi)第一類(lèi)是移動(dòng)端App的常規(guī)登錄用戶(hù)手持設(shè)備、光線(xiàn)相對(duì)可控、攝像頭素質(zhì)普遍不錯(cuò)這種場(chǎng)景下人臉識(shí)別的通過(guò)率和體驗(yàn)都很好。第二類(lèi)是需要快速切換賬號(hào)的場(chǎng)景比如一些工具類(lèi)應(yīng)用用戶(hù)可能在工作賬號(hào)和個(gè)人賬號(hào)之間來(lái)回切人臉識(shí)別比輸密碼快得多。第三類(lèi)是作為二次驗(yàn)證手段在密碼登錄之后加一道人臉核驗(yàn)提升安全等級(jí)。不適合的場(chǎng)景也很明確第一類(lèi)是公共設(shè)備上的登錄比如共享終端、公共查詢(xún)機(jī)這些設(shè)備攝像頭角度固定、光線(xiàn)復(fù)雜而且用戶(hù)對(duì)在公共設(shè)備上刷臉有心理抵觸。第二類(lèi)是光線(xiàn)極差或者用戶(hù)戴口罩、帽子遮擋嚴(yán)重的情況雖然現(xiàn)在很多算法支持口罩識(shí)別但通過(guò)率會(huì)打折扣如果業(yè)務(wù)對(duì)登錄成功率要求極高就要慎重。第三類(lèi)是用戶(hù)群體對(duì)隱私極度敏感的產(chǎn)品這時(shí)候即使用戶(hù)嘴上不說(shuō)實(shí)際使用中也會(huì)回避人臉登錄入口。我的建議是人臉識(shí)別登錄作為主登錄方式之一和密碼登錄、短信驗(yàn)證碼登錄并存讓用戶(hù)自己選。不要強(qiáng)制強(qiáng)制會(huì)引發(fā)反感也不要只做人臉單一登錄方式一旦出問(wèn)題就是全量故障。1.3 百度AI人臉識(shí)別能力在登錄場(chǎng)景中的定位百度AI的人臉識(shí)別能力在這個(gè)登錄方案里扮演的是“比對(duì)引擎”的角色。具體來(lái)說(shuō)它提供兩個(gè)核心能力一是人臉檢測(cè)從一張圖片里找出人臉的位置和關(guān)鍵點(diǎn)二是人臉比對(duì)判斷兩張人臉是不是同一個(gè)人并給出相似度分?jǐn)?shù)。在登錄場(chǎng)景中典型的流程是這樣的用戶(hù)在注冊(cè)或者首次使用時(shí)先錄入一張基準(zhǔn)人臉照片這張照片經(jīng)過(guò)質(zhì)量檢測(cè)后存到服務(wù)端。之后每次登錄客戶(hù)端采集一張實(shí)時(shí)人臉照片上傳到服務(wù)端服務(wù)端調(diào)用百度AI的比對(duì)接口把實(shí)時(shí)照片和基準(zhǔn)照片做比對(duì)如果相似度超過(guò)設(shè)定閾值就判定登錄成功。這個(gè)方案的好處在于比對(duì)邏輯放在服務(wù)端客戶(hù)端只負(fù)責(zé)采集和上傳安全性更高。而且百度AI的接口封裝得比較成熟開(kāi)發(fā)者不需要理解人臉識(shí)別的底層算法只需要按照文檔調(diào)用接口、處理返回結(jié)果就行。對(duì)于中小型項(xiàng)目來(lái)說(shuō)這是性?xún)r(jià)比很高的選擇——自己訓(xùn)練模型成本太高用開(kāi)源方案效果不穩(wěn)定調(diào)用成熟接口是最務(wù)實(shí)的路徑。2. 接入前的準(zhǔn)備工作賬號(hào)、密鑰與SDK選型2.1 百度AI開(kāi)放平臺(tái)的賬號(hào)注冊(cè)與應(yīng)用創(chuàng)建接入的第一步是在百度AI開(kāi)放平臺(tái)注冊(cè)賬號(hào)并創(chuàng)建應(yīng)用。這個(gè)過(guò)程本身不復(fù)雜但有幾個(gè)細(xì)節(jié)容易踩坑。注冊(cè)賬號(hào)需要實(shí)名認(rèn)證個(gè)人開(kāi)發(fā)者用身份證企業(yè)開(kāi)發(fā)者用營(yíng)業(yè)執(zhí)照。實(shí)名認(rèn)證的審核時(shí)間一般在幾分鐘到幾小時(shí)之間建議提前做不要等到開(kāi)發(fā)到一半才發(fā)現(xiàn)賬號(hào)沒(méi)認(rèn)證。認(rèn)證完成后進(jìn)入控制臺(tái)找到“人臉識(shí)別”相關(guān)的服務(wù)創(chuàng)建一個(gè)應(yīng)用。創(chuàng)建應(yīng)用的時(shí)候需要選擇應(yīng)用類(lèi)型一般選“通用”就行除非你有特殊需求。創(chuàng)建完應(yīng)用后平臺(tái)會(huì)給你三個(gè)關(guān)鍵信息API Key、Secret Key、以及應(yīng)用對(duì)應(yīng)的App ID。這三個(gè)東西是后續(xù)調(diào)用接口的憑證尤其是API Key和Secret Key相當(dāng)于你的賬號(hào)密碼絕對(duì)不能泄露到客戶(hù)端代碼里。我見(jiàn)過(guò)有開(kāi)發(fā)者圖省事把Secret Key直接寫(xiě)在Android或iOS的代碼里結(jié)果被人反編譯拿到盜刷了大量接口調(diào)用次數(shù)。這個(gè)坑一定要避開(kāi)。注意API Key和Secret Key只能保存在服務(wù)端客戶(hù)端永遠(yuǎn)不要直接持有?？蛻?hù)端需要調(diào)用人臉識(shí)別時(shí)統(tǒng)一走自己的服務(wù)端中轉(zhuǎn)。2.2 Access Token的獲取與緩存策略百度AI的接口調(diào)用需要一個(gè)Access Token這個(gè)Token是通過(guò)API Key和Secret Key換來(lái)的有效期默認(rèn)是30天。獲取Token的接口是一個(gè)標(biāo)準(zhǔn)的HTTP POST請(qǐng)求把API Key和Secret Key作為參數(shù)傳過(guò)去返回一個(gè)JSON里面包含access_token和expires_in兩個(gè)字段。這里的關(guān)鍵問(wèn)題是Token不能每次調(diào)用都去換一次。因?yàn)楂@取Token的接口本身有頻率限制而且每次換Token都有網(wǎng)絡(luò)開(kāi)銷(xiāo)。正確的做法是在服務(wù)端緩存Token用一個(gè)定時(shí)任務(wù)或者懶加載的方式在Token快過(guò)期的時(shí)候刷新。我一般的做法是服務(wù)端啟動(dòng)時(shí)獲取一次Token記錄獲取時(shí)間和有效期之后每次調(diào)用人臉識(shí)別接口前檢查T(mén)oken是否還有足夠剩余時(shí)間比如剩余時(shí)間少于1小時(shí)就刷新。刷新的時(shí)候加一個(gè)鎖避免并發(fā)請(qǐng)求同時(shí)去刷新導(dǎo)致重復(fù)獲取。這個(gè)邏輯用Redis或者本地緩存都能實(shí)現(xiàn)看你的服務(wù)端架構(gòu)。import time import requests class BaiduFaceTokenManager: def __init__(self, api_key, secret_key): self.api_key api_key self.secret_key secret_key self.token None self.expire_at 0 def get_token(self): if self.token and time.time() self.expire_at - 3600: return self.token url https://aip.baidubce.com/oauth/2.0/token params { grant_type: client_credentials, client_id: self.api_key, client_secret: self.secret_key } resp requests.post(url, paramsparams, timeout5) data resp.json() self.token data[access_token] self.expire_at time.time() data[expires_in] return self.token上面這段代碼就是一個(gè)簡(jiǎn)單的Token管理器核心邏輯是“有緩存且未臨近過(guò)期就直接用否則重新獲取”。實(shí)際項(xiàng)目中你可以把它封裝成一個(gè)單例全局共享。2.3 SDK還是直接調(diào)HTTP接口我的選型對(duì)比百度AI提供了多種語(yǔ)言的SDK包括Java、Python、PHP、Node.js等。那到底是直接用SDK還是自己封裝HTTP請(qǐng)求我在不同項(xiàng)目里兩種方式都用過(guò)說(shuō)一下各自的優(yōu)劣。SDK的優(yōu)勢(shì)是封裝好了鑒權(quán)、請(qǐng)求構(gòu)造、結(jié)果解析這些重復(fù)勞動(dòng)調(diào)用起來(lái)代碼量少。比如Python SDK里人臉比對(duì)就是一行client.match(faces)的事。但SDK的劣勢(shì)也很明顯一是版本更新可能滯后于接口本身新出的能力SDK里不一定有二是SDK會(huì)引入額外的依賴(lài)如果你的項(xiàng)目對(duì)依賴(lài)體積敏感可能不太合適三是出問(wèn)題的時(shí)候排查鏈路更長(zhǎng)你得先確認(rèn)是SDK的問(wèn)題還是接口的問(wèn)題。直接調(diào)HTTP接口的優(yōu)勢(shì)是透明、可控。你知道每一步在做什么請(qǐng)求參數(shù)和返回結(jié)果都是明文的排查問(wèn)題方便。而且不依賴(lài)特定語(yǔ)言的SDK任何能發(fā)HTTP請(qǐng)求的環(huán)境都能用。劣勢(shì)就是需要自己處理Token、自己構(gòu)造請(qǐng)求、自己解析返回代碼量多一些。我的建議是如果是快速驗(yàn)證或者小型項(xiàng)目用SDK省事如果是生產(chǎn)環(huán)境、對(duì)穩(wěn)定性和可控性要求高自己封裝HTTP請(qǐng)求更穩(wěn)妥。我現(xiàn)在的項(xiàng)目基本都走HTTP直調(diào)因?yàn)榉?wù)端語(yǔ)言可能換但HTTP接口不會(huì)變。3. 人臉比對(duì)接口的調(diào)用細(xì)節(jié)與參數(shù)調(diào)優(yōu)3.1 人臉檢測(cè)接口先確認(rèn)圖片里有沒(méi)有合格的人臉在做人臉比對(duì)之前有一個(gè)前置步驟經(jīng)常被忽略人臉檢測(cè)。很多人直接把用戶(hù)上傳的照片丟給比對(duì)接口結(jié)果返回“人臉模糊”或者“未檢測(cè)到人臉”然后一頭霧水。其實(shí)比對(duì)接口內(nèi)部也會(huì)做人臉檢測(cè)但如果你先用檢測(cè)接口篩一遍可以提前給用戶(hù)更明確的提示。人臉檢測(cè)接口返回的信息很豐富包括人臉的位置框、人臉關(guān)鍵點(diǎn)眼睛、鼻子、嘴巴的位置、以及人臉的質(zhì)量分?jǐn)?shù)。質(zhì)量分?jǐn)?shù)這個(gè)字段特別有用它綜合了模糊度、光照、遮擋等因素分?jǐn)?shù)越高說(shuō)明人臉質(zhì)量越好。我在實(shí)際項(xiàng)目里會(huì)把質(zhì)量分?jǐn)?shù)低于某個(gè)閾值的照片直接打回讓用戶(hù)重新拍而不是硬著頭皮去比對(duì)。def detect_face(image_base64, token): url https://aip.baidubce.com/rest/2.0/face/v3/detect params {access_token: token} data { image: image_base64, image_type: BASE64, face_field: quality,blur,illumination,occlusion } resp requests.post(url, paramsparams, datadata, timeout5) result resp.json() if result[error_code] ! 0: return None face_list result[result][face_list] if not face_list: return None return face_list[0]這段代碼調(diào)用檢測(cè)接口返回第一張人臉的信息。注意face_field參數(shù)它決定了返回結(jié)果里包含哪些字段。如果你不傳這個(gè)參數(shù)返回的信息會(huì)很少只有位置框。傳了quality之后才能拿到質(zhì)量分?jǐn)?shù)。3.2 人臉比對(duì)接口的核心參數(shù)image_type、face_type、quality_control比對(duì)接口是登錄功能的核心。它的調(diào)用邏輯是傳兩張圖片一張是用戶(hù)實(shí)時(shí)采集的一張是之前存的基準(zhǔn)圖接口返回一個(gè)相似度分?jǐn)?shù)。這里有幾個(gè)參數(shù)必須理解清楚否則很容易調(diào)出莫名其妙的結(jié)果。第一個(gè)是image_type它告訴接口你傳的圖片是什么格式。支持BASE64、URL、FACE_TOKEN三種。BASE64就是把圖片編碼成字符串直接傳適合圖片不大的場(chǎng)景URL是傳一個(gè)可訪(fǎng)問(wèn)的圖片鏈接接口自己去下載FACE_TOKEN是之前調(diào)用檢測(cè)接口時(shí)返回的人臉標(biāo)識(shí)可以理解為“人臉身份證”。在登錄場(chǎng)景里基準(zhǔn)圖我建議存成FACE_TOKEN因?yàn)镕ACE_TOKEN本身就代表了那張人臉而且體積小、傳輸快。實(shí)時(shí)圖用BASE64傳因?yàn)樗羌磿r(shí)采集的沒(méi)有現(xiàn)成的URL。第二個(gè)是face_type它告訴接口圖片里的人臉是什么類(lèi)型?？蛇x值有LIVE生活照、IDCARD身份證芯片照、WATERMARK水印證件照、CERT證件照。登錄場(chǎng)景一般用LIVE因?yàn)橛脩?hù)是實(shí)時(shí)拍的屬于生活照范疇。如果你用錯(cuò)了類(lèi)型比如把生活照標(biāo)成證件照比對(duì)分?jǐn)?shù)可能會(huì)偏低。第三個(gè)是quality_control它控制是否開(kāi)啟圖片質(zhì)量檢測(cè)?？蛇x值有NONE不檢測(cè)、LOW低質(zhì)量檢測(cè)、NORMAL正常質(zhì)量檢測(cè)、HIGH高質(zhì)量檢測(cè)。開(kāi)啟質(zhì)量檢測(cè)后如果圖片質(zhì)量不達(dá)標(biāo)接口會(huì)直接返回錯(cuò)誤而不是給一個(gè)不可靠的比對(duì)分?jǐn)?shù)。我一般設(shè)成NORMAL既能過(guò)濾掉明顯不合格的圖片又不會(huì)因?yàn)闃?biāo)準(zhǔn)太嚴(yán)導(dǎo)致正常圖片被拒。第四個(gè)是liveness_control它控制是否開(kāi)啟活體檢測(cè)。這個(gè)參數(shù)在登錄場(chǎng)景里非常重要因?yàn)槿绻蛔龌铙w檢測(cè)用戶(hù)拿一張照片就能騙過(guò)系統(tǒng)。可選值同樣是NONE、LOW、NORMAL、HIGH。我建議至少設(shè)成LOW有條件的話(huà)設(shè)成NORMAL?；铙w檢測(cè)會(huì)增加一點(diǎn)耗時(shí)但安全性的提升是值得的。參數(shù)推薦值作用不設(shè)置的后果image_typeBASE64實(shí)時(shí)圖/ FACE_TOKEN基準(zhǔn)圖指定圖片格式接口無(wú)法解析圖片face_typeLIVE指定人臉類(lèi)型比對(duì)分?jǐn)?shù)可能偏低quality_controlNORMAL圖片質(zhì)量檢測(cè)低質(zhì)量圖片也能比對(duì)結(jié)果不可靠liveness_controlNORMAL活體檢測(cè)照片可冒充真人3.3 相似度閾值怎么定一個(gè)需要數(shù)據(jù)支撐的決策比對(duì)接口返回的相似度分?jǐn)?shù)是一個(gè)0到100的浮點(diǎn)數(shù)分?jǐn)?shù)越高說(shuō)明越可能是同一個(gè)人。那閾值定多少合適這個(gè)問(wèn)題沒(méi)有標(biāo)準(zhǔn)答案取決于你的業(yè)務(wù)對(duì)安全性和通過(guò)率的權(quán)衡。閾值定得高比如90分安全性好但用戶(hù)可能因?yàn)楣饩€(xiàn)、角度等原因達(dá)不到導(dǎo)致登錄失敗率上升。閾值定得低比如70分通過(guò)率高但誤識(shí)別的風(fēng)險(xiǎn)也增加別人可能用相似的臉蒙混過(guò)關(guān)。我的經(jīng)驗(yàn)是先定一個(gè)初始值比如80分然后在上線(xiàn)后收集真實(shí)數(shù)據(jù)看通過(guò)率和誤識(shí)別的比例再動(dòng)態(tài)調(diào)整。百度官方文檔里給的建議是80分以上可以認(rèn)為是同一人但這個(gè)建議是基于通用場(chǎng)景的你的具體場(chǎng)景可能需要調(diào)整。還有一個(gè)技巧不要只用一個(gè)固定閾值可以根據(jù)場(chǎng)景動(dòng)態(tài)調(diào)整。比如用戶(hù)第一次登錄時(shí)閾值設(shè)高一點(diǎn)確認(rèn)是本人后后續(xù)登錄可以適當(dāng)降低因?yàn)橐呀?jīng)建立了信任?；蛘吒鶕?jù)設(shè)備信息、登錄地點(diǎn)等輔助信息來(lái)調(diào)整閾值設(shè)備可信、地點(diǎn)常規(guī)的時(shí)候閾值可以低一些。def compare_face(live_image_base64, base_face_token, token): url https://aip.baidubce.com/rest/2.0/face/v3/match params {access_token: token} data [ { image: live_image_base64, image_type: BASE64, face_type: LIVE, quality_control: NORMAL, liveness_control: NORMAL }, { image: base_face_token, image_type: FACE_TOKEN, face_type: LIVE, quality_control: NORMAL, liveness_control: NORMAL } ] resp requests.post(url, paramsparams, jsondata, timeout5) result resp.json() if result[error_code] ! 0: return {success: False, msg: result[error_msg]} score result[result][score] if score 80: return {success: True, score: score} else: return {success: False, score: score, msg: 相似度不足}這段代碼就是比對(duì)的核心邏輯注意請(qǐng)求體是一個(gè)數(shù)組包含兩張圖片的信息。返回結(jié)果里的score就是相似度分?jǐn)?shù)。4. 服務(wù)端架構(gòu)設(shè)計(jì)從采集到登錄態(tài)下發(fā)的完整鏈路4.1 客戶(hù)端采集照片的質(zhì)量控制要點(diǎn)客戶(hù)端采集照片這一步看似簡(jiǎn)單實(shí)際上決定了后續(xù)所有環(huán)節(jié)的成功率。我在項(xiàng)目里總結(jié)了幾條采集端的控制要點(diǎn)。第一引導(dǎo)用戶(hù)把臉?lè)旁谥付▍^(qū)域內(nèi)。可以在相機(jī)預(yù)覽界面上畫(huà)一個(gè)橢圓或者圓角矩形提示用戶(hù)把臉對(duì)準(zhǔn)。這個(gè)簡(jiǎn)單的UI引導(dǎo)能顯著提升采集質(zhì)量。第二控制采集時(shí)的光線(xiàn)。太暗或太亮都會(huì)影響識(shí)別。可以在預(yù)覽界面上實(shí)時(shí)顯示亮度提示太暗的時(shí)候提示“光線(xiàn)不足”太亮的時(shí)候提示“避免逆光”。第三限制采集的圖片大小。百度AI接口對(duì)圖片大小有限制一般要求base64編碼后不超過(guò)2MB最短邊至少15px最長(zhǎng)邊最大4096px?？蛻?hù)端采集時(shí)不要直接傳原圖先做一次壓縮把長(zhǎng)邊壓到640px左右就夠了既滿(mǎn)足識(shí)別要求又減少傳輸時(shí)間。第四采集后先做一次本地質(zhì)量檢查。可以用一些輕量的客戶(hù)端檢測(cè)庫(kù)判斷圖片是否模糊、是否有人臉不合格的直接讓用戶(hù)重拍不要浪費(fèi)一次網(wǎng)絡(luò)請(qǐng)求。4.2 服務(wù)端接口的分層設(shè)計(jì)采集接口、比對(duì)接口、登錄接口服務(wù)端的接口設(shè)計(jì)我建議分成三層每層職責(zé)單一方便排查問(wèn)題。第一層是采集接口負(fù)責(zé)接收客戶(hù)端上傳的實(shí)時(shí)照片做基本的格式校驗(yàn)和大小校驗(yàn)然后把照片暫存起來(lái)返回一個(gè)臨時(shí)的圖片ID。這一層不做人臉識(shí)別只做文件處理。第二層是比對(duì)接口接收臨時(shí)圖片ID和用戶(hù)ID從數(shù)據(jù)庫(kù)里取出該用戶(hù)的基準(zhǔn)人臉FACE_TOKEN調(diào)用百度AI的比對(duì)接口返回比對(duì)結(jié)果。這一層是核心邏輯層所有的參數(shù)調(diào)優(yōu)、閾值判斷都在這里。第三層是登錄接口接收比對(duì)接口的結(jié)果如果比對(duì)成功生成登錄態(tài)比如JWT Token或者Session ID返回給客戶(hù)端如果比對(duì)失敗返回失敗原因和重試提示。這樣分層的好處是每一層都可以獨(dú)立測(cè)試和替換。比如以后想換一家的人臉識(shí)別服務(wù)只需要改比對(duì)接口這一層采集接口和登錄接口不用動(dòng)。# 比對(duì)接口的偽代碼 def face_login(user_id, temp_image_id): # 1. 取出臨時(shí)圖片 temp_image get_temp_image(temp_image_id) if not temp_image: return {code: 400, msg: 圖片已過(guò)期} # 2. 取出用戶(hù)基準(zhǔn)人臉 user get_user(user_id) if not user or not user.base_face_token: return {code: 400, msg: 用戶(hù)未錄入人臉} # 3. 調(diào)用百度AI比對(duì) token token_manager.get_token() result compare_face(temp_image.base64, user.base_face_token, token) # 4. 處理結(jié)果 if result[success]: login_token generate_login_token(user_id) return {code: 0, msg: 登錄成功, token: login_token} else: return {code: 401, msg: 人臉比對(duì)失敗, score: result.get(score)}4.3 基準(zhǔn)人臉的錄入流程與存儲(chǔ)策略基準(zhǔn)人臉的錄入是整個(gè)功能的基礎(chǔ)。如果基準(zhǔn)圖質(zhì)量差后續(xù)所有比對(duì)都會(huì)受影響。所以錄入環(huán)節(jié)要嚴(yán)格。錄入流程一般是這樣的用戶(hù)在設(shè)置里選擇“錄入人臉”客戶(hù)端采集一張照片上傳到服務(wù)端服務(wù)端調(diào)用檢測(cè)接口檢查人臉質(zhì)量。如果質(zhì)量合格調(diào)用檢測(cè)接口拿到FACE_TOKEN把FACE_TOKEN和用戶(hù)ID關(guān)聯(lián)存到數(shù)據(jù)庫(kù)。如果不合格提示用戶(hù)重新采集。存儲(chǔ)策略上我建議只存FACE_TOKEN不存原始圖片。原因有兩個(gè)一是FACE_TOKEN體積小存儲(chǔ)成本低二是原始圖片涉及用戶(hù)生物特征信息存儲(chǔ)和傳輸都有合規(guī)風(fēng)險(xiǎn)能不存就不存。如果業(yè)務(wù)確實(shí)需要保留原始圖片一定要加密存儲(chǔ)并且明確告知用戶(hù)。還有一個(gè)細(xì)節(jié)一個(gè)用戶(hù)可以錄入多張基準(zhǔn)人臉嗎技術(shù)上可以但我不建議。多張基準(zhǔn)圖會(huì)增加比對(duì)時(shí)的選擇邏輯而且用戶(hù)自己也不知道該用哪張。一張高質(zhì)量的基準(zhǔn)圖就夠了如果用戶(hù)覺(jué)得當(dāng)前基準(zhǔn)圖不好可以重新錄入覆蓋。5. 上線(xiàn)前必須處理的異常情況與邊界問(wèn)題5.1 網(wǎng)絡(luò)超時(shí)與接口限流的應(yīng)對(duì)方案百度AI的接口調(diào)用是走公網(wǎng)的網(wǎng)絡(luò)超時(shí)是必須考慮的問(wèn)題。我在項(xiàng)目里遇到過(guò)好幾次因?yàn)榫W(wǎng)絡(luò)抖動(dòng)導(dǎo)致比對(duì)接口超時(shí)用戶(hù)那邊看到的就是“登錄失敗”但實(shí)際上只是網(wǎng)絡(luò)問(wèn)題。應(yīng)對(duì)方案是設(shè)置合理的超時(shí)時(shí)間并且做重試。超時(shí)時(shí)間我一般設(shè)5秒太短容易誤判太長(zhǎng)用戶(hù)等不及。重試策略是第一次超時(shí)后隔500毫秒重試一次如果還超時(shí)再隔1秒重試一次三次都失敗才返回錯(cuò)誤。重試的時(shí)候要注意如果是活體檢測(cè)失敗這種業(yè)務(wù)錯(cuò)誤不要重試因?yàn)橹卦嚱Y(jié)果也一樣。接口限流是另一個(gè)問(wèn)題。百度AI的接口有QPS限制具體數(shù)值取決于你的賬號(hào)等級(jí)。如果短時(shí)間內(nèi)大量用戶(hù)同時(shí)登錄可能會(huì)觸發(fā)限流返回“請(qǐng)求過(guò)于頻繁”的錯(cuò)誤。應(yīng)對(duì)方案是在服務(wù)端做一層隊(duì)列把比對(duì)請(qǐng)求排隊(duì)處理控制并發(fā)數(shù)。或者提前申請(qǐng)更高的QPS配額根據(jù)業(yè)務(wù)峰值來(lái)定。import time def compare_with_retry(live_image, base_token, token, max_retry3): for i in range(max_retry): try: result compare_face(live_image, base_token, token) if result[success] or result.get(error_code) 0: return result # 業(yè)務(wù)錯(cuò)誤不重試 if result.get(error_code) in [222207, 222208]: return result except requests.Timeout: pass time.sleep(0.5 * (i 1)) return {success: False, msg: 網(wǎng)絡(luò)異常請(qǐng)稍后重試}5.2 活體檢測(cè)失敗與照片攻擊的防范活體檢測(cè)是防止照片攻擊的關(guān)鍵。但活體檢測(cè)本身也有失敗率正常用戶(hù)可能因?yàn)閯?dòng)作不規(guī)范、光線(xiàn)不好等原因被判定為“非活體”。這時(shí)候不能簡(jiǎn)單地說(shuō)“你是照片”而要引導(dǎo)用戶(hù)重新操作。我的做法是活體檢測(cè)失敗后返回一個(gè)明確的提示比如“請(qǐng)確保是本人操作并保持光線(xiàn)充足”然后讓用戶(hù)重試。如果連續(xù)三次活體檢測(cè)失敗就降級(jí)到密碼登錄避免用戶(hù)被卡死。照片攻擊的防范除了活體檢測(cè)還可以加一些輔助手段。比如檢測(cè)圖片的EXIF信息如果發(fā)現(xiàn)是用相機(jī)拍攝的原始照片而不是實(shí)時(shí)采集的就拒絕?；蛘咭笥脩?hù)在采集時(shí)做一個(gè)隨機(jī)動(dòng)作比如眨眼、轉(zhuǎn)頭增加攻擊難度。但這些手段會(huì)增加用戶(hù)操作成本需要權(quán)衡。5.3 用戶(hù)換臉、整容、年齡變化導(dǎo)致比對(duì)失敗的兜底這是一個(gè)容易被忽略但實(shí)際會(huì)發(fā)生的問(wèn)題。用戶(hù)換了發(fā)型、戴了眼鏡、胖了瘦了都可能導(dǎo)致比對(duì)分?jǐn)?shù)下降。如果閾值定得死這些用戶(hù)就登錄不了了。兜底方案有幾個(gè)一是允許用戶(hù)重新錄入基準(zhǔn)人臉在登錄失敗頁(yè)面上提供“重新錄入”的入口。二是設(shè)置一個(gè)“寬容期”比如比對(duì)分?jǐn)?shù)在70到80之間時(shí)不直接拒絕而是要求用戶(hù)輸入密碼作為二次驗(yàn)證驗(yàn)證通過(guò)后允許登錄并提示用戶(hù)更新基準(zhǔn)人臉。三是記錄每次比對(duì)的分?jǐn)?shù)如果發(fā)現(xiàn)某個(gè)用戶(hù)的分?jǐn)?shù)持續(xù)下降主動(dòng)提醒用戶(hù)更新基準(zhǔn)圖。整容這種情況比較極端但確實(shí)存在。如果用戶(hù)整容后比對(duì)失敗只能走重新錄入流程。所以在產(chǎn)品設(shè)計(jì)上重新錄入的入口一定要明顯、好找。6. 實(shí)測(cè)數(shù)據(jù)與性能優(yōu)化讓登錄成功率穩(wěn)定在可用水平6.1 不同光線(xiàn)條件下的比對(duì)分?jǐn)?shù)分布我在一個(gè)測(cè)試環(huán)境里做了幾組對(duì)比實(shí)驗(yàn)用同一個(gè)人的基準(zhǔn)圖在不同光線(xiàn)條件下采集實(shí)時(shí)圖看比對(duì)分?jǐn)?shù)的變化。結(jié)果如下光線(xiàn)條件平均比對(duì)分?jǐn)?shù)通過(guò)率閾值80室內(nèi)正常光92.398%室內(nèi)偏暗84.785%室內(nèi)偏亮/逆光81.276%室外陰天88.593%室外強(qiáng)光79.668%從數(shù)據(jù)可以看出光線(xiàn)對(duì)識(shí)別效果的影響非常明顯。強(qiáng)光和逆光是最差的情況通過(guò)率只有不到七成。所以客戶(hù)端的光線(xiàn)引導(dǎo)不是可選項(xiàng)而是必選項(xiàng)。6.2 圖片壓縮對(duì)識(shí)別速度和準(zhǔn)確率的平衡客戶(hù)端采集的圖片如果不壓縮一張可能好幾MB上傳耗時(shí)不說(shuō)百度AI接口處理起來(lái)也慢。我測(cè)試了不同壓縮比例下的表現(xiàn)長(zhǎng)邊像素圖片大小上傳耗時(shí)比對(duì)耗時(shí)比對(duì)分?jǐn)?shù)變化1280約800KB1.2s0.8s基準(zhǔn)640約200KB0.4s0.5s-0.5分480約120KB0.3s0.4s-1.2分320約60KB0.2s0.3s-3.8分結(jié)論很清晰壓到640px長(zhǎng)邊是性?xún)r(jià)比最高的選擇圖片大小降到200KB左右比對(duì)分?jǐn)?shù)只降了0.5分幾乎可以忽略。再往下壓分?jǐn)?shù)下降就比較明顯了。所以我在項(xiàng)目里統(tǒng)一用640px作為采集圖片的長(zhǎng)邊上限。6.3 并發(fā)場(chǎng)景下的Token管理與接口調(diào)用優(yōu)化當(dāng)多個(gè)用戶(hù)同時(shí)登錄時(shí)Token管理和接口調(diào)用會(huì)成為瓶頸。我做過(guò)一個(gè)壓測(cè)單臺(tái)服務(wù)端在不做優(yōu)化的情況下大概能支撐每秒20次比對(duì)請(qǐng)求。優(yōu)化后能到每秒80次左右。優(yōu)化的點(diǎn)主要有三個(gè)一是Token緩存避免每次請(qǐng)求都去換Token二是HTTP連接復(fù)用用連接池而不是每次新建連接三是異步處理把比對(duì)請(qǐng)求放到線(xiàn)程池或者協(xié)程里不阻塞主線(xiàn)程。import requests from concurrent.futures import ThreadPoolExecutor session requests.Session() executor ThreadPoolExecutor(max_workers20) def async_compare(live_image, base_token, token): future executor.submit(compare_face, live_image, base_token, token) return future用Session復(fù)用連接用線(xiàn)程池控制并發(fā)這兩個(gè)改動(dòng)就能把吞吐量提升好幾倍。7. 一些只有踩過(guò)坑才知道的實(shí)操經(jīng)驗(yàn)7.1 FACE_TOKEN的有效期與更新時(shí)機(jī)FACE_TOKEN不是永久有效的百度AI的文檔里說(shuō)它“長(zhǎng)期有效”但實(shí)際測(cè)試下來(lái)如果長(zhǎng)時(shí)間不用可能會(huì)失效。我遇到過(guò)用戶(hù)三個(gè)月沒(méi)登錄再登錄時(shí)發(fā)現(xiàn)基準(zhǔn)圖的FACE_TOKEN已經(jīng)無(wú)效了比對(duì)直接報(bào)錯(cuò)。所以我的做法是在用戶(hù)每次成功登錄后順便更新一次基準(zhǔn)圖的FACE_TOKEN。具體來(lái)說(shuō)如果用戶(hù)是用FACE_TOKEN比對(duì)的比對(duì)成功后把實(shí)時(shí)圖再調(diào)一次檢測(cè)接口拿到新的FACE_TOKEN覆蓋舊的。這樣基準(zhǔn)圖始終保持新鮮不會(huì)因?yàn)殚L(zhǎng)期不用而失效。7.2 錯(cuò)誤碼的完整梳理與用戶(hù)提示的映射百度AI的接口會(huì)返回各種錯(cuò)誤碼如果直接把錯(cuò)誤碼拋給用戶(hù)用戶(hù)根本看不懂。我整理了一份常見(jiàn)錯(cuò)誤碼和用戶(hù)提示的映射表錯(cuò)誤碼含義用戶(hù)提示0成功-222207未檢測(cè)到人臉請(qǐng)確保臉部在畫(huà)面內(nèi)222208人臉模糊請(qǐng)保持穩(wěn)定重新拍攝222209人臉太小請(qǐng)靠近一些222210人臉太大請(qǐng)離遠(yuǎn)一些222211人臉角度過(guò)大請(qǐng)正對(duì)攝像頭222212光照太暗請(qǐng)到光線(xiàn)充足的地方222213光照太亮請(qǐng)避免逆光216101參數(shù)錯(cuò)誤系統(tǒng)異常請(qǐng)稍后重試216200空?qǐng)D片請(qǐng)重新拍攝這份映射表直接決定了用戶(hù)看到提示時(shí)的體驗(yàn)。提示要具體、可操作不要只說(shuō)“失敗”。7.3 灰度發(fā)布與降級(jí)策略的實(shí)際操作人臉識(shí)別登錄上線(xiàn)時(shí)不要一次性全量放開(kāi)。我的做法是先灰度10%的用戶(hù)觀察一周的登錄成功率和誤識(shí)別率。如果數(shù)據(jù)正常再逐步擴(kuò)大到50%、100%?；叶绕陂g如果發(fā)現(xiàn)異?？梢钥焖倩貪L到密碼登錄。降級(jí)策略也要提前設(shè)計(jì)好。當(dāng)百度AI接口不可用、或者錯(cuò)誤率超過(guò)閾值時(shí)自動(dòng)切換到密碼登錄并給用戶(hù)一個(gè)提示“人臉登錄暫時(shí)不可用請(qǐng)使用密碼登錄”。這個(gè)切換邏輯要寫(xiě)在服務(wù)端不要依賴(lài)客戶(hù)端判斷。7.4 用戶(hù)隱私告知與合規(guī)注意事項(xiàng)最后說(shuō)一個(gè)容易被技術(shù)開(kāi)發(fā)者忽略的點(diǎn)隱私告知。人臉信息屬于敏感個(gè)人信息采集前必須獲得用戶(hù)明確同意。我的做法是在錄入人臉之前彈出一個(gè)告知頁(yè)面說(shuō)明采集人臉的目的、存儲(chǔ)方式、使用范圍用戶(hù)點(diǎn)擊“同意”后才能繼續(xù)。這個(gè)頁(yè)面不能默認(rèn)勾選必須用戶(hù)主動(dòng)點(diǎn)擊。另外如果業(yè)務(wù)涉及未成年人還需要額外的監(jiān)護(hù)人同意流程。這些合規(guī)細(xì)節(jié)雖然繁瑣但一旦出問(wèn)題后果比技術(shù)bug嚴(yán)重得多。人臉識(shí)別登錄這個(gè)功能技術(shù)實(shí)現(xiàn)本身并不復(fù)雜難的是把各種邊界情況處理好讓它在真實(shí)場(chǎng)景下穩(wěn)定可用。我上面寫(xiě)的這些都是實(shí)際項(xiàng)目中驗(yàn)證過(guò)的做法你可以直接參考。如果你的項(xiàng)目場(chǎng)景比較特殊比如光線(xiàn)條件特別差、或者用戶(hù)群體比較特殊可能需要額外調(diào)整參數(shù)和策略。核心原則就一條不要假設(shè)用戶(hù)會(huì)按照你預(yù)期的方式使用要把所有可能的異常都考慮到。