主題：新技術與應用

時間：2016年4月21日下午

地點：北京國際會議中心201會議室

主持人：

大家好！

我們下午的會議即將開始，我在這里自我介紹一下，我是QCon

的主編，我們QCon有兩個主編，一個是大家比較熟悉的臧秀濤，一個

是我。沒有特別多的主持經驗，還請各位多多擔待。

我們這個專題是《新技術應用》，下午有騰訊、滴滴和搜狗、中信

銀行的講師為大家分享。首先讓我們看一下第一個出場的中信銀行軟

件開發中心系統分析和設計王晶老師，他2015年才加入中信銀行，現

在在這個領域有十多年的工作經驗，他分享的主題是《人臉識別在商

業銀行的應用以及接受挑戰》，讓我們看一下到底有哪些痛點，大家掌

聲歡迎。

王晶：

大家下午好！

我是來自中信銀行的王晶，今天很榮幸參加QCon2016北京站技術

開發大會。今天想借這個機會跟大家分享一下人臉識別技術在商業銀

行的應用情況，以及我們面對的挑戰。其中會介紹業務相關的需求，

應對業務需求技術構架的設計，以及我們具體遇到的哪些實際問題，

做出的改進，以及遺留的問題目前還沒有更好的解決方案。隨著業務

的發展，技術構架經受更多的挑戰，也需要跟業務需求一起演進，最

后一部分是總結。

我今天演講的重點是如何應用人臉識別技術，來構建銀行行業的

技術方案，滿足銀行行業的業務需求，重點在這個地方。

第一，對銀行行業來說相比互聯網有特別的地方，它是穩健經營、

風險管控比較高的地方。它首先要識別客戶的身份，大家可以試想一

個公司必須對他的客戶有起碼的了解。如果你不知道你的客戶是誰，

你的客戶做什么樣的業務，它的身份怎樣，你無法提供一個高質量的

客戶服務，給客戶提過個性化的服務，所以這也是高質量客戶服務的

基礎。

我不知道哪些是金融行業的，從國際上看巴塞爾委員會97年推行

了KYC概念，04年巴塞爾委員會要求銀行建立以客戶為基礎的身份審

查程序，你要了解你的客戶身份，以及客戶的業務。傳統的銀行都有

它的風控、內審和外部審計，要求銀行定期辨識客戶的身份，確定業

務運行是合規的。

在我國身份識別的情況。97年和2000年對于巴塞爾委員會的KYC

概念，推出實名制，你要帶著身份證辦理業務。06年從立法的角度頒

布了《洗錢法》，你可以通過技術手段確認客戶的真實身份。特別是

2015年12月，大家從一些媒體上看到，央行發布了通知，鼓勵有條

件的銀行使用生物識別技術，結合其他的手段來識別客戶的身份。這

里強調的是，這個手段只是作為輔助的手段，并不是作為唯一的手段

來辨識客戶的身份。

簡單看一下商業銀行的場景，大家可以看到反洗錢，你做存款開

戶、結匯業務之前，首先要辯明你的身份是真實的身份，冒用其他人

身份證不會辦理這樣的業務。大家日常辦信用卡，這些是銀行風險相

對高的地方，這些需要身份識別。包括需要對VIP客戶識別，如何為

你的VIP客戶提供個性化、精準化的營銷，這些也需要識別客戶的身

份。

重點看一下人臉識別目前有哪些已經上線的應用，從中信銀行目

前已經上線的。比如說你在柜臺辦業務，它可以通過刷臉的方式進行

識別身份進行開卡業務。第二個是VTM就是視頻柜臺終端，你也可以

在VTM上做開卡、消卡、掛失、存款證明，這些去柜臺辦的業務都可

以在自助終端上辦。第三個你可以通過自己的移動設備，通過刷臉的

方式申請，再到就近的網點領卡，這個都是通過刷臉實現的。業內同

業有銀行在去年八月份推出在ATM上面進行小額的取款，進行刷臉的

方式，一個是你必須到ATM上，在網點的周圍，再一個是小額的取款。

互聯網金融有刷臉支付，還有刷臉貸款。比如說保險和證券行業都有

很多的應用。

因為現在央行不允許遠程開戶，這對國內網上銀行微眾銀行有影

響。其中有一個實名制電子帳戶，這種帳戶現在已經有商業銀行嘗試

用遠程刷臉的方式進行遠程開戶，作為一種新業務的探索。

現在給大家介紹行業的特點，中信銀行到底做了哪些。中信銀行

在商業銀行或者是國有銀行實踐人臉識別技術相對比較早。去年11

月上了第一款應用，這塊的業務場景可以跟大家參考一下。你辦業務

首先可以通過聯網核查取得照片，同時根據現場的照片，有一個業務

閾值告訴你是通過，還是不通過，通過這種方式來輔助來辦業務客戶

身份辨識，它的好處不光是便利性。還有一個好處，柜員對于是人都

有一個主觀的判斷，主觀特性比較高，沒有統一的程序可以采用，可

以人臉識別輔助判斷可以幫助業主降低風險，杜絕漏洞。

第二塊業務剛才提到的VTM,視頻柜臺機，這個也是通過跟遠程

客服人員進行視頻交互，通過刷臉之后可以辦很多你必須要跑到柜臺

可以辦的業務，你現在可以在自助終端上辦理，方便客戶的使用。

第三塊是移動終端的遠程業務，這塊比如說是信用卡電子渠道，

以后用戶申請信用卡，他可以在家里通過手機申請，通過刷臉的方式

可以申請。從銀行做這些業務的方式來看，首先是做人工渠道，再一

個是電子渠道。為什么是這種方式呢？因為人工渠道，比如說在柜臺

或者是VTM都是在銀行的網點，有人員輔助幫你判斷。如果想做人臉

識別的攻擊是比較困難的。移動終端客戶可以在任何時間、任何地點

用，這時候不可避免有些人可能會嘗試人臉識別的攻擊，嘗試會破解,

這塊后面會詳細提到。

目前應用的效果是，目前的業務大概兒萬筆，量不是很大，后續

會接入很多互聯網渠道的應用，甚至嘗試私有云或者是公有云的方式,

業務量會更大，這對業務構架提出更多的挑戰。目前人臉識別對比的

速度是1秒到1.5秒，我們也在不斷的優化和探索，希望把時間縮的

更短。目前基本上是1：1的圖片對比，比如說做VIP客戶識別，可能

做1對N的圖片識別。

下面感性的認識一下，我行目前做了這三個識別解決方案。其中

有一個案例，某客戶在分行辦業務，他拿著身份證辦，人工看這個身

份證的照片看不出任何區別，基本上是一個人。通過人臉識別的程序,

我們這個程序跟銀行柜臺前端界面集成在一起，它的分值只有40分,

柜面人員根據業務流程出示證件沒有帶，詢問問題的時候問答入流，

但是問到他家人更細節的信息，比如說生日這些他就答不上來了，柜

員跟他解釋，我們的系統識別出來你可能跟身份證不是同一個人，如

果不是一個人需要出示輔助證件、授權委托書，我們不允許拿別人的

證件辦業務，跟他溝通以后是他拿弟弟的身份證來辦業務，這就杜絕

了冒用其他身份證辦業務，這樣是不是也降低客戶體驗了呢？其實對

銀行行業有一定的特殊性，它以風險控制為第一要求，銀監會對他有

相關的要求，所以在這個基礎上進一步提高客戶體驗，這是我們后續

要做的。

簡單看一下為什么最近大家在媒體上看到人臉識別，為什么只有

刷臉最近會占據很多版面，為什么刷臉會這么火，傳統的密碼可能會

忘，簽名對于電子識別，比如說虹膜、指紋，這是一種侵入式的方式,

用戶感受到你用這種方式在做識別，用戶體驗不好，處理速度慢。還

有一個跟大的缺點，樣本庫很難建立，試想一下作為商業銀行面對客

戶時是全國甚至是全球的客戶，你如何采集紅膜、指紋、掌紋數據樣

本信息。但是對于人臉或者照片來說，這就相對簡單容易的多。

比如說蘋果手機如果手上有水識別程度比較差，靜脈也不是永久

的識別方式，可能會變，隨著年齡的變化，因為它的采集設備非常龐

