Azure NLP(自然語言處理)介紹

自然語言處理支援可以看、聽、與使用者交談和理解使用者的應用程式。 使用文本分析(text analytics)、翻譯和語言理解服務。

文本分析(text analytics)

分析文本是一個過程，是評估文件或短語的不同層面，以便深入了解該文本的內容。 在大多數情況下，人類能夠閱讀一些文本並理解其背後的含義。 即使不考慮文本所用語言的文法規則，也可以在文本中識別出特定的見解。

例如，人類可以閱讀文件後總結文件的意思。 也可能還會認出人名或著名地標，例如東京晴空塔。甚至認知到該文本想要幫達的情感。

文本分析技術

文本分析是一個過程，在該過程中，在AI演算法會評估文本中的這些相同屬性，以獲得特定的見解。 一個人通常會依靠自己的經驗和知識來獲得見解。 而我們必須為電腦提供類似的知識才能執行該任務。 有一些常用技術可用於構建分析文本的方法，包括：

• 文本中使用的術語的統計分析。 例如，去除常見的“停用詞”（像“哦”這樣的詞，基本上它們沒有甚麼意義），並對剩餘的詞進行頻率分析（計算每個詞出現的頻率）可以提供關於文本的線索 文本的主要主題。
• 將頻率分析擴展到多詞短語，通常稱為 N-gram（兩個詞的短語是 bi-gram，三個詞的短語是 tri-gram，等等）。
• 在對單詞進行計數之前，使用stemming 或lemmatization 演算法對單詞進行正規化 — — 例如，將“power”、“powered”和“powerful”等單詞解釋為同一個單詞。
• 使用linguistic structure rules來分析句子 — — 例如，將句子分解成樹狀結構，如名詞短語，它本身包含名詞、動詞、形容詞等。
• 將單詞或術語編碼為可用於訓練機器學習模型的數字特徵。 例如，根據文本文件包含的術語對文本進行分類。 該技術通常用於執行情感分析，其中將文件分類為正面或負面。
• 建立vectorized models，通過將單詞分配到 n 維空間中的位置來擷取單詞之間的語義關係。 例如，這種建模技術可能會為“狗”和“動物”這兩個詞分配值，使它們彼此靠近，而“汽車”可能會被分配一個值，使它們相距更遠。

雖然以上這些技術可以發揮很大的作用，但自行開發它們可能要花很大的代價。 Azure Cognitive Services可以通過使用預訓練模型來幫助簡化應用程式開發，這些模型可以：

• 確定文本的語言（例如，中文或英文）
• 對文本執行情緒分析以確定正面或負面情緒。
• 從可能表明其主要談話要點的文本中提取主要語句
• 識別和分類文本中的實體。 實體可以是人、地點、組織，甚至是日期、時間、數量等日常用品

語音的識別和合成

現行AI能夠接受語音命令並提供語音回應。 我們可以通過與它們交談來控制它們 — — 發出諸如“關燈”之類的命令，並要求語音回應諸如“今天會下雨嗎？”之類的問題。

為了實現這種與AI的互動，AI必須要有以下兩種能力：

• 語音識別 — — 偵測和解釋人類說話的能力。
• 語音合成 — — 產生人類說話的能力。

語音識別

語音識別涉及擷取人類說話並將其轉換為可以處理的資料 — — 通常是通過將其轉錄為文本(就是文字化)來呈現。 所說的話可以是音檔中錄製的語音，也可以是來自麥克風的即時語音。 分析音檔中的語音模式以確定對應到單一詞彙的可識別模式。 ，實現這種方式的軟體通常使用多種類型的模型，包括：

• acoustic model — 將音頻信號轉換為phonemes（特定聲音的呈現）
• language model一種將phonemes對應到單一詞彙的語言模型，通常使用統計演算法根據phonemes預測最可能的單一詞彙序列。

語音合成

語音合成在許多方面與語音識別相反。 它關注音檔資料，通常是通過將文本轉換為語音。 語音合成解決方案通常需要以下資訊：

• 要朗讀的文本
• 用於發聲的語音

為了合成語音，系統通常將文本標記化(tokenizes)以將其分解為單一單詞，並為每個單詞分配語音。 然後它將音標分解為韻律單元( prosodic units)（例如短語、子句或句子）以建立將轉換為音頻格式的phonemes。 然後通過應用聲音將這些phonemes合成為音頻，這將決定音高和音色等參數； 並產生可以輸出到揚聲器或寫入文件的音頻。

Microsoft Azure 的Speech cognitive service提供語音識別和語音合成功能，其中包括以下API：

• The Speech-to-Text API
• The Text-to-Speech API

speech-to-text API

Speech-to-text API 將音頻即時或批量轉錄為文本格式。 轉錄的音頻源可以是來自麥克風的real-time audio stream或音頻檔案。

