一種對(duì)話機(jī)器人開(kāi)發(fā)技術(shù)綜述與系統(tǒng)架構(gòu)實(shí)現(xiàn)

摘? 要：對(duì)話機(jī)器人是使用自然語(yǔ)言處理與生成技術(shù)，模擬人類對(duì)話邏輯并與人進(jìn)行交流的計(jì)算機(jī)程序。作為新一代人工智能產(chǎn)品的人機(jī)交互主要入口，邏輯實(shí)現(xiàn)方式與交互是對(duì)話機(jī)器人設(shè)計(jì)的關(guān)鍵。本文結(jié)合對(duì)話機(jī)器人的技術(shù)特點(diǎn)，在實(shí)現(xiàn)過(guò)程中采用基于Python語(yǔ)言的Django微服務(wù)Web應(yīng)用開(kāi)發(fā)框架，將對(duì)話算法模型與邏輯處理過(guò)程進(jìn)行微服務(wù)化API封裝，使其他應(yīng)用能夠請(qǐng)求對(duì)話服務(wù)的接口進(jìn)行功能的二次開(kāi)發(fā)。為了提高對(duì)話響應(yīng)速度，本文采用了關(guān)系型數(shù)據(jù)庫(kù)MySQL與基于內(nèi)存的非關(guān)系型數(shù)據(jù)庫(kù)Redis結(jié)合的方式，減少算法模型對(duì)硬盤(pán)的讀取次數(shù)，優(yōu)化了用戶體驗(yàn)。

關(guān)鍵詞：微服務(wù);Django;MySQL;Redis

Abstract： A chatbot is a computer program that simulates human conversation and communicates with human through natural language processing and generation technology. As main access to human-computer interaction for a new generation of artificial intelligence products， logical implementation and interaction are critical to the design of chatbots. Based on technical characteristics of chatbots， this paper adopts Python-based Django micro-service web application development framework in the implementation and encapsulates dialogue algorithm model and logic processing process into a micro-service API （Application Programming Interface）. Thus， other applications can request the interface of dialogue service for a secondary development of functions. In order to improve the efficiency of query processing， a memory-based non-relational database Redis （Remote Dictionary Server） is used with relational database MySQL （Structured Query Language） to reduce the number of reads from hard disk and so to optimize system performance.

Keywords： micro-services; Django; MySQL; Redis

1? ?引言（Introduction）

對(duì)話機(jī)器人是當(dāng)前人工智能領(lǐng)域的研究熱點(diǎn)，它應(yīng)用自然語(yǔ)言處理與生成技術(shù)，以聊天界面或API為基礎(chǔ)，能夠與人進(jìn)行語(yǔ)音或文本對(duì)話，以聊天的方式解決用戶的需求[1]。對(duì)話算法主要包括以下幾個(gè)過(guò)程：自然語(yǔ)言理解、對(duì)話狀態(tài)追蹤[2]、對(duì)話內(nèi)容管理[3]、自然語(yǔ)言生成[4]。但是上述過(guò)程的核心算法都是基于Python編程語(yǔ)言開(kāi)發(fā)的，與網(wǎng)站軟件開(kāi)發(fā)或終端硬件開(kāi)發(fā)的技術(shù)架構(gòu)并不兼容。為了適應(yīng)越發(fā)復(fù)雜的大型網(wǎng)站系統(tǒng)單體架構(gòu)，微服務(wù)技術(shù)應(yīng)運(yùn)而生，其核心思想是各種自治的子系統(tǒng)協(xié)同工作，共同完成大型網(wǎng)站的功能和業(yè)務(wù)需求[5]。

對(duì)話機(jī)器人與其他微服務(wù)程序不同的地方在于：處理對(duì)話邏輯需要大量高頻重復(fù)且復(fù)雜的計(jì)算過(guò)程和頻繁的存取硬盤(pán)數(shù)據(jù)的過(guò)程。隨著使用對(duì)話的用戶規(guī)模變大，由于硬件資源有限，對(duì)話程序在運(yùn)行過(guò)程中很容易造成對(duì)話響應(yīng)速度變慢、對(duì)話邏輯處理不完整甚至是服務(wù)宕機(jī)等現(xiàn)象，嚴(yán)重影響用戶體驗(yàn)。

