一、场景化导购背景
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 助手用户的使用轮次，用户进来之后有没有意愿长期地沟通下去？或者对于一些特定问题，用户点赞、点踩，通过这种方式去分析用户对产品的认同度。先不关注电商平台的所谓转化指标，而是先回归到一个产品去看它的功能有效性、完整性和用户的体验反馈。
