一、場景化導購背景

1. 為什么要做場景化導購

為什么要做場景化導購？通常，用戶訪問電商平臺時帶有明確的需求。他們會通過搜索、瀏覽推薦等方式尋找相關商品，隨后進行篩選決策，最終完成交易和履約。在這一過程中，尋找和篩選階段構成了導購環節。

當前電商平臺存在幾個問題：

• 消費群體差異化需求未得到充分識別。不同消費群體在訪問電商平臺時，其關注點存在顯著差異，但平臺未能有效區分。例如，育兒群體可能對促銷和價格優惠特別敏感，平臺應針對性地提供更有效的展示和提醒。
• 商品篩選階段信息繁雜、效率低下。現有電商平臺上信息種類繁多，包括各種優惠政策、服務條款以及用戶評價等。然而，這些信息往往散落在圖片、文字等不同載體中，導致用戶難以快速獲取對自身有價值的信息。
• 難以滿足非標準化購物行為。例如，當用戶搜索服裝后希望進行更多個性化篩選時，平臺往往只能提供標準化、被動式的導購流程，如選擇配送地址、篩選包郵商品或選擇尺碼等。這種扁平化的體驗難以滿足用戶的多樣化需求。我們希望中心貨架平臺能從扁平化體驗走向垂直化、主動式的體驗，這是我們做智能體驅動場景化導購的出發點和初衷。

2. 什么是場景化導購

場景化導購可以通過三個關鍵詞來概括：貼切、沉浸和信任。

• 貼切：針對特定人群的差異化需求，提供更具針對性的服務"界面"，即定制化的交互過程。例如，對于寶媽群體，平臺應該提供與其相關的采購知識，并根據不同孕齡階段調整信息內容。此外，平臺還需要提供豐富的商品輔助信息。
• 沉浸：提升消費者購物過程的便捷性和連貫性，改善當前割裂的消費體驗。目前，消費者在瀏覽平臺上的商品后，往往需要在小紅書、B站等不同平臺間切換，以獲取博主評價、產品評測或優惠信息。場景化導購旨在整合這些信息，提供一站式的購物體驗。
• 信任：幫助消費者全面了解商品，增強其決策信心。例如，根據消費者的關注點（如售后服務），突出顯示相關的用戶反饋，如"多位用戶反饋該商家的售后服務非常可靠"。

從人群定制化服務出發，通過主動引導和互動式導購，為消費者提供一個全面、連貫且值得信賴的購物體驗。

3. 場景化導購智能體框架

產品和技術層面的場景化導購智能體框架主要包含以下幾個方面：

• 工具：1688 平臺擁有豐富的服務資源，包括商品搜索、圖像搜索、比價雷達，以及平臺商品價格走勢、物流服務等一系列原生服務工具。
• 買家畫像：平臺在用戶采購過程中，會關注并分析用戶信息和行為特征，構建更細粒度的畫像。
• 意圖理解與過程把控：系統能夠追蹤并理解用戶的需求意圖。比如，當用戶表達“想要為參加聚會購買合適的衣服搭配”這樣較為復雜的需求時，系統能夠基于用戶的上下文，將導購任務進行合理拆解。
• AI 場景化導購應用：包括但不限于 AI 穿搭推薦、AI 商品搜尋、AI 商品分析建議等場景化導購智能體。

4. 場景化導購智能體的挑戰

場景化導購智能體有幾個挑戰需要去解決：

• 復雜意圖理解：在實際場景中，用戶需求的表達往往更為復雜。例如，購買連衣裙時，用戶可能會描述“想買一件適合特定場合穿著的小碎花連衣裙”。這種復雜的需求描述可能需要通過與智能體多輪交互對話來逐步獲取信息。在此情況下，需要構建一個能夠組織和記憶買家在平臺上整個行為的結構化系統。
• 平臺原生應用的集成與調用：這包括原生工具與智能體之間的交互和調用適配，與搜索工具的聯動，以及潛在的數據分析聯動等。
• 場景化知識構建與分析：智能體的關鍵在于數據的差異性。1688 導購智能體與其他導購智能體的區別并不在于所使用的模型或鏈路，而在于我們擁有獨特的數據資源。這是平臺沉淀垂直領域智能體的核心價值。我們已構建了自己的知識體系，包括知識鏈路以及圖片類多模態數據的處理方法。

二、場景化導購智能體實踐

1. 買家對話意圖和行為動線意圖識別

