情境
正式應用中的多語言聊天機器人
旅遊產品支援英語、日語、西班牙語與中文。 系統判定對話語言與地區，載入對應產品詞彙表與政策片段，再要求模型回答並保留指定產品名稱。
品質依各語言分別評估。 不能只因平均分數高就上線；必須先由當地母語者確認意圖、詞彙、語氣與拒答方式。
正式環境場景
多語言聊天機器人用 LLM API
旅遊產品支援英語、日語、西班牙語與中文。 系統判定對話語言與地區，載入對應產品詞彙表與政策片段，再要求模型回答並保留指定產品名稱。
正式環境實作
API、主要模型與備援設定
| 正式環境選擇 | 建議 | 原因 |
|---|---|---|
| API | POST /v1/chat/completions | OpenAI 相容伺服器端請求 |
| 主要模型 | gemini-2.5-flash | 多語言且要求低延遲的聊天，優先選擇 Gemini 2.5 Flash。 |
| 備援模型 | gpt-5.6-terra | Terra 僅用於通過相同母語者審查的語言。 政策密集或混合語言處理失敗的問題，交給 Sol 或人工。 |
| 升級模型 | gpt-5.6-sol | 只在主要路徑未達品質或複雜度門檻時使用 |
| 輸出規則 | 任務文字或修正 | 回覆符合當地語言習慣、保留指定詞彙，且不混入其他地區政策。 |
架構
多語言聊天機器人流程如何運作
- 分別判定語言與地區。
- 載入當地詞彙表與核准的政策片段。
- 直接以目標語言生成。
- 檢查指定詞彙、數字與政策用語。
- 不支援或信心不足的語言，轉交人工。
API 請求
透過 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": "Reply in the detected locale. Preserve GLOSSARY terms exactly. Use only the supplied locale policy and do not translate protected product names."},
{"role": "user", "content": "Explain the cancellation window in the customer's language using the locale policy."}
]
}'模型選擇
為什麼以 gemini-2.5-flash 為主要模型
多語言且要求低延遲的聊天，優先選擇 Gemini 2.5 Flash。
Terra 僅用於通過相同母語者審查的語言。 政策密集或混合語言處理失敗的問題，交給 Sol 或人工。
驗收
多語言聊天機器人驗收檢查
| 指標 | 通過條件 |
|---|---|
| 意圖保留 | 各支援語言都維持原本要求的操作與限制 |
| 詞彙準確度 | 指定產品、法律與專業詞彙符合當地詞彙表 |
| 母語者接受度 | 母語者無須大幅改寫就能接受含義、語氣與流暢度 |
| 各語言延遲與成本 | 每個上線語言都符合自己的回覆時間與對話成本預算 |
失敗處理
部署前要處理的失敗
- 以為英文表現能代表所有語言
- 機器翻譯整個評估集
- 忽略當地政策
- 用平均分掩蓋弱勢語言
輸出
回傳輸出與執行紀錄
回覆符合當地語言習慣、保留指定詞彙，且不混入其他地區政策。
每次正式執行記錄模型 ID、請求 ID、token 用量、重試、驗證結果與最終處理。
常見問題
可以使用翻譯自英文的提示詞嗎？
意圖、語氣、詞彙與政策因地區而異，請使用當地語言的原生範例。
一個模型應處理所有語言嗎？
只有各語言測試通過才適合；按語言分配給分別驗證的模型可能更穩妥。
如何測試混合語言訊息？
使用真實混合語言訊息，確認意圖與必要詞彙都保留。
用自己的輸入測試設定
以相同請求、工具與驗證規則比較主要和備援模型。