如何評測語音助手的智能程度（3）：交互流暢

本篇文章為大家帶來【交互流暢】維度的評測點拆解。這個模塊，重點考量智能助手各個性能指標及交互體驗層面的表現。希望對從事相關領域工作的各位有所啟發。

當用戶發起需求后，【意圖理解】在前，【服務提供】在後，基本上已經構成了一輪完整閉環。

之所以把【交互流暢】這個點作為一個單獨維度拆解出來，是因為其貫穿始終。如果這個模塊的內容如果處理不好，將全程傷害體驗。

本篇文章為大家帶來【交互流暢】維度的評測點拆解。

這個模塊，重點考量智能助手各個性能指標及交互體驗層面的表現。

1. 服務穩定性

「正常運行」、「不出bug」、「魯棒性好」

評測點已經講完了，十分清晰，幾乎每一個互聯網從業者都能夠說出個1234，然後呢？

穩定不好，這類問題可大可小，小點就是網路繁忙，不給你任何反饋，大到極致，機器人可以反動搞事情：「愚蠢的人類啊，阿西莫夫的機器人三定律也救不了你們。」

好了，開個玩笑。實際上，定義「what」容易，解決「how」往往都才是考量業務理解。

所以，在過往我經常會問面試者的問題有一個：你曾經做過的智能助手產品，出過哪些問題，你是如何解決的？

不同的人回答不同，對於這類命題，才更有探索價值。

一般情況下，回復這些是技術的問題，往往都很糟糕，實際上，每個公司的穩定性業務保障是需要一個體系來承擔的。

所以能得分的面試回答是，把影響穩定性的故障進行一個分類，並且設計好處理路徑。

這裡只有大類別，單單一個業務後台，就能做很多範圍細分。故障表現情況例如：崩潰、局部故障、弱網環境、狀態更新、請求超時、並發表現……嚴重程度不一致，此處不逐一展開。

出過哪些問題分類回答完畢，你是如何解決的呢？是後續的一個命題。

一般情況下，公司的業務流程是這樣運轉的。

這裡有3個細節：

反饋的行為折損。根據歷史數據表現，1個問題被報上來，背後往往有至少10個以上的用戶遇見過，只是用戶懶/報問題麻煩，沒有報而已。
反饋的信息折損，客服問：你做了什麼操作導致的崩潰？用戶答：我也不知道，就崩潰了。這種情況，是不利於排查和定位問題的。
「解決方案的設計」，這裡也分為「臨時解決方案」和「全局最優解決方案」兩說。

下圖是一個信息化的風控結構，做過相關模塊的，懂得自然懂，篇幅太長，此處不展開。

所以，在考量服務穩定性上有兩個大層面，一個是智能助手本身的穩定性表現，二個是在服務用戶的過程中，如何規避，以及遇見問題后的業務響應速度表現。

服務穩定性的考量是以一定周期、頻次進行考量才是科學合理的。

2. 響應速度/流暢度

服務穩定性保障了之後，接下來就是速度。

語音交互這件事，本身就是因為語音輸入的高效性。

當用戶發出了需求，希望儘快拿到反饋，現在的用戶極其沒有耐心，速度一旦過慢，註定會被棄而不用。

而在智能語音助手交互對話的過程中，又包含哪幾個階段呢？

先明確一點，一味追求快並非是好。

人類喚醒后，計算器的響應靈敏度，靈敏度太強（誤喚醒）或太弱（沒反應）都不好，當然如果升級下維度，還可以添加場景，比如噪音下喚醒，遠場喚醒等。靈敏度是可以調試的，以表現合適最好。
人類表述了自己需求后，ASR有兩種方案，一種是邊識別邊轉換文本，另外一種是表述完畢后一口氣轉換為文本。
業務邏輯處理表現，其實是NLP領域最為核心的部分，也是最為耗時的部分，從效率角度上而言，此處儘管追求越快越好。
這裡的語音播放，不是越快越好，而是合適就好，語速太快會給人一種輕浮及不穩重的感受，太慢則顯得很笨以及可能造成不耐煩。而反饋樣式則需要儘快呈現，有些智能助手語音播放完畢了，結果下面的內容還沒載入到位。
人類總計2次交互，一次喚醒，一次表達意圖，這2個行為過後，等待AI反饋。也就是說，當用戶說完話后的下一秒，助手要同時處理，識別+理解+介面查詢+反饋四個階段，這個過程中，全部都是用戶的等待狀態。