大。人臉識別，它的特點正好可以解決剛才提到的兒個問題。首先它

的便利性非常高，每個人都會帶著自己的臉，不會說忘帶卡或者是手

機，因為它的處理速度快。大家可以看到，目前我們是1秒到1.5秒,

以后可能更快。它對銀行比較特殊，其實我們有它的數據源，比如說

人行和公安部聯網核查圖片，我們作為比較可靠的數據源。去年有些

銀行業推出顏值采集，實際上也是收集數據源的操作。我自己的感受

還有兩點，一個是隨著移動設備的普及，視頻采集，包括人臉采集越

來越方便，不像虹膜專有設備，現在每個人都有手機和PAD,更重要

的一點是軟件的發展，這兒年隨著云計算處理能力的提升，以及大數

據，包括深度學習跟算法相關的演進，人臉識別商用現在已經成為一

個非常靠譜的事情。所以商業銀行正式把它納入到業務范疇之內，這

就是人臉為什么火的兒個原因。

簡單看一下，除了金融行業，其實還有很多其他有趣的應用。如

果大家比較了解可能都知道，信息系統通過刷臉登錄，不需要密碼。

包括身份證也有很多重復的情況，幫助解決身份證重復，幫助公安部

門可以做人臉識別去重的操作。提高工作效率，通過人臉識別的考勤

簽到，包括去火車站和機場快速通關，這些都是非常快速的應用。我

了解像FaceBook通過照片可以識別出照片的朋友微博ID都是哪些，

這些都是它的應用。

第二，技術構架和識別效果，以及識別的改進。人臉識別的過程,

目前是從視頻流中截出多張照片，通過質量檢測程序，這個后面會具

體說。檢測出來質量能達到我們閾值的一張照片，這張照片會做人臉

檢測，比如說人臉的特征、眼角、嘴角、瞳孔等等方式。檢測出人臉

做圖片裁剪，下一步是提取特征值，這里面主要是基于深度學習相關

的算法。特征值提取以后做特征對比，最后是返回識別度，它是百分

比的相似度，這個相似度我們也會定一個業務的閾值，跟業務閾值比,

它能告訴前端，這兩個人究竟是同一個人，還是不是同一個人。

下面看一下我們人臉識別的邏輯技術構架，左邊這三塊黃塊表示

的后面會繼續介紹。質量檢測是用來從視頻流或者是拍的多張照片中

挑出質量最高，適合人臉識別的一張照片。圖片裁剪是根據人臉識別

出定位坐標以后，對圖片和人臉進行裁剪。中間這一部分是目前接入

的應用，對于銀行行業來說，我們的接入是希望能比較好的與現有流

程進行集成，而不希望對業務流程做太多的改造。

右邊是后端的簡單結構，相對比較簡單，行業會對專門的報文。

我們這邊有一個集群，我們基于這個實現高校處理，用來支持大并發、

高響應的要求。右邊來看，我們第一步可能會對相關的信息做聯網核

查，聯網核查會返回人行或者是公安部的圖片信息，有一個流控機制,

因為作為人行是比較關鍵的，向很多銀行提供服務，如果你的互聯網

接入流量大，如果把核查壓跨了受影響非常大。入庫以后我們得到聯

網核查的照片，這個照片跟現場的照片，我們跟人臉識別的引擎提取

特征值，做特征值的比較，處理完以后返回結果，每一次對比的機構

都存在關系數據庫，這是原數據。這些原數據會導入到下游的ODS和

報表系統，供業務部門，比如說運營管理部門做進一步的業務分析，

這是一個簡單的技術構架。

一個典型的處理流程跟大家簡單介紹一下，以柜面的處理為例，

可能分成三步。第一步如果有客戶來銀行辦業務，他首先拿著二代身

份證，在讀卡器中讀取信息，首先判斷身份證是否真實，把核查的信

息跟現場從視頻流中采集的信息，送往人臉識別的后臺，在送后臺之

前首先會做活體檢測，避免防止攻擊，這在互聯網渠道多一點，在柜

臺可能不太需要。同時需要做質量檢測和圖片裁剪，這個請求會把這

兩張圖片發到人臉識別服務集群，核查之后會發到人臉識別的引擎，

在引擎中做特征值提取，特征值比較返回結果。

第二步是人工的判斷，這一步其實也很有意義，人工判斷兩個人

到底是不是一個人，可能跟系統判斷的結果是相反的。如果不一致，

可能從業務流程，他會要求客戶出示輔助證件。事后我們根據人工跟

機器判斷的結果既然不一致，識別引擎從算法角度可能改變了，它不

斷通過做數據訓練，然后升級識別引擎，來提高它的識別率。

第三步是做一些相關查詢之類的，這是比較典型的處理流程。接

下來簡單看一下，雖然服務比較簡單，但是服務設計有兒個不同層面

跟大家分享一下，我們的服務是面向全行發展標準化的服務，是規范

性的。服務本身支持版本化，我們后續可能有不同的服務，比如說報

文形式，我們可以做的相互兼容，支持不同的版本。

在容錯考慮方面有些機制，比如說我們已經識別成功，但是在入

庫跟應用管理平臺出錯，我們允許正常返回，異步處理，陷落地，后

人工進行處理。通過超時控制，包括對超時的統計，服務在多長時間

內超過多少秒的請求，我們會記錄下來，同時也有運維相關的報警機

制。我們還有一些像從路由幫忙實現服務容錯的設計。

剛才也提到了服務的流控，因為我們接入很多不同的應用。尤其

像聯網核查需要進行保護，需要進行流控的機制。對于我們來說，我

們支持不同的接入方，不同的交易來實現流控，同時支持流控不同的

陣容，不同的接入系統。如果是阻塞性任務可能是比較耗時的，這種

情況下我們很難做流控，我們的解決方式就是通過異步的方式請求，

然后再寫給Netty,通過這種方式我們可以處理海量的并發請求，而

且是在阻塞性任務的情況下。

接下來看一下服務的拓展性，因為本身服務是一個無狀態的服務,

所以橫向狀態相對比較容易，使用負載均衡就可以擴展。未來隨著業

務的發展，可能不光水平拓展，還需要支持服務的彈性橫向擴展，后

面也會介紹如何實現這一點。同時我們設計一個比較有特點的地方，

我們不僅僅使用一種識別引擎，我們目前支持多種識別引擎。同時在

生產中收集不同引擎對于銀行業務處理的不同效果，然后進行優化和

比較。

服務的高可用，它的故障檢測、故障切換，服務器集群是使用主

備機房的方式。我們目前做的持續集成和灰度發布，響應業務的快速

迭代和快速上線的要求。

這部分并不是前臺和后臺非常多的技術內容，但是也是我們實踐

過程中從業務到解決方案過程當中發現的難點，跟人臉識別相關的，

跟大家簡單分享一下。

首先是上線之后發現光線仍然對識別有較大的影響，大家可以看

到玻璃反光，這個對識別效果有較大的影響，現在我們并非有什么可

以高新技術可以解決。目前解決的是外置攝象頭，調相對的角度來解

決這個問題。背景逆光，目前我們通過在柜臺內放置合適的光源來解

決這個問題。第三個是自動對焦，換上自動對焦攝象頭就可以解決了。

人的生理特征的差異，比如說80年上海灘的周潤發跟86年英雄本色

的周潤發兒乎分辨不出來。通過人工跟業務對比和自動對比的差異，

通過數據訓練通過算法的角度可以得到比較好的解決。

第三個難點是姿態和配飾，人戴的眼鏡，不能帶墨鏡，中間是透

明玻璃的，這些也是通過算法可以解決比較好的。我們進行過大量的

測試，這些對于識別的效果沒有太多的影響。

接下來談一下目前我們遺留一些難以解決的問題，比如說化濃妝

的問題，有的時候看不出是同一個人。再比如說整容的問題，戴非常

深的墨鏡，戴銀色反光的墨鏡，雙胞胎長的確實非常像，以及可信生

物源，這些問題都是從人臉識別技術角度很難解決的。

我們還有其他的方式，就是人臉質量檢測模塊，這里面有兒個參

數。比如說他會檢測人頭的角度，左眼、右眼、嘴巴的程度，通過這

些我判斷這個照片是不是符合人臉識別引擎的要求，如果不符合可能

