ASR項目實戰-架構設計

一般而言，業務訴求作為架構設計的輸入。

需求清單

對于語音識別產品而言，需滿足的需求，舉例如下：

功能需求

文件轉寫。

長文件轉寫，時長大于60秒，小于X小時，X可以指定為5。

短文件轉寫，時長小于60秒。

實時語音識別。

長語音識別，時長大于60秒，小于Y小時，Y可以指定為5。

短語音識別，時長小于60秒。

支持多個語種。

其它功能需求，比如：

前處理

支持多種音頻文件格式。

支持多種采樣率和位深。

支持去回聲和抗噪。

支持在音頻文件中處理多個聲道。

中間處理

支持VAD。

支持區分音頻文件中的多個講話人。

支持輸出文本對應的時間偏移。

支持使用熱詞提高字準率。

后處理

支持輸出標點符號。

支持輸出拼音類語言的大、小寫。

支持數字、符號的歸一化處理。

非功能需求

集成多個合作伙伴。

云云對接，即將請求轉發給合作伙伴開放在公網的API服務，通過公網API訪問的形式集成其語音識別能力。

集成軟件包，即將合作伙伴的語音識別服務部署在相同的機房內，通過內網API訪問的方式集成其語音識別能力。

集成算法庫，集成合作伙伴的語音識別能力。

集成算法模型，基于相同的算法庫，合作伙伴提供模型，進而集成其語音識別能力。

控制并發路數。

通過接口接入的基礎設施，限制并發TPS。

基于當前可用的并發路數，限制可以接入的請求數量。

基于各個應用的業務推廣情況，定義并發路數的最低、最高配額，保證基本的并發路數。

基于各個應用的業務實際情況，定義調用量的最高配額，控制調用量。

支持擴容。

通過擴容硬件的方式，增加服務能力。

針對某具體應用的實際情況，通過擴容，滿足其業務訴求。

針對某具體業務場景的實際情況，通過擴容，滿足其業務訴求。

技術指標

文件轉寫場景下的時延類指標，比如

轉寫比，即端到端處理時長與語音文件時長的比值。這個指標不是越小越好，需結合投入的硬件成本綜合考慮，定義符合預期的指標目標值。

語音識別場景下的時延類指標，比如

首字時延

尾字時延

蹦字時延

模型文件的大小，影響如下：

決定了軟件包版本構建的時間、安裝服務的時間、啟動服務的時間，是影響版本交付效率的直觀因素。

模型文件占用的空間越大，則加載模型后，進程占用的內存空間則越大。這對硬件規格和技術方案、部署方案有直接的影響。

一定載荷下可提供的并發路數。

運營類需求

支持記錄具體應用使用語音識別服務的業務調用量。

支持基于調用量，對具體應用進行計費。

運維類需求

提供日志，比如：

提供業務調試日志。

提供接口訪問日志。

提供監控能力。

提供對基礎設施的監控，比如CPU使用率、內存使用率、硬盤使用率等，以及必要的告警。

提供對業務組件的監控，比如進程是否存在，進程的CPU、內存使用率等，以及必要的告警。

提供對關鍵業務指標的監控，比如當前各服務實例在用、可用的并發路數，各業務可用、在用的并發路數等。

安全類需求

在云服務API層面增加保護，比如：

提供鑒權能力。

提供參數校驗能力。

抵御DOS攻擊的能力。

對用戶數據的管理，包括但不限于：

使用安全通道傳輸用戶數據。

使用加密方式保存用戶數據。

允許用戶刪除數據。

允許用戶指定數據的保存周期。

用戶未提供數據保存周期時，系統支持自動刪除。

架構方案

基于前述舉例列出的需求，整體方案中包括如下組件：

業務類組件

接入網關

安全網關

業務網關

算法服務

支撐類組件

運維服務

運營服務

開發者服務

接入網關

主要職責有：

對外提供安全協議的請求通道，比如HTTPS。

限制業務請求的速率。

基于協議規則的請求流控。

安全網關

主要的職責是對外部發來的請求進行鑒權，攔截非法請求。

當鑒權通過時，補充必要的數據字段，比如應用標識等。

業務網關

主要的職責有：

對請求消息中的字段，進行校驗，從而攔截非法請求。

依據請求消息，依據一定的業務規則，選擇合適的算法服務來提供服務。

依據一定的業務規則，從指定的算法服務的集群中，挑選一個實例來提供服務。

記錄業務調用量。

記錄計費數據。

記錄必要的運維數據。

記錄必要的調試日志。

基于業務規則的請求流控。

算法服務

算法服務，提供語音識別的基本能力。

依據與合作伙伴的協作方式，算法服務包含如下類型：

