【ML專欄】如果ML是一個多功能螺絲刀，那麼它的刀頭是什麼——談如何定義演算法工程師的領域經驗（的一部分）

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

TL;DR

• Conv和CTC都是一種領域相關的DL組件，而非通用組件。
• 領域DL組件還很少，是需要各領域的演算法工程師來認真思考和解決的，其他領域的人很少能幫上忙。
• 特定領域內演算法工程師的（部分）本質工作可以概括為：把原來一個非常高維、極度稀疏的問題近似為了一個較低維空間中的、在現有數據下不那麼稀疏的一個問題來學習/建模，在降低學習需要的樣本數量和訓練時間、提高模型精度的情況下，也提升了模型對於badcase的【可人工快速維護性】（這個概念見 【ML專欄】可解釋性與修badcase ）。

前言

這篇文章並沒有一個【2018Q2】的Tag，看過 【2018.5】本專欄定位 V2 的同學會知道這是什麼意思。

思考的起點

回想了一下，發現我早在一年前就已經認識到Conv和CTC在DL中的與眾不同，只不過當時還沒有將其納入到自己的認知框架中而已。

除了對於Conv和CTC的認知外，另一部分基礎是對於【高維稀疏場景】的認知，這部分來源於我過去幾年導航路徑規劃問題的思考，其理論化是在今年完成的：

• 【ML專欄】談One-hot的本質功能
• 【ML專欄】【2018Q1】（4）眾包vs有監督學習
• 【ML專欄】可解釋性與修badcase
• 【2018.5】也許你的用戶並不想要千人千面，或是那大數據上帝視角模型的結果

還一部分是來源於我過去1年來對【連續狀態轉移序列】建模的思考，這方面內容會在後面單開文章介紹。

DL的通用性

本文的目的之一也是希望討論下大家都認為的DL的通用性的邊界是哪裡，哪些通用DL研究可以解決，哪些需要領域專家來思考。

如何定義領域專家的能力

有不少人能夠意識到領域知識對個人職業生涯的重要意義。但這個領域知識是什麼，什麼是什麼不是則一直很模糊。本文也是希望向大家分享一下自己目前的思考結果，拋磚引玉。

作為預備，我們先回顧一下圖像和語音識別領域中DL的一些略微不同的東西。

圖像、Conv層以及CNN

這方面內容可以參考《Deep Learning》：

• 英文版 http://www.deeplearningbook.org/
• 中文版 https://github.com/exacity/deeplearningbook-chinese

雖然目前Conv已經被嘗試在各個領域中應用，不過其最早是被設計用來解決圖像類的問題的。

不知道大家最初看到Conv的結構時候能聯想到什麼，對我來說這就是一組可學習的【濾鏡】，有過簡單圖像處理經驗的同學都會對這個概念非常熟悉。而無論是Conv和濾鏡都可以追溯到生物眼鏡對圖像的處理方式上。

毫無疑問，從表達能力上來講Conv層相對於全聯接層表達能力更差了，它是一種對於圖像的【先驗】知識。先驗的加入可能會導致欠擬合，但大量的成功應用證明了它很不錯。

上面我其實是在說，Conv與DL的其他部分相對來說，其實沒有什麼太大的關係。它的構造主要來源於大自然和我們對於圖像的處理方式/先驗，只不過可以被用在DL當中，而且在圖像上有其強大的優勢。

CNN中還有另外兩個東西，一個是Pooling，一個是多層網路結構。後者在我看來屬於DL的通用性範疇，不在本文討論範圍內。

Pooling可能並沒有我們想像的高大上，DeepMind最近的一篇文章告訴我們：Pooling對於卷積網路在「微小改變不變性」上的貢獻只在訓練開始時候存在，訓練完成後作用不大，詳見 DeepMind論文：CNN的變形穩定性和池化無關，濾波器平滑度才是關鍵

同樣，CNN對於圖像也絕非完美。在Theories of Deep Learning (STATS 385)課程的PPT中，我看到了下面一段，CNN表現較差的case的總結：

Conv層（和Pooling）可能並非DL中必須部分，也可能不是對於圖像效果最好的組件，它們只是目前工程條件下速度和效果的一個不錯的折中。這個折中是如此的「完美」，以至於我們忘記了這點。

目前Conv已經被借用到了各個領域，但我並不把它看成是Conv的通用性，因為很多借用都是用的1D Conv。我認為這是由於Conv和圖像類應用的大量普及，使得Conv的工程基礎設施大幅改善了，而目前DL上的基礎輪子還太少，所以大家試用之後覺得1D Conv還不錯。當然你可以進一步「推廣」到1x1 Conv，這其實就是某些維度上的全聯接層了。

語音與CTC

Connectionist Temporal Classification，它的應用範圍如此之少，以至於在《Deep Learning》一書中對它的描述就只有一句話。CTC的內容可以參考 Sequence Modeling with CTC

下面我簡單摘要一下：

• CTC是一種特殊的可微分的不同長度序列之間的loss。
• 它規定了一種將長序列壓縮為一個短序列的方式：合併連續的重複元素，去掉所有空元素。
• 它主要處理待評估序列較長且「內容」較少，Target序列較短且一般是不可變的label真值，並且不要求輸入Target序列和原始序列的位置對齊方式。

