|
聊天機(jī)器人的三個(gè)基本部分 一個(gè)聊天機(jī)器人，有三個(gè)基本部分： 輸入輸出：用來(lái)接受、理解用戶(hù)問(wèn)題，并生成、返回答案給用戶(hù)。 對(duì)話控制：用來(lái)構(gòu)建雙向的關(guān)系。 i）用戶(hù)問(wèn)題=>知識(shí)庫(kù)知識(shí) ii）知識(shí)庫(kù)知識(shí)=>機(jī)器人答案 知識(shí)庫(kù)：用于回答用戶(hù)問(wèn)題的知識(shí)的集合。
NOTE：如上的三個(gè)部分是從功能角度的分析，并不是說(shuō)一個(gè)Chatbot必須要有與之一一對(duì)應(yīng)的模塊或分層。 聊天機(jī)器人的實(shí)現(xiàn)技術(shù) 從學(xué)術(shù)研究的角度講，聊天機(jī)器人所需技術(shù)涉及到自然語(yǔ)言處理、文本挖掘、知識(shí)圖譜等眾多領(lǐng)域。 在當(dāng)前的研究中，大量機(jī)器學(xué)習(xí)、深度學(xué)習(xí)技術(shù)被引入。各種炫酷的算法模型跑在Google、微軟等IT寡頭的高質(zhì)量數(shù)據(jù)上，得到了頗多激動(dòng)人心的研究成果。 但具體到實(shí)踐當(dāng)中，在沒(méi)有那么巨量的人工標(biāo)注數(shù)據(jù)和大規(guī)模計(jì)算資源的情況下，于有限范圍（scope）內(nèi)，開(kāi)發(fā)一款真正有用的機(jī)器人，更多需要關(guān)注的往往不是高深的算法和強(qiáng)健的模型，而是工程細(xì)節(jié)和用戶(hù)體驗(yàn)。 此處，我們只是簡(jiǎn)單介紹幾種當(dāng)前實(shí)踐中最常用，且相對(duì)簡(jiǎn)單的方法： Solution-1： 用戶(hù)問(wèn)題->標(biāo)準(zhǔn)問(wèn)題->答案 知識(shí)庫(kù)中存儲(chǔ)的是一對(duì)對(duì)的“問(wèn)題-答案”對(duì)（QA Pair）。這些Pair可以是人工構(gòu)建的，源于專(zhuān)家系統(tǒng)或者舊有知識(shí)庫(kù)的，也可以是從互聯(lián)網(wǎng)上爬取下來(lái)的。 現(xiàn)在互聯(lián)網(wǎng)資源這么豐富，各種網(wǎng)頁(yè)上到處都是FAQ，Q&A，直接爬下來(lái)就可以導(dǎo)入知識(shí)庫(kù)。以很小的代價(jià)就能讓機(jī)器人上知天文下曉地理。 當(dāng)用戶(hù)輸入問(wèn)題后，將其和知識(shí)庫(kù)現(xiàn)有的標(biāo)準(zhǔn)問(wèn)題進(jìn)行一一比對(duì)，尋找與用戶(hù)問(wèn)題最相近的標(biāo)準(zhǔn)問(wèn)題，然后將該問(wèn)題組對(duì)的答案返回給用戶(hù)。 其中，用戶(hù)問(wèn)題->標(biāo)準(zhǔn)問(wèn)題的匹配方法可以是關(guān)鍵詞匹配（包括正則表達(dá)式匹配）；也可以是先將用戶(hù)問(wèn)題和標(biāo)準(zhǔn)問(wèn)題都轉(zhuǎn)化為向量，再計(jì)算兩者之間的距離（余弦距離、歐氏距離、交叉熵、Jaccard距離等），找到距離最近且距離值低于預(yù)設(shè)閾值的那個(gè)標(biāo)準(zhǔn)問(wèn)題，作為查找結(jié)果。 但關(guān)鍵字匹配覆蓋面太小。距離計(jì)算的話，在實(shí)踐中比對(duì)出來(lái)的最近距離的兩句話，可能在語(yǔ)義上毫無(wú)關(guān)聯(lián)，甚至滿擰（比如一個(gè)比另一個(gè)多了一個(gè)否定詞）。另外，確認(rèn)相似度的閾值也很難有一個(gè)通用的有效方法，很多時(shí)候都是開(kāi)發(fā)者自己拍腦袋定的。 因此，這種方案，很難達(dá)到高質(zhì)高效。 Solution-2. 用戶(hù)問(wèn)題->答案 知識(shí)庫(kù)中存儲(chǔ)的不是問(wèn)題-答案對(duì)，而僅存儲(chǔ)答案（文檔）。 當(dāng)接收到用戶(hù)問(wèn)題后，直接拿問(wèn)題去和知識(shí)庫(kù)中的一篇篇文檔比對(duì)，找到在內(nèi)容上關(guān)聯(lián)最緊密的那篇，作為答案返回給用戶(hù)。 這種方法維護(hù)知識(shí)庫(kù)的成本更小，但相對(duì)于Solution-1，準(zhǔn)確度更低。 Solution-3. 用戶(hù)問(wèn)題->語(yǔ)義理解->知識(shí)庫(kù)查詢(xún)->查詢(xún)結(jié)果生成答案 從用戶(hù)的問(wèn)題當(dāng)中識(shí)別出用戶(hù)的意圖，并抽取這個(gè)意圖針對(duì)的實(shí)體。 相應(yīng)的，知識(shí)庫(kù)內(nèi)存儲(chǔ)的知識(shí)，可以按照二維表的方式組織（類(lèi)比關(guān)系數(shù)據(jù)庫(kù)中的table）。 Chatbot在提取了意圖和實(shí)體后，構(gòu)造出對(duì)知識(shí)庫(kù)的查詢(xún)（Query），實(shí)施查詢(xún)，得出結(jié)果后生成回答，回復(fù)給用戶(hù)。 我們下面講的框架，就是基于本方案的。 極簡(jiǎn)版聊天機(jī)器人架構(gòu) 在此，給出一個(gè)極簡(jiǎn)版Chatbot實(shí)現(xiàn)方案，幫助你在一天的時(shí)間內(nèi)，開(kāi)發(fā)一款問(wèn)題解決型聊天機(jī)器人。 下圖是這款機(jī)器人的架構(gòu)：
最左側(cè)的語(yǔ)言理解（Language Understanding）模塊，和右上的回復(fù)生成器（ResponseGenerator）加起來(lái)對(duì)應(yīng)的圖-1中的是I/O部分。 正中的對(duì)話管理器（Dialog Manager）和上下文存儲(chǔ)（Context Store）屬于圖-1里的中控部分。 最下方是知識(shí)庫(kù)。 語(yǔ)言理解 怎么能夠從用戶(hù)的提問(wèn)當(dāng)中發(fā)現(xiàn)意圖和實(shí)體呢？ 最簡(jiǎn)單的是基于規(guī)則的方法：用關(guān)鍵字/正則表達(dá)式匹配的方式，來(lái)發(fā)現(xiàn)自然語(yǔ)言中的意圖和實(shí)體。 GET_INPUT IF "有（.+）嗎" inUser_Input Intent = “商品推薦” ELIF "（郵費(fèi)|郵資|運(yùn)費(fèi)|快遞費(fèi)）+" inUser_Input Intent = “查詢(xún)郵費(fèi)” ELIF "（保修|維修|修理|售后）+" inUser_Input Intent = “查詢(xún)售后” … … FOREACH（Color in Colors） IF （Color inUser_Input） Entity.Type = “ProductColor” Entity.Value = Color … … 這樣做的優(yōu)點(diǎn)顯而易見(jiàn)：方便、直接。 缺點(diǎn)也很明顯：缺乏泛化能力。 一件事有很多種說(shuō)法的時(shí)候，需要開(kāi)發(fā)者將所有這些說(shuō)法都手動(dòng)添加到白名單里。 這樣不僅很難面面俱到，而且，還會(huì)碰到不能夠靠匹配關(guān)鍵詞解決的問(wèn)題。比如，有人問(wèn)“郵費(fèi)能給免了嗎”，有人問(wèn)“這個(gè)商品郵費(fèi)多少錢(qián)？”,這根本是兩個(gè)意思，如果都有“郵費(fèi)”匹配，給同一個(gè)答案，就答非所問(wèn)了。 這個(gè)時(shí)候，就需要引入基于模型的方法：使用機(jī)器學(xué)習(xí)模型來(lái)進(jìn)行意圖識(shí)別和實(shí)體抽取。 基于模型的語(yǔ)言理解包含兩個(gè)子任務(wù)： 意圖識(shí)別(intentionclassification)：用來(lái)識(shí)別用戶(hù)所提問(wèn)題的意圖，也就是用戶(hù)希望做一件什么事。 實(shí)體抽取(entityextraction)：用于提取用戶(hù)對(duì)話中所提供的和意圖相關(guān)的參數(shù)(實(shí)體)，例如時(shí)間、地點(diǎn)等。 具體某個(gè)Chatbot的意圖類(lèi)型和實(shí)體類(lèi)型，是其開(kāi)發(fā)者自己定義的。例如小明的客服機(jī)器人可以如此定義： Case1：發(fā)到北京的貨包郵嗎？—— 意圖：查詢(xún)包郵；目的地實(shí)體：北京 Case2：00183號(hào)商品快遞到伊犁郵費(fèi)多少？—— 意圖：查詢(xún)郵費(fèi)；目的地實(shí)體：伊犁，商品Id實(shí)體：00183 Case3：02465號(hào)商品有保修嗎？——意圖：保修查詢(xún)；商品Id實(shí)體：02465 引用-2-1 或者，換個(gè)定義意圖和實(shí)體的方式，也沒(méi)有問(wèn)題： Case2’：00183號(hào)商品快遞到伊犁郵費(fèi)多少？—— 意圖：商品查詢(xún)；目的地實(shí)體：伊犁，商品Id實(shí)體：00183，商品屬性實(shí)體：郵費(fèi) Case3’：02465號(hào)商品有保修嗎？——意圖：商品查詢(xún)；商品Id實(shí)體：02465，商品屬性實(shí)體：保修 引用-2-2 一般來(lái)說(shuō)，意圖識(shí)別是一個(gè)典型的分類(lèi)模型(e.g. Logistic Regression，Decision Tree等)，而實(shí)體抽取則是一個(gè)Sequence-to-Sequence判別模型（一般選用Conditional Random Field）。 語(yǔ)義理解模塊當(dāng)然可以自己開(kāi)發(fā)。不過(guò)，這需要長(zhǎng)期積累的自然語(yǔ)言處理(NLP)的專(zhuān)業(yè)知識(shí)和經(jīng)驗(yàn)，高效的運(yùn)算框架，以及標(biāo)注工具的支持。 作為輕量級(jí)Bot的開(kāi)發(fā)者，單獨(dú)開(kāi)發(fā)一個(gè)語(yǔ)言理解模塊耗時(shí)耗力，效果還未必好。不如選用現(xiàn)成工具。在附錄中我們會(huì)介紹一款微軟對(duì)外發(fā)布的在線語(yǔ)言理解工具：LUIS。可以很方便的實(shí)現(xiàn)上述功能。 知識(shí)庫(kù)查詢(xún)和結(jié)果返回 知識(shí)庫(kù)用于存儲(chǔ)知識(shí)，本身可以是各種形式：數(shù)據(jù)庫(kù)，API，或者文本文件等。 用戶(hù)的問(wèn)題經(jīng)過(guò)語(yǔ)言理解，被提取成了意圖和若干實(shí)體。下面要做的是，針對(duì)不同的知識(shí)庫(kù)類(lèi)型，將意圖和實(shí)體構(gòu)造成對(duì)應(yīng)的查詢(xún)。下表中幾種情況比較常用： 知識(shí)庫(kù)類(lèi)型 查詢(xún)構(gòu)造 回答生成 關(guān)系型數(shù)據(jù)庫(kù) 根據(jù)意圖和實(shí)體確定table name，where條件，和目標(biāo)column等要素，構(gòu)建SQL Query 將SQL Query結(jié)果填注到對(duì)應(yīng)模板中，生成回答問(wèn)題的自然語(yǔ)言 Web API 根據(jù)意圖和實(shí)體確定要調(diào)用的API類(lèi)型和參數(shù)，構(gòu)造Http Request 將Web API調(diào)用結(jié)果填注到對(duì)應(yīng)模板中，生成回答問(wèn)題的自然語(yǔ)言 結(jié)構(gòu)化文本文件(json, xml等) 根據(jù)意圖和實(shí)體，確定對(duì)應(yīng)文件路徑和對(duì)其中存儲(chǔ)數(shù)據(jù)結(jié)構(gòu)的查詢(xún) 將獲取內(nèi)容填注到對(duì)應(yīng)模板中，生成回答問(wèn)題的自然語(yǔ)言 非結(jié)構(gòu)化文本文件 根據(jù)意圖和實(shí)體，確定對(duì)應(yīng)文件路徑 直接返回文本內(nèi)容 針對(duì)小明的問(wèn)題，我們選擇SQL Server作為知識(shí)庫(kù)。知識(shí)存儲(chǔ)在table中。 用戶(hù)的問(wèn)題經(jīng)過(guò)語(yǔ)言理解，被提取成了意圖和若干實(shí)體。下面要做的就是：將解析出來(lái)的意圖和實(shí)體構(gòu)造成一個(gè)SQL Query，用于在知識(shí)庫(kù)table中進(jìn)行查詢(xún)。 例如，我們來(lái)看引用-2-2中的Case2’和Case3’。 知識(shí)庫(kù)里有一個(gè)Table，名字叫Product，其中每一個(gè)row對(duì)應(yīng)一種產(chǎn)品，每個(gè)column對(duì)應(yīng)一個(gè)屬性。 那么從Case2’中解析出來(lái)的意圖和實(shí)體（意圖：商品查詢(xún)；實(shí)體：[目的地：伊犁，商品Id：00183，商品屬性：郵費(fèi)]），則可以被構(gòu)造成一個(gè)SQL Query： SELECT ‘郵費(fèi)’ FROM Product WHEREProduct_name = '00183' AND Destination = ‘伊犁’ 引用-3 Query在SQL Server中運(yùn)行的結(jié)果（比如是26元），被放到一個(gè)預(yù)置的針對(duì)商品查詢(xún)的答案模板里，生成答案。 預(yù)置模板：“您查詢(xún)的${商品Id}號(hào)商品的${商品屬性}是${Query_Result}。” 生成答案：“您查詢(xún)的00183號(hào)商品的郵費(fèi)是26元。” 引用-4 上下文存儲(chǔ)客戶(hù)和客服對(duì)話的時(shí)候，經(jīng)常會(huì)問(wèn)多個(gè)問(wèn)題。而不同的問(wèn)題之間，可能有一些信息是共享的。例如： 客戶(hù)：02366這款產(chǎn)品可以退換嗎？（問(wèn)題1） 客服：7天之內(nèi)無(wú)理由退換。 客戶(hù)：寄到南昌郵費(fèi)多少啊？（問(wèn)題2） 客服：10塊親。 客戶(hù)：武漢呢？（問(wèn)題3） 引用-5 上例中，問(wèn)題1詢(xún)問(wèn)可否退換，并提到了一個(gè)產(chǎn)品的Id；問(wèn)題2詢(xún)問(wèn)到南昌的郵費(fèi)，但是沒(méi)有提具體產(chǎn)品；問(wèn)題3干脆只有一個(gè)地名。 但是作為人工客服很明白：?jiǎn)栴}2詢(xún)問(wèn)的產(chǎn)品是問(wèn)題1中出現(xiàn)的02366，而問(wèn)題3則是詢(xún)問(wèn)這款產(chǎn)品寄到武漢的郵費(fèi)。 這些同一個(gè)對(duì)話中不同語(yǔ)句之間共享的信息，就是上下文（Context）。 想要機(jī)器人具備上下文的記憶、理解功能，而不是把用戶(hù)的每一個(gè)單獨(dú)語(yǔ)句當(dāng)作本輪問(wèn)題的全部信息來(lái)源，就需要有一個(gè)ContextStore來(lái)專(zhuān)門(mén)負(fù)責(zé)上下文信息的記錄、查詢(xún)、更新和刪除（CRUD）。參見(jiàn)圖-2中最右側(cè)下方的模塊。 每次用戶(hù)新輸入的信息都要先進(jìn)行語(yǔ)言理解，再結(jié)合現(xiàn)有ContextStore中存儲(chǔ)的內(nèi)容，或更新Context，或讀取之前的Context作為補(bǔ)充信息。 以引用-5為例，可以將意圖，和幾種實(shí)體類(lèi)型對(duì)應(yīng)的實(shí)體值（例如Id，目標(biāo)屬性，目的地等）存儲(chǔ)在Context中。 當(dāng)新的用戶(hù)語(yǔ)句輸入后，假設(shè)從中能夠提取出新的意圖或?qū)嶓w值，則用新值更新Context，否則，讀入現(xiàn)有的對(duì)應(yīng)實(shí)體值，作為本次語(yǔ)言理解的補(bǔ)充。 在引用-5中，問(wèn)題1中讀取到了商品查詢(xún)的意圖，商品Id，和“退換“這一商品屬性，將它們存入Context。 問(wèn)題2中讀取到了”郵費(fèi)“這一商品屬性，和之前存儲(chǔ)的不同，則更新Context的商品屬性值，并新存入“目的地”這一實(shí)體。 問(wèn)題3則更新了目的地，并讀取其他的包括意圖、商品Id和商品屬性的值，與目的地一起用來(lái)構(gòu)造查詢(xún)。 Context的場(chǎng)景針對(duì)性非常強(qiáng)，很多時(shí)候需要針對(duì)不同的意圖，記錄不同類(lèi)型的實(shí)體值。在不同意圖之間切換的時(shí)候，也有可能會(huì)保留部分原有實(shí)體。這些都要針對(duì)具體情況case by case分析。 具體ContextStore中存儲(chǔ)什么樣的內(nèi)容，CRUD策略是什么，都是開(kāi)發(fā)者需要自己決定。 機(jī)器人的反問(wèn) 某些情況下，Chatbot可能需要反問(wèn)用戶(hù)若干問(wèn)題，或者和用戶(hù)確認(rèn)之前的某個(gè)回答，在這種情況下，就需要有內(nèi)部流程控制。 例如：在商品查詢(xún)的目標(biāo)屬性為郵費(fèi)時(shí)，目的地缺失，這時(shí)候就需要主動(dòng)要求用戶(hù)輸入對(duì)應(yīng)的值。 不同場(chǎng)景的需求不同，這樣的控制流程很難統(tǒng)一規(guī)劃，因此需要在具體實(shí)踐中根據(jù)具體需求，完成細(xì)節(jié)。 或者，也可以主動(dòng)提出幾個(gè)備選問(wèn)題，請(qǐng)用戶(hù)選擇他們想問(wèn)的。 開(kāi)發(fā)一款機(jī)器人的基本流程 按照我們剛才說(shuō)的： 1. 創(chuàng)建語(yǔ)言理解模塊。 定義意圖、實(shí)體類(lèi)型；收集數(shù)據(jù)，選取特征；進(jìn)行標(biāo)注、訓(xùn)練驗(yàn)證和測(cè) 2. 創(chuàng)建一個(gè)知識(shí)庫(kù)。 創(chuàng)建SQL Server Database及若干表格，用來(lái)存儲(chǔ)問(wèn)答知識(shí)。 3. 編寫(xiě)中控程序，負(fù)責(zé)負(fù)責(zé)： i）接受用戶(hù)問(wèn)題并調(diào)用語(yǔ)言理解模塊進(jìn)行解析； ii）根據(jù)語(yǔ)言理解結(jié)果構(gòu)知識(shí)庫(kù)查詢(xún)； iii）執(zhí)行知識(shí)庫(kù)查詢(xún)； iv）根據(jù)數(shù)據(jù)庫(kù)查詢(xún)結(jié)果構(gòu)造答案； v）創(chuàng)建并維護(hù)Context。 在完成了上述工作后，一個(gè)可以理解人類(lèi)語(yǔ)言的聊天機(jī)器人就可以上線為顧客服務(wù)了。 在實(shí)踐當(dāng)中，還有一些問(wèn)題需要注意： Tip-1：語(yǔ)言理解部分可以考慮同時(shí)采用model-based模型和rule-based模型。 Model-based模型雖然可擴(kuò)展性強(qiáng)，但也會(huì)有精準(zhǔn)度不高，不容易即時(shí)修改等問(wèn)題（雖然可以在線訓(xùn)練和發(fā)布，但作為model-based分類(lèi)器和判別工具，如須改變某句話的分類(lèi)，或許并不能靠添加單一的訓(xùn)練數(shù)據(jù)來(lái)完成）。 在這種情況下，考慮和rule-based的意圖、實(shí)體識(shí)別相結(jié)合。可以通過(guò)添加一系列正則表達(dá)式來(lái)匹配意圖，抽取實(shí)體。 Tip-2：某些情況下，Chatbot可能需要反問(wèn)用戶(hù)若干問(wèn)題，或者和用戶(hù)確認(rèn)之前的某個(gè)回答，在這種情況下，就需要有內(nèi)部流程控制。 例如：在商品查詢(xún)的目標(biāo)屬性為郵費(fèi)時(shí)，目的地缺失，這時(shí)候就需要主動(dòng)要求用戶(hù)輸入對(duì)應(yīng)的值。 不同場(chǎng)景的需求不同，這樣的控制流程很難統(tǒng)一規(guī)劃，因此需要在具體實(shí)踐中根據(jù)具體需求，完成細(xì)節(jié)。 Tip-3：有些時(shí)候，在無(wú)法明確用戶(hù)意圖時(shí)，也可以主動(dòng)提出幾個(gè)備選問(wèn)題，請(qǐng)用戶(hù)選擇他們想問(wèn)的。 總之，在實(shí)踐中由于具體的場(chǎng)景和需求，會(huì)遇到各種各樣的問(wèn)題。到時(shí)候，就兵來(lái)將擋，水來(lái)土掩吧！ 附錄：微軟語(yǔ)言理解智能服務(wù) LUIS 為了幫助普通開(kāi)發(fā)者解決自然語(yǔ)言理解這一開(kāi)發(fā)瓶頸，微軟推出了自己的語(yǔ)言理解智能服務(wù) - LUIS。
LUIS (LanguageUnderstanding Intelligent Service) 的使命是讓非NLP專(zhuān)業(yè)的開(kāi)發(fā)者，能夠輕松地創(chuàng)建和維護(hù)高質(zhì)量的自然語(yǔ)言理解模型，并無(wú)縫對(duì)接到相關(guān)應(yīng)用中去。 使用LUIS，一個(gè)Bot需要?jiǎng)?chuàng)建一個(gè)（或多個(gè)）LUIS App，然后標(biāo)注所期望的輸入(用戶(hù)的自然語(yǔ)言提問(wèn))和輸出(意圖和實(shí)體)，再經(jīng)過(guò)在線訓(xùn)練來(lái)獲得自己的語(yǔ)言理解模型。 整個(gè)開(kāi)發(fā)過(guò)程中，開(kāi)發(fā)者只需要清晰地定義自己需要讓機(jī)器理解的用戶(hù)意圖和實(shí)體即可，并不需要了解背后算法的細(xì)節(jié)。 LUIS的開(kāi)發(fā)流程包括三大步驟：
數(shù)據(jù)輸入和標(biāo)注 LUIS開(kāi)發(fā)者可以在界面上輕松地進(jìn)行在線數(shù)據(jù)標(biāo)注。 首先，在對(duì)應(yīng)的用戶(hù)意圖中輸入自然語(yǔ)言語(yǔ)句，例如：在“商品查詢(xún)”意圖中輸入一句“00183號(hào)商品快遞到伊犁郵費(fèi)多少？” ；然后，通過(guò)鼠標(biāo)選取實(shí)體并指定類(lèi)型，例如：選擇“郵費(fèi)”標(biāo)注為“商品屬性”。 標(biāo)注結(jié)果在頁(yè)面上顯示如下：
LUIS平臺(tái)會(huì)自動(dòng)從用戶(hù)輸入并標(biāo)注的數(shù)據(jù)中提取文本特征。這些特征，包括LUIS預(yù)設(shè)的常用文本特征（從大數(shù)據(jù)語(yǔ)料中提取），也包括用戶(hù)自定的新特征。 LUIS允許用戶(hù)通過(guò)兩種方式來(lái)定義新特征： 短語(yǔ)列表特征（Phrase List Features） 需用戶(hù)自己定義若干短語(yǔ)列表，這些被定義在同一列表中的短語(yǔ)，都會(huì)被當(dāng)作同一個(gè)實(shí)體類(lèi)型中的實(shí)體處理。
在定義過(guò)程中，LUIS還會(huì)通過(guò)其語(yǔ)義詞典(semantic dictionary)挖掘技術(shù)，根據(jù)用戶(hù)輸入的短語(yǔ)，自動(dòng)從海量的網(wǎng)絡(luò)數(shù)據(jù)中發(fā)現(xiàn)相似的短語(yǔ)，并推薦給用戶(hù)。從而有效地提升了效率。 模式特征（Pattern Features） 也稱(chēng)為正則表達(dá)式特征。主要用于定義若干正則表達(dá)式。 LUIS根據(jù)這些表達(dá)式從用戶(hù)輸入數(shù)據(jù)中抽取符合其模式的實(shí)體。 模型的訓(xùn)練 LUIS的模型訓(xùn)練過(guò)程極其簡(jiǎn)單，開(kāi)發(fā)者只需點(diǎn)擊一下 “Train” 按鈕，后臺(tái)就會(huì)基于輸入數(shù)據(jù)進(jìn)行自動(dòng)訓(xùn)練。 訓(xùn)練的時(shí)間與標(biāo)注數(shù)據(jù)量相關(guān)，標(biāo)注數(shù)據(jù)越多，訓(xùn)練所需的時(shí)間越長(zhǎng)。同時(shí)，訓(xùn)練時(shí)間還與LUIS App所支持的意圖和實(shí)體個(gè)數(shù)相關(guān)，意圖和實(shí)體越多，訓(xùn)練時(shí)間也越長(zhǎng)。 模型的測(cè)試、發(fā)布和服務(wù) 訓(xùn)練完模型，開(kāi)發(fā)者可以對(duì)其進(jìn)行性能測(cè)試。方法有兩種： 交互式測(cè)試：開(kāi)發(fā)者可以在頁(yè)面上直接輸入自然語(yǔ)言語(yǔ)句，然后目測(cè)模型輸出結(jié)果。 批量測(cè)試：開(kāi)發(fā)者需要上傳一份測(cè)試數(shù)據(jù)，LUIS完成全部測(cè)試后給出精準(zhǔn)率和召回率等統(tǒng)計(jì)數(shù)據(jù)，并針對(duì)每一項(xiàng)意圖和實(shí)體的繪制出Confusion Matrix。 測(cè)試過(guò)的模型，只需點(diǎn)擊“Publish”按鈕，就可以發(fā)布到微軟的Azure云平臺(tái)上，成為一個(gè)立即可用的API Service。 開(kāi)發(fā)者可以通過(guò)Http的Get方法，調(diào)用模型，對(duì)新的語(yǔ)句進(jìn)行意圖識(shí)別和實(shí)體抽取。 迭代更新 上述三個(gè)步驟是可以不斷重復(fù)迭代的。 模型訓(xùn)練完發(fā)布上線后，可以繼續(xù)輸入、標(biāo)注新的數(shù)據(jù)，重新訓(xùn)練，再次發(fā)布。如此循環(huán)往復(fù)，逐步改進(jìn)質(zhì)量。 使用提示 1. 當(dāng)前的LUIS是一個(gè)純粹model-based的語(yǔ)言理解工具。 雖然可擴(kuò)展性強(qiáng)，但也會(huì)有精準(zhǔn)度不高，不容易即時(shí)修改等問(wèn)題（雖然可以在線訓(xùn)練和發(fā)布，但作為model-based分類(lèi)器和判別工具，如須改變某句話的分類(lèi)，或許并不能靠添加單一的訓(xùn)練數(shù)據(jù)來(lái)完成）。 在這種情況下，可以考慮LUIS和rule-based的意圖、實(shí)體識(shí)別相結(jié)合。可以通過(guò)添加一系列正則表達(dá)式來(lái)匹配意圖，抽取實(shí)體。 2. 每一個(gè)LUIS App都有一個(gè)內(nèi)置的意圖，叫做None，非常有用。一般用它來(lái)收集那些用戶(hù)經(jīng)常會(huì)問(wèn)，但是Chat Bot并不打算回答的問(wèn)題。 若不在None中指定它們，這些問(wèn)題很可能會(huì)被錯(cuò)誤的預(yù)測(cè)為其他用戶(hù)自定義的意圖，造成Chat Bot的over trigger（e.g.用戶(hù)問(wèn)：你是女孩嗎？Bot回答：江浙滬包郵），從而嚴(yán)重影響用戶(hù)體驗(yàn)。
| 
