AI 客服工具評估表：用實測任務比較候選方案

用相同任務與可追溯紀錄，比較候選方案的回答依據、人工操作、例外處理、權限與加權分數。

採購比較容易受展示畫面或銷售說明影響，真正的差異往往要放進日常任務才看得出來。這份評估表以相同題目和資料測試候選方案，分開記錄答案依據、人工操作、例外處理與資料管理，再用事先訂好的權重整理取捨。文中的比較數字是明確假設的示例，不代表任何品牌的實測結果。

候選方案先用同題測試

先定義要比較的任務，再挑選方案，避免看過簡報後才替各家設計不同考題。把日常問題整理成固定測試集，涵蓋能從既有資料回答的查詢、需要整理兩份資料的問題、資料缺漏的問題，以及應交由人員處理的請求。每題都寫明預期依據、允許的回答範圍，以及哪些說法不應出現。題目可取材自工作情境，但先移除姓名、電話、訂單號等可識別資訊。

每個候選方案使用相同版本的題目、知識資料、帳號權限、操作時間與測試方式。開始前記錄方案版本、匯入資料種類、測試通路和設定者；若某方案不支援指定的資料輸入方式，保留這項限制，不要替它換一題比較容易的題目。除非所有方案一起更新並重跑，測試期間不臨時補資料或調整提示。

例如，要比較退換貨問題，就把同一份政策摘錄和幾種意思相同、措辭不同的問法交給各方案。依固定順序送出問題，保留原題、完整回答、可見的來源線索和操作備註。若一題連測試人員都無法一致理解，先修正題目，再讓每個方案重做；不要只替單一方案修改考題，否則結果失去可比性。

測試清單也要標明範圍：納入哪些通路、提供哪些資料，以及何時算完成。若需求涉及 LINE、Facebook Messenger、Instagram 私訊或網頁聊天，就將各通路列為待驗證項目，逐一詢問能否接入並以相同任務實測。簡報中提到某通路不等於已完成驗證；這份記錄應能讓另一位同事照著相同條件重做。

回答依據如何核對

回答聽起來合理，不表示內容有資料支持。每題先指定應使用的資料，再檢查方案是否能指出相關文件、段落或其他可核對的來源線索。把回答拆成可驗證的主張，例如資格條件、所需步驟、例外情形和聯絡方式，逐項對照測試資料。若方案提供來源，確認它真的支持相應主張，而不是只看見一個文件名稱就判定正確。

建議每次記錄三種結果：資料支持且重要資訊完整、部分有據但漏掉關鍵條件、或找不到依據而仍自行補出答案。再加一欄標明錯誤影響，例如會造成錯誤承諾、增加來回詢問，或只是措辭不一致。這能避免把流暢度當成準確度，也方便之後追查究竟是哪份資料、哪個條件或哪種問法造成落差。

例如，假設測試資料只說明退貨申請需要商品資訊，沒有寫明期限。若回答清楚指出期限尚未提供並轉交確認，應記下它有辨識資料缺口；若回答自行說出一個期限，就記錄為沒有依據的主張。這是評估方法的假設示例，不代表任何方案實際產生過該答案。核對時保留題目和來源摘錄，讓評分者能檢視同一份證據。

也要測試相同意思的不同問法，以及資料中沒有答案的問題。可把否定句、口語問法或少一項條件的問題放進題目集，檢查回答是否仍落在資料範圍內。遇到來源彼此矛盾或版本不同時，觀察方案是否指出不一致、要求補充，或直接選一邊回答。不要替方案猜測它採用哪份資料；將可見結果和無法確認之處分開記錄。

人工操作步驟如何記錄

評估的不只是生成答案，也包括人員為了把答案送到可用狀態實際做了什麼。從接收題目開始，記下查找資料、輸入問題、檢查來源、修改文字、詢問同事、交接處理和完成回覆的步驟。每一步記錄操作者、使用的工具、花費的人工時間與等待時間。分開計算人工投入和系統等待，才看得出省下的工作是否被額外檢查或複製貼上抵銷。

先選一位熟悉流程的測試者，再由另一位同事依相同說明操作一部分題目。記錄兩人在哪些步驟需要不同解讀、是否找得到來源，以及哪裡會把上下文遺失。不要只記總完成時間，也要標出重做、切換通路、重複輸入資料和尋求人工確認的次數。若操作手冊或訓練時間不同，亦應列入背景，避免把熟練程度誤認為方案差異。

例如，假設一題要先確認政策、再整理答案並交給客服複核，操作表就分別記錄「找資料」「草擬」「複核」「完成」的人工時間及等待時間。若某候選方案產生答案很快，但每題都要重新貼入客戶問題或人工補上政策連結，這些工作都要算進整體流程。只比較生成速度，會漏掉真正影響日常人力的步驟。

