Dialogflow Intent 與 Context 完整教學：打造聰明的多輪對話

為什麼有些聊天機器人感覺很笨，有些卻能像真人一樣對話？

關鍵在於「多輪對話」的設計。一個笨機器人每次都像第一次見面，聽完就忘。一個聰明的機器人會記住對話脈絡，理解你真正想要什麼。

Dialogflow 透過 Intent、Entity、Context 三大元素，讓你設計出能「記住」對話的機器人。這篇文章深入講解這些概念，教你打造真正聰明的 AI 對話。

如果你還不熟悉 Dialogflow 基礎，建議先閱讀 Dialogflow 完整指南。

---

Intent（意圖）詳解

Intent 是 Dialogflow 最核心的概念：使用者想要做什麼。

什麼是 Intent

當使用者說「我想訂位」，Dialogflow 需要理解這是「訂位」的意圖，而不是「查詢訂單」或「問營業時間」。

Intent 的工作流程：

使用者輸入 → NLU 分析 → 匹配 Intent → 執行回應
    │              │            │            │
「我要訂位」    意圖理解    make_booking    「好的，請問...」

Training Phrases 設計技巧

Training Phrases 是教機器人認識 Intent 的例句。寫得好，機器人辨識就準確。

技巧 1：提供多樣化的說法

不要只寫一種說法：

❌ 不好的例子（只有一種說法）：
- 我要訂位

✓ 好的例子（多樣化）：
- 我要訂位
- 想訂個位子
- 預約座位
- 可以幫我訂位嗎
- 我想預約
- 訂桌

技巧 2：覆蓋不同長度

- 訂位（極短）
- 我要訂位（短）
- 幫我訂明天晚上的位子（中）
- 你好，我想預約這週六晚上 7 點，4 個人用餐（長）

技巧 3：包含常見錯字

台灣用戶常見的錯字或口語：

- 定位（「訂」寫成「定」）
- 預月（「約」寫成「月」，注音誤觸）
- 我想book位子（中英混用）

技巧 4：使用 Entity 標註

在 Training Phrases 中標註 Entity，讓 Dialogflow 學會擷取資訊：

訂 @sys.date:date 的位子
→ 「訂明天的位子」會擷取 date = 明天

建議數量：

• 每個 Intent 至少 10-15 個 Training Phrases
• 重要的 Intent 可以到 30-50 個

Response 設定方式

Response 是機器人的回覆。有幾種設定方式：

1. 純文字回覆

最簡單的方式，直接輸入文字。可以輸入多個變體，Dialogflow 會隨機選擇。

- 好的，請問用餐日期是哪一天？
- 沒問題！請告訴我您想訂哪一天？
- 好的，我來幫您訂位。請問是哪一天用餐？

2. 包含參數的回覆

使用 $parameter_name 引用參數值：

好的，您想訂 $date $time，$party_size 位用餐，對嗎？

3. 平台專屬回覆

不同平台可以設定不同格式：

• LINE：Flex Message
• Messenger：Quick Reply
• 網頁：純文字

預設 Intent 說明

Dialogflow 自動建立的兩個 Intent：

Intent	觸發時機	建議設定
Default Welcome Intent	對話開始時	親切的問候 + 功能引導
Default Fallback Intent	聽不懂時	提供選項或轉人工

Fallback Intent 設計建議：

❌ 不好的回覆：
「抱歉，我聽不懂。」

✓ 好的回覆：
「不好意思，我沒有理解您的意思。您可以試試：
• 輸入「訂位」預約座位
• 輸入「菜單」查看餐點
• 輸入「客服」聯繫真人」

---

Entity（實體）進階

Entity 讓 Dialogflow 從使用者輸入中擷取有意義的資訊。

系統實體 vs 自訂實體

系統實體（System Entity）

Dialogflow 內建的實體，直接可用：

實體	用途	範例
@sys.date	日期	明天、1/15、下週一
@sys.time	時間	7 點、晚上 8 點半
@sys.number	數字	4、十、一百
@sys.phone-number	電話	0912345678
@sys.email	Email	[email protected]
@sys.url	網址	https://...
@sys.geo-city	城市	台北、高雄

自訂實體（Custom Entity）

針對你的業務需求建立：

Entity: @menu_item
Values:
- 炒飯
- 炒麵
- 牛排
- 義大利麵

