隨著 AI 應用在商業領域的滲透及普及，電商 B 端商家經營及商家運營場景也進入了百花齊放的階段，帶來了前所未有的變化與機遇。
在 InfoQ 舉辦的 AICon 全球人工智能與開發大會上快手電商運營平臺 / 研發負責人袁首超為我們帶來了精彩專題演講“大模型在電商 B 端的應用實踐”，分享將從快手電商 B 端實際業務場景出發，結合真實線上應用案例 (規模化運營、運營提效等)，講述大模型在快手電商 B 端應用的技術方案，如何通過技術架構建設，實現大模型應用的快速交付并兼顧各場景差異化的訴求；并通過體系化技術建設，實現大模型從模型到應用層面的準確度提升；其次也會從實際生產出發，分享針對大模型應用場景差異化的穩定性保障手段能力。最后結合業務應用情況，分享未來電商技術大模型應用技術的未來發展方向及展望。
內容亮點：
了解快手電商 B 端在大模型應用上的實踐經驗
了解大模型應用前沿技術及案例
了解前沿技術如何與業務結合的實踐及思考
以下是演講實錄（經 InfoQ 進行不改變原意的編輯整理）。
B 端大模型應用建設背景
在電商領域，從角色和核心領域相互關系來看，除了日常接觸較多的消費者，電商的絕大部分參與角色都在 B 端，像在平臺賣貨賺錢的商家、達人，還有類似公司機構的服務商、MCN 機構、ISV 等。從平臺視角，運營角色也很多，除了常見的產運、用戶運營，電商行業還有商家運營，直播電商場景下還有達人運營。這些眾多角色相互合作、聯系，結合一些領域共同構成了復雜的電商生態。
從 B 端視角來看，商家從入駐開始，到賣貨、發品、交易、履約，再到最后結算、清退，整個過程中要處理大量流程，涉及眾多領域，還會與達人、服務商、MCN 等產生合作與聯系。我們統計發現，B 端給商家的 PC 端工作臺頁面大概有 200 多個，商家若想經營得好，至少要了解一兩百個產品功能。尤其在直播電商場景下，新引入的內容場域是主要交易載體，內容生產給商家的經營成本和經營門檻帶來了較大挑戰。
從運營端來看，電商大促是主要業務流程，每次大促 基本全員參與，且涉及較多外部協作，如與商業化、主站體驗等協作，同時還會用到眾多產品功能，包括協作團隊的產品功能。 現在電商環境競爭激烈，大促日常化，運營同學或小二工作狀態繁瑣，除了大促還要處理其他專項或業務流程。
直播電商 B 端的業務場景挑戰如下：
場景多樣性 ：平臺內包含商家、團長、達人共計 10 余種角色，形成上百種業務組合，涉及到的業務環境也越來越多。
業務復雜度高 ：平臺內商家、達人、場景落地復雜的商業模式，每個場景都環環相扣，單一解決方案難以應對。
內容創作要求高 ：與傳統貨架電商相比，內容生產對商家經營的重要性越來越高，整體成本投入也越來越大。
運營復雜度高 ：除了基本的客情維護、商品、履約之外，還需要掌握比較多的運營診斷、政策動向等，以便更好地吸引商家。
B 端大模型的技術實踐
電商大模型基座建設
在重構電商 B 端的過程中，我們的主要思路集中在三個方面：通用性、效率和可靠性。
通用性是我們建設大模型能力的核心，我們希望這個能力能夠適配電商 B 端的各個業務場景，并解決相應的問題。從行業角度來看，大約從 2020 年開始，大模型進入了快速發展階段，無論是國外的 OpenAI、谷歌、Meta，還是國內的阿里、百度、字節等公司，都在積極發展。國內生成式大模型的數量已經達到了 1900 多個。
然而，通用大模型在解決行業專業問題時，由于領域知識的局限性，往往難以很好地解決一些相對專業的問題。因此，各行各業開始建設自己的大模型，如醫療、汽車、金融等，電商 B 端的大模型也是按照這個思路建設的垂直大模型。
在建設大模型時，我們會遇到一些電商特有的典型問題。以商品為例，我們面臨兩個相對典型的問題。第一個是關于商品理解的問題，我們需要對商品有深入的理解，并生成相應的標簽，這些標簽將用于各種場域的分發、推薦或商達撮合過程中。然而，傳統小模型存在局限性，只能生成預設的標簽，無法挖掘出更細粒度的信息。
通用大模型雖然能挖掘更多信息，但生成的內容相對隨意，可能不適用于推薦或分發場域。我們更期望的是能夠識別出商品的具體屬性和適用場景，如法式女帽適合夏天海邊出游，以便在用戶搜索時直接推薦。第二個挑戰是商品文案的生成。
在內容場域，除了商詳頁的文案外，我們還需要生成大量的臺本，即主播在直播間介紹商品時的稿子。我們希望生成的文案自然流暢，能夠讓主播直接在直播間使用。傳統小模型可能只能進行圖像識別和文案提取，生成的內容生硬且無法使用。通用大模型雖然能生成流暢的文案，但可能會出現嚴重的事實錯誤，這在直播電商中可能導致虛假宣傳問題，甚至可能導致封號。
針對商品理解和電商創作事實性問題，我們采取了相應的應對措施。對于提高商品理解能力的問題，我們引入了生成和理解聯合建模的大模型訓練方法。在訓練過程中，我們不僅保留了大模型的開放性生成能力，還結合了多種多維的電商理解任務進行聯合建模。
這樣，大模型在進行商品理解時，能夠明確從哪些維度去分析商品，例如風格、同類目、同品牌等。對于電商創作中的事實性問題，我們主要采用了基于課程學習的多粒度知識注入范式。通過這種方法，大模型能夠學習從簡單到復雜的多層級電商領域知識。
在這個過程中，我們積累了超過 1 億的基礎數據，并在進行推斷理解時，結合了超過 1000 萬的知識圖譜來確保生成內容的準確性和可靠性。
電商 B 端大模型基座建設由四個層次構成，最上層的應用層直接面向用戶，提供具體的 AI 應用解決方案，包括電商商品理解、電商創作工具和電商對話助手。
這些解決方案利用大模型的能力，旨在提升電商業務的效率和效果。在應用層之下是能力層，它提供細粒度理解、可控生成和智能體交互等多方向的大模型能力，為應用層提供支持。
再往下是方案層，它基于電商 B 端的業務場景沉淀了通用的解決方案，如數據解決方案、算法解決方案和評估解決方案。最底層是架構層，負責高性能大模型基礎建設，包括訓練、推理、評估等環節，以及 ROCE 多軌網絡、混合并行、計算優化等技術。這四個層次相互協作，共同構建了一個全面、高效、可靠的技術支持體系，以滿足電商 B 端的業務需求。
大模型工程體系建設
開發引擎
在大模型工程體系建設方面，我們面臨的挑戰是如何將算法有效地應用于實際業務中，開發出供用戶使用的產品功能。我們的場景非常多樣，多達 20 多個，我們從中篩選出了 P0 階段的業務場景。
然而，我們的工程開發團隊在大模型開發方面缺乏經驗，從熟悉到搭建一個簡單的大模型應用可能需要十幾天，這對于我們眾多的場景來說是不可接受的。因此，構建一個高效且低成本的技術體系來支撐業務場景是我們的首要任務。
我們的技術體系建設思路與行業大致相同，從基礎的大模型能力開始，如提示詞、工具調用，最終形成一個垂直領域的 Agent 來解決復雜場景。我們通過垂直領域的 Agent 組合來解決一些非常復雜的業務場景。
我們的基礎能力建設，即工具鏈部分，包括開發框架的建設，我們將其定位為大模型領域的 Spring 框架。我們希望通過它降低普通工程研發的開發門檻，使他們只需編寫幾行代碼或進行配置化操作，就能實現大模型應用。除了集成基礎能力，我們還從三個維度進行建設：擴展性、易接入和協作模式。
在擴展性方面，我們保留了很好的擴展性來支撐各種差異化場景的定制，提供了 9 種擴展點，每種擴展點內置一到兩個默認方案，共有 20 多個默認方案，如知識庫、繪畫等，都是可配置的，用戶可以基于這些實現自己的擴展。
在易接入方面，我們建設了一個領域能力市場，與公司的服務發現能力打通，只需簡單配置即可注冊到領域能力市場，并直接被引擎使用。
在協作模式方面，由于涉及眾多業務場景和研發團隊，我們采用開源方式推進，建立了一個 git 倉庫，任何人都可以使用這個倉庫，實現自己的擴展，并將迭代增量建設的能力貢獻回代碼倉庫，實現能力的升級。這種模式不僅在電商 B 端有用，也影響了電商事業部之外的團隊，如本地和商業化團隊。
Agent 平臺
在大模型工程體系建設中，我們不僅開發了框架，還進一步推出了 Agent 平臺，以實現更高效的應用交付。我們的 Agent 平臺名為“千機”，其定位是實現無代碼配置化交付大模型應用。
千機平臺主要針對三類場景：一是典型的通用場景，如會話助手，用戶無需自行開發，通過配置即可使用；二是小流量場景，這些場景不需要單獨的服務，可以通過配置化快速部署；三是快速驗證和試點場景，用戶可以配置化嘗試，以評估效果。我們希望將大模型交付從研發擴展到產運，使產運人員能夠自行配置和迭代大模型應用。千機平臺的主要增量建設包括租戶隔離、模型切換和實時反饋等運營向能力。
RAG
在建設工程體系框架的過程中，我們也遇到了一些典型問題，如 RAG。RAG 是所有大模型應用都無法避免的挑戰，我們在智能助手中深度使用 RAG，并通過離線和在線兩套流程進行優化。
離線流程中，我們優化了 Embedding 算法，并構建了向量索引和倒排索引，同時定期將知識庫和聊天記錄輸入大模型進行微調。在線流程中，除了傳統的 Query 改寫，我們還使用了多路召回能力，進行精準匹配、模糊匹配和向量匹配，最終進行重排，將知識交給大模型進行文案優化輸出。
以智能客服場景為例，通過這套體系，我們的準確率提升了大約 17%。如果將這一提升折算成商家經營成本，我們每天可以為商家降低幾十萬到一百萬左右的經營成本。