人工智慧需要學習海量數據，數據的準確性如何來保證呢？

01-14

謝邀，我認為AlphaGo的勝利，是人工智慧與大數據真正走上國際舞台中央的一刻，象徵意義大於實際意義，但不得不說，大數據+機器學習演算法的組合，已經在很多方面超越了人類極限，人類創造智能，智能通過對海量數據的學習，間接在特定方向超越人類。

擁有海量優質數據的重要性不必多說。

其實所有與數據有關的應用，不論是基礎的數據統計，複雜的數據多維分析，還是我們提到的個性化推薦、用戶畫像等人工智慧的應用，對於數據準確性都是有較高的訴求的。數據的準確性，直接影響數據應用最終的呈現效果，也從而影響基於數據的商業決策和產品智能效果。

我們服務過的很多公司，使用我們來替代上一代的流量統計產品，或作為自有數據系統的補充和延伸。在這種情況下，客戶會對不同系統之間進行對比，例如，對比神策分析與上一代流量統計產品在關鍵指標上的差異，對比神策分析與自有數據系統的數據細節差異等，由此衍生出了數據準確性的話題，這也是我們為什麼有很多關於數據準確性的經驗可以談。

在協助客戶進行這些數據對比的時候，我們也對數據處理過程中的準確性問題有了更加系統的認識，並且在整體的產品和系統設計上也做了很多相應的處理，在這裡一併分享。

數據處理五個步驟

對於大部分數據應用來說，數據處理都可以劃分為如下五個步驟：

在這五個步驟中的每一步，都會面臨數據準確性的問題，並且神策分析也相應地進行了針對性的處理和應對，下面結合我們之前的一些實際的應對案例，進行詳細介紹。

1.採集環節的準確性問題與應對

數據採集這個環節，一般而言，會是準確性最常出問題的環節之一。我們在實際服務客戶，進行數據校驗和對比的過程中，也積累了相當多的經驗，在這裡共享給大家。

在這個環節，準確性問題會有兩大類：

一類是與人有關的因素。例如，由於粗心或某種原因，在部分頁面沒有嵌入 SDK，遺漏了對某個關鍵操作的採集，或者在某個關鍵的代碼埋點處採集錯了某個重要的屬性。整體上，一般軟體開發過程中可能有的人為錯誤，在這裡都有可能出現。
另一類則是與人無關的，純粹技術性的因素，下面是一些非常典型的問題，與大家分享：

在 iOS、安卓 App 上進行客戶端數據採集時，為了不影響用戶體驗，通常都是在客戶端本地做好緩存、壓縮、加密等，然後在網路良好的時候會嘗試非同步發送數據，這也決定了這些數據的時間只能以客戶端時間為準，並且有可能事件發送時間與事件發生時間有較大間隔。除此之外，少部分用戶的手機有可能連時間都不準確，這些都會造成最後採集的數據不準確。
在 iOS 和安卓 App 上進行新用戶激活的判斷時，常見的方案是在本地 ROM 上存儲一個標記文件或者類似的方案，用於標記這個設備上是否是首次激活本 App。但是，一旦用戶卸載然後重裝這個 App，這個標記也會隨之失效，從而導致首次激活判斷錯誤。
在 H5/Web 界面上進行客戶端採集數據時，都是以 JS SDK 的方式進行的，如果碰到部分異常流量無法觸發 JS，則 JS SDK 是採集不到這些用戶行為的，在這種情況下，如果和 Nginx 日誌等進行對比，則數據也無法一致。
部分第三方統計分析工具由於技術限制，對於除預置屬性以外的其餘自定義屬性有較多限制，例如自定義屬性只能有有限個，自定義屬性的取值也只能是有限個等，這樣其實客觀上導致了數據採集能力有限，沒有辦法採集到所需要的數據，從而影響數據的準確性。例如，某個漫畫類的 App 想採集每一個漫畫頁面的閱讀量，把漫畫名稱作為一個自定義屬性，但是，在實際使用某免費的第三方流量統計工具時，卻發現這個自定義屬性最多只能有 10 萬個取值，而漫畫名稱又遠遠不止 10 萬個，從而導致採集的數據並不準確。

對於採集環節這些人為的或者非人為的數據異常的因素，基於我們以往處理這方面問題的經驗，我們在產品和服務層面，提供了以下方案進行處理：

