一段聲音的旅程（四）有多少人工就有多少智能

經常聽到「有多少人工就有多少智能」來形容「AI」，前文我們在聊語音時，也說到了數據標註，就是拼人力的地方之一，還有什麼地方也在拼人力呢？為什麼會如此呢？本文我們來好好聊一聊「人工」的智能。

先聊一個話題，見客戶的時候經常會聊到，個人認為這是個有趣的話題，可以幫助我們建立對於AI的基礎認知；

逆概問題

這個話題是黑白球問題，問題是這樣的，有一個箱子裡面裝了無數個球，包含黑球和白球，我們不知道裡面有多少個球，也不知道有多少個黑球，有多少個白球（當然，現實中，除了黑球、白球之外，還有可能會出現沒見過的球，我們稱這些超出預期的球為「黑天鵝」），請預測，下一次取出的球是黑色的概率是多少？？？

當然，概率問題不是我們要聊的，我們主要聊的是這裡面的邏輯推理過程。

1、因為不知道箱子里有多少黑白球，最初的概率基本就是靠拍腦袋瞎蒙，這個肯定不靠譜，沒有意義；

2、先依次取出十個球，看取出來的球的顏色，假設，黑色5個白色5個，心裡應該大概對箱子里有個初步猜測，可能是黑白各半，下次取出的球有50%是黑色；

3、繼續取球，取到一百個球，黑球到70個，白球到30個，這時應該修正一下結論了，下個球是黑球大概在70%左右；

4、繼續取球，取到九百九十九個球，取第一千個時，發現首次取出來一個紅球（遇見「黑天鵝」了），這一下子，對於下一個球的判斷就發生質的變化，因為存在一個可能是紅球，當前黑球概率不論是多少，都可能是錯的，因為還不清楚紅球的概率會是多大；

5、繼續取球，取到一萬個球，黑球4000個，白球1000個，紅球5000個，一下子概率就變成4:1:5了，黑球概率變為40%左右；

6、以此類推...

（當然，這個話題里的例子，紅球有些太誇張，佔五成比例，卻前一千個一個都沒取到，沒事，大家需要意會這個思維過程）

這是什麼概念呢，怎麼好像和我們AI沒啥關係，其實關係很大，上文中舉過一個例子，「李洋泊」、「李昂博」、「梁博」，和前面的話題對應起來就是這樣子，最開始，你有個同事叫「李洋泊」，當你和同事們一起聊天時，說到這個人名，語速快一些或慢一些，清楚一些或者模糊一些，你都能夠快速知道是「李洋泊」，這就是只有「黑球」的時候，這個時候，好聲音的節目熱播，你知道了「梁博」這個人，同事們一起聊天，如果語速稍微快一些，聽覺上就會開始迷糊了，說的到底是誰？觀察一段時間，發現一個是同事，一個是明星，同事聊天，說同事的概率還是要高於明星的（八卦女同事除外哈，不要在意這些細節），這時其實就相當於會有一個概率，70%說的可能是「李洋泊」，30%說的可能是「梁博」，反正就是這兩個其中一個嘛，這其實就開始了黑白球概率問題。

又過了些日子，又來了一個同事，他叫「李昂博」，忽然發現，之前的「反正就是這兩個其中一個嘛」忽然不成立了，今天同事們聊天，也可能說的是「李昂博」，這就是忽然發現了「黑天鵝」，此時，我們就要重新再去思考了，之前說的7:3已經不成立了，那麼怎麼才能知道這個「黑天鵝」的比例呢？得再觀察一段時間，最後得出一個新的概率，40%可能是「李洋泊」，50%可能是「李昂博」，10%可能是「梁博」，以此類推…

這話題是經典的「逆概」問題；和我們目前「AI」所探討的問題很像，都是要基於「已發生的過去」來「預測未來」，當然，這也是「大數據」經常聊到的話題，數據越真實越豐富，則對現狀的還原、對趨勢的把控、對未來的預測等等，就會越準確，特別注意，這裡都是概率性質的用詞，「越」準確，而不是「一定」準確，AI的最大特點就是不確定性。

我們先從前面的話題里梳理幾個結論：

1、沒有過去就沒有未來；

2、過去的數據越豐富越全面，對未來預測則越準確；球取的越多，球的預測比例會越接近真實比例關係；「豐富」特指量級，「全面」特指維度；

3、「黑天鵝」的出現，現有「智能」是無法區分的，經過一定時間的觀察，如果「黑天鵝」達到無法被忽略且必須解決的地步，原則上都需要重新訓練所有相關模型建立新的「智能」；（這也是「AI」需要不斷迭代的原因，同時，可以順勢推導出，「AI」雲服務化的必要性）；

在早些年做語音時，我主張「軟硬體一體化」，及之後的「雲端芯一體化」，其理論基礎就是這幾篇文章中的知識，前面兩章一直在強調語音的「音」部分如何難，「芯」所承載的是降低「音」也就是audio輸入的門檻成本，主推「即插即用」的理念；「端」所承載的是降低語音能力「被集成」的門檻成本，幾行代碼即可引入語音能力；「雲」除了是本文說的能力迭代，同時也承載了降低語音能力「被定製」的門檻成本，在線可視化定製並實時體驗；三者，大開大合，相輔相成～

俗話說，無規矩不成方圓，即，有規矩易得方圓，一個理。其實第二點結論也能有類似的推導，第二點裡描述，越「全面」越「準確」，那麼，約束前提條件越多（即：已知維度越多），是不是就越容易「全面」，是不是就越容易「準確」了呢？很熟悉是嗎？沒錯，就是現在主流的語音「垂直化」或「場景化」的理念。（特別注意：「容易」是相對的，不要誤以為在垂直場景里，語音就可以被輕視哦！）

如果對垂直場景還比較迷糊，這裡拿前面的人名舉例子。塑造一個場景，部門開會討論工作，此時，「梁博」被說到的概率趨近於零，這時你聽到類似的音的詞就可以排除「梁博」的干擾，從「李洋泊」、「李昂博」選一個最相似的，這其實就在提高準確率；同樣，再假設你和「李洋泊」一個部門，部門裡面人都不太認識另一個部門的「李昂博」，此時，同樣是部門開會討論工作，此時聽到相似音的詞，幾乎可以直接認定為「李洋泊」，是不是準確率進一步提高了？這就是垂直化場景化的好處，注意，我們在舉的例子都比較極端，真實生活里是極其複雜的，也許部門開會聊岔了聊到好聲音的「梁博」也是有可能的，我們隨時都要保持一顆一切皆有可能的「概率」的心～

