“奧卡姆剃刀原則”體現在Bot設計上，是同一個功能，從三個維度都可以去完成，甚至不同維度也有不同的子方式，但哪種方式最為簡潔，這才是真正尤為重要的一點，而不是僅僅局限于完成這個功能本身。

一、Bot框架本質

搭建NLU語義解析框架，在上篇文章中我我已經提到，它作為最開始頂層設計的基本解析框架，是整個Bot產品的基石。

在系統上，會影響到整個框架的是否足夠簡潔，意圖內的多輪或跨意圖多輪的可實現與否，場景中每個意圖觸發的邊界（拋開模型泛化的意圖句式不談）等等。

我之前將這個搭建NLU語義解析框架的本質，定義為從“用戶語音需求”、“服務”和“NLU語義技術”三個維度，去尋找“最優解”集合的問題。但這這個感覺是從上帝視角，對他們結構性的一種描述。

但具體在去做每個Domain的時候作為Bot的產品，定位就不在是一種俯瞰的上帝視角，而是作為“NLU語義”這個圈本身定位這個感覺。

從這個角度出發，Bot產品在實際工作中，起到的更像是一種“連接”的作用，將用戶的語音中的要素識別并抽取出來，通過Bot產品，精準連接到對應的服務細節，然后再返回給用戶結果，完成這個從語音輸入到語音輸出的產品閉環設計。

二、Bot框架初步探究

接下來結合我最近的思考和實踐，在Bot基本框架上，我嘗試去回答下面這三個問題：

1. 對每個Bot場景的框架來說，一個極為重要的評價標準
2. 什么因素，是我們在最初設計Bot解析框架時，所不需要考慮。（注意，這里是不需要考慮的）
3. 簡化框架，采取怎樣的操作方式更加合理

先附上一個基本框架形式，方便之后的論述：

還有必要聲明一點：下面的所有思考，都將暫時拋去模型訓練對意圖語料的影響。并不是因為它對于語音交互來說不重要，相反基于算法的語料訓練的越好，每個場景不同意圖的句式的精準性和泛化性會同步提高。

只不過Bot產品設計在這個層面上，起到的作用不會很大，這部分的工作都是“模型訓練師”（算法工程師）去通過線上大量Query數據和標注語料去訓練，實現意圖句式的泛化。

產品在設計Bot框架時，意圖句式的泛化應該是在整個框架搭建好，邏輯走通以后的最后一步，對于產品設計來說并非最重要的影響要素。

2.1框架的簡潔性

我個人評價一個Bot框架的標準，是在可以滿足該場景所有功能情況下，它的簡潔性。以最常見的“查天氣”這個場景為例，要實現它很容易，可以通過多種框架形式去實現。

比如可以有三個意圖“search_weather”（普通天氣查詢）、“search_tem”（普通溫度查詢）和“search_con”（查詢天氣指數）去搭建Bot框架，這也是亞馬遜這個Domain的做法，通過這三個意圖實現天氣功能。

但如果是涉及到更多服務參數的場景，比如車載場景，服務參數并不會像天氣那么少，那么意圖可能就會隨著增加，而意圖的增加，對于整個框架來講，它的簡潔性必然是下降的。

與此同時會帶來另外一個在現象上更嚴重的問題：在“多輪對話”模塊，過多的意圖會導致多輪配置的復雜度大幅提升，搞起來非常痛苦，同時后期Bot框架的維護成本非常高。這無論對于產品還是技術來講，都會影響該場景下的可拓展性。

所以，我將在滿足功能下一個Bot框架的簡潔性視為評價一個框架，最為重要的指標。當然它有一個前提假設，就是能夠實現該場景下所有的意圖和功能，不能陷入單純為了形式上的簡化而簡化。

2.2探究一個功能的三個路徑

接下來我會通過實驗，去驗證并嘗試回答第二個問題：即什么因素，在進行Bot框架頂層設計的時候，不需要考慮的因素（至于為什么是不需要考慮的，最后會提及到）。在此提出三個假設，稍后會進行驗證：

1. 用戶在現象層面的“意圖”，對單間搭建Bot框架的影響
2. 用戶同一個“現象意圖”的不同類型表達句式對Bot框架的影響
3. 整個場景內，服務參數的多少對Bot框架的影響