針對(duì)上述問(wèn)題，本文在技術(shù)實(shí)現(xiàn)過(guò)程中采用基于Python語(yǔ)言的Django開(kāi)發(fā)框架，并根據(jù)業(yè)務(wù)邏輯將對(duì)話模型進(jìn)行模塊拆分，在模塊之間添加Redis緩存[6]，用內(nèi)存中的讀寫(xiě)過(guò)程替代了高頻的復(fù)雜計(jì)算和高頻的硬盤(pán)存取過(guò)程。

2? ?相關(guān)技術(shù)（Related technologies）

2.1? ?Python

Python是由Guido van Rossum在20世紀(jì)80年代末到90年代初于荷蘭國(guó)家數(shù)學(xué)和計(jì)算機(jī)科學(xué)研究所設(shè)計(jì)出來(lái)的一種結(jié)合了解釋性、編譯性、互動(dòng)性和面向?qū)ο蟮母呒?jí)程序設(shè)計(jì)語(yǔ)言。它具有易于學(xué)習(xí)與維護(hù)、可移植、可擴(kuò)展、可嵌入等特點(diǎn)。Python由于代碼簡(jiǎn)潔、基礎(chǔ)代碼庫(kù)完善等優(yōu)勢(shì)，已經(jīng)應(yīng)用于人工智能、Web應(yīng)用開(kāi)發(fā)、運(yùn)維系統(tǒng)開(kāi)發(fā)、游戲開(kāi)發(fā)等重要領(lǐng)域。Python語(yǔ)言在人工智能領(lǐng)域被廣泛應(yīng)用是因?yàn)樗鼘?duì)科學(xué)計(jì)算的友好支持[7]，包括基礎(chǔ)的Numpy、Pandas、Scikit-learn等科學(xué)計(jì)算工具箱和Tensorflow、Pytorch、Caffe等深度學(xué)習(xí)開(kāi)發(fā)框架都是以Python語(yǔ)言為基礎(chǔ)進(jìn)行封裝的。

2.2? ?Django

Django是一款基于Python的免費(fèi)開(kāi)源的Web應(yīng)用開(kāi)發(fā)框架，采用了MVT的框架模式，即模型M（Model）、視圖V（View）和模板T（Template），于2008年9月發(fā)布了第一個(gè)正式版本1.0。MVT模式將傳統(tǒng)MVC模式中的Controller層拆分成業(yè)務(wù)邏輯操作與請(qǐng)求的處理與轉(zhuǎn)發(fā)，將業(yè)務(wù)邏輯操作結(jié)合到了View層中，View通過(guò)調(diào)用Model層與Template層，根據(jù)HTML、CSS、JavaScript等對(duì)數(shù)據(jù)進(jìn)行渲染后返回給前端瀏覽器界面。同時(shí)新增了一個(gè)URL分發(fā)器，負(fù)責(zé)將不同的URL請(qǐng)求分發(fā)給不同的View進(jìn)行業(yè)務(wù)邏輯處理。Django擁有強(qiáng)大的數(shù)據(jù)庫(kù)功能，并自帶一套功能完備、界面美觀的管理后臺(tái)。由于Django具有低耦合、開(kāi)發(fā)快捷、部署方便、復(fù)用性高、運(yùn)維成本低、完善的開(kāi)發(fā)者社區(qū)等優(yōu)點(diǎn)，近些年來(lái)許多大型網(wǎng)站的開(kāi)發(fā)都選擇Django作為Web應(yīng)用核心開(kāi)發(fā)框架，例如YouTube、Google、Instagram、Reddit，以及國(guó)內(nèi)的豆瓣、知乎等。

