Skip to main content

案例研究 - 錯誤處理機制：有無 handle 的差異

錯誤處理機制​

在編排 workflow 時，常常會需要處理錯誤的機制，Asgard 教你一個錯誤處理的小技巧，讓你可以重複使用處理錯誤的流程。

Step 1：Exit & Entry 讓錯誤統一回到情境判斷的 LLM 錯誤處理​

調用外部AI模型的LLM Completion，預設都會帶有Success與Failure方便處理兩種不同條件的路徑，由於調用外部AI模型，需要考慮到模型的計算能力以及其所能支援方案的門檻等，並非每一筆對AI模型的請求都能成功存取，因此需要處理failure的流程。

Exit​

在「客服情境」裡新增Exit並修改名稱與描述為「流量控管」。此時的Exit會作為接續其他工作流程的傳送點，統一將有錯誤的LLM導向到飯店QA的錯誤提示訊息流程。請將客服情境中有關LLM Completion處理Failure的節點連接到「流量控管」的傳送點。

Entry​

回到飯店 QA 的 Workflow 並新增一個進入點，可直接點擊上方的飯店 QA 回到 Workflow Sets 選取或是使用頂端列的選單切換，新增後修改名稱與描述為「LLM錯誤處理進入點」，並將該節點連接到原先設定的Push Message節點。

將 Exit（流量控管）與Entry（LLM錯誤處理進入點）連接便完成了 LLM 的錯誤流程處理，並能將用戶導向到先前設計的 Push Message 去提示用戶目前流量控管中。

Step 2：Update Context 清除歷史對話​

提示流量控管中後，需要讓用戶回到聆聽問題並判斷情境的 Listen Message 節點，此時需要清除先前的歷史對話訊息。請接續 Push Message 後面新增一個 Update Context 的 Processor 來幫助我們清除歷史對話作為情境判斷用。

  • 屬性點擊「＋」新增一個空白的變數
  • 命名為 historyStart
  • Type 請選 Expression 並輸入以下範例。
  • Optional: 可以將 Processor 的 Description 改成容易識別的描述幫助工作流程的編排易讀性，例如改成「清除對話紀錄」
  • 儲存設定
(() => {
  // return the result of the expression
  return historySize();
})()

historySize為 Asgard 內建函數，historyStart 為先前在 Update Context 裡所新增的變數，historySize 是指訊息的總量，每一則訊息都會記算一筆，算到上一個對話為止，因此這裡是將 historyStart 更新為 historySize，藉此清除歷史對話訊息。

清除完後將 Update Context 連接到原先的 Listen Message 節點即完成。

Step 3：預覽 Bot​

點擊 Preview 來預覽並測試以下情境：

測試一：LLM 模型錯誤處理​

在客服情境用來生成關鍵字句的 LLM Completion Processor，藉由調整 MaxTokens 來模擬消耗 Token 不足的情境，促使進入錯誤處理的流程。請將MaxTokens由 4096 改成 10 並儲存設定後預覽。

由於 AI 模型耗用 Token 不足，因此該流程會統一導向 LLM 錯誤處理的進入點並顯示設定好的錯誤訊息，範例為「系統忙碌中」。

測試二：LLM 模型正常運作​

將 LLM Completion Processor 的 MaxTokens 調整回去4096 儲存設定後預覽。