基于Django 的漢維地址翻譯網(wǎng)絡(luò)服務(wù)的設(shè)計與實現(xiàn)

斯拉吉艾合麥提·如則麥麥提，艾山·吾買爾，張濟(jì)民，汪烈軍，劉勝全

（1.新疆大學(xué)信息科學(xué)與工程學(xué)院，烏魯木齊 830046；2.新疆大學(xué)新疆多語種信息技術(shù)實驗室，烏魯木齊 830046）

0 引言

命名實體（Named Entity，NE）是指具有特定意義的實體，主要包括人名、地名、組織機(jī)構(gòu)名、時間日期、地址、量詞表達(dá)式等，表達(dá)文本的關(guān)鍵部分，承載著文本的重要信息。因此，機(jī)器翻譯中命名實體的準(zhǔn)確翻譯對譯文整體質(zhì)量具有十分重要的影響[1]。命名實體翻譯對跨語言信息檢索具有十分重要的作用[1-2]，命名實體的識別[3]與翻譯等相關(guān)技術(shù)是目前自然語言處理領(lǐng)域的一個研究熱點。

命名實體具有一定的組成規(guī)范，部分實體變化較大，而且不斷出現(xiàn)新的詞匯的部分，有些實體在語料中很少見，這使得機(jī)器翻譯中出現(xiàn)嚴(yán)重的未登錄詞（Out-Of-Vocabulary，OOV）問題，給翻譯任務(wù)帶來了極大的難度。命名實體翻譯對準(zhǔn)確性和規(guī)范性有較高的要求。由于命名實體翻譯有其自身的特點，實體翻譯與句子翻譯之間存在著很大的差異，因此，很有必要將命名實體翻譯作為一個獨立于句子翻譯的問題進(jìn)行研究。

地址翻譯在學(xué)術(shù)上可以歸結(jié)為命名實體翻譯任務(wù)[4]。文本地址信息一般由幾個基本地址單元組成，結(jié)構(gòu)相對比較規(guī)整，通常情況下地址單元可以是一個地名、機(jī)構(gòu)名或者地名追加地址輔助信息。作為命名實體的一部分，學(xué)者們對地址翻譯已經(jīng)開始開展相關(guān)的研究。苗等人[5]提出了一種面向機(jī)器翻譯的機(jī)構(gòu)地址切分方法，在地址翻譯領(lǐng)域中得到了很好的效果。對于地址與機(jī)構(gòu)名翻譯，李等人[6]提出了一種先切分，再翻譯，最后調(diào)序的方法，在地址翻譯中取得了不錯的效果。嘵等人[7]定義與歸納了郵政信函上的地址信息，提出了一種非精確字符串匹配技術(shù)的自動地址翻譯方法。于等人[8]提出了一種規(guī)則與統(tǒng)計相結(jié)合的中文地址翻譯方法，并取得了較好的效果。

隨著深度學(xué)習(xí)的快速的發(fā)展，基于神經(jīng)網(wǎng)絡(luò)的機(jī)器翻譯方法有了長足的進(jìn)步[9]，國內(nèi)外學(xué)者們開始使用神經(jīng)網(wǎng)絡(luò)對命名實體進(jìn)行翻譯[10-11]。本文使用完全注意力機(jī)制的神經(jīng)機(jī)器翻譯模型Transformer 來搭建漢語-維吾爾語地址翻譯模型，設(shè)計與實現(xiàn)了基于Django的網(wǎng)絡(luò)服務(wù)接口，并使用UWSGI+Nginx 來負(fù)載均衡提高并發(fā)量。本文分別提供了維吾爾語-漢語通用文本翻譯服務(wù)與漢語-維吾爾語文本地址翻譯服務(wù)。為了方便演示，設(shè)計與實現(xiàn)了基于Django 的漢語-維吾爾語地址翻譯在線系統(tǒng)及頁面。

1 相關(guān)模型及工具

1.1 機(jī)器翻譯模型