下面以天氣場景為例，如果要實現“查詢溫度”和“查詢空氣質量”這兩個功能，基于當前的Bot框架實現方式，在邏輯上有以下三種：

1. 通過兩個Intent進行劃分，即“查詢溫度”意圖和“查詢空氣質量”意圖
2. 通過兩個slots進行劃分，即“溫度”槽位和“空氣質量”槽位
3. 通過同一個slots中，兩個Value進行劃分，進“溫度”值和“空氣質量”值

2.2.1 Intent維度

如果在Intent層面去劃分，那么整個框架已經明顯：兩個意圖（溫度、空氣質量），兩個槽位（城市、日期），其中的典型句式，舉個例子如下：

• Intent（溫度）：{city}{date}溫度【是多少】
• Intent（空氣質量）：{city}{date}空氣【好不好】

這樣的兩個句式，是可以觸發對應的意圖，沒錯吧。注意【】括起來的詞，表示屬于“意圖非必要要素”，而中間的“溫度”和“空氣”則為“意圖必要要素”（你起碼得有溫度這倆字的，沒毛?。?，也符合我之前對一個句子四種要素的基本構成。

那么這樣的操作方式，是可以明確觸發“查詢溫度”和“查詢空氣質量”這兩個用戶意圖，同時通過后續配置槽位策略去請求到對應的服務。

好，這個操作是可以滿足功能的，我們先放在這里不管他了。

2.2.2 slots維度

如果選擇在slots這個維度去劃分映射關系的話，那先假設溫度為{tem}，空氣質量為{AQI}兩個槽位，其中的典型句式，會是這樣的：

Intent：

• {city}{date}{tem}【是多少】
• {city}{date}{AQI}【好不好】

這樣配置好的兩個句式，用戶在發出Query之后，觸發的是同一個意圖，但因為槽位的性質不同，所以可以抽取出不同的實體，去進行后續的服務請求和回復話術配置，到這里好像沒毛病。這樣的句式可以觸發意圖，觸發意圖后也能請求到對應的服務。

（1）一個槽位一個值？

But，這樣的方式可能會產生一個疑問：像{city}或{date}這樣的槽位，他們內部都是包含大量信息的，而這樣的處理方式，每個槽里面只包含一個信息，即“溫度”或“空氣質量”（頂多再會加上一些同義詞），直覺上會很奇怪，它好像并不符合我們對“槽位”這個概念的基本認知。

這恰恰是需要警惕的一點：如果糾結于“槽位”本身，并且是通過觀察當前普遍認同的槽位設定，比如常見的“地點”、“時間”、“歌手”、“出發地”等，這也是當前幾乎所有能找到得科普文章或網站上的介紹形式。

會非常容易陷入一個誤區，你得到的槽位的基本認知，是通過現象層面已經被解決問題的歸納而得出的，那么結論也僅僅是停留在現象層面的認知和結論。你應該思考的是去溯源，思考為什么會有“槽位”這個東西存在，它對于整個Bot產品來說，定位在哪里，槽位在本質上是為了解決一個什么的問題而誕生，而這個問題又為什么存在。

我想強調得是“槽位”只是基于以上思考，在最后一步推導出的一個現象層面上“解”的自然表現，而表現是可以浮動的，卻非本質上的“不動因”。

這個問題在這里就不展開了，可能需要單獨講，先拋出一個結論性的觀點：槽位是可以只包含一個信息點的，并且在某些情況下，也只能通過這樣的存在形式，才可以完成某些場景的意圖上的功能。

（2）系統影響

真正的影響，是要從系統思維的角度出發，看看這樣的方式，對整個Bot后續其他模塊的影響是怎樣的。

在多輪上的問題，上文已經說了多輪分為意圖內和跨意圖。意圖內的多輪，其本質就是該意圖內槽位的“改變”（增、換、否的）。試想一下這樣的槽位處理方式，如果用戶第一輪Query“北京今天溫度”，第二句“那空氣質量呢”。

首先，這個功能從Bot多輪的角度來講，是必須要支持的，用戶第二句的意圖非常明顯是“北京今天空氣質量”。那么此時DST在追蹤到上一輪的Query意圖的輸出語境，并且本輪Query句式所觸發的意圖，對應的輸入上文語境剛好一致的時候（其實是同一個意圖，簡單理解，就是它自個），它會把{city}{date}{tem}全部繼承下來，又因為{AQI}在上一輪沒有，屬于新增槽位要加上，這時候組合成的第二輪意圖：{city}{date}{tem}{AQI}

