AI視頻剪輯工具：解鎖創(chuàng)作的無限可能
開發(fā)用于 CCAI 實現(xiàn)的 API 并非易事，可能面臨諸多挑戰(zhàn)，包括：
如果缺乏 API 平臺，實時轉(zhuǎn)換數(shù)據(jù)系統(tǒng)復(fù)雜性并高效轉(zhuǎn)發(fā)給調(diào)用者將非常困難。
通過 API 融入業(yè)務(wù)結(jié)構(gòu)時，CCAI 的效果更佳。添加的功能越多（API 也越多），簡化 API 集成流程就越重要。需要整合重復(fù)性工作，驗證安全狀況，并實施優(yōu)化，以確保良好的最終用戶體驗。
Apigee API Management 為更快、更輕松地實現(xiàn)這一目標(biāo)鋪平道路。Apigee 是一個直觀的平臺，供機(jī)器人設(shè)計師和架構(gòu)師將關(guān)鍵業(yè)務(wù)流程和見解融入工作流程。具體而言，Apigee 使 Dialogflow 能夠與后端系統(tǒng)對話。
Apigee 的內(nèi)置策略可用于檢查 Dialogflow 請求、設(shè)置響應(yīng)、驗證定義的參數(shù)以及實時觸發(fā)事件。例如，如果一次呼叫滿足定義的業(yè)務(wù)標(biāo)準(zhǔn)，Apigee 可以在 BigQuery 等數(shù)據(jù)倉庫中增強(qiáng)“360 度視圖”，將客戶添加到營銷活動列表中，或發(fā)送短信/文本提醒，所有這些都不會顯著影響路由時間。
通過將 CCAI 與 Apigee 配對，能夠充分利用 Google Cloud 轉(zhuǎn)換工具集，減少對話架構(gòu)師集成 API 所需的時間，創(chuàng)建更具凝聚力的開發(fā)環(huán)境以解決呼叫中心挑戰(zhàn)。
以下是用于 Dialogflow CX API 實現(xiàn)的 Apigee API 開發(fā)的一些最佳實踐：
假設(shè)有一個 Dialogflow CX 虛擬代理，需要由 Apigee 提供的三個實現(xiàn) API：
從技術(shù)上講，可以為每個 API 創(chuàng)建一個單獨的 Dialogflow CX Webhook，指向三個單獨的 API 代理。
然而，由于 Dialogflow 具有專有的請求和響應(yīng)格式，為這些履行 API 創(chuàng)建三個單獨的 API 代理會產(chǎn)生三個非 RESTful 代理，除了 Dialogflow CX 虛擬代理外，其他客戶端難以使用這些代理。
相反，建議創(chuàng)建一個通用 Apigee API 代理，負(fù)責(zé)處理所有履行 API。Dialogflow CX 將只有一個 Webhook，配置為將請求發(fā)送到通用 Apigee API 代理。每個 Webhook 調(diào)用帶有一個唯一標(biāo)識正確履行 API 的標(biāo)簽。
Apigee 提供了兩個特定于 Dialogflow 的策略：ParseDialogflowRequest 和 SetDialogflowResponse。強(qiáng)烈建議盡可能使用這些策略。
這樣不僅遵循了優(yōu)先選擇內(nèi)置策略而非自定義代碼的一般最佳實踐，還確保 Dialogflow 請求和響應(yīng)的解析與設(shè)置標(biāo)準(zhǔn)化、強(qiáng)化和高性能。
作為一般規(guī)則：
ParseDialogflowRequest 在 API 代理中僅需一次，并在身份驗證后放置在 PreFlow 中。SetDialogflowResponse 可用于每個不同的履行響應(yīng)（即，每個唯一的 Webhook 標(biāo)簽）。如果 SetDialogflowResponse 不滿足所有要求，可使用 AssignMessage 或 JavaScript 策略進(jìn)行補(bǔ)充或替換。
應(yīng)使用條件流來分離不同履行 API 的邏輯。實現(xiàn)此目的的最簡單方法是在 PreFlow 中放置 ParseDialogflowRequest 策略。添加該策略后，流變量 google.dialogflow.<Optional-prefix>.fulfillment.tag 將使用 Webhook 標(biāo)簽的值填充。然后，該變量可用于定義請求進(jìn)入特定條件流的條件。
以下是使用相同三個履行 API 的條件流示例：
Dialogflow CX Webhooks 有自己的請求和響應(yīng)格式，不遵循 RESTful 約定（如 GET 用于讀取、POST 用于創(chuàng)建、PUT 用于更新等），這使得傳統(tǒng)客戶端難以使用為 Dialogflow CX 創(chuàng)建的 API 代理。
因此，建議使用代理鏈。通過代理鏈，可以將 API 代理分為兩類：Dialogflow 代理和資源代理。
代理鏈提供了一種重用代理的方法。然而，當(dāng)調(diào)用從一個代理轉(zhuǎn)移到另一個代理時，可能會產(chǎn)生一些額外開銷。另一種方法是使用可重用共享流，開發(fā)明確設(shè)計為可重用的組件。共享流將策略和資源組合在一起，可抽象為共享庫，允許在多個位置使用的功能被捕獲。它們還使安全團(tuán)隊能夠標(biāo)準(zhǔn)化可信系統(tǒng)連接的方法和規(guī)則，確保安全合規(guī)性，同時不影響創(chuàng)新速度。希望以這種方式連接的代理必須位于同一組織和環(huán)境中。
在創(chuàng)建聊天機(jī)器人或任何其他自然語言理解增強(qiáng)型應(yīng)用程序時，響應(yīng)延遲是一個重要指標(biāo)。最大限度地減少延遲有助于保留用戶注意力，避免用戶懷疑機(jī)器人是否已損壞。
如果 Dialogflow 虛擬代理依賴的后端 API 響應(yīng)時間較長，可通過預(yù)取數(shù)據(jù)并將其存儲在 Apigee 的緩存中提高性能。可以包含令牌和其他元信息，這些信息可能直接影響客戶輸入與 Dialogflow 返回提示之間的時間。Apigee 緩存是可編程的，提供更大靈活性，從而提升對話體驗。可使用 Response Cache（或 Populate Cache）結(jié)合 Service Callout 策略實現(xiàn)數(shù)據(jù)預(yù)取和緩存。
使用 SetDialogflowResponse 策略響應(yīng)虛擬代理時，可通過 <Parameters> 元素一次返回多個值。該元素接受一個或多個子 <Parameter> 元素。如果可能，將單個參數(shù)作為 JSON 對象返回，通常比將響應(yīng)分解為多個參數(shù)（每個參數(shù)包含單個字符串或數(shù)字）更有效。可通過 <JSONPath> 利用此策略。
推薦這種方法的原因：
如果 Webhook 服務(wù)遇到錯誤，Dialogflow CX 建議返回某些 4XX 和 5XX 狀態(tài)碼，以通知虛擬代理發(fā)生錯誤。每當(dāng) Dialogflow CX 收到這些類型的錯誤時，會調(diào)用 webhook.error 事件并繼續(xù)執(zhí)行，而不向代理提供錯誤響應(yīng)的內(nèi)容。
然而，在某些情況下，履行 API 提供錯誤反饋是合理的，例如通知用戶電影不再可用或某個電影票無效。在這些情況下，考慮使用 200 HTTP 狀態(tài)碼進(jìn)行響應(yīng)，以提供關(guān)于錯誤是預(yù)期錯誤（如 404）還是意外錯誤（如 5XX）的上下文。
Apigee 的內(nèi)置策略、細(xì)致入微的安全方法、共享流和緩存機(jī)制提供了更順暢的方式來實施有效的虛擬代理，從而為最終客戶提供快速響應(yīng)。通過應(yīng)用這些最佳實踐，Dialogflow 工程師能夠有更多時間進(jìn)行創(chuàng)新，專注于構(gòu)建更好的對話體驗，而無需集成后端系統(tǒng)。
原文鏈接：Apigee best practices for Contact Center AI
