1688AI 助手“源宝”的产品演变之路

导读 本文将分享 1688 电商买家 AI 助手“源宝”从早期诞生到版本迭代的经历，希望为大家在成熟产品特别是 toC 产品里落地 AI 应用提供一些参考。

今天的介绍会围绕下面六点展开：

1. 为什么要做电商买家的 AI 助手？

2. 做什么样的 AI 采购助手？

3. MVP 版本： 模型能力约束下的应对

4. 2.0 版本： 转向数据驱动的 agent 设计

5. 未来畅想

6. 问答环节

分享嘉宾｜程亦曲 1688 AI产品专家

编辑整理｜马同学

内容校对｜李瑶

出品社区｜DataFun

---

01

为什么要做电商买家的 AI 助手？

1. AI 在电商行业的应用

1688 作为 B2B 电商平台，除了少部分个人消费者之外，大部分买家是各类型的 B 类买家，例如企业自采，淘宝卖家在 1688 进货，线下百货店、实体店进货等。AI 助手的核心目标是为这些 B 类买家提供帮助。

AI 在电商行业的应用起源非常早，应用场景也非常广泛，比如营销导购、智能客服，以及为商家和客户提供的各类工具。另一方面，从电商用户的角度来看，在日常使用电商 APP 时，并没有看到很多 AI 产品赋能场景，而实际上这个过程中大模型是可以起到作用。

2. 为 1688 买家带来哪些新可能

通过梳理买家使用流程，发现买家采购体验中有很多提升空间。典型问题有三个：

• 第一个是使用链条长，包括从需求产生、导购发现，到挑选决策、下单成交等诸多环节。

• 第二个是信息密度高，由于链路长，在这个过程中各类型的信息分布在平台里不同页面以及页面中的不同楼层，要求买家对整个产品有一定的熟悉程度。

• 第三个也是最大的问题，B 类买家区别于 C 类消费者，对决策的客观性、准确率等要求更高，会非常精细地在多个商品之间去进行对比，从而找到他最满足他的需求的商品。对于不同买家，由于购买目的不同，也会导致决策差异性。

这些问题导致采购整体效率比较低，时间成本比较高。

大模型的优势在于对各类型非结构化数据的理解，并做到辅助决策。

从买家需求角度，有了大模型之后，无需完全依赖洞察买家间接行为数据，例如浏览和加购等行为去猜测买家需求，而是可以建立沟通渠道，让买家通过语音或者文本的方式充分表达出需求，这样获得的需求一定是最完整、最精确，颗粒度也是非常细的。从供给角度，除了消费整个电商平台目前已有的结构化数据之外，AI也能够理解非结构化的数据，例如店铺介绍、买家原始评价，并且结合多模态能力，大模型能够理解商品详情图、甚至是商品讲解视频内容。基于大模型对需求和供给双方更好的理解，可以打破原先平台被动服务，用户主动浏览和操作的方式，转为将部分判断过程节点交由 AI 完成，AI 可以像用户的贴身采购助理一样，在各个过程中，做回答、做判断，并提供建议。

基于以上分析，我们将 1688 AI 采购助手的目标为，站在买家的视角，围绕着买家的需求出发，在目前的用户使用链路上帮助用户进行信息的获取和处理，最终提升用户在单节点上的采购效率。

02

做什么样的 AI 采购助手？

1. 功能切入点

在实际落地时，我们面对的第一个问题是功能切入点的选择。

从需求角度，我们首先分析了用户主要的动线，例如首页搜索、商品详情页、购物车等，这些是目前电商用户进入到 APP 后最常用到的场景。其次，和用研团队一起合作，调研了现有动线上用户主要将时间花在哪些任务上。我们很快锚定，用户痛点在于他们找不到自己想要的商品，以及确定了目标商品之后想要了解商品详情，想要多对比多款商品，以及想要去计算实际到手价，精确计算对比哪个商品更符合其要求。

从技术角度，我们进一步结合大模型擅长的总结、分类、润色创作等能力。基于用户需求范围和大模型的能力，最终保留了部分功能点，既满足可行性较高，又对用户比较重要。

最终，我们决定优先从购物车和商品详情页这两个后置场景去切入，为用户提供例如回答商品的详情问题，总结买家评价和对比多款商品并选出最优品等能力。

2. 交互切入

在成熟的产品中落地 AI，常用的交互方式有三种：

• 第一种是单点嵌入模式。通过单点的功能直接嵌入到对应的页面中，这种方式的好处是对用户的动线侵入非常弱，用户非常容易用起来，但缺点是用户其实并不能感知该功能是 AI 助手。所以对于我们想做陪伴式个人采购助理这一目标而言，并不是最好的切入方式。

