剛好做過一個類似的產品，雖然沒有那麼高大上，但一些核心技術原理應該也參考意義，說一下做的思路。類似小冰這樣的產品說簡單也簡單，說複雜也複雜。單純從外面看你會覺得小冰與去年人人網上流行的小黃雞類似，但在技術實現上有本質的差異。 此類應用的大致流程都是：使用者輸入一段話（不一定只是單詞）->後端語義引擎對使用者輸入的語句進行語義解析->推斷使用者最可能的意圖->呼叫對應的知識庫、應用、計算引擎->返回結果給使用者。

1、最初級的實現方法：關鍵詞匹配 建一個關鍵詞詞庫，對使用者輸入的語句進行關鍵詞匹配，然後呼叫對應的知識庫。 此種方式入門門檻很低，基本上是個程式設計師都能實現，例如現在微信公眾平臺的智慧回覆、諸多網站的敏感詞過濾就是此類。 但此種方式存在諸多問題，例如： a、由於是關鍵詞匹配，如果使用者輸入的語句中出現多個關鍵詞，此時由於涉及關鍵詞權重（與知識庫的關鍵詞對比）等等問題，此時關鍵詞匹配的方法就不擅長了 b、不存在對使用者輸入語句語義的理解，導致會出現答非所問的現象。當然在產品上對回答不上的問題就採用賣萌的方式來規避掉。 c、基本上無自學習能力，規則只能完全由人工維護，且規則基本是固定死的。 d、效能、擴充套件性較差。還是上面的一句話中包含多個關鍵詞的例子，採用普通程式語言來做關鍵詞匹配，效能奇差。即便採用一些文字處理的演算法來做（例如Double-array trie tree），也很難滿足大規模場景需求。

2、稍微高階點的實現方法：基於搜尋引擎、文字挖掘、自然語言處理（NLP）等技術來實現 相對於1的關鍵詞匹配，此種實現方法要解決的核心的問題可以大致理解為：根據一段短文字（例如使用者問的一句話）的語義，推測出使用者最可能的意圖，然後從海量知識庫內容中找出相似度最高的結果。 具體技術實現就不細說了。舉一個很粗糙的例子來簡單說一下此種實現方法處理的思路（不嚴謹，只是為了說明思路）。 假如使用者問：北京後天的溫度是多少度？ 如果採用純搜尋引擎的思路（基於文字挖掘、NLP的思路不盡相同，但可參考此思路），此時實際流程上分成幾步處理： 1、對輸入語句分詞，得到北京、後天、溫度3個關鍵詞。分詞時候利用了預先建好的行業詞庫，“北京”符合預先建好的城市庫、“後天”符合日期庫、“溫度”符合氣象庫 2、將上述分詞結果與規則庫按照一定演算法做匹配，得出匹配度最高的規則。假定在規則庫中有一條天氣的規則：城市庫+日期庫+氣象庫，從而大致可以推測使用者可能想問某個地方某天的天氣。 3、對語義做具體解析，知道城市是北京，日期是後天，要獲取的知識是天氣預報 4、呼叫第三方的天氣介面，例如中國天氣網-專業天氣預報、氣象服務門戶 的資料 5、將結果返回給使用者

以上例子其實很粗糙，實際上還有諸多問題沒提到：語義上下文、語義規則的優先順序等等。 例如使用者上一句問：北京後天的溫度是多少度？下一句問：後天的空氣質量呢？這裡實際上還涉及語義上下文、使用者歷史喜好資料等等諸多問題。

此種處理方法存在的最大問題：規則庫還主要依賴於人工的建立，雖然有一定的學習能力，但自我學習能力還是較弱。可以藉助一些訓練演算法來完善規則，但效果並不是很好。而這也是目前流行的深度挖掘技術所擅長的。

3、當下時髦且高階的玩法：基於深度挖掘、大資料技術來實現 這是cornata、google now等後端的支撐技術，至於小冰，感覺應該是以2為主+部分領域知識的深度挖掘。