LUIS關鍵項目(entities)的設計

在前一篇文章中針對LUIS的運用可以理解到意圖及關鍵項目(entities)的設計,是整個語意理解精準度的關鍵,一個LUIS App 目前最多可以定義 30個關鍵項目(entities),所以接下來我們來看看在LUIS裡針對自訂義關鍵項目(custom entities)的幾種設計方式。

Simple
最一般性簡單通用性質的,這種類型的值通常是個簡單概念的描述,例如:飲料、地點。

Hierarchical
具有父子階層繼承關係性質的,例如『我要一個滿福堡』,我們可以建立一個【漢堡】的entities,類型是Hierarchical,子階層則有【滿福堡】、【雙層牛肉堡】、【香辣雞腿堡】,不管是哪一種,它都是【漢堡】這個entities的一種。

Composite
複合式的設計,可以把多個不相關的entities,組合成一個複合式entities,例如『2張到台北的商務艙高鐵票』,這個句子中包含有【數量】【地點】【高鐵票種】,如果想定義成一個【高鐵訂單】的entities,那麼就可以把【數量】【地點】【高鐵票種】這3個彼此獨立的entities,進一步組合成【高鐵訂單】的entities,這種類型的設計與Hierarchical最大的不同是,子項目的entities彼此間是獨立的,此外要組合成Composite的entities只能是simple 或 hierarchical類型的entities。

List
相似詞(同義字)的設計,將意思相同的詞定義成統一的entities,例如:台大、台灣大學都是指向【台大】,美金、美圓、美鈔都是指向【美金】。

 

那麼entities應該採用哪一種類型設計比較好呢?個人的看法是沒有絕對,端看你的應用,例如我希望LUIS可以回饋給我訂單的細項entities以及識別出它是一張訂單entities,那也許你需要採取的是Composite類型,但如果我只是希望LUIS可以回饋給我對話語句中的地點entities,那麼定義一個Simple類型就可以滿足你的需求。

 

 

若本文對您有所幫助,歡迎轉貼,但請在加註【轉貼】及來源出處,並在附上本篇的超連結,感恩您的配合囉。

By No.18