如何評測語音技能的智能程度之交互流暢
當用戶發起需求后，【意圖理解】在前，【服務提供】在后，基本上已經構成了一輪完整閉環。
之所以把【交互流暢】這個點作為一個單獨維度拆解出來，是因為其貫穿始終。如果這個模塊的內容如果處理不好，將全程傷害體驗。
本篇文章為大家帶來【交互流暢】維度的評測點拆解。
這個模塊，重點考量智能助手各個性能指標及交互體驗層面的表現。
【交互流暢】(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，讀取短信等)時的表現。
在滿足用戶需求的時候一定有方案，而不同方案之間的取舍考量就存在比較關系了。
筆者在設計業務的時候，同時也會考量用戶的隱私保護安全。
你要安全，就加判斷確認，加驗證，影響流暢度。
你要流暢，就替用戶配置更多的默認選項，影響安全。
“流暢”和“安全”本身就是一個互相沖突的命題。此處沒有對錯，只有選擇。
【交互流暢】是一個非常重要的全局性指標，貫穿【意圖理解】和【服務提供】始終。如果這個維度的評測方向如果處理不好，將全程傷害體驗。
以上，關于第三大維度【交互流暢】的諸多考量點，就此完結。
