搜狐 發表於 2019-10-25 10:47:36
人工智慧的發展走過了從機器智能到感知智能的階段，正在邁向認知智能的階段。然而由於人類複雜的語言系統，一問一答形式的人機互動已經滿足不了用戶的真實需求，機器必須學會處理人類複雜的語言。
隨著語音識別、NLP等技術的成熟，多輪對話交互系統將成為人機互動的重要紐帶和橋梁。
目前市場上人機對話交互主要分為三種類型：任務型、問答型、閒聊型。
任務型主要目的就是根據用戶描述的問題，收集必要的參數信息以完成用戶的任務；問答型主要通過模型的解析，匹配知識庫的答案並提供給用戶；閒聊型主要以調節情緒，在用戶當下的使用場景，以貼近用戶情感為目的，拉近用戶的距離。
人機對話交互中，機器處理自然語言時需要用到不同的語義表達形式來處理。主要有分布式語義、框架式語義、模型式語義。
01 分布式語義
可以簡單的理解為相似句模型解析。分布式語義需要標註大量的訓練數據，大量的知識點會形成一個向量空間。當用戶問題過來時，機器先將用戶的問句進行分詞，根據分詞結果匹配詞庫，也可以將語義理解成向量，機器根據空間向量分布判斷給出最優解。
日常在進行模型調優時，我們主要從數據和算法兩個方面進行調優，再根據模型的正確率和召回率，找到最優的f值，給定模型的閾值。
目前大量的機器學習都用的是分布式語義，依靠數據來處理語義間的關係，但分布語義理解比較淺，很難處理深層的語義。
02 框架式語義
現在市場上有很多的語音助手產品，通過獲取用戶問題中的關鍵參數，然後將參數填入協議中，完成用戶的任務操作。
例如「查一下7月1日上海到洛杉磯的航班」，這句話中我們需要獲取到用戶的四個信息槽位：
首先我們明確用戶的場景，用戶是想查飛機的航班信息，所以結果裡肯定不能出現汽車、火車等場景；
「7月1日」對應的肯定是時間的參數time，所以查詢的結果裡肯定是7月1日當天的一個航班信息；
用戶的出發地是上海，目的地是洛杉磯，分別對應參數裡的origin、destination，所以這邊兩個參數不能顛倒，不然查詢的結果就不是用戶真實想要的信息了。
可以看到框架式語義最重要的就是要識別語義中的參數信息，缺一個都不能完成用戶的真實需求。所以在框架式語義中，框架識別和參數識別是非常重要的。
但用框架語義處理一些指代詞等高級的語言或需要結合上下文理解的時候，會因為缺少某一個槽位，而丟失用戶信息，所以現在很多框架語義配置時用了「平行槽位」。
首先明確在某一場景下，我們需要獲取哪些槽位信息，當配置了平行槽位後，用戶語義中缺少哪一個槽位信息，通過配置追問話術，將槽位信息補全，以完成用戶的最終目的。
03 規則式語義
規則式語義就是將用戶問句通過表達式的形式進行匹配，當滿足規則要求時，給出結果回復。
要讓用戶問句能通過規則匹配問題，首先要明確走規則匹配邏輯要優先於相似句匹配。規則也需要獲取問句中的實體信息，滿足要求後，即可匹配上。
下面就舉一個例子：
我們看這條規則由 {} 。 & | ： # 等標點符號，也有欄位等信息組成的一條規則。看這規則會覺得比較亂，但細細分析，其實還是很簡單的一條規則。
首先明確這個規則的意圖，是一個打開動作，說明是一個指令。後面需要填寫的槽位信息就是A股、港股、美股的槽位信息、最後一個就是欄目。所以可以確定這條規則就是一個「打開某隻股票的個股資料」。
因為每個標點代表的意思是不同的，這就不細細說明了。所以當用戶問句滿足這個規則要求，就滿足了這個規則對應的標準句，那用戶就能得到該標準句對應的答案了。
不同的語義處理形式邏輯都不同，但最終的目的還是為了能完成用戶下達的任務或操作。隨著分詞技術、實體抽取、NLU等技術的成熟，人機互動會更加和諧，處理效率會越來越高。
來源：搜狐
打開APP閱讀更多精彩內容聲明：本文內容及配圖由入駐作者撰寫或者入駐合作網站授權轉載。文章觀點僅代表作者本人，不代表電子發燒友網立場。文章及其配圖僅供工程師學習之用，如有內容圖片侵權或者其他問題，請聯繫本站作侵刪。 侵權投訴