我們開始在逆概理論上再延展，黑白球主要表達的是一種逆概的邏輯，其核心承載是「球」，區分的是「顏色」；同理，如果承載是「聲音」，區分的是「內容」，這就是一直在聊的語音識別，若區分的是「人」，就是聲紋識別；如果承載是「圖像」，區分的是「物」，就是圖像識別中的萬物識別，若區分的是「人」，就是人臉識別；承載是「文字」，區分是「義」，就成了自然語義理解... 當然，我們還可以發散想像一下，如果它所承載區分的是「行為」和「因果」，又會是怎樣的呢？好像很厲害的樣子，是不是「我們可以根據已經發生過的『因』，來預測未來可能的『果』」了呢？？？注意，前面這句話其實偷換概念了，正確的描述應該是：「我們可以根據已經發生過的『因果』關係，來預測當前的『因』，將來可能發生的『果』，或者，將來想要什麼『果』，則當前需要種下什麼『因』」，仔細比對兩種描述的區別，對「AI」現狀的認知會更加清晰一些。

對於「AI」未來的展望，影視作品、網文軟文等等到處都是，展望未來並不是我寫這些文章的初衷，這裡就不展開了。

以上主要聊的是：「預測逆概」的「不確定性」。如果你和語音供應商談過合作，會發現，語音企業在描述自己語音能力的時候，都會說，「我們的語音識別能達到95%，甚至在有些場景下可以到99%，當然，這是一般情況下，如果現場環境太嘈雜或者其他特殊情況下，干擾多了，表現會略差一些，但是整體效果是可以基本保障的」，這個95%和99%，就是一個「預測逆概」，是在他用於模擬「未來」的測試集合中，能夠達到這個值，畢竟模擬並非真實，中間還是會存在一些可能的變數，而且不知道這個變數有多大，這就是一種「不確定性」，越接近其模擬的場景，這個「不確定性」風險會相對越小，當你有一個非常垂直的行業，語音企業需要為你「定製」語音，就是讓他模擬的場景無限接近你的真實場景，為你降低這個「不確定性」帶來的風險，所以，如果再聽到供應商說需要定製，就不要罵他們技術爛了，理解一下他們的難處，他們也是想把事情做好的。

「預測」的逆概問題，是我們日常「經驗總結」的一種邏輯表現，對於今天我們所探討的語音語義這些AI能力，主要是基於計算機來完成的，我們在逆概問題基礎上進行延展，再討論一個關於「辨識」的逆概問題。

辨識問題

「AI」的承載是計算機，計算機的優勢在於存儲數據和計算數據，所以，「AI＋」這個理念，如果想要復用到任何一個細分領域，都需要先考慮這三個關鍵問題：

1、如何化為數據？

－ 1）「過去」能更好的「存儲」起來；「未來」能被「表現」出來；

－ 2）數據是需要能夠被「計算比較」且「沒有歧義」的；

2、如何計算比較？

－ 1）現在式的「過去」是由無數多個過去式的「未來」所組成，相互之間反覆「計算」，找到「差異的規律」，這就是所謂的「訓練」；

－ 2）在經歷「未來」時，和訓練好的數據再進行「計算」，根據「差異規律」來判定，這個「未來」是否符合「預期」；

3、如何判斷預期？

－ 1）若要判斷是否「符合預期」，自然是先要有預期；

－ 2）對比計算中的「規律」是否「符合預期」，最終是需要人來判斷的；

感覺很玄乎對吧，那我們借用黑白球問題來舉例吧，之前黑白球，是不考慮「辨識」這個維度的，所以球的顏色很簡單，黑白紅，但真實世界中，球的顏色可不是那麼絕對的黑白紅，這裡我們就在黑白球話的基礎上，增加一個維度，「顏色辨識」（注意，為了不搞得太複雜，這裡假設一個球的整個球面的顏色都是一樣的）。

我們有三件準備工作要做：

1、一個預期，這個預期就是目標箱子里的球有「黑」和「白」兩種（同理，放到ASR里，這個預期就是「要識別出來的文字」，放到NLU里，這個預期就是「要表達的意思」），沒錯，這個很重要，要先有「預期」，經常會被忽略掉；

2、一個可以被「計算比較」的「沒有歧義」的「數據」表示方式，來表示顏色，很巧，今天我們的計算機有好幾種數據都可以用來標記顏色，我們這就用RGB值吧（這裡就不介紹什麼是RGB了，一般產品同學和設計同學都懂這個）；

3、一個初始的設定，也是這個「規律」的雛形，即，人如何區分什麼顏色是「黑」？什麼顏色是「白」？這個計算機可無法定義，需要人先來定義，這個就是最初的「規律」，注意，「人來辨識」是這裡的重點；好吧，其實準備工作時，還沒有任何數據嘛，就隨便拍個腦袋：RGB值＝#000000，是黑色；RGB值＝#FFFFFF，是白色，當前實際意義不太大，但是如果你使用的是別人已經用其他數據訓練好的模型就會有意義了（比如，使用別人已經訓練過的語音識別來用，就是一個有意義的初始規律），這裡我們就按最簡單的來繼續吧；

我們開始取出一個球，這個球就是當前所謂的「未來」，我們先對其轉化為數據，也就是先採集它的RGB值，#030303，按照之前設定的規律進行辨識，這個即不是前面定義的「#000000」，也不是「#FFFFFF」，所以是不符合我們設定的規律的，當前這個球就屬於bad case，只能由「人來辨識」，這人一看，辨識為「黑色」，就這樣，一個新的數據產生了，「RGB值＝#030303，是黑色」；我們此時可以修改這個「規律」，如：RGB值＝#000000或者#030303，是黑色；RGB值＝#FFFFFF，是白色。

我們通常把「取球」並採集它的RGB值的過程，稱之為「數據採集」；把這種「人來辨識」所產生數據的過程，稱之為「數據標註」；把「按照之前設定的規律進行辨識」的行為，稱之為「模型匹配」；把「修改規律」的過程，稱之為「模型訓練」，把用於修改規律的數據的集合，稱之為「訓練集」。

再取出一個球，RGB值，#0d0d0d，辨識一下，我去，又是bad case，這人一看，還是「黑色」，規律中追加一個RGB值＝#000000或#030303或#0d0d0d，都是黑色；

依次取球，取到第十個，規律變成了：RGB值＝#000000或#030303或#0d0d0d或#010101或#111111，都是黑色；RGB值＝#ffffff或#f0f0f0或#eeeeee或#f7f7f7或#f5f5f5，都是白色。

每次都是bad case，每次都要修改規律，這樣不對吖，一個個做下去，工程量太大了，要優化優化思路了；一方面，沒必要經歷一個數據就重新定義一遍規律，可以積累一部分數據，統一根據數據趨勢，定義一種更自由的規律（預測概率的結論，積累數據越多，規律越接近真實），另一方面，需要對規律有一種評價的方式，否則規律的自由到可能會無法控制。

於是，我們把規律修改為，RGB值小於或者等於#111111，都是黑色；RGB值大於或者等於#eeeeee，都是白色；這個規律對於當前已有的10條數據，均適用，所以初步判斷這個規律是正確的。

這裡要注意，因為初始預期里是「黑」和「白」，所以其實在這個時候，所有人都以為，箱子里只有白和黑兩種顏色，在這個前提下，這個規律就成為了正確的規律；同理，在語音里，就算一個模型能做到99%，它也有很大的可能識別不了你的名字，比如「李昂博」，因為在這個模型認為的「正確的規律」中，根本就不存在這個名字，要麼被命中一個相似的文字，要麼成為bad case識別不出來。

