AI Agent实战：打造京东广告主的超级助手 | 京东零售技术实践

前言

自 2022 年末 ChatGPT 的问世，大语言模型（LLM）技术引发全球关注。在大模型技术落地的最佳实践中，智能体（Agent）架构显现出巨大潜力，成为业界的普遍共识，各大公司也纷纷启动 Agent 技术验证项目。

基于此背景，我们在 23 年下半年对 Agent 的应用进行了一些探索，并打造了京东广告投放 Agent 应用---京准通智能助手。过去一年，京准通智能助手历经多个版本迭代，已经具备智能客服、数据查询、广告创编等 AI 能力，逐渐成为广告主的超级助手。这背后，依托于我们构建的 AI 工程化技术体系。本文将详细介绍京准通智能助手的构建过程，并系统化阐述 AI 工程能力建设中的关键技术实践与创新方法论。

一、Agent 在京东广告投放中的落地

1、Agent 在京东广告投放中的应用场景

经过前期我们对 Agent 应用方向的探索和尝试，确定了 Agent 在京东广告投放中落地的两个主要的场景：

1.1 服务提效

1.2 盯盘提效

2、Agent 工程能力实现

在明确具体应用场景的基础上，依托前期技术积累与探索成果，工程实现层面需重点构建 RAG 和 Function Call 两大核心技术能力，为智能客服与智能指令场景的应用提供技术支撑。下面将深入阐述这两大核心能力的实现方案。

2.1 RAG 能力的演变

RAG 能力在实际应用中，经历过多次升级迭代，主要分为两个版本：RAG1.0、RAG2.0

RAG1.0

RAG1.0 版本中完成了基础能力的建设，包含两部分：离线知识构建、在线推理引擎。

离线知识构建

离线知识构建的核心工作是将知识转化为向量并存储。主要有以下几个步骤：

1.产品/运营将相关业务的知识整理成文档（Markdown、Excel 等）

2.根据不同格式和切割方式将内容切割成若干个内容块

3.调用 embedding model，进行内容向量化

4.将向量存储至京东 Vearch 向量库

在线推理引擎

在线推理引擎提供实时在线服务，核心工作是检索相关知识并调用大模型解决问题。主要有以下几个步骤：

1.收到用户 Query，调用 embedding 模型，进行向量化，获得向量。

2.根据 Query 的向量，在向量库中进行相关性检索，获得和 Query 相关的知识