神經(jīng)網(wǎng)絡(luò)翻譯模型[12]自提出以來，在多個語言對上的表現(xiàn)顯著地超過了統(tǒng)計機(jī)器翻譯模型，成為當(dāng)前主流的翻譯模型[9，13-14]。本文使用哈佛大學(xué)自然語言處理研究組開源的OpenNMT[15]工具進(jìn)行完全注意力網(wǎng)絡(luò)的神經(jīng)機(jī)器翻譯模型Transformer[16]來訓(xùn)練漢語-維吾爾語地址翻譯系統(tǒng)。

Transformer也是由編碼器和解碼器兩個部分組成。編碼器由一個多頭注意力網(wǎng)絡(luò)和一個簡單的全連接前饋神經(jīng)網(wǎng)絡(luò)組成，中間添加了殘差連接，共有6層，每一層之間進(jìn)行層標(biāo)準(zhǔn)化操作。解碼器是由兩個多頭注意力網(wǎng)絡(luò)和一個全連接前饋網(wǎng)絡(luò)組成，同樣是6層，也有殘差鏈接和層標(biāo)準(zhǔn)化操作。

Transformer 模型里面的多頭注意力由多個縮放點積的注意力組成，縮放點積注意力計算公式如式（1）。

首先使用Query-key 向量通過相似度計算得到權(quán)重，除于縮放因子然后用Softmax 函數(shù)對權(quán)重歸一化，最后乘以V，作為注意力向量。

多頭注意力機(jī)制計算公式如式（2）和（3），給定（Q，K，V），首先使用不同的線性映射分別將 Q、K 和 V 映射到不同的空間，然后使用不同的注意力網(wǎng)絡(luò)計算得到不同的空間的上下文向量，并將這些上下文向量拼接得到最后的輸出。

對一個序列到序列的問題來說，序列的順序是一個很重要的信息。Transformer 使用了位置編碼的方法，將編碼后的向量與詞嵌入進(jìn)行求和，加入了相對位置信息。計算位置編碼的公式如式（4）和（5）：

其中，pos 指詞語在序列中的位置，dm odel是詞向量維度。

Transformer 模型在摒棄了傳統(tǒng)的CNN 和RNN 網(wǎng)絡(luò)，表現(xiàn)更好的性能，可并行化，速度更快，同時能提升翻譯質(zhì)量。

1.2 Django Web框架

Django 是基于Python 語言的開源Web 應(yīng)用框架，發(fā)布于2003 年。Django 框架內(nèi)部各個模塊聯(lián)結(jié)緊密，遵循 MVC（Model，View，Controller）設(shè)計規(guī)范，可以避免重復(fù)代碼。Django 簡單易學(xué)，具有很強的擴(kuò)展性，具有模板系統(tǒng)以及強大的自帶后臺系統(tǒng)，是目前最受歡迎的Web 框架之一。

Django 采用MTV 的框架模式，其中M 表示模型（Model），與 MVC 中的 M 功能相同，映射業(yè)務(wù)對象，負(fù)責(zé)和數(shù)據(jù)庫交互，進(jìn)行數(shù)據(jù)處理；T 表示模板（Tem?plate），與MVC 中的V 功能相同，負(fù)責(zé)封裝構(gòu)造要返回的HTML，將頁面展示在瀏覽器上；V 表示視圖（View），與MVC 中的C 功能相同，負(fù)責(zé)接收請求，進(jìn)行業(yè)務(wù)處理，返回應(yīng)答，模型和業(yè)務(wù)之間協(xié)調(diào)業(yè)務(wù)邏輯關(guān)系。Django MTV 結(jié)構(gòu)圖如圖1 所示。

圖1 Django MVT結(jié)構(gòu)圖

1.3 UWSGI 與Nginx服務(wù)器

UWSGI 是一個全功能的 HTTP（HyperText Trans?fer Protocol）服務(wù)器，實現(xiàn)了 WSGI（Web Server Gateway Interface）的所有接口，是一個快速、自我修復(fù)、開發(fā)人員和系統(tǒng)管理員友好的Web 服務(wù)器。主要作用是把HTTP 協(xié)議轉(zhuǎn)化成語言支持的網(wǎng)絡(luò)協(xié)議。