Django框架原理如圖1所示。首先，客戶端向服務(wù)發(fā)送HTTP請(qǐng)求，由WSGI（Web Server Gateway Interface）模塊統(tǒng)一進(jìn)行協(xié)議處理后，發(fā)送給請(qǐng)求中間件，并由請(qǐng)求中間件交由URL分發(fā)器進(jìn)行統(tǒng)一分發(fā)。若找不到對(duì)應(yīng)的URL地址，則直接返回給響應(yīng)中間件，經(jīng)過(guò)WSGI模塊統(tǒng)一處理后返回給瀏覽器。若找到對(duì)應(yīng)的URL地址，則由視圖中間件進(jìn)行處理后映射到View層中的函數(shù)。View層的函數(shù)根據(jù)業(yè)務(wù)邏輯判斷是否需要調(diào)用Model層，Model層利用對(duì)象關(guān)系映射（Object-Relational Mapping，ORM）[8]將數(shù)據(jù)庫(kù)表抽象成Python中的類，數(shù)據(jù)庫(kù)表中的字段抽象成Python類中的屬性，通過(guò)對(duì)Model層的類的操作得到數(shù)據(jù)庫(kù)的API，避免了復(fù)雜的數(shù)據(jù)庫(kù)語(yǔ)句編寫(xiě)。View層在調(diào)用Model層的同時(shí)從Template層的靜態(tài)資源庫(kù)中調(diào)用HTML/CSS/JavaScript資源，并將數(shù)據(jù)和頁(yè)面解析、渲染成HTML頁(yè)面，經(jīng)事務(wù)中間件處理后返回給響應(yīng)中間件，由響應(yīng)中間件交給WSGI模塊統(tǒng)一處理后返回給瀏覽器。

2.3? ?MySQL數(shù)據(jù)庫(kù)

MySQL在Web應(yīng)用方面是最好的RDBMS（Relational Database Management System，關(guān)系數(shù)據(jù)庫(kù)管理系統(tǒng)）應(yīng)用軟件之一，由瑞典的MySQL AB公司開(kāi)發(fā)，屬于Oracle旗下產(chǎn)品。數(shù)據(jù)庫(kù)（Database）是按照數(shù)據(jù)結(jié)構(gòu)來(lái)組織、存儲(chǔ)和管理數(shù)據(jù)的應(yīng)用程序。關(guān)系型數(shù)據(jù)庫(kù)是建立在關(guān)系模型基礎(chǔ)上的數(shù)據(jù)庫(kù)，借助于集合、代數(shù)等數(shù)學(xué)概念和方法來(lái)處理數(shù)據(jù)庫(kù)中的數(shù)據(jù)。在關(guān)系型數(shù)據(jù)庫(kù)中，數(shù)據(jù)以表（Table）的形式出現(xiàn)，表中的每一行稱為一條記錄，表中的每一列稱為一個(gè)屬性，表與表之間以代數(shù)關(guān)系為基礎(chǔ)組成完整的系統(tǒng)數(shù)據(jù)。數(shù)據(jù)庫(kù)表的結(jié)構(gòu)設(shè)計(jì)決定了數(shù)據(jù)庫(kù)的性能，合理的數(shù)據(jù)庫(kù)結(jié)構(gòu)可以讓使用者在每次訪問(wèn)最少數(shù)量的表的前提下完成業(yè)務(wù)需求。MySQL數(shù)據(jù)庫(kù)使用標(biāo)準(zhǔn)的SQL語(yǔ)言形式對(duì)數(shù)據(jù)進(jìn)行增加、刪除、修改、查詢等操作，由于其體積小、速度快、成本低、使用靈活等特點(diǎn)被應(yīng)用于中小型網(wǎng)站開(kāi)發(fā)。

2.4? ?Redis

