我們未來希望能夠用智能做數(shù)據(jù)的自動關聯(lián)，希望把幾十個來源不同的數(shù)據(jù)源、不同格式的扔進去，就可以很快地把數(shù)據(jù)關系梳理清楚，相似、相同的數(shù)據(jù)下表達方式不同的也能夠迅速聚集在一起。
在這個方面我們已經做了很多工作，比如在android的和包方面用了深度學習技術、文本技術，把各種技術集合在一起來判斷多個不同的包是不是屬于一個應用。
讓我們來暢想一下未來，前面提到了在大數(shù)據(jù)上孕育了非常多的智能奇跡。如果在把這些智能運用在駕馭數(shù)據(jù)，可以形成非常好的正循環(huán)，使得數(shù)據(jù)科學發(fā)展變得越來越快的加速螺旋上升的過程，為我們創(chuàng)造更好的未來。
Q&A
Q1：如何訪問talking data的沙箱？
張夏天：目前訪問TalkingData的數(shù)據(jù)沙箱需要向TalkingData提出申請，明確使用數(shù)據(jù)范圍，用途, 并簽訂NDA以后（如果涉及商業(yè)用途還需要簽訂商業(yè)合同）后，TalkingData會為申請者提供訪問帳號。
Q2：也就是一個新版的mllib？
張夏天：可以這么認為。我們在實際使用中，發(fā)現(xiàn)MLLib的問題還是比較多的，無論是訓練速度還是精度都不能滿足我們的需要。因此我們自己實現(xiàn)了一些Spark上的機器學習算法。
Q3：大數(shù)據(jù)應用的最新挑戰(zhàn)是什么？
張夏天：目前來說我們認為最新的挑戰(zhàn)是把數(shù)據(jù)處理流程如何智能化?，F(xiàn)在大數(shù)據(jù)應用最大的一個短板就在于應用的成本很高，而很大一塊以成本就在于基礎的數(shù)據(jù)處理過程，需要投入大量的人力來完成，限制了大數(shù)據(jù)應用的規(guī)?；焖購椭?。因此我們認為未來應該應用數(shù)據(jù)科學，人工智能的先進技術和方法來解決數(shù)據(jù)處理過程過于繁瑣和笨重的問題，降低大數(shù)據(jù)應用的成本。
Q4：fetegata基于spark實現(xiàn)的，他是如何做到性能比spark高很多倍。另外我們用它不需要調整參數(shù)就可以得到很好的效果，具體是怎么做到的？
張夏天：最根本的原因就是提高了算法的收斂速度和穩(wěn)定性，使得在一般情況下，只需要掃描一次數(shù)據(jù)，極大降低IO開銷。關于Fregata是如何做到這點的，大家可以耐心等待幾周，我們很快將把Fregata開源出來，同時會在arxiv網(wǎng)站上publish相關論文，屆時歡迎到家試用和批評指正。
Q5：lib庫的一個特點是根據(jù)內存大小，自動調整維度么？
張夏天：是的。因為Spark平臺本身的限制，參數(shù)并行很困難，因此單個節(jié)點的內存大小就限制了模型的大小。在面對超大維度問題時，通過稀疏正則化可以降低模型的規(guī)模，使得能夠在單個節(jié)點的內存中存儲。但是一般的稀疏正則化方法的稀疏度是依賴于L1正則化項的系數(shù)的，并不能精確控制模型的稀疏度。我們在很多實踐中發(fā)現(xiàn)，做模型稀疏度越高其精度也會越低，所以我們希望算法能夠把模型的規(guī)模降到內存剛好裝下的規(guī)模，取得精度和效率之間最好的平衡。
Q6：您好，fregata的功能確實很強悍，目前是開源的嗎，普通用戶怎么能夠體驗到？
張夏天：10月份之內會開源，到時候會發(fā)布到Github上，所有人都能使用。我們將采用Apache 2.0的License。
Q7：在優(yōu)化過程中，模型平均是否受數(shù)據(jù)分布傾斜的影響，比梯度平均較大？你們工作中，比spark的梯度平均好的原因，是不是因為你們的數(shù)據(jù)分布較均衡？這是不是算是極端情形，而不能看做一般情形？
張夏天：應該不是。我們的測試不僅是基于我們自己的數(shù)據(jù)，我們還測試了很多公開數(shù)據(jù)集。有大數(shù)據(jù)集，也有小數(shù)據(jù)集，有低維度密集數(shù)據(jù)，也有高維度系數(shù)數(shù)據(jù)。測試的結果都是類似的。