需要從新采集，避免了不合格的照片到后端造成對業務的影響。經過

最終的改進，目前的誤認率小于千分之一，我們之前對連部的裁剪可

能有問題，我們做了應用上的優化。包括人行有些圖片是帶網文的，

需要算法做不同的適應，這些后面都做了很多優化，所以達到了現在

的結果。

剛才也提到了人臉識別有沒有安全性的問題，其實是有的。比如

說有人通過照片跟視頻的方式做攻擊，有些人做一些假的面具。如果

遠程的場景每個人都可以嘗試，對于這些我們怎么處理呢？我們提供

了后期檢測方式，它會對連部的關鍵點檢測和跟蹤，還有3D的方式,

要求用戶會做幾種姿態，比如說眨眼、點頭、左右搖頭這種方式來確

定用戶是真實的人，而不是照片或者是一段視頻，這個方式其實也有

它的問題，用戶體驗不是特別好，要求用戶做一些比較奇怪的動作，

后續我們還看3D人臉檢測，通過紅外的方式來判斷是一個人。

同時活體檢測，我們有兩個可以供大家參考，實現黑名單機制和

重試的次數，防止惡意的用戶不斷嘗試進行人臉識別的攻擊。魔高一

尺，道高一丈，3D打印人臉效果，目前識別比較困難。右邊是電影中

的畫面，對于通過安全文件的檢測，這個檢測不光是刷臉，它還會手

臂的擺動和人的神態，如果跟原來人不是同一個人，馬上會進行電擊,

警察馬上會過來。

第三，技術構架的挑戰和演進，業務發展對技術的進一步需求，

當然技術也會從某些角度引領業務的發展。業務可能需要一個整體的

生物識別技術綜合應用，需要建立一個生物識別技術的平臺，不僅僅

是人臉識別，還包括其他的。比如說指紋、手寫等等方面的綜合應用。

剛才也看到了攻擊跟被攻擊的技術不斷引進，作為銀行對安全性非常

敏感的業務如何應對。還要提升處理速度，目前是一對一的圖片對比

的場景，以后對于識別VIP客戶可能是一對多以及其他，對于處理速

度和數據量，對于并發請求的要求會更高。支持動態配置，自適應優

化。比如說我們可以通過程序來控制終端的采集設備，比如說在不同

的光線下實現不同的曝光程度，包括對于服務端閾值的動態調整。

看一下我們對未來技術構架的演進方向，首先有生物識別客戶端,

我們可以支持更多的協議。后端的處理模塊，實際上跟協議本身無關。

后續我們這邊不光是人臉識別，它非常適合部署在云平臺，我們后續

整個更替構架是基于行業業務的云平臺構架，來打造生物識別的PaaS

服務，這是我們后續的重點。

從剛才的邏輯構架上來，我們還有幾點其他的改進。因為我們會

得到非常海量的圖片數量，比如說內容管理平臺，同時整個服務希望

能夠做成云服務的形式，實現云平臺多活，多數據中心的改造，提高

它的可用性，以及就近訪問的特點。

我們自己總結了一下，從商業銀行的角度，剛才的開發對我們有

哪些挑戰呢？我們跟相關的業內人士做過探討，銀行的技術構架是比

較傳統的，隨著去IOE的變化，后續擁抱云平臺，需要對構架做出開

發，需要與時俱進。剛才提到人臉識別技術非常適合做PaaS服務，目

前行內已經有laaS相關的服務，如何打造PaaS服務，我們計劃在今

年對人臉服務做PaaS服務的試點上線應用，需要解決服務的發現、編

排等等這樣的技術構架。

另外，容器跟現有AAS平臺的集成，這些在銀行中如何跟PaaS

服務進行結合，這是需要我們研討的事情。也需要自服務門戶和實時

部署，這些基礎機制的支持。同時一,銀行可能是開發規范比較嚴格的

地方，后續我們也需要有其他各種規范。其中有一個比較有特點的地

方，就是互聯網公司可能會做自動化部署。比如說部署它的應用持續

上線改進，對銀行來講可能比較困難，銀行需要對上線的時間，包括

層層審批。所以這個如何跟自動化部署結合，也需要探討，有可能在

技術上支持。但是最終上線還是需要有審批等等類似的環節。

為了提高它的可用性，對多活、雙活應用的改造，這里面多數據

中心，你是通過DNS或者是二層往三層的改造，實現服務的路由。可

能涉及到數據復制跟存儲，這里面又涉及到數據移植性的問題，這些

都是我們的挑戰，以及跟后續改進優化的過程。

最后一部分是簡單的總結，人臉識別可以作為一個輔助手段，比

較好的解決商業銀行身份識別的需求。目前已經有了一些業務應用的

場景。但是現在需要強調的是，在銀行行業，它需要跟其他識別方式

結合使用，英國有一個銀行是完全的互聯網銀行，它的開戶機制就是

通過人臉完全在線，通過刷臉，當然它也是結合了聲音兩種方式，可

以非常簡單的完成開戶，這點目前是國內微眾銀行的瓶頸，目前央行

不允許這種業務。我自己來看，隨著人臉識別技術不斷發展跟其他技

術綜合應用，行業對這方面技術的積累，如果以后有可能開放這塊的

業務，對于無論是互聯網銀行，還是傳統的商業銀行都是非常大的契

機，可以基于做很多新業務的拓展和創新。

最后，剛才也提到了人臉識別非常適合作為云服務的形式，在我

們銀行作為私有云的部分存在，這就是我今天演講的內容，謝謝大家。

主持人：

非常感謝王晶老師帶來的精彩分享，我有個朋友上次跟他一起去

銀行，也是人臉識別。但是它那個認證失敗了，我一直嘲笑他，是因

為他顏值不夠，原來還有其他的原因，再次感謝王晶老師。

提問：

我想問兩個問題，第一個是關于安全性，現在做人臉識別需要把

人臉數據都要存儲在系統云端。怎么防止到時候人臉庫到時候被偷庫

了，這個有什么應對的方式嗎？

第二個問題，現在像VR技術的發展，很多VR設備是可以通過視

網膜投射技術，這樣的技術使得從軟件層面完全區分不出來你到底看

到的是真實的人臉，還是VI虛擬出來的人臉，對于這種欺騙的手段,

接下來馬上可能就會出現，有沒有技術上應對的方案呢？

王晶：

這兩個問題根據我的理解簡單跟大家討論一下，第一個問題，這

些數據都在我們數據中心，即使是云服務，也是私有云服務，這些放

在銀行的數據中心本身監管都有很嚴格的要求，不會存在整體泄露的

情況。

提問：

人臉識別能不能做成并不需要存儲你的指紋圖像，而只需要存儲

特征就可以完成識別和認證。

王晶：

人臉識別可以做到，我給大家介紹一個場景，因為有客戶隱私的

考慮。比如說我們對VIP客戶的識別，很多人來銀行辦業務，想識別

出其中一個人，來辦業務的人，在他不知情的情況下你拍到他，我們

的做法是對于這些圖片不做存儲，在芯片級別中做特征值的存儲。比

如說VIP客戶，來得人只是通過特征值的方式進行對比，不會做存儲。

提問：

是像UK上面的嗎？

王晶：

這是我們專有的設備，它有芯片和計算，這是專門做的。

你說的第二個問題關于VR或者是其他的攻擊方式，目前我們也在

探討一些類似3D成像或者是紅外的方式，它的成像究竟是一個視頻,

還是一個物體，或者是有溫度的人在前面做，而不是虛擬的一段視頻,

一段VR的影像就可以通過的。

提問：

你好，我想問一下這里面更多像是圖片的檢索，我輸入一張圖片

進去，把相似的圖片檢索出來。你剛才提到深度學習在圖片當中的應

用，因為深度學習參數規模是很大的，你們在這里面是怎么處理的呢？

因為我看到你們有圖象識別集群，你們是不是已經做了分布式的方法,

現有的框架你們用了哪些呢？

王晶：

我們目前是一個集群，因為本身服務是兩部分，一個是人臉識別

服務，這部分是通過負載均衡實現的。人臉識別的算法，我們有一套

內部的分布式調度程序。剛才說到深度學習算法級別的東西，這些東

西有些可能涉及到商業機密，只能大致說一下實現思路。比如說對于

