小村軟體有限公司
聯絡我們
選單

聊天機器人製作的最佳實踐 - 不讓它結束在什麼都答的盒子，做成業務上有用的導線

· 更新日期: · · AI, 聊天機器人, Web 製作, 諮詢導線改善, 知識庫

更新紀錄(僅初版,2026年04月08日 發布)
初次發布
引用本文(DOI: 10.5281/zenodo.21616391)

本文保存於 Zenodo。以下同時提供一律指向最新版本的 DOI，以及固定於您正在閱讀版本的 DOI。

小村 豪(2026)。〈聊天機器人製作的最佳實踐 - 不讓它結束在什麼都答的盒子，做成業務上有用的導線〉。小村軟體有限公司。https://doi.org/10.5281/zenodo.21616391 https://staging.comcomponent.com/zh-TW/blog/2026/04/08/001-chatbot-best-practices/

DOI(最新版本)
10.5281/zenodo.21616391
DOI(此版本)
10.5281/zenodo.21616392

本文整理製作面向 Web 網站的諮詢聊天機器人、公司內部 FAQ 機器人、一次對應機器人時的通論。 先講結論，成功的聊天機器人比「模型的聰明」更早已整理好角色、知識源、權限、交接條件、評估方法。

聊天機器人的話題，不自覺地從「用哪個模型」「用 RAG」「用多代理」進入比較容易。 但實務上有效的順序稍微不同。

要先決定的是要減少誰的哪個工作到什麼程度。 這個順序崩壞的話，對話即使聽起來像樣，也不會連接到諮詢也不會連接到業務效率。

技術系・B2B 網站特別有這種傾向強。 有價值的不是閒聊長時間持續。 是準確地導引服務內容，必要時連接到適當的頁面或負責人。 現在的主要開發指南，正式品質上也強烈提出要分別設計評估、接地、護欄、交接的前提。123456

1. 先講結論

相當粗略但實務上好用的說法如下。

  1. 聊天機器人最初決定 1 個用途比較強。
  2. 比模型更早，需要決定以什麼為根據回答。
  3. 需要區分無法給出出處的答和應該交給人的答。
  4. 高風險處理越是不能削薄權限和確認階段。
  5. 正式運營中沒有對話日誌和評估集的話，改善幾乎變成直覺。
  6. 要放到 Web 網站的話，比起長時間持續對話，幫助頁面理解和諮詢導線更容易成為價值。

聊天機器人做好的話方便。 但是，作為什麼都答的綜合窗口過度擴張，精度、運營、責任範圍會一口氣崩壞。 最初做窄一點，從確實有用的領域擴張結果會比較快。7

2. 先放整體圖

先是整體圖。

YesNoYesNo使用者問題對應範圍內嗎知識搜尋 / 工具呼叫諮詢頁面 / 負責人引導權限・安全條件是否滿足附出處的回答 + 下個動作交給人日誌 / 評估 / 改善

這張圖重要的是，聊天機器人不是 1 個 prompt，而是包含導線、知識、權限、評估的機制。 不只是答問題就結束，要包括回答的條件、不回答的條件、接下來要引導什麼來設計。

現在的主要工具群也以這個思考方式製作。 Google Cloud 把 webhook 或 handoff rules、evaluation 作為分開的功能，OpenAI 把 model snapshot 的固定或 evals 作為正式運營的基本引導。12834 也就是說，不試圖只用提示詞解決全部是最初的最佳實踐。

3. 最先該決定的是「要減少誰的什麼工作」

製作聊天機器人之前，先把用途縮到 1 個。 這裡曖昧的話，評估軸和知識設計都無法決定。

粗略地把用途做成表如下。

用途 主要價值 主要指標 最初不要做比較好的事
Web 網站的諮詢導線 不讓讀者迷惑，送到適當頁面或諮詢 重要頁面到達率、諮詢率、離脫率 長時間持續閒聊
支援一次對應 增加 FAQ 或步驟的自主解決 自主解決率、平均對應時間、再諮詢率 例外對應也從一開始就全自動
公司內部知識搜尋 縮短資訊探索時間 回答到達時間、再搜尋率、業務時間削減 權限未整理就橫跨搜尋全公司文件