對話消息意圖的識別，最簡單的情形是單人消息，例如描述一個較為復雜的需求，如為全家聚會購買衣物的要求。在使用大型語言模型進行識別時，通常會采用結構化的思維鏈（Format Chain of Thought）。這種方法使得模型不必立即輸出結果，而是先進行一段分析以理解用戶意圖，隨后再執行相應的操作。然而，在很多情況下，與用戶的交互會涉及多輪對話。我們需要判斷何時應對多輪對話的上下文進行壓縮或重寫，何時可以保留全部信息。此外，提示詞（Prompt）的描述應當結構化，一方面是因為結構化語言在底層描述上具有普遍適用性，另一方面則是由于預訓練階段大量的代碼語料使得大型語言模型能夠更好地理解和處理這種結構性。

在線上環境中，意圖分析經常會出現錯誤。例如，用戶詢問關于尺碼的問題，但系統卻將其解讀為關于材質的問題。對于這種情況，需要建立相應的反饋機制。目前的處理方式是將這類案例存儲在錯誤庫中。有了錯誤庫之后，整個流程就遵循檢索增強生成（Retrieval-Augmented Generation）的邏輯，即在接收到問題后，需要補充知識內容以構建一個信息量更豐富的上下文。

除了消息類的意圖識別，我們還在探索在客戶端上分析用戶行為軌跡意圖的可行性，并進一步引導輔助決策。這就需要將一個相對小型的模型集成到客戶端上。我們嘗試了從幾十兆字節到幾百兆字節不等的模型，盡管仍面臨不少挑戰，但這種邊緣智能的解決方案不僅能適應實時反饋的場景，還能充分利用邊緣計算能力來優化產品體驗，同時對用戶數據的隱私保護更為友好。

2. 計劃式學習-用小模型追蹤對齊任務狀態

當大型語言模型剛剛問世時，業界鮮有團隊著手研究計劃式學習，即利用小型模型在 Agent 架構中承擔規劃任務。所謂計劃式學習，可以以購買手機支架為例進行闡釋：模型應具備任務識別能力，為完成購買手機支架的目標，需制定商品搜索計劃。該計劃的主題是手機這一商品類別，對此需要收集相關信息（如預算和品牌等）。為了完成這一計劃，模型需要向用戶提問，例如詢問預算。若用戶回答"100 元左右"，部分信息便得到更新。隨后，模型繼續詢問品牌偏好等問題。信息收集完畢后，模型將生成一個查詢語句，如"100 元左右的任意品牌手機支架"，然后執行商品搜索操作并返回結果。

在計劃式學習的指令微調（SFT）階段，我們采用了對話式訓練模式，即構造多輪交互式指令以激發基礎模型對任務形態的理解。SFT 完成后，還可通過進一步對齊來提高模型的追蹤準確性。追蹤準確性指的是模型在詢問完預算后是否會繼續詢問品牌，而非生成無關內容。這種能力難以僅通過 SFT 培養，需要通過對齊訓練來強化模型的內在結構性約束。

我們進行了對比實驗，在 Bloom 1.5B 基礎模型上，經過強化學習對齊后，其信息追蹤準確性提高了 5 個百分點。許多普遍的對齊實現，通常不是對整個序列進行評分和約束，而是僅對最后一個 token 進行約束。在我們的場景中，除了最后一個 token 外，我們還利用第一個 token 來提高意圖識別的準確性。

3. 場景離線知識和實時知識

知識是智能體系的核心，主要包含兩個部分：其一為離線知識庫，涵蓋商品信息等百科知識以及外部知識的綜合；其二為實時場景化知識。由于諸多商品信息具有實時性，如價格波動和優惠變化等，因此部分信息需支持在線調用。同理，我們通過結構化的思維鏈（Format COT）來控制檢索增強生成（RAG）的過程，以提高準確性。輸出流程包括四個步驟：首先生成分析結果（Thought），其次得出結論（Conclusion），再進行校驗（Rethink），最后實施風格控制輸出。

4. Format-COT 的 RAG 生成控制

什么是 Format-COT 的 RAG 生成控制？從結構化角度而言，通常建議采用 XML 格式，因為 XML 具有較強的通用性，有利于模型的識別和處理。例如，在商品信息（offer info）中，需要找出支持問題（question）部分的相關信息，進行分析，然后按照指定的輸出格式（output format）來生成回答。

