【2018.Q1】（1）O2O中技術的核心價值（的一部分）

05-17

來自專欄互聯網在孫嘉龍低維認知中的投影

TL;DR

O2O充分競爭之後，拼的（一方面）是各自建立的協作關係鏈的效率，而高效率需要：（1）充分的線下基礎信息/數據向線上平台的傳遞，（2）線上系統對於線下環境變化高效的反應能力，（3）實時展示給各端用戶的應該是由當下最新信息產生的服務/結果。
如果你相信上面一條，而且相信自己領域的信息是會變化的，那麼一個純端到端的監督學習方案就是不夠的。

題外話

這個專欄開了1個月，終於開始做本來計劃的事了——系統介紹自己在互聯網方面的階段性思考。精力有限，估計也就最多每周一篇吧。

2018.Q1更新了自己對整個互聯網的認知，這個認知下有些推論，會拆成多篇文章進行闡述，本文只是該系列第一篇，敬請期待。

由於個人認知範圍有限，本文主要討論到家類的O2O服務的C端側，主要包括快遞、外賣、打車。其他場景我熟悉的不多，但我相信這其中問題是有共性的。

在發展上，本文主要討論現階段的狀態，即各領域都只有少數競爭者，跑馬圈地時期已過，效率的競爭成為主要因素之一。

本文只是本系列的一個鋪墊，拿大家熟悉的例子進行舉例，但終歸不是要討論O2O本身。

本文的觀點源自於對以下問題的思考和融合：

讓我們看下面三個問題：

快遞配送上門發現家裡沒人時，快件應該放在哪裡？
配送外賣時，小區是否可以進電瓶車，配送時間有多長？（是否應該把多個該小區的配送單盡量集中在少數幾個配送員那，以減少綜合配送成本？）小區配送員的車、電池、車上的其他商品是否容易被盜？
打車時，如何給出乘客上車點附近一個司機和乘客都方便到達和尋找的位置？

這個幾個問題都制約著整體服務的效率，並且都是線下的本地化的信息。

這些信息在平台信息搜集方案完善時候，可以通過大數據挖掘來自動生成，並提供給後面的訂單。
這其中的某些信息系統無法低成本獲得，妨礙了向新用戶進行推薦。例如新用戶如何知道那個隱秘的快遞櫃在哪裡？平台如何知道春節期間該小區某個門已經禁止外賣出入，但另一個門可以？新乘客如何找到小區門東側100米那個可以停車但系統又不知道怎麼描述的上車點的位置？像各種地圖App上的交通事件上報大家已經很熟悉了。
當這些信息變化時候，如果系統不能及時響應變化，則這期間受影響的訂單體驗下降會非常嚴重。
光靠平台進行歷史數據挖掘，更新信息需要的時間較長，往往需要一定的時間或者一定的訂單量。
這些信息雖然數量龐大，但仍屬於眾包可標註的範圍。（有眾包也無法標註的場景，本系列後面文章會提到）

相信各種場景下優化策略至少1年的同學會深有體會。

在我看來，這類問題的下一階段的解決手段只有一個，那就是靠各種意義上的眾包，人員可能是公司地推人員、當地誌願用戶、當地經過認證的用戶有償上報、所有用戶。

一個（部分的）本地人為平台和本地人（可匿名地）提供數據/信息，改善本地人服務體驗的協作鏈條。而平台可以依靠此數據做更上一層的其他服務。

如何組織相應的人來上報是一個產品形態/運營方式的問題，本文不討論。

在這個場景下，數據天然就是變化的，一旦有新數據上報進來，如何自動化、半自動化的進行審核？如何做到10min級線上數據更新？如何對潛在的數據變更做識別和預警？數據的快速干預方案？

未來平台考慮的因素會越來越多，對於各端的用戶來說會越來越傻瓜，只要提供信息就好，系統會來做綜合決策，推薦一個最優方案。

隨著對低badcase率的要求越來越高，那種能隨意丟棄一點請求的線上變更方案越來越不可接受了，所有的業務邏輯越來越事務化，越來越要求可追蹤可干預可解釋。

這對「傳統」系統衝擊是巨大的：

大幅提升挖掘pipeline的效率，並且要做線上化。
線下離線算好線上用的空間換時間的策略不再那麼有效，需要越來越複雜的線上緩存方案和線上計算。
純ML模型很難快速更新和快速干預特定case。這個問題後面系列文章會談，我認為解決手段不是online learning
新的需求：自動審核、自動預警、數據快速干預平台，所有更新版本的可回溯可分析。
隨著數據更新頻率的加快和數據版本的連續化，對於某些挖掘/學習方案的數據表示方式也提出了新的要求，這方面以ID one-hot+embedding為基礎的ML方案會有些力不從心。而且我覺得這不是模型（能解決）的問題，而是特徵工程的問題。

最後我也沒有談核心價值是什麼，但我想大家讀到這裡應該有自己的判斷了。

下面的問題會在後續文章進行展開：

下面的問題並不在本文框架內，目前尚在思考：