人們去飯店點完了菜，等上菜的過程中，中間服務員還會過來幫忙緩解，這個過程較長，一定要考慮好等待體驗管理，不至於讓用戶無聊。

前後端共同協作，添加一些語音播報，模態框提示，漸隱消失提示，動畫效果，來管理用戶的等待體驗。

而有些無屏的音箱則需要使用等待、載入、成功等光效表現來管理用戶的等待體驗過程。

所以，在響應速度/流暢度這個維度上，不同的情況不同的對待，以合適最好。

3. 交互形式豐富度

每一種交互形式的存在，都有著其依賴的場景。

下圖是我嘗試窮舉人類的輸入行為（儘力做到MECE）。

點觸、語音、手勢、點頭搖頭、人臉識別、聲紋、指紋驗證等等均算在內。

這一塊真的不需要多講，除了腦機介面，基本上都玩過，體驗過的都會覺得其有意思的地方。

交互形式豐富度，評測點已解釋完畢，在未來，一定是多模態交互，來適應各種各樣的業務場景。

說一點，產品經理應該修鍊的部分。

筆者有一個出門問問的耳機，它是智能助手的操控延伸。在提供創新體驗的同時，弄明白了是什麼（what），基於此去探究為什麼（why）以及怎麼辦（how）。

所以，筆者認為產品經理應該修鍊的部分。

盡量多的去使用智能硬體，把工作體驗變成日常，以培養敏感度。
弄清楚這些交互方式、元器件連接方式背後的技術實現原理。
每種技術方案都有多種實現方式，知曉其優劣勢及實現成本。

這三層修鍊是遞進關係。只有這些把這類東西融入到了我們的生活之中，敏感性才培養得起來，繼而去加深理解，如此才更有可能做創新。

我們今天所熟知的眾多的科學以及專利技術的發明者，其實都是根據前人的經驗進行的某種程度上的改進。從結果上來看，主要有兩種改進方向。

一種是將一個原本在實驗室裡面理論上可行，變成大規模批量生產的方案。

另一種則是根據已有的技術發明，發現一些「居然這個技術還可以被這樣使用」的方案。

蘋果公司在技術研發上，並沒有什麼特別優秀的表現，但是在整合以及運用技術的這件事情上，則是優秀中的代表。市面上的絕大多數的手機公司的研發部門，應該都叫技術方案整合商更為貼切。

只有將自己的日常浸潤到各種類型的交互體驗里，進而去理解實現方案背後的技術原理，才更有可能做出創新啊！

4. 新手教學表現

我第一次給父母體驗『小愛同學』的時候，他們是需要我的幫助才能使用。

什麼是喚醒；什麼是監聽；什麼時候你說話它會響應/不響應；覺得羅嗦，如何打斷對方。

這個教學行為大概要持續一小會，言傳身教才能夠學出如何進行語音交互。

如果沒有我，我的父母將無法上手。這種依賴人，在旁邊教的東西，實在是學習成本太高。

而當我們的產品被用戶首次體驗的時候，如果沒有新手教學，用戶也許就獃滯在那裡，並不知道如何使用。

新手教學體驗是非常重要的一個環節。

體驗各家智能語音助手，在這一塊的表現上各不一致，故而列為評測點。

行業新的新手引導教學其實非常多的種類，滑屏海報，蒙版遮罩，文字tips，互動式引導。

簡單一分為二的說，大體可以分為，基本操作教學，以及對應業務的教學。

在考量這個業務表現得維度上，基本操作教學必須得有。而具體業務教學，則是具體問題具體設計。

百度地圖的新手引導就做得十分友好。基本上為小度導航的每個業務能力配備了沉浸式引導方案。

這一塊是參照遊戲行業的解決方案。就我過往對小度的體驗，其實有很幾次改版了，不斷迭代演化至今。

最好的交互設計其實是不需要新手引導的，如同微信一樣自然。

在一個普遍使用點觸操作習慣的年代，如何讓用戶體驗這種新的交互體驗方式？壓力就在新手教學上。學的會就用，學不會就丟棄。

嘗鮮體驗過後，以後也會（改變習慣）使用語音尋求業務，壓力則在業務設計上。方便就用，不方便就丟棄。

這是一個遞進邏輯。只有基本操作掌握了才有後面的（改變習慣）使用，把用戶當成小白的新手教學行為，一定得做好！

5. 全雙工交互表現

全雙工（Full Duplex）是通訊傳輸的一個術語。通信允許數據在兩個方向上同時傳輸。