人臉的檢測，包括深度學習來實現特征的檢索，如果對這些感興趣的

話，我們可以在會后溝通。

提問：

你好，我想問一下，是不是你剛才講的人臉識別檢索分布式系統,

現在屬于內部的項目？

王晶：

可以這么說。

提問:

以后有沒有類似提供一些API或者是三方合作的可能性。

王晶：

目前我們的定位還是應用于銀行內部，以后有可能會往公有云跟

私有云結合的方式。比如說像平安的金融，它已經對外提供了金融云

的服務。首先對于我們來說先把公有云做好，至少在同業做一些推廣,

包括面向互聯網金融做一些推廣也是有可能的。

提問：

因為我看到也有其他的公司在做人臉識別解決方案，你們的優勢

在哪里呢？

王晶：

銀行是以滿足銀行的業務為第一條件，它并不是像科技公司追求

技術做的最好，像微軟面向所有的科技公司，在不同的行業不同解決

方案，滿足業務的需求，這是它的第一要求。在這個基礎上，如果技

術成熟對外提供公有云服務也是可以的，所以它跟微軟的定位是完全

不同的，實際上這個完全是兩種想法。

主持人：

謝謝兒位踴躍提問的同學，也謝謝王晶老師精彩的解答，現在我

們休息十分鐘。

下面即將開始我們今天下午的第二場演講，大家應該都有滴滴出

行的APP,反正我現在已經離不開滴滴了，以前晚上打車的時候經常

遇到拒載，現在有滴滴已經好多了。我們非常有幸邀請到滴滴出行工

程生產力團隊研發技術總監齊賀老師，他演講的題目是《用數據驅動

滴滴產品決策》，大家掌聲有請！

齊賀：

大家下午好！

我叫齊賀，來自滴滴出行，我所在的部門是工程與生產力部門，

這個部門主要是為了提升滴滴運轉效率所組建的。今天要跟大家分享

的是滴滴從去年開始在做一件事情，這個事情其實在互聯網領域也被

反復的提及，特別是基于大數據發展的規模，這個詞匯不斷的在不同

的領域被大家提到，就是數據驅動。

在開始演講之前，我想先了解一下，在座的聽眾大家來自于哪兒,

有來自于互聯網的嗎？有來自于移動互聯網的嗎？大家有坐過AB測

試或者大家有產品和技術,涉及到AB測試場景的同學有多少呢？我相

信今天你們聽完我的分享會有一些收獲，這也是我們滴滴在實踐AB

測試將近大半年時間里面，我們所做技術上的沉淀，以及我們踩過一

些坑，希望大家能有所收獲。

先看一下大綱，首先給大家講一個故事，就是發生在滴滴APP里

面的故事，可能有的同學也經歷了這樣的故事。然后介紹一些方法，

一些相對通用，大家反腐提及的方法。再介紹一下滴滴數據驅動平臺

產品架構，以及對應的技術架構。最后給大家一些真言，如果你做AB

測試,你通過AB測試拿到某一些數據輔助決策或者直接產生決策的時

候，你要注意的點非常重要，最后是其他的技術。

我們先進入第一個，左側這張圖片是我們滴滴APP的截圖，這是

去年截圖。而這張截圖是由我們的大老板截的，當時在APP工具里面,

他把這張照片放上面提了一個問題，為什么我看到的車的數量少了，

為什么只有五輛，昨天我看到要比這個數量多很多。這時候大家反應

很迅速，這時候有一個用跳出來說了，程總是這樣的，我們最近剛上

了一個應用，通過一些算法的匹配，找到對于打開APP的用戶來講，

最可能被匹配到的五輛車。這樣做的優勢是可以讓用戶在打到車的過

程里面，跟他看到的車有相對一致的體驗。

但是程總說了，我不是這么考慮的，我看到車的第一感覺是，作

為一個重度用戶，我首先的感覺是不安全，是不是滴滴司機都跑了，

沒有車了。特別是出租顯示十輛，快車顯示五輛，這樣一對比的話，

這種不安全感又加強了。但是為什么不改成十輛呢？如果用戶看到了

很多車，但是結合很多條件，比如說司機的接單意愿，司機所處的位

置以及家的位置等等很多因素考量。如果用戶看到很多車，但是打不

到車，他會抱怨。

這時候有一個問題面對我們，放在這里究竟是五輛車或者是十輛

車好，或者什么樣一個數字是最好的。包括老板，他也沒有說我們要

顯示多少輛，知識大家覺得這么多的方案里面，我們非常難以選擇到

合理的方案。這個故事在快結束的時候我給大家拋出這個答案，大家

也可以考慮一下，你覺得五輛好、十輛好或者是多少輛更合適，放在

滴滴APP里面開放給用戶。

我說一個背景，滴滴APP大家基本上都用過，它的發展時間其實

是比較短的，截止到目前也沒有滿四年。當然它的融資速度，包括市

值，以及我們公司的規模增長是非常快的，這都來自于我們最近對外

披露的信息。比如說3月21號我們訂單首次達到了一天綜合1000萬

單，我們在去年艾瑞做的市場報告里面，我們在專、快車市場訂單率

達到了88.4,日均訂單量占比84.1%,截止到現在我們仍然有很多競

爭對手，這些公司并沒有放棄這個非常大的蛋糕。其實我們面對的挑

戰非常大，可能少有不慎就有非常大的風險。

剛才我們也提到了，公司人員規模擴大的比較快，往往在移動互

聯網或者是互聯網公司里面有一個比較普遍的現象，產品經理會有特

別多的想法，功能會不斷的疊加，越來越多的人會置疑，因為研發資

源有限。究竟有沒有效果？我們做這么多東西有沒有效果，我們做了

很多東西好像沒有什么用。我們在日常的研發活動里面，我們也會反

復聽到大家問這樣一些問題。

比如說最近我訓練出來兒個模型，究竟哪個模型比較好，比如說

這個模型是好的司機模型，適合按好司機的策略匹配。如何證明通過

機器模型的學習，比某一個同學調的運營配置更好。還有就是我有很

多新的產品方案，然后基于這些產品方案，我該如何做選擇先做哪個

或者是AB兩種方案里面哪個更好，我想測試一下在西二旗，這些用戶

對某一個功能的接受程度或者是他們和非西二旗其他用戶的接受程度

怎么樣。我們怎么衡量我新上功能的效果，怎么證明它有用呢？

這些功能我希望先從5%還是，如果效果0K的話我再逐步轉全流

量，這些都是我們產品線同學經常提到的。介紹這個故事和我們遇到

的場景之后，我想先跳出來，我們了解一些相對基礎的概念，這對接

下來我們講的平臺比較有幫助，我們用非常短的時間了解這兒個概念。

首先叫定向發布，大家可以看最上面，我們打開叫所有人群，比如說

滴滴所有的用戶，我有一些功能，我希望它能夠按照一定的規則把人

群篩選出來，然后把一個功能投放給特定的人群，我們把它叫做目標

人群，類似漏斗一樣的方式，讓符合條件、符合規則的用戶漏下來，

讓不符合的人流下去，這是定向投放。比如說最常見的基于地域的，

比如說我投放到北京，我們把人群的屬性做一個抽象。比如說時間，

我希望在某一個區域的某一個時間段，把功能投放給用戶，這其實也

是一種屬性。

接下來我們再看另外一個概念，可能這個詞匯聽的更多一些，我

把規則放的更大一些，添加了一線城市用戶，這里面又會帶來很大量

的用戶。目標群體也會被擴充，相對于剛才提到的定向，人群在逐步

的擴大。當我把規則完全去掉的話，意味著所有的人群都會放進來，

這個時候意味著已經是全流量的發布。在我們的理解里，它會更體現

出一個過程，從小到大，逐步一級一級的發布出去。

然后是AB測試，這意味著我有兒種對應的方案舉棋不定，我可能

首先找到一個目標人群。然后讓他們按一定的比例進行分配。我們只

調節其中非常小的變量，比如說正常經典的AB測試，我只需要調整某

一個變量，某一個按鈕的大小、顏色、位置等等。當然這個變量的調

節，放在一個大型的APP里面或者是產品里面，它會對用戶的行為產

生不一樣的影響，通過用戶的行為、數據來形成對應的一些關鍵指標