其中作為最初的 1 個容易做的是對象窄、答的正本容易決定的。 例如，

  • 產品 FAQ 的一次回答
  • 諮詢前的服務引導
  • 公司內部步驟書的搜尋

這一帶容易開始。

相反，

  • 契約判斷
  • 金額確定
  • 例外批准
  • 客戶個別條件強的諮詢

這類的最初不做成主戰場比較安全。

另外，從一開始需要做成 multi-agent 的案例不多。 Microsoft 也整理說 single-agent 讓實作單純，降低運營負載，成為容易預測的執行模型，沒有明確分離理由的話，建議先用 single-agent 驗證。7

4. 對話設計比模型選定更早

聊天機器人容易失敗的理由之一是對話的入口和出口沒定。 「總之自由輸入什麼都可以」的話，能做和不能做的邊界會曖昧。

4.1 固定對話的入口

最初的訊息中先顯示對應範圍比較穩定。 例如面向 Web 網站，

  • 能對應的諮詢內容
  • 能立刻引導的頁面
  • 諮詢時必要的最小資訊

最初拿出來，對話的晃動會減少。

能用按鈕或快速回覆的話，

  • 想知道費用
  • 想知道能否對應
  • 想看事例
  • 想諮詢

這樣放最初的分歧，比只自由輸入相當穩定。

4.2 問的資訊最小限

問使用者的項目只要改變答或路由的就夠。 因為覺得問一下比較好就增加項目的話，離脫會增加。

例如，

  • 業種
  • 諮詢種別
  • 現有系統的有無
  • 緊急度

改變下個引導的話，問的意義存在。 相反，不馬上使用的資訊放到後面比較好。

4.3 決定回答的結束方式

好的回答不是只有本文結束。

  1. 結論
  2. 根據或參照來源
  3. 接下來能採取的行動

以這個順序結束，對話容易連到業務。

特別面向 Web 網站，比起在對話內完結，

  • 往相關服務頁面前進
  • 看事例
  • 往諮詢表單前進

這樣下一步明確比較能成為價值。

4.4 高風險話題分到專用路徑

認證、PII、金額、契約、例外批准這類高風險領域，不要混到通常的引導流程的相同路徑比較安全。 Google Cloud 的 handoff rules 也明示了把高風險要求導到特定 agent 的例子。3

5. 知識設計決定品質的大半

聊天機器人的品質比起模型更容易以知識崩壞。 答案的來源資訊曖昧的話，哪個模型都不穩定。

5.1 先決定「要以什麼為正本」

至少要決定以下。

  • 把哪些文件或頁面作為正本
  • 誰是更新責任人
  • 以什麼頻率更新
  • 什麼時候丟棄舊資訊

沒有這個的話，機器人會同時撿舊資訊和新資訊。 那個不一致相當高機率被使用者看到。

5.2 不是以頁面單位而是以意義單位切

RAG 常見的失敗是把 PDF 或頁面直接塞進去就結束。 實際上，

  • 1 個制度說明
  • 1 個步驟
  • 1 個 FAQ
  • 1 個注意事項

這樣以意義的塊處理，回答比較穩定。

Microsoft 表示 RAG 品質依賴於內容準備，以 chunking、vectorization、hybrid search、semantic ranking 為基本線引導。5 OpenAI 的 file search 也以查詢重寫、多重搜尋、keyword + semantic search、reranking 為前提。9 也就是說最佳實踐不是「放入文件」，而是「把文件轉換為可搜尋的知識」。

5.3 顯示出處和更新日

使用者能安心的不是很會說話的機器人。 是能追蹤根據的機器人。

  • 看哪個頁面答的
  • 哪個文件的哪個項目
  • 什麼時候更新的資訊

能顯示的設計，誤答時的調查也會容易。

OpenAI 的 web search 以返回附出處回答為前提設計，Microsoft Copilot Studio 也引導 grounded, cited responses。1011 從網站內或公司內部文件回答的情況，也以這個「能追蹤根據」的狀態為目標比較容易運營。

5.4 最新資訊分到外部搜尋

新鮮度重要的主題，不要只以固定知識回答比較好。

例如，

  • 營業日
  • 價格改訂
  • 採用資訊
  • 故障資訊
  • 法律修訂或制度變更