商品信息 RAG 召回的內容包括商品標題以及通過多模態處理得到的圖像到文本的離線數據。將這些信息整合后，首先進行初步分析（thought），然后得出結論（conclusion）。但是，結論不能直接輸出，還需要進行重新思考（rethink）。在提示詞（prompt）層面也可以控制幻覺現象，這里需要生成一些額外內容來進行控制，評估置信度的高低，最后再通過一些風格控制來形成最終輸出。

例如，在用戶詢問商品尺寸的場景下，結論部分不應直接輸出所有規格尺寸的描述給用戶，因為在表達規則（express rule）部分會有相應的約束。當尺碼類信息較多時，最好再添加一些風格和格式約束，以進一步控制其表達方式，確保輸出給用戶的信息簡潔明了。

5. 復雜需求描述 & 商品搜索

在探討如何實現 AI 原生聯動搜索時，不妨以一個具體場景為例：假設用戶需要尋找一件適合周末聚會穿著的連衣裙，且預算控制在 200 元以內。這類復雜需求在當前電商搜索系統中往往難以精準匹配理想商品。然而，借助大型語言模型（LLM）的能力，我們可以構建更智能的搜索流程。首先，LLM 會對用戶需求進行深入分析，識別出關鍵要素，如“周末連衣裙”或“晚宴連衣裙”等類別，并提取隱含的需求參數。隨后，模型將生成相應的商品 Query，用于進行初步召回。在得到相關商品列表后，系統會進行匹配過濾，剔除不符合要求的商品。最后，LLM 會對篩選后的結果進行整合，生成一體化的輸出。

（1）需求解析和語義商品召回

需求解析是指用戶提出需求后，如何調用相應工具的過程；而商品召回則是指根據給定的商品 Query 召回相關商品的過程。當一個需求到來時，大型語言模型會通過 COT 引導，生成潛在的搜索引擎習慣的商品 Query（通常電商搜索引擎對形容詞加名詞品類描述的查詢支持較好)。接下來是 RAG 的借鑒。由于不同搜索引擎支持的參數各異，需要根據配置文檔，讓模型借鑒知識，從需求中提取適當的參數。比如“200 元以下”的價格限制，以及默認的“包郵”等參數，隨后調用搜索工具。

在獲取大量商品后，需進行匹配和排序。我們使用 M3E 模型對商品信息和用戶需求進行向量化，這構成了基礎召回部分。如果缺乏資源或語料來訓練大規模垂直領域表征模型，可以先嘗試使用通用的 M3E 或 BGE 嵌入。在信息明確的情況下，這些通用語義表征的噪聲通常不會過大。然而，向量召回的語義漂移問題是需要關注的。例如，"婚禮連衣裙"可能被誤認為"時尚連衣裙"而被召回。因此，需要第二個模塊，即使用傳統的深度學習模型（e.g. RoBERTa）進行相關性打分。這類模型通過標題和相應的人工構造查詢進行訓練。目前，更重的 LLM 重排方案也可考慮，但需要根據系統和場景實際評估。

（2）ReACT 的搜索優化

下一階段是 ReACT 的搜索優化。需求解析后會產生多個查詢，其中一些長尾查詢難以召回商品，甚至可能出現空召回的情況。因此，需要根據這一反饋信號對查詢進行改寫，并進行二次嘗試。這個過程實質上是通過結果對輸入進行修正的逐步優化收斂，而這種鏈路的實現只有在大型語言模型的驅動下才成為可能。當然，最終還需要施加規則約束，以防止過多的嘗試次數。理論上，所有能夠提供反饋信號的工具調用都可以通過 ReACT 的過程來進行優化。然而，目前在效率方面仍然存在一些待解決的問題。就電子商務搜索而言，供給側本身也會參與鏈路的聯動優化。ReACT 或者說通過結果反饋來優化收斂的模式，可能會為我們打開更廣闊的想象空間。

6. 多模態商品信息分析

在電子商務領域，大量商品信息以圖片形式呈現。對于這部分信息的處理，主要有兩種邏輯：一種是在線構建圖文混合的多模態知識庫，然后進行多模態的檢索增強生成（RAG）；另一種是離線將信息統一處理成結構化的文本知識。我們在實踐中選擇了后者。前者存在幾個問題：首先，多模態大模型的推理能力尚不夠強；其次，這種方式會顯著增加系統鏈路的復雜度。本文將從一個視角闡述當前多模態大模型在推理方面的局限性。目前，主流的多模態架構分為兩類：圖文編碼分離和圖文編碼統一。使用第一種架構時，多模態的感知（視覺編碼）和多模態的推理（模態橋接到 LLM）在某種程度上是分離的，模態橋接后段并未能在預訓練中實現規模化（scaling），天然形成了推理效果瓶頸。對于第二種統一架構，以 GPT-4o 為代表，目前在多模態數據層面的規模法則（scaling law）似乎還不夠顯著，其在圖像理解和推理方面相比文本處理仍有不小差距。

