頑疾

Airbnb的數(shù)據(jù)團(tuán)隊(duì)很重要的一個(gè)職責(zé)就是傳播基于數(shù)據(jù)的決策方法。我們將數(shù)據(jù)的獲取民主化，使得每一個(gè)Airbnb的成員都可以量化他們基于數(shù)據(jù)的決策影響力并且借此洞察用戶偏好，提升數(shù)據(jù)產(chǎn)品的用戶體驗(yàn)。最近，我們開始解決一個(gè)令人頭疼的問題。隨著組織的擴(kuò)大，如何確保我們?nèi)绾未_保一個(gè)洞見有效地通過社交網(wǎng)絡(luò)，這在我們內(nèi)部稱之為知識(shí)擴(kuò)張。

當(dāng)我們團(tuán)隊(duì)僅由幾個(gè)樂于分享和發(fā)現(xiàn)研究技巧的人組成這不是什么難題。但是當(dāng)我們團(tuán)隊(duì)開始快速擴(kuò)張時(shí)，這個(gè)問題一下就被放大了。Jennifer是一位新來的數(shù)據(jù)科學(xué)家，她正在研究如何通過房東拒租的話題和同事開展工作。

這里是我們所看到的：

1. Jennifer 找到了一堆的PPT、Email、Google Docs 并且詢問團(tuán)隊(duì)其他成員有關(guān)這個(gè)項(xiàng)目的歷史。
2. 前人的代碼已經(jīng)不是最新的了，但 Jennifer 還是從 GitHub 或者原來作者的機(jī)器上弄下來代碼。
3. 在和代碼一頓混戰(zhàn)之后， Jennifer 意識(shí)到之前的項(xiàng)目有些許問題，她決定從頭開始擼代碼。
4. 在浪費(fèi)大量重復(fù)工作之后，Jennifer 又放棄了重頭開始的想法，她感到精疲力盡。
5. Jennifer 留下了一堆的 PPT、Email、Google Doc, 循環(huán)往復(fù)。

基于其他公司的對(duì)話，我們發(fā)現(xiàn)這個(gè)現(xiàn)象實(shí)在太普遍了。隨著組織的擴(kuò)張，跨團(tuán)隊(duì)跨時(shí)期的知識(shí)傳輸成本不斷增長(zhǎng)，一個(gè)低效、烏合的研究環(huán)境使得這種情況雪上加霜，放慢了分析和決策的速度。因此，一個(gè)更加一氣呵成的解決方案可以加快決策落地的速度并且保持公司在知識(shí)洪流中立于不敗之地。

藥方

隨著我們看到這個(gè)問題工作流的不斷發(fā)生，我們意識(shí)到我們可以做得更好。作為一個(gè)團(tuán)隊(duì)，我們?cè)谝黄饹Q定了做研究的五個(gè)關(guān)鍵原則：

• 可重復(fù)性 - 代碼不應(yīng)該分離，整個(gè)查詢、轉(zhuǎn)化、可視化、文檔撰寫應(yīng)該一氣呵成，并且保證結(jié)果是盡量更新的。
• 質(zhì)量 - 沒有經(jīng)過正確性和準(zhǔn)確性審查的研究都不應(yīng)該被共享。
• 用戶體驗(yàn) - 研究結(jié)果應(yīng)該是讓讀者容易理解的，我們也應(yīng)該將美感和品牌延伸考慮在內(nèi)。
• 可得性 - 任何人都可以發(fā)現(xiàn)、瀏覽并且保持在相關(guān)工作話題上的更新。
• 學(xué)習(xí)價(jià)值 -  與可重復(fù)性，其他研究者應(yīng)該能夠通過工具和技術(shù)從其他人的工作中增益自己的能力。

根據(jù)這些原則，我們單獨(dú)調(diào)查了現(xiàn)有的工具來解決這個(gè)問題。我們注意到Rmarkdown和 iPython notebook 是一個(gè)可重復(fù)性研究的一個(gè)優(yōu)秀解決方案。 GitHub 提供了一個(gè)審查框架，但是對(duì)于代碼之外的內(nèi)容和文檔，比如圖片就沒有什么好的解決方案。 可得性通常是基于文件夾的形式的，但是類似Quora這樣的其他站點(diǎn)內(nèi)在對(duì)標(biāo)簽和話題又有特殊的審查機(jī)制。

綜上，我們將這些想法集成到一個(gè)系統(tǒng)里面。我們的解決方案整合了貢獻(xiàn)和審查的工作，用一個(gè)工具來呈現(xiàn)和傳播知識(shí)。我們內(nèi)部稱之為"知識(shí)倉庫"。