產品實現了多項目機制，專門為客戶提供用於測試與沙盒的「測試項目」，來完成數據採集的開發和調試，並且在上線之後，可以將測試項目的元數據同步到正式項目。
為每一個數據採集 SDK 與數據採集工具，都提供了專門的 Debug 模式，與「測試項目」和「導入數據實施查看」功能相配合，在開發過程中，就可以直觀地看到採集的數據，從而很方便地對數據採集的結果進行調試。
產品提供了獨特的「埋點管理」功能，對於各種不同端的 SDK、採集工具部署的埋點，都進行實時的監控與管理，直觀地看到數據採集的進度和數據異常。
對於客戶端 SDK 採集的數據，在架構上做了最大的努力進行優化，保證對於之前就發生並且被採集到卻由於網路原因最近才接收到的數據，也能夠準確地按照行為發生的時間進行回溯，從而準確地接收數據，並最終準確地還原用戶行為。而對於上一代的統計分析產品而言，由於它們本身的架構設計與統計口徑，導致它們無法很好地回溯這些之前採集的數據，所以在進行對比時，會有數據差異。
對於客戶端本身時間錯誤的問題，我們也一直在嘗試在 SDK 中增加對採集的事件時間進行對時的功能。目前初步的思路是在每次成功的數據發送請求後，都根據服務端返回的準確時間，對採集的數據中的事件發生時間進行相應得修正。
對於卸載重裝 App 導致首次激活判斷錯誤的問題，我們建議客戶採用不會隨著卸載重裝改變的設備 ID 或者用戶註冊 ID 作為用戶標識，並且將這個判斷邏輯移到服務端，從而解決了這個問題。
對於異常流量不會觸發 JS 導致 JS SDK 無法抓取到數據的問題，我們應該意識到，這些連 JS 都不會觸發的流量不會是正常用戶的訪問，對於這些數據，在絕大部分情況下，不採集反而是更好的一種方案。除此之外，對於部分反而會觸發 JS 從而被採集到的 spider 等類型的機器流量，我們也根據 UserAgent 等特徵做了相應的標識。
神策分析在數據採集能力上，支持最多上萬個的自定義屬性，每一個自定義屬性都支持六種類型，並且在取值上沒有任何限制，從而讓使用者能夠採集。

2. 傳輸環節的準確性問題與應對

傳輸環節，一般主要是指通過客戶端 SDK 等採集到數據，然後通過網路發送給數據平台。由於一般是走 HTTP 協議通過公網進行傳輸，所以肯定會面臨網路異常等錯誤。

對於 JS SDK 而言，由於語言特性與網頁本身的處理機制，目前並沒有太好的方案來解決網路異常等。根據我們這麼多年的處理經驗，JS SDK 一般會由於網路原因帶來 3% 到 5% 左右的數據丟失。

對於 iOS 和安卓 SDK，相比較 JS SDK，在網路異常時可以有更好的處理方案，例如，當由於某些數據沒有成功時，依然緩存在本地，直至發送成功時才從本地把這些數據去掉。所以，一般而言，iOS 和安卓 SDK 的數據發送會有 99% 以上的完整性。但是，在某些惡劣的網路條件下，有時候依然會出現，數據已經成功發送了，但是本地得到的介面返回依然是錯誤，從而下次會重複發送這些數據，導致接收到的數據會重複。神策分析在接收端有相應的去重邏輯，解決由這種原因帶來的數據重複問題。

當然，在神策分析產品發布之初，我們就提供了服務端數據採集的解決方案，讓客戶可以通過內網來傳輸數據。所以，我們一向推崇，如果同一個行為在客戶端和後端都能夠採集到，那麼優先推薦在服務端採集，通過內網而不是公網傳輸，能夠有效地規避傳輸中的網路異常問題，保證數據的準確性。當然，附帶地，也一併解決了傳輸過程中的安全與隱私問題。

3. 建模與存儲環節的準確性問題與應對

建模與存儲環節，主要碰到的問題大概有：

由於硬體或者軟體問題，導致存儲的數據丟失或者損壞，從而影響數據的準確性。
由於數據模型的限制，導致歷史數據無法回溯，從而影響數據的準確性，這一點在大部分上一代流量統計工具中存在。
由於存儲方案的限制，導致已經導入的數據無法修改或者刪除，從而在數據有錯誤的時候也無法修正。

針對這些問題，神策分析採取了如下一些方案進行應對：

基於 HDFS 的分散式存儲，每一份數據都會存儲多份，因此，當硬碟損壞，機器故障時，依然會有完整的可訪問的數據。
採用了更加靈活高效的數據模型，可以回溯過往的歷史數據，保證數據的完整性。
提供了分事件、日期的數據刪除和重導機制，用於修複數據，最大限度保證數據的準確性。

4. 統計分析環節的準確性問題與應對

我們在協助客戶進行數據對比時，經常也會在這個環節碰到一些準確性方面的問題，最常見的有：

查詢或者計算過程的 bug，導致最終的統計和計算結果不準確。
不同的系統、工具，對於同一個指標，有不同的統計口徑，即使採集的數據完全一致，最終的計算結果也可能有較大差異。

對於這些問題，我們是採用了如下一些方案：