的影響。比如說轉化率、日活、留存等等這些非常常見的指標。通過

對于不同組相同指標的對比，我們可以推斷出來，其中某一個方案可

能要優于另外一個方案，然后再借助灰度發布的手段逐步轉權，實現

這樣的過程。

了解完這三個概念以后，大家想象我們剛剛聽到產品線同學說的

六個問題。基本上是有這三個方法解決的，當然它是三個方法的疊加

組合成的。其實在很多領域里面，大家會反復的提數據驅動，我們簡

單介紹一下數據驅動是怎么回事。其實就是非常簡單的四步，首先你

要找到一個優化指標，我們通常在內部叫做KPL你要優化什么樣的

東西，其目的就是為了找到提升的點。你要設定一個假設，我基于提

升或者是降低某一個關鍵指標，我做某一個功能，然后這個功能在假

設成立的情況下合適是可以達到目的的。

接下來是設計實驗、開發功能，灰度發布測試，再形成這樣的行

動和過程。設定指標然后做實驗和行動這樣一個過程。我們來看一下,

在這個平臺沒有之前，大家是怎么來做的？其實通用的做法，大家想

到我要實現局部的投放或者是某一些實驗的配置，最常見的最直接的

就是使用配置文件，不同的系統，通過加載不同的配置來形成不同樣

的行為，從而達到這樣的目的。但是它也會帶來很多局限性，我們在

沒有做平臺之前，我們對應的產品線，其實大家在做實驗或者是做灰

度的時候或多或少會遇到這樣的問題。

比如說最常見的使用配置上線的問題，在于它的周期比較長，我

們的研發同學在做新的功能。產品經理說，我在這個城市的效果不錯,

我希望把它擴大到另外一個城市，這個時候我要改配置或者要重新部

署這個版本，整個過程在我們那邊快點的話需要半天時間，這樣的轉

全，大家知道隱含著很大的商業價值，即使你延后了半天上線，有可

能有對應的收入上的影響。比如說每個產品線都有一套，需要專門的

人投入，這個勢必會影響開發，這種配置有一種非常常見的問題，它

只支持非常常見的規則，按照一定的比分比匹配。但是當這個規則復

雜的時候，這種方式經常捉襟見肘。我希望要一個20到50歲區間的

男性北京的，因為這個在本地運行的系統里面，其實它是很難獲取這

樣的用戶標簽，它必須要建立服務之間的調用，來檢查某一個人在不

在系統里面。對應的系統會做的非常復雜，它要解決很多的點，比如

說調用、容錯，我們怎么樣響應這種服務。

還有最常見的是移動端的支持，大家知道作為移動互聯網產品，

特別像蘋果I0S產品，通常情況下你把包丟到Stroe里面，你需要灰

度發布的時候，這個版本其實是在蘋果手里面控制，你很難基于舊有

的方式做移動端的灰度發布，這些問題是我們在做這個系統之前所面

對的。

接下來我們該怎么做呢？首先對于研發過程，我們做一個簡單的

抽象，這個符合絕大多數研發的模型，首先你有一個想法，然后你把

它描述成一種功能或者是我們經常用的PRD形式，在由開發人員、測

試人員，把包拿到，最后由對應的0P同學部署，同時發布就做了，這

是非常常見的情況。為了應對我們剛才提到靈活的發布，我們希望用

高效短周期的方式支持灰度發布或者是AB測試。

我們首先考慮做這樣一件事情，我們把部署和發布進行分離，什

么意思呢？部署在這個時候只意味著你開發完的包被打出來，被部署

到線上去，然后完成啟停，它具備服務能力，但是它并不一定真正給

用戶提供服務或者是抵達到用戶手里，而發布真正在做這樣一個環節

的事情。基于發布的環節，我們可以非常靈活的來控制發布的行為。

舉一個例子，比如說就是有一個特別糾結的場景。首先從1%開始

測試一個模型，沒有問題，再擴大5%,再到50%,但是剛到50%覺得

數據不是特別好，怎么辦？先回到20%觀察一段時間，如果你把發布

環節單獨拿出來做，意味著在一個平臺或者是一個開放的API里面完

成，你并不需要改配置就可以完成這樣的操作。

再比如說我做實驗，我新訓練出來一個模型，以前跑兩個模型跟

控制組的對比，我先訓練出第三個模型，我切出來一些用戶跑第三個

模型。這個過程如果你把發布單獨做的話，意味著你把你的流量細分,

再打到對應的實驗組里面就可以實現，這個過程不需要做任何的發布

上線。

發布拿出來以后你可以做很多的事情，我剛才提到了我們要做數

據驅動，你圈定好的流量，你找到了非常靈活的規則。接下來你要去

找針對你的想法所確定的關鍵指標，然后進行驗證，一般情況下是基

于日志或者是基于其他的緯度，比如說用戶的反饋等等來收集驗證的

數據，如果驗證達到要求的話，它會作用在發布里面。

當然很有可能，這個驗證是沒有什么用的，你怎么挑選變量依然

沒有什么效果，這個時候它需要重新作用于想法，你要優化你的想法

或者是我們經常說的打磨你的產品，嘗試其他的變量或者是其他的解

決方案，能不能去幫助想法完善，從而達到預期的目的。

基于這個想法，有沒有這樣一種方法，它像一個開關一樣，然后

當我部署一個版本的時候，它已經具備了兩個版本的能力，只是在我

沒有打開開關的時候，所有的用戶都在這個范圍里面，當我打開開關

的時候會有符合要求的用戶看到新特性，或者是符合實驗目的的目標

人群進入到新特性里面，而我并不需要做任何版本的發布，因為這就

在一個版本里面。

這時候大家想它會怎么實現呢？其實它是比較簡單的，因為這個

東西是我們的研發人員要去使用的。我們內部叫做工程開關，可能大

家離的遠，如果我們允許用戶進來的話。通過對于這個參數，我們可

以實現對人群的篩選，它把規則進行初步的抽象，抽象成了軟件開關

就可以了。至于規則有多么復雜，這個其實是規則要考慮的問題。

用戶通過功能開關，可能會進入到實驗里面，對應的實驗代碼，

這個時候用戶進入到實驗里面，可能會在一組或者是二組或者我們經

常說，在實驗組或者是對照組，這個又用什么來區分呢？這個也是云

端返回實驗的變量所決定的。比如說我們做一個購買按鈕，一個紅色

和藍色來做實驗的時候，對于不同的用戶，它的分組進不進實驗，這

些都是服務端控制的。對于端上，對于應用實驗的具體業務方，它只

需要拿實驗。對于用戶來講它屬于紅組或者是藍組，然后再決定對應

的展現，這是我們產品的構想。

為什么這么做呢？因為我們有很多很復雜的規則場景，比如說現

在我們看到的，我們希望有一個功能或者有一個實驗，它投放在北京

市。但是它又不在國貿地區，當然原因可能有很多，蘋果手機，二十

到五十歲之間的男性，在3月1號到3月20號早晚高峰之間投放某一

個功能，這么一個非常復雜的功能。剛開始聊到了，真正基于本地配

置的方式，只能實現非常簡單的規則。基于這種復雜的規則，我們的

思路就是把它放在服務端，對于任何使用規則的來源方，它只要通過

不同語言的SDK來拿到對應的開關狀態。端上的人只需要寫對應紅的

代碼，可以讓這個用戶得到對應的功能展示。

基于這兩個在產品上的核心設計，我們把一個完整的過程進行描

述。它大概是這樣一個過程，首先是人群選擇，比如說我要做實驗，

我要做定向發布或者我要一集一集的做灰度發布，它本質上是人群的

選擇，本質上是規則的組合或者是規則的抽象。人群做完之后，如果

我要做實驗，我在第二個環節里，我設置不同的實驗分組，它的變量

是什么，當然最重要的是，我希望看到哪些指標，我希望不同的實驗

組作用在哪些指標上，從而收集不同組用戶最終的結果數據。然后把

這個配置發布到在線服務上，由在線服務提供這樣一種匹配的能力。

因為滴滴有很多的語言，在端上還有I0S、安卓和H5的頁面，不同的

業務場景使用不同語言的SDK來加載我剛才提到的直接匹配的結果，

從而形成這樣的實驗分群或者是灰度發布的方式。