• 第二种是独立对话页。这种方式也比较常见，其优势在于冷启成本非常低，只要在现有页面中加一个功能入口即可。同时因为唤起的是一个独立 AI 对话页，页面内迭代空间非常大，AI 功能和原有场景功能可以解耦开。但它的最大问题在于对用户动线会有比较明显的打断，同时早期因为用户并不知道 AI 能够提供哪些能力，所以需要配合用户教育例如运营手段让用户能够用起来，长期培养认知。

• 第三种是 agent 指令。例如钉钉里面，用户输入斜杠，可以立即告知大模型，想要它完成什么任务。这个方式最大的好处在于，平衡了前面两种交互方式的优缺点，它同时具备弱侵入和功能灵活性大的优点。这种方式中期来看是比较理想的，但短期确实对成熟产品来说改造成本会比较高。

所以经过综合对比，我们选择了第二种独立对话页，由于整个项目立项是偏探索性质，所以以独立对话页的方式切入，成本低，同时对现有用户体验不会有太大的影响。

目前，AI 助手定位已确定，以 agent 为核心，通过多轮交互对话方式为用户提供不同的 agent 能力。最顶层是意图识别 agent，下面会有各个场景的不同单点 agent，例如商品对比、评价总结等。往下是 agent 构建所需要的底层技术能力，比如大模型、多模态、RAG 以及站内已有工具。另外，大模型依赖于数据质量，所以站内外数据库建设也是至关重要的。Agent 之上是产品层，包括商品详情页、采购车等用户动线核心场景，并通过入口浮球、Tips 引导等方式吸引用户使用。

具体来说，当用户进入 AI 助手页面后，输入 query，然后通过意图路由 agent 找到最能满足用户需求的 agent，再由对应 agent 进行回答，并最终输出给用户。Agent 效果实现依赖于工具库和知识库的能力，包括覆盖度和质量。

03

MVP 版本：模型能力约束下的应对

1. 模型能力约束

回顾最初的 MVP 版本，当时最大问题是模型能力不足。对照项目立项时间和通义模型版本发布时间（见下图），可以看到项目立项时，模型选择比较有限。Qwen 模型可选版本是 7B 和 14B。基于产品定位，我们所运用到的大模型能力主要还是总结、润色等通用认知能力，并不需要很强的外部行业知识，因为这些知识可以通过 RAG 等其他方式灌给用户。所以这种情况下我们也没有选择去微调，而是直接使用了 Qwen 小版本模型进行开发。

但在产品设计和技术方案实施的过程中，我们发现当时版本模型的通用能力并不足够，它会带来一系列基础能力下限问题。以商品对比 Agent 为例，会存在内容重复、逻辑错误、前后矛盾、输出格式不稳定等问题。

2. 应对方法

发现问题后，我们尝试了 prompt engineering 工作，但其实在小版本模型上收效并不是很好。由于没有更大尺寸的模型可以使用，我们调整了策略。我们没有使用微调，而是使用了将核心决策分析过程规则化，用代码的方式去实现，然后把实现出来的结果一起放入到 prompt 里面，让模型在最后只做总结和润色。

比如商品对比功能，如下图中间部分所示，会具体帮助大模型对比回头率、发货速度以及商家星级等维度，然后将结果以文本的方式拼到 prompt 里面去，最终实现的效果如图中右侧所示，模型能够给出自然语言结论以及对应的解释。

至于为什么不去做微调，其实有两个原因，第一个原因是即使做了 SFT 和对齐之后，效果仍然不稳定，没有办法彻底解决问题，只是把较大概率事件变成了更小概率，但依然是一个产品中不能接受的，这个结果并不能达到上线的标准。第二个原因是我们评估未来整个 AI 助手会向 agent 数量越来越多的方向去迭代，如果每个 agent 都要单独训练小模型，无论是资源成本还是迭代灵活度都是不可以接受的。所以 MVP 1.0 版本，我们接受了部分代码逻辑化，大模型只做总结润色方式去进行迭代。

第一版效果如下，在一个对话框中，用户选择两个想要对比的商品，然后发起对比，模型会给出最终的结果，推荐其中一款商品。买家评价总结 agent，会拉取买家的原始评价，分维度进行分析。在这一版本中，回答本身是没有错的，但是经过小范围灰度和内测，大家反馈其对实际提升采购决策并没有很大价值，因为输出内容是显而易见的，并且 AI 回答呆板不够灵活，因此并不能很好地帮助用户进行决策。

