如何評測語音技能的智能程度（3）——交互流暢
摘要：所以，在考量服務穩定性上有兩個大層面，一個是智能助手本身的穩定性表現，二個是在服務用戶的過程中，如何規避，以及遇見問題後的業務響應速度表現。這個模塊，重點考量智能助手各個性能指標及交互體驗層面的表現。
《如何評測語音技能的智能程度》是5篇系列文字，來自一位創業者，也是DuerOS開發者的投稿，老曹儘量不做變動和評價，儘量保持系列文章的原貌，這是第3篇。
當用戶發起需求後，【意圖理解】在前，【服務提供】在後，基本上已經構成了一輪完整閉環。
之所以把【交互流暢】這個點作爲一個單獨維度拆解出來，是因爲其貫穿始終。如果這個模塊的內容如果處理不好，將全程傷害體驗。
本篇文章爲大家帶來【交互流暢】維度的評測點拆解。
這個模塊，重點考量智能助手各個性能指標及交互體驗層面的表現。
【交互流暢】（1）服務穩定性
“正常運行”、“不出bug”、“魯棒性好”。
評測點已經講完了，十分清晰，幾乎每一個互聯網從業者都能夠說出個1234，然後呢？
穩定不好，這類問題可大可小，小點就是網絡繁忙，不給你任何反饋，大到極致，機器人可以反動搞事情，“愚蠢的人類啊，阿西莫夫的機器人三定律也救不了你們。”
好了，開個玩笑。實際上，定義“what”容易，解決“how”往往都纔是考量業務理解。
所以，在過往我經常會問面試者的問題有一個，你曾經做過的智能助手產品，出過哪些問題，你是如何解決的？
不同的人回答不同，對於這類命題，才更有探索價值。
一般情況下，回答這些是技術的問題，往往都很糟糕，實際上，每個公司的穩定性業務保障是需要一個體系來承擔的。
所以能得分的面試回答是，把影響穩定性的故障進行一個分類，並且設計好處理路徑。
這裏只有大類別，單單一個業務後臺，就能做很多範圍細分。故障表現情況例如：崩潰、局部故障、弱網環境、狀態更新、請求超時、並發表現……嚴重程度不一致，此處不逐一展開。
出過哪些問題分類回答完畢，你是如何解決的呢？是後續的一個命題。
一般情況下，公司的業務流程是這樣運轉的。
這裏有3個細節。
第一個是反饋的行爲折損。根據歷史數據表現，1個問題被報上來，背後往往有至少10個以上的用戶遇見過，只是用戶懶/報問題麻煩，沒有報而已。
第二個是反饋的信息折損，客服問：你做了什麼操作導致的崩潰？用戶答：我也不知道，就崩潰了。這種情況，是不利於排查和定位問題的。
第三個是“解決方案的設計”，這裏也分爲“臨時解決方案”和“全局最優解決方案”兩說。
下圖是一個信息化的風控結構，做過相關模塊的，懂得自然懂，篇幅太長，此處不展開。
所以，在考量服務穩定性上有兩個大層面，一個是智能助手本身的穩定性表現，二個是在服務用戶的過程中，如何規避，以及遇見問題後的業務響應速度表現。
服務穩定性的考量是以一定週期、頻次進行考量纔是科學合理的。
【交互流暢】（2）響應速度/流暢度
服務穩定性保障了之後，接下來就是速度。
語音交互這件事，本身就是因爲語音輸入的高效性。
當用戶發出了需求，希望儘快拿到反饋，
現在的用戶極其沒有耐心，速度一旦過慢，註定會被棄而不用。
而在智能語音助手交互對話的過程中，又包含哪幾個階段呢？
先明確一點，一味追求快並非是好。
1、人類喚醒後，計算器的響應靈敏度，靈敏度太強（誤喚醒）或太弱（沒反應）都不好，當然如果升級下維度，還可以添加場景，比如噪音下喚醒，遠場喚醒等。靈敏度是可以調試的，以表現合適最好。
2、人類表述了自己需求後，ASR有兩種方案，一種是邊識別邊轉換文本，另外一種是表述完畢後一口氣轉換爲文本。
3、業務邏輯處理表現，其實是NLP領域最爲核心的部分，也是最爲耗時的部分，從效率角度上而言，此處儘管追求越快越好。
4、這裏的語音播放，不是越快越好，而是合適就好，語速太快會給人一種輕浮及不穩重的感受，太慢則顯得很笨以及可能造成不耐煩。而反饋樣式則需要儘快呈現，有些智能助手語音播放完畢了，結果下面的內容還沒加載到位。
5、人類總計2次交互，一次喚醒，一次表達意圖，這2個行爲過後，等待AI反饋。也就是說，當用戶說完話後的下一秒，助手要同時處理，識別+理解+接口查詢+反饋四個階段，這個過程中，全部都是用戶的等待狀態。
人們去飯店點完了菜，等上菜的過程中，中間服務員還會過來幫忙緩解，這個過程較長，一定要考慮好等待體驗管理，不至於讓用戶無聊。
前後端共同協作，添加一些語音播報，模態框提示，漸隱消失提示，動畫效果，來管理用戶的等待體驗。
而有些無屏的音箱則需要使用等待、加載、成功等光效表現來管理用戶的等待體驗過程。
所以，在響應速度/流暢度這個維度上，不同的情況不同的對待，以合適最好。
【交互流暢】（3）交互形式豐富度
每一種交互形式的存在，都有着其依賴的場景。
下圖是我嘗試窮舉人類的輸入行爲（盡力做到MECE）。
點觸、語音、手勢、點頭搖頭、人臉識別、聲紋、指紋驗證等等均算在內。
這一塊真的不需要多講，除了腦機接口，基本上都玩過，體驗過的都會覺得其有意思的地方。
交互形式豐富度，評測點已解釋完畢，在未來，一定是多模態交互，來適應各種各樣的業務場景。
說一點，產品經理應該修煉的部分。
筆者有一個出門問問的耳機，它是智能助手的操控延伸。在提供創新體驗的同時，弄明白了是什麼（what），基於此去探究爲什麼（why）以及怎麼辦（how）。
所以，筆者認爲產品經理應該修煉的部分。
-
儘量多的去使用智能硬件，把工作體驗變成日常，以培養敏感度。
-
弄清楚這些交互方式、元器件連接方式背後的技術實現原理。
-
每種技術方案都有多種實現方式，知曉其優劣勢及實現成本。
這三層修煉是遞進關係。只有這些把這類東西融入到了我們的生活之中，敏感性才培養得起來，繼而去加深理解，如此才更有可能做創新。
我們今天所熟知的衆多的科學以及專利技術的發明者，其實都是根據前人的經驗進行的某種程度上的改進。從結果上來看，主要有兩種改進方向。
一種是將一個原本在實驗室裏面理論上可行，變成大規模批量生產的方案。
另一種則是根據已有的技術發明，發現一些“居然這個技術還可以被這樣使用” 的方案。
蘋果公司在技術研發上，並沒有什麼特別優秀的表現，但是在整合以及運用技術的這件事情上，則是優秀中的代表。市面上的絕大多數的手機公司的研發部門，應該都叫技術方案整合商更爲貼切。
只有將自己的 日常浸潤到各種類型的交互體驗裏，進而去理解實現方案背後的技術原理 ，才更有可能做出創新啊！
【交互流暢】（4）新手教學表現
我第一次給父母體驗‘小愛同學’的時候，他們是需要我的幫助才能使用。
什麼是喚醒；什麼是監聽；什麼時候你說話它會響應/不響應；覺得羅嗦，如何打斷對方。
這個教學行爲大概要持續一小會，言傳身教才能夠學出如何進行語音交互。
如果沒有我，我的父母將無法上手。這種依賴人，在旁邊教的東西，實在是學習成本太高。
而當我們的產品被用戶首次體驗的時候，如果沒有新手教學，用戶也許就呆滯在那裏，並不知道如何使用。
新手教學體驗是非常重要的一個環節。
體驗各家智能語音助手，在這一塊的表現上各不一致，故而列爲評測點。
行業新的新手引導教學其實非常多的種類，滑屏海報，蒙版遮罩，文字tips，互動式引導。
簡單一分爲二的說，大體可以分爲，基本操作教學，以及對應業務的教學。
在考量這個業務表現 的 維度上，基本操作教學必須得有。 而具體業務教學，則是具體問題具體設計。
百度地圖的新手引導就做得十分友好。基本上爲小度導航的每個業務能力配備了沉浸式引導方案。
這一塊是參照遊戲行業的解決方案。就我過往對小度的體驗，其實有很幾次改版了，不斷迭代演化至今。
最好的交互設計其實是不需要新手引導的，如同微信一樣自然。
在一個普遍使用點觸操作習慣的年代，如何讓用戶體驗這種新的交互體驗方式？壓力就在新手教學上。學的會就用，學不會就丟棄。
嚐鮮體驗過後， 以後也會（改變習慣）使用語音尋求業務 ，壓力則在業務設計上。方便就用，不方便就丟棄。
這是一個遞進邏輯。只有基本操作掌握了纔有後面的（改變習慣）使用，把用戶當成小白的新手教學行爲，一定得做好！
【交互流暢】（5）全雙工交互表現
全雙工（Full Duplex）是通訊傳輸的一個術語。通信允許數據在兩個方向上同時傳輸。
先用通俗的例子比喻下。
單工：類似聽廣播。
單向傳遞信息，一個人只能聽另一個人說。
半雙工：類似對講機。
甲：洞幺洞幺，能不能聽到我說話，over。
乙：可以聽到，over。
全雙工：類似打電話。
甲：喂，還記得我的聲音麼？我是…… 乙：啊，是你小子啊……
雙方可以各說各的，可以互相打斷。
人機交互追求更加自然流暢，這一點必不可少。
當前的語音助手，只有在進入監聽狀態纔可以做出反饋。
而進入監聽的兩種情況，一種是使用[喚醒詞]，完成喚醒/打斷的動作。
另一種是AI判斷業務沒完，做出引導式的追問，然後進入監聽狀態。
例如：
用戶：我想看最近上映的電影。
助手：爲你找到如下電影，你可以對我說看第幾部。播放完畢後進入監聽狀態。
其實助手第一時間在屏幕上展示了電影列表的搜索結果，但是總得把語音唸完……。
作爲用戶而言，我已經看到了助手給我的展示結果，也知道你的後續話術套路，我會迫不及待的使用[喚醒詞]，完成打斷行爲……使用過的都會感受到這種情況的心累。
而在全雙工的能力加持下，即爲，你播報你的，我說我的，不用等你念完，才進入監聽狀態，你念一半的時候，我搶話到下一步驟，你根據我的節奏推進業務就好。
還有一種技術方案相信從業者們也不陌生，就是基於當前語義場景下的“判斷爲無效內容後的拒絕響應”。
例子：我想聽……嗯，我想想，哦對了，那個周杰倫的青花瓷
識別出用戶當前說的話是不是給它的指令，能過濾掉無效的停頓，語氣助詞等干擾信息，再做出反應。
這就是全雙工所指的“瞬間雙向”表現，更接近人與人之間的自然對話，提升了交互體驗。
階段性結尾
同樣的，在【交互流暢】這個單元模塊，有更多評測點去列舉，但是受限於篇幅以及能力所限，刪掉的一些內容。保留以及刪除評測點的原則，也是基於評測指標的普適性。
同樣用提問的方式，列舉一下我刪除掉的考覈點。
第（6）點，列舉一個我玩遊戲多多自走棋，體驗遊戲助手的例子。敏感詞，會在很多的地方出現。防止內容攻擊，保護安全的，特別是大公司，往往會用上一個敏感詞庫過濾處理，相信很多的人都遇見過，有些給你反饋，有些則直接給你和諧掉了。顯然是影響交互體驗流暢度的。造成這種情況的顯然是政策問題。
第（7）點，未來的交互體驗過程中，多硬件終端，多場景，有屏無屏的交互體驗方案，這是一個“現階段各家都沒做，而在未來各家一定會做”的評測點。
如果列舉其例子，問題以及探討解決方案起來，篇幅就過長了，就目前AI跨平臺使用表現而言，故現階段捨棄。
第（8）點，完成任務時候的成本考量。這個裏面涉及一些語音識別、語義理解的層面。比如，任務流的多輪對話是分層次的，而當用戶一口氣給助手提供多個查詢槽位，能否給予結果。比如，在一些支付和驗證的層面，視覺和聲紋讓用戶付出的代價幾何等等。助手取硬件權限（讀取GPS，讀取短信等）時的表現。
在滿足用戶需求的時候一定有方案，而不同方案之間的取捨考量就存在比較關係了。
筆者在設計業務的時候，同時也會考量用戶的隱私保護安全。
你要安全，就加判斷確認，加驗證，影響流暢度。
你要流暢，就替用戶配置更多的默認選項，影響安全。
“流暢”和“安全”本身就是一個互相沖突的命題。此處沒有對錯，只有選擇。
【交互流暢】是一個非常重要的全局性指標，貫穿【意圖理解】和【服務提供】始終。如果這個維度的評測方向如果處理不好，將全程傷害體驗。
以上，關於第三大維度【交互流暢】的諸多考量點，就此完結。
【關聯閱讀】