讀者稍微想像一下語音識別端到端的流程就能發現，CTC非常適合該場景，或者說就是為該場景設計的。

相對於沒有CTC的時代，CTC去掉了對於語音label序列中對齊位置的標註，大大降低了標註的成本。同時通過讓模型自己學習對齊方式，減少的對模型的約束，給提升模型效果增加了空間。

適配各種奇怪的特徵、各種奇怪的距離定義

特徵結構

如果說DL在各個領域中應用時遇到的最大的問題是什麼，我覺得就是各種奇怪的特徵表達方式和各種尚未被清晰定義的對象間的距離函數了。我相信非主流領域中的同學應該會同意我的。

我們來列舉一些不那麼簡單的特徵及其結構：

• 符號序列，以NLP為代表。
• 雖然可以通過RNN類結構來在網路中自動把序列長度維壓掉（類似於Pooling），但在某些情況下一個更低成本的方式是利用word2vec類的方案把符號在序列中的順序關係變為一個vec表示（雖然這個方法並不是總work）。
• 樹形結構，例如各種語法樹、AST之類的東西。
• 這方面目前看到的是以TreeLSTM為代表的適配這類樹形結構的網路結構。某種意義上來說，這是一個為樹形結構定製的、共享參數的、自適應深度的組件，也能起到將整個樹形結構「Pooling」成單個vec的作用。
• HTML。
• 圖、網路，例如社交網路、GIS中的道路網路抽象、有限元類方法的離散化結果等。
• 這方面是以node2vec、GCN為代表的一類結構。但我認為以圖上隨機遊走和GCN這種短途類Conv結構不太適合GIS的路網和有限元類方法的結果，以及其他「離散的不好」的結構。
• 而且（個人認為）這類結構在大規模、非小世界網路中學習速度很差。這方面後面有空單獨開篇討論。
• 元素集合。
• 點雲。這是3D物體採樣邊界點的集合，不了解的同學可以參考 點雲數據處理
• 自帶層次關係結構的特徵，如IPv4地址。

還有一些特徵雖然可以當作傳統特徵來處理，但未必是最佳實踐，例如我在 【ML專欄】談One-hot的本質功能 中指出的空間坐標類特徵。

雖然我們可以通過各種xx2vec類的思路來把各種信息都壓成一個vec來處理，但正如目前seq2seq類場景的人所認識到的，把一個seq壓成一個vec算不上一個足夠好的方案，從這個vec生成各種結構的結果時更是令人頭痛。

像TreeLSTM這種在網路結構中就包含了對於對象結構的適應我覺得是最好的方案，而這條線的名字就是可微分編程。

什麼是可微分編程呢，我搜了下發現並沒有達到我預期的介紹文章，可能我後面得考慮單獨寫一篇介紹什麼是我認識中的可微分編程……如果哪位同學看到一個好的這方面的介紹請留言。再此之前大家可以先拿這個知乎問題的答案湊合一下： LeCun 說的可微分編程是什麼？

距離定義

在ML問題中，除了各種結構的特徵的處理以外，另一個重要的問題就是如何定義loss，而這個loss一般都是某種距離或者類似物。

從方法論的角度來說，一個可微分的loss是比特徵、網路結構本身等更重要的東西，這個方面的內容我也計劃後面單獨開文討論……（呃，寫一篇文章之後發現還要再寫3篇……）

拋開方法論的角度，如何定義兩個對象有多相似其實基本包含了我們對某類對象的認知到底有多深入——哪些東西是不重要的，哪些東西是重要的。

但很遺憾的是，除了少數問題（分類、標量回歸等）以外，我們對各種對象的距離認知都還很膚淺。這也是為什麼我對CTC評價很高。

舉一些例子，我們如何在特定場景下定義各種元素的距離呢？

• 不同的不等長序列之間
• 不同的集合之間
• 不同的樹之間
• 不同的圖之間
• 不同的點雲之間。

一個有價值的距離定義意義重大，而且這真的很難。

洞察一個業務場景下如何定義距離非常很難，一個能接在DL網路中的可微分的loss則更難。

領域知識

領域相關的DL組件

經過前面各種討論，我想大家應該能發現，對於不同結構的特徵的處理、不同的loss——這種一般在網路最前幾層和最後幾層的東西——其實和DL的中間結構有很大的差異，而且往往是因場景、問題不同而不同的。

這與其說是DL的一部分，不如說是各個領域適配DL所需要自己準備的東西。這就是我所謂的「刀頭」。

領域知識

很自然的，領域相關的DL組件是一種領域知識。

回顧已經普及的搜索、廣告、推薦，連需求及其工程解決方案都是廣泛普及的。連工程的同學都知道什麼是一個倒排索引，它的作用是什麼。這在很多新的領域是很難想像的，因為這顯然是一個演算法在落地過程中的需求，這絕非一個外領域的工程的同學在沒有演算法視角的情況下能夠獨立洞察的。

