模型變小？
週三的產品規劃會議，我被問了一個看起來很簡單、其實讓我卡住很久的問題：
「如果模型壓縮之後變小了，那我們的產品是不是就會變快？」
我前幾天剛好看到平台上〈三元 LLM 的 1.58-bit 之後：壓縮格式如何變成推論效能〉這張卡，裡面提到模型的壓縮格式可能會影響推論效能。老實說，1.58-bit、三元 LLM 這些細節我還沒有能力自己判斷，看到公式會先放空 😂 但我突然發現，自己以前一直把「模型更小」直接翻譯成「使用者等比較少」。這個翻譯可能太快了。
會議上工程師說可以研究小一點的模型，我第一個反應是把需求寫成「AI 回覆等待時間控制在 2 秒內」。現在回想，那其實只是我的願望，不是驗收條件。因為 2 秒是從哪裡開始算？按下送出，還是畫面出現第一個字？如果第一個字 2 秒出現，但後面又停住 5 秒，使用者會覺得快嗎？我當下完全沒想過。
所以我們臨時畫了 3 個原型流程：客服查詢、會議摘要、幫忙改寫一段文字。原本我以為只要拿同一個問題去跑，記錄總秒數就好，結果第一個坑馬上出現。客服查詢的內容很短，等待感還可以；會議摘要需要處理比較長的內容，畫面雖然很早就有反應，但中間停頓時，我以為系統壞掉了；改寫功能則是很快吐出結果，可是用字不符合我們產品原本的語氣，PM 看到的「快」跟使用者要的「可直接用」根本不是同一件事。
那天我有點尷尬，因為我本來以為自己是在幫忙定義效能，最後才發現我只是把一個技術方向換成一個漂亮的數字。模型變小可能降低某些部署負擔，也可能讓推論路徑、硬體支援、輸出穩定度出現新的取捨。這些我不敢裝懂，但至少我現在知道，不能只問「壓縮幾成」或「模型幾 B」。產品要驗收的是使用者實際感受到的流程。
我們後來把驗收問題改成這幾個，先記下來給跟我一樣的 PM：
- 使用者從按下送出，到看到第一個有意義的回應，要等多久？
- 第一個字出現之後，後續輸出有沒有常常停住，讓人以為當機？
- 同一個任務連續試 5 次，速度和結果品質的落差大不大？
- 回覆雖然變快了，使用者需要自己重寫或重做的比例有沒有增加？
- 不同長度的輸入，短問題和長文件是不是要分開驗收？
- 速度變快之後，成本、錯誤率、內容格式有沒有一起被記錄？
- 如果模型或壓縮格式換掉，使用者能不能在產品介面上感覺到差異，差異又是不是可接受？
我現在比較喜歡把「模型更小」當成一個待驗證的產品假設，而不是成果本身。工程師可以告訴我壓縮格式和推論怎麼做，但我需要追問的是：在客服人員最忙的那 10 分鐘裡，他會不會少等一次？在會議摘要那個流程裡，他會不會因為中途停頓而重按送出？
天啊，原來 PM 學 AI 不一定要先把每個 bit 都搞懂，但要很小心，不要把自己不懂的技術名詞，包裝成一個看似精準的需求。下次再有人說「模型變小所以會更快」，我應該會先問：快在哪個流程，快到什麼程度，使用者怎麼證明他真的覺得快？🤔
作者：菲菲