遠(yuǎn)程字典服務(wù)（Remote Dictionary Server， Redis）是一個(gè)基于key-value形式存儲(chǔ)的NoSQL數(shù)據(jù)庫(kù)[9]，用哈希表表示key與value之間的映射關(guān)系，可用key值迅速查詢對(duì)應(yīng)的value值[10]。Redis使用ANSI C編寫(xiě)，包含五種數(shù)據(jù)結(jié)構(gòu)，并且支持網(wǎng)絡(luò)通信和多語(yǔ)言API，遵守BSD協(xié)議，可擴(kuò)展性強(qiáng)，可選作持久化存儲(chǔ)[11]。由于Redis的數(shù)據(jù)以key-value的形式存儲(chǔ)在內(nèi)存中，且Redis的事務(wù)操作具有原子性，因此比硬盤(pán)讀寫(xiě)更迅速，讀取速度可以達(dá)到110，000 次/秒，寫(xiě)入速度可以達(dá)到81，000 次/秒[12]。Redis通常應(yīng)用在“高頻讀、低頻寫(xiě)”的熱點(diǎn)數(shù)據(jù)緩存、計(jì)數(shù)器、消息隊(duì)列、排行榜、社交網(wǎng)絡(luò)、訂單系統(tǒng)等高吞吐、高并發(fā)場(chǎng)景。

3? ?流程設(shè)計(jì)與實(shí)現(xiàn)（Process design and implementation）

3.1? ?對(duì)話服務(wù)問(wèn)答流程

基于Django的對(duì)話機(jī)器人服務(wù)流程如圖2所示。

（1）對(duì)話服務(wù)從前端接收參數(shù)sentence和userId。其中sentence為用戶輸入的句子，userId為用戶的唯一標(biāo)識(shí)。

（2）Django框架中的View層函數(shù)解析參數(shù)sentence和userId。

（3）以sentence為key在Redis的nlu目錄中進(jìn)行查詢。若查詢到記錄，則將value取出作為dialogue，并更新生命周期為604，800 秒;若查詢不到記錄，則將sentence傳入NLU模塊進(jìn)行理解，輸出作為dialogue，并將最新的理解結(jié)果寫(xiě)入Redis。其中，dialogue為NLU模塊進(jìn)行理解后的計(jì)算結(jié)果。

（4）以u(píng)serId為key在Redis的userdst目錄中進(jìn)行查詢。若查詢到記錄，則從value列表取出dst.state和keyword，并更新生命周期為604，800 秒;若查詢不到記錄，則初始化dst.state和keyword并寫(xiě)入Redis。其中，dst.state為該用戶的對(duì)話狀態(tài)追蹤信息，keyword為該用戶上次對(duì)話的關(guān)鍵詞。

（5）將sentence，dialogue，dst傳入DPL對(duì)話策略學(xué)習(xí)模塊進(jìn)行意圖識(shí)別。若DPL模塊處理結(jié)果顯示為非問(wèn)答，則給出回應(yīng)，并傳回給前端;若DPL模塊處理結(jié)果顯示為問(wèn)答，則將處理后的問(wèn)題question傳入QA模塊。

（6）以question為key在Redis的qa目錄中進(jìn)行查詢。若查詢到記錄，則從value列表中取出answer，并更新生命周期為604，800 秒;若查詢不到記錄，則從數(shù)據(jù)庫(kù)中掃描關(guān)鍵詞并進(jìn)行問(wèn)答對(duì)匹配傳回給前端，同時(shí)將問(wèn)答對(duì)寫(xiě)入Redis，并更新生命周期為604，800 秒。

通過(guò)上述流程，高頻輸入的句子、高頻活躍的用戶對(duì)話狀態(tài)追蹤和高頻匹配的問(wèn)答對(duì)全部被緩存至Redis之中。其他用戶請(qǐng)求服務(wù)時(shí)，若輸入的是經(jīng)常被輸入的語(yǔ)句和經(jīng)常被理解的問(wèn)題，則直接從Redis數(shù)據(jù)庫(kù)中讀取內(nèi)容，不必進(jìn)行煩瑣的計(jì)算過(guò)程和緩慢的讀硬盤(pán)過(guò)程。

3.2? ?MySQL數(shù)據(jù)庫(kù)結(jié)構(gòu)設(shè)計(jì)

由于對(duì)話機(jī)器人模型首先需要掃描對(duì)話域內(nèi)的關(guān)鍵詞，匹配成功后再掃描該關(guān)鍵詞分支下的全部問(wèn)答對(duì)，因此將關(guān)鍵詞表中的keyword字段作為問(wèn)答對(duì)表的外鍵。關(guān)鍵詞表和問(wèn)答對(duì)表如表1和表2所示。

