流程型代理程式基本概念

本文說明如何使用 Dialogflow CX 流程建構虛擬服務專員的基本概念。概略介紹最重要的概念。

代理

Dialogflow CX 代理程式是虛擬服務專員,可處理與使用者的並行對話。這種自然語言理解模組可以解讀人類語言的細微差異。Dialogflow CX 會將使用者在對話期間提供的文字或音訊內容轉譯為應用程式與服務可以解讀的結構化資料。您可以設計並建構 Dialogflow CX 代理程式來處理您的系統所需要的對話類型。

Dialogflow CX 代理程式與客服中心的真人客服專員類似,您可以訓練代理程式和客服專員來處理預期的對話情境,而且訓練內容不必過於明確。

流量數

複雜的對話通常會涉及多個對話主題。 舉例來說,披薩外送服務專員可能會將「餐點訂單」、「顧客資訊」和「確認」視為不同主題。每個主題都需要多個對話回合,服務專員才能從使用者取得相關資訊。

流程 用於定義這些主題和相關的對話路徑。每個服務專員都有一個名為「預設啟動流程」的流程。簡單的代理程式可能只需要這個單一流程。 較複雜的代理程式可能需要額外流程,而不同的開發團隊成員可負責建構及維護這些流程。舉例來說,披薩外送代理程式的流程可能如下所示:

多流程圖範例。

網頁

Dialogflow CX 對話 (工作階段) 可以描述為狀態機,並以視覺化方式呈現。工作階段的狀態以網頁表示。

您可為每個流程定義許多頁面,好讓這些頁面能夠合併起來,處理流程設計主題的完整對話。在任何時間點,只有一個頁面是目前頁面,目前頁面會視為有效,與該頁面相關聯的流程也會視為有效。每個流程都有專屬的開始頁面。流程最初啟用時,開始頁面會成為目前頁面。在每次對話中,目前頁面會維持不變或轉換至其他頁面。

您可以設定每個頁面,從使用者收集與頁面代表的對話狀態相關的資訊。舉例來說,您可能會在下方的圖表中建立頁面 (以藍色標示),用於披薩外送代理程式的「訂餐」流程。圖表的「Start」節點代表「Food Order」流程的開始頁面。完成流程後,系統會轉移至「確認」流程。

多流程圖範例。

實體類型

實體類型 可用來控管系統從使用者輸入內容中擷取資料的方式。

Dialogflow CX 提供預先定義的系統實體,可以比對許多常見的資料類型。舉例來說,您可以使用系統實體來比對日期、時間、顏色、電子郵件地址等。不過,您也可以自行建立自訂實體來比對自訂資料。舉例來說,您可以定義蔬菜實體,以便比對可在日用品商店代理程式中購買的蔬菜種類。

參數

參數 用於擷取及參照使用者在工作階段期間提供的 值。每個參數都有名稱和實體類型。不同於原始使用者輸入內容,參數是結構化資料,可輕鬆用於執行某些邏輯或產生回應。

表單

您可以為每個網頁定義表單,也就是要從網頁的終端使用者收集的參數清單。代理程式會與使用者進行多輪對話,直到收集到所有必要表單參數 (也稱為網頁參數) 為止。代理程式會依網頁上定義的順序收集這些參數。您也必須為每個必要表單參數提供提示,讓代理程式向使用者索取該資訊。這項程序稱為「填寫表單」

舉例來說,您可以建立表單,收集 Collect Customer Info 網頁的消費者姓名和電話號碼。

意圖

意圖可以將使用者在一個對話回合中的意圖歸類。

意圖包含下列資料:

字詞 定義
顯示名稱 顯示在控制台的意圖名稱。
標籤 有助於分類意圖的標籤。例如:head intent
訓練詞組 <0 訓練詞組是指使用者可能會輸入或說出的字詞範例,亦稱為使用者輸入內容。如果使用者輸入內容與其中一個詞組相近,Dialogflow CX 就會將其視為與意圖相符。您無須定義所有可能的範例,因為 Dialogflow CX 內建的機器學習技術會依據其他類似的詞組擴充清單。
參數 您定義的訓練詞組會使用參數,從使用者輸入內容的特定部分擷取值。
DTMF 模式 請參閱「電話整合的 DTMF」。

Webhook

Webhook 是代管商業邏輯或呼叫其他服務的服務。 在工作階段期間,您可以透過 Webhook 使用 Dialogflow CX 自然語言處理程序擷取的資料,產生動態回應、驗證收集到的資料,或在後端觸發動作。

Webhook 可以是標準 webhook彈性 webhook。 使用標準 Webhook 時,要求和回應欄位是由 Dialogflow CX 定義。使用彈性 Webhook 時,您可以定義要求和回應欄位。

Fulfillment

在代理程式的對話回合中,代理程式必須回應使用者提出的問題、查詢資訊或終止工作階段。代理程式也可能需要與服務聯絡,才能產生動態回應或採取行動。完成 所有這些操作。

出貨內容可能包含下列任一項目:

  • 靜態回應訊息。
  • Webhook 會呼叫動態回應和/或採取行動。
  • 參數預設集,可設定或覆寫參數值。

在代理程式的回合中,可以 (有時也應該) 呼叫多個完成動作,每個動作都可能會產生回應訊息。Dialogflow CX 會將這些回應保留在回應佇列中。 代理程式回合結束後,Dialogflow CX 會將排序過的回應傳送給使用者。

狀態處理常式

狀態處理常式 (也簡稱處理常式) 可建立回應給使用者,以及/或轉換目前頁面,藉此控制對話。系統會評估每個對話回合的處理常式,並可能影響工作階段。處理常式有三種一般資料類型:

字詞 定義
處理常式需求 如要讓處理常式對工作階段產生任何影響,必須滿足下列需求。如果處理常式符合需求並以某種方式影響工作階段,就會呼叫該處理常式。
處理常式執行要求 <0x0A 如果呼叫處理常式,系統會使用選用的執行要求,為使用者建立回應。這些回應可以是靜態代理程式資料中定義的回應,也可以是從 Webhook 服務動態擷取的回應。
處理常式轉移目標 如果呼叫處理常式,系統會使用選用的轉場目標來變更目前頁面。下一頁只能是流程開始頁面,或是目前有效流程中的頁面。

狀態處理常式分為兩種類型,處理常式需求也不同:

字詞 定義
路徑介面集 <0x0A 當使用者輸入內容符合意圖和/或滿足工作階段狀態的某些條件時,系統就會呼叫路徑。有意圖需求的路線也稱為「意圖路線」。只有條件規定的路線也稱為「條件路線」
事件處理常式 < 事件處理常式會在事件叫用時呼叫。 當系統收到非預期的使用者輸入內容,或發生 Webhook 錯誤時,會觸發部分內建事件。您也可以定義自訂事件,在對話以外發生事件時叫用。

處理狀態處理常式有三個步驟:

字詞 定義
1. 範圍 處理常式必須在範圍內,才能對工作階段產生任何影響。範圍取決於處理常式是否套用至流程、頁面或表單參數,以及相關聯的流程是否處於啟用狀態、相關聯的頁面是否處於啟用狀態,或是服務專員目前是否嘗試填寫相關聯的表單參數。
2. 評估 系統會依序評估範圍內的每個處理常式。如果處理常式符合規定,就會通過評估。
3. 撥打電話 如果處理常式在範圍內並通過評估,系統就會呼叫該處理常式。系統會呼叫任何相關聯的完成動作,並將任何相關聯的轉換目標套用至工作階段。

區域規劃與位置設定

建立代理程式時,您必須指定區域做為代理程式的位置。傳送至代理程式的要求會由這個區域的 Google 服務處理,且 Dialogflow CX 會將靜態資料保留在地理區域或位置內。為獲得最佳效能,請選擇鄰近服務和使用者的區域。

建立代理程式後,就無法變更其位置。 如要變更代理程式的位置,請匯出及還原至新代理程式,並使用不同的位置。

每個位置都有相關聯的設定,會套用至整個專案。 在大多數情況下,您不需要編輯這些位置資訊設定,預設設定即可正常運作。如果您的系統需要客戶管理的加密金鑰 (政府機構或受監管產業通常會要求),請進一步瞭解位置資訊設定

控制台

Dialogflow CX 提供名為「Dialogflow CX 主控台」的網頁版使用者介面 (參閱說明文件開啟主控台)。您可以使用這個主控台來建立、建構及測試代理程式。這項工具會將每個流程繪製成對話狀態機圖表,方便您設計及瞭解複雜的虛擬服務專員。

Dialogflow CX 主控台與 Google Cloud 主控台不同 (請參閱說明文件開啟主控台)。Dialogflow CX 控制台用於管理 Dialogflow CX 代理程式, Google Cloud 控制台則用於管理 Google Cloud專屬的 Dialogflow CX 設定 (例如計費功能設定) 和其他 Google Cloud 資源。

在大多數情況下,我們會建議您使用 Dialogflow CX 控制台來建構代理程式,但您也可以透過 Dialogflow API 建構適用於進階情境的代理程式。

整合

Dialogflow CX 提供多種內建整合功能,可與其他對話平台整合。這些整合功能會為使用者提供使用者介面,並為您呼叫 API。您只需要建構代理程式,並視需要實作 Webhook 服務。各項整合會以平台專屬方式處理互動,詳情請參閱特定整合的說明文件。

互動

每次對話輪流進行時,都會發生互動。 在互動期間,使用者會將輸入內容傳送至 Dialogflow CX, 而 Dialogflow CX 會傳送回應。 實作系統來處理互動時,有兩種方式可供選用:使用 API 或整合功能。

使用 API 時,系統必須處理下列事項:

  • 建構代理程式。
  • 為使用者提供使用者介面。
  • 針對每一回合的對話呼叫 Dialogflow API,將使用者輸入內容傳送至 API。
  • 除非代理程式回應完全是靜態 (不常見),否則您需要代管 Webhook 服務,以處理啟用 Webhook 的執行要求

使用整合時,系統只需要處理下列事項:

  • 建構代理程式。
  • 視需要實作 Webhook 服務。

下圖顯示一個對話回合的步驟。

API 流程圖。

  1. 使用者輸入或說出某項內容,稱為「使用者輸入內容」
  2. 使用者介面或整合系統會接收輸入內容,並透過偵測意圖要求轉送至 Dialogflow API。
  3. Dialogflow API 會收到偵測意圖要求。 這項函式會將輸入內容與意圖或表單參數相符、視需要設定參數,並更新工作階段狀態。如果需要呼叫已啟用 Webhook 的執行要求,系統會將 Webhook 要求傳送至您的 Webhook 服務,否則請前往步驟 6。
  4. Webhook 服務會收到 Webhook 要求。您的服務會採取任何必要動作,例如呼叫外部 API、查詢或更新資料庫等。
  5. Webhook 服務會建構回應,並將 Webhook 回應傳回 Dialogflow CX。
  6. Dialogflow CX 會建立偵測意圖回應。 如果系統呼叫了 Webhook,就會使用 Webhook 回應中提供的回應。如果沒有呼叫 Webhook,系統會使用在代理程式中定義的靜態回應。Dialogflow CX 會將偵測意圖回應傳送至使用者介面或整合系統。
  7. 使用者介面或整合系統會收到偵測意圖回應,並將文字或音訊回應轉送給使用者。
  8. 使用者看到或聽到回應。