Speech-to-text API 使用的模型基於微軟訓練的通用語言模型(Universal Language Model)。 該模型的資料由 微軟部署到Azure。 該模型針對兩種場景進行了優化，會話和聽寫。 如果微軟的預建的模型不能滿足需求，我們可以訓練自己的模型，包括聲學、語言和發音。

text-to-speech API

當您使用text-to-speech API 時，我們可以指定要用於發聲文本的聲音。該服務包括支持多種語言和區域發音的多種預定義語音，包括標準語音以及利用神經網路克服語音合成中關於語調的常見限制的neural voices，從而產生更自然的聲音。 我們還可以自行開發語音並將它們與text-to-speech API 一起使用。

關於支援的語言清單可以參考以下文件連結:

• Speech-to-text languages
• Text-to-speech languages

使用對話式語言理解來建立語言模型

如果你知道英國數學家艾倫圖靈，哪麼你一定知道圖靈測試。所謂圖靈測試是指假設如果對話足夠自然，我們有可能不知道我們是在與人交談還是與電腦交談。 就是聊天機器人，例如目前最火紅的CheatGPT。

為了達成圖靈測試，電腦不僅需要能夠接受語言作為輸入（文本或音頻格式），而且能夠解釋輸入的語義 — — 換句話說，理解什麼人類 正在說甚麼。

Azure使用 Language Service支援對話式語言理解。 要使用對話語言理解，我們需要考慮三個核心概念：表達方式(utterances)、實體(entities)和意圖(intents)。

表達方式(utterances)

人類表達的方式，而電腦要能理解。例如

開電視

開燈

實體(entities)

實體是表達方式裡的一個事物。例如上面兩個標達方式中，電視與燈就是實體。

意圖(intents)

這是指人類表達的語句中想要完成甚麼目的。例如上面的範例中都是要打開某項設備。所以在對話語言中我們可以定義一個與這些語句有關"開啟"的意圖。

語言理解應用程序定義了一個由"意圖"和"實體"組成的模型。 表達方式(utterances)用於訓練模型，以根據特定的輸入識別最有可能的意圖和應該套用它的實體。 例如以下範例：

上表中，每個意圖都有許多表達方式。 意圖應該是對表達方式作業進行分組的簡潔方式。 特別要注意的是 None 意圖(也就是空白，甚麼都沒有)。 我們應該使用 None 意向來幫助處理還沒又對映到的任何表達方式。 None 意圖被視為是fallback，通常用於在回應給使用者當AI不理解人類的意圖時的所有回應。

建立一個對話語言理解包括兩個主要任務。 1)必須定義用於訓練語言模型的實體、意圖和表達方式 — 稱為authoring the model。 2)發布該模型。

Authoring

建立authoring resource後，我們使用它來創作和訓練對話語言理解應用程序，方法是定義我們的應用程序將預測的實體和意圖以及可用於訓練預測模型的每個意圖的表達方式。對話式語言理解 有一個很全面的訓練好的模型可以使用，我們也可以把它拿來調整成自己要的。我們可以編寫代碼來定義模型的元素，但在大多數情況下，使用 Language Understanding portal 建立模型是最簡單的。

建立意圖

對於每個意圖，我們應該包括多種的表達方式，以提供使用者一些表達意圖的範例。如果一個意圖可以應用於多個實體，請確保包含每個潛在實體的樣本表達方式； 並確保在表達方式中識別出每個實體。

建立實體

通常有以下四種類型的實體:

• Machine-Learned:模型在訓練期間從我們提供的範例表達方式中的上下文學習的實體。
• List:這是一個清單和子清單的層次結構實體。例如，設備清單可能包含燈和電視的子清單。 對於每個清單條目，我們可以指定同義詞，例如電視等同意液晶電視機。
• RegEx:u 一種模式的正則表達式(regular expression)的實體 — 例如，以定義 [A-Z][0–9][0–9][0–9][0–9][0–9][0–9][0–9][0–9][0–9] 這樣的模式就是身分證字號
• Pattent.any:沒有辦法從一些範例表達方式提取實體，需要一些特定的模式才可以

使用Azure Language Service與 Azure Bot Server建立聊天機器人

現行聊天機器人可以用在許多的場合，如：

• 語音通話
• 訊息服務
• 線上客服
• 電子郵件
• 社交媒體平台
• 協同作業工具

現在的消費者已經被養成的吹毛求疵的奧客。 對於企業所提供的服務或商都都希望能夠立刻收到回覆，並能應對複雜的問題。但老實說，你們(消費者)才付出少錢啊，要求一大堆。

對話通常是一問一答的形式。 這種模式構成了對應消費者的基礎，並且通常基於現有的常見FAQ文件。 要實施此類解決方案，我們需要：

• FAQ的知識庫 — — 通常帶有一些內建的自然語言處理模型，使可以用多種方式表達的問題能夠以相同的語義理解。
• 一種機器人服務，通過一個或多個管道提供連接知識庫的介面。

對應上面兩種需求，Azure提供兩種服務:

• Language service.
• Azure Bot services.