這類。

這種質問，以別路徑參照更新源的網站或 API，或明確回覆「最新資訊請確認這個頁面」比較安全。 把公開網站作為知識源使用的情況，也要先縮小信任哪個域名。Copilot Studio 也以縮小到配置好的域名的搜尋、citations、relevance check 為前提。11

6. 提示詞比起長文的人格設定，短的運營規則

聊天機器人的 prompt 真正有效的比起長的人格設定，是短而明確的運營規則。

至少分為以下 4 層比較容易整理。

  1. 角色
  2. 可以參照的知識和工具
  3. 可以回答的條件 / 交接的條件
  4. 回答形式

例如角色能短地寫「做諮詢前的引導」「引導公司內部步驟」。 回答形式也「結論 → 根據 → 下個動作」就夠。

相反，弱的 prompt 容易變成如下。

  • 只有人格設定長
  • 答的根據曖昧
  • 使用工具的條件不明
  • 沒寫交接條件

6.1 使用結構化的輸出

訂單狀況、預約空位、諮詢分類這類連到後段處理的場面，不只自由文比較安全。 OpenAI 也引導使用 Structured Outputs 的 JSON 返回。1

給人看的文章和機器接收的值分開比較好。 例如，

  • 顯示文: 給使用者看的說明
  • intent: 諮詢種別
  • confidence: 判定確度
  • next_action: 下一個導線

只這樣分運營就會穩定。

6.2 固定 model version，評估後再改變

正式系中，「昨天和今天答的方式稍微不同」會成為事故。 OpenAI 建議在 production applications 中 pin model snapshot，製作測量 prompt 的 behavior 的 evals。1 另外明示最佳化以 evals → prompt engineering → fine-tuning 的持續循環進行的前提。2

6.3 依工作分 model

不需要讓 1 個 model 背負全部。 OpenAI 也引導低延遲明確處理用 GPT 系，複雜且曖昧度高的判斷用 reasoning 系的區分使用。12

實務上，

  • FAQ 回答或分類用輕的 model
  • 例外判定或複雜的摘要用 reasoning model
  • 高風險判斷用人類

這樣分，成本和品質兩方都容易穩定。

7. 安全設計「彈掉危險問題」還不夠

講到安全設計，容易只想像有害問題的封鎖。 但實務上重要的不只那個。

7.1 以 prompt injection 為前提

LLM 系的機器人中以 prompt injection 為前提比較好。 Microsoft 整理 direct 和 indirect 2 種類，也表示透過外部網站或檔案中埋入的 hidden instruction 讓 session 被奪取的可能性。613

也就是說，讀外部文件或 Web 頁面的機器人中，

  • 不把外部內容與 system instruction 同列處理
  • 最小化工具執行權限
  • 在高風險處理前放入確認

是必要的。

7.2 最小化權限

「能讀的資料全部能讀」「能執行的操作全部能執行」很危險。 Microsoft 的 security guidance 也整理 least privilege 和外部內容的影響分離重要。6

公司內部機器人特別，

  • 各部門的閱覽權限
  • 各客戶的資訊分離
  • 含個人資訊的文件的排除

需要先決定。

7.3 個人資訊和認證以別層處理

不要認為「機器人會好好遮罩」比較安全。 Microsoft 的 public website grounding 的說明也明記使用者輸入的 personal data 不會自動 scrub / mask。11

處理個人資訊或客戶特定資料的話，

  • 認證在應用程式端做
  • 縮小能取得的資訊
  • 留審計日誌
  • 在回答前滿足本人確認條件

這樣的設計必要。

7.4 安全不是開發的最後而是從最初就轉

NIST 的 Generative AI Profile 也放著以設計、開發、利用、評估的各階段管理風險的前提。14 也就是說安全設計不是發佈前的最後的檢查項目。 是要從最初放入規格的。

8. 從最初決定交給人的條件

「不懂的話交接給負責人」只寫一句結束的設計弱。 實際上需要決定在什麼條件、交給哪裡、附上什麼。

例如以下條件從最初容易放。

  • 需要認證的問題
  • 需要契約或金額確定的問題
  • 無法給出處的問題
  • 2 次以上無法好好引導的問題
  • 投訴或緊急性高的諮詢
  • 法務、勞務、醫療等高風險領域的諮詢