接下來因為不同的用戶，在基于這種平臺設計上，不同的用戶可

能會看到不同的行為。這時候它會表現出不同的動作，比如說點擊意

愿和留存。這些東西通過一些日志收集的工具或者是手段，就可以流

轉到我們整個日志大庫里面。再基于大庫，我們啟動一些計算的方法,

然后把對應的指標跑出來，算出來之后再導入到整個實驗平臺里，從

而形成端到端的過程，確定人群，影響行為，收集指標，最終做一個

數據比對的展現。

這個過程解決了我在那張圖里面提到的發布和衡量，或者是測量

這樣一個環節。而對于產品線的同學來講或者對于研發同學來講，它

只需要把剛才提到的一個版本具備的兩種特性開發出來、測試上來部

署上去，整個后面的過程，比如說算法的同學、產品的同學或者是BI

的同學獨立完成，并不需要借助研發人員做任何的上線。

我們來看一下系統的組成，先從最上面看，最上面是我們提供的

一系列對外的服務。比如說我們有給產品人員或者是運營人員、BI人

員提供的UI,他可以在平臺上進行配置邏輯語或者是非等這些邏輯的

操作疊加的措施。有些平臺想借助規則匹配的能力來獲取這方面的能

力。我們剛才提到了，在定義灰度的時候，我們會和公司的內部系統

打交道，比如說用戶畫像的系統。它會幫助我們提供用戶的年齡分段

或者它是不是新用戶等等這些標尺，我們用戶所在的位置，西二旗地

區在不在。當然還有幫我們做用戶ID的反解，很多操作都是在這個環

節完成。

我們最核心的部分，比如說通過我們的UI或者是通過開放的API,

可以把實驗通過描述，在我們那邊可以實現描述。它主要是用來保證

文件的開發是有效的，包括我做一些容錯，如果服務器之間的配置不

一樣要定期檢查報警或者是重傳等等這些機制。它把配置分發在哪兒

呢？分發在我們提到的在線服務，主要響應的是一些APP請求。當然

還有一種場景，我們內部其實有很多的模塊，這些模塊對于響應的延

時要求非常苛刻，甚至一毫秒都不能接受，這時候我們和這臺機器同

步，而這個配置它的執行其實是由它來完成的。它用來響應不同的時

延的要求提供不同的方式，當然最極端的現在我們正在開發的使用共

享內存來達到這樣的規則解釋或者是分發這樣的方式。

服務定位以后，在左下角這個層，我們提供了各種語言的SDK,

就是我們滴滴內部比較主流的語言，這個東西的作用是什么呢？一方

面它負責拿到結果，因為這樣使用起來更容于理解。另外一點它要做

容錯，比如說A政策掛掉的時候，我們的SDK要攔著，如果它掛的話

原則上不應該影響主業務。SDK如果抓到異常，我們會做一些及時的

更正。比如說灰度發布，在這種情況下，我剛才提到的場景，它的影

響意味著灰度或者定向沒有辦法做了，實驗沒有辦法做了，但是業務

不會受到任何的影響。

在使用SDK以后，它形成了不同的用戶行為，會通過各種各樣的

直至收集工具，我們對應的計算模塊會定期的，因為它有不同的時間

策略，有一些可以容忍天或者更長級別的數據。我們的分析模塊，主

要是用來從大庫里面計算這樣的關鍵指標。再通過我們的調用，把數

據扔到這里面。包括對不同唯獨的數據進行對比，來方便不同的業務

場景，大概的過程就是這么兒個系統來組成的。

剛才我們一開始給大家賣了一個關子，就是車標的實驗。首先我

們這個實驗設計是在廣洲、深圳做的，當車的數量大于十輛的時候，

我們為用戶展現三種方式，第一種是五輛，第二種是十輛，第三種是

有多少展示多少，它運營的指標跟專車、快車比較核心的業務指標，

運行了大概兩周多的時間，最后在兒個關鍵指標上，我們發現十組的

效果要優于所有的。當然九組也可能不錯，這個需要接下來不斷的調

節參數，設定實驗找到最好的數字，現在我們用的版本是用十輛車標

做的展現。

因為有不少同學其實也做過實驗，我想說一下我們在做這個平臺

的時候所踩過的坑，需要特別注意，如果你做實驗需要特別注意幾個

技術點或者是坑，一定要避免它。

第一個是實驗碰撞，以前我們最簡單就是拿手機號的奇數和偶數,

一個實驗沒有問題，兩個實驗個實驗，更多實驗的時候，問題就會產

生了，我們內部叫做實驗碰撞。對于手機號奇數的用戶來講，如果有

三個實驗，它會匹配到Al、B1和C1,它最終的結果是A1+B1+C1,這

塊有什么問題呢？我做A實驗的PM可能他看到的Al、Bl、C1是大于

A1+B1+C1的。其實引申出來一個問題，你怎么樣來做百分比的分桶，

這其實是比較有講究的，它要保證兒個點，首先第一點是塞等，如果

這個用戶匹配到灰度的百分比里面，它每次都應該能進，只要這個配

置沒有做任何變化。第二個是均勻化，如果總是那么一波人被灰度或

者是做實驗，所有的東西都是在手機尾號第一位的1到5這兒個人來

做，這個實驗會嚴重的便宜。而另外一部分資源會被浪費，其實它壓

根兒不會被灰度，這個實驗很簡單，你拿手機號的最后兩位，比如說

0到19來圈20%,這個很容易出問題，兩個灰度兩波人會被同時圈住。

還有并行實驗，如果你在物理上希望把每個實驗進行隔離，資源的上

限是有的。比如說百分之百的用戶，能不能有一些機制呢？彼此之間

影響不大的實驗可以并行起來，這個是分組策略要考慮的問題，你怎

么實現并行的時候怎么實現隔離，這里面我們內部使用的方式，大概

是這樣一個實現，用戶有一個標尺。比如說設備號或者是用戶ID,我

們會把它和我們實驗本身的唯一標識做分析，再把它對于一千或者是

一萬個桶里面，因為我們的流量非常大。我們想做一個百分比的時候,

我就采用這種方式去取對應桶，它整套算法是穩定的，就像剛才說的

奇歐也是實現幕等的方式。用戶在這個時間里面他是1%,在另外一個

時間里面他可能是99%到100%的區間里面。

并行實驗和互斥實驗，因為它把分桶完全打散掉了，意味著A1

和A2,對于B1和B2的影響是均衡的，從而把這種方式扣掉了。怎么

實現互斥呢？其實也比較簡單，我只需要讓兩個實驗使用不同得分桶

可以實現隔離。

你怎么實現擴量，擴量是你在做AB測試的時候必須遇到的場景,

我要做這么一個實驗，A組、B組，對應的是60%,當我想把A組擴到

30%的時候就有問題了，我們拿手機號取下面的人群，大家可以看20、

20、60的比例，從B組挪兩個人過來，這就實現了30：20：50的結

果，但是這是有問題的，我們把它叫做比較糟糕的擴量，為什么呢？

是因為你在做實驗的時候，你希望看到的A和B,它們彼此和實驗主

體是雙盲的，這個時候你把B組的用戶挪到A組，這個結果作為在最

終的計算結果上就會出現結果的偏差。更好的方式是什么呢？其實比

較好理解，我對B組不做任何的變化，這個就會轉化為一個問題，對

于這種分組我要對實驗結果產生最小的影響。

對于大型系統來講，你一定要梳理好你的日志，因為試制是所有

決策的源頭，如果日志不準，打的亂七八糟會有很多的問題。所以我

們和滴滴其他部門一起合作著力推動日志統一的事情，這里面有幾個

點很關鍵。首先日志要建立規范，然后要有來源的管理，不同的服務

器，在短的本地，不同場景下的日志，你要有規范化的管理，然后要

有一些日志手機的手段，比如說你怎么樣做連接和清洗。然后你才能

基于這些數據做很多應用系統。比如說像我們這個系統屬于決策支持

的系統，還會做行為分析，監控或者是一些分析定位等等，這些東西

一定要花大力氣做。

接下來是事件池與指標池，比如說對于用戶流量的影響，對于性

能的影響，這都需要建立一些池子，進行統一的管理。然后讓一起來

看一，包括指標也是一樣的，兩個產品之間計算完全不一樣。大家在比

