如果你設計過 AI 相關的產品或功能（像是 AI 客服、內部知識問答,甚至只是一個會議摘要的按鈕......)大概都經歷過這個場面，我們在 QA 階段覺得一切完美，連各種 Error Handling 都網羅且定義清楚了，結果一上線模型卻開始答非所問 😂 難道是模型不夠聰明？還是哪裡出問題？
這篇文章想跟你分享以下三點，也許是你在 retro 會經歷到的問題：
- 同一個模型，為什麼測試時順利，上線就頻頻出錯？
- 你不能期待使用者按照關鍵字問問題，那系統該採取什麼做法？
- 資料明明足夠，AI 為什麼還是無法回答清楚？
根據我經歷過幾類 AI 產品落地的經驗，最大的體會是問題常常不在模型的能力，也不在檢索引擎。真正的問題往往是更上游的一層，也就是在問題和資料真正進到模型「之前」，我們怎麼定義跟處理它們。
底下我會用兩個真實案例，把上游拆解清楚。就算我們不會寫程式也一定看得懂，理解後你的職能可以往 AI 更靠近一步，成為真正的 AI PM，同時也可以幫團隊省下一大筆無效的試錯成本（畢竟每一次試錯,都是在燒 Token）。
企業內部知識庫系統
1. 你不能期待使用者按照關鍵字問問題
場景是公司的內部行政知識庫。HR 想在團隊裡建立一套行政流程問答系統，且公司人越來越多，每天 HR 同仁都被重複的問題淹沒，所以他們希望透過 AI 建立內部知識庫，把效率提升起來。
我們的做法是先把公司所有的規章、行政制度等文件全部整理出來，餵給 AI 當成它的「知識大腦」(補充：這個概念是「先檢索、再讓模型生成」的架構，就是常聽到的 RAG)，再透過 LLM 搭配我們已經校正過的 System Prompt，做成一個有前端介面的產品。
這產品聽起來很單純。但我們做完、開始內部封測後，就發現了蠻多問題。比方說同仁對系統只輸入「我想請假」，知識庫就洋洋灑灑把病假、事假、特休、產假的規定全列出來，產出冗長的一大篇，要員工自己看。
後來內部檢討時我們發現，使用者其實不太清楚應該怎麼問，才能問得精準。如果檢索這一層處理得不夠細緻，系統就只能拿使用者實際打出來的字，去對應到最接近的內容。它一開始就沒拿到足以聚焦的線索，而我們也不可能強迫每一位員工都把需求講得清清楚楚。真要那樣就跟傳統沒有 AI、靠關鍵字比對的知識庫沒什麼兩樣（命中關鍵字就吐回一堆內容），又何必做一個 AI 產品?
所以我們後來的調整是在把問題丟進檢索「之前」先補一層處理。這一層拆開來看，其實是以下三個動作在接續：
- 意圖識別：先判斷這個人想做什麼，比方說他是不是要請假。
- 槽位填充：要完成這件事，使用者的問題裡還缺哪些關鍵資訊(比方說假別、天數)。
- Query 改寫：把補齊後的需求，重新寫成一句檢索友善的查詢。
具體來說，當系統判斷使用者的問題缺了關鍵 slot (像是假別、天數)，它不急著去查資料，而是先反問一句，等使用者補上，再把這個更完整的問題改寫成乾淨的查詢，送進知識庫。
- 員工：我想請假
- 系統：請問您想了解哪一種假別的規定呢？(病假 / 事假 / 特休 / 產假)
- 員工：（點選）特休
- 系統內部改寫成查詢:「特休的請假條件、可用天數與申請流程」，再送進 RAG
2. 產品設計的經驗談
有幾個產品設計上的眉角，是能累積經驗的地方
第一：反問不能變成「逢問必反問」，不然使用者會覺得很煩躁😩。所以我們設了一道判斷是系統會先評估手上的問題「夠不夠拿去檢索」，只有當它發現缺了關鍵槽位、意圖又不夠明確時，才反問。
第二：該怎麼問？我們沒有讓使用者自己打字補充，而是直接給幾個選項按鈕(病假、事假、特休、產假) 直覺性的點一下就好。這不只是讓使用者輕鬆，對系統來說按鈕回傳的是一個明確、封閉的值，不會再多出一句得重新推測的內容，所以等於我們用一個 UI 設計，順手把下一輪的輸入品質也處理好了。
第三：留一條真人客服的路。萬一補問完還是答不出來，我們不傾向讓 AI 隨便回答，而是希望把它導到真人的窗口，由真人客服幫忙轉接。
總結來說，我們只多了幾個的小動作，卻讓產品品質與效果大大提升。使用者拿到的不再是一篇要自己撈重點的長文，而是針對他的問題精準回答。而這整段調整，我們沒有換掉任何一個底層模型，也沒有再多餵一份資料。所以能讓這個產品從「能用」變「好用」的，不是更強的模型，而是在問題進到模型之前，先幫使用者把問題問清楚。
B2B 產品的 AI 客服
1. 資料足夠，但會被切碎
我們在做 B2B AI 客服的時候，一樣是把所有關於這個產品的規格、細節、購買方式，全部都會給 AI，但測試時我們問了：「Pro 方案版本同時支援幾個人在線？」答案明明就寫在我們餵給 AI 的 PDF 產品手冊裡，但 AI 卻沒辦法精準回應。
正當我們以為是資料沒吃進去，把整份 PDF 重新上傳後，結果還是一樣。後來我們把資料庫撈出來看，問題出在資料「切塊」的方式。一份文件要變成 AI 查得到的知識，中間有一條看不見的輸送帶，像是要先解析 PDF、轉成純文字，再切成一段一段 chunk，最後轉成向量、存進資料庫，當使用者問問題時，系統才拿問題去比對、撈出最相關的那幾段。
原本 PDF 裡那張方案對照表是一個大表格。系統把它轉成純文字、再按固定長度切塊時，把表格的標題(Pro 版)跟對應的數值(50 人)切開，散落到不同段落去，對 AI 來說，它手上沒有任何一段同時寫著「Pro 版 = 50 人」。更關鍵的是，當客戶的問題被轉成向量、拿去資料庫裡比對，「Pro 版能同時上線幾人」這句話跟上面任何一段的語意都不夠接近，所以正確的段落根本沒被撈出來。
於是我們回頭處理資料的清洗跟結構化。
- 先把所有資料轉成 markdown 格式，讓「Pro 版」跟「50 人」這種對應關係，在文字層面就被綁在同一列。
- 把切塊規則從「按固定字數硬切」改成「認得文件結構」，讓一整張表被當成一個完整單位，不會在中間被切斷，每一段也盡量帶上它所屬的章節脈絡（例如：這是哪個產品、哪個段落底下的資訊）確保它離開原本的上下文之後，還讀得懂。
這背後有個原則，我覺得值得每個做 RAG 的人記住：進到資料庫的每一塊知識，都應該是「就算單獨被抽出來，也讀得懂」的。 一塊知識如果非得靠前後段落才說得清楚，那它被切碎、被單獨撈出來的那一刻，就已經失真了。
結果，資料重新處理之後，AI 不只能精準回答數字，還能順手幫客戶比較不同方案的差異。因為這一次，它手上拿到的是一張完整的表，而不是幾片拼不回去的碎片。
結語：所謂 AI PM 的價值
一位真的懂 AI 如何落地到人間的 PM，總不能只追著最新模型去嚐鮮，而是會去設計系統的防線。下次遇到類似的意思，可以先反問自己「我們確定進到模型裡的『問題』跟『背景知識』，都是乾淨又精準的嗎?」把注意力放回這層上游，才是讓一個 AI 產品從「快速落地變成商用工具」的關鍵。