先用通俗的例子比喻下：

單工：類似聽廣播——單向傳遞信息，一個人只能聽另一個人說。

半雙工：類似對講機。

甲：洞幺洞幺，能不能聽到我說話，over。

乙：可以聽到，over。

全雙工：類似打電話。

甲：喂，還記得我的聲音么？我是……

乙：啊，是你小子啊……

雙方可以各說各的，可以互相打斷。

人機交互追求更加自然流暢，這一點必不可少。

當前的語音助手，只有在進入監聽狀態才可以做出反饋。

而進入監聽的兩種情況，一種是使用[喚醒詞]，完成喚醒/打斷的動作。

另一種是AI判斷業務沒完，做出引導式的追問，然後進入監聽狀態。
例如：

用戶：我想看最近上映的電影。

助手：為你找到如下電影，你可以對我說看第幾部。播放完畢後進入監聽狀態。

其實助手第一時間在屏幕上展示了電影列表的搜索結果，但是總得把語音念完……。

作為用戶而言，我已經看到了助手給我的展示結果，也知道你的後續話術套路，我會迫不及待的使用[喚醒詞]，完成打斷行為……使用過的都會感受到這種情況的心累。

而在全雙工的能力加持下，即為，你播報你的，我說我的，不用等你念完，才進入監聽狀態，你念一半的時候，我搶話到下一步驟，你根據我的節奏推進業務就好。

還有一種技術方案相信從業者們也不陌生，就是基於當前語義場景下的「判斷為無效內容后的拒絕響應」。

例子：我想聽……嗯，我想想，哦對了，那個周杰倫的青花瓷

識別出用戶當前說的話是不是給它的指令，能過濾掉無效的停頓，語氣助詞等干擾信息，再做出反應。

這就是全雙工所指的「瞬間雙向」表現，更接近人與人之間的自然對話，提升了交互體驗。

6. 階段性結尾

同樣的，在【交互流暢】這個單元模塊，有更多評測點去列舉，但是受限於篇幅以及能力所限，刪掉的一些內容。保留以及刪除評測點的原則，也是基於評測指標的普適性。

同樣用提問的方式，列舉一下我刪除掉的考核點。

第（6）點，列舉一個我玩遊戲多多自走棋，體驗遊戲助手的例子。敏感詞，會在很多的地方出現。防止內容攻擊，保護安全的，特別是大公司，往往會用上一個敏感詞庫過濾處理，相信很多的人都遇見過，有些給你反饋，有些則直接給你和諧掉了。顯然是影響交互體驗流暢度的。造成這種情況的顯然是政策問題。

第（7）點，未來的交互體驗過程中，多硬體終端，多場景，有屏無屏的交互體驗方案，這是一個「現階段各家都沒做，而在未來各家一定會做」的評測點。

如果列舉其例子，問題以及探討解決方案起來，篇幅就過長了，就目前AI跨平台使用表現而言，故現階段捨棄。

第（8）點，完成任務時候的成本考量。這個裡面涉及一些語音識別、語義理解的層面。比如，任務流的多輪對話是分層次的，而當用戶一口氣給助手提供多個查詢槽位，能否給予結果。比如，在一些支付和驗證的層面，視覺和聲紋讓用戶付出的代價幾何等等。助手取硬體許可權（讀取GPS，讀取簡訊等）時的表現。

在滿足用戶需求的時候一定有方案，而不同方案之間的取捨考量就存在比較關係了。

筆者在設計業務的時候，同時也會考量用戶的隱私保護安全。

你要安全，就加判斷確認，加驗證，影響流暢度。
你要流暢，就替用戶配置更多的默認選項，影響安全。

「流暢」和「安全」本身就是一個互相衝突的命題。此處沒有對錯，只有選擇。

【交互流暢】是一個非常重要的全局性指標，貫穿【意圖理解】和【服務提供】始終。如果這個維度的評測方向如果處理不好，將全程傷害體驗。

以上，關於第三大維度【交互流暢】的諸多考量點，就此完結。後續文章會補充餘下的部分，並以相同的形式進行補充解釋和完善。

後續篇幅預告：【人格特質】——智能助手是否具備足夠的魅力/人格化特質，就情緒表現，情商，共情、個性化、擬人化程度來設計評測指標。

謝謝你看到了這裡，希望能給大家的工作帶來一些幫助和思考。

寫作這個事情，考量點真的太多，無法敞開了寫。可以在留言區評論或者添加作者微信公眾號深入討論。