我們發現，積累十個數據所總結的規律，辨識準確率很低（數據量太小），於是，我們先取出100個球，標註好，其中有70個標註為黑球，30個標註為白球，再次優化出新的規律：「RGB值小於或者等於#9f9f9f，都是黑色；RGB值大於或者等於#dddddd，都是白色，#9f9f9f和#dddddd之間的顏色，則通過『相似』判斷，越接近#9f9f9f是黑色，越接近#dddddd的則是白色」。

為了驗證這個新規律的準確率，再取100個球，一方面人工標註好作為標準答案，另一方面用這個新規律來辨識，兩者結果進行對比，就能夠得到準確率，用來評價這個新規律的優劣；我們把這個用於驗證的體系，叫做「評價系統」，將這個準確率的定義標準，叫做「評價標準」，將這100個用於驗證的球，叫做「驗證集」。根據這個描述，我們可以發現，評價系統其實也是基於一個驗證集合來做評價的，所以，驗證集的選取方式，將會直接影響評價結果，如果驗證集就是按照當前規律來選取的，這個結果很可能會達到100%，極其漂亮，同理，如果驗證集就是特地違背當前規律來選取的，這個結果可能會差到0%，極其難堪，所以，這個數值只能作為參考。

聊到上面這個極好極壞都可能的準確率，我們該怎麼處理呢？

這裡有一個簡單可行的方法，就是「隔離準備」，做訓練集和做驗證集的人完全分開，相互隔離，在「同一個預期」的條件下，獨立準備數據集合，這樣得到的數值會相對客觀一些。

繼續取球，我們取到了一個球，顏色是「#ad2d2d」，相似偏黑色，按這個規律則辨識為了「黑色」。

繼續取球，取到第1000個球時，顏色「#ff0000」，按這個規律辨識為「白色」，而這個時候，有人一看，不對啊，這個明明是紅色，既不是白色也不是黑色，之前的「預期」不對吖。此時，忽然發現「黑天鵝」，之前的初始預期嚴重遺漏了這個關鍵可能，其實裡面不僅有黑球和白球，還有紅球，所以之前的準確率，可能存在很大偏差，而且因為「預期」的嚴重遺漏，之前可能有些球在人工標註的時候，「即像黑色又像紅色」的數據會直接被標註為「黑色」，就像前面那個「#ad2d2d」，在「預期只有黑白」時標註成「黑色」是正確的，但是，在「預期有黑白紅」時就應該標註成「紅色」了，類似這些數據都需要重新人工再標註一遍，當然，這之後的模型訓練等工作也都需要重新再做一遍；黑天鵝的闖入，讓我們需要把過去的部分數據重新review，重新進行標註，模型重新訓練，重新尋找規律，重新測試驗證，甚至需要準備更多更多的新樣本數據，來儘可能保障當前訓練的數據更能夠趨近於未來的真實概率。

這就是「辨識」的問題。我們總結幾個關鍵點：

1、辨識的關鍵還是需要人來辨識，所以，數據標註是一件非常非常重要的事，其標註的數據質量，直接關係到模型的優劣；

2、訓練模型所用的標註好的數據，越豐富越全面，則模型的準確率會越高，當然，所帶來的標註成本就會越大，人工投入也會隨之變大；

3、初始的預期極其關鍵，也就是，「你想要什麼」，是至關重要的，AI本質上無法創造預期，只能基於已知預期和已知過去，去預測未來發生的概率；

這才只是考慮顏色，如果再加上球的大小、重量、材質、形狀....等等，綜合到一起考慮，每增加一個維度，複雜度都成指數增長，這會是一個多麼複雜多麼龐大的體系呢？而這一切，「機器」都無法獨立辨識，都是需要「人」。

鋪墊的廢話太多，辛苦各位看客，這個基本的認知還是蠻重要的，一方面，能夠幫助我們後續的溝通、學習、成長中，事半功倍；另一方面，在面對大部分客戶時，可以通過這兩個話題，來生動地描述「有多少人工就有多少智能」這個核心瓶頸，同時也能夠幫助客戶從科幻世界中拉回到現實中來，腳踏實地，攜手打造AI的精品。

說法與含義

我們拉回到語音的產品中來，語音產品里的「智能」擔當，是自然語義理解，即NLU，其核心任務，是理解文字中的具體含義。在今天的行業里，語義是所有能力中最難做好的，雖然垂直場景化會比較好一點，但使用者的認知閱歷、性格情緒、思維方式、理解能力等等的不同，說話的方式會有很大區別，語義結果也會有很大的區別；而同一句話，在不同的語調語境、心境環境、陰陽頓挫等等的情況下，說的內容也會有不同的語義結果，所以定製化的難度還是非常大的。根據前面總結的關鍵點，語義是「文字」和「含義」的對應關係，「預期」就是「用戶可能會說的話及其對應可能表達的含義」，為了讓「初始的預期」更接近用戶真實可能會說的話，我們需要儘可能去收集可能的語言說法和文字內容，通過人工對這些素材進行「含義」的標註，從而形成訓練集去訓練模型，使用中，需要不斷積累文字素材，不斷積累訓練集，不斷迭代模型，從而提升語義的能力。

對於語義中「預期」的補充：可能很多產品同學，認為語義的「預期」是語義的最終「義」的範圍，比如，需要語義支持「查詢某地某時的天氣」、「導航去某個地點」、「播放某個名字的歌曲」等等，這裡需要解釋一下，如果你定義自己為語音產品中的具體「場景」或「技能」的產品經理（注意：有些地方叫「場景」，有些地方叫「技能」，顆粒度多少會有些不同，但為了方便，這裡就統一都叫「場景」了），這個認知是沒問題的，顆粒度到前面例子也確實足已；如果你定義自己為「語義產品」的產品經理，那麼這個認知就略有偏差了，語義的關鍵是「文字」和「含義」的對應關係，所以，語義的「預期」應該是，「『今天天氣怎麼樣』、『幫我查一下明天上海天氣』等等各種說法對應『查詢某地某時的天氣』這個含義」 、「『導航到徐家匯』、『徐家匯怎麼走』等等說法對應『導航去某個地點』這個含義」等等，「說法」和「含義」都是語義的非常重要的輸入，依照我們前面描述的「沒有過去就沒有未來」，如果語義預先無法知道有這麼一個說法，那語義是無法理解其正確含義的，同樣的，如果語義預先無法知道有這麼一種含義需要被辨識出來，那語義也是無法辨識出這個含義的。