同義詞設定

讓 Entity 認識同一個東西的不同說法：

Entity: @menu_item
Value: 炒飯
Synonyms: 蛋炒飯, 炒飯飯, 炒飯便當, fried rice

Value: 牛排
Synonyms: 牛排餐, 菲力牛排, steak, 排骨, 排餐

複合實體設計

當需要擷取複雜資訊時，可以組合多個實體：

Entity: @booking_info
Value: @sys.date @sys.time @sys.number 位
Example: 明天晚上 7 點 4 位

對話：
User: 我要訂明天晚上 7 點 4 位
→ 擷取：date=明天, time=19:00, party_size=4

建議：複合實體容易出錯，建議改用多輪對話分開詢問。

---

Context（上下文）深度解析

Context 是讓機器人「記住」對話的關鍵。沒有 Context，每次對話都像第一次。

Input Context / Output Context

Output Context：這個 Intent 觸發後，「設定」的 Context Input Context：這個 Intent 需要「存在」才能觸發的 Context

範例：訂位流程

Intent: start_booking
Input Context: (無)
Output Context: booking（lifespan: 5）
Response: 「好的，請問用餐日期是？」

Intent: provide_date
Input Context: booking
Output Context: booking_date（lifespan: 5）
Response: 「$date 收到，請問幾點用餐？」

Intent: provide_time
Input Context: booking_date
Output Context: booking_complete（lifespan: 2）
Response: 「$date $time，請問幾位用餐？」

效果：使用者必須先觸發 start_booking，才能觸發 provide_date。這樣可以防止使用者亂講話導致流程混亂。

Lifespan 生命週期設定

Lifespan 決定 Context 存活多少輪對話。

Lifespan	效果
0	立即移除這個 Context
1	只存活這一輪
5	存活 5 輪（預設）
10+	長時間記憶

設定建議：

• 短流程（2-3 步）：Lifespan 設 3-5
• 長流程（5+ 步）：Lifespan 設 10+
• 需要清除時：在結束 Intent 設定 Output Context lifespan = 0

多輪對話設計模式

模式 1：線性流程

開始 → 問日期 → 問時間 → 問人數 → 確認
 │        │         │         │        │
 └─ C1 ──┴── C2 ───┴── C3 ───┴─ C4 ───┘

每一步設定不同的 Context，確保順序執行。

模式 2：分支流程

        ┌─→ 內用流程 ─→ 問人數 → 問時間
開始 ──┤
        └─→ 外帶流程 ─→ 問品項 → 問取餐時間

根據使用者選擇，進入不同的 Context 分支。

模式 3：隨時跳出

在任何步驟都可以說「取消」跳出流程：

Intent: cancel_booking
Input Context: booking
Output Context: booking（lifespan: 0）  // 清除 Context
Response: 「已取消訂位，有其他需要嗎？」

Context 參數傳遞

Context 可以攜帶參數，讓後續 Intent 使用前面收集的資訊。

設定方式：

Intent: provide_date
Parameters:
  - date: @sys.date
Output Context: booking
  - 參數會自動帶入 Context

下一個 Intent 中使用：
Response: 您選的日期是 #booking.date

存取方式：

• 同名 Context：$parameter_name
• 指定 Context：#context_name.parameter_name

---

Agent 架構設計

當專案變大，Intent 和 Context 的管理變得很重要。

意圖分類策略

用命名規則分類：

訂位相關：
- booking.start
- booking.provide_date
- booking.provide_time
- booking.confirm
- booking.cancel

查詢相關：
- query.order_status
- query.menu
- query.hours

通用：
- common.greeting
- common.thanks
- common.help

好處：

• 在 Console 中排列整齊
• 一眼看出 Intent 屬於哪個功能
• 團隊協作更清楚

對話流程規劃

在開始建 Intent 之前，先畫出對話流程圖：

┌───────────────────────────────────────────────┐
│                  對話開始                       │
│              「你好，我是 XX 客服」              │
└───────────────┬───────────────────────────────┘
                │
    ┌───────────┼───────────┬───────────┐
    ▼           ▼           ▼           ▼