04

2.0 版本：转向数据驱动的 AI 产品设计

1. 数据驱动提升质量上限

1.0 版本中，已经把整体产品和技术框架都搭起来了，我们已经知道 AI 助手长期要往哪个方向走，但短期 1.0 上线 agent 效果并不好，下一步面临的问题是如何提升上限。

当时，恰逢 Qwen 发布了 1.5 版本 72B 模型，它在各类 Benchmark 上，包括聊天机器人、多轮会话上都有非常好的表现，基本上与 GPT3.5 平齐。

于是我们很快进行了尝试，不对现有 agent 做任何改动，甚至 prompt 也没有调，只是单纯地将其切换到了更大尺寸的 72B 模型上去，观测效果。效果是很好的，基础的能力问题都得到了非常明显的解决。接下来 2.0 阶段最重要的目标就是如何提升 agent 回答质量的上限。

下一步的工作要围绕数据展开。当模型的基础分析和决策能力已经够的时候，回答质量主要取决于是否给模型足够的信息，是否把大模型不理解的业务概念解释好，是否能够为大模型提供更多电商行业的信息和用户的偏好，从而让大模型能够知道该从哪个角度去回答问题，进而更加符合用户的预期。

我们围绕着数据去展开，需要考虑以下四个方面：

• 第一是数据丰富度。可以设想如果用人工的方式去完成这个 agent，那么会需要哪些数据源？数据源是否已有，还是需要通过数据挖掘的方式建设起来。如果是通过数据挖掘方式建设，这种方式是否可以规模化，能够持续满足 agent 需求。

• 第二是数据质量，包括数据覆盖度、完整性、准确性、时效性。例如当我们想要给用户提供比较价格功能时，价格信息是否准确，商品详情页和搜索结果页展示信息完全一致是至关重要的。

• 第三是数据使用，数据什么情况下要通过 TOOLS 方式接入，什么情况下通过 RAG 去使用。此外，目前的业务系统中的很多数据，其存储方式不是为了大模型的使用设计的，所以获取到数据后给到大模型之前，要考虑是否进行过滤和后处理。过滤是指去除冗余信息，不用给到大模型。后处理是指一些专有名词，可以转化成自然语言表达。这些细节都会影响到最后输出内容的质量。

• 第四是数据验证。我们要真实地搭建一个 agent，然后离线地去测试，分析最终回答质量是否符合预期。如果不符合，是哪个层面的问题，是否有对应的解法。

2. 数据驱动的产品设计流程

回到整个 agent 产品设计，经过大半年实践，我们认为对于 AI agent 产品经理，典型的产品设计流程如下图所示。其中黑色框是传统产品经理也在做的事情，红色框是 AI 产品经理在产品设计过程中特别需要注意的事情。

理想效果定义，是指当明确用户需求后，除了要做高保真原型之外，还要做高保真还原内容，因为高保真还原内容会指导下一步的所有工作。例如如果内容里面分了三个字段，每个字段展示长度是不一样的，比如 A 字段希望 5 个字，然后 B 字段希望 15 个字，后续所有的可行性评估、数据验证都会围绕着你的理想效果去展开。所以在理想效果定义阶段，越细越好，越还原越好。

可行性验证，要对如下关键要素进行判断。首先，模型能力是否足够，其实也在考验产品经理对大模型的技术能力边界了解到什么程度。第二是数据层面，关键数据是什么，以及对应的数据质量是否符合。第三是 agent 是否涉及到与现有的系统进行打通，它是否依赖 tools 或执行 action，需要现有系统 API 能力。

确定 AI 可行后，下一步就是非常关键的数据验证环节。这里会涉及到 prompt engineering 的工作，包括 COT、few-shot 等，能够显著提升输出质量的小技巧。我们搭建了 1688 内部 AI 研发平台，作为 agent builder 工具。因为整个数据验证的过程中，我们可能会反复地尝试多种不同的 pipeline，pipeline 的搭建过程如果没有好的 agent builder 支持，效率非常低的。所以基础设施的建设确实对 AI 时代的产品设计效率有很大影响。此外，在这个环节我们要去多去关注批量化结果，而不是 goodcase，因为在任何一个 AI 应用，包括 chatbot 者 agent 产品，实际的生产环境中，对用户体验更重要的是批量化结果，甚至是 badcase，所以以 badcase 去驱动迭代方案是一个更佳的方式。

如果上述环节都顺利完成，数据验证通过，才会走到后续的技术开发的过程。