要詳細了解一個領域的具體需求，就代表要了解這個領域遇到的常見問題。這裡舉幾個例子：

NLP中的停用詞

簡介見 https://zh.wikipedia.org/wiki/%E5%81%9C%E7%94%A8%E8%AF%8D 。

停用詞是對某些詞的詞頻與其信息量的一個洞察。（題外話：TF-IDF就是沿著這個詞頻與信息量思路產生的一種演算法）

很顯然，這類特殊的詞的發現和特殊處理是一個領域知識，只在特定領域中有用。

基於WiFi的定位

這是一個大家不那麼熟悉的例子。其主要方式就是在用戶手機開GPS的時候同時記錄GPS位置和周圍WiFi，當只有WiFi的時候進行反查。

這裡就有些特殊的WiFi需要處理，可以提高整個定位系統的精度，如移動的WiFi、覆蓋範圍很大的WiFi。

領域知識的傳播與壁壘

廣泛使用的通用的技能其實算不上壁壘，了解DL基礎的畢業生每年正在大量畢業，戰鬥力強又廉價，這給奔三的從業者帶來很大的壓力。所以很多人希望以領域經驗作為壁壘。

那麼上面這種領域組件的經驗是壁壘么，我覺得長期來說也很難。

領域組件本來就是因為其足夠簡化、足夠魯棒才會得到業內的承認，成為一個領域標準組件的。這本身決定了它的廣泛普及、相對容易理解、精確的定義和推導會留下文字資料可供學習，這使得快速上手成為可能。而能快速上手的東西顯然不是壁壘。

領域知識一旦產生，就會隨著技術人員的交流和人員的流動進行傳播，但這個傳播是有速度的。所以最先找到這類領域知識的人和組織會在一個小的時間窗口內受益。

其實在更傳統的行業中，我們能看到一些更讓互聯網同學震驚的事實：領域知識的執行甚至可以創造：公司級的分工、行業、乃至專業學科，例如我在前面文章中提到的「核反應堆安全分析」。

領域問題的建模

領域的需求、領域內的常見問題是領域知識，那麼領域問題的建模方式顯然更是。而且這個可能更符合很多人對領域知識的理解。

這裡我舉一個大家不那麼熟悉但又相對容易想到的一個問題——地圖App中的到達時間預估：

如果把這當成一個ML問題，那麼它的輸入一般有幾個：

• 實際道路的一個抽象表示，這一般表示為一個有向屬性圖。
• 歷史上的導航軌跡（GPS結果序列），可以基本指導每個時間所到達的位置。
• 最近一段時間內正在進行的導航軌跡。

這裡的2和3其實是一種類型的數據，但由於時效性對這個問題非常重要，這兩種數據的處理成本也有很大差異，所以分開。

首先這個問題我們是可以無腦用RNN和DL來做一個模型的，效果調好了不會太差，很多時空數據挖掘的文章也是在這個思路上走的更遠。

但顯然工業界早就解決過這個問題，在那個DL還沒有興起的時代。那麼怎麼解決的呢？

• 這裡有一個假設，或者叫對領域問題結構的一個洞察：相距較遠的不同位置上的車流速度（分布）幾乎沒有相關性。
• 那麼就簡單了，整個軌跡上各小段的耗時可以基本看做是可微的，可獨立處理的。
• 使用一個實時系統來從實時軌跡中拆解和估計各個小段上的通行速度。
• 對由於數據缺乏沒有結果的路段進行各種時間上或空間上的填補/插值。
• 再用這個各小段上的速度（也叫做路況），來合成一個新的路徑上的總時間。
• 這個合成過程可以利用一些從歷史軌跡上學到的位置之間的相關關係結果。

這個思路很顯然，很多沒有做過這方面的同學也能很快想到。

但我們思考這個問題，其實相對於原始的「輸入很多歷史序列和一個待預測序列，回歸一個時間結果的問題」，我們做了一個分解，使得這裡面待學習/統計的參數大大下降了。

在所有的軌跡空間中，想靠KNN之類的方法來回歸簡直是不可能的，從seq的距離定義開始就會卡住。

而新的方法直接簡化為所有位置上的速度的估計和最後的合成問題。雖然光靠軌跡數據仍然無法填滿所有的位置，但基本基本能夠準確地填充大部分，其他靠各種「模型」進行填補。

這幹了件什麼事呢？

就是把原來一個非常高維、極度稀疏的問題近似為了一個較低維空間中的、在現有數據下不那麼稀疏的一個問題來學習/建模，在降低學習需要的樣本數量和訓練時間、提高模型精度的情況下，也提升了模型對於badcase的【可人工快速維護性】。

我現在認為，這就是大數據場景下演算法工程師的領域建模工作的一個概括。從中我們可以看到演算法工程師的工作在這個領域中的價值。

這個過程不光包含了問題的精確定義、抽象、建模，也包括像典型的「臟數據」清洗、不同價值數據的賦權、適合的DL組件構造、訓練流程、線上系統設計和成本折中。

後記

本來重點只是想寫最後一段，結果寫著寫著就成了一個類似綜述的東西，查了各種資料。還留下好幾個坑要填……

推薦閱讀：