┌───────┐ ┌───────┐ ┌───────┐ ┌───────┐
│ 訂位  │ │ 查詢  │ │ 客訴  │ │ 其他  │
└───┬───┘ └───┬───┘ └───┬───┘ └───┬───┘
    │         │         │         │
    ▼         ▼         ▼         ▼
 [流程]    [流程]    [轉人工]   [FAQ]

設計原則：

• 主要功能不超過 5 個入口
• 每個流程控制在 3-5 步
• 永遠提供「返回」或「取消」選項

大型專案組織方式

方法 1：用 Context 前綴分組

booking_*：訂位相關 Context
order_*：訂單相關 Context
support_*：客服相關 Context

方法 2：考慮升級到 CX

如果 Intent 超過 50 個，建議改用 Dialogflow CX。CX 的 Flow 架構更適合大型專案。

詳細的 CX 教學請參考 Dialogflow CX 教學：從入門到進階。

---

對話架構越做越亂？Intent 和 Context 的規劃需要經驗，架構不好會讓專案難以維護。預約架構諮詢，讓有經驗的人幫你設計可擴展的架構。

---

Conditional Response 條件式回應

讓機器人根據不同情況給出不同回應，更像真人對話。

根據參數動態回應

場景：根據人數給不同回應

方法 1：在 Response 中使用條件（ES 不直接支援）

方法 2：使用 Fulfillment

function handler(agent) {
  const partySize = agent.parameters.party_size;

  if (partySize > 10) {
    agent.add('10 位以上需要預付訂金，請問可以嗎？');
  } else if (partySize > 6) {
    agent.add('好的，6 位以上幫您安排包廂，請問時間是？');
  } else {
    agent.add('好的，請問用餐時間是？');
  }
}

根據 Context 切換回應

場景：已經問過日期，不要重複問

function handler(agent) {
  const context = agent.context.get('booking_date');

  if (context) {
    const date = context.parameters.date;
    agent.add(`您之前選的是 ${date}，要改日期嗎？還是繼續？`);
  } else {
    agent.add('請問用餐日期是哪一天？');
  }
}

實作範例

完整的條件式訂位流程：

exports.dialogflowWebhook = (request, response) => {
  const agent = new WebhookClient({ request, response });

  function handleBooking(agent) {
    const { date, time, party_size } = agent.parameters;

    // 檢查是否是週末
    const bookingDate = new Date(date);
    const isWeekend = bookingDate.getDay() === 0 || bookingDate.getDay() === 6;

    // 檢查是否是熱門時段
    const hour = parseInt(time.split(':')[0]);
    const isPeakHour = hour >= 18 && hour <= 20;

    if (isWeekend && isPeakHour && party_size > 4) {
      agent.add('週末熱門時段大桌位置有限，建議提前 3 天預約。您確定要訂這個時段嗎？');
    } else if (isWeekend) {
      agent.add('週末用餐人較多，建議提早 10 分鐘到場。確認訂位嗎？');
    } else {
      agent.add(`好的，${date} ${time}，${party_size} 位，確認訂位嗎？`);
    }
  }

  const intentMap = new Map();
  intentMap.set('booking.confirm', handleBooking);

  agent.handleRequest(intentMap);
};

更多 Fulfillment 開發細節，請參考 Dialogflow Fulfillment 與 API 整合教學。

---

常見錯誤與除錯

錯誤 1：Intent 互相衝突

症狀：說 A 卻觸發 B

原因：Training Phrases 太相似

解法：

1. 檢查兩個 Intent 的 Training Phrases
2. 讓差異更明顯
3. 使用 Input Context 區隔

錯誤 2：Context 過期

症狀：多輪對話中途斷掉

原因：Lifespan 太短

解法：增加 Lifespan，或在每個步驟都重新設定 Output Context

錯誤 3：參數擷取失敗

症狀：應該擷取到的參數是 null

原因：

1. Entity 沒有覆蓋使用者的說法
2. Training Phrases 沒有標註 Entity

解法：

1. 增加 Entity 的同義詞
2. 確認 Training Phrases 有正確標註

除錯技巧

使用測試面板：

1. 在 Dialogflow Console 右側測試
2. 點擊「Diagnostic Info」查看詳細資訊
3. 檢查觸發的 Intent、參數值、Context 狀態

查看歷史記錄：

1. 點擊左側「History」
2. 查看過去的對話記錄
3. 找出辨識失敗的案例，加入 Training Phrases

常見問題 FAQ

