上一篇文章(從「人工智能產業概況」到「CUI交互特徵」)中提到了人工智能概況，本篇則是開始從技術觀點著手，探討語意模型FSR以及用設計的觀點去理解INTENT中的Listen、Action、Replay代表的涵義。
前情提要完，以下為正文開始為逐字稿正文
目前 NLU算法常用的模型叫做框架語意模型（FSR）。他在做的是「填槽」的一個動作。比如說當一些「關鍵字詞」，我用「COSTA買咖啡」的案例來說明，用戶可能會在這個場景中有多種意圖，用戶可能會說「我要買杯咖啡」、「我要修改咖啡」、「我要刪除咖啡的訂單」，甚至是「我可能要支付訂單」這件事情。這邊都會牽扯到「填槽」，也就是咖啡的名稱、杯數、口味、冷熱。
但今天如果是換成「STARBUCKS買咖啡」，可能在意圖上是相同的，SLOT可能相同都是要買咖啡，可是知識圖譜（KNOWLAGE BASE）是不一樣的。例如咖啡名稱COSTA叫做酷樂冰、STARBUCKS叫做星冰樂。
例如用戶語料是「我要加美式、冰的、大杯加脫脂奶帶走」，人工智能經過ASR之後會先經過對話結構的斷句，人工智能會去撈關鍵字出來。當撈出來之後，我們就會判斷他會處在哪一個DOMAIN的INTENT裡面。我們就會知道說用戶要「添加咖啡訂單」，此時會對其他字詞進行「Session Structure Filling」並對SLOT進行填巢判斷，哪一個slot代表該ITEMS的屬性都會填好。
FSR這張表就像是我是店員幫用戶去填寫一份買咖啡的訂單，用戶的話進過機器的轉譯，基於技術語言的INTENT讓他背後代表一個可以被機器理解的涵義。
場景中的用戶需求叫做Intent（意圖），CUI也是這樣的，我們必須先了解用戶在這個場景中必須產生哪些意圖。正如同壽司之神小野二郎一樣，他用眼神觀察你的動作就知道你想做些什麼？你對於這道菜的喜好為何？
Intent就是所有CUI環節中的「重中之重」，剛剛的FSR技術語言可能對設計背景的人來說真的很難，我們不是技術背景可能不太懂。那麼設計師可以做什麼事情？
在語音交互的部分，設計師基本上在做的工作就是「LISTEN」、「ACTION」、「REPLAY」的LSR表對話編寫。
「LISTEN」是什麼？LISTEN就是我們如何去判斷、聽懂用戶要表達的東西。用戶要表達的內容要如何去對應到INTENT裡面。也就是所謂的一個泛化能力的處理。泛化能力的好與壞就是考慮設計師對於場景與用戶的熟悉度。
「ACTION」其實很簡單，就是這個INTENTS下用戶有些期待的結果，例如我們剛剛前面提到的買咖啡。機器對應到用戶所說的指令。
「REPLY」其實就是用戶期待獲得的反饋結果，你可以看到我繼續用買咖啡的例子，我在REPLY上面寫「確認一杯大杯冰美式，你今天還想喝點什麼？」、「你可以修改訂單或確認購買」。這兩句話對應起GUI來說，第一句就是在講導購，第二句我們就是引導用戶下一個ACTION是什麼？你可以做什麼樣的事情。
總結一下CUI，他不是一個蹦一下就跳出來的東西，他最早是從IVR（交互式语音应答，Interactive Voice Response）像是中華電信哪種客服服務而來，他是一個以「服務應用為主導」來告訴用戶你可做什麼樣動作的一個系統。但今天在CUI的領域裡有一個挑戰是「以用戶為主導」的服務應用去主導「語境」、「功能需求」該如何發生。所以當用戶喊了「你好，天貓精靈，我想做某某行為」時，系統會主動幫你完成。
CUI我們看到的東西都是很表象的對話，他其實背後的都在依靠我們對於場景的熟悉，我們對於對話的理解。因為在這裡地方他有很多東西是不顯性的，我也沒辦法告訴大家什麼是對的什麼是錯的，也沒辦法剛大家說那樣的設計是最好的。
Nathan總結之後馬上把麥克風交給冠芠，快速進行到多模態環節。
有沒有人知道「多模態」是什麼東西？在講多模態之前，我們先來講「多通道」，多通道的意思是人類的五感「視聽嗅未觸」。多模態是指一種表意方式包含「文字」、「圖像」、「聲音」、「影片」、「動作」等表意元素。
當各種技術不斷提升，人在場景內的交互方式已經不單純是用觸控的方式去處理，我們簡稱這種複雜的方式都叫做一種「多模態」的交互方式。我們今天工作坊主要是以「語音交互為主」然後去碰撞「其他交互方式」。一個良好的多模態體驗，就像是填寫交響樂的樂譜，設計師必須把很多不同聲部的樂器（交互動作），填寫到一個樂譜內，讓用戶在體驗的過程中感覺到書心自在，不會感受到很大的「心智負荷」。
用台灣捷運站的例子來說，當你在車廂內到每一站的時候，你會先吸收到文字站名這樣的語言視覺、燈效警示、甚至是在不同的路線上會有不同的到站音樂。這些都是在不影響用戶心智負荷的狀態去輔助你的指示。
但我們不禁要問，人真的可以一心多用嗎？當大量的訊息彼此堆疊的時候，對用戶來說會帶來更多的心智負荷。信息處理的步驟我簡單的來講就是「感知」>「認知」>「回應」。
用「禁止停車」的指示牌來說，我們先看到上面的文字還有顏色並透過你對於語言的理解，人們會知道他叫你在這裡不可以停車，接著具體給的回應就是你不會把車停在這邊。
故此，當我這邊將顏色與文字進行調整之後，人對於信息的處理是會出現矛盾的，要欺騙大腦是很簡單的一件事情。
在一個廚房場景來說，操作者的心智支援是有限的，他有可能要煮咖啡又同時要使用你的產品，以及同時間又要作一些料理的過程。設計者必須要考慮用戶能提供的心智支援有哪些，所以你產品在同時間中會給用戶的信息干擾必須要調整。
有一種可以調整心智負荷的方式就是增加「時間維度」，假如在機場要點咖啡，我們不會一口氣問用戶「多大杯」、「口味」、「甜度」、「冷熱」，而是一個問題一個問題去提問，減少他的心智負荷。在GUI上面會給用戶其他的指令引導，例如「我要買COSTA」、「我要買星巴克」、「我要換一批」。
舉機場這個例子主要是，因為用戶在機場通常會很著急想要搭機，所以我們不會一口氣攤開所有的信息，而是對他的信息等級進行篩檢。
如何設計一個多模態的語音交互，我再以一個郵輪的例子當作說明，一個郵輪的用戶旅程大概可能是「上船」、「放行李」、「靠港」、「下船」。我們將旅程拉出來進行各斷點的拆解，接著我們將客戶方蒐集而來的語料進行分析歸類「領域」（DOMAIN），並用時間框架、船上的位置框架進行劃分，接著再用專案的目的進行優先等級的判斷。
如果郵輪上面要擺放的語音問詢機，那麼船這麼大，最優先且理所當然應該解決的是船上各區域位置問題。如果你正在處理的是機場的案子，那麼娛樂領域的東西勢必會減少，因為你不希望大部分的人聚集在你的機器一直聽歌做群聚休閒的活動，而是希望大家來查找訊息，快速得到答案。
再以機場的語音查詢機來舉例，在做一台機器的時候我們會先圈出一個重點。那就是這台機器的主打重點是什麼？這背後你就有非常多的東西要進行考量。
第一是該品牌的宣傳策略是什麼？如果你有帶屏的話，你跟屏幕內的連動關係是如何？
第二是服務的優先級，如果你想要做一個公共問詢機，那麼勢必應該減少娛樂內容的產出量以及佔比，
第三則是必須考量機器放置的位置是在機場的哪裡，這台機器是否放置在客流熱區，抑或是中樞交會的地點。
第四則是硬體，你必須考慮到人機高度，該硬體的高度是否對人體高度很恰當。若該機器的商業目標是為了吸引小朋友來遊玩，那麼硬體勢必要對幼兒進行高度的調整。這台機器是否是單體抑或是模組化，是否可以方便拆卸維修。若你需要旁邊需要提供充電服務，則必須考慮是否要加上座位，要做幾個座位比較恰當，抑或是站立式不給坐。
第五則是服務功能，如你想要額外提供CHECK IN，攝像頭、掃碼、交易，等不同的行為，那麼你就必須想到是否要有GUI、VUI等方式讓用戶滿足需求，而這些需求又會對應到不同的交互方式。
接著正式進入到工作坊的部分，主講人分別給了現場八個組別進行選擇，分別有「飯店」、「辦公室」、「快餐店」、「遊樂園」、「家庭」、「機場」、「高鐵站」、「養老院」等八個場景。
接著在另外一張表中，主講人又給了另一個限制，希望在我們的場景勾選最多四種硬體設備，強迫我們思考用戶在該場景中最重要需求點為何。
由於我們組別選到了「遊樂園」的選項，很快的開始思考用戶在遊樂園的用戶旅程地圖，並用主講人提供的框架來思考用戶在每個流程中的「意圖/Intent」。在這張圖中的垂直軸很特別，分別有「位置性質」、「時間性質」、「權益性質」、「服務需求」、「信息查詢」、「休息及其他」等維度，故我們小組員發想出的意圖便利貼就可以在垂直項的維度分類，讓我自己理解哪些意圖的優先等級對用戶來說是重要。
時光匆匆，組員們很快的就把最小流程的搭建好，也把我們的想像中的機器畫了草圖，工作坊上半場很快的就結束。休息片刻之後，Nathan馬上就跟大家講解在撰寫「LAR表」中會出現的幾個相關問題，以及語音交互如何作測試的方法。
