AI 專案卡關？你可能正在解決錯的問題

從 Spotify 的反直覺實驗談起，看懂 AI 專案最常見的三種認知落差

客戶說 AI 一直亂講話，團隊便開始調整 Prompt；客戶說搜尋不到資料，便加派人力補標籤；客戶說系統很卡、流程經常中斷，工程師便不斷修 Bug、加防呆。

這些做法聽起來都很合理，卻可能建立在同一個錯誤上：把客戶描述的「現象」，直接當成問題的「原因」。

結果就是，大家投入了更多時間與資源，問題卻沒有真正改善。

Spotify 的提醒：聽懂技術名詞，不等於理解技術

2014 年，一位在 Spotify 實習、研究推薦系統的工程師 Sander Dieleman，做了一項當時看起來不太直覺的嘗試：使用卷積神經網路（CNN）分析歌曲的音訊內容。

當時很多人對 CNN 的印象仍停留在影像辨識，但 Dieleman 想解決的，其實是推薦系統常見的「冷啟動問題」。

傳統推薦系統通常需要參考使用者的播放、收藏與跳過紀錄，判斷一首歌可能適合哪些人。然而，新歌和冷門歌曲缺少足夠的互動資料，系統自然很難推薦。

Dieleman 的做法，是讓模型直接從音訊中學出歌曲的潛在特徵。如此一來，即使歌曲還沒有累積足夠的播放資料，系統仍有機會判斷它可能適合哪些聽眾。延伸閱讀 Spotify 的技術實驗

如果當時的討論只停留在「CNN 是做影像辨識的」，這個想法可能連進入實驗驗證的機會都沒有。

同樣地，在 AI 專案裡，當我們只聽懂一部分技術名詞，再用直覺補完剩下的認知落差，就很容易看錯問題，也選錯解法。

核心問題

客戶說的是現象，不一定是原因

客戶通常只能描述自己遇到的狀況，例如「AI 一直亂講」、「搜尋不到東西」或「系統跑到一半會卡住」。

需求端收到抱怨後，往往急著提出解法；技術端則根據這個解法開始執行。但如果一開始對問題的理解就錯了，後續做得越多，反而可能離真正的原因越遠。

以下是 AI 專案中常見的三種認知落差。

1. 把「記憶問題」當成「智商問題」

當客戶抱怨 AI 亂講話時，團隊可能認為模型不夠聰明，於是不斷修改 Prompt，甚至考慮更換更強的模型。

但問題也可能不是模型不會回答，而是它根本沒有取得正確的內部資料。

例如，客服機器人被問到公司最新的退貨規則，卻只能依靠模型原本學過的內容作答。這時無論怎麼調整 Prompt，都無法補上系統從未取得的資訊。

因此，真正該確認的是：

• 系統能否取得正確且最新的內部資料？
• 檢索時是否找到了真正相關的文件？
• 回答內容能否追溯到可信來源？

如果問題出在知識存取，團隊才需要進一步評估是否導入 RAG，讓模型根據企業內部資料回答，而不是在缺乏依據時硬猜。

2. 把「理解問題」當成「關鍵字問題」

當客戶抱怨搜尋不到商品或文件時，團隊可能以為是標籤不夠完整，於是投入更多人力補標籤、加關鍵字。

但使用者搜尋時，不一定會使用與資料完全相同的字詞。

例如，使用者搜尋「適合梅雨季穿的鞋」，商品資料裡可能只有「防水」、「止滑」和「快乾」。如果系統只會比對相同關鍵字，即使標籤增加了，也未必能理解這些概念之間的關係。

此時真正該確認的是：

• 問題來自資料標記不足，還是系統無法理解語意？
• 使用者是在搜尋特定字詞，還是在表達一種需求？
• 現有搜尋方式能否處理意思相近、用詞不同的內容？

如果問題出在語意理解，團隊才需要評估向量檢索或混合搜尋，讓系統能根據意思尋找資料，而不只是比對關鍵字。

3. 把「流程邏輯問題」當成「穩定性問題」