Google Cloud 的 handoff rules 中明示比起 instruction 基礎的 handoff 可以用 deterministic 的控制。3 高風險領域越是比起「大概交」，「這個條件必交」運營比較容易。

交接時應該交給人的資訊，也先決定比較輕鬆。

  • 到這裡為止的對話歷史
  • 已取得的項目
  • 參照的頁面或文件
  • 機器人卡住的理由
  • 接下來希望確認的點

這 5 個齊全，交接後的手返回就會相當減少。

9. 沒評估的改善幾乎是運氣

聊天機器人改善中最危險的是看幾件對話「感覺變很好了」進行。 這樣每次碰 prompt，別的部分會壞。

OpenAI 建議先寫 evals 用接近實運營的輸入轉。2 也就是改善的出發點不是 prompt 而是評估集。

9.1 至少想要的指標

觀點 指標 看的理由
對話成果 user goal satisfaction 看使用者的目的是否達成
工具利用 tool correctness 看是否用正確的工具、正確的引數
根據性 citation 有無、hallucination 率 減少像樣的誤答
運營 escalation rate、離脫率、平均 turn 數 看對話體驗是否太重
事業成果 諮詢率、自主解決率、對應時間 測量機器人導入的價值

Google Cloud 的 CX Agent Studio 也把 user goal satisfaction、tool correctness、hallucinations 等整理為評估指標。4 這個思考方式在任何實作都能相當沿用。

9.2 改善不是飛刀而是以循環轉

改善的順序大致以下就夠。

做評估集計測現狀 prompt / model分類失敗例修正知識 / prompt / routing / handoff再評估正式監視

沒有這個循環的話，改善依賴個人的直覺。 相反有這個循環的話，「什麼變好了、什麼變壞了」容易追蹤。

10. 放到 Web 網站的話和諮詢導線一體設計

放到企業網站的聊天機器人，聊天本身未必是主角。 很多情況作為

  • 傳達是什麼公司
  • 引導該看哪個服務頁面
  • 顯示事例或 FAQ
  • 減少諮詢前的不安

的輔助線設計比較自然。

特別技術系・B2B 網站服務說明複雜。 所以比起在聊天說盡全部，引導到適當的頁面的強的場面多。

例如以下流程相性相當好。

  1. 確認諮詢種別
  2. 引導相關服務頁面
  3. 必要時提出相關事例或 FAQ
  4. 還有不明點就只問最小限
  5. 連到諮詢表單

這樣聊天就成為營業或諮詢導線的輔助。 相反與頁面導線分開放的話，容易成為「能說話但不前進的盒子」。

11. 90 天做基礎的進行方式

沒必要大規模開始。 90 天做基礎的話，以下順序現實。

0-2 週: 決定用途和正本

  • 決定想減少什麼的諮詢
  • 決定對象使用者
  • 決定正本文件和更新責任人
  • 決定交給人的條件

3-6 週: 小規模試作

  • 只用主要情境做 prototype
  • 做入口訊息和分歧
  • 能返回附出處的回答
  • 做 20~50 件的評估集

7-10 週: 以試點打磨

  • 看實使用者的日誌
  • 分類卡住的問題
  • 比 prompt 更先修正知識和 routing
  • 不順利的領域強化交接條件

11-12 週: 決定正式運營的型

  • 決定每週看的指標
  • 固定管理 prompt / model version
  • 決定更新流程和責任人
  • 判斷是否擴張到第 2 個用途

以這個順序進行，能降低從一開始做大而崩壞的機率。

12. 常見的失敗

最後整理相當常見的失敗。

12.1 做成什麼都答的綜合窗口

從一開始把範圍擴太廣，精度和責任範圍都會曖昧。 縮用途到 1 個比較強。

12.2 沒正本和更新責任人

就算有 RAG 的機制，原資訊沒整理的話不穩定。 知識運營是別的工作。

12.3 沒出處就斷定

像樣的答在運營中最危險。 無法追根據的答之後難以修正。

12.4 讓高風險處理突然執行

匯款、契約更新、個人資訊參照這類操作，不能拿掉確認或人的批准。