因此，我們目前更傾向于信任多模態模型的感知能力。我們會將商品詳情圖中的文字信息提取出來，構建結構化的文本知識。純文本大模型在理解這些信息方面表現更為出色。在這個過程中，我們還會進行評測，判斷是否可能產生幻覺。最終，我們將所有信息整合成統一的文本商品知識，用于整體的商品信息分析或導購過程。從長遠來看，端到端的多模態 RAG 能處理更豐富的場景，信息損失程度也會更低，但這有賴于多模態大模型的進一步發展。

7. AI + 效果評測

所有上述工作完成后，還需對大模型的通用輸出進行評測。這部分任務無法像標準輸出任務那樣提供測試集，而外包標注從時間和成本角度考慮都相對較高，難以作為日常頻繁的評測環節。因此，自然而然地想到是否可以利用大模型來進行評測。運用大模型進行評測時，需要明確定義評測維度和目標等方面，以構造相應的提示引導。例如，針對賣點生成任務的評測，需要考察其準確性、賣點生成的邏輯性，以及最基本的不涉及色情暴力等風險問題。對于大模型生成的評測結果，可以通過人工抽樣分析，以驗證評測結果的正確性。我們還研究了通過微調小規模模型來對大模型生成的任務結果進行更低資源成本評測的可行性。從部分實驗數據來看，這種方法顯示出一定的效果。然而，在實際應用中存在較大局限性，因為無論是數據還是數據格式都與任務高耦合，這意味著難以實現通用化。

三、場景化導購案例

1. AI 智能找挑輔助

打開 1688 應用程序后，進入任意商品的詳情頁面，例如某款女裝連衣裙的詳情頁。當您詢問關于這些商品的采購建議、質量評估或賣點等問題時，系統會根據您的人群屬性（如都市女白領、程序員、全職媽媽等），給出針對性的回答，并為您總結最有價值的商品評價內容。

同時，在著裝搭配方面，如果您是女性用戶，想要購買一件適合晚間約會的連衣裙，系統可以為您提供穿搭建議以增添魅力。我們會通過夸克搜索引擎獲取相關信息，然后利用大型語言模型進行分析，確定最適合約會場合的風格。隨后，系統會為您推薦一套完整的穿搭方案，這背后是有專業知識支撐的，例如襯衫與高跟鞋或耳環的搭配。當您面臨兩件連衣裙的選擇困難時，系統可以提供商品對比功能。它會告訴您哪件更適合您，同時考慮性價比因素。如果您繼續詢問是否有同款推薦，系統會執行兩個步驟：首先從上下文中識別目標商品，然后通過圖像搜索找出相似款式。若您在推薦需求中表達了更多具體選擇信息，系統也會相應地進行精確篩選操作。

2. smart shopping

我們還嘗試了一個更加端到端的 AI + 電商搜索 demo，叫做 smart shopping，它能夠提供一種更加整體化的 AI + 找挑體驗路徑。例如，當您需要尋找春季流行服飾時，系統會主動訪問一個趨勢分析的服務來獲得相關數據，并緊接著生成一份采購建議。完成這一步驟后，系統開始調用平臺的商品搜索獲取候選商品并根據前面的需求、知識進行深度選品分析。最終會向用戶呈現一個包含三件商品的采購方案。方案中詳細說明了每件商品適合您的理由，這些理由是伴隨整個信息流程產生的，而非與搜索過程割裂。

3. 原生導購鏈路全域 tips

我們也嘗試在 APP 的更多地方，通過一些方式提醒用戶下一步要怎么做，比如用哪一張優惠券更劃算，夏天到了需要去采購一些什么東西，整個過程當中會有更強的引導。

四、未來 AI 導購的一些隨想

商品信息分發將向采購解決方案分發的方向演進。目前，電商平臺會為用戶推薦或搜索商品，這是非常淺層且零碎的信息化連接。我們期望能夠提供一個更完整的解決方案直面用戶。打個比方，就像一位值得信賴的主播在為用戶指引，用戶之所以買單，本質還是基于長期采購結果反饋而形成的信任機制。我們必然不可能真的成為主播或 mcn，但供應鏈和前場的定制化分析對接是能產品化的。

