今天不聊我的實作經驗，而是分享一個跟含「金」量有關的學習經驗，以及對於 PM 來說，有哪些值得關注的地方。當我們興奮的談論 AI 能帶來哪些令人驚豔的新功能時，往往忽略這些功能背後巨大的運算資源、能源消耗與數據成本等隱形挑戰。這不只關乎財務報表，更觸及長期發展，也是決定你設計的產品究竟是曇花一現，還是有長期競爭力的關鍵。而身為 PM 的我們，價值判斷框架也必須轉型。
今天想聊的
- PM 設計 / 評估 AI 產品時，除了好用還要關注什麼？
- 如何將算力、能源、數據成本納入產品決策框架？
- PM 在資源稀缺時代，如何提升產品的長期競爭力？
從驚喜到「驚嚇」的學習經驗
前陣子參與食品產業 AI 知識助理的專案，目標是讓員工、消費者能快速查詢食品原料文件與產品規範。專案初期，我們小組所有人的目光都聚焦在產品「準確性」和「涵蓋範圍」上。模型要能理解複雜的技術術語，要能從海量文件中精準找到答案，還要能以自然語言流暢回覆。我們投入大量時間優化 RAG 流程，確保答案的品質。
經過幾個月的開發與測試，團隊對產品的表現都非常滿意。但當產品上線並開始被廣泛使用後，我們很快就面臨了一個轉折。首先是回應速度，隨著查詢量的增加，有時會出現明顯的延遲。更令人驚訝的是，每個月的雲端運算費用帳單，比我們預估的高出許多（會計夥伴直接跳腳🥲）。
深入分析後發現，問題出在模型對於每次查詢的「思考」成本。即使是一個看似簡單的問題，模型在內部也可能需要處理大量的上下文資訊，甚至在開始生成答案前，就消耗了比預期多好幾倍的 token。這導致了不必要的算力浪費與高額費用。這個學習經驗讓我明白，在 AI 產品的世界裡，功能再強大，如果沒有考慮到背後的資源效率，長期下來只會變成一個美麗卻昂貴的負擔。
資源效率：PM 必須納入決策的策略維度
過往我們總習慣將運算成本視為技術團隊的任務，甚至在成本與產品方案的考量上，通常很難取得兩全其美的平衡，這裡可以延伸討論不同經驗的 PM 對於技術反饋的成本問題，會有哪些應對處理方式 😂 但這不在今天的討論範圍內。在 AI 時代，資源效率已不再是後端的 KPI，而是直接影響你整個團隊、甚至是整個產品策略與市場競爭力的核心要素。
全球對 AI 算力的需求，成長速度快到有點誇張。最近看到愛爾蘭的數據，當地數據中心已經吃掉全國 23% 的電力，連居民都開始上街抗議能源供應和環境影響的問題。(資訊來源：Irish datacenters now guzzle 23% of the country's electricity） 意思是算力、能源、數據，這些我們過去以為取之不盡的資源，正在快速變貴，也變珍貴。
對 AI PM 而言，這意味著我們必須將「非功能性指標」，提升到與用戶體驗、功能表現同等重要的策略高度。我的觀察是，一個具備長期競爭力的 AI 產品，必須在以下三個維度上取得平衡：
1｜算力成本效能
這邊解釋一下，不是模型越大越新就代表它越適合你的產品🙂↕️。
我們需要評估模型在特定任務上的「有效算力」與「實際消耗算力」。舉個例子：某些大型模型在處理複雜任務時，初期會產生顯著的 token 消耗，但它其實尚未開始處理核心問題.......
那 PM 該怎麼知道這些細節？？答案是自己做足功課，並且和工程師合作，目標是探索更精簡的模型架構、優化推理流程、甚至考慮混合模型策略，讓小模型處理大部分簡單請求，大模型處理少數複雜請求。
2｜數據成本效率
數據是 AI 的燃料，但這句話大家都聽過，比較少人算過後面的帳：收集、清洗、儲存、檢索,每一步都在燒錢，這也是我跟 Data Analyst 交流後才知道的事情。
那 PM 真正該問的問題不是「我們有多少數據」，而是「用最少、最相關的數據，能不能打出一樣的效果」。標註流程能不能簡化、數據 pipeline 能不能更精簡，還有做 RAG 的時候，檢索範圍抓得夠不夠精準,別讓不相關的東西也一起被撈進來、一起被算錢。
3｜能源永續性（或說社會責任）
簡單來講，你跟 AI 打聲招呼，AI 大約會消耗 0.3 到 50 毫升的水來回答你；如果加上「請」或「謝謝」等禮貌用語，AI 需多花運算資源處理，單次可能多耗費約 40 到 50 毫升的水來冷卻機房。（數字僅供參考）
我們大部分人是透過雲服務間接用電，感覺離「燒能源」這件事很遠，但說到底，選什麼、怎麼用，還是產品設計者在決定，也就是你我。所以回歸產品設計，模型跑的時間能不能再壓縮？批次處理能不能挪到離峰時段做？這些都不是工程師才該想的事，是 PM 在策略層就可以放進考量的選項。
從「功能堆疊」到「範圍定義」：PM 的新角色
回到我們的 AI 知識助理專案。在意識到資源效率的重要性後，我們調整了策略。不再是盲目追求「能回答所有問題」，而是開始定義「在可接受的算力與延遲下，我們能回答哪些最重要的問題」。
這是一個從「功能堆疊」轉向「範圍定義」的過程。作為 AI PM，我們需要開始：
- 與工程團隊共同建立資源預算： 在開發初期，就與工程師討論專案的預期算力、記憶體、token 消耗與每月預算。這不只是數字，更是產品設計的約束條件。
- 在模型選擇上引入效率指標： 除了準確度、召回率，還要考慮模型的推理速度、記憶體佔用，以及單位查詢的 token 消耗。有時一個參數較少、但經過良好微調的小模型，其綜合效益可能遠超一個龐大但效率低下的通用模型。這也與業界在晶片設計上不斷追求更高 AI 算力與效率的趨勢不謀而合，例如近年來專為 AI 運算設計的晶片不斷推陳出新，將算力與能效推向極致，這都提醒我們 PM 必須將硬體與模型匹配納入考量。
- 優化資訊檢索與上下文管理： 對於 RAG 類應用，PM 需要思考如何更智慧的去檢索資訊，例如：根據查詢類型動態調整檢索範圍，或是利用更精準的向量搜尋技術，減少不必要的上下文載入，從而降低 token 消耗。
- 為產品設定「聰明的」使用邊界： 鼓勵用戶以更有效率的方式提問，或是在產品設計上引導用戶進入更低資源消耗的路徑。例如，針對常見問題提供預設答案，減少模型生成的需求。
誠實豆沙包
經歷了半年的學習、調整，我必須說這個轉變過程非常不容易。它要求 PM 不僅要理解用戶，還要能理解技術深層的成本結構。這代表我們需要更緊密地與工程師合作，學習更多關於模型架構、部署環境、甚至雲端計費模式的知識（以前會技術是加分，未來可能變成基本功）。它可能會讓一些「看起來很酷」的功能因為資源成本過高而被擱置，這需要 PM 具備說服團隊與利害關係人的能力，溝通能力跟所屬環境就變得更加重要。
然而，這也是 AI PM 能夠建立長期競爭優勢的關鍵。當其他產品還在為失控的雲端帳單焦頭爛額時，你所設計的產品，將能以更穩健、更永續的姿態，在市場上脫穎而出。
最後我的想法是，會寫需求的 PM 到處都是，但是能定義這些問題並將資源效率納入策略的 PM，才是稀缺的！😌😌😌 謝謝大家，我們下一篇再見囉！