12.5 交給人曖昧

只寫「必要時給負責人」的話，現場會卡。 需要決定條件、收件人、附加資訊。

12.6 沒評估集

改善時不知變好還變壞。 這相當多。

12.7 從一開始做 multi-agent

增加 agent 設計自由度上升。 但同時 latency、狀態管理、監視、除錯、權限管理也變重。沒必要的分離理由，先用 1 個試比較安全。7

13. 總結

聊天機器人製作的最佳實踐一句話說， 比模型選定更早，決定角色、知識、權限、交接、評估。

特別重要的是以下 5 點。

  • 縮用途到 1 個
  • 決定正本和出處
  • 分開高風險領域
  • 明文化交給人的條件
  • 轉接近實運營的評估

面向 Web 網站，面向公司內部都這個順序相當共通。 把聊天機器人不作為「很會說話的東西」，而作為「整理在業務的哪裡縮短、在哪裡連到人的東西」設計，比較不易失敗。

相關文章

參考資料

  1. OpenAI, Prompt engineering ↩ ↩2 ↩3 ↩4

  2. OpenAI, Model optimization ↩ ↩2 ↩3 ↩4

  3. Google Cloud, Handoff rules ↩ ↩2 ↩3 ↩4

  4. Google Cloud, Evaluation ↩ ↩2 ↩3

  5. Microsoft Learn, RAG and Generative AI - Azure AI Search ↩ ↩2

  6. Microsoft Learn, Security planning for LLM-based applications ↩ ↩2 ↩3

  7. Microsoft Learn, Single agent or multiple agents ↩ ↩2 ↩3

  8. Google Cloud, General agent design best practices ↩

  9. OpenAI, File search. 作為搜尋行為的細節，Assistants File Search 也整理了 query rewrite、多重搜尋、keyword + semantic search、reranking ↩

  10. OpenAI, Web search ↩

  11. Microsoft Learn, Use public websites to improve generative answers ↩ ↩2 ↩3

  12. OpenAI, Reasoning best practices ↩

  13. Microsoft Learn, Prompt Shields in Microsoft Foundry ↩

  14. NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1) ↩

相關文章

共用相同標籤的最新文章。能以相近的主題延伸理解。

相關主題

與本文相近的主題頁面。以本文為起點，可進一步連到相關服務與其他文章。

常見問題

整理諮詢這個主題時常見的問題。

製作聊天機器人時最先該決定什麼？
不是模型選定，而是先決定「要減少誰的哪個工作到什麼程度」，並把用途縮到 1 個。這裡曖昧的話，評估軸和知識設計都無法決定。比起長的人格設定提示詞，先整理角色、知識源、權限、交接條件、評估方法，對話才會連接到諮詢或業務效率。
聊天機器人一開始需要做成 multi-agent 嗎？
多數案例不需要。Microsoft 整理指出 single-agent 讓實作單純、降低運營負載、成為容易預測的執行模型，沒有明確分離理由的話建議先用 single-agent 驗證。從一開始增加 agent，latency、狀態管理、監視、除錯、權限管理也會跟著變重。
什麼樣的問題應該交給人處理？
從最初就明文化交接條件比較安全，例如需要認證的問題、需要契約或金額確定的問題、無法給出處的問題、2 次以上無法好好引導的問題、投訴或緊急性高的諮詢、法務勞務醫療等高風險領域。交接時也要附上到目前為止的對話歷史、已取得的項目、參照的頁面、機器人卡住的理由等資訊，交接後的手返工才會減少。
沒有評估集也能改善聊天機器人嗎？
只看幾件對話「感覺變好了」就修改 prompt 的話，別的部分會壞，改善幾乎變成運氣。OpenAI 建議先寫評估集，用接近實運營的輸入測量現狀，之後分類失敗例、修正知識或 prompt 或 routing 或 handoff，再評估並在正式環境監視，以循環方式改善。改善的出發點不是 prompt 而是評估集。

作者檔案

本文作者的個人檔案頁面。

Go Komura

小村軟體有限公司 代表

以 Windows 軟體開發、技術諮詢與故障調查為中心，在難以重現的故障調查與既有資產仍在運作的專案上具有優勢。

聯絡我們
回到部落格一覽