摘要：在 InfoQ 举办的 AICon 全球人工智能与开发大会上快手电商运营平台 / 研发负责人袁首超为我们带来了精彩专题演讲“大模型在电商 B 端的应用实践”，分享将从快手电商 B 端实际业务场景出发，结合真实线上应用案例 (规模化运营、运营提效等)，讲述大模型

随着 AI 应用在商业领域的渗透及普及，电商 B 端商家经营及商家运营场景也进入了百花齐放的阶段，带来了前所未有的变化与机遇。

在 InfoQ 举办的 AICon 全球人工智能与开发大会上快手电商运营平台 / 研发负责人袁首超为我们带来了精彩专题演讲“大模型在电商 B 端的应用实践”，分享将从快手电商 B 端实际业务场景出发，结合真实线上应用案例 (规模化运营、运营提效等)，讲述大模型在快手电商 B 端应用的技术方案，如何通过技术架构建设，实现大模型应用的快速交付并兼顾各场景差异化的诉求；并通过体系化技术建设，实现大模型从模型到应用层面的准确度提升；其次也会从实际生产出发，分享针对大模型应用场景差异化的稳定性保障手段能力。最后结合业务应用情况，分享未来电商技术大模型应用技术的未来发展方向及展望。

内容亮点：

了解快手电商 B 端在大模型应用上的实践经验

了解大模型应用前沿技术及案例

了解前沿技术如何与业务结合的实践及思考

以下是演讲实录（经 InfoQ 进行不改变原意的编辑整理）。

在电商领域，从角色和核心领域相互关系来看，除了日常接触较多的消费者，电商的绝大部分参与角色都在 B 端，像在平台卖货赚钱的商家、达人，还有类似公司机构的服务商、MCN 机构、ISV 等。从平台视角，运营角色也很多，除了常见的产运、用户运营，电商行业还有商家运营，直播电商场景下还有达人运营。这些众多角色相互合作、联系，结合一些领域共同构成了复杂的电商生态。

从 B 端视角来看，商家从入驻开始，到卖货、发品、交易、履约，再到最后结算、清退，整个过程中要处理大量流程，涉及众多领域，还会与达人、服务商、MCN 等产生合作与联系。我们统计发现，B 端给商家的 PC 端工作台页面大概有 200 多个，商家若想经营得好，至少要了解一两百个产品功能。尤其在直播电商场景下，新引入的内容场域是主要交易载体，内容生产给商家的经营成本和经营门槛带来了较大挑战。

从运营端来看，电商大促是主要业务流程，每次大促 基本全员参与，且涉及较多外部协作，如与商业化、主站体验等协作，同时还会用到众多产品功能，包括协作团队的产品功能。 现在电商环境竞争激烈，大促日常化，运营同学或小二工作状态繁琐，除了大促还要处理其他专项或业务流程。

直播电商 B 端的业务场景挑战如下：

场景多样性 ：平台内包含商家、团长、达人共计 10 余种角色，形成上百种业务组合，涉及到的业务环境也越来越多。

业务复杂度高 ：平台内商家、达人、场景落地复杂的商业模式，每个场景都环环相扣，单一解决方案难以应对。

内容创作要求高 ：与传统货架电商相比，内容生产对商家经营的重要性越来越高，整体成本投入也越来越大。

运营复杂度高 ：除了基本的客情维护、商品、履约之外，还需要掌握比较多的运营诊断、政策动向等，以便更好地吸引商家。

在重构电商 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 平台名为“千机”，其定位是实现无代码配置化交付大模型应用。

千机平台主要针对三类场景：一是典型的通用场景，如会话助手，用户无需自行开发，通过配置即可使用；二是小流量场景，这些场景不需要单独的服务，可以通过配置化快速部署；三是快速验证和试点场景，用户可以配置化尝试，以评估效果。我们希望将大模型交付从研发扩展到产运，使产运人员能够自行配置和迭代大模型应用。千机平台的主要增量建设包括租户隔离、模型切换和实时反馈等运营向能力。

在建设工程体系框架的过程中，我们也遇到了一些典型问题，如 RAG。RAG 是所有大模型应用都无法避免的挑战，我们在智能助手中深度使用 RAG，并通过离线和在线两套流程进行优化。

离线流程中，我们优化了 Embedding 算法，并构建了向量索引和倒排索引，同时定期将知识库和聊天记录输入大模型进行微调。在线流程中，除了传统的 Query 改写，我们还使用了多路召回能力，进行精准匹配、模糊匹配和向量匹配，最终进行重排，将知识交给大模型进行文案优化输出。