較轉化率的時候又有什么意義呢？這些東西都是需要統一來做的。

接下來一點就實驗要很科學，這里面有我們經常犯的問題，比如

說新鮮期，我調整了一個界面，用戶一開始覺得挺好玩的，我多點兒

次。局部優化什么意思呢？我調整了一個按鈕的顏色，看似對按鈕的

點擊產生了影響，對于總量來講可能是零和的。還有就是周期性的影

響，比如說滴滴每周六訂單量是最高的。你考慮至少一個完整的周，

當然要考慮新鮮期，你可能要放到兩周甚至更長的時間，你才能達到

對你來說相對有意義的值，還有就是指標選擇，什么意思呢？你做一

個變量的調節，你要找跟變量直接相關的指標，直接證明這個變量調

節的作用。因為中間我們有太多的變化產生，由于時間關系不再展開

講了。

實驗的統計意義，這個非常重要，因為實驗往往是基于局部猜測

全局，在這個地方如果樣本小，執行時間少，這種時候很容易讓你拿

到看似比較好的數據或者跟你的假定的數據，你可能會下一個錯誤的

結論。在這時候你一定要考慮在統計學上的意義，這個地方也跟大家

稍微簡單說一下，我們內部叫做假設檢驗的方法，其實就是概率論里

面的東西，你要考慮犯一型錯誤和二型錯誤，讓他支持A組和B組的

結果。

最后一個是其他應用的場景，比如說主干開發，所有的人大家基

于主觀做開發的時候，我要上線，有些功能沒有完成，我把功能進行

隱藏就可以了，不讓用戶看到，這些功能其實是可以上線的，它不會

影響你的版本。比如說定向人群分析，我把它投放到西二旗，以及跟

其他的用戶進行對比，我來看這個地區的人的一些特點和敏感度，這

里面說一個點。其實我們的乘客赫斯基，我們經常做司機會面對這樣

一個問題，就是資源共享的問題。比如說我對北京的百分之五十的司

機做實驗的時候，有可能它的傾斜會導致這50%的用戶吃掉另外50%

的訂單，但是在AB測試里面，假設它們兩個彼此不受影響，做類似這

樣的實驗我們是要特別的謹慎。

還有模型訓練對比，我們可以實現新跑出來的模型能夠第一時間

建立實驗分組，跑出數據，這個過程我也給大家介紹了。其實應用場

景是比較多的，謝謝大家。

主持人：

再次感謝齊賀老師，由于時間關系，現在我們只問一個問題。

提問：

我想問一下，剛剛我們看到功能開關通過SDK的狀態位來判斷開

關是關和開，在不同的代碼里面實現不同的功能。我們平時做新功能

開發的時候這個可能沒有問題，但是有些功能升級，它并不是很明顯

的兩段代碼做對比，而是我把代碼A改成了A+,這種代碼修改的增量

有沒有相對應的方案做灰度發布。

齊賀：

其實原理本身很簡單，因為它侵入了代碼，有可能它不太適用于

場景，我們內部還在使用在路由那個層面進行兩個系統的分配。當然

如果還是小的功能，其實這個通過一些架構的設計，可以把它剝離出

來。因為我說一個前提，我們一定要具備兩種形態，就是A或者是B,

這個其實對于設計有一定的要求。

提問：

這個對于我們的開發者提出了開發模式的要求。

齊賀:

現在新舊都要測。

提問：

我們看到的都是代碼級的AB測試或者是代碼級的灰度發布，我們

剛才說的阿波羅平臺有沒有做到支持零開發資源介入純業務方的調

整。比如說我就拿一張頁面來講，我在這里面并沒有預埋代碼，有沒

有可能用阿波羅平臺在運行時動態調整UI上面的東西呢？

齊賀：

這個我們是跟公司其他的部門一起合作，我們很多實驗產品在端

上，這部分依賴于上線才能完成。但是結合一些動態化的技術其實可

以下發一些東西，這樣可以實現動態的加載來完成。

提問：

也就是說下發的邏輯還需要開發的介入。你剛才講到UI系統，這

個UI系統是指功能調整的UL還是說條件創建和調整的UIo

齊賀：

主要是規則，比如說我要擴量，我從50%到100%,在我們系統里

面要加對應的實驗分組，只要它的代碼能解釋實驗分組的變量，它就

可以動態的實現。比如說我再加一個綠組，你想改字，這個代碼本身

是不支持字的變化，對應就得改代碼了。

提問：

后面數據統計那里，因為我們每一個實驗，剛才提到我們要針對

性的看一些指標。當我想做一個實驗的時候，我出一張新的報表，這

個報表是需要我們的BI部門支持,還是在這套系統里面業務方可以直

接定制一張報表出來。

齊賀：

如果是端上的事件類指標，我們是支持自動訂閱和自動計算，當

然它還可以復合，頁面按鈕的點擊轉化，這些東西其實都可以訂閱。

但是有一種指標需要在事后算，比如說追訂單標，這些東西要BI一個

一個接，接完之后其他人可以實現訂閱了，這是一次性的成本。

提問：

我們剛才說的是常規的數據統計，我們做AB測試的時候，你們所

有的統計是天生支持對比的嗎？

齊賀：

那當然了，其實剛才有一個細節沒有講，SDK本身在實現分組的

時候還會做一個染色，染色信息也會流轉到大庫，默認有了灰度組、A

組或者是B組，在計算的時候只要兩組信息進行

照應就可以了。

提問:

整個滴滴上線第一天就支持這種對比還是說后面改造的。

齊賀：

去年十月份改的。

提問：

整個一套都改掉，是天生支持對比，還是一塊一塊的。

齊賀：

肯定是一塊一塊的，因為這個畢竟是輔助的工具，公司還有更重

要的事情來做。

主持人：

謝謝齊老師耐心的解答，下面我們休息十分鐘。

下面我們開始第三場的分享，她是騰訊高級工程師田蘭老師，大

家都知道騰訊最賺錢的部門是什么？就是游戲部門，游戲部門如何通

過數據來進行精細化的游戲策劃和運營，今天讓田蘭老師給大家解答

一下，下面請大家用熱烈的掌聲歡迎田蘭老師。

田蘭:

大家好！

我是來自騰訊游戲的田蘭，今天我給大家分享的是在關于新技術

浪潮下，我們數據團隊的二次創業。其實這個名字聽起來有點嚴肅，

我們用一句俗語來講，就是在游戲行業第一的騰訊，我們怎么為游戲

做數據服務，今天講三個部分。

第一，數據之困。

第二，數據服務產品化探索。

第三，iData數據服務團隊的介紹。

我們團隊一直專注于游戲數據的服務，現在它屬于我們騰訊運營

部的中心，主要負責游戲數據的采集、傳輸、統計分析和運營支持。

在騰訊游戲十年道路當中，數據曾經遇到過很多的困難和挑戰，當然

這對我們來說也是一個機遇。在這期間其實有兩次重大的事件，對我

們數據服務產生重大的影響，就是頁游和手游的爆發。

這是我們騰訊數據團隊在新業務接入時候規模的數據圖，第一點

發生在2010年，這一年有什么重大事件，就是我們的頁游爆發，這里

面我們可以看到整個新游接入量是此前N年的綜合。我們頁游保持高

速增長的趨勢下，2014年整個新業務接入兒乎在2013年的基礎上再

翻一倍，在這么大的服務量級下，我們原來是統計事務型團隊，我們

服務的業務量級也出現了很大的增長，所以整個團隊轉成了平臺型的

團隊，它主要解決在數據需求上的效率問題。

這個標準化平臺，我們也取得了一些成績，可以很好的為游戲進

行數據的服務。但是到了2014年手游爆發的時候，我們發現僅僅效率

的提升并不能滿足游戲的需要，游戲需要我們數據團隊能夠提供更多

的能力。我們可以這么來說，手游的爆發加速了整個游戲數據服務的

產品化的進程，在2014年我們整個團隊從平臺型的團隊，轉向了產品

型的團隊。

為什么說手游爆發加速了？因為那個時候看到了游戲數量的井

噴，在這期間，更好我們大數據技術的發展是蓬勃發展的，在精細化

運營方面有更多的需求。由于游戲數量的大增，我們整個游戲運營的