到此，就會出現問題，你到底是要干嘛？是要查溫度，還是要查空氣質量。如果在天氣這個場景，“查溫度”與“查空氣質量”是分開的話，那么到這里，系統就不知道要請求什么了。

所以在每個場景框架的建立之初，一定要時刻保持對整個Bot系統思維的意識。

因為很多種方式和路徑，都能完成同樣的功能，但不同方式對整個系統和其他模塊帶來的影響是不一樣的，如果在頂層設計的時候不考慮清楚，就會帶來后續的某些功能不能實現，或是實現的方式更加復雜。

2.2.3value維度劃分

Value維度進行劃分，有兩種形式：

• 一種是僅僅把“溫度”和“空氣質量/空氣”作為固定的Value值，就好像“北京/北京市”作為{city}槽位里的一個固定值一樣。這樣操作的本質是，將該句式“意圖必要要素”作為槽位中的一個值；
• 第二種方式，則是將整個“意圖要素”（必要與非必要全部包含），都作為Value值做歸一化的處理，同時他們共屬于一個槽位，我假定這個槽位為{condition}，那么將會出現下面的兩種不同配置方式

第一種配置方式（句式、槽位詞表圖）：

第二種配置方式（句式、槽位詞表圖）：

（1）第一種Value化缺陷

先來看第一種方式，可以看到它為了滿足用戶后綴里“是多少”和“好不好”這兩種問法，就必須要有兩種句式去配置（這并不是大問題）。

但是由于“溫度”和“空氣質量”屬于同一個槽位的兩個值，也就是{condition}中出現任意一個，這兩個句式都能觸發該Intent，這就會導致一個現象層面的問題：即Query為“北京今天溫度好不好”和“北京今天空氣是多少”也能觸發該意圖，雖然這可能不會造成多大負面影響，但它還是破壞了意圖句式的準確度。

但為什么會導致這樣的現象呢？可以通過意圖要素去解釋?！皽囟仁嵌嗌佟边@句Query屬于溫度意圖要素，“空氣好不好”屬于空氣質量意圖要素，本來他們的邊界是完全不在一起的（如下圖）。

但我們基于簡化框架的目的，把這兩個要素中的“意圖必要要素”分別抽取出來，作為同一個槽位中的值，但同時為了要滿足用戶更多Query的問法，就要在句式中增添“非必要意圖信息”（即上文的“好不好”和“是多少”），這樣的做法最終導致兩個意圖的邊界出現了混亂。所以這樣的Value化操作方式，本質上是在“精簡框架”和“Cover用戶更多句式”之間去做出取舍。

不過綜上來看，它的效果并好，這還僅僅是最為簡單場景的兩類Query而已，如果是更復雜的場景，用戶的表達句式更加復雜，那這樣的做法所暴露的缺陷是極為明顯的

（2）第一種Value化優勢

對比上面，在觀察第二種Value化的操作方式，可以看到的優勢就很明顯：

1. 簡潔
2. 所有“意圖要素”在槽位詞表的層面采用相同方式處理，而不是在句式層面。本質上不會導致“意圖要素”發生邊界混亂，也就不會出現說“溫度好不好”這樣奇怪的Query，卻仍能觸發意圖的的問題。
3. 后續的可拓展性、維護成本低。在此基礎上優化迭代新的功能，或是發生一些比較緊急的Case，只需要在整個框架中處于在外一層的“槽位詞表”維度去修改，而不用涉及到框架性、意圖層面的改變。

3.反過來想，影響簡潔性的不是什么因素

通過上面的實驗，我想第二個問題中的三個假設，應該可以得到自然的驗證。

第一個假設：用戶的“現象意圖”，是否要能成為影響Bot框架核心因素？

答案是：“否”。

用戶在現象層面的意圖，并不能作為你構建Bot框架時的核心思考因素。通過上面天氣場景的例子已經證明，用戶在現象層面上的兩個意圖，在Bot框架中，可以在邏輯上從intent/slots/value三個維度轉化。用戶意圖，不能代表Bot意圖。