以智能客服场景为例，通过这套体系，我们的准确率提升了大约 17%。如果将这一提升折算成商家经营成本，我们每天可以为商家降低几十万到一百万左右的经营成本。

我们面临电商复杂业务场景的挑战，这些场景涉及众多业务领域，如售前、售中、售后以及政策咨询等。单一的 Agent 难以应对多样化的需求，而增加 Agent 数量又会导致资源消耗和响应时长增加，影响成本和用户体验。

因此，我们采用了多 Agent 合作的多轮会话解决方案，沉淀了多个垂直领域的 Agent 集合，并建立了一个路由层来识别用户意图，将请求分配给相应的 Agent 处理，以提高回复的准确率和可靠性。

在大模型工程体系建设完成后，我们面临的下一个重要任务是验证大模型应用的可用性和可靠性。为此，我们构建了一个评测平台。这个平台对于 B 端业务场景尤为重要，因为 B 端对内容的准确性和合规性有严格的要求。

例如，在商品文案生成中，任何事实性错误或违规词汇都可能对商家造成严重影响，如违反广告法可能导致店铺被关闭或封号。此外，如果大模型给出的建议导致商家亏损，商家可能会要求赔偿。因此，我们的评估必须符合风控逻辑，确保可靠性。

上线后，我们面临的另一个挑战是如何赢得用户对大模型应用的信任。我们建立了一个三层评估体系，包括规则评估、大模型二次评估和人工评估，以确保交付的大模型应用是可靠的。

在知识质检方面，我们首先进行简单的规则校验，如错别字和领域知识纠错，然后由大模型判断知识的可用性、伦理合规性以及对用户的帮助程度，最后由审核团队进行标注，输出知识评估。为了解决上线后的信任问题，我们正在探索如何将用户对大模型的应用数据量化，以建立信任。

我们希望将用户的反馈和客观指标（如 ROI、转化率）结合起来，形成一个可量化的数字，使用户相信大模型应用的可靠性。例如，滴滴司机的评分系统就是基于用户评价和司机表现得出的分数，用户看到这样的分数后，会认为它是可靠的。我们也希望在大模型产品上实现类似的量化信任。

通过这些建设，我们完成了评测体系的建设。在上线前，我们利用三层评估能力对交付结果进行评估，并建立链路归因分析，以确定哪些改动影响了大模型的效果。上线后，我们收集产品功能数据和用户反馈，将其作为基础因子交给产运团队，以便他们进行整体评估和迭代，并将这些因子量化，转化为白盒化的产品，以提高用户信任和产品优化。

通过上述建设，我们已经完成了整个大模型技术体系的构建。体系的最底层依托于快手的基础设施，建立了电商大模型基座。在此基础上，我们通过智林引擎和千机平台来支持业务场景的具体落地实施。智林引擎作为一个开发框架，旨在降低工程研发的门槛，使得开发人员能够通过简单的代码编写或配置化操作来实现大模型应用。

千机平台则进一步简化了这一过程，它允许用户通过无代码配置化的方式直接交付大模型应用，从而覆盖了如会话助手、小流量场景和快速验证试点等多样化的业务需求最后，我们通过鸿儒平台，也就是我们所说的评测平台，对整体效果进行监控和迭代优化。鸿儒平台的建设是为了确保大模型应用的可靠性和合规性，它通过规则评估、大模型二次评估和人工评估三层评估体系来保障交付应用的质量。

我们在三个主要方向上进行了工作：首先是理解领域，包括商品理解和内容理解等；其次是创作领域，涵盖台本创作和内容生产等场景；最后是绘画领域，即各种助手类应用，到目前为止已经累计交付了十几个场景。这样的技术体系不仅提高了开发效率，还确保了应用的可靠性和用户的信任度，为电商 B 端提供了强有力的技术支持。

我们分享一个故事，其中一位内容创作者担心 AI 会取代他的工作。对此，有人建议他不应将 AI 视为敌人，而应将其视为朋友，利用 AI 来帮助自己创作出更好的作品。这个故事同样适用于我们的业务。我们期望 AI 能够成为我们用户的伙伴，助力升级电商服务和生态。我们希望 AI 能够成为消费者的贴心朋友，帮助他们更高效地购买到满意的商品。同时，我们也希望 AI 能够成为商家和达人的助手，帮助他们降低经营成本，增加销售量。

来源：商财洞察君