從業人員也增加了，這對我們的運營平臺提出了更多的要求。比如說

運營效果、效率，以及體驗上都有很多不同的要求點。

在2014年整個騰訊游戲服務數據團隊，也對我們數據服務的產品

化做了探索，我們怎樣進行團隊的轉型。首先我們來看一個問題，數

據為誰而生，這似乎是一個很簡單的問題。數據當然是為我們的研發

和運營來提供游戲的質量分析。對于我們的團隊來講，騰訊游戲就是

我們服務的目標，但是要影響游戲，其實作為一個數據團隊來講，它

并不是直接來影響的。我們要讓一個游戲的運營能夠運營的更好，能

夠達成它運營的目標。我們作為數據產品，其實是在影響運營游戲的

人，我們來看一下在騰訊使用游戲數據服務的用戶，它的職能服務大

概是什么樣的呢？我們可以把它大致分為兩個方向。

它是關注我們運營結果這一部分的用戶，它可能更多的是看數據

內容，以及可視化的結果，它通常是什么人呢？我們的老板、研發、

策劃運營，這一部分在平臺時期滿足的比較好，從需求的效率到結果

的呈現都能夠滿足我們游戲運營的需要。但是在2014年之后有很多用

戶轉向了另一個方向，就是關注我們運營的決策。他們希望通過數據

洞察問題，幫助他們決策解決，這部分人是數據分析、市場、策劃運

營，數據幫助他們解決什么問題呢？

這里有一個比較通用的說法，當初游戲進行運營分析推廣，改善

游戲品質，提升游戲的收益，這是跟籠統的。我們作為數據產品要解

決的時候，我們可能要從更細的階段來看，一個游戲的運營，它大致

分為六個階段，策劃、研發期、成長期、成熟期、篩推期，以及退市。

中間的四個階段都是數據所參與的階段，我們又把這個階段大致分為

兩類。第一類就是研發期和成長期，游戲的研發和成長期數據通常承

擔的職能是進行數據的采集、抽取和計算，幫助游戲改善游戲的品質,

這是我們在這個階段做的事情，也是我們前面在平臺型團隊主要做的

事情。

當游戲進行全量運營之后，我們的運營人員更多關注到精細化運

營。比如說用戶的新進、留存、收入各個方面。精細化運營在傳統的

數據服務當中比較少涉及，這是在數據產品轉型期間對我們提出更高

的挑戰。我們的數據是怎么切入的呢？游戲的精細化運營，它通常是

圍繞我們用戶的生命周期來進行的，用戶的生命周期就是從注冊到留

存。我們大致可以劃分為五個運營場景，比如說玩家注冊之前我們有

拉新的環境，在玩家成長期有保留存，然后有拉收、促活躍，如果玩

家出現了活躍下降的狀態，我們會觸發流失挽留的場景，我們不斷找

到需要干預的用戶，并且為它做出一些運營的決策，幫助我們達到運

營的目標。

拉新跟拉回流投入的成本相對比較高，所以在這個過程中，我們

又會引入用戶生命周期總價值，來衡量整個拉新、拉回流的投入產出

比。我們通過從各個渠道來的用戶考量它的生命價值，來考察我們拉

新渠道的質量，這個也是重要的指標。比如說在拉回流的時候，我們

怎么去圈定高價值用戶投入更高的成本拉回流，這都是我們精細化運

營的過程。針對一個游戲來講，我們的數據服務團隊可以做深、做細,

不斷的調整我們整個運營的策略。如果作為一個數據產品、數據服務,

我們可能需要考慮更多的問題，在這些我們希望把更多有效果的運營

方案沉淀下來，并且能夠給用戶更高效的方式進行運營的過程，這個

就形成了數據服務產品需求的雛形。

數據怎么從事務變成服務，也是我們產品化探索過程當中非常重

要的問題。我們來看一下數據分析和運營的流程，它通常是什么過程

呢？我們需要明確我們的目標，目標要細分，要做數據的規劃，然后

做數據的準備，設定我們分析的方法，以及分析執行、結論輸出，最

后做運營決策，然后評估效果，這是我們日常運營的流程，它可能是

相對較長的過程。在這個過程中，我們怎么通過數據服務產品，幫助

他們。我們把這個過程抽象為三個階段，我們的目標、過程和結果，

在數據分析過程當中，到底要做什么，是需要發現問題，還是需要評

價我們版本的效果或者是活動效果呢？還是需要預測趨勢或者是挖掘

新的機會。我們明確我們的目標之后，需要通過數據準備、數據統計

分析、報表瀏覽，在線的數據詳細的分析，再到用戶觸達干預過程，

又回到數據采集，在這么一個循環的過程當中，不斷的調整我們整個

運營的策略。最終能夠達到我們設定的目標，是否達到這個結果的考

量。

在整個過程中，我們發現這個過程是最消耗人力和時間的流程。

所以在數據服務產品當中，我們也重點將我們的服務集中在這一部分。

希望我們直接來看一下在騰訊，游戲數據服務有一個名字是怎么來做

的，這是我們以內容產品驅動的數據閉環的服務產品。現在主要是為

騰訊內部的游戲服務，目前應該有兩百多個大中型游戲。iData數據

服務正泰分為兩部分，一個是主線，一個是閉環，主線就是我們的數

據分析，數據分析作為內容驅動。剛才我們提到用戶生命周期，我們

把它分為五個階段，新進、留存、活躍、付費、流失。然后我們通過

提供的工具平臺，將剛剛所提到的過程形成一個服務的閉環。比如說

我們通過數據上報與指標設計，來完成采集和存儲，數據管理、抽取

和可視化的呈現。再通過數據分析服務支撐的多維分析平臺來完成我

們的多維分析的計算和多維的可視化。

最后我們再通過運營知識服務來支撐數據營銷平臺進行渠道投放

的管理，以及營銷數據的應用。大家看到這三個平臺對應到我們看的

過程，我們中間提供這樣的工具，幫助我們進行精細化的運營，在這

個服務生態下，我們需要有一個后臺系統來支撐。iData有這么一套

數據服務的架構來支撐我們服務生態，它主要分為四個部分，采集傳

輸、存儲計算、分析服務和數據應用。在存儲計算部分使用到騰訊的

分布式數據倉庫，以及我們自研的不是計算平臺，以及我們的計量實

施分布平臺，共同支撐我們整個分析服務的存儲計算。

在分析服務層，通過剛剛的存儲計算服務來支撐什么樣的服務

呢？就是報表服務，這是最常見的，還有我們的用戶提取，這是我們

的精準用戶的獲取過程，以及用戶的跟蹤分析，我們可以關注一群用

戶，他們在某一個時間段內，在游戲類各個方面的表現，以及多維分

析，從多個角度呈現用戶的屬性特征，以及多類提取，這是為游戲內

用戶的詳細信息提供了一項數據服務，由我們的存儲計算和分析服務,

共同支撐數據應用，這里面有兒項。

因為我們原來數據集中在數據分析，從數據應用領域設置的比較

少。因為我們分析的話，到分析服務這里就截至了，我們希望分析服

務延伸到應用，我們可以精準獲取用戶群體，以及我們的用戶規則引

擎。還有用戶的線下服務，這后面會有較為詳細的介紹，下面我們來

介紹一下三個核心平臺，數據管理平臺，多維分析平臺和數據營銷平

臺。

數據管理平臺，如果我們從流程來看，采集、存儲、抽取計算、

寬表，這跟我們傳統的數據管理平臺沒有大的差別。我們每天需要處

理超過200大眾型游戲的數據，每天新增30T的數據量，通過我們采

集傳輸平臺來處理。然后我們需要做一層中間表的計算，因為游戲數

據通常以天來進行分析和應用。所以我們會有一層抽取計算的工作，

我們通常會把用戶和每天的數據匯集到一起，以充值為例，我們可以

進行計算。

剛才提到閉環服務，除了我們提取存儲以外，我們還會做度量指

標的邏輯存儲。比如說充值用戶數，總充值金額，這些度量指標，它

的算法，我們會將它進行邏輯存儲，這是為了后面我們在多維分析的

時候使用到，后面再詳細介紹。

這樣的方法與傳統的統計平臺有什么不同呢？數據分析是最老的

方式，我們從一個數據源、數據表進行統計，輸出一份報表，這件事