Q1: Intent 的 Training Phrases 該寫多少才夠？10 個 vs 100 個差別多大？

最佳範圍 15–40 個，再多邊際效益遞減，再少辨識率不穩。測試結果：(1) 5 個以下——辨識率 < 60%，使用者說話稍有變化就 match 不到；(2) 10–15 個——辨識率 75–85%，可接受；(3) 20–30 個——辨識率 85–95%，品質明顯提升；(4) 50+ 個——辨識率 95–98%，但邊際效益低；(5) 100+ 個——反而可能降低——模型過擬合、訓練時間爆長、甚至搶到其他 intent 的判定權。撰寫 Training Phrases 原則：(A) 多樣性 > 數量——10 個不同句型勝過 100 個相似句子；(B) 包含常見錯字 / 口語化——「現在幾點」、「幾點了」、「現在時間」、「報時」都要；(C) 包含 entity 變化——「訂台北明天的票」、「訂高雄下週一的票」讓 Dialogflow 學 entity pattern；(D) 不要太長句——20 字以內為佳，長句拆成短句；(E) 避免矛盾——同個 phrase 不要同時放兩個 intent。提升辨識率的方法：(1) 每週看 History 找辨識失敗案例加到 Training Phrases；(2) 用 Agent Validation 工具檢查 intents 之間是否太像；(3) 用 Machine Learning Classification Threshold（設 0.7 以上才 match）避免低信心辨識。

Q2: Context 的 Lifespan（生命週期）設多少合適？5 是預設但我常遇到 context 還沒用就消失

依對話情境設，沒有固定答案。(1) Lifespan 定義：context 會在 N 輪對話後自動失效。預設是 5 輪，代表設完 context 後 5 輪對話內還有效。(2) 常見情境建議：(A) 收集多個欄位的表單（訂票、註冊）——設 10–15，避免使用者中間離題後回來 context 消失；(B) 簡短確認（yes/no follow-up）——設 2–3，立即確認後就該結束；(C) 跨 session 狀態——用 Session Parameters 或外部 DB，不要用 context（context 是 session 內的）；(D) 全局設定（如使用者語言偏好）——設 100+ 或用 Session Parameters。常見陷阱：(1) Lifespan 太短——預設 5 太短，長對話常中斷；(2) Lifespan 太長——會讓舊 context 影響新對話（「我要訂票」設了 booking context，十分鐘後使用者問別的事還被誤認為訂票）；(3) 同時存在多個 active context——邏輯衝突，Dialogflow 不知道選哪個。最佳實踐：(1) 設計對話 flow 時畫出 state machine；(2) 明確標註每個 context 的進入和離開條件；(3) 用 "reset_context" 在 flow 結束時手動清除；(4) 定期 audit 哪些 context 其實沒被用到。

Q3: System Entity（@sys.date、@sys.number）用起來有什麼坑？

日期 / 時間辨識在中文環境常出錯。(1) @sys.date 的問題——(A) 「明天」、「下週一」辨識 OK，但 「農曆新年」、「端午節」等節日辨識率差；(B) 「三月中」—— Dialogflow 不懂（會 match 失敗或亂猜）；(C) 時區問題——如果不指定，Dialogflow 可能用 UTC 而非本地時間；(D) 相對日期（「後天下午 3 點」）要搭配 @sys.time 和正確時區設定。(2) @sys.number 的問題——(A) 「五百」、「5百」、「500」都能辨識，但 **「大概 5 百」**就可能 fail；(B) 中文數字計算（「一萬零五百」= 10,500）辨識有限；(C) 小數點不同地區寫法（3.14 vs 3,14）要注意 locale。(3) @sys.time 的問題——(A) 「下午兩點半」OK，「兩點三刻」 Dialogflow 可能不懂；(B) 24-hour vs 12-hour 混用容易出錯。避坑策略：(1) 自訂 Composite Entity 包裝複雜情境——如「農曆日期」entity 包含常見節日 mapping；(2) Fallback intent 接住 system entity 辨識失敗的 case，讓 bot 問「您是指哪一天？」；(3) 用 webhook 做後處理——收到 raw entity value 後在 webhook 做 validation 和 normalization；(4) 建立 QA test cases——準備 50+ 個真實使用者會說的話，確保 entity 正確辨識。