每輪採用固定開始與結束定義，例如從操作者讀到問題起算，到答案經過必要檢查、可以交付為止。遇到卡住時，不要默默代做；先按事先設定的重試規則處理，並記下原因和結果。最後把每題的步驟清單與耗時放在評分旁，說明差異來自哪個環節。這樣團隊可以決定要改善資料、調整流程，或繼續評估其他方案，而非只看一個總時間。

例外情境怎麼評分

例外題要測出方案何時不該直接回答。準備缺資料、條件互相矛盾、問題含糊、超出服務範圍，以及要求查詢未提供資訊等情境。每題先寫下合格處理方式：指出缺少什麼、提出必要的澄清問題，或交由人員接手。評分者依相同標準檢查各方案，避免把自信的語氣當成處理能力，也不要因為答案篇幅長就給較高評價。

可把每個例外結果記為「符合預期」「部分符合」或「未符合」，再註明原因。符合預期代表方案有辨識限制並採取合適下一步；部分符合代表有發現問題但漏掉重要條件；未符合則是捏造依據、承諾未確認事項，或在應交接時仍自行作答。記錄實際回答和事先定義的標準，並保留評分者的簡短理由，讓不同人能重看並校正判斷。

例如，假設客戶只問「這個可以辦嗎」，題目沒有說明商品或申請類型。合格結果應先詢問缺少的條件，而不是直接肯定。若資料彼此矛盾，合格結果應指出矛盾並尋求確認，不應自行挑一個版本。這些情境都要用相同資料和問法測試；若回答會影響對外承諾，另行標記為重要失誤，不讓其他容易題目的好表現把它掩蓋。

在測試開始前也要寫清楚重試規則，例如哪些技術中斷可以重送、何時停止、是否允許人員補充上下文。所有方案都用同一規則，失敗題保留原始紀錄，不要只重測表現不佳的一家。最後按情境類型檢視結果：資料不足、語意含糊、衝突內容、轉人工和服務範圍外各自有沒有達到預期。這比用一個整體印象分數更容易找出採用後需要的防護措施。

權限與資料出口問什麼

先以虛構或去識別化資料建立測試環境，再確認不同角色能看見、修改和匯出哪些內容。向供應方詢問管理者、一般操作人員與唯讀人員的權限差異，並實際檢查各角色能否存取知識資料、對話紀錄、設定和帳號管理。若測試需要串接外部通路或服務，先確認所需權限、憑證由誰管理，以及停用連結後哪些資料仍留在原處或候選方案中。

資料出口要從實際操作確認，不要只聽到「可以匯出」就結案。詢問對話紀錄、附件、知識文件、使用者設定等資料是否能分別取得，能否辨認欄位和時間，匯出後是否可閱讀與整理，以及是否需要額外協助。若可用測試資料執行匯出，就挑一筆資料對照原始內容，確認欄位、來源和附件是否完整；不能驗證的項目就記為待確認，不猜測其可攜性。

也要問清楚資料保留、刪除、備份、帳號停用和服務終止時的處理方式，要求對方用書面說明流程與責任人。若有刪除功能，可在不影響正式資料的測試環境中執行，再檢查介面或書面回覆是否能證明預期範圍已處理。不要把真實客戶紀錄放進未核准的測試環境，也不要把供應方的口頭承諾當成資料出口或清除的完成證據。

比較表可分成「已實測」「已取得書面回答」「尚未確認」三類，並記錄回答日期、對應問題和負責追問的人。若某項權限或資料出口是採用的前提，就預先設為必須通過的條件；不能因為其他分數高而略過。這份檢查表是採購評估工具，實際資料使用仍應依組織核准的流程處理。若供應方的說明不完整，先保留差距和責任人，再決定是否繼續測試。

加權分數如何解讀

先決定各項工作的相對重要性，再設定權重，權重總和為百分之百。每個面向用相同的五分尺度評分，並附上支撐分數的測試紀錄；尚未驗證的項目標成未知，不能當作滿分或零分混入平均。若權限、必要通路或例外處理有不可妥協的條件，先列為通過門檻，再計算加權分數，避免高分掩蓋關鍵缺口。

以下是明確假設的示例，分數僅用來說明算法。回答依據占百分之二十五、操作流程百分之二十、例外處理百分之二十、權限與資料出口百分之十五、人工接手百分之二十。甲與乙是假設的兩個候選方案，各面向以一至五分評分；表中沒有任何實際供應商的測試結果，也不代表普遍適用的權重設定。

計算方式是各面向分數乘以權重後加總：甲為四乘二十五、五乘二十、三乘二十、二乘十五、四乘二十，合計三百七十分，再除以一百分，得三點七零分。乙合計三百五十五分，除以一百分得三點五五分。這只表示在這組假設權重與評分下的排序；若更重視資料出口，應調整權重並重新計算，同時回看原始證據。下一步可先整理一組去識別化常見問題與評分欄位，再到 ReplyBot 網站 了解相關資訊。