「場景」的產品經理和「語義」的產品經理是屬於相互協作關係，但是在真實的工作中，分工的邊界其實並不特別嚴格，會存在很多摩擦。大家的核心矛盾是在「說法-含義的人工標註」的投入上。一般有兩種情況下會出現這個分歧，一種情況，是做一個新場景時；一種情況，是給語義的效果做測試驗收時。我們拿一個比較偏門的需求來舉例，車行業中的「查詢胎壓」這個需求，場景的同學的提出「查詢胎壓」的語義需求，語義的同學要做這個需求，需要足夠充分的「說法」的準備，然後交給研發同學進行語義的模型訓練。這裡的足夠充分的「說法」，誰來準備呢？語義的同學會說：「這個是你業務方設計的需求，用戶會怎麼說，要怎麼說，只有你們知道，我們又不懂這個業務」；場景的同學會說：「我們提出了需求，語義的同學應該專註在語義的說法和泛化上，人會怎麼表達，怎麼說話，怎麼來問出這個需求，這個是語義的範疇，我們也不懂」；這個中間環節，就變成了灰色地帶，任何一邊的同學往前走一步，都會好一些，但如果任何一邊的同學都往後退一步，「說法」的豐富性，就非常難做好，如果「說法」不豐富，會是什麼樣的結果呢，用戶在用語音的時候，說「查看胎壓」就可以，說「現在胎壓多少」就不行了，然後你就會看到「這個語音做的真垃圾，一點都不智能」的評論，是不是似曾相識？同理，在兩邊相互交付的時候，一樣存在這個問題，要測試，要測試集合吧，誰來做這個測試集合呢？

如果你在工作中遇到上面的問題，請冷靜客觀地反思一下，或許往前走出一小步，彼此多溝通，就完全不一樣了。

這裡也介紹一下一般語音或語義公司（註：這個地方對應上面的語義的同學）的做法供大家參考：一方面，新場景、後續升級迭代、能力測試等的數據準備都在語音語義公司完成，會讓客戶（註：這裡對應場景的同學）提需求同時，舉幾個例子，作為藍本；然後會安排公司內部同學或外包進行大量數據泛化、標註、質檢等等；另一方面，在工程上會建立快速迭代的機制和流程，交付給客戶之後，如果中間出現了說法不支持的問題時，可以第一時間快速響應，迭代修復；這也是AI企業to b業務的一般做法，當然也不是所有的公司都如此，有些企業還是會把這份風險直接推給客戶去承擔的。

語義理解

一般在這個時候，就該講，詞向量和語言模型了。前面我們通過辨識的問題，引出過一個基礎要求，即：「一個可以被「計算比較」的「沒有歧義」的「數據」表示方式」，在前面的話題里是「RGB」，在語義里，就是這個「向量」，知道它所存在的意義即可，反覆去討論詞向量的各種學習訓練，對於技術實現的宏觀理解有一定意義，但對於我們產品和設計同學來說，認知上沒有太大的提升，所以，這裡換個思路，我們按照學習語言的過程，從「詞」到「句」再到「文」來講述NLU中的幾個關鍵環節。

詞->分詞->詞性和領域術語

在中文的NLU中，首先要根據「詞」來進行拆分，這個過程就是「分詞」。在英語里，單詞與單詞之間是空格分離的，所以英文在分詞上沒有太多的歧義，而中文裡，就可能會千差萬別。比如：「南京市長江大橋」，如果按照「南京市，長江大橋」來分詞，指的就是「橋」，如果按照「南京市長，江大橋」來分詞，指的就是「人」；再如：「鳩山由紀夫宣布辭去日本首相職務」，如果這麼分「鳩山，由，紀夫，宣布辭去日本首相職務」，「鳩山」和「紀夫」這兩人都是誰啊，如果按「鳩山由紀夫，宣布辭去日本首相職務」來分詞，看，明明是「鳩山由紀夫」一個人的事嘛。

其實很多影視作品裡也有類似的橋段，加幾個逗號斷句，意思完全相反，通過這些例子，我們需要了解到的是，分詞對於理解的重要性。回看前面的兩個例子，如果需要規避這種錯誤，我們要注意什麼呢？ 其一，是「概率」，「南京市長江大橋」按「南京市，長江大橋」分詞是高概率的，而按「南京市長，江大橋」來分詞，概率很低；其二，是「生詞」，如果我們先知道「鳩山由紀夫」就是日本首相，那麼就不會出現「鳩山，由，紀夫，宣布辭去日本首相職務」的分詞方式了。當然，不可能這麼簡單，如果南京市真的有一位叫「江大橋」的市長呢？

由此，對應上面兩個點我們引出兩個詞，一個叫「詞典」，一個叫「統計」。詞典是用來記錄「詞」的，也就是告訴NLU，這是一個詞，不能分開，這是個非常重要的參考維度；統計是根據規律來計算「概率」的過程，比如「詞頻」，當同一句話，有多種不同的分詞方法時，詞頻就是一個非常好的參考維度，幫助NLU更精確的進行分詞。

結合這兩點，我再引入幾個詞，「監督學習」、「無監督學習」和「半監督學習」，更具體更精準的定義可以網上搜一下，我簡單來描述，大家意會即可，所謂「監督」，就是「人」的介入，「監督學習」就是人工參與或干預的學習過程，反之，不需要人工參與或干預的學習過程，就是「無監督學習」，而兩者相結合，就是「半監督學習」。在前面我們有結論：「AI」需要大量「標註」好的數據進行訓練，比如當前說的「分詞」，分詞想越準確，那麼我們所定義的詞典就需要覆蓋儘可能多的詞，機器無法知道哪幾個字怎麼組合才是個詞，所以，這需要大量的人力投入到標註，這對應的就是「監督學習」，這樣的人力投入成本實在太大，有沒有什麼辦法能夠讓機器代替人來標註，或者儘可能減少人力投入來標註呢？

我們從網上抓取了大量的數據，如果人來區分，幾個字是不是一個詞，會怎麼做呢？要麼認識，要麼在哪裡見過，要麼網上搜一下看看哪裡出現過沒有，這三種做法有一個共性，對，都是「出現過」，這就有規律可尋了，讓計算機對這些數據進行反覆分析，看哪些是反覆出現的，詞頻越高，是詞的概率就越高，這樣就做到了「無監督學習」咯～（注意，通過「無監督學習」來學習「詞」，「詞頻」只是其中一個維度，還會有「詞性」等等維度，就這一個點，也是非常複雜的；同時也提醒大家，分詞也是「搜索」產品必備能力之一哦）

中文裡有很多很多詞有著固定的規律和定義，比如同音詞和同義詞，同音詞是音同字不同，當然義也不同，比如「報復」和「抱負」，「樹木」和「數目」；同義詞是義同詞不同，比如「我」、「俺」、「本人」、「在下」、「老子」、「小人」… 都是第一人稱「我」的義。前者，對於語音識別來說，是一個很大的負擔，為了減輕ASR的負擔，我們一般會讓ASR不僅將文字輸出，也同步將拼音輸出，交給NLU來統一處理，NLU可以根據具體「句」和「文」的特性，來將詞進行糾正；後者，對於語義理解來說，是需要大量積累的，這是語義「泛化」的基礎之一，也是語義「智能」表現的一部分，而這個的積累，又是需要大量的人的投入的，不過這個稍微好點，畢竟還有「同義詞典」這種東西，事半功倍對吧。提個問題，產品和設計的同學，當你面對一個語音產品的時候，是不是苦惱過，用什麼方式去使用它才能判斷它是「聰明」還是「傻蛋」呢？ 看完此文，會不會有一些靈感了呢？記得告訴我是怎麼耍這些「AI」產品的吧～

