在前一篇文章中針對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