案例性質：以下是一個假設示範案例，用來說明小型企業如何使用 Langfuse 衡量 AI 工作成本與品質。公司規模、案件量、成本、工時與改善幅度均為 SasaDaily 教學假設，不是真實企業或 Langfuse 官方公布的導入成果。
一家八人的線上課程平台，每天都會收到學員問題。
有些非常簡單。
- 忘記密碼怎麼辦？
- 課程影片在哪裡？
- 教材怎麼下載？
- 付款完成後什麼時候可以上課？
也有一些比較複雜。
- 付款成功但帳號沒有開通。
- 課程內容和購買方案不一致。
- 需要退款或更換方案。
- 企業團體帳號權限有問題。
平台原本已經做了一個 AI 學員客服。
幾個月後，老闆看到一件很開心的事情：
AI 每個月回答了很多問題。
但財務和客服主管接著問：
所以到底省了多少？
這時大家才發現，原本根本沒有足夠資料回答。
原本只知道「AI 用很多」
團隊每個月可以看到：
- 模型 API 帳單。
- AI 呼叫次數。
- 客服總案件數。
卻不知道：
- 哪一類客服最花模型費。
- 哪些答案真的可以直接使用。
- 哪些最後還是被真人重寫。
- 哪些 AI 回答根本沒有解決問題。
- 哪一類工作其實比人工處理還麻煩。
於是公司決定把 Langfuse 接進客服 AI。
第一步：先把不同客服工作分開
團隊不再把所有紀錄都叫做：
AI Customer Support。
而是先拆成四種工作。
- 帳號與登入。
- 課程操作。
- 付款與訂單。
- 退款與特殊問題。
每一個完整客服案件，都建立成可以追蹤的工作紀錄。
這樣月底才能知道：
哪一類案件最常發生？
哪一類最花錢？
哪一類最容易需要真人介入？
第二步：Langfuse 先記「系統發生什麼」
Langfuse 可以追蹤一個 AI 工作流程裡的模型呼叫與其他執行步驟。
所以團隊先留下：
- 使用哪個模型。
- 模型使用量與成本。
- 整個流程跑多久。
- 中間經過哪些步驟。
- 是否發生異常或重試。
例如：
同樣是「付款後沒有開通」。
有些案件可能只需要：
查一次訂單，再產生回答。
另一些卻可能：
- 搜尋訂單。
- 重新查會員帳號。
- 再次呼叫模型。
- 工具失敗後重試。
- 最後仍然轉真人。
從學員畫面看起來，都只是一個客服問題。
背後成本卻可能差很多。
第三步：不能只記「技術成功」
這是今天整套流程最重要的地方。
API 沒有報錯。
AI 成功產生一段回答。
技術上可以算：
成功。
但對客服來說，這還不夠。
團隊替每個案件再加一個結果：
- 可直接用。
- 需人工修改。
- 失敗。
可直接用：
回答符合既有客服規則，不需修改重要內容。
需人工修改：
主要答案仍可保留，但真人需要修正條件、日期、方案或其他重要內容。
失敗：
回答不能安全使用，或真人必須重新從頭處理。
這個結果可以放進 Langfuse
Langfuse 支援替 Trace 加上品質 Score。
因此團隊可以把這三種工作結果作為分類式評估資料。
這樣月底就不只是看到：
某個模型花了多少。
還能看到：
這些錢最後買回來多少真正可以使用的結果。
第四步：人工修改時間還要另外記
Langfuse 能記模型系統裡的成本、延遲與品質資料。
但它不知道客服人員最後花了多少時間修改。
所以平台另外在客服後台加一個簡單欄位：
人工處理時間。
不用精確到每秒。
第一階段甚至可以只分：
- 不到 1 分鐘。
- 1 到 5 分鐘。
- 超過 5 分鐘。
- 需要重新處理。
這樣就開始看得到隱藏成本。
為什麼人工時間一定要算？
假設兩種客服 AI。
模型 A：
每件成本比較高。
但回答大多可以直接使用。
模型 B：
每件模型成本便宜一半。
但大量案件要客服人員修改三到五分鐘。
如果只看 API，B 一定獲勝。
把人的時間加回來後，答案可能完全反過來。
所以公司真正要計算的不是：
最便宜模型。
而是：
最便宜的「可用客服結果」。
第五步：還要知道問題最後有沒有真的解決
這又是另一層。
一個回答可能完全不需要客服人員修改。
但學員看完後又問一次：
「所以我現在到底要怎麼做？」
這時不能因為 AI 第一封回答沒有被人工修改，就算完全成功。
平台因此再加入：
問題是否真正解決。
第一版可以非常簡單：
- 已解決。
- 再次詢問。
- 轉真人。
這項資料通常要來自客服系統，而不是 Langfuse 自己。
現在終於有兩套資料
Langfuse 告訴公司：
- AI 花多少。
- 跑多久。
- 用了哪個模型。
- 哪個流程一直重試。
- 品質 Score 如何。
客服系統告訴公司：
- 真人花多少時間。
- 學員有沒有再次詢問。
- 最後有沒有轉真人。
- 問題有沒有真正解決。
把兩邊接起來，才開始像一張真正的 AI 成本表。
假設一個月跑 3,000 件客服
以下全部是假設數字，只用來說明如何判斷。
平台一個月有 3,000 件 AI 輔助客服。
其中：
- 帳號與登入：1,200 件。
- 課程操作：900 件。
- 付款與訂單：600 件。
- 退款與特殊問題：300 件。
如果只看數量，最值得自動化的好像是登入問題。
但真正分析後可能出現完全不同結果。
帳號登入：量很大，但原本就很快
假設帳號登入問題：
- 可直接用比例很高。
- AI 成本很低。
- 幾乎不用人工修改。
看起來非常成功。
但原本真人處理一件可能只需要一分鐘。
所以它的價值主要來自：
- 量大。
- 可以 24 小時處理。
- 減少客服被重複小問題打斷。
而不是每件省下很多錢。
課程操作：可能是最漂亮的一類
例如：
「某個功能在哪裡？」
「作業怎麼上傳？」
「影片字幕怎麼開？」
如果公司的知識資料整理得很好，AI 可能：
- 直接使用比例高。
- 模型成本低。
- 人工修改少。
- 再次詢問率也低。
這種就是很適合繼續自動化的工作。
付款問題：不能只追求直接處理
付款與帳號狀態牽涉真正的訂單資料。
AI 可以：
- 整理問題。
- 查詢允許存取的訂單狀態。
- 準備回覆。
但涉及：
- 修改付款狀態。
- 重新收費。
- 改變方案。
- 正式退款。
就不應該因為「自動化率愈高愈好」而取消必要的人工確認。
有些轉真人不是失敗。
而是正確的工作設計。
退款與特殊問題可能最不值得全自動
假設退款案件只占總量 10%。
但 AI 每次需要：
- 查訂單。
- 查方案。
- 確認使用紀錄。
- 閱讀退款規則。
- 判斷例外。
最後大多仍然要真人核准。
這時 Langfuse 可能讓團隊看見：
這類工作：
- 模型成本最高。
- 執行時間最長。
- 人工介入最多。
但這不代表 AI 完全沒有用。
更合理的做法可能是：
停止讓 AI 試圖完成整個退款，只留下「整理資料＋準備客服摘要」。
這就是「改善」而不是「全部停掉」
很多 AI 導入只有兩種想法：
成功，就全面自動化。
不成功，就整個關掉。
其實中間還有一個非常重要的選擇：
縮小 AI 的工作範圍。
例如原本退款 Agent 要做：
- 讀問題。
- 查資料。
- 判斷資格。
- 決定退款。
- 產生回覆。
改成只做：
- 讀問題。
- 整理訂單資料。
- 找出缺少資料。
- 產生人工審查摘要。
最後決策交回客服。
AI 仍然可以省時間。
但風險與不必要的模型步驟可能同時下降。
第六步：月底把四種客服分成「保留、改善、停止」
平台每月做一次回顧。
保留：
成本合理、結果穩定、人工修改少，而且問題真的有被解決。
改善：
已經有價值，但仍存在成本過高、修改太多或流程太長的問題。
停止：
使用量低、價值小，或者 AI 產出的工作量反而增加人工負擔。
這時 Langfuse 就不只是工程團隊除錯工具。
它開始提供管理層做決定所需要的底層證據。
假設最後得到這種結果
帳號登入：
保留。
理由：量大、低風險、結果穩定。
課程操作：
保留並擴大。
理由：直接解決率高，人工修改少。
付款問題：
改善。
理由：AI 可以整理與查詢，但重要狀態變更仍保留人工確認。
退款：
縮小工作範圍。
理由：讓 AI 只準備資料，不再嘗試完成整個流程。
這就比：
「我們 AI 客服一個月回答 3,000 次。」
有管理價值得多。
真正可以建立哪些 KPI？
第一階段不用很多。
這家公司只看六個：
- 每件 AI 模型成本。
- 平均執行時間。
- 可直接用比例。
- 平均人工修改時間。
- 真正解決比例。
- 轉真人比例。
而且不是只看公司總平均。
要依不同客服工作分開看。
為什麼不能全部平均？
假設：
登入問題非常便宜。
退款問題非常昂貴。
全部放在一起平均後，可能看起來：
AI 每件客服成本還可以接受。
結果團隊完全看不到退款流程其實正在大量消耗模型與人工。
所以 Tag 與工作名稱很重要。
它讓公司可以問：
是哪一種工作在花錢？
而不是只問：
AI 總共花多少？
還可以用 Langfuse 找出異常案件
Langfuse 的 Trace 也能協助團隊回頭查看個別工作。
例如突然有一件客服：
成本是平常五倍。
團隊就可以往下看：
- 是不是讀了太長資料。
- 是不是某個工具一直失敗。
- 是不是模型連續重試。
- 是不是 Agent 走了多餘步驟。
這種資料特別適合找出：
平均數看不到的浪費。
Prompt 改版也要一起比較
假設客服團隊把 Prompt 從 V1 改成 V2。
不要只問：
新版是不是寫得更完整？
可以比較：
- 模型成本。
- 執行時間。
- 可直接用比例。
- 人工修改時間。
有時 Prompt 寫得愈長，答案看起來愈完整。
成本和速度卻一起變差。
真正重要的是：
新版到底有沒有改善最終工作。
資料隱私不能因為要追蹤就忘掉
客服 Trace 可能包含：
- 使用者問題。
- Prompt。
- 模型輸出。
- 工具取得的資訊。
所以公司不能為了分析成本，就把所有學員個資完整保存到觀測系統。
可以先問：
除錯真的需要完整姓名嗎？
需要 Email 嗎？
需要付款資訊嗎？
如果不需要，就不應該紀錄。
Langfuse 提供資料 Masking 方法，可以在資料送出前先遮蔽敏感內容。
對正式企業導入而言：
可以觀測，不代表應該記錄一切。
完整工作流程
第一步：挑一個客服流程。
不要一次監控所有 AI。
第二步：替工作分類。
登入、課程、付款、退款分開。
第三步：Langfuse 記錄系統資料。
成本、延遲、模型、Trace。
第四步：加入結果 Score。
可直接用、需人工修改、失敗。
第五步：客服後台補人工資料。
人工時間、問題是否解決、是否轉真人。
第六步：每月按工作類別比較。
不要只看公司平均。
第七步：保留、改善、停止。
讓數據真正對應管理決定。
可以直接使用的 AI 客服 ROI 檢查 Prompt
你是我的 AI 客服成本與品質分析顧問。 我們目前已經使用 Langfuse 記錄 AI 客服。 每一個客服案件可以取得： 工作類別、 模型、 模型成本、 執行時間、 可直接用／需人工修改／失敗、 人工修改時間、 是否再次詢問、 是否轉真人、 最後是否解決。 請不要只算總平均。 第一步： 依客服工作類別分開分析。 第二步： 每一類計算與比較： 平均模型成本。 可直接用比例。 需人工修改比例。 失敗比例。 平均人工修改時間。 真正解決比例。 轉真人比例。 第三步： 找出三種異常： 模型成本低，但人工修改很多。 可直接用比例高，但真正解決率低。 成本高、人工多，而且最後仍大量轉真人。 第四步： 把每一類工作分成： 保留。 改善。 停止或縮小 AI 工作範圍。 第五步： 對「改善」項目提出具體修改方向： 換模型。 縮短 Prompt。 改善資料來源。 減少不必要工具步驟。 改成人工確認。 縮小 Agent 權限或任務範圍。 最後告訴我： 哪一類 AI 客服真正降低整體工作成本？ 哪一類只是把 API 成本變低，卻把工作搬回真人？ 哪一類雖然不能全自動，但仍值得保留 AI 做前置整理？ 資料不足時請直接指出缺口，不要因為 AI 使用量很高就判定導入成功。
這個案例最容易犯的三個錯
第一，只看模型費。
人工修改才可能是最大的隱藏成本。
第二，把轉真人算成失敗。
付款、退款與高風險案件，本來就可能應該轉真人。
第三，把「AI 有回答」算成問題解決。
學員再次詢問，代表工作可能還沒真正結束。
什麼時候才適合擴大自動化？
不是看到 AI 成功率 95% 就立刻擴大。
比較好的訊號是：
- 可直接用比例穩定。
- 人工修改低。
- 真正解決比例高。
- 失敗代價可控。
- 整體成本低於原流程。
這些條件同時成立，才代表這一類工作逐漸成熟。
今天最重要的商業判斷
很多小公司導入 AI 以後，第一個興奮的數字都是：
「AI 幫我們做了多少件事。」
但真正進入管理階段後，問題應該變成：
哪一件真的省了人？
哪一件只是看起來自動化？
哪一件便宜但一直要修改？
哪一件雖然不能完全自動，卻能替真人準備好 80% 的工作？
Langfuse 最有價值的地方，不是替老闆自動算出一個漂亮 ROI 百分比。
而是把原本藏在 AI 裡面的成本、速度與執行過程變得看得到。
再把這些資料和人的時間、真正解決率放在一起。
公司才終於可以做一個更重要的決定：
這個 AI 到底要保留、改善，還是停止？
AI 管理真正成熟的標誌，不是公司裡有多少 Agent。
而是每一個還留在流程裡的 AI，都說得清楚它替人少做了什麼，以及為什麼值得繼續付錢。
今天，和 AI 一起進步一點。
每天學會一個 AI 技巧。
每天節省一點時間。
每天提升一點能力。
SasaDaily，陪你一起成長。
