基于Django 的漢維地址翻譯網絡服務的設計與實現

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

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

0 引言

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

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

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

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

1 相關模型及工具

1.1 機器翻譯模型

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

Transformer也是由編碼器和解碼器兩個部分組成。編碼器由一個多頭注意力網絡和一個簡單的全連接前饋神經網絡組成，中間添加了殘差連接，共有6層，每一層之間進行層標準化操作。解碼器是由兩個多頭注意力網絡和一個全連接前饋網絡組成，同樣是6層，也有殘差鏈接和層標準化操作。

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

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

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

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

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

Transformer 模型在摒棄了傳統的CNN 和RNN 網絡，表現更好的性能，可并行化，速度更快，同時能提升翻譯質量。

1.2 Django Web框架

Django 是基于Python 語言的開源Web 應用框架，發布于2003 年。Django 框架內部各個模塊聯結緊密，遵循 MVC（Model，View，Controller）設計規范，可以避免重復代碼。Django 簡單易學，具有很強的擴展性，具有模板系統以及強大的自帶后臺系統，是目前最受歡迎的Web 框架之一。

Django 采用MTV 的框架模式，其中M 表示模型（Model），與 MVC 中的 M 功能相同，映射業務對象，負責和數據庫交互，進行數據處理；T 表示模板（Tem?plate），與MVC 中的V 功能相同，負責封裝構造要返回的HTML，將頁面展示在瀏覽器上；V 表示視圖（View），與MVC 中的C 功能相同，負責接收請求，進行業務處理，返回應答，模型和業務之間協調業務邏輯關系。Django MTV 結構圖如圖1 所示。

圖1 Django MVT結構圖

1.3 UWSGI 與Nginx服務器

UWSGI 是一個全功能的 HTTP（HyperText Trans?fer Protocol）服務器，實現了 WSGI（Web Server Gateway Interface）的所有接口，是一個快速、自我修復、開發人員和系統管理員友好的Web 服務器。主要作用是把HTTP 協議轉化成語言支持的網絡協議。

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

圖2 Django+UWSGI+Nginx工作流程

2 設計與實現

2.1 系統整體架構

本文研究工作以Python 編程語言編寫，翻譯模型以PyTorch 深度學習框架搭建，由于神經網絡機器翻譯系統模型與結構復雜，參數龐大，使得翻譯速度變慢并且系統難以并行化。針對此問題，本文以Django +UWSGI+Nginx 架構設計實現了地址翻譯網絡服務，使得讓系統同時處理多個請求，從而翻譯速度與并發量兩個方面達到較好的工程要求。本文所設計的整體系統框架如圖3 所示。

圖3 系統整體框架圖

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

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

本文研發的系統是基于web 的網絡服務接口，接口說明以及調用參數對使用者很重要，下面詳細介紹漢維地址翻譯服務接口的調用參數、調用示例以及服務接口的返回結果。具體的，接口調用參數信息如表1所示，接口調用示例如表2 所示，接口返回示例如表3所示。

表1 接口調用參數表

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

表2 接口調用示例表

表3 接口服務返回示例表

服務接口返回結果中，text 表示模型翻譯結果，code 參數是本次請求的狀態，通過code 代碼可便于發現錯誤原因，不同的code 代碼有不同的含義，如果code 是200 表示當前請求成功，如果是0 說明接口服務內部出現異常，如果是500 表示服務器內部錯誤等。

2.3 系統演示

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

系統頁面功能解析：

上側框：輸入待翻譯文本；

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

下側框：顯示翻譯結果。

圖4 漢維地址翻譯頁面

系統工作流程：

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

（2）服務端解析用戶請求之后把待翻譯內容傳給翻譯模型；

（3）翻譯模型經過大量的計算將文本內容進行翻譯并把結果返回給客戶端。

3 實驗

3.1 實驗環境

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

3.2 實驗結果與分析

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

表4 漢維地址翻譯服務接口測試結果

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

4 結語

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