記得小學學語文時，還有一個點，老師教了挺多，說會更利於閱讀理解，這個就是「詞性」，中文詞性分為「實詞」和「虛詞」，實詞包含：名詞、動詞、形容詞、區別詞、代詞、數詞、量詞；虛詞包含：副詞、介詞、連詞、助詞、語氣詞、擬聲詞、嘆詞。這些詞我就不介紹了，都學過，引入這個的關鍵是，實詞是「義」的核心，虛詞則相對，不承擔「義」的核心，但是虛詞更多會帶來一些「情緒」、「程度」、「語氣」等等方面的補充，從而間接影響「義」，所以這個也是非常重要的點。對於NLU來說，實詞是最為關鍵的部分，用於正確理解用戶話中的意圖和主體，虛詞則是「泛化」的基礎之一，同時也是「情感識別」的關鍵之一。

在「詞」這個維度，語言通用的部分暫告一段落，我們來說說，非通用的業務相關部分。場景化AI是今天的大趨勢，車、電視、音箱、機器人、IoT等等，這些垂直場景里，對於「詞」的訴求，有特性也有共性，特性的詞，需要產品的同學，根據自身業務，細化積累，比如：專業術語及術語別名等等；共性的詞，比如：不論是手機、車、音箱等行業，如果用了導航領域，就都需要poi的詞表，而且都是一樣的，天氣也一樣，每個行業用的天氣領域，城市的詞表都是一樣的，這些也是需要產品同學有方向有目標地去深入挖掘和積累。

對於詞，最後需要講的一點是「新詞熱詞」，對於每個場景的辭彙，目標都是全集，但是一方面，「全」是一個偽命題，趨近於但不可能「全」，每天都在產生新的詞，新詞被吸收到NLU中來是能力成長的關鍵；另一方面，「新」反而很多用戶不一定知道，所以可能說到的概率反而會低，「熱」就是一個NLU消除詞的歧義的關鍵；這兩點，對應到最開始的逆概問題中，就是「黑天鵝」問題。

句->語法->句式與修辭手法

說到句子，首先想到的就是「主謂賓定狀補」，它們是句子的組成部分，它們有一些有效組合的方式，稱之為「句式」，增加一些藝術手法，又引出了「修辭」，學校都教過的東西，這裡就不反覆說了，這些都是用來幫助語義提升能力的非常好的維度。

諸如句式與修辭等等，這些在語言中對於字詞的組合規則，在AI里，我們稱之為「語法」；「寫語法」指的就是人工書寫這些規則，這裡對應前面所提到的「說法」。一般產品在沒有落地前，我們是根據「場景」產品經理提的「需求」，先定義出「含義」，然後安排大量人力，按他們自己的表達方式，來寫語法規則，通過「人工」來儘可能覆蓋人對於同一個「含義」可能表達出的所有「說法」，遵循前面逆概的思維邏輯，投入的人力越多，覆蓋的「說法」越全，用戶使用時，能夠正確理解用戶的話的概率越高，也就越「智能」；如果產品已經落地了，可以通過數據統計，匯總用戶說的話，安排大量人力，對其逐一進行「人工標註」，將標註好的數據，放回到NLU中重新訓練，周而復始，NLU的能力就會逐步逐步地提升。

這裡闡述一個我的個人觀點：智能的「九成法則」。其大致描述是，「當一個人90%能夠想到的話，它都能夠理解，那麼，這個人就會認為它很智能；當一個群體中，90%的人都認為它智能，那麼，這個群體都會認為它很智能」，90%在這個法則中是一個泛值。九成法則的核心理念在於「智能的觸達並非是演算法和技術，是其展現的認知的覆蓋率」，所以，只要能達到這個「認知」的覆蓋率，用「規則」也好，用「模型」也罷，用「正則表達式」也好，用「DNNCNNRNN」也罷，用「監督學習」也好，用「非監督學習」也罷，都是觸達AI的一種方式和方法而已；一方面，不要過度放大新演算法新技術所帶來的所謂「AI」，腳踏實地做好每個細節，那些需要人來處理的繁雜瑣碎的臟活累活，不論多牛逼的演算法，多神奇的模型，都是必然需要做的，「等」不如「做」，該人力投入的地方還是需要投入的；另一方面，也不要過分貶低新演算法新技術所帶來的進步，雖然它無法做到完全不需要人來參與，但是相比上個人工智慧的資本風口階段，已經讓人力投入降低了很多，效果提升了很多；正確看待技術，客觀審視演算法，才能用好它們，將它們的潛能激發出來，價值最大化。

在當前語音產品的場景里，對於句子的要求，主要有兩大類別，「命令」和「文本」；「命令」對應在大部分的消費品類中，如手機、音箱、車、IoT等等，以「語音助手」為主要形態，專註於「幫助用戶去執行一件事」；「文本」在消費品類中，則主要以「輸入法」為主，但其實它出現在很多垂直行業，比如客服質檢、翻譯機等等，還有閱讀理解類的產品。前者以「短句」為主，言簡意賅，主體明確，句式相對簡單，且上下文相關性較小；後者以「長句」為主，有複雜的句式結構，豐富的修辭手法，且上下文相關性很大，這對於NLU來說，是一個非常大的挑戰。近幾年語音產品的爆發，基本上是個終端自稱「AI」，必有「語音」這一項，這個主要指的是前面說的「命令」式的「語音助手」的形態，相比之下，「短句」在一個約束的垂直場景中，在一個既定的交互領域內，用戶的隨意發揮相對減少，說的話更容易被NLU所覆蓋；從體驗角度來說，相比GUI的「層層深入」，語音的VUI所帶來的「一言即達」確實要便捷很多，這也讓語音逐步成為了市場的寵兒。