3. 上线后四个 Agent 的 Case

下面通过四个 case 来展示上线后的效果。

第一个是商品对比。在 2.0 版本中，引入了更多的数据，同时把对比的权利由规则定义交给了大模型自主的决策。另外，在这个版本里面，也从原来纯文本的回答呈现改成了结合 GUI，降低了用户阅读门槛。从结果来看，大模型回答的智能感和灵活度提升较大，agent 的用户点赞率也从 30%-40%，提升到 80% 左右。

第二个 case 是商品建议 agent，目标是当用户在浏览商品的时候，快速帮用户总结商品卖点，而不是让用户去商品详情页中自己去浏览。在 2.0 版本中，通过商品知识库的构建，引入了完善的近 20 个商品指标。同时在用户需求图谱中，引入了用户人群、年龄等信息，从而能够实现个性化建议。

第三个 case 是商品详情咨询 agent，是一个典型的从用户需求洞察出发，最后推导到数据层面，需要去自建数据等数据工程的工作。在 1.0 版本上线后，我们发现用户浏览商品的时候，经常会询问商品属性、规格等细节，对于非标类商品用户会要求 AI 助手推荐尺码，但第一版本无法做到，因为可用数据只有商详图的传统 OCR 数据，这个数据对模型无法理解，所以没有办法基于数据给出推荐。后续算法自研了一个从商详图中解析出来结构化文本，能够将商详图完整解析成为 Markdown 文本，然后把这个文本通过 RAG 方式给到模型，最终做到可以基于用户提供的数据，比如身高和体重，然后结合尺码表的信息给出合理的尺码推荐。最终效果提升显著，上线后，agent 满意度有明显提升，提升了 20 个 PT。

最后一个是针对 B 买的商机追爆 agent。由于 B 类买家经常希望了解市场上有哪些爆品正在热卖，然后快速进货，追赶潮流，获取利润。针对这一场景，没有 AI 助手的时候，用户进入榜单页面后要自己去选择，筛选价格段、类目、榜单类型，然后进行浏览。但是，很多用户并不知道榜单页面，而且榜单页面交互方式需要填写表单，用户操作成本较高。引入榜单数据源后，通过 AI 方式，识别用户追爆意图，并路由到相应 agent，然后在相应 agent 内，智能识别用户需要类目、榜单类型，并最终召回给到用户。此外，还会结合爆品信息做关键词的提取、功能价格分析、爆品趋势总结等功能，为 B 买提供建议。

05

未来畅想

在 AI 产品能力应用和落地过程中，我们有如下一些感受。

首先，当我们所使用的模型能力已经达到一个比较好的水平的情况下，最终效果壁垒取决于数据质量，较高的数据质量才能为上层产品设计奠定扎实的基础。

第二个感受是，对话交互并不是用户产品落地的终局形态，因为对于普通用户来说，特别是电商用户，让用户去提出一个好问题，并且需要输入或打字，这样的方式对用户而言难度还是太大了。电商最终解决的还是供需匹配的问题，单点上的提升确实有其价值，但并不是本质所在，更本质的应该是做到端到端的应用，即用户将需求描述清楚，系统一步到位给出最满意的商品。

最后分享一个彩蛋，1688AI 深度找功能近期正在小范围内测中。该功能能够基于需求，首先帮用户找到最匹配的若干款商品，然后会给出结构化的可解释的推荐理由。基于此可以看到，我们现在正在做的方向，是从原先在已有动线上的单点提效向更新的用户动线去发展，使用户使用链路更短，使用门槛更低，找的更精准，更符合各种 B 类买家的长尾需求。并且通过清晰的结果呈现，帮助用户更快更好地了解所需信息。（产品链接：aizhao.1688.com。注：当前仅 PC 端可试用）

最后，欢迎大家下载 1688APP，体验 AI 助手“源宝”。

06

问答环节

Q1 ：彩蛋中的功能为什么更适合 B 类买家，而不是一般买家？

A1：作为 C 类消费者，在找商品时候，需求不会非常精准。但是 B 类买家会带着明确的商机和目标，同时也愿意为了获得更好匹配效果付出更多努力。因此深度找对 B 类买家更具价值。

Q2 ：大模型不了解行业概念是如何解决的？

A2：我们主要通过 RAG 数据维度去解决，比如如果数据来源于站内，我们在给大模型前会做解释。另外，也引入了例如夸克引擎等外部知识库，通过公开网页信息给出更多参考信息，帮助大模型了解行业概念。

以上就是本次分享的内容，谢谢大家。