神策分析對於任何一個分析模型，都積累了非常豐富的測試用例以及完全自動化的測試系統，儘可能保證神策系統本身的計算正確性。
對於自身的每一個指標的計算口徑，我們都提供最為完善的說明與樣例，同時，我們也會盡量弄清楚其它第三方統計系統的各個指標的計算口徑，以便在協助客戶進行數據對比時，能夠準確地說明問題。
神策分析本身具有任意指標上的任意維度的下鑽和篩選的分析能力，部分其它第三方分析工具在一些固定維度上也可以進行下鑽，這也便於進一步找到數據差異的關鍵點。
與部分第三方統計系統不同，神策分析可以提供最細粒度的用戶行為數據，從而可以從最原始的數據層面對數據進行核對和分析。

下面是幾個我們協助客戶進行數據對比時的真實案例：

某客戶需要對比神策分析與某免費流量統計工具 U 的活躍用戶數，由於神策分析在該客戶的 X 版本才集成，所以就選擇對比 X 版本上的活躍用戶數，然而，在一開始，數據始終存在較大偏差。在經過仔細閱讀工具 U 的文檔後，我們發現，如果一個用戶在今天從 App 版本 X-1 升級到版本 X，則他會算作版本 X-1 的活躍用戶，而不算作版本 X 的觸發用戶，這主要是由於工具 U 的計算方案上的限制。而對於神策分析而言，如果一個用戶在今天從 App 版本 X-1 升級到版本 X，則他會算作版本 X-1 的活躍用戶，也會算作版本 X 的觸發用戶，並且在計算今天不分版本的整體的觸發用戶數時，也會對之進行去重。在與客戶說明清除這些計算差異之後，很快得到了客戶的認可。並且，隨之客戶 App 新版本升級完成之後，整體的數據差異也很快減少到了可以接受的程度。
某零售客戶需要對比神策分析中的購買事件的總金額與他們自有資料庫中訂單表的總金額，選擇了具體的某一天進行對比，發現總有極少的差異。在仔細核對了原始數據後，發現神策分析的購買事件的時間，是用戶在 App 與網頁上提交訂單的時間，而客戶自己的資料庫中，則是以訂單的最終更新時間為基準。因此，在計算某一天的購買總金額時，會出現微小的差異。

5. 可視化與反饋環節的準確性問題與應對

在這個環節，一些常見的準確性問題包括：

可視化界面本身的 bug 導致的數據不準確。
可視化界面本身的展示限制，所導致的數據理解上的偏差。例如，在網頁上展示分析結果時，如果展示的行數過多，可能直接導致瀏覽器崩潰等，為了避免這些問題，通常只能對數據做一些截斷處理，這也會導致沒有辦法準確地看到數據的全貌。

針對這些問題，神策分析採取了如下一些應對方案：

實現了前端的自動化測試框架，自動完成前端的正確性測試，以避免由於程序 bug 導致的問題。
針對瀏覽器顯示階段的問題，提供了下載 CSV 文件和 API 獲取全量分析結果等方案，使得使用者可以獲取全量完整的數據。

簡而言之，數據準確性是一切數據應用的前提，我們神策數據為數百家客戶服務，其中不乏人工智慧客戶，如智齒科技、百度視頻等等，都將人工智慧應用在日常工作與生活中。整個團隊從前在百度從事大數據相關工作，踩過很多的坑，才積累了豐富的經驗。一方面，我們會根據這些經驗進一步優化和改進我們的產品，另一方面，我們也會將這些經驗遷移到我們客戶的實際使用場景，為客戶的數據校對工作提供更優質的服務。

謝邀。

AlphaZero除了規則外，沒有對局數據輸入。

如果是需要針對外界數據進行處理的AI，你除了處理過程的AI外，甚至也可以弄個專門研究數據置信度的AI。

首先，數據並不是模擬的假數據。

其次，假數據的定義是啥？比如圖像識別，就是要千萬張圖片，語音識別就是要很多聲音的語料，AlphaGo就要很多棋局數據。怎麼才算假圖片，假聲音，假的對局？

另外，數據的獲取途徑就可以保證真實，例如無人駕駛的駕駛數據，就是汽車行駛時的數據。

所以總結下來，

1，數據的來源就可以保證真實。

2，人工打標籤保證真實。

靠人的方法篩選和標註數據，可以允許一定量的雜訊存在，以此訓練出接近或超過人類準確性的人工智慧，這是目前流行的監督學習的路子。

數據的準確性上，之前的數據集並沒有很好的保證，例如Imagenet的一些數據，以及最近Andrew N.G做的醫學數據集，標籤的準確性都存在問題等等。

如何來保證準確性，我想演算法標註+手工標註的方式可以確保比較高的準確性吧…對於一些比較難以處理的問題標註，這個還是專家來標註更能保證準確性如果專家願意的話…

可以參考卡爾曼濾波過程設置置信度參數