這里的核心其實(shí)是一個(gè)我們提交工作成果的 Git 倉庫。我們?cè)?Jupyter 筆記、Rmarkdown 文件或者純 markdown都會(huì)發(fā)布在這里，所有的文件(包括查詢文件和腳本)都會(huì)被提交。每個(gè)文件都從一個(gè)很小的結(jié)構(gòu)化元數(shù)據(jù)開始，包括作者、標(biāo)簽以及TLDR，再用一個(gè)Pyhon腳本驗(yàn)證內(nèi)容并用Markdown格式轉(zhuǎn)化為純文本。我們使用 GitHub 從審查流程中拉取請(qǐng)求系統(tǒng)。最后，用一個(gè) Flask的 web-app 來渲染Repo的內(nèi)容作為一個(gè)按時(shí)間、話題、內(nèi)容排序的內(nèi)部博客。

這些工具集的最頂層，我們有一個(gè)流程 專注于確保所有研究是高質(zhì)量和高可用的。和工程代碼不同，低質(zhì)量的研究是不會(huì)產(chǎn)生指標(biāo)下降或崩潰日志的。相反，低質(zhì)量的研究表現(xiàn)為知識(shí)的環(huán)境嘈雜，而團(tuán)隊(duì)只能信任他們自己創(chuàng)建的研究。

為了避免這種現(xiàn)象的發(fā)生，我們將流程封裝在工具里面，結(jié)合了工程上的代碼評(píng)審和學(xué)術(shù)上的同行評(píng)議方法，保證我們的研究結(jié)果以一個(gè)startup的速度在推進(jìn)。在代碼評(píng)審的環(huán)節(jié)，我們檢查代碼的正確性、最佳實(shí)踐和工具。在同行評(píng)議上，我們檢查方法論的改進(jìn)、現(xiàn)有工作的關(guān)聯(lián)性以及準(zhǔn)確的解釋性聲明。我們通常不指望一個(gè)研究是面面俱到的，但是也不能草率迭代，這些對(duì)他們都是有正確的和透明的限制的。我們能夠駕馭內(nèi)部的R和Python包并維護(hù)品牌調(diào)性、整合數(shù)據(jù)倉庫的函數(shù)庫、以及基于GitHub的R和Python筆記的文件處理流程。

圖一 - 一個(gè)兩篇文章的總結(jié)卡牌的知識(shí)流截圖

圖二 — 一篇房東同意接待的缺口天數(shù)的研究文章示例

這些工作為我們的智囊團(tuán)提供了強(qiáng)大的功能。

• 可重復(fù)性 — 這個(gè)工作從核心的ETL表查詢到轉(zhuǎn)化、可視化到整理文章都是在一個(gè)文件里完成的。通常是 Jupyter 筆記, RMarkdown, 或 markdown 文件。
• 質(zhì)量 — 通過學(xué)習(xí)GitHub來發(fā)表、審查以及版本控制直接推動(dòng)了我們整個(gè)工作流。
• 高可用 - markdown 將我們的 web-app 隱藏在代碼之后并且我們使用了內(nèi)部一致的美學(xué)風(fēng)格，對(duì)非技術(shù)讀者也更加友好。同行評(píng)審用評(píng)論也能提供反饋和交流并提高了項(xiàng)目的影響力。
• 可得性 - 元數(shù)據(jù)的結(jié)構(gòu)非常有利于通篇瀏覽歷史研究。每個(gè)文章都有一組tag，并有一個(gè)類似于知乎話題的多對(duì)一的內(nèi)置話題機(jī)制。用戶可以訂閱話題并且收到新消息提醒。文章可以以書簽收藏、通過讀者瀏覽或者在博客流中訂閱。
• 學(xué)習(xí)價(jià)值 - 通過之前一系列的工作，現(xiàn)在數(shù)據(jù)科學(xué)家可以分享自己的新方法論、代碼技術(shù)并且加快品牌化推廣，讓團(tuán)隊(duì)之外的人可以快速了解自己的領(lǐng)域。

這個(gè)知識(shí)倉庫囊括了海量的內(nèi)容。大量的工作都是和某個(gè)非嘗試性問題的深挖，但是對(duì)實(shí)驗(yàn)結(jié)果的檢驗(yàn)沒有被我們的實(shí)驗(yàn)記者記錄也是很普遍的。此外也有一些純粹關(guān)于如何擴(kuò)展數(shù)據(jù)分析的文章，包括新方法論的撰寫、工具或包的示例、使用SQL和Spark的教程等等。我們也在知識(shí)倉庫上公開數(shù)據(jù)博客文章，當(dāng)然也包括這一篇。總的來說，這個(gè)原則就是：如果這個(gè)東西將來可能對(duì)一些人有用就可以發(fā)。

未來

知識(shí)倉庫仍然是個(gè)在建工程。小團(tuán)隊(duì)正在持續(xù)滿足新需求特性。我們也在公司內(nèi)部的其他團(tuán)隊(duì)推廣這種方法，比如一些不使用GitHub的量化研究。最后，我們正在測(cè)試一個(gè)基于Markdown的內(nèi)建審查編輯應(yīng)用，這個(gè)應(yīng)用另一個(gè)可能的特性是主編對(duì)研究議題的管理，我們也正在考慮現(xiàn)有文章的遷移問題。