Q4: Welcome Intent 和 Fallback Intent 要怎麼設計才自然？

Welcome Intent 要引導、Fallback Intent 要給出路。(1) Welcome Intent 設計原則——(A) 簡潔——不要一次列 10 個功能，說「我可以幫您 X、Y、Z」最多 3 件事；(B) 主動引導——「請問是要查詢、購買、還是其他問題？」讓使用者明確選擇；(C) 不重複呼叫——如果使用者剛打完 welcome，下一句要接有意義的內容；(D) 記憶回訪使用者——用 User Storage 或 DB 記錄，第二次造訪說「歡迎回來！上次您在問…」。(2) Fallback Intent 常見錯誤——(A) 只說「我不懂」——使用者挫折，會直接放棄；(B) 無限 loop——「我不懂，請再說一次」→ 還是不懂 → 一樣訊息，很煩；(C) 沒收集 fallback 案例——不追蹤 fallback 原因，改善不了。(3) 好的 Fallback 設計——(A) 道歉 + 解釋 + 選項：「抱歉我沒聽懂。您可以試試 [功能 A / 功能 B] 或輸入『人工客服』」；(B) 連續 fallback 升級——第一次重述、第二次給選項、第三次直接轉人工；(C) log 下來人工 review——每週花 30 分鐘看 fallback log，找出可以加 intent 的場景。(4) 進階：(A) 用 LLM fallback——接 GPT/Gemini，fallback 時讓 LLM 嘗試理解，品質比純 rule-based 好；(B) 情緒偵測——偵測使用者挫折度（憤怒用語），自動升級服務等級。

Q5: Dialogflow 和 Rasa / Botpress 等開源方案比起來，優缺點是什麼？

依規模、技術力、資料主權需求選。(1) Dialogflow 優勢——(A) 托管服務，零運維；(B) Google NLU 品質高，特別是中文；(C) 多語言支援原生（單 agent 一百多種語言）；(D) 整合 Google 生態（Speech-to-Text、Contact Center AI）；(E) scaling 免操心；(F) SLA 和企業合約。缺點：(A) 資料要送 Google——某些合規場景不行；(B) 定價按使用量——大規模可能很貴；(C) 模型黑盒——無法完全 customize。(2) Rasa 優勢（開源，Python）——(A) 完全可自訂——模型、pipeline、dialogue policy；(B) 資料完全在自家 infra；(C) 無長期 vendor lock-in；(D) MIT 授權可商用；(E) 社群大、生態豐富。缺點：(A) 自己維運——要 DevOps 人力；(B) 中文 NLU 要自己調——預設模型不如 Dialogflow；(C) scaling 自己處理。(3) Botpress 優勢（開源 + SaaS）——(A) 視覺化 flow editor——比 Rasa 好上手；(B) 內建 LLM 整合；(C) hybrid deployment——可自架或用他們 SaaS。(4) 選擇建議——(A) 快速上線 + 中文優先 + 資料可以上雲 → Dialogflow；(B) 資料主權強 + 有 DevOps 能力 + 要極致自訂 → Rasa；(C) 想要 Rasa 的自主 + 更好 UX → Botpress；(D) 想用最新 LLM 做 agent → 2025 年考慮直接用 LangChain / LlamaIndex + LLM，傳統 chatbot framework 可能被淘汰。2025 趨勢：Generative AI chatbot 崛起，intent-based 架構逐漸被 "LLM + function calling" 取代，但 Dialogflow CX 已整合 Gemini，仍是主流選擇。

---

下一步

掌握 Intent 和 Context 後，你可以：

1. 整合後端系統：Dialogflow Fulfillment 與 API 整合教學
2. 串接 LINE Bot：Dialogflow LINE Bot 串接教學
3. 學習 CX 版本：Dialogflow CX 教學：從入門到進階

---

對話設計需要專業建議？

好的對話設計讓使用者覺得在跟真人聊天，不好的設計讓人想直接打電話找客服。

如果你需要：

• 規劃複雜的多輪對話流程
• 優化現有機器人的辨識率
• 設計自然流暢的對話體驗
• 處理大量 Intent 的架構規劃

預約 AI 導入諮詢，讓有經驗的對話設計師幫你打造真正好用的 AI 客服。

諮詢完全免費，我們會在 24 小時內回覆。

---