客服聊天機器人用 LLM API

正式應用中的客服聊天機器人

SaaS 客戶詢問為何同一張帳單被扣款兩次。 客服服務取得最新帳務政策與已遮蔽個資的帳單狀態，再要求模型依據資料回答，或回傳轉交人工的資料。

模型不能自行退款，也不能捏造帳戶狀態。 身分未確認、資料互相矛盾或帳務工具失敗時，附摘要與來源 ID 轉交人工。

客服聊天機器人流程如何運作

• 分類請求並確認身分驗證要求。
• 取得核准政策與已遮蔽個資的帳戶資料。
• 產生附內部來源 ID 的回答，或轉人工資料。
• 確認每個說法都有依據。
• 執行有重大影響的帳戶操作前，先轉交人工。

透過 LLMFly AI 呼叫 gemini-2.5-flash

從伺服器送出請求，將範例內容與預留工具格式換成應用的資料與工具。

curl https://app.llmfly.ai/v1/chat/completions \
  -H "Authorization: Bearer $LLMFLY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gemini-2.5-flash",
    "messages": [
      {"role": "system", "content": "Answer only from SOURCES and ACCOUNT_FACTS. If evidence is missing, identity is unverified, or an action requires permission, return ESCALATE with a concise reason."},
      {"role": "user", "content": "The customer says this invoice was charged twice. Explain the status or escalate."}
    ],
    "response_format": {"type": "json_object"}
  }'

為什麼以 gemini-2.5-flash 為主要模型

大量且回答範圍、轉人工規則明確的客服請求，預設使用 Gemini 2.5 Flash。請用自己的工單確認語言品質與政策遵循。

Flash 未遵守回答規格時，改用已測試的 Terra。 複雜的政策衝突或需要多個工具的帳戶問題，交給 Sol 或人工。

客服聊天機器人驗收檢查

部署前要處理的失敗

• 不惜代價追求不轉人工
• 讓機器人捏造政策
• 傳送不必要的敏感資料
• 只衡量單次回合

回傳輸出與執行紀錄

回傳附內部來源 ID 的有據回答，或結構化的轉人工原因。

每次正式執行記錄模型 ID、請求 ID、token 用量、重試、驗證結果與最終處理。