大厂县建设局网站建一个自己的网站

当前位置： 首页 > news >正文

大厂县建设局网站,建一个自己的网站,韶关网站建设,做水晶接单在哪个网站接前言 自2022年末ChatGPT的问世#xff0c;大语言模型#xff08;LLM#xff09;技术引发全球关注。在大模型技术落地的最佳实践中#xff0c;智能体#xff08;Agent#xff09;架构显现出巨大潜力#xff0c;成为业界的普遍共识#xff0c;各大公司也纷纷启动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、京准通智能助手能力展示 基于以上构建的工程化能力支撑了京准通智能助手的落地目前已包含问题解答、数据查询、物料创建、物料编辑等能力。 体验地址https://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能力接入铺平道路促进智能助手能力的持续提升为商家提供更智能化的产品。总之道阻且长行则将至