Nginx 是一款高性能的HTTP 服務(wù)器，反向代理Web 服務(wù)器，服務(wù)器功能和UWSGI 功能很類似，但是Nginx 還可以用作更多用途，例如，通過反向代理，可以攔截一些Web 攻擊，保護(hù)后端的Web 服務(wù)器；可以負(fù)載均衡，分配請求到多節(jié)點Web 服務(wù)器；也可以緩存靜態(tài)資源，加快訪問速度，釋放Web 服務(wù)器的內(nèi)存占用。Django、UWSGI 與Nginx 之間的關(guān)系及工作流程如圖2 所示。

圖2 Django+UWSGI+Nginx工作流程

2 設(shè)計與實現(xiàn)

2.1 系統(tǒng)整體架構(gòu)

本文研究工作以Python 編程語言編寫，翻譯模型以PyTorch 深度學(xué)習(xí)框架搭建，由于神經(jīng)網(wǎng)絡(luò)機(jī)器翻譯系統(tǒng)模型與結(jié)構(gòu)復(fù)雜，參數(shù)龐大，使得翻譯速度變慢并且系統(tǒng)難以并行化。針對此問題，本文以Django +UWSGI+Nginx 架構(gòu)設(shè)計實現(xiàn)了地址翻譯網(wǎng)絡(luò)服務(wù)，使得讓系統(tǒng)同時處理多個請求，從而翻譯速度與并發(fā)量兩個方面達(dá)到較好的工程要求。本文所設(shè)計的整體系統(tǒng)框架如圖3 所示。

圖3 系統(tǒng)整體框架圖

具體的，首先Nginx 服務(wù)器接收到客戶端（一般是瀏覽器或某種應(yīng)用）發(fā)送過來的HTTP 請求，將參數(shù)包進(jìn)行解析，如果是靜態(tài)文件請求就直接返回用戶請求的靜態(tài)文件。如果是一個動態(tài)的請求，那么Nginx 就將請求發(fā)個UWSGI，UWSGI 接收到請求后將參數(shù)包處理成WSGI 可以接受的格式，并發(fā)給WSGI，WSGI 根據(jù)請求調(diào)用應(yīng)用程序的某個文件（一般是Django 里面的view.py 文件）里面的某個函數(shù)，最后處理完將返回值再次交給WSGI，WSGI 將返回值打包，打包成UWSGI 能夠接收的格式，UWSGI 接收WSGI 發(fā)送的請求，并轉(zhuǎn)發(fā)給Nginx 代理，Nginx 最終將返回值返回給客戶端。

2.2 漢-維地址翻譯接口說明

本文研發(fā)的系統(tǒng)是基于web 的網(wǎng)絡(luò)服務(wù)接口，接口說明以及調(diào)用參數(shù)對使用者很重要，下面詳細(xì)介紹漢維地址翻譯服務(wù)接口的調(diào)用參數(shù)、調(diào)用示例以及服務(wù)接口的返回結(jié)果。具體的，接口調(diào)用參數(shù)信息如表1所示，接口調(diào)用示例如表2 所示，接口返回示例如表3所示。

表1 接口調(diào)用參數(shù)表

其中text 表示帶翻譯文本，from 與to 分別是源語言和目標(biāo)語言語種，appkey 是用戶秘鑰，format 是輸入?yún)?shù)格式，task 參數(shù)表示為任務(wù)類型，用戶根據(jù)需求可以選擇使用通用的機(jī)器翻譯模型（NMT）或者是地址翻譯模型（AddrNMT）。

表2 接口調(diào)用示例表

表3 接口服務(wù)返回示例表

服務(wù)接口返回結(jié)果中，text 表示模型翻譯結(jié)果，code 參數(shù)是本次請求的狀態(tài)，通過code 代碼可便于發(fā)現(xiàn)錯誤原因，不同的code 代碼有不同的含義，如果code 是200 表示當(dāng)前請求成功，如果是0 說明接口服務(wù)內(nèi)部出現(xiàn)異常，如果是500 表示服務(wù)器內(nèi)部錯誤等。

2.3 系統(tǒng)演示

另外，為了方便演示本文設(shè)計了在線地址翻譯頁面，系統(tǒng)效果如下圖4 所示。

系統(tǒng)頁面功能解析：

上側(cè)框：輸入待翻譯文本；

中間部分：用戶根據(jù)自己的需求可以選擇模型以及翻譯語言方向等；