3.3? ?Redis存儲(chǔ)策略設(shè)計(jì)

根據(jù)對(duì)話機(jī)器人模型的流程可知，高頻輸入語(yǔ)句的NLU計(jì)算結(jié)果、用戶狀態(tài)和用戶對(duì)話關(guān)鍵詞、高頻問(wèn)答對(duì)匹配結(jié)果可以在Redis進(jìn)行緩存處理。其中，高頻輸入語(yǔ)句的NLU計(jì)算結(jié)果用set命令存入chatbot：nlu目錄下，以sentence為key，以dialogue為value，生命周期為604，800 秒;用戶狀態(tài)和用戶對(duì)話關(guān)鍵詞用lpush命令存入chatbot：userdst目錄下，以u(píng)serId為key，以dst和keyword為value列表，生命周期為604，800 秒;高頻問(wèn)答對(duì)匹配結(jié)果用set命令存入chatbot：qa目錄下，以question為key，以answer為value，生命周期為604，800 秒。

4? ?性能分析（Performance analysis）

4.1? ?系統(tǒng)硬件指標(biāo)及測(cè)試工具

本文的對(duì)話機(jī)器人服務(wù)開(kāi)發(fā)采用的是Windows 64位操作系統(tǒng)上位機(jī)，處理器為Intel（R）Core（TM）i7-8565U CPU @ 1.80 GHz 2.00 GHz，核心數(shù)8 個(gè)，內(nèi)存為16 GB、2400 MHz頻率，服務(wù)部署于開(kāi)發(fā)機(jī)上。性能指標(biāo)測(cè)試收集工具采用的是Postman請(qǐng)求模擬器v7.34.0和Apache Server中的ab.exe組件。

4.2? ?單個(gè)請(qǐng)求響應(yīng)時(shí)間測(cè)試

首先由一個(gè)新用戶向?qū)υ挿?wù)發(fā)問(wèn)，然后更換用戶再向?qū)υ挿?wù)問(wèn)相同的內(nèi)容，記錄請(qǐng)求的響應(yīng)時(shí)間。如圖3和圖4所示，新用戶向?qū)υ挿?wù)發(fā)問(wèn)時(shí)請(qǐng)求完成時(shí)間為345 ms，而更換用戶后問(wèn)相同問(wèn)題時(shí)請(qǐng)求完成時(shí)間僅為83 ms。因?yàn)榍耙幻脩舻恼Z(yǔ)義理解結(jié)果和問(wèn)答對(duì)匹配結(jié)果已經(jīng)被記錄至Redis中，新用戶的發(fā)問(wèn)請(qǐng)求只需在Redis中讀取數(shù)據(jù)，無(wú)須進(jìn)行復(fù)雜的計(jì)算和數(shù)據(jù)庫(kù)讀取。

4.3? ?并發(fā)請(qǐng)求測(cè)試

設(shè)置Apache Server ab.exe組件的參數(shù)-n與-c分別為{0，10，100，1000，10000}和{0，10，100，1000，10000}。其中，-n為總請(qǐng)求數(shù)，-c為并發(fā)請(qǐng)求數(shù)。記錄服務(wù)的吞吐率（Requests per Second，RPS，單位為req/s）和平均請(qǐng)求完成時(shí)間（Time per Request，TPR，單位為ms），測(cè)試結(jié)果如表3所示。

由測(cè)試結(jié)果可知，對(duì)話服務(wù)在4.1節(jié)的運(yùn)行條件下，接收100 個(gè)并發(fā)請(qǐng)求的時(shí)候達(dá)到性能瓶頸，此時(shí)RPS達(dá)到25左右，且隨著并發(fā)量增加RPS不再變化;TPR為40 ms左右，且隨著并發(fā)量增加TPR不再變化。

5? ?結(jié)論（Conclusion）