命令式的語音產品，針對「一對一」的人機對話。通過以往的用戶數據統計發現，用戶會更傾向於使用「2～10個字的短句」，而短句中，一般包含兩到三個核心部分，一個動作，一個主體，一個修飾主體的詞，比如：「打開（動作）窗帘（主體）」、「空調（主體）調到（動作）25度（度數量詞）」，複雜點，如：「我想 打個電話給（動作）媽媽（主體）」、「你能幫我找一下附近（動作）有停車場（條件）的酒店（主體）嗎」；最後這個例子相比前面幾個，是不是有點開始感覺拗口了，越長的句子，要表達的核心部分越多，說起來就越是有些拗口，這不僅僅是在口語上有一定彆扭，還對於用戶記憶力有一定要求，對於一個用戶在使用語音的時候，更加傾向於「放鬆」、「自由」、「口語化」的表達，核心部分越多，用戶在說命令之前，需要思考和記憶的部分就越多，用戶的成本就會越高，這樣的說話方式，平時溝通中也很少見到吧。其實很早以前我做手機助手的時候，就做過類似的事，比如：兩個動作同時說的case，「我想發簡訊給秋歌中國移動的號碼內容是明天早上八點要開會並定一個明天早上六點的鬧鐘備註提醒秋歌早點出門」、一個動作五六個條件的case，「幫我找一下附近的有停車場的有wifi的有團購優惠的還在營業的吃日料的地方」，看著讀都有些饒吧，其實，從後台數據統計來看，除了測試，真實用戶基本沒人用。（特別注意：這裡討論的僅是產品體驗，如果就是為了PR炫技，這是一個不錯的case）。那麼，用戶難道沒有更多關鍵詞的訴求了嗎？ 其實還是有的，一般這裡會把一句超多關鍵詞的句子，拆分成多個短句，多次交互來完成這個訴求，比如：「幫我找一下附近吃日料的地方」＋「需要有停車場和wifi」＋「還得要有團購優惠」＋「去掉不在營業的店」… 其實從技術角度上來說，後面這個多輪對話篩選要比前面一大串關鍵詞的篩選，要複雜很多難很多，對應產品和交互在場景設計上，需要考慮斟酌的地方也特別多，大家在做到的時候，就會體會到。

對於「短句」，前面說的「句式與修辭」等維度的影響就會小很多，句式不會太複雜，修辭基本不會有，維度上少了很多，NLU做起來會相對容易一些。但是，就算事短句，在生活中，也是有很多特別之處的，我們在短句的基礎上，再介紹幾個維度，便於產品同學進一步去思考和優化「句」的理解能力。用戶的性格不同，人的情感狀態不同，用戶生活的地域不同，說話方式都會有所不同；同樣，對語音的交互訴求也會有所不同。比如，「確定」的表達，中規中矩的同學，可能就說「確定」，性格溫和一些的同學，可能會說「好的」，開心時，可能會說「好嘞」，低沉時，可能就只說一個字「好」，河南山東那一片，可能會說「中（『種』的發音）」等等。我記得之前看過一個段子，一個人說「有個鎚子的鎚子哦」，問，這個人到底是有鎚子還是沒有鎚子呢？想要做好語音產品，語言上還是需要下下功夫的哦～

文->上下文->語境和認知

句子組成文，在我們探究的以對話為核心的語音產品中，對應的是多輪對話的基本交互形態，因為需要多次和用戶反覆對話，有可能前面對話中已經說過的內容，後面就會被省略掉，比如：有這麼一句話，「能穿多少穿多少」，請問，這句話的意思是穿「多」還是穿「少」呢？這句話的兩種解讀方式都是正確的，但意思是卻完全相反，怎麼辦呢？看看前面說了什麼，結合起來看，前面一句是「天氣太熱了」，一下子就點明了，那句話是盡量少穿點。

在這個過程中，被略去的內容，就是「上下文」，我們在NLU中經常會說，「上下文相關」和「上下文無關」，引入上下文，對於NLU來說是很複雜的，這不僅僅是對演算法的考驗，也是對產品和設計同學的考驗。

前面文章有描述過，一個完整的對話始於「喚醒」，經過多次與用戶的語音交互，終於「執行」一個任務，我們把這個稱之為「多輪對話模式」，如果要再開始，則又要始於喚醒，依此類推。一般一個完整的對話，一旦用戶下達指令了，就進入了一個相對固定的流程里，其實這個上下文是產品定義好的，相當於，已經寫好流程的腳本，用戶必須按腳本流程來，對話結束，上下文就結束了，如果再開始新的對話，上一次說的內容就不會被繼承下來。這種交互方式的特點是有非常明確的起點和終點，相對固化同時相對簡單，但靈活度自由度太低，用戶很容易說一些超出預期的內容而被固定流程拒絕並強制引導回正確流程里，用戶若按既定流程進行，體驗會很流暢，也容易理解容易上手，和遊戲里的固定腳本的劇情很像。比如：

人：「我要預定一張機票」

機：「請問從哪裡到哪裡？」

人：「我不告訴你要去哪」

機：「對不起，我無法理解您的意思，請告訴我從哪個城市出發去往哪個城市，比如，您可以說，從北京到上海，請問您需要從哪裡到哪裡？

人：「從上海到北京」

機：「什麼時間出發？」

人：「下周二早上八點」

機：「以為您找到多張機票，請選擇第幾個？」

…

流程多分支問題以後再聊，本文主要是探討NLU，如果按照交互定義好的流程，在每個固定節點，都可以看成是一個小領域的「說法-含義」的NLU需求，沒有其他節點的干擾，如果不滿足這個節點的「說法」，可以引導用戶按要求再說一次，這樣的產品設計，讓用戶體驗感覺是「上下文有關」，但其實技術上可以「上下文無關」，這就極大降低了NLU的難度。

還有另一種交互方式，是在一次完整對話執行之後，再在新對話中延續上個對話的部分內容，我們稱之為「上下文對話模式」。比如：

人：喚醒＋「今天天氣怎麼樣？」

機：「今天上海天氣晴」

人：喚醒＋「北京的呢？」

機：「北京今天天氣晴轉多雲」

人：喚醒＋「明天的呢？」

機：「北京明天的天氣小雨」

…

這種由多次完整對話完成的上下文有關的對話模式，沒有明確的起點和終點，自由、靈活但用戶理解起來要相對要複雜一些，雖然這種體驗更加接近真實生活中的對話，但這種體驗對產品設計和技術實現，都是有非常多的挑戰，特別是技術上瓶頸過多，效果無法做到產品設計的預期要求，所以當前對此類體驗褒貶不一，我相信，隨著技術更精進，產品設計更精細，未來的語音交互，上下文相關的對話模式將越來越多。

「上下文對話模式」有哪些頭疼的地方呢？

其一，承載「上下文對話」的主交互模式，不能是「喚醒＋識別」這種交互形態，這種形態，當去執行一個任務之後，語音就退出了，再喚醒起來體驗上會覺得很繁瑣，所以這裡要引入一種新的交互形態，我稱之為「連續識別」的形態，也就是執行完任務之後，就不退出了，用戶一次喚醒，可以連續識別，完成多項任務，這樣才能真正展示出「上下文對話」的體驗優勢，好的，是不是感覺很不錯，那問題來了，既然還是需要「喚醒」，那麼就意味著，就算是「連續識別」的模式，也還是需要退出的（這裡請產品同學結合這幾篇文章中的知識，來判斷這裡為什麼需要退出），那產品同學，要怎麼定義退出的條件呢？

如果今天你的產品已經用到了這種「連續識別」的交互模式，那應該體會到，「退出機制」是這種交互模式中最重要也是最有難度的體驗點，這裡也將過去的經驗總結幾個點給到大家，希望有所幫助：