下側(cè)框：顯示翻譯結(jié)果。

圖4 漢維地址翻譯頁面

系統(tǒng)工作流程：

（1）點擊翻譯按鈕以后客戶端將待翻譯的文本以及用戶所選擇的內(nèi)容打包JSON 格式請求發(fā)送給Web服務(wù)接口；

（2）服務(wù)端解析用戶請求之后把待翻譯內(nèi)容傳給翻譯模型；

（3）翻譯模型經(jīng)過大量的計算將文本內(nèi)容進(jìn)行翻譯并把結(jié)果返回給客戶端。

3 實驗

3.1 實驗環(huán)境

本文實驗在Ubuntu 18.04 操作系統(tǒng)上進(jìn)行，硬件環(huán)境為Intel Core i5-9400F CPU @ 2.90GHz 處理器，2塊 NVIDIA GeForce RTX 2080 Ti（11GB），32G 內(nèi)存以及500G 硬盤。使用的軟件環(huán)境有Ubuntu 18.04 版本的 64 位操作系統(tǒng)，Python3.6、PyTorch1.0、Django3.0、uwsgi2.0.15 以及Nginx1.12.1 版本。地址翻譯模型使用OpenNMT 工具，通過Transformer_base 參數(shù)在單個GPU 卡上訓(xùn)練。

3.2 實驗結(jié)果與分析

為了更正確的測試本文漢維地址翻譯服務(wù)接口并發(fā)量以及相應(yīng)速度兩個方面的性能，本文利用2000 條文本地址對接口進(jìn)行多線程測試。為了更全面驗證，分別測試三次，最后將三次的相應(yīng)時間與成功次數(shù)求平均。主要的測試結(jié)果如表4 所示。其中，成功次數(shù)是指請求成功的個數(shù)，相應(yīng)時間是接口所花費處理所有請求的時間，每秒翻譯個數(shù)是指平均每秒處理的地址文本個數(shù)。

表4 漢維地址翻譯服務(wù)接口測試結(jié)果

表4 的實驗結(jié)果可以看出系統(tǒng)具有比較穩(wěn)定的速度和并發(fā)量，當(dāng)線程數(shù)量分別 1，16，64，128 的時候沒有數(shù)據(jù)包丟失的情況，而隨著并發(fā)量的繼續(xù)增加系統(tǒng)出現(xiàn)丟失數(shù)據(jù)包的情況，線程數(shù)量為200 每批1 個句子的時候平均丟失了20 個請求包。從平均每秒翻譯的句子個數(shù)來看：單線程每批翻譯一個句子的時候平均每秒翻譯的句子個數(shù)為3.78 個；當(dāng)線程數(shù)量128，每批50 個句子的時候平均每秒翻譯個數(shù)為46.03；當(dāng)線程數(shù)量200，每批50 個句子的時候平均每秒翻譯個數(shù)為44.40。這說明系統(tǒng)不丟失數(shù)據(jù)的情況下并發(fā)量128左右，每批50 個句子的時候達(dá)到比較好的結(jié)果。由于實驗環(huán)境的局限性，本文實驗使用一臺服務(wù)器和兩張GPU 卡進(jìn)行的，分析系統(tǒng)的翻譯速度和并發(fā)量，該項工作具有一定的實踐意義。

4 結(jié)語

本文使用PyTorch 深度學(xué)習(xí)框架與OpenNMT 工具構(gòu)建了完全注意力機(jī)制的漢維地址翻譯模型，并使用簡單易學(xué)的Django Web 框架編寫網(wǎng)絡(luò)接口，然后通過一款優(yōu)秀的Web 服務(wù)器UWSGI 和輕量級反向代理服務(wù)器Nginx 來實現(xiàn)負(fù)載均衡，最終實現(xiàn)了Django +UWSGI+Nginx 架構(gòu)的穩(wěn)定并具有并發(fā)量的漢維地址翻譯服務(wù)接口。由于實驗環(huán)境的局限性，本文只用一臺服務(wù)器進(jìn)行實驗，但是實際應(yīng)用中模型翻譯質(zhì)量、速度以及并發(fā)量要求更高，未來將進(jìn)一步對地址翻譯任務(wù)模型與工程方面進(jìn)行更深入的探索。