本文從對(duì)話機(jī)器人算法流程出發(fā)，根據(jù)對(duì)話算法使用框架的特點(diǎn)，在技術(shù)實(shí)現(xiàn)過(guò)程中采用基于Python編程語(yǔ)言的Django微服務(wù)框架對(duì)算法業(yè)務(wù)邏輯進(jìn)行API封裝，以便他人調(diào)用API接口進(jìn)行對(duì)話功能的二次開(kāi)發(fā);同時(shí)將復(fù)雜的計(jì)算流程和硬盤(pán)存取流程拆分，并將高頻訪問(wèn)的句子、高頻使用用戶的對(duì)話狀態(tài)追蹤信息和高頻匹配的問(wèn)答對(duì)進(jìn)行Redis緩存處理及MySQL持久化存儲(chǔ)處理。對(duì)性能分析的結(jié)果表明，基于Django框架和Redis緩存的對(duì)話服務(wù)開(kāi)發(fā)流程減少了計(jì)算過(guò)程和硬盤(pán)存取過(guò)程，能夠應(yīng)對(duì)大規(guī)模的數(shù)據(jù)存儲(chǔ)需求。對(duì)話服務(wù)的請(qǐng)求響應(yīng)迅速，吞吐率指標(biāo)正常，在保證性能的同時(shí)優(yōu)化了用戶體驗(yàn)。

參考文獻(xiàn)（References）

[1] 楊曄.基于深度學(xué)習(xí)的聊天機(jī)器人的研究[J].信息技術(shù)與信息化，2020（03）：158-159.

[2] Tsung-Hsien Wen， David Vandyke， Nikola Mrksic， et al. A Network-based End-to-End Trainable Task-oriented Dialogue System[C]. Proceedings of the 15th Conference of the European Chapter of the Association for Computational Linguistics（Volume 1： Long Papers）， 2017：438-449.

[3] Chien-Sheng Wu， Andrea Madotto， Ehsan Hosseini-Asl， et al.? Transferable Multi-Domain State Generator for Task-Oriented Dialogue Systems[C]. Proceedings of the 57th Annual Meeting of the Association for Computational Linguistics， 2019：? 808-819.

[4] Hao Zhou， Tom Young， Minlie Huang， et al. Commonsense knowledge aware conversation generation with graph attention[C]. Proceedings of the 27th International Joint Conference on Artificial Intelligence， 2018：4623-4629.

[5] 徐維，劉屹.微服務(wù)技術(shù)框架在智慧警務(wù)應(yīng)用中的優(yōu)勢(shì)和缺點(diǎn)[J].信息通信，2019（08）：82-83.

[6] 張永躍.基于微服務(wù)+Redis的政務(wù)數(shù)據(jù)共享模式設(shè)計(jì)[J].電子技術(shù)與軟件工程，2020（14）：208-209.

[7] 呂戌杪，粟藝峰，張蒙蒙，等.基于Django的煤礦地測(cè)防治水信息管理系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)[J].科技經(jīng)濟(jì)導(dǎo)刊，2020，28（15）： 13-14.

[8] 石鳳貴.基于MTV模式的遠(yuǎn)程教學(xué)系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)[J].電腦知識(shí)與技術(shù)，2020，16（07）：93-96.

[9] 屠雪真.一種大規(guī)模Redis集群云運(yùn)維技術(shù)[J].電腦知識(shí)與技術(shù)，2019，15（08）：1-3.

[10] 桂成杰，曾獻(xiàn)輝.結(jié)合Redis與WebSocket的智能空調(diào)移動(dòng)環(huán)境實(shí)時(shí)控制技術(shù)[J].軟件導(dǎo)刊，2020，19（01）：190-194.

[11] 王佩劍.基于Docker容器的Redis高可用實(shí)現(xiàn)方案[J].信息通信，2019（08）：67-70.

[12] 寧方美，賀雪梅，牟晉娟.SpringBoot集成Redis緩存技術(shù)在企業(yè)一卡通系統(tǒng)中的應(yīng)用[J].電子技術(shù)與軟件工程，2019? （24）：133-134.

作者簡(jiǎn)介：

孫小魚(yú)（1993-），男，碩士，初級(jí)研究員.研究領(lǐng)域：人工智能，微服務(wù)開(kāi)發(fā).