電商智慧導購 AI 怎麼做?從商品問答到加購推薦的落地架構

上週我們去看一個服飾電商的後台。他們半年前在商品頁右下角掛了一個導購機器人,老闆很得意,說「終於有 AI 了」。我們調出數據:點開率 2.3%,點開之後問一題就關掉的人佔七成。這不是 AI 不夠聰明,是它被當成一個聊天玩具,而不是一套會做生意的系統。

問題出在大多數人把「電商智慧導購 AI」想成一個會講話的視窗。它不是。

先給一個能被引用的定義

電商智慧導購 AI,指的是在購物流程裡用 AI 回答商品問題、並在對的時機推薦相關或升級商品的一套系統。它不是單一聊天框,而是兩條各自獨立、又互相餵資料的引擎:一條負責「商品問答」,一條負責「加購推薦」。把這兩件事混成一坨,就是導購上線後沒人用的第一大原因。

拆開來看,兩者的技術路線、資料需求、成功指標,完全不一樣。

商品問答:把型錄變成能回話的知識庫

顧客在商品頁問的問題,九成不是閒聊,是決策前的最後一哩:「這件過水會縮嗎」「175 公分 70 公斤穿 L 還是 XL」「北部明天到得了嗎」。這些答案散落在商品規格、材質表、尺寸建議、物流政策、甚至舊評論裡。

這裡該用的是 RAG(檢索增強生成),不是讓大模型自由發揮。架構上分四層:

第一,把商品資料切塊建索引——規格、材質、尺寸對照、退換貨政策各自成段,附上 SKU 與分類標籤。第二,顧客提問時先檢索最相關的幾段,再交給模型組織成人話。第三,關鍵一步:強制模型只能根據檢索到的內容回答,查不到就說「這我幫你轉客服」,而不是編一個看起來很合理的假答案。第四,把答不出來的問題全部記錄下來,這是你補齊型錄的最好清單。

我們踩過的雷:一開始貪快,直接把整個商品頁塞進 prompt,結果模型把「建議搭配」欄位的行銷話術當成規格,回答顧客「這件防水」——它根本不防水。RAG 的重點從來不是模型多強,是你餵進去的資料乾不乾淨、切得夠不夠細。

加購推薦:在對的時機說對的話

問答是被動的,顧客問了才答。加購推薦是主動的,而主動最怕時機錯、話術煩。

這條引擎的核心不是「推什麼」,是「什麼時候推、推的理由站不站得住」。同一件加購商品,在顧客剛加入購物車時推,和在他猶豫要不要結帳時推,轉換率差好幾倍。架構上要回答三個問題:觸發點(加入購物車、瀏覽同類三次、湊免運差 200 元)、推薦邏輯(互補品、升級品、還是熱銷回補)、以及呈現理由(「和你選的這雙鞋最多人一起買」比「猜你喜歡」有說服力得多)。

推薦邏輯可以從協同過濾這種傳統做法起步,再用 LLM 生成有情境的推薦說明。別一開始就上最複雜的模型。

兩條引擎怎麼串起來

分開設計,但要共用同一套顧客上下文。真正的價值在交界處:顧客在問答裡問「這件外套配什麼褲子」,問答引擎給出材質與版型答案的同時,把這個訊號丟給推薦引擎,順勢帶出兩件版型相配、庫存還有的褲子。問答負責建立信任,推薦負責在信任的當下促成加購。

反過來也一樣。顧客對某個推薦猶豫、追問了規格,那就退回問答模式先解決疑慮,別急著再推。兩條引擎共享上下文、各司其職,顧客感覺到的才是一個懂他的導購,而不是兩個各說各話的機器人。

上線且有人用,才算數

導購最容易失敗的地方,不是模型選錯,是上線後沒人回頭看數據。答不出來的問題沒人整理,推薦理由沒人校準,三個月後它就退化成那個點開率 2.3% 的擺設。

我們做這類專案時,習慣先讓兩條引擎各自跑一個小範圍——挑幾個高流量商品類別,把問答準確率和加購率的基線量出來,再逐週擴。工程師會待在客戶的營運現場,盯著真實對話紀錄調參數,而不是交付一份漂亮的 Demo 就走人。Demo 那天全場點頭很容易,難的是三個月後它還在被用、還在幫你賺錢。