智慧城市是什麼？國內一直沒有一個清晰的定義。業內各方從自身角度出發都做過一些嘗試，但目前還沒有形成一個共識。為了儘可能更準確地定義「智慧城市」，機器之心決定推出「智慧城市深度訪談」系列。
我們希望透過多角度轉述業內專家的觀點，呈現出一個目前中國在「智慧城市」領域的發展現狀及所遇困難的全貌，以供各方參考。
我們認為，智慧城市不應是高房大瓦與電子版「千里眼順風耳」的簡單堆砌。而應從體驗出發，在軟性環境中體現出一個城市對居民的人文關懷。
要做到這一點，第一步便是能感知市民的整體真實需求。其中，讓機器理解人的語言以及「資料打通」的能力必不可少。
作為機器之心「智慧城市深度訪談」的第一站，我們有幸採訪了一家在自然語言處理以及大資料領域已有多年專案經驗，並有自己獨特工程化思考的上市公司。與人們的印象不同，神州泰嶽透過多年的兼併重組，已經陸續發展出人工智慧、物聯網板塊，成為了一家多板塊綜合性企業。
本次訪談的嘉賓，神州泰嶽人工智慧研究院院長晉耀紅博士，與 AI 大資料副總裁張瑞飛，共同向我們介紹了神州泰嶽與眾不同的基於語言學知識構建的 NLP 語義分析平臺，及以「資料高速通道」取代「動遷式」做法的智慧城市大資料新思路，還介紹了神州泰嶽如何透過工程化的思路，讓人工智慧演算法真正結合到實際智慧公安場景中的經驗。
以下為對話原文，機器之心做了不改變原意的整理：
需求驅動的語義分析工程特色
機器之心：神州泰嶽人工智慧聚焦自然語言處理技術，業界對神州泰嶽人工智慧業務最起初的認識也是從「DINFO-OEC 非結構化文字分析挖掘平臺」這個語義分析產品開始的，該平臺是如何設計並建設起來的？
晉耀紅：我之前在中科院主要做「HNC（Hierarchical Network of Concepts）概念層次網路理論」的研究，這是一套涉及詞語、句子到篇章之間的關係全框架理論。
當時希望設計一套語義網絡把語義給符號化，比如「高興」和「傷心」是一對反義詞，但把這對詞直接輸入到計算機，計算機是無法理解這對詞之間的反義關係，我們希望透過用符號的語言描述讓計算機能理解這種關係。
後來在北師大時做的國家課題——「針對海量文字的知識表示和計算」，也是基於 HNC 理論上的擴充研究，是十二五國家 863 專案中中文資訊處理語義相關的唯一課題。
再後來創辦了中科鼎富，做企業以後才發現一個個零散演算法的研究，在面對客戶的具體需求時是遠遠不夠的，對方更希望直接看到產品在他們的業務場景下能產生什麼效果。後來在市場上慢慢開啟局面的方法，就是推出「DINFO-OEC 語義分析平臺」。
DINFO 為「鼎富」的英文名，OEC 代表「Ontology-Element-Conception」，「OEC 模型」是由本體樹、要素樹和概念樹三棵樹組成。我們希望由本體樹、要素樹直接描述業務，由概念樹來對剩下的複雜語言的語義進行處理。
OEC 平臺主要做兩件事：1、把零散的演算法按一定規則整合起來；2、根據業務建模，即把客戶的業務知識系統性地透過符號化處理表達出來，平臺底層演算法自動把資料進行整理。平臺的定位就是把資訊系統性地分類整理出來，將非結構化資訊轉結構化，根據演算法自動把資訊進行分類、提取標籤。
比如在處理投訴業務的客服場景，客服系統接收到的是一條條非結構化的投訴文字資訊，OEC 平臺能將投訴的「物件」、「內容」、「重要性」等結構化資訊從文字中分析出來。一條投訴文字可能有 1000 字，客服想要看的可能就是幾個資訊點，比如建議、表揚，還是投訴等標籤化的資訊。
目前平臺底層中與 NLP 相關的演算法有 200 多個。最簡單的如 word2vec 這些訓練的工具，在平臺底層都有整合。訓練的時候可以自行選擇 SVM、LSTM 等演算法。平臺在金融、公安業務中的分類、提取功能的正確率和召回率都能達到 95% 以上。
機器之心：目前神州泰嶽的 OEC 語義分析平臺在業內有競品嗎？
晉耀紅：我們在業界暫時沒有競品。
在演算法技術路線上，我們更強調對語言本身的理解，堅持以本體論為框架，把人的語言學知識符號化，區域性結合機器學習的演算法。從我們在中科院期間研究的 HNC 概念層次網路理論到現在的 OEC 平臺，其實都是以本體論為核心。
我們在這個技術路線下，希望在更高、更抽象的層次，用本體論的思想把理解相關的根本性的知識解決掉，剩下的適合交給演算法的區域性再交給演算法處理。
國內其他一些跟 NLP 相關的公司，目前主要還是在演算法層面希望做的更精細。受到深度學習的影響，目前國內其他公司研究的重點更多是 seq2seq 的這類跟語音相關的問題。輸入的是語音的 sequence，輸出的是文字流的 sequence，對句子與句子之間語義關聯性，以及篇章中段落之間的關聯性關注要少一些。
這種方法適用性可能會更好一些，但最根本的問題是沒有真正的理解語言。單獨基於深度學習的演算法，在測試集上看上去效果很好，但是實際落地的場景中基本很少看到。因為在實際落地的場景中，訓練的語料庫往往沒有那麼大。
機器之心：所以稱神州泰嶽 NLP 技術「自成一派」的原因主要還是在選擇以本體論為核心的語義理解技術路徑上。能否再具體介紹一下你們的技術研發方法論？
晉耀紅：NLP 對於語義領域的研究現有兩大學派：一派堅持用一定的語言學知識為基礎的研究方法；另一派是純計算機的，主張完全用計算機演算法來拆解語言之間的關係，包括用統計學習、機器學習、深度學習等方法。這兩派暫時沒有孰優孰劣之分，要靠實踐來檢驗。
我們跟很多純計算機學派的研究者也是朋友，他們的觀點主要是，不管語言裡是什麼都標註出來。但這有點像大海撈針，需要考量背後的計算力及付出的代價。基於語言學的研究者則希望教會計算機人類語言的規則和知識。在這一點上，兩個派別不能達成一致。
神州泰嶽作為一家商業化運營的公司，主要服務企業客戶，目的是在有限的時間內有效解決問題，不參加學術研究路線之間的爭論。
我們從歷史工程專案中總結的經驗出發，把已有的人類語言學的知識，透過語義庫告訴機器。在多年的積累下，我們的語義庫已積累了 80000 餘個語義概念，主要是中文詞，包括上位詞、下位詞、同義、轉義等等，透過語義對一個詞在特定語境下的概念進行描述。
語義庫是人對常識知識和語言知識的積累和表示，所以我們希望把它符號化。目前我們有一個由 30 餘人的語義庫團隊在做語義符號化的工作，他們大部分是語言學背景的。
除此之外，還有語料庫，主要對客戶的文字資料進行標註，從中提取和分析出來其中包括的語言知識。前段時間神州泰嶽跟北師大聯合釋出的 Chinese Word Vector 語料庫，這個語料庫生成的 word2vec 基礎資源機器可以直接使用。（機器之心報導：深度 | 自然語言處理的一大步，應用Word2Vec模型學習單詞向量表徵）
從語料到語義存在一個知識的提煉過程，語義庫和語料庫是一個相輔相成的關係。
把人的語言學知識告訴機器的做法，一個最明顯的優勢是在應用場景下可以做到冷啟動。比如公安、客服系統，用已有的語義分析框架使系統先啟動起來。雖然也許一開始效果並不一定特別理想，假設準確率是 50%，但這部分準確的語料就可以作為標註語料，作為演算法學習的樣本，去做擴充，然後做一定的泛化。這樣形成一個良性迴圈，不斷的逼近客戶要求。
目前很多深度學習應用場景下，需要足夠的語料來訓練。假如光訓練預料就需要 1 個月，這 1 個月也許客戶就沒有耐心了。有些客戶就是想要兩天時間內就看到效果。另外很多客戶資料也不可公開，無法準備出符合要求規模的資料去讓機器訓練。
張瑞飛：80-90% 的客戶都有這樣的問題，比如中國電信，客服的動單分類有 2000 多項。電信自己整理了 3 個多月，每一個分類下的資料都很少，但電信也不可能在每一個細分小類都幫助我們訓練出那麼大量的資料，提供給機器學習演算法訓練。
實踐過程中很多場景都有這個資料冷啟動的問題。晉博士提出的方法是在沒語料的情況下能產生一定效果，然後在效果上進行最佳化迭代。
晉耀紅：再比如，我們最近在給工信部做一個公文寫作的研究課題，其中一個模組就用到深度學習的方法來對句子進行復述，把表達方式上弄得更豐富一些。但我們發現公文的語料就很少，我們把所有工信部的公文全部蒐集起來才 18000 篇。18000 篇對於公文來說已經很多了，但是對於機器 seq2seq 的演算法還是很少，這樣用深度學習訓練出來的演算法還不可用。
所以我們就結合人的經驗知識，讓機器在 18000 篇裡面自動學習每一種公文型別，或者每一個發文物件寫作的規範或者寫作的格式。利用學習的結果去摘取或者自動寫一些句子，所以在這種場景中我們還是把人的知識結合起來。
工程經驗幫助平臺完善底層演算法
機器之心：在面對自然語言理解的問題時，很多訓練語料都需要人工提前標註。但也是因為語言的範疇很大，語義特徵定義起來很困難。那語義模型的泛化能力的根本，是否取決於人們花多少時間去標註出多大規模的語料？
晉耀紅：這裡面其實涉及兩大類知識。
第一類是需要人工定義，用於理解基本詞彙語義的「常識性知識」。比如我們這個對話的場景下，很多關於人工智慧的知識都算是常識，開始對話前對話雙方就都理解了，這就建立在雙方都互相瞭解一些特定詞彙的概念的基礎上。在我們這個平臺模型裡，主要體現在常用詞彙的語義和語義關聯性，比如「高興」和「傷心」這兩個詞在各個行業場景中的意思基本不會變。這類常識性語義的知識基本靠人工來構建。目前我們已經構建了 80000 多個資源的語義庫，覆蓋了大部分的中文詞彙。
另一類是可以人工給的，但也可以透過人工標註讓機器自動學的「非常識性知識」。比如特定領域的分類體系，需要人工給定義，機器可以進行一定程度的學習，但主要還是靠人工。但也有一些領域可以透過語料標註來自動學的。比如司法領域裡，一些收集不全的專業法律術語就可以透過演算法、語料讓機器自動學習。
張瑞飛：深度學習的方法要有泛化的能力，一定需要資料去驅動。
舉一個實際情況例子，我們對 A 市公安案事件的學習，模型對案件分類、要素提取的準確率，直接用深度學習的方法可能能到 70-80%，但是一放到 B 市、C 市公安案事件，準確率就會降到 50% 以下。因為比如一些 B 市、C 市的方言語料，系統在 A 市的文字中沒有見過。
那麼解決的方法，第一種就是疊加使用晉博士基於本體論的方法。因為本體論是可以透過小語料用符號規則來表示的，注入先驗知識。我們透過這個方法把深度學習模型 70-80% 的準確率提升到 90% 以上。
第二種是透過遷移學習的方法。
第三就是使用大量標註語料。我們對整個公安 400 萬個案事件進行了標註，提取了該領域的詞向量 20000 個。透過上面多種方法的疊加，最終準確率達到 99%。達到這樣的水平，我們才能說有泛化能力。
這個過程付出的成本還是挺大的，因為公安網不允許連外網，一定要駐場標註。同時還需要透過一線業務人員的反饋，才能知道提取的特徵的準確性。而且在模型黑箱訓練的過程中，還沒法進行修改。
所以不結合晉博士的先驗知識的能力，我們是沒有辦法在公安落地的。如果準確率只有 75%，肯定不夠，平臺就沒法用了。
機器之心: 就上述公安的專案，標註的成本和效率大概是怎樣？
張瑞飛：我們駐場了 50 多個人，標註了一年半，標註了 400 萬個案事件，基本覆蓋了國內至少 30、40 個地市級城市在過去十年的所有案事件。
案事件有一些特徵，就是例子特別少，數量跟新聞根本沒辦法比。另外案事描述一般特別短小，幾乎沒有統計的特徵，沒法根據詞頻統計重複出現的詞彙。
如果我們單純靠深度學習，其實效果並不好，就必須結合的晉博士的理論進行結合，當然結合方式有深淺之分。
機器之心：在公安場景中，每個刑警基於自己的斷案經驗，可能都會有一套專屬的斷案方法論，比如需要蒐集哪些線索、哪些線索最有價值。OEC 平臺在建設過程中是如何使用人的經驗？並且在實際應用中如何與人的研判資訊相結合、互動？
張瑞飛：我們的「神州泰嶽智腦 2」的系統裡，研判路徑是自學習的一個過程。
每個刑警在斷案的時候的確都有自己的思維規律，但是這些思維規律主要可以歸納為四種——圖譜、時間軸、地圖、標籤分類，這是我們總結的基本的研判模式。
對每一個研判路徑，我們定義了需要輸入的準確的資料型別，在介面上會要求業務人員輸入相關資訊，系統在後臺就能形成一個引數。
也許在訓練半年以後，系統就可以根據案件自動分類，在沒有人工干預前，沿著以前的研判路徑進行判斷。做到這種程度就可以減少反應時間，這種預處理在需要時就可以馬上針對大批次案件計算出來路徑，比以前可能要算 48 小時效率高很多。
另外，這個系統可以替代人對已有線索的遺忘。人在專注於一個焦點問題時，可能會忽略之前的線索，這時系統可以幫助人去處理一些背景資訊線索，讓人可以把精力聚焦在最需要關注的問題上，而又不會忽略掉重要的背景聯絡。
這是我們倡導的一個人機互動的模型，做到這一步後，我們希望後續可以幫助公安去自動地釋出作戰指令，甚至去建設一個真正的「公安大腦」。
在這個平臺的幫助下，當遇到重大案子而派出所沒有足夠研判的警力時，就可以申請技偵、現場勘查、刑偵等資源，像會診一樣，多個部門一起形成一個指揮方案；或者突發一些重要事件時，公安需要馬上將各種資訊結合起來的時候，人工智慧的威力就能很好體現。合作作戰平臺帶來的應急和同步上案能力的提升是傳統的合作作戰方案給予不了的。
「資料打通」的新思路
機器之心：神州泰嶽除了語義分析 OEC 平臺，還開發了一系列大資料產品。自然語義處理技術要在實踐中落地，底層的資料打通是否必不可少？
張瑞飛：資料是實現人工智慧技術應用的必要前提。在未來的五年，我們覺得資料打通和共享是常態。
公安現在建大資料中心，就是想解決公安部內部資訊打通、融合的問題。
政府最高層是有意要打破這個資料壁壘的。比如，公安部部長趙克志在深圳講：「要大力推進公安資料智慧化建設，堅決打破部門警種壁壘，推進資料融合共享，加強高階整合應用，助推警務流程再造。」
我們覺得，我們目前在做的事情跟趙部長提的理念非常接近了。
為了幫助企業管理資料，我們做了三種資料打通：結構化資料和非結構化資料打通——「Dinfo-OEC 語義分析平臺」、網際網路外網資料和企業內網資料的打通——「蜂鳥資訊採集系統」、企業各類應用系統和第三方系統之間的高速資料共享——「Buffer 資料流水線」。
機器之心：能否具體介紹一下「Buffer 資料流水線」是如何幫助機構內部和機構之間實現「資料打通」？
張瑞飛：傳統大資料公司做智慧城市的資料打通通常是「動遷式做法」，建一個大資料平臺把所有現有分佈在機構內部各處的資料收上來。但我們做的是建高速的資料共享通道——「Buffer 資料流水線」，將企業內部各類應用系統和第三方系統之間建立連線。
我們認為，通道的方式比動遷的方式更好。如果把通道的做法比喻為修路，原來的資料庫比喻成村子或者樓也好，透過通道我們可以把它連成一個虛擬的資料資源池，就是數字的虛擬化。同時資料高速通道加速了資料處理速度，打通的過程中就可以開始服務客戶，而不是等建成後才服務客戶。比如運算速度不夠，就提高運算力；如果客戶把資料輸給我，我會把更多的資料接入進來幫你碰撞，然後把結果還給大家。這樣就避免了一些人為的壁壘。
另外，這背後其實有深刻的計算理論，我們認為傳統的 ETL（資料倉儲技術，Extract-Transform-Load，抽取-轉換-載入）應該要被顛覆掉了。這個說法也不是我們提出的，是 16 年 Kafka 的創始人在舊金山 Qcon 會議做了一個「傳統 ETL 已死，而實時流長存」演講。
兩年前，我們跟公安探討過如何替代掉大資料 Lambda 架構的方式。「Buffer 資料流水線」是我們當年理念的一個落地。
在 Lambda 架構裡，實時要寫一條程式，批次處理時要再寫一條程式，這樣就沒法維護資料的一致性，而且程式開發特別複雜。我們必須有一個通道去把實時資料和批次資料做在一起，然後就能處理近乎無限的資料來源。
比如，亞馬遜今天可以在一個通道里不區分實時、批次地去處理 50 萬以上的資料來源。我們需要這樣的方法來適應大資料今天的變化速度，這樣我們才能在交換和共享的過程中去載入一些像深度學習這樣的演算法，能在通道里把資料都連線起來。
當然在這個過程當中，我們認為傳統的 Oracle GoldenGate 或者 Dell Shareplex 就沒有必要存在了，因為我們在適配這層當中就把這個傳統的做法取代了。
「Buffer 資料流水線」系統其實是幾個技術的結合：第一，流式資料處理技術，比如說像 Storm；第二，流資料和記憶體資料庫（資料空間）的對映，在這裡面可以處理事務和帶狀態的邏輯；第三，資料來源端的適配，比如說 Hadoop 導到 GreenPlum，Oracle 9 到 Oracle 10，或者 Mysql。
國內的公司很多做的是開源的封裝，主要在表層，但我們主要是在大資料底層去改程式碼。當然也會去借鑑一些開源的程式碼，因為開源有好多豐富的場景因為錘鍊的成熟度比較高了，但是從底層去最佳化跟封裝就產生了完全不同的兩個體系。
用開源的封裝方法存在一些問題，比如封裝好了，Spark 的更新，系統是跟不上的。另外，封裝解決的問題比較表層，一個看起來有很多類別的平臺，但是遇到要如何分析這些大資料的問題時，往往會卡在很基礎的技術上。
資料的交換與共享是大資料應用的大趨勢。在底層去 Lambda 化和替代傳統的 ETL，以及打通資料流水線的高速公路，就是我們最近在技術上必做的事。
大資料+人工智慧如何結合落地？
機器之心：我們其實一直有意尋找在智慧城市中多元大資料結合分析語義的案例。之前提到神州泰嶽還與雲從科技這類做安防領域計算機視覺的公司合作，目的是將文字和視覺的語義資訊進行融合嗎？
張瑞飛：語義和影像在將來是必須結合的東西。
貴陽公安提出的「人像大資料」，所謂人像大資料其實就是人的大資料和像的大資料，以及大資料平臺三合一。像的大資料就是影像。人的大資料從哪來？只能從文字來。
在刻畫人物時，公安主要是透過卷宗文字、DNA 檔案、現場勘查記錄、檔案、手機聊天資訊、網際網路資訊等，把大資料提取出來的線索串並起來，使人的特徵浮現出來，再跟影像進行比對。這就是一個實際化的應用場景。
其實視覺目前也有不成熟的地方，今天的視覺識別都還是從一個較窄的領域去做識別，有較大的侷限性。比如說人臉，一旦被遮擋了，對人腦去識別是沒有什麼區別的，但是對於機器就有區別。
應用領域窄，就限制了視覺技術在公安領域的應用。比如公安有一個億人臉的資料庫，機器透過身份證照片識別出 95% 相似度的人臉照片可能會達到幾百張。幾百張相似的人臉如果都要公安直接全部去跟蹤篩選、分析，數量就太大了，在人力物力成本都不可行。
對於公安來說要達到可用的程度，就必須壓縮到十幾張的數量，怎麼壓縮呢？一方面是案事件的串並，把人的線索提取出來。比如說戴眼鏡的，就從幾百張裡面調出戴眼鏡的幾十張；還有總穿牛仔褲或者總戴鴨舌帽的，走路姿態是右肩膀還是左肩膀比較高？這些特徵都可以從影片學習中提取出來。
我們透過這種方法使視覺演算法在一個大的資料集中的應用變得可行，透過平臺把演算法和工程形成一個互補，從而能把人準確地從資料中挖掘出來，這就不是一家創業公司可以單獨做到的事情了。
我們在貴陽與雲從的合作，創業公司偏向於只提供視覺識別技術 API，不太喜歡駐場解決工程化的問題。因為對於像雲從這種創業公司來說，更重視的是短期內佔領更多的市場，而不是在一個點做深。但是總要人去把這件事情做深，所以神州泰嶽就整合整個應用，提供工程化解決方案。
我們雖然是做語義的公司，但是神州泰嶽在深圳公安是人工智慧的組長，團隊中包括騰訊、華為在內。我們整合的人工智慧就不能理解為語義本身了，而是整個人工智慧和大資料應用到底怎麼結合起來的課題。
所以越是接觸這類專案，我們就越認識到區域性作坊式研究的一個個演算法必須被聚集起來，這就是我們要做一個平臺的原因。
歸根到底，人工智慧就是個工程的事
機器之心：神州泰嶽做了那麼多產品，什麼時候決定要往工程化的路線去做人工智慧？
張瑞飛：當我們 16 年 8 月份啟動「智享雲平臺」的時候，對未來方向其實也還有點模糊，但是現在看來越來越清晰。
在未來我們認為單一演算法很難構成競爭力，因為會有很多新的分支而且演算法很容易被複制。比如 ITGCM，懂 GCM 演算法的人如果要做 ITGCM 就很容易。我們考慮：單純專注演算法研究能帶來的突破是不是太有限了？第一，單純的演算法帶來的實際業務突破可能不會超過 2%；第二，演算法太容易被複製了。
我們問過自己一個問題，企業在發展的過程中應該沉澱的是什麼？如果說是科學家和演算法的話，那可能就錯了，因為其實沉澱不下來。
另外，我們也去真正思考成本的問題。比如神州泰嶽有 600 人的人工智慧團隊，這一年的人工成本如何解決。在人工智慧這麼火的時候，我們如何維持三年以上工程團隊的穩定性。這些問題就切切實實擺在企業面前。這些問題解決好了，某種意義上講，我們的專案管理就做好了。同樣一個專案，如果我們的成本是 400 萬，別人的成本是 4000 萬，我們覺得他們沒法跟我們抗衡。
第三點，人工智慧不太可能走向「魔幻人工智慧」，即演算法不太可能輕易發生大躍進。我們其實試過特別新的演算法，除了某些演算法我們覺得確實有提升之外，大部分演算法其實還是一種理論嘗試，最後還是迴歸到一些傳統的深度學習模型中。
這樣我們就想，是不是今天的人工智慧走工程化的路線就是必然的選擇？
這個結論背後有兩個基礎理論：第一，人工智慧是基於形式推理的而建立的，而形式推理是可以機械化的；第二，資訊理論和控制論的發展，導致了形式推理可以工程化。
包括深度學習或者 CNN 神經網路在 08 年以後逐漸發展，我認為都是對這兩個理論的擴充。在這兩個基礎理論不變的時候，我們不敢設想魔幻人工智慧的產生，只能是沿著工程化的方法去做人工智慧。
工程化的路線，就決定了我們要去做各種技術儲備，比如蜂鳥資訊採集、Buffer 流水線、流程引擎（用於合成作戰）、底層大資料平臺、DINFO-OEC 語義分析平臺，智享雲平臺等等。
這些工程化平臺都是為了實現技術落地。沒有平臺，技術就落不了地。我們做了兩年，感覺到要實現產業化落地，這些付出是必須的。
我覺得我們這類面向大 B 的公司都可以嘗試：在原來在大 B 公司積累的資源和工程化的經驗的基礎上，再銳意突破一些深度學習的演算法技術，做出自己的演算法特色來，進而打造出獨特的落地場景。這種落地是很難被取代的，這種工程化的投入會把公司差異開來，而不是演算法把大家差異開。
機器之心：我們瞭解到中國中文資訊學會和神州泰嶽合作做了一個產學研平臺——「中文資訊（深度處理）開放創新平臺 China-NLP」，能否介紹一下創辦這個平臺的初衷及意義？
張瑞飛：這個平臺的出發點是人工智慧需要從手工作坊的做法走向工業化的做法。
目前很多學校的老師做研究的方法依舊是手工作坊的作法，是在區域性研究一個一個演算法，對於全域性的需求沒有明確的認知。我們認為，人工智慧除了演算法本身之外，有很多問題是在產業落地的過程中才能發現並解決的。
比如資料本身的交換和共享問題；怎麼把 tensorflow，或者其他的深度學習工具，變成分散式的，或者極限化的一個資源池；能不能夠用最小的硬體，或者 CPU 的指令級去最佳化現在的計算。這些都是工程化的過程中，一個平臺要考慮的問題。
又比如一位教授做了一個針對醫療領域的深度問答引擎，跟醫院對接的時候就會遇到這個引擎如何與已有的系統對接的問題；另外，這個系統跟已有的病人病例系統是什麼關係？怎麼來評估這套系統能不能上線？上線後需要什麼框架？資料怎麼來？
這些問題的出現，就極大地阻礙了學術界的成果向工業界轉化，有時候基本意味著轉化不了。
我們推出這套平臺，就是希望把神州泰嶽在產業裡積累的工程化經驗，釋放給學術界的老師們，讓老師們依託這個平臺更好得把演算法的應用到實際需求中，向產業化轉化。
自然語言處理的未來：語義終極特徵
機器之心：神州泰嶽在自然語言處理領域的研究有什麼未來的計劃？
晉耀紅：首先還是需要深入細化本體論設計，不同的場景下對本體的要求是不斷變化的。本體業務建模這塊還有很大的發展空間。
另外自然語言的能力包括理解和生成，後續可能考慮增加語言生成的能力。如公文寫作能力。語言理解和生成是硬幣的兩面，目前平臺主要著重於分析的能力。先分析公文寫作，句子、段落之間怎麼連線的，在這個基礎上分析文章框架，學習每一個詞、字的應用。
公文寫作複雜，是未來研究的一個方向。其中有很多困難，目前像市面上一些寫詩的應用屬於比較娛樂化的，但是公文寫作每一個字、每一句話都不能錯，不能有歧義。
我們希望做一個效果可控的公文自動生成應用。公文寫作有很多困難，有很多潛規則、隱知識，但因為是嚴格的八股文，也有優勢。根據我們的調研，一般寫公文都是先去研究原來的公文是怎麼寫的，然後在以前的公文基礎上進行修改。這個過程跟機器學習其實有相通之處。我們對於產品的設想是希望能讓公文寫作人員輸入感情色彩、表達方式、緊迫性等元素，讓機器自動生成文章。
作為公文寫作研究的中間結果，我們也做了一個自動寫詩的應用。但是這個跟別的寫詩應用的差別在於可以每一句話讓使用者輸入一個詞來表達整句詩的意境，比如鄉愁。
機器之心：深度學習演算法目前在自然語言處理還沒有實現大的突破，對於這一點神州泰嶽有什麼思考？
晉耀紅：我們認為原因是語言的特徵更抽象一些，不像影像 RGB 三種元素就是它的終極特徵，語言沒有終極的特徵。
我們在中科院做的 HNC 概念層次網路的工作其實就是希望找到語言的終極特徵。這裡面有很多有意義的工作，但目前價值還沒有完全發揮出來，可能還很少有人能認識到語言終極特徵的重要性。
目前各種演算法比賽，我們做企業的也要從客觀角度去看待，可能有時候是在封閉的集合去刷分，發現了問題針對性的改一下就能提高。但其實很多情況下也許不能體現實際應用過程的水平。
當然，比賽也許能一定程度促進演算法的發展，對學術研究有用。但國內一些公司透過比賽來提高知名度，如果這個過程不能提升演算法在實際工作中的效果，在資源上可能造成了一定的浪費。
現在的學術界更多的是在刷榜，做一個演算法去刷分。國內的學術研究，很多時候就像一個老前輩說的，就是在做習題，別人在英語裡做了一個，咱們把它拿過來漢語裡做了一個，就是創新。但是其實很少有去研究這背後終極的問題，或者說去研究一個新的演算法。這種創新性的工作還是很少。
張瑞飛：在研究方向的話，我們希望恢復機器學習的本來面目。
邢波教授前一段時間說，在做人工智慧模型演算法梯隊裡存在一個知識退化的趨勢，因為人們開始把深度學習來代替整個機器學習。神經網路是機器學習本來的分支，但還有其他的分支。
我們在工程實踐的時候，在做標註的時候，不在乎是否一定要用深度學習。
工程化的任務應該是去評估業務目標如何分解，需要把整個演算法能力框架搭建起來，然後找最有效、最捷徑的演算法。
也許對深度學習一個小的改變就是一篇論文了，但我們覺得這個沒有太大的意義。我們企業做人工智慧考慮的是成本，追求的是成本和成效的平衡。