第一次在 AI 產品上跑 A/B testing 時，我相信大部分的團隊都會直接套用傳統做實驗的方法，我也不例外。概念大概會是隨機分成兩個或多個版本，並且選定 Key Metric 和 Guardrail Metrics 後，等流量跑到設定目標時，用指標來驅動後續決策。
這聽起來很正常，畢竟這套方法在傳統功能上跑了這麼多年，換到 AI 功能上應該也差不多吧？差蠻多的，因爲 AI 功能的 output 不固定，如果是一般功能，測的可能是 UI 或一些行為的改變，例如：按鈕顏色、文案、還是推薦邏輯等……但 AI 的回覆你沒辦法完全控制它輸出什麼，這就是最大的差異點。
尤其現在很多產品以對話式 AI 功能（AI 客服、智能問答、推薦回覆等）作為第一個落地場景時，這個問題會更加明顯。因為每個用戶拿到的回覆都不一樣，你以為在比 A 版本和 B 版本，但其實每個人看到的都是不同版本 🥲
今天想聊的是：
- A/B Testing 差異分享：傳統產品 vs AI 產品
- PM 該如何設計 AI 功能的 A/B Testing？
- Angela 真心話分享：為什麽 QA 環節很重要？
聊聊醫美場景
前陣子跟夥伴協助醫美診所的 LINE Bot 導入 AI 客服，來達到 7/24 無時無刻都能轉單的目標。客人可以透過 LINE Bot 詢問療程差異、術前注意事項、術後照護建議，可由 AI 小幫手自動回覆，不需要人工值班。
上線第一週，預約轉換率沒有明顯提升，偶爾還有客人說「問了跟沒問一樣」，這時朋友開始著急，也很合理的提出下一步，叫做 A/B testing，測看看哪個版本的 AI 回覆效果更好，以利後續優化。
當實驗開下去後，也面臨到如開頭提到的問題，AI 產品跟傳統產品 A/B Testing 的思維是完全不一樣的。
AI 實驗設計三個關鍵
關鍵一：System Prompt
沒有 System Prompt，你測的只是 AI 的隨機輸出主因在於還沒有「穩定的版本」可以比較，同一個客人問「玻尿酸術後多久消腫？」，Bot 今天說三天、明天說五到七天、後天說「建議術後回診確認」。你沒辦法完全控制它輸出什麼，Output 不可控，你分組再精準也沒用……
→ 我們的解法：先定義 System Prompt
白話文說明，就是在實驗上線前，先把自己的 Bot 問到爆！！🔥
在沒有 system prompt 的情況下，LLM 的輸出格式、長度、語氣每次都不可控（偏向自由發揮），導致 PM 沒有穩定的版本可以拿來當對照組。
而 System prompt 控制的是 AI 怎麼輸出，不是控制用戶怎麼輸入。不管用戶怎麼問，你都可以透過 system prompt 規定 AI 的回覆格式、字數上限、語氣風格、內容邊界。這是讓輸出穩定的基礎。
有了 system prompt 之後，自己手動測一輪：列出 20 個有代表性的問題，每個問題重複送進 API 跑 5–10 次，接著把結果攤開來看看同樣的問題，LLM 回覆的核心資訊一致嗎？格式穩定嗎？有沒有哪次答案跟其他次差很多？
如果同一個問題跑十次有三種不同答案，就要回去調整參數，例如把 temperature 調低（偏向法規或具有爭議的內容我們會壓到接近 0）、在 prompt 加上明確的格式指令、或在 API 回覆送出前加一層後處理檢查。
⚠️ 補充：這一步驟很土炮，但如果你跳過這一步，後面的所有數據都會讓你很痛苦，因為很多雜訊。所以我會調到「同樣的問題，回答都在可接受的範圍內」非常穩定後才開始分組。‘
關鍵二：分組邏輯
用單次對話分組，你測的可能是同一個人的不同狀態傳統 A/B testing 分組的前提是：A 組的人和 B 組的人是不同的人，兩組互相獨立。但第一次跑實驗時我用了單次對話來分組，同一個 LINE 帳號這週進來是 A 組，下週進來可能就是 B 組。舉例： 安小姐上週剛做完療程來問術後照護，這週來問新療程的價格，其實兩者需求完全不同，但我把他算成兩個獨立的受測者，因此結果跟目標完全不一樣。
→ 解法：分組單位要改成 LINE 帳號，不是單次對話。
同一個帳號，整個實驗週期只走 A 組或只走 B 組。這樣才能確保兩組是真正不同的人，比出來的結果才有意義。而實作上不複雜，只要當用戶第一次傳訊息進來，用他的 LINE User ID 判斷分組，把結果存進 DB 裡即可。之後不管他來幾次，系統都會確保他實驗週期會被分在同一組裡。
⚠️ 補充：要留意分組的定義在實驗開始前就要確定且不能中途改（概念跟傳統實驗方式一樣）
關鍵三：勝出指標之外的事情
預約率上升代表實驗已經結束？NO！沒有因為我當時只觀察我定義的勝出指標：預約率。
當預約率上升，直覺上會覺得該版本表現好，但後來才發現，預約率只能告訴你「客人有沒有按下預約按鈕」，沒辦法告訴你「AI 說的東西對不對」。那我這個實驗是只在乎預約率，但不在乎它的品質嗎？我開始反思這個實驗。
舉個例子：AI LINE Bot 回覆語氣很好、說話很流暢，客人覺得問題滿心歡喜就預約了。但把術前禁食時間說錯，客人沒有多想就照著做了，畢竟他也不確定真實性，結果到現場才發現術前的狀態不對，才知道出大事啦～☹️而這個情境是 PM 從數據上看不出來的☹️
→ 解法：預約率之外，要另外追蹤 LLM 回覆內容有沒有問題。
我們的做法是定期從 LINE Bot 的對話記錄裡隨機抽幾筆，用人工來仔細檢驗回覆內容是否正確，如果人工忙不過來，也可以用 LLM-as-judge 輔助。就是讓另一個 AI 幫你把關，逐筆檢查回覆有沒有明顯的錯誤或不適當的內容，先過濾一遍，再讓人工確認高風險的部分。
⚠️補充：預約率和回覆品質，兩個都要過，實驗才算真的結束。預約率高但回覆有問題，那仍然是不及格的實驗😂
那該如何設計 AI 產品實驗？
1. 用意圖分群取代隨機分組
以這次醫美 AI LINE Bot 場景為例，我自己的做法是在 LINE Bot 初始化的時候，直接丟幾個 Quick Reply 按鈕讓用戶根據意圖做選擇，後面的實驗分組就可以在同一種意圖裡面再做 A/B，這樣比出來的結果才有意義 😊 當然，實際落地還有不少細節要處理，例如有些用戶不會點按鈕、直接打字進來要怎麼辦？這個下一篇再來詳細說！
2. 把 Prompt 當變數來測
還記得我們有提到 System Prompt？你想測 AI 回覆有沒有比較有幫助？但每個用戶拿到的回覆內容都不一樣，你無法控制變數。所以真正可以控制的是你給 AI 的指令，例如：Prompt A 是「用條列式回答」，Prompt B 是「用對話語氣回答」，兩組用戶分別跑這兩個 Prompt，你才能比較哪一個指令設計的比較好
3. 先定義清楚成功的樣子，然後用指標測量是否達成
與其等一個實驗跑兩週才知道結果，不如先想清楚「什麼叫好的回覆」，是用戶有沒有繼續追問？有沒有直接離開對話？有沒有給負評？接著把這些訊號變成持續監測的指標，AI 每次更新你馬上就知道有沒有變好，就不需要都從頭設計實驗。
Angela 真心話分享：QA 環節很重要
其實在醫美、醫療相關甚至金融、法律等 AI 產品上，資訊錯誤有可能是踩到醫療與法律責任問題，所以 QA 環節需要變成實驗的一部分。
而實際帶過這類導入的觀察是，很多團隊在 QA 這件事上投入的資源會遠低於應有的比例 ☹️。大家普遍覺得 AI 說得自然啊，應該沒有問題吧！但自然不一定正確，所以每一輪實驗開始前，都需要有人對照醫療事實逐筆抽查，包含回覆有沒有觸及不該碰的診斷建議？個人化的回覆有沒有把 A 療程的注意事項，錯配給詢問 B 療程的客人？
你的團隊在做 AI 功能的 A/B testing，目前走到哪個階段了呢？歡迎一起交流，我很想知道不同場景的實際狀況～～如果這篇對你有幫助，歡迎追蹤我的 Newsletter，持續分享 AI 產品策略的實戰觀察。