1、用戶靜默一段時間則認為語音退出，一般定義在10秒，請根據具體業務來決定，不要定義太短，如果有視覺輔助，務必做好視覺上的引導；這個點一般通過VAD來實現，本來就是「10秒內用戶不說話」嘛，先要通過AEC消除背景音（這裡有一個消除得乾淨不幹凈的概率），之後人聲檢測（還有一個人聲判定的概率），才能判定；在不同的場景中，聲源、揚聲器、麥克風等等的各種因素都會給這個結果帶來很多不確定因素，要注意把控好風險，具體細節前面文章都有細說，這裡就不重複了；

2、用戶主動退出語音，比如退出語音的指令或者硬按鍵等等，很好理解，沒啥好補充的；

3、用戶說的話，連續多次未命中產品定義的場景範圍，建議這個多次定義為2～3次，不宜過多；這個點是防止用戶可能在交談，或者在聊其他的內容，如果沒有一些場景的限制，那麼用戶在電話或者和別人說話中，語音就會處於反覆「瞎聊」的尷尬境地，所以這個地方，建議產品同學，根據自身產品的定位，定義一個場景的限制範圍，如果用戶說的內容，超出了這個範圍，2～3次之後，就退出語音，提醒用戶，有需要再喚醒；如果不太理解為什麼要「限制範圍」，你可能沒有考慮到，很多產品中，還定義了「閑聊」的技能場景，這個場景很特殊，什麼都可以問，什麼都能回答，這個場景如果被允許，則本項基本無效，建議在「連續識別」的交互模式中，限制「閑聊」的場景；

以上三點，從語音、語義、主動退出三個角度給予建議，希望在日常體驗設計中，能夠被借鑒。很多年前，這個方案出現在樂視電視上，「基於雙麥遠講方案，一次喚醒連續識別的強上下文對話形態，全語音操控，告別遙控器」，很多核心問題都是我們處理好的，之後他們換了語音引擎，這些坑處理的非常不到位，整體體驗就明顯差了很多。產品同學，將技術用好真的很關鍵哦～

其二，即是第二點，也是接著前面樂視電視的例子，繼續說，現在市面上，做「連續識別」體驗相對較好的，是訊飛的產品，如車上的「飛魚」，號稱「免喚醒」，整體體驗好談不上，還算可用的（發布會上演示的「全程免喚醒」是有點炒概念的嫌疑），在真車上體驗過，還是要先喚醒，喚醒成功之後，ASR就會一直在工作，且同步在做NLU，根據NLU的結果，來決定是否需要響應用戶的指令，如果60秒內沒有下達產品定義好的場景，則會自動退出。ASR+NLU的結合，這是我覺得訊飛確實做的好的地方，但是這種做法也有很多很多的問題：

1、延時問題，因為需要asr＋nlu同步進行，且在nlu出來結果之後，才可響應用戶行為，這就導致用戶說完話要等好一會兒，才會有反應；是不是覺得也就慢一點，其實沒什麼？其實不然，我在感受到這一點的時候，想到的是兩種用戶場景，一種是用戶說完了，此時他的預期是等幾秒語音會對他做出反應，而此時nlu沒有甄別出他的意圖，不會有任何反應，用戶還在等，之後會忽然陷入迷茫，是說錯了嗎？還是網路不好？還是它出什麼毛病了？其他什麼原因？而另一個情況，則是在有第一種情況經歷之後，當使用時，等幾秒之後，語音沒有作出反應時，用戶會認為可能是哪裡說錯了，立刻再說一次，說的時候，前一次指令被響應了，忽然響應的指令會干擾用戶，這一次說的話可能還沒說完就被打斷了，一下子打亂了用戶的體驗邏輯。語音在「時間維度」上的體驗，非常關鍵，整體把控不當，用戶就很容易陷入一種「對於未知的恐慌」心理中，這樣會讓整體體驗減分不少（其實，語音產品如果喚醒反應很慢，也會出類似的體驗問題）。

2、為了解決延時問題，我們可能會將asr＋nlu的整個步驟放到端上來完成，這樣就能消除網路因素所帶來的等待時長忽長忽短的問題，但又引出了一個新的問題，端的硬體性能問題和端的迭代周期問題，一般端上的硬體肯定不會有雲端那麼好，效率那麼高，所以在端上，必然會有所壓縮有所裁剪，這麼壓縮裁剪之後，asr＋nlu的整體效果會大打折扣，就算是這個大打折扣的asr＋nlu，也要比以前「喚醒＋識別」的端的資源的要求高出五到十倍（「喚醒＋識別」，端上的asr＋nlu只需要承載僅無網條件下的語法訴求，而這個「免喚醒」，端上asr＋nlu則需要承載所有的語法訴求），目標硬體扛得住嗎？迭代周期也是一個要求，前面有提到語義迭代的意義，這裡不重複了；

3、響應反饋的體驗問題，這個地方不同人觀點不一樣，我就僅表達我個人的觀點了，後台播放著音樂，喚醒之後，音樂是繼續播放，當asr＋nlu中nlu明確用戶的意圖之後，才會打斷音樂，執行並反饋用戶，這個地方，讓我覺得「喚醒」在整個體驗中好多餘，在確認意圖之後才停止音樂做出響應，整體讓我有些滯後的感覺。當然，我知道這樣做是有其原因的，需要喚醒，是為了防止平時用戶的正常溝通誤入語音，導致語音誤以為用戶在操作語音，就像家裡在聊天或者大半夜沒人說話，音箱自己忽然說起話來，怪嚇人了；而之所以意圖明確之後才有反饋，是為了做到，響應產品指定的「場景範圍」，範圍之外則忽略（注意，這裡「閑聊」也不再範圍之內哦），只有nlu的結果出來了，才知道是範圍內還是範圍外，才能做出正確的響應。

雖然種種原因所致，但我從產品這個角色來界定整體體驗，我並不認為體驗好，為了炒一個所謂的「AI」，犧牲了用戶太多的體驗，技術的瓶頸都是客觀存在的，在產品這個維度思考問題，本就沒有對錯可言，更多的是產品在理解技術瓶頸之後，所做出的技術和體驗之間那個平衡點的選擇而已。

其三，場景歧義問題，多個場景領域之間，有很多是有歧義的，比如，在車行業，僅說「徐家匯」，可以是導航到「徐家匯」，同時也可以是「徐家匯」的天氣，這個地方就會有，場景歧義的問題，徐家匯到底是導航領域還是天氣領域？產品可以定義為「多領域」，讓用戶選擇「導航」和「天氣」兩個領域來確認，但是這樣把流程多做了一步，體驗不太好，因為是「車」這個垂直行業，用導航比天氣多，所以，也可以定義為默認「導航」，這就是場景歧義問題。

