Android-AIUI技能設計技巧及處理策略總結
半年多一直在做機器人語音方向的應用，現在產品基本上穩定下來了，在語音互動的路上踩過不少坑，在這裡記錄分享一下。假設看到這篇文章的人對AIUI的基本概念包括實體、技能、語料、意圖都已瞭解。
最開始的語音處理方案
訊飛MSC錄音+本地NLP處理。
當時還不知道有AIUI這個東西，本地做了一個簡陋的NLP處理的程式。大概思路和AIUI的技能處理一樣，先把不同的問題分類並定好優先順序，然後從返回的語音文字中提取出關鍵字，分析意圖。再對相應的意圖做處理。
這種方案滿足了最初的演示需求，但是機器人的語音互動體驗不好，必須使用固定的句式、只能回答固定的問題。演示圓滿完成之後，公司要求著力做好這個專案。本來說有個demo就行的任務，變成了產品級的專案。於是就有了下面的方案。
真正可行的語音處理方案
MSC錄音 + AIUI語義解析 +本地技能處理
既然是產品級的專案，開始研究要怎麼做。在AIUI的官網中看到了有關AIUI的介紹，發現其處理思路和我之前做的幾乎一樣，但其豐富的問題庫，優秀的語義解析設計比我的好多了。也就是說，我可以用AIUI這套處理實現之前所有的功能，還能做的更好。
AIUI的接入有一定的學習成本， 經過幾個月的實踐，總結一下AIUI的技能語料設計的內容。
AIUI的語料是全匹配的，比如你設計的語料是“你叫什麼名字”，問法也必須是“你叫什麼名字”才能識別出來。由於錄音中可能會存在各種各樣的雜音，要想識別“你叫什麼名字××××××”（×表示任意字元）這種問題，需要使用AIUI的
通配實體。如果終端的實體需要差異化配置，可以使用動態實體。動態實體分為應用級、使用者級和自定義級。應用級可以在實體名相同的情況下，為每個 appid 設定不同的實體副本；使用者級對每個使用者維護一個實體副本；自定義可以自定義的維度，為自定義的維度設定不同的實體副本。我的應用在不同的城市，實體的資料是不一樣的，相同城市，實體資料一樣。所以選擇了自定義維度，維度就是城市(city)。
動態實體在應用每次啟動必須重新上傳，否則不會生效。每次上傳都會覆蓋之前的動態實體。
語料設計時儘量不要出現文字，全部用實體來表示。
例如：我的某一條語料就是{common}{station}{common}{go}{common}{station}{common}
其中common是通配實體，可以匹配任意1-21個字元，go是一個靜態實體，語料可以是“去，到，前往”等，station是一個動態實體，表示每個城市的站點。
這樣設計的好處在於，如果發現某個詞語有很多近義詞，可以直接修改其靜態實體就行，而不必修改語料的句式。技能在初期設計時，就應該做好區分，保持單一原則，即一個技能只處理一類問題。千萬不要把不同型別的問題放在同一技能裡面，當你後續需要對不同技能分類處理的時候，你就會感謝當初選擇了單一原則。
當技能多了，避免不了會出現一個語料，一種問法，可能對應了多個技能裡的意圖。預設的結果在最外層的，更多結果會體現在”moreResult”這個欄位裡面。這個時候要怎麼處理？我的策略是：技能分級，按優先順序處理。為每一種技能設定一個優先順序，只處理最高優先順序的技能。如果最外層的優先順序和moreResult裡面最高優先順序的優先順序一樣，則取最外層的結果。如果更低，則取moreResult裡面最高優先順序的結果。
“rc=4”的語義處理：這類語義為未知語義，平臺上沒有對應的技能或者問答對。這類語義是需要過濾處理的，我的邏輯是：如果當前有正在處理的語義，直接丟棄未知語義；如果沒有，則保留。
如何處理商店的技能：商店的技能其實很好處理，因為商店的技能基本上都是有直接答案的。我們可以統一處理。在answer這個欄位裡能解析到商店技能返回的語義結果的回答，我們只要處理這個資訊就可以。
思考
1.AIUI的這套語音語義處理方案解決了錄音、識別、語義解析功能，但是實際使用過程中，使用者的問法不可能按照我們設計的來，如何才能最大限度地匹配出使用者的意圖？最好還是自己做一些NLP的處理，比如可以計算使用者的問法和語料庫的相似度，選擇一個相似度最大的意圖返回給使用者，或者引導使用者做出正確的問法。
2.全雙工互動：1.0版本做的是單工的，即機器人說話的時候不錄音，使用者需要看機器人的狀態來判斷這個時候是否在錄音，是否可以開始互動，體驗很不好。2.0版本就改成了全雙工的互動，機器人響應的同時，也在錄音。這個改動很簡單，但是對使用者體驗的提升卻是極大的。如果你也是和我一樣的方案，建議也做成全雙工的。這種全雙工的方式在某些形態，比如手機上，可能不太合適，但是像機器人、智慧家居這些產品形態上是很合適的。試想如果每次互動，都要先說一遍喚醒詞，這樣的產品你會喜歡使用嗎？
注：本篇為工程實踐中的純乾貨分享，轉載請註明出處。