第二個假設：用戶同一個“現象意圖”的不同類型表達句式，是否能成為影響Bot框架核心因素？

答案是：“否”。

如果連“用戶意圖”本身都不能作為核心因素，那么它更上一層的句式層面的泛化說法，又怎么可能成為核心因素；從技術上講，這也只是用戶說法通過模型泛化的問題。

第三個假設：整個場景內的“服務參數”多少，是否作能成為影響Bot框架核心因素？

答案還是不能。

因為即時要服務的參數再多，在Bot中也可以在Value層面去處理。這個在Bot中最極端的體現，就是“槽位值”這個概念，歌手足夠多吧，但一個{singer}詞典，就全部解決啦。

那么在請求類的服務中，邏輯也是一致的，即使要請求的服務參數再多（任何服務場景），也是同樣的思路去解決，所以“服務參數”數量，也不能成為影響Bot框架核心因素。

4.奧卡姆剃刀原則

上面的簡單實驗，回答了最開始提出的三個問題，同時加上自己最近的一些實踐。目前至少找到在做Bot設計時非常重要的原則，奧卡姆剃刀原則：

如無必要，勿增實體。

這個原則的思想是同樣可以做好的事情，用較少的東西去做，切勿浪費較多東西去做，也被稱為“簡單有效原理”。

體現在Bot設計上，同一個功能，從三個維度都可以去完成，甚至不同維度也有不同的子方式，但哪種方式最為簡潔，這才是真正尤為重要的一點，而不是僅僅局限于完成這個功能本身，“兩點之間線段最短”，這是公理。

如果這個場景比較簡單，涉及到功能不多，可能哪種采取方式并不會有太大影響?？杉僭O要做的東西比較重度，或者說在初版之后要進行更豐富的拓展，那么在設計之初，讓整個框架保持最大程度可能性的簡潔，是十分必要的一點。

“奧卡姆剃刀原則”，也成為我在Bot產品設計時核心思想，最近在實踐中重構天氣場景，也嘗試完成了只用兩個意圖（不包含用于承接多輪的重名意圖），去Cover住天氣場景的所有功能，算是理論結合實際，完成了一小步。

5.Bot產品感受

在文章的最后，更想談一些自己的感受，我想表達的是上面所有的論述都是極其膚淺和缺乏根基的。它有兩個非常嚴重的缺陷，這個缺陷倒不是說這個上面的內容或觀點存在過大偏差（當然也是存在的），而是我的這些思考以及得出結論本身的思考方式本身存在缺陷。

• 其一，本質上只是通過自己在實踐中的經驗，用歸納法去從現象層面得出一些因果關系上的東西，然后得出一些原則或思想，雖然并不能說他們不對，但這樣的方式缺乏更為底層的“根基”（不知道能不能感受到我所說的這個味道）。
• 其二，過于片面，這是我自己都能明顯感受到的，做過這些東西歸納出這一方面的思考，做過那些東西就得出另外一些方面的思考。這樣下去整個體系會變得越來越復雜，但也越來越容易流與現象的流變，而很難縱向深挖出更為底層和基礎的東西。

所以最近也開始在思考尋找Bot框架設計中的第一性原理，從那個最底層的“第一因”出發，這個“第一因”一定是抽象的，且可能跟Bot本身無關，然后用演繹法去推導Bot框架設計的理論，將底層邏輯導通。

我的第二個感受是：就“現象問題”去解決“現象問題”一定是做Bot產品（或者說任何產品都是如此吧）的大坑，但Bot對話產品表現的更為明顯，畢竟人的對話場景或人的Query形式有點不可窮盡的意思哦。

場景會越來越多，每種場景所表現出來的形式也不盡相同，也就是說現象層面上的東西永遠是流變的。同時技術也在不斷向前演化，說不定哪天有了新的技術突破，做Bot的方式方法就會發生改變。

但一定也會有那個最為本質和底層的點，是所有Bot產品共有的底層的“第一因”（第一性原理）。只要NLU底層語義技術，不突破目前基于統計模型理論的機器/深度學習方式；只要人的說話方式和習慣不改變，它也一定不會改變的那個基石元素找到，才可以。

本文由 @free 原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自 Unsplash ，基于 CC0 協議