云云集成，請求轉發至合作伙伴開放在公網的API服務。

軟件包集成，合作伙伴的軟件包和自有的組件部署在相同的基礎設施上，算法服務與其通過內網API的方式集成。

算法庫集成，使用JNI方式，算法服務集成合作伙伴提供的算法庫文件。

算法模型集成，算法服務集成模型，提供服務。

運維管理服務

主要職責是供運維人員管理、分析業務系統運行情況，包含的內容比較廣，比如：

軟件倉庫

部署管理

配置管理

運維數據管理

采集系統

離線監控系統

在線監控系統

告警系統

運營服務

主要職責是供產品、運營人員分析業務運行現狀，比如：

運營數據管理

采集系統

報表系統

告警系統

開發者服務

主要職責是供開發者管理業務的運行情況，比如：

訂閱服務

計費報表

技術決策點

劃分業務組件中各個組件的職責時，存在一些決策點，對設計方案存在影響，因此需要深入考慮。

語音識別過程可以劃分為前、中、后三階段的處理操作，依據前述架構方案，結合業務場景，需要思考這三個階段在分別哪個業務組件上交付。

關于前處理

對于實時語音識別，假如使用手機作為錄音設備，則可以限定錄制時使用的音頻文件格式、采樣頻率、位深、聲道的數量，去回聲和搞噪可以交給錄音設備來完成，因此不涉及復雜的前處理。

對于文件轉寫，則無法限定音頻數據文件的錄制設備、文件格式、采樣頻率、位深、聲道數量、錄制環境等，因此需要支持前處理。相關的前處理特性，可能的實現位置有業務網關或者算法服務。

假如前處理在業務網關組件上實現，則下載文件、提取音頻時長、記錄計費數據、記錄計量數據、基于業務規則的請求流控等可以一并實現。前處理的音頻文件，需要將上傳至公共存儲，由算法服務下載。

本方案的優點：

在業務網關層面可以實現文件有效性的檢查，避免將非法文件傳遞至算法服務，浪費算法服務器的算力。

在業務網關層面實現基于業務規則的請求流控，提前攔截非法請求，避免浪費算法服務的算力。

本方案的缺點：

業務網關和算法服務需要通過存儲服務來傳遞音頻文件，算法服務多了一次下載文件的操作。

假如前處理在算法服務上實現，業務網關組件只需轉發請求，而下載文件、提取音頻時長、記錄計費數據、記錄計量數據、基于業務規則的請求流控等特性均需要在算法服務來實現。

本方案的優點：

只涉及一次下載文件的操作。

本方案的缺點：

算法服務組件的數量比較多，假如音頻文件保存在公網的存儲服務上，則均需要開放外網訪問權限。

對于文件有效性的檢查延遲到了算法服務組件，惡意的請求可能會占用算法服務的算力資源。

基于業務規則的請求流控延遲到了算法服務組件，同樣占用了算法服務的算力資源。

關于提取音頻文件中音頻數據的時長，處理音頻文件中多個聲道，目前比較簡單的方案是使用開源軟件FFmpeg來實現。但這款軟件存在一些問題，比如：

License非商業友好。

處理音頻文件時，比較消耗CPU。

為支持某些特定的音頻格式時，需要增加一些額外的編碼、解碼庫，編譯FFmpeg的過程比較曲折。此外，音頻格式涉及到的開源軟件，其License可能非商業友好。此外，部分項目的代碼比較舊，長期無人維護，遇到問題時會比較尷尬。

偶爾會不穩定，對音頻文件執行操作時會失敗，但事后使用相同的音頻文件重現問題時，發現問題無法復現。

關于后處理

語音識別的結果中沒有標點符號，作為書面形式閱讀時會增加很多障礙，不同的句讀可能會產生不同的理解，從而出現不必要的歧義。對于中文而言，這個現象尤其嚴重。因此為了提升可讀性，需要在語音識別輸出的結果進行處理，增加必要的標點符號，比如句號、逗號、探號、問號等。

對于拼音類語言，比如英語、法語等，相同的單詞在不同場景下，其大小寫形式可能會不同，比如the President和the president，前者指代現總統，而后者僅為泛指。為了提升可讀性，需要對語音識別輸出的結果進行處理，增加合理的大、小寫形式。

對于數字、單位等詞匯，語音識別的結果中均表示為文字，與通常使用的書面表達形式不同，閱讀體驗比較差，因此有必要依據一定的規則或者場景將其還原為常見的表達形式，改善閱讀體驗。

針對上述三個特性，決策點有：

實現方案，使用機器學習模型實現，還是使用代碼基于一定的規則來實現。

實現位置，在業務網關實現，還是在算法服務實現。

架構設計 一句話識別

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。