[{    "_score": 0.7526149153709412,//相关性分值    "_source": {        "title": "搜索快车-定向设置-关键词定向-功能入口",        "content": " 搜索快车->新增/编辑快车推广单元->添加关键词...",         "status": 1,         //更多字段...    }, },//更多知识...]

复制代码

3.拼接提示词，要让模型更方便理解，需要将知识处理成特定的格式

//这里不方便展示业务真实的提示词，以下仅提供大致思路
请根据信息"""搜索快车-搜索快车投放要素-定向设置-关键词定向-功能入口- 搜索快车->新增/编辑快车推广单元->添加关键词；//更多知识..."""
回答问题"""搜索快车关键词设置"""

复制代码

4.调用大模型接口，传入拼接好的提示词，获取结果返回给用户。

{"output": "在搜索快车中进行关键词设置的步骤如下：\n\n1. **添加关键词**：\n   - 进入搜索..."}

复制代码

RAG2.0

向量召回时，通常要设置最低相关分值和最大召回数量，来调控召回内容的质量和数量，以追求更好效果。然而，在 RAG1.0 版本的实际应用中依然遇到了无法召回和召回质量的问题，在解决问题过程中，逐步建设了向量多路召回、ES 检索、重排序等能力，形成了 RAG2.0 版本。

向量多路召回：

场景： 部分有用的内容，相关度不够，无法召回。

剖析： 向量召回的分数与相关内容密度强相关，理论上密度越高，相关分值越高。同理，文档内容越短时相关内容密度也就越高。

方案： 知识构建向量时，将同一块知识，按照【概述+内容】分别存两份向量，其中概述内容较短，也就意味着密度较高，更容易获得高相关性。在召回时，按照概述和内容两路分别召回再去重的方式，提升召回率。

ES 检索

场景： 在对用户问题分析中，发现有一部分广告主提出一些【智能计划】相关的问题（对于搜索快车或推荐广告的智能出价的计划的习惯性简称），由于广告投放产品中有一个叫做智能投放的产品，在知识召回的时候大部分召回了智能投放相关的知识，导致无法正确回答此类问题。

方案： 新增一路 ES 检索，通过自定义分词器中的同义词、专用词、禁用词的方式，来实现部分内容的召回。比如，同义词设置：智能计划 => 智能出价计划（解决用户习惯的问题）、 购物触点 => 推荐广告 京挑客 => 京东联盟 （解决产品线升级改名的问题）..

重排序

场景： 通过以上手段，有效提升了知识召回率，但是引发了另一个问题，召回的部分知识不相关，会误导模型，影响模型作答效果。

方案： 引入 ReRank 模型，在知识召回后，调用算法侧部署的 ReRank 服务，对知识进行重排序，过滤无关知识。

经过技术迭代，RAG2.0 的能力已经演变为上图。

2.2 Function Call 能力的构建

Function Call 的能力主要是为了服务智能指令，比如：提供一个计划数据查询的工具，当用户发送【查询今天 ROI > 10 的计划】，模型会返回 Function Call 标识，包括 function name 及 arguments，调用成功后，用对应的组件渲染出来报表。

同样包含两部分，分别是：工具能力注册、在线推理引擎。

工具能力注册

该模块主要工作是将工具的信息管理起来，主要包含三部分信息，分别是：

1.模型感知的信息：主要作用是给模型做推理，名称、参数、描述，为了让模型推理更准确，描述的内容我们做了拆分，由基本描述、扩展描述、示例指令几部分组成，下面是一个工具给模型的信息示例：

{    "type": "function",     "function": {        "name": "query_xxxx_data" //名称        "description":             "根据ROI、时间....查询广告计划数据" + //基本描述            "这是一个查询计划数据的工具，可以根据..." + //扩展描述            "示例指令：\n- 查询今天ROI > 10的计划数据\n -查询上周..." //示例指令        "parameters": { //参数            "type":"object",            "properties":{                "startTime":{                    "type":"string",                    "description":"开始时间，格式yyyy-mm-dd"                },                "endTime":{                    "type":"string",                    "description":"结束时间，格式yyyy-mm-dd"                },                "roi":{                    "type":"string",                    "description":"ROI（投产比）查询条件，如："ge|3"代表大于等于3。gt-大于，lt-小于，eq-等于，ge-大于等于，le-小于等于"                },                //...            }        }    }}

复制代码

2.后端感知的信息：正常情况下，工具的执行其实是调用了后端的接口，那么就需要接口地址、接口入参、接口出参、成功条件等信息。其中接口的入参和模型感知信息中的参数是同一份数据。

{    "url": "http://xxx.jd.local/xxx", //接口地址    "success":{//成功条件        "condition":{            "from":"code",            "operator":1,            "target":1        },        "data":"data"    },    "params":[//出参        {"key":"code","type":"integer","description":"code码"},        {"key":"msg","type":"string","description":"错误信息"},        {"key":"data","type":"string","description":"返回给前端数据"}    ],    "error":{"msgType":1,"msgKey":"msg","msgContent":""}}

复制代码

3.前端感知的信息：工具调用成功后，通常有多种处理方式：1.把结果直接返回给用户。2.把结果给到模型，模型继续做推理，同时可以再定义 Prompt。3.将结果使用组件渲染给用户。

我们为广告主提供的工具大部分都要用组件进行渲染，比如数据报表。当工具需要和组件结合的时候，需要考虑组件的配置化和复用率，这里我们打通了既有的低代码平台，会将组件的信息保存下来。

{"pageData":[    {        "name":"数据表格",        "componentName":"jad_ReportTable",        "jsUrl":"jadfe/xxx/ReportTable.6a3493f4.js", //组件CDN地址        "options":[//组件配置            {                "key":"columns",                "type":"list",                "name":"列设置",                "options":[{"key":"title","name":"列名称","type":"input"},{"key":"key","name":"字段key","type":"input"},{"key":"width","name":"宽度","type":"inputNumber"},{"key":"sort","name":"排序","type":"switch"}],                "value":[{"title":"计划名称","key":"campaignName","width":110},{"title":"产品线","key":"businessTypeStr","width":110},{"title":"时间","key":"date","sort":false},{"title":"展现数","key":"impressions","sort":true}],        }],}

复制代码

在线推理引擎

提供实时在线服务，核心作用是组装工具信息调用大模型进行推理。以下是主要步骤：

1.收到用户 Query，从数据库读取工具信息

2.将工具组装成模型需要的格式，组装 Prompt，调用模型

3.如果模型返回 Function Call 标识，通过标识中的 function name 找出对应的工具，调用该工具的接口

4.根据结果的展示行为，有以下几种处理方式：

5.前端将返回的内容展示给用户，如需要组件，动态加载组件的 CDN 地址，完成渲染。

2.3 工程能力全貌

经过各种能力的建设后，工程能力的全貌演变为下图。其中与模型交互的核心能力采用了 Langchain 框架。

3、京准通智能助手能力展示

基于以上构建的工程化能力，支撑了京准通智能助手的落地，目前已包含：问题解答、数据查询、物料创建、物料编辑等能力。

体验地址：jzt.jd.com（需要商家账号）

在支撑京准通智能助手落地中，除了以上一些核心能力的构建，也有很多细节的优化，比如：

指令中日期的准确性优化

二、基于业务沉淀 Agent 搭建平台

以上就是京准通智能助手业务从 0 到 1 的过程，可见一个大模型应用真正应用到生产环境中，是比较复杂且有非常大的工作量的，我们在思考，如果广告内有其他的业务场景，是否能实现一些能力的快速复用？

与此同时，随着业务效果的优化进入深水区，我们需要通过对工作流程更精细化的编排来进行效果的优化。

综合以上考虑，我们决定在工作流能力构建的同时，将已有的能力增强并沉淀一个 Agent 搭建平台，来提升工程复用率和应用搭建效率。以下是整体架构：

基建： 主要是公司的基建，提供一些基础能力，如：向量库、ES、OSS、Mysql、CDN 等等

Agent 设计器： 主要是提供 Agent 可视化的设计能力，包括智能体、知识库、工具库、记忆库、工作流等核心功能。

Agent 引擎： 主要是根据设计器产生的配置，动态运行工作流程，如：知识的召回、提示词的加工、模型的推理、工具的调用、代码的执行等等。

端能力： 主要是面向用户的对话式组件，这里我们沉淀了一套 AI 组件库，可快速组装出兼容 PC、H5 的对话框。与此同时，针对内部的京 ME 办公场景，对外如微信中的场景，我们也通过 API 调用的方式进行了支持。

应用场景： 有这些能力，就可以轻松的利用平台支撑起各种 Agent 应用，包括我们的京准通智能助手。同时除了业务之外，还可以做内部提效的 Agent 应用。

下面我们将主要介绍一下 Agent 设计器和 Agent 引擎的实现。

1、Agent 设计器

团队空间为了方便协作和做业务隔离，团队空间下，可以进行智能体的搭建、知识库的管理、工具库的管理、工作流的编排等等。

知识库中，可以选择不同的向量模型，方便做召回优化的实验。

工具库中，可以设置每个工具的模型感知信息、接口、参数、渲染组件等。

工作流中，可以随意拖拽编排工作流程，比如：召回节点可以设置召回策略、召回数量、最低分值等；大模型节点可以设置 System、User 提示词、历史会话轮数等。

2、Agent 引擎

Agent 引擎负责和模型交互，是影响效果和性能的核心模块。我们做了重点的设计和重构。在设计阶段，我们考虑的首要问题是：Langchain 的取舍。

Langchain 框架提出了 LCEL 语法，将 Prompt、LLM、Tool 等概念进行了抽象并高度封装，能快速上手并实现一些 Demo，对新手比较友好。

然而，随着业务的复杂度不断增加，以及对模型的了解不断深入，会发现，Langchain 的过度封装，把很多简单的事情变的更复杂了，明显影响了业务自由度及开发效率，同时也带来了一定的性能损耗。

举个例子：工具调用中，模型接受的参数是一个 JSON Schema，我们只要将工具参数存成一个 json 用的时候就会非常方便。

然而，如果使用 Langchain，就需要先将 json 转成一个 pydantic 类，再使用 Tool 类进行工具的注册，在调用模型时，Langchain 又会转换成 json。

本来一行代码就可以搞定，使用 Langchain 后需要几十行代码才能实现，并且降低了性能。

最终，我们决定移除 Langchain 框架，直接用原生 python 实现，仅保留个别用起来比较方便的工具，如：文档切割。

整体上，设计了一套工作流调度器，并将所有节点实现了组件化。收到请求后会初始化一个工作流调度器，调度器根据时机来操作每个节点的执行。

截止目前，Agent 平台已经为包括智能助手在内的多个 Agent 应用进行了赋能。其中，在京准通智能助手的效果调优中，基于工作流编排的能力，快速进行了各种策略的迭代，大幅提升了迭代效率。

京准通智能助手工作流示意图

三、总结

以上是我们京东广告在 Agent 应用上的一些工程化实践，通过构建 RAG、Function Call 等核心能力，为京准通智能助手业务提供 AI 超能力，并为广大商家赋能。

下一步，我们还将推动多 Agent 架构升级，为更多专业的 Agent 能力接入铺平道路，促进智能助手能力的持续提升，为商家提供更智能化的产品。总之，道阻且长，行则将至！