當客戶抱怨系統很卡、跑到一半經常中斷時，團隊可能直覺認為系統不穩定，於是持續修 Bug、加防呆。

但問題也可能出在一開始的流程設計。

例如，同樣是申請退款，「已出貨」需要先完成退貨，「尚未出貨」則可以直接取消並退款。當一項任務開始出現多種狀態與分支，原本單一路徑的流程就可能無法支撐。

此時真正該確認的是：

• 系統能否辨認任務目前進行到哪個狀態？
• 遇到不同條件時，能否進入正確的處理分支？
• 任務中斷後，能否從原本的位置繼續？

如果問題出在流程結構，團隊才需要評估具備狀態與分支管理能力的工作流設計，例如 LangGraph，而不是繼續在線性流程上增加更多修補。

關鍵洞察

工具不是答案，診斷才是起點

RAG、向量檢索與工作流框架，分別處理不同層次的問題，但它們都不是聽到特定抱怨後就能直接套用的標準答案。

即使同樣是「AI 亂講話」，原因也可能是資料過期、檢索錯誤、Prompt 不清楚，或模型能力不足；同樣是「系統卡住」，也可能來自程式錯誤、等待逾時，或流程無法管理多種狀態。

因此，在選擇技術之前，團隊應先回答三個問題：

1. 問題發生在哪個使用情境？
2. 問題可能來自資料、檢索、模型，還是流程？
3. 要設計什麼測試，才能證明問題真的被解決？

先定義問題，再選擇工具；先設計驗收方式，再投入開發。否則，技術導入得越快，也可能只是在錯誤方向上前進得越遠。

拒當無效傳聲筒：把抱怨轉譯成可驗證的問題

真正讓 AI 專案卡住的，往往不是大家不夠努力，而是每個人都在用不同的語言討論同一件事：

• 客戶描述的是：「我用起來哪裡不順。」
• 需求端關心的是：「怎麼趕快把問題修掉。」
• 技術端思考的是：「系統缺少哪一層能力。」
• 決策者在意的是：「修完之後，能不能放心上線。」

如果中間沒有人負責翻譯，客戶的抱怨很容易被直接轉成一個尚未經過診斷的解法。

因此，一個好的「數據翻譯官」或 Analytics Translator，不只是把客戶的原話轉交給工程師，而是要完成三件事：

1. 還原問題發生的使用情境與影響。
2. 把模糊抱怨轉成可以診斷的技術假設。
3. 定義修正後可以驗收的成功條件。

這個角色的價值，在於接起業務需求與技術判斷之間的落差，讓客戶、需求端、技術端與決策者，可以用同一套標準討論問題。延伸閱讀 Analytics Translator 的角色

好的翻譯，不是把一句話換成另一個技術名詞，而是把「AI 很難用」這種模糊感受，轉換成可診斷、可實作，也可驗收的問題。

金句啟發

名詞只聽懂一半，問題就會對不齊。當講不出同一種語言，會議室裡就只剩直覺投票。

延伸閱讀

1. 使用 CNN 學習音訊潛在特徵，克服冷啟動問題｜Recommending Music on Spotify with Deep Learning
2. 接起業務與數據專家鴻溝的 AI 成功關鍵角色｜Analytics Translator – The Must-Have Role

重點整理

為什麼 AI 專案經常很努力，問題卻沒有改善？

因為團隊可能直接把客戶描述的現象當成原因，在還沒有完成診斷前，就開始調整 Prompt、補標籤或修 Bug。投入的資源越多，不代表方向越正確。

聽到客戶抱怨後，應該立刻導入 RAG、向量檢索或工作流框架嗎？

不一定。這些技術分別處理不同層次的問題。團隊應先確認問題來自資料、檢索、模型還是流程，再選擇適合的工具，並設計可以驗證改善結果的測試。

「數據翻譯官」在 AI 專案中扮演什麼角色？

他的工作不是單純傳話，而是把模糊的使用者抱怨，整理成具體的使用情境、可診斷的技術問題與可驗收的成功條件，讓需求端、技術端與決策者能用同一套標準討論問題。