其四，上下文失效問題，我們在這個場景歧義的基礎上再追加上下文的話，又會帶來新的問題，當有上下文是問「天氣」時，按照上下文的定義，後面說的「上海徐匯」其實就相當於在說「上海徐匯的天氣」，那這個時候只說「上海徐匯」就並不是默認「導航」了，在這種情形下，「上下文」何時失效，怎麼失效，就變成了用戶無法預知到的。這個時間太長，假如10小時，則今天早上說了一個「北京天氣」，一整天，說「上海徐匯」、「北京天安門」等poi，全都進到天氣里去了，如果之前沒問過天氣，則一整天，說這些都應該是進導航的，而如果這個時間太短，假如10秒，則說完「北京天氣」，前方一個左轉，回來再問，「上海徐匯」，就跑導航去了，一點「上下文」的體驗都沒有，是不是體驗起來就全亂了？ 還有，當前上下文是天氣時，這個時候來了一個沒有上下文的指令，此時「天氣」這個上下文是失效呢？還是繼續有效呢？這個「上下文」的失效對於用戶體驗來說非常難界定，需要大家在自己行業自己產品中反覆體驗來慢慢打磨。

其五，跨域問題，當正在導航的流程中，忽然說了一個非導航領域的指令，此時是跳轉到新的指令執行？還是強制用戶完成當前指令後才可以執行其他指令？如果跳轉到新的指令執行，執行完畢後，是否還需要再回到導航的流程中來，繼續完成呢？ 這只是產品的選擇，就不展開探討了。

以上，不論是「上下文無關」的「多輪對話模式」，還是「上下文有關」的「上下文對話模式」，一般在對外市場宣傳時，都會將自己的NLU稱之為具備「上下文理解能力」，所以，我將這兩大類，都放到「上下文」這個部分來詳細聊。

但不要以為，有了分詞、語法、上下文，就真的能做好NLU，對於語言來說，所涉及的面實在太廣，可不僅僅前面提到的「字詞句文」，還與當前的對話的語境，乃至人的經歷、閱歷、教育、背景、三觀、認知等等，都息息相關。限於篇幅，就不再繼續展開了，我簡單舉兩個相關的例子。

第一個例子，是當時我寫這篇文章時，《獵場》剛播完，想蹭一下熱度的，沒想到一忙起來，就是三個月後了，所以錯過了很多。戲裡戲外，在你不知道背景的情況下，或許會認為，「感動」和「敢動」只是同音詞所帶來的同音詞的歧義理解，而當你知道，獵場劇情中，飾演胡歌一任女朋友的章齡之，同時也是邊上這位戲裡戲外都是胡歌好兄弟的陳龍的現實中的妻子時，是不是對於下圖的「不敢動，不敢動」又多了一份含義？ 背景知識能夠讓很多話語，暗藏很多潛在含義，人尚難瞬間領悟，何況AI？

第二個例子，是霍金離世時網上出的段子，可以將其僅僅停留在，《時間簡史》這是個詞，所以分詞錯誤導致理解錯；也能上升到，兩個人的認知處於不同的層次上，人的眼界，思維的格局，考慮問題的高度，甚至到三觀，都是完全不一樣的，從而引發的對於同一句話的理解，會有天壤之別。對於人來說，有些人你會聊得來，有些人你完全聊不來，有些人一聊就冷場，有些人秉燭夜談也難盡興，等等，人尚難面面俱到，何況AI？

回到我們的NLU，它離我們期待的理解能力還非常遙遠，還是需要產品、設計、研發同心協力，不斷努力，不斷前行。

歧義消除和語義糾錯

前面是從「詞->句->文」來聊語義，同樣，也可以從「文->句->詞」來思考。

通過「上下文」，我們可以通過上文的一些元素，比如，所描繪的場景，所表達的情緒等等，來幫助下文「理解」句子的意思；如果下文的句子本身有一些歧義，也是可以通過上文的這些元素來消除的。比如前面的舉的例子：

人：「霍金是誰」

機：「霍金是《時間簡史》的作者…」

…

人：「你有《時間簡史》嗎」

此時，根據上文的對話，我們可以知道，用戶的當前認知中，已經知道《時間簡史》是一本書，那麼在後面的對話中，就可以消除掉上面例子的尷尬歧義，直指「詢問是否有《時間簡史》這本書籍」的含義。

同樣的，通過句子語法的不同，也可以消除「詞」的一些歧義，比如有個詞是「成都」，這個詞既可以是「城市」，也可以是「歌曲名」，這就是歧義，那到底是哪個呢？這個時候，就可以看看這句話的語法是什麼，用戶說的是「我想聽成都」，這種case就能夠消除這個歧義，直指「歌曲成都」的含義；再如：

人：「播放歌曲」

機：「好的，正在為您播放歌曲」

人：「成都」

…

這裡也是可以根據「上下文」的場景來消除歧義的，靈活運用這些語言中的元素，可以有效地幫助我們消除歧義，正確理解用戶意圖。

通過文、句、詞，還可以帶來一個重要的能力，我們叫做語義糾錯，比如：

人：「我要導航」

機：「請問你要去哪裡？」

人：「漕可涇開發區」（不是打錯字了，這裡舉例就是漕「可」涇）

…

用戶有可能因為口音、因為讀錯、因為等等原因，導致說出的內容和正確的內容存在一定的偏差，當語義有正確詞作為參考時，語義可以進行糾錯，將錯誤詞進行矯正。因為這種糾錯能力，也是具備AI的所有概率特性，為了能夠讓語義糾錯效果更好，我們可以通過「文、句、詞」來縮小範圍，從而提高糾錯的準確率。

如前面的例子，上下文中表達了「導航」的場景限制，意味著，「漕可涇開發區」高概率是一個地點的poi，當前用戶gps所在「上海」這個城市，高概率說的是一個「上海」的「poi」點的名字，於是，拿「漕可涇開發區」到「上海」的「poi」詞表中進行模糊比較，發現與之最接近的是「漕河涇開發區」，從而，將其糾正為「漕河涇開發區」。

注意：糾錯是一把雙刃劍，用不好，可能會讓語義效果不升反降，所以，產品同學要和研發深入去溝通演算法的實現邏輯，詳細了解「語義糾錯」中的各種場景，仔細分析可用的語言元素，才能定義出更加有效的矯正規則，從而幫助語義提升最終體驗。

上面講了這麼多關於語義的思維方式，語義產品的日常工作會經常涉及到這些，語音也好，語義也好，圖像識別也好，機器學習也好，AI這個行業的演算法技術，萬變不離其宗。語音產品使用的技術能力都滿足「沒有過去就沒有未來」的基本設定，沒有數據，能力做不好，體驗做不好，用戶就不會主動去用；用戶不用，就無法產生足夠豐富足夠全面的數據；而沒有數據... 這就形成了一個惡性循環。若想將其轉化為良性循環，這個關鍵的點，就在訓練集和測試集的產品標準定義上。

如果我們能夠在最開始的訓練集和測試集定義的維度足夠充分，足夠全面，數據錄製的量足夠豐富，對於人工標註的質檢控制足夠到位，以此集合，定義好產品的量化指標，項目之初，從產品到設計，從研發到演算法，從項目到測試，整個團隊都能拉齊所有認識，一方面建立了足夠接近真實的預測環境，另一方面也統一了大家的目標和方向。

如果你的團隊出現了這樣的情況，試試看，很快就能看到整個團隊和之前不一樣了。

在這個「有多少人工就有多少智能」的AI時代，產品和設計的同學，你們真的意識到自己有多麼重要嗎？