從被動式應答轉向主動式問題解決。被動式應答模式需要用戶逐步推動，例如用戶輸入特定衣物的需求及條件，系統隨后根據輸入提供檢索結果。未來，我們希望能夠主動幫助用戶收斂需求，從而提升整體購物體驗。

從“大家的 1688”蛻變為“你的 1688”。當前電商平臺的千人千面很大程度上仍停留在短期、淺層的偏好迎合，比如用戶購買了帽子后繼續推薦帽子。雖然某些采購場景可能樂見，但這顯然不是真正個性體驗。我們對未來的期望是，電商平臺能夠對每位用戶形成深入且長效的理解。例如，對于一位新晉寶媽，平臺應該圍繞其未來一年與嬰兒相關的采購需求提供定制服務。不單是垂直，而是往陪伴的邏輯上走，真正的長生成周期服務貼合。

最后歡迎大家下載 1688 的 APP，去體驗我們的 AI 采購助手。

五、Q&A

Q1：計劃式學習那里沒有 RAG?

A1：它是在用戶要買手機支架的前提下猜出來去問預算和品牌，如果要買一張椅子，它會去問材質和可能長寬高，基礎大模型本身蘊含的知識會讓他在 0-shot 的時候想到一些可能的商品-屬性關聯，當然微調指令中提及的關聯多少也會影響到。這個框架本身是可以配合 RAG 的，當開啟某類商品的采買，例如手機支架，第一步就是做一個知識庫的 function-call，從知識庫把手機支架采買需要引導詢問的關鍵屬性放進一個結構性上下文中。從這里也可以看出，這個模型起到的作用是一個 planning 的角色，在整個 Agent 系統中做好調度。在實際落地中，對 planning 的理解和推理都有很大的挑戰，尤其是復雜場景中，這個 bloom 1.5B 上的實驗只是說明了一種訓練的可行性，以及這種方式在特定垂直場景下能以低資源看到的一些效果邊界，實際情況中，需要根據場景作出調整。

Q2：商品召回的時候怎么判斷 query 和商品 match?

A2：用商品的標題匹配是不是 match，這個時候用 embedding 去做召回的時候，它會有漂移，就是有可能它不是一個時尚休閑連衣裙，而是一件婚禮連衣裙，它的 embedding 可能會很接近，這個時候需要有個監督模型在后面來判斷 true or false，即這個 query 和商品是不是匹配？這個模型是要訓練的，要構造一些 query 和 title 的關系對，生成的 query 和商品的 title 過濾掉那些閾值比較低的候選。但這套方案是建立在一個理想的假設上，就是商品的標題是反映真實信息的且描述了商品真實要點，這屬于供給側信息的問題，我們目前也遇到一些挑戰。

Q3：怎么保證整個鏈路準確？

A3：我們通過 COT 的邏輯，盡可能讓它先分析一下，生成對應的 advice， advice 里面本身會有一些上下文來保證生成商品詞是盡可能跟需求比較相關的，有了這個過程相對來說它的幻覺會弱一點，但是如果一定要解決，讓它生成的 query 絕對滿足用戶的描述，那指標是很難絕對被量化的，原因有些時候它的 query 是開放式的，只能通過后面鏈路去慢慢調整它，甚至多輪對話再去調整它。它本身整個就是 pipeline 的，不是端到端的，所以其實很難保證每個環節沒有噪音，每個地方的噪音都會累積下來。比如匹配模型不太準，把一些錯誤的商品放進來了，后面還會有大模型來做篩選哪些是適合的商品，它大概會幫你過濾出來。

Q4：AI 導購助手上線的時候有沒有業務指標評測，比如銷量或者轉化率？以及有沒有做過 AB test？

A4：我們現在大概整個灰度的用戶量就幾萬，其實很少，它現在沒有轉化價值，但是值不值得去做這件事情？從第一性原理去出發，它是解決用戶問題的，從產品邏輯上面來看，它確實是一種更好的體驗方向。所以我們現在不會嚴格去監測所謂的轉化率，因為轉化率太深了，大概率沒有那么優秀，肯定在首頁去優化 CTR 更好一些。我們會去監測 AI 助手用戶的使用輪次，用戶進來之后有沒有意愿長期地溝通下去？或者對于一些特定問題，用戶點贊、點踩，通過這種方式去分析用戶對產品的認同度。先不關注電商平臺的所謂轉化指標，而是先回歸到一個產品去看它的功能有效性、完整性和用戶的體驗反饋。