AI 应用工程化专场
内容介绍
1. 初识 Spring AI Alibaba开源项目
2. Spring AI Alibaba 深入讲解
3. Spring AI Alibaba RAG 开发实践
4. Spring AI Allbaba 未来规划
5. 数据
6. 问答
今天主要讲的是Spring Alibaba开源项目。从名称上可以看出,它其实是Spring生态中的一个重要组成部分。对于熟悉Java或微服务开发的开发者来说,应该都比较了解。在这之前,有一个颇为成功的项目叫做Sprout,它与Spring Cloud生态紧密结合。接下来也会提到Spring Alibaba项目,其定位是帮助Java开发者更方便地构建AI智能体,大致目标就是如此。因为大家所了解到的很多项目都是基于开放生态的。
关于个人,如前面主持人所介绍,我是刘军。我参与的开源项目其实相当多,刚才主持人也提到了,我之前还不知道他也是来自本地的,他还参与了cooking sphere开源社区。这就说明整个开源生态在中国的发展势头良好。这确实是一个好现象,意味着在我们本地的城市,大家能够自发地通过社区的形式来举办相关活动。
我参与的开源项目包括Apache Dubbo,以及阿里巴巴的Spring Cloud Alibaba等多个项目。目前,我在开源方面的主要投入集中在阿里巴巴的相关项目上。今天,我计划分享四个部分的内容:首先是项目的背景,其次是项目的一些基本使用方法和原理。在中间部分,我会通过一个机票住宿的实例来进行说明。
他可能会在多轮绘画过程中使用寄存器,并与大模型进行交互等,这些稍后会详细展开。最后是关于项目的规划。由于该项目仍处于起步阶段,我们非常欢迎大家的参与。这是第一页的内容,尽管可能有些显示问题,但不影响理解——这是关于项目介绍的部分。这里阐述了整个项目的背景,即当下大家都在热议的AI领域,特别是生成式AI。我猜测,无论是在公司业务讨论中,还是在技术交流会上,大家谈论最多的应该都是与大模型相关的服务。
01. 初识 Spring AI Alibaba开源项目
在领域快速发展的阶段,在模型开发方面,可能在座的各位能直接参与的机会都不太多。毕竟,这需要一些特定的公司,比如云平台或大型企业来主导,因为它们既需要专业人才,又需要承担高昂的成本。那么,对我们而言,更相关的可能是如何将这些AI技术应用到我们的业务和实践当中,这与我们密切相关。作为Java开发者,当我们接受AI后端模型服务时,应该如何操作呢?其实,最直接的方式是利用OpenAI或阿里的通义千问模型,它们都提供了开放的API接口,这是标准的接入方式。所有的大模型服务都支持这样的调用方式,因此只需直接通过HTTP接口调用它们即可,这是最为直接的方法。
在这个方式之下,我们必然会遇到许多挑战。因为首先,你需要深入了解这些HTTP接口的规范,这本身就是一个相对复杂的过程。其次,仅仅调用单个原子接口往往难以解决你的实际问题。例如,如果你调用OpenAI的completion接口来进行基本对话,这可能相对简单,或许你花一天时间就能完成接口对接。
然而,当你真正着手解决业务问题时,比如利用RAG或其他AI应用开发模式来构建智能体应用,你就需要在多个原子接口的基础上封装自己的业务逻辑,这使得整个过程变得更加复杂。在这种情况下,如果我们使用Spring生态来开发Java应用,虽然Spring的RestTemplate等工具能帮助我们简化OpenAI等API的接入,减少一些模板代码的编写,但它并不能解决我们在开发AI智能体应用时所面临的标准编程范式问题。
在此背景下,大家可能听说过中国浪潮的开放生态,或者像Love Index面向AI场景的开发框架,它们正是为了解决这类问题而诞生的。在Java生态中,关于与这些框架的深度对比,今天可能无法详细展开,但这确实是一个值得探讨的方向。
我们回到Java生态的话题。在Java生态中,首先值得一提的是,Spring官方社区在今年五月份发布了一个关于AI的开源项目,项目名称可能有些复杂,暂且称之为“Spring AI 1.0.0-M1”。我们与Spring官方社区进行了官方的沟通和协作。随后,在九月份,阿里巴巴也将他们的相关项目进行了开源,并进行了相应的建设。
总的来说,Spring AI与阿里巴巴合作的项目是以Spring AI为基础,同时提供了对百炼大模型服务的标准适配。虽然最初的第一版本我们主要完成了这一功能,但实际上它包含的内容更为丰富。接下来,我会详细介绍一些内容,比如如何将你的智能体应用部署到线上,如何进行Prometheus调优,以及当简单的对话形式无法满足你的场景需求时,如何进行流程编排等。在这些场景下,Spring AI生态目前更专注于底层原则的实现。因此,这也是我们当前科研项目要重点做的事情。
这就是我们与Spring社区协作的形式,具体来说,就是Spring AI与阿里巴巴合作所开展的工作。简单来说,绿色的部分代表了Spring AI或Spring生态擅长做的事情,这相当于Spring Framework最初出现时,旨在简化整个Java生态的开发过程。那么,Spring AI的定位是什么呢?
Spring AI致力于从原子层面进行抽象,以简化整个Java领域在AI应用开发中的复杂性。而蓝色的部分则代表了我们在这个项目中将会开展的一些工作,具体内容我在这里就不详细展开了。如果大家对此感兴趣,可以在后面拍照留念,或者观看回放。
接下来提到的是阿里巴巴之前已经成功开展的一个类似项目。该项目与Spring生态所做的工作相辅相成,其中绿色部分代表Spring生态的贡献,而蓝色部分则展示了阿里巴巴生态的努力。这两部分共同构成了一个在阿里巴巴开源生态中的整体微服务解决方案,集成了分布式事务处理、任务调度等多种功能。其实,这两者的核心理念是相似的,我们可以推测,它们后续的发展方向也将趋于一致,希望这样的解释能帮助大家更好地理解。
02. Spring AI Alibaba 深入讲解
关于第二部分,虽然具体内容看不清楚,但我想强调的是白色字体部分所展示的AI阿里巴巴框架的核心功能和使用方法。我将其核心特性概括为以下三个部分。首先,这是一个专为Spring或Java开发者设计的框架。简而言之,它是一个标准的Spring Boot应用。开发AI智能体就像开发Spring Boot应用一样,你可能只需要注入一个Bean,这个Bean就是负责模型调用的概率,这是最简单的理解方式。
第二部分主要介绍了这个框架所承担的具体任务及其抽象层面上的功能。它能够与各种模型进行适配,实现Brown的即时存储管理,同时涵盖了RAG的开发以及一些工具集的定义。这些都是框架所提供的原子级别的抽象功能。除此之外,AI阿里巴巴框架还会进行一些更高层次的工作,比如流程编排以及本地开发工具的集成等。第三部分聚焦于它与各生态的集成,特别是与阿里云模型服务的整个生态的深度融合。考虑到智能体本身也是一种应用,特别是与AI紧密相关的应用,从开发、生产到部署上线、运维的整个生命周期中,都需要与各种生态进行集成。此外,我们也将关注流量管理等方面,确保应用的顺畅运行。这与后续讲师的讲解也是息息相关的。
这里是直观地展示一下,使用Spring Boot结合阿里巴巴的相关框架来开发应用时,具体需要完成哪些步骤。假设我们已经有一个Spring Boot应用,那么第一件事情就是添加必要的依赖,这是一个标准的操作。第二件事情是在Spring Boot应用的文件中添加AI服务的that scope,即代表百年的服务,比如通义模型的API地址等,这个配置是不变的。无论这是一个老应用、新应用,还是标准的Spring Boot应用,都会有一个启动入口。
完成上述三件事情后,我们引入the client的AI框架客户端就充当了一个模型代理服务的角色,我们可以将chat line注入到我们的任何业务逻辑中。这时,当我们与模型进行交互的任何问题时,我们就可以在这个位置直接进行处理。这个位置可以看作是一个AI智能体或者是一个AI交互的接口。所有的业务逻辑处理都集中在这里,非常直观。
上面简要介绍了阿里巴巴的某个框架,并直观地展示了它如何简化我们的开发工作,其实就是一个book制作了一个B,就是这么简单。接下来,我们深入了解一下框架背后的核心概念的抽象,看看它是如何帮助我们完成这些任务的。
第一个抽象就是“Chat Model”。简而言之,Chat Model的作用就是赋予应用与大型模型进行技术对话的能力。就像我们之前提到的,OpenAI提供了自己的HTTP API,我们可以通过它与模型进行check聊天。而现在,这个Chat Model的抽象解决了如何帮助我们将应用与模型连接起来的问题。基本上,它就是做了这件事情:让我们的应用能够轻松地与大型模型进行交互。
当你接入大模型服务时,如果把这个过程用图来表示,那么大模型服务就位于中间。你通过调用它的开放Open API来与它进行交互,本质上就是给它输入,然后它给你输出。回想起最初GPT刚发布的时候,大家可能都有印象,它的输入和输出都是纯文本格式。你向它提供自然语言的输入,它就会给你返回自然语言的输出,这其中包括它的推理以及更深层次的内容。
随着模型技术的不断发展,现在的输入形式已经不再局限于纯文本。Spring AI的抽象也不仅仅支持文本输入,它还支持图像、语音以及视频等多种形式的输入。相应地,输出形式也变得更加多样化,不再仅仅是文本。例如文生文,再比如你可以要求模型根据文字生成图片,或者将图片转换为语音,甚至将语音转换为文字等。这种多模态的输入输出能力,现在许多AI框架都已经支持,只需要进行简单的调用即可实现。
一旦你声明并接入了这个Chat model,你就可以直接调用它来处理各种形式的输入输出。此外,现在的模型还具备处理多模态输入的能力,即可以同时接受文字和图片作为输入,并进行相应的理解和处理。这种层次的抽象极大地简化了接入过程,使得开发者能够更加方便地利用AI模型的能力。
那么第二个概念就是关于提示词管理的Prompt。Prompt对于大多数人来说可能并不陌生,但考虑到我们今天要做的是一些基础介绍,我还是会简要解释一下。简单来说,Prompt的作用就体现在与模型交互的过程中,我们给到模型的输入都可以理解为是“提示词”。换句话说,当我们与模型进行交互时,我们的输入内容就是通过Prompt作为提示词传递给模型的。
随着模型技术的不断进步,现在的Prompt已经超越了以往我们常见的简单问答形式。现在的输入变得更加复杂且多层次,有些被称为System Prompt,它包含了多个角色的信息。在这些角色中,我们的问题通常对应于User Prompt,即用户提示词。此外,还存在其他几个不同的角色提示词。
阿里巴巴的Spring AI框架在这一方面提供了很好的抽象,它帮助我们更有效地管理这些Prompt。例如,我可以指定System Prompt为应用编码,如果编码中没有问题,那么我可以直接这样调用。另外,它还支持文件加载的形式,这一点与Spring生态紧密结合,使得使用更加便捷。
我只需通过一个注解,就能轻松管理我的System Prompt,它类似于一种预先设定的角色。比如说,我开发了一个智能体,并为其设定了客服的角色定位。这个角色的定位是固定的,无论面对什么样的问题,它都会以这个角色来回应。因此,我可以将这个角色信息写在文件中,然后通过Spring AI框架的注解功能直接加载进来,无需每次都重新指定。
还有一种功能,就像之前提到的,最新版本的框架支持在nos这边动态地调整Prompt。这意味着,当我的应用启动后,我可以通过可视化界面或手动操作,实时地调整我的Prompt。这种调整对于Inform来说尤为重要,因为往往需要频繁地调整才能达到最优效果。这种动态调整的能力是另一个框架的重要抽象,它专注于输出部分,与我们之前讨论的chat model图表中的输入输出环节紧密相关。换句话说,它关乎模型向我们提供的反馈和结果。
从程序的角度来看,我们为何要进行这样的操作呢?因为程序通常期望获得的输出是结构化的。当我获取到这些数据后,我需要将其转化为符合我标准的数据结构,无论是为了传递给下游的应用程序,还是存储到数据库中,或是进行其他处理。程序期望的一定是格式化的数据,然而,从模型的视角来看,它提供的数据可能并不符合我们的期望格式。为了解决这个问题,框架在其中扮演了关键角色。以原始用户问题为例,框架会在将问题提交给模型之前,先明确我们期望的输出格式,并将这一格式与问题一同传递给模型。这样,模型就能根据我们想要的格式来生成输出,即它能够返回你预定的我有哪些字段,并确保返回的字段既不多也不少。随后,框架再将模型输出的数据转换成程序能够处理的格式,比如Java中的这个B在这时就可以处理了。
这个处理过程是由框架自动完成的。当我们定义了相应的方法并提出问题后,框架会自动处理数据格式的问题,无需我们手动干预。此外,还有一点需要提及,那就是Function Call,这也是AI开发中常用的一个概念,即工具调用。
也就是说,在与许多模型交互的过程中,我们可以预先告知模型一些可用的方法。换句话说,我们可以向模型说明,存在哪些方法可以被调用。由于模型的知识是通过预训练获得的,它无法替代我们完成所有事情。最直观的一个例子是,业务系统与模型之间通常是相互独立的,模型不会直接涉及业务系统的具体逻辑。
当你调完模型后,比如模型的角色涉及修改或查询数据时,你该如何处理呢?一个简单的方法是,预先告知模型你有哪些方法可供调用。当模型识别到你的问题需要使用这些方法时,它会通过框架来请求调用这些方法。此时,框架作为一个中心化的注册和管理中心,会接收到模型的请求,并识别出需要调用的方法。然后,框架会负责执行这个方法,完成数据的修改或查询。虽然这个过程听起来可能有些复杂,但实际上,框架的存在大大简化了这一流程,使得模型与业务系统之间的交互更加高效和便捷。
这是在框架上的设计,特指斯洛尼亚阿里巴巴框架的抽象层。该框架预先定义好了所有的函数,这些函数具有特殊定义。比如,通过使用注解,当在prompt中调用模型时,相关参数会自动传入,这一过程由框架自动完成。如果模型在决策推理后发现需要调用某个函数,那么这个调用过程同样由框架自动处理。简而言之,整个函数的元数据组装、识别,以及最终的函数调用,都是由框架来完成的。
这是一个框架的抽象表示,是calling模型交互过程的抽象具体的展示。以下是一些伪代码,其大意是,在使用Spring AI框架后,定义函数变得非常简单,只需为方法添加一个注解,它就被识别为可调用的函数。
上面展示的是请求部分,这是Prometheus的请求,而这是模型给出的答复。在没有function calling和函数调用的情况下,请求就是请求,我们不会附加任何额外的内容。例如,当我们向模型提出一个求平方根的问题时,模型会给出它自己的计算结果。
然而,如果我们为这些函数定义添加了注解,那么在再次请求模型时,框架就会在这边附加额外的信息。
关于这个“tooth”,这是我们与模型进行的第一次交互。在输入了额外信息后,模型给出了一个响应。这个响应并非如最左侧所示直接给出答案,而是提示我们需要调用某个方法。接着,在第一次交互后,模型的行为已经发生了变化。到了第二轮交互,由于在之前的交互中框架接收到了调用该方法的指令,框架便调用了这个方法并完成了运算,最终得出了一个答案。
他还需要与模型进行一次额外的交互,即带上之前的信息,包括他的原始问题以及模型之前要求他调用的方法。他会告诉模型,他已经按照指示调用了该方法,并且该方法执行后的答案是如此这般。然后,他将这一整套信息再次给到模型。模型在接收到所有这些上下文信息后,会给出最终的答案。从最初的交互到这一轮交互的整个过程,包括所有必要的方法调用,都是由框架自动为我们完成的。这正是框架对“folding封装”所带来的便利之处。否则,我们就需要亲自去处理与OPO的对接工作了。
接下来要介绍的框架中的另一个AI编程模式的抽象,是关于rag这一部分的,即检索增强。检索增强这一通用概念,实际上分为两个组成部分。
我们应该如何看待这个图示呢?图中展示的是,中间存在一个中转介质,即向量数据库。这个向量数据库的主要功能是存储我们的私域数据。那么,为什么我们需要这个向量数据库呢?原因在于,我们之前提及的混合模型中,大模型通常是预先训练好的。因此,它们可能不了解一些最新的信息,也可能不熟悉我们特定领域的私域信息。为了弥补这一不足,我们需要为大模型提供辅助数据。在当前的模式下,这些辅助数据就是通过向量数据库来提供的。首先,我们需要对私域数据进行离线处理,即对其进行向量化,这个过程在此不详细展开。你可以理解为,例如将某些文档向量化后,存储到向量数据库中。接下来,就是我们之前讲述的智能应用与AI的交互过程。
在交互过程中,系统会首先查询向量数据库。举个例子,当用户询问关于某产品的具体使用方法时,框架在正式调用模型之前,会先在向量数据库中执行一次检索,就像是在数据库中搜索“该产品如何使用”的相关信息。这一步骤是在私域数据中进行的搜索,旨在找到相关的具体文档,而通常情况下,这些文档中必然包含用户问题的答案。在这种场景下,系统会自动将原始问题及上下文一同传递给模型。这些都是框架自动完成的,模型会基于原始问题和上下文,最终给出一个精确的答案。这就是所谓的“break”部分。
然后,在阿里巴巴的框架中,首先进行的是离线处理,这是一个标准的模式,涵盖了接口的运行和抽样,这些都在蓝色背景的部分有所体现。接下来是与向量数据库的对接,无论是存储还是查询功能。此外,还包括中间的组装环节,比如召回策略的制定,以及窗口控制的实现等,这些都是框架所承担的任务。可以说,框架将我之前提到的所有AI编程范式都进行了抽象和定义。以上是关于阿里巴巴框架,特别是其核心内容的抽象和定义的一些讲解。由于今天无法进行现场演示,我们就以李总展示的一个机票智能助手为例,来探讨如何使用阿里巴巴框架进行业务场景应用的开发,特别是如何运用我们前面提到的AI概念。
03.Spring AI Alibaba RAG 开发实践
下面是该应用的一个架构图,我们期望实现的目标如图左侧所示。因为我这是一个机票智能助手,所以我希望它能够回答用户关于订票的各种问题。用户自然会用自然语言与我进行对话。如果用户需要查询订单信息,或者进行改签、退票等操作,这些功能都应该能够自动完成,这是我期望这个助手能够具备的能力。
简单来说,这个应用需要满足以下几点要求:首先,它必须能够与AI进行实时对话,这是最基本的要求。第二个是它需要支持多轮对话,即当用户提出一个问题后,如果他继续提出第二个问题,系统应该能够自动记住并理解前一个问题的上下文信息,这是需要自动完成的。
第三点要求是要理解并严格遵守机票操作的相关术语和规范。这是什么意思呢?因为当用户进行退票、改签等操作时,每个公司都有自己的一套规定,包括收费标准等各个方面。这些具体细节对于一个通用的AI系统来说通常是未知的。因此,在这个时候,我们需要利用之前提到的那个模式,即RG rag模式,将我们公司特有的这些规定和信息传递给AI系统。在进行这些操作之前,AI系统必须严格遵守这些规定。
第四点要求是他能够调用必要的工具来辅助完成其任务,以上就是四点主要要求。为了达成这四点要求,这里提示了一下我们可能会用到上面提到的模型的几个功能点。当然,chat model并未明确写出,但基本上是需要接入的。此外,还需要用到bom的管理from calling、对话记忆功能,以及之前提到的reg等模式,这些基本上都会被用到。
右边的这张图是架构图,我简单为大家讲解一下。中间的部分是我们开发的应用,它是基于阿里巴巴框架开发的特定过程应用。用户在这里有一个输入问题的界面。中间环节涉及的是我们公司的一些规定等私域数据,这些数据通过向量数据库进行查询。那么,这里的核心是什么呢?就是我们机票的实际数据。因为机票的所有订单等信息都存储在你的数据库中,这部分业务逻辑是不变的,而我们只是在业务的基础上增加了一些智能化的能力。这是我们的机票服务及其数据的大致情况。
这是我们的应用主题。其实,使用阿里巴巴的框架来开发这个应用相对简单。只需利用这一行代码,即流式代码,就能将我之前所有的功能都集成在这里。
首先,我定义了一个“system prompt”系统,Prompt相当于给这个应用设定了一个角色定位。假设你是一个机票助手,那么你应该如何执行任务呢?这主要包括一些职责和约束的设定。
在这里,“adviser”实际上是框架中定义的一个概念,它本质上是指我提供了一个支持多轮对话的组件,并告知你在与大模型进行问答时需要携带之前的历史消息。简单来说,这与reg有关。即我声明了一个向量数据库,意味着在回答某个问题之前,会先在这个向量数据库中检索一下,再结合上下文。此外,还有一个日志打印功能,方便调试和追踪。最下面的一行则是声明本地可用的函数、工具或模型。基本上,用这样几句话,就把这个智能体的核心概念都组装起来了。而下面这部分是方式calling定义的一个展示,这个在前面已经看过了。
这部分声明之下,便是其具体的定义部分,这部分内容相对直观,无需过多阐述。大家可以看到,这里定义了一个标准的方法。紧接着,是标准的加入方法,只是在方法上增加了一个注解,指明了它是并发的,并简要描述了该函数的功能,以便于模型理解,整体而言相当简洁。
接下来,我们关注的是多轮对话的实现。如前所述,多轮对话的声明已经给出了一个组件。那么,它是如何实现的呢?这里的关键在于,该组件会基于一个对话ID conversation ,根据ID来组装历史上下文,这一步骤是由框架自动完成的。
右边这部分相对复杂一些。大致意思是,在将请求发送给模型之前,由于这个request携带的是用户的原始请求,因此我会根据对话ID去查询历史消息,并将查询到的历史消息添加到request中。这样,在与模型进行交互时,请求就会包含上下文信息。而这是框架做的事情。
然后,关于RE这部分,它更偏向于原理层面的内容。之前我们提到的离线部分,就是指这一环节。当我有了文档(dock),即一些文本内容时,我需要将这些内容存储到向量数据库中。这是一个独立的步骤,可以在线进行,也可以预先作为离线任务完成,甚至设置为定时任务,这些都是可行的。而这个过程与之前提到的类似。
同时,框架为我们处理了这样一件事:当我们拥有very store中的数据时,在将请求(request)发送给模型之前,框架会先在存储系统中进行检索,具体来说是检索向量数据库。检索完成后,框架会将检索到的上下文信息添加到请求中。这样,当请求与原始问题一同被发送给模型时,它们就已经携带了上下文信息。而这个过程是自动化的。
以上就是机票助手的架构及其所用到的一些组件。对于开发者来说,直观了解这些内容通常就足够了。而我们的这个示例是包含源码的,并且源码存放在GitHub的仓库中。
这里有一个example,稍后我会展示这个示例的地址。另外,还有几页内容是关于如何快速体验这个智能机票助手的。我们提供了一个位置,这是一个阿里云上的应用,具体是一个server平台。大家可以访问这个地址:KCEPCP.col.aliyun.com。进入页面后,你会看到一个模板应用,这个模板应用支持快速部署,因为它的service是弹性的。你只需要点击相应按钮,就可以立即进行部署,而它唯一的要求是,由于这个应用需要访问通义模型,而通义模型这边提供了免费额度,所以你需要根据提供的链接去申请一个API,并将API贴在相应的位置,然后就可以进行下一步部署了。这里也介绍了如何在百炼上申请API Key的方法。
到达这个位置后,其实无需大家进行任何操作,系统会自动跳转到该页面。函数部署完成后,由于它是一个service,因此会自动分配一个公网可访问的地址。此时,你只需访问这个地址,就可以直接调用你的应用,并看到相应的界面。这个界面支持聊天功能,你可以进行模拟对话,与智能机票助手进行交互,以检查它是否符合你的要求。
04. Spring AI Allbaba 未来规划
最后,我们来谈谈整个项目的规划。前面已经提到,我们的这个项目,包括Spin AI本身,都还处于一个比较早期的阶段,即尚未发布且基于1.0的正式版。目前,Spin AI似乎正处于一个类似于“里程碑三”的状态。因此,我们的工作也还在进行中。
这是从较为宏观的视角来阐述我们接下来的工作计划。之前所讲述的所有内容,基本上都涵盖在绿色的这一部分中。左边展示的是我们框架的位置,其中也包括了之前提到的OG,它是用Java编写的。
这些基础框架,我们将其定义为偏原子层的组件。也就是说,上面提到的智能体应用开发所用的所有原子组件和范式,都是通过这些偏底层的框架进行抽象的。Spring Alibaba团队会负责一些生态适配工作,包括适配Apps、黑gress等。这就是原子层的作用。而利用这些原子层的框架,我们可以开发一些包括RAG应用和普通的聊天室应用,以及与AI进行基本交互的应用。这些应用通常不会很复杂,应该能够满足大部分需求。
再往上一层,这是我们目前规划中可能会做的一项工作,即所谓的work flow编排。这是针对更复杂应用场景的解决方案。我们会提供标准的API和框架,让大家可以通过编码的方式来定义工作流,从而开发出更复杂的agent的智能体应用。当然,在这一层还没有实现可视化功能,主要还是以框架为主,这也是我们的核心所在。大家可以通过编码来完成这些工作。
然后,在最上层,我们计划提供一些Studio层的功能,主要是为框架本身增加可视化元素。这些可视化的工具简单来说,第一个功能可能会帮助你快速生成下面的项目。举个例子,我们使用Spring有一个start.spring.io这样的平台,它可以生成项目的脚手架。我们只需要选择一些依赖项,项目骨架就能快速搭建起来,然后就可以导入到我们的IDE环境中。对于我们整个Spring ARA来说,阿里巴巴本质上也是提供了类似的功能。
理论上来说,如果我已经实现了workflow这一层的功能,你当然可以自行编写APR来统一定义工作流。另外,我也可以提供一个控制台,允许你通过拖拽的方式设计工作流,设计完成后可以一键下载。下载下来的项目,就像是一个由阿里巴巴团队预先编写好的模板,或者说你下载了一个项目骨架一样。然后,你可以将这个项目导入到你的IDE中进行进一步的开发。
这是一点,即项目的脚手架支持通过拖拽方式快速搭建原型,并可以一键下载。而后续的维护和部署工作,仍然是在IDE中通过框架来完成的。
第二个阶段,当你在IDE中开始开发时,我们还希望能提供一些本地开发工具。这些开发工具的主要功能是什么呢?简单来说,就是当你在IDE中运行你的本地开发项目时,我们假设有一个内置功能,即当你通过local host访问特定端口时,就能够可视化地看到你的智能体,包括它的工作流或框架的运行情况。此外,你还能够在可视化的本地工具中进行一些from的调优。这些调优操作都是实时可见的,并且能够反映出框架的内部状态。这就是Studio层可能实现的一些功能,并且我们目前正在积极推进这一层的开发。
上面的图表更侧重于应用架构层面,其涵盖的领域范围相对更广泛一些。大致意思是,我们会在整个AI应用的流量管理,稍后HighGress的讲师会详细讲解,以及动态的form管理、事件驱动以及整体可观测性平台等方面进行一些生态适配工作。此外,关于后端模型服务的适配,这里我就不再详细展开了。
05. 数据
数据的格式对于框架来说是没有固定要求的。可以这样理解,数据的格式是由您这边来定义的。具体来说,您需要定义一个Java Bean或Java对象,并在定义完成后以某种方式声明它。当您与模型进行交互前,比如您向模型提出一个问题时,并开始问模型了。那么框架会拿着你定义好的java类的原数据,比如有哪些字段,而每个字段的string是什么类型,有什么字段?它都会给你放到你的请求的brand的上下文当中,并给到模型。
其中,每个业务场景都有其独特性,因此框架并不提供一个统一的数据格式或规范。以调用外部服务为例,最典型的场景可能是调用外部API。在这种情况下,规范实际上是由您自己定义的。具体来说,当您声明要调用某个外部函数或API作为入口时,您需要在该入口处明确指定您期望接收的参数数量以及每个参数的类型。
这里有两个问题,其涉及到不同格式的组合与身份的识别。那么,对于格式的选择,是应该指定一种格式还是允许多种格式相互组合呢?这实际上取决于各个业务的具体需求。每个业务都有其独特性,因此框架不可能提出一个统一的数据格式要求。这正是大型模型存在的意义所在,即它们能够适应并处理各种不同的业务需求。
以提到的场景为例,假设您定义了十个或更多的方法,每个方法可能需要调用不同的API,并且所需的数据格式也各不相同。在这种情况下,框架会在每次调用时,根据您定义的十个函数或者更多的函数,将这些信息放入上下文并传递给模型。模型则能够根据您提供的信息,理解并返回相应格式的数据。
在这里有个问题:如果要做开源项目,通常期望有一定的格式统一性。然而,在实际的业务场景中,要实现这种格式统一是非常困难的。当然,我们可以在下面聊,因为统一的话,对于业务来说,这已经是业务上的代码了。
比如这里,我提出的问题是关于计算平方根的。本身模型可能并不擅长直接计算平方根。那么,如何计算平方根呢?这就需要应用开发者自己来实现这个功能,即定义出在这个业务场景下应该如何计算平方根。而我作为框架,能够做的事情就是:当你定义好了这个计算平方根的方法后,我会将你原始的求平方根的问题,以及你定义的计算方法一起传递给模型。模型在接收到这些信息后,就能够调用你作为业务开发者所定义的计算平方根的函数来完成计算。但是,作为框架,不可能定义好求平方根就必须有这几个入参,即数参,而这个可能不是平方根。
同学:刘斌老师您好,我想请教一下关于向量化的过程。我使用过不同的平台,发现它们的向量化效果存在差异。特别是在进行检索或分段时,有时会出现一些问题。我想了解一下,是哪些因素导致了这些差异?
刘斌老师:可以,这个问题我能理解,但是我可能给不了你完整的答案。这个问题的原因在于,向量化以及相关的数据处理领域,并非我最为擅长或专业的方向。这涉及到调整向量数据库、理解大模型服务等较为专业的知识。然而,从框架设计的角度出发,我在这一领域或许有一些微薄的经验可以分享。
影响线上化效果的因素可能出现在以下几个环节。首先是原始文档,即将文档读入系统中。读入后,首要任务是对文档进行切片处理。为什么要切片呢?因为文档可能非常庞大,比如达到好几兆的大小。在这种情况下,你最终的目标是将处理后的文档传递给模型服务,让它为你执行向量化操作。目前,大多数线上模型服务都设有窗口限制,即文件大小不能超过一定阈值。一旦超过这个大小,文件就无法传输。因此,你需要对文档进行切片处理。如何进行切片呢?切片的方式会直接影响到模型接收输入后,进行向量化处理的效果。在切片这一环节,存在多种方法和策略可供选择。
第二个环节是切片后的处理。由于你的切片是基于语义的,因此,在切片完成后,你需要将每一片文档提供给模型服务进行向量化计算。值得注意的是,不同的模型服务在进行向量化计算时会有所差异,这也会导致中间结果的不同。接下来,向量化后的数据会被存储到向量数据库中。所以,大致上有两个关键环节需要注意。另外,当接收到请求时,需要进行一些召回操作,即进行查询。这一过程中也有多种实现方式,它们同样会对最终效果产生影响。
我这边大概提供了三点内容作为总结。但那时,我只拥有GPT-2模型。我那时的工作是使用GPT-2进行一些微调,并应用于文本生成任务。当时,在NLP领域,GPT和BERT是两个热门的模型,它们都基于Transformer架构构建。然而,GPT采用的是单向Transformer架构,因此更适合于文本生成这类任务。所以,我当时选择了这个模型进行训练。尽管GPT-2的效果尚可,但与其他模型相比,并没有展现出压倒性的优势。
之后,由于我的研究方向发生了转变,我便没有再关注GPT的发展,直到2022年11月ChatGPT 1的发布。由于我之前有过使用经验,因此这次的使用让我感受到了强烈的对比,真切地感觉到AI时代确实已经发生了翻天覆地的变化。ChatGPT发布后,国内外的头部企业和研究机构纷纷跟进。从2023年开始,截至2024年6月,我们已经见证了一系列大模型的涌现。我认为,“百模大战”是对AI上半场一个较为贴切的概括。然而,由于AI大模型对算力有着极高的要求,它注定成为只能由几家头部厂商竞争的项目。我们内部判断,AI领域可能会经历一个从“卷模型”到“卷应用”的转变。
这也意味着每个人都有机会参与到AI时代的变革中。接下来,我分享一些公开数据来与大家探讨。第一张图展示了中国AI原生应用月活跃用户数的趋势。从图中可以看出,从2024年初到9月份,月活跃用户数已经翻了两倍多,且每个月的增长势头都相当可观。此外,我还展示了某个具体产品的月活跃用户数增速变化。左边是全球增速榜,可以看到最高的月活跃用户数增速已经超过了400%。而在国内,增速最高的是K美,其月活跃用户数增速为36%。无论是从整体使用量还是月活跃用户数的增速来看,国内相较于国外仍有很大的提升空间。因此,我认为大家都可以发挥自己的idea,尝试开发一些AI原生应用。
作为一款网关产品,我们主要关注的是AI流量对网关带来的挑战,以及我们能在网关上实现哪些功能,以帮助用户更高效地构建AI原生应用。
我们认为,与常规业务流量相比,AI流量呈现出三个显著特征。首先,它倾向于使用长连接。AI请求通常采用WebSocket或SSE协议,这意味着长连接的比例相对较高。因此,在网关更新配置时,需要特别注意维护这些长连接,确保它们在请求结束后再断开,从而避免断连对业务造成的不良影响。
第二个特点是高延迟,具体体现在大模型请求的响应时间上。由于大模型进行推理的速度相对较慢,其响应时间往往远超普通应用。这使得AI应用在面对恶意攻击时显得尤为脆弱。同时,大模型生成的内容具有一定的概率性,即便大模型已采取内容安全防护措施,仍可能存在疏漏,带来一定风险。特别是在国内环境下,一旦涉及非法内容,将带来严重麻烦。因此,这也是网关产品需要重点考虑的问题。第三点特征是大带宽消耗。在AI场景中,带宽的消耗远超普通应用。如果网关产品没有做好流量处理,就可能导致缓存数据量巨大,进而引发内存快速上涨的问题。
传统流量网关在这三个方面确实存在一些处理能力上的不足。例如,在配置热更新方面,如果在更新配置时需要执行reload操作,这会导致长连接断开,对用户体验造成不良影响。特别是在高并发场景下,如果所有长连接都断开并重连,很容易引发重连风暴,进而可能导致后端服务被压垮。
第二点,传统流量网关的安全防护能力不足,特别是缺乏对AI生成内容的检测与拦截机制。第三点,其流量处理能力存在短板,尤其是串口网关在处理带有情绪响应的流式body时显得力不从心。特别是在用户进行了自定义扩展机制的情况下,这种流量处理能力的不足会变得更加明显。
AI网关具备三层功能。第一层,作为入口流量网关,它主要解决长连接、大报文处理以及配置热更新的问题,并对外提供API接口和开放平台服务。第二层和第三层功能,则是我们认为在AI时代网关应当额外增加的重要功能。
而在AI Proxy这一层,我们解决的是统一协议的问题。用户在构建AI应用时,如前文所示,会面临众多大模型的选择。通常情况下,用户会涉及使用多个大模型。虽然目前业界的主流标准倾向于OpenAI的协议,但每个大模型之间的协议实际上都存在细微的差异。如果开发者需要接入不同的大模型,而每次都需要为每个大模型单独进行适配,这将大大增加开发成本。因此,我们在网关这一层实现了协议的统一,以降低开发者的适配难度和成本。
紧接着的另一个问题是,每个大模型都有一套独特的身份认证机制,API Key的格式也可能各不相同。显然,我们不能要求进入网关的每个请求都携带不同格式的API密钥。因此,在AI Proxy这一层,网关会进行统一的身份认证处理,屏蔽掉每个大模型特有的身份认证方式。而网关会实施一层统一的身份认证机制,并且支持在网络层面配置不同的消费者。然后基于这些不同的消费者,我们可以为他们分别设置限流、限额措施,以及针对AI流量的安全防护能力和可观测性。
最后一层功能是对模型的负载均衡处理。除了常规的负载均衡之外,我们还特别实现了模型的fallback机制。由于大模型在调用时的失败率相对较高,因此我们可以先设置一个首选的、性能较好的大模型。当调用该首选模型失败时,通过fall back机制,可以自动切换到另一个兜底的大模型进行处理。这样的处理方式远比直接返回给用户错误响应的体验要好得多。
还有一个功能是提供模型灰度发布的能力。对于大模型厂商而言,在发布新版本模型时,可以先进行AB test。具体而言,就是将不同的用户群体分配到两个不同的模型上,以观察并对比这两个模型在性能指标等方面的表现。
接下来,我将详细阐述S在AI领域所做的具体工作。第一部分,关于如何应对AI流量带来的挑战,特别是大报文、长连接以及高延迟问题。第二部分,我会讲述如何扩展AI应用能力,以协助用户迅速构建AI应用。第三部分,将介绍一些AI在gress应用中的场景,包括在内部的实践落地以及外部客户的案例。
那么网关是如何实现长连接无损热更新的呢?首先,我们采用的是数据面与控制面分离的架构。控制面负责处理所有配置更新的计算,并将更新后的配置下发给数据面。数据面在更新配置时,通过标准化的配置协议,如LDS、CDS、RDS、SDS等进行操作。这样,当我们需要修改配置时,只需针对相应的部分进行修改,从而最小化配置的改动,避免引发不必要的影响。另一个无法避免的问题是网关升级时的处理。在网关升级过程中,重启Pod是在所难免的。那么,如何确保在此过程中长连接不被中断呢?我们为此引入了一个优雅退出的机制。当存在长连接时,用户可以根据需要调整优雅退出的时间。通常,大模型的一条长连接维持时间较短,最长也不过几分钟到几十分钟不等。通过调整优雅退出的时间,可以适当延长旧Pod的存活时长。在升级过程中,新来的请求会被路由到新的Pod上处理,而旧Pod则会继续处理其上的所有连接请求,直至全部处理完毕后才被释放。这样,即便是在升级过程中,也能确保长连接的无损维持。
第二点是我们安全网关的核心能力。左上角展示的是传统限流方案,比如基于QPS的全局限流,以及按每秒、每分钟、每小时、每天等不同时间粒度进行的限流,或者基于HTTP 的header和请求参数进行的限流。然而,仅依靠这些传统方案显然无法满足AI场景下的安全防护需求。由于大模型与传统请求在调用方式上存在差异,我们特别引入了一个面向token的限流机制。这种机制不仅支持全局限流,还可以根据不同时间粒度进行限流,并且支持基于header、param等多种维度的限流。更重要的是,我们的token限流能够实现完全流失处理,从而更准确地量化大模型处理的数据量。
还有一项关键能力是CC防护。由于前面已经提到,大模型的RT相对较高,因此当面临攻击时,大模型应用会显得更加脆弱。为了应对这一挑战,我们可以一键接入阿里云WAF安全防护产品。阿里云WAF在安全防护领域已经深耕多年,对于CC攻击具有非常高效的处理能力。
此外,网关本身还提供了一些基于IP维度、Cookie维度等的保护式限流措施。除了七层限流之外,网关还额外提供了四层的限流功能。这意味着,如果在七层建立连接后再进行限流,可能会已经消耗了网关的部分资源。而四层限流的优势在于,它能在连接尚未建立之时就直接进行限制,从而有效避免了对网关资源的无谓消耗。
最后一点,我认为在AI时代,对于AI请求而言,内容安全是至关重要的。前段时间,如果大家有关注这一领域的话,应该已经注意到一些国内企业因为AI助手回答了错误信息,而导致股价下跌的新闻。因此,在国内环境下,内容安全显得尤为重要。
HighGrass已经与阿里云的内容安全服务进行了对接。阿里云的内容安全解决方案是阿里内部基于多年来在电商等多种场景下的经验积累而打造的,能够针对视频、文本、图像、语音等多种形式的AI数据进行安全防护处理。如果检测结果发现问题,我们可以在网关层面直接对内容进行封禁。值得一提的是,阿里云的内容安全服务已经通过了信通院的认证,这为使用者提供了更加可靠的保障,让使用者可以更加放心。
接下来会谈谈HighGrass在流失处理方面的努力。一方面,我们前面提到的AI方面的token限流、AI可观测性以及AI内容安全等功能,都是基于插件形式实现的,并且完全支持流式处理。这些插件之所以能够实现流失处理的底层支持,得益于我们提供的可扩展机制的SDK。该SDK内置了流失处理接口,因此,如果网关用户有自定义扩展的需求,可以调用SDK中的流失处理接口来实现自己的业务逻辑。通过这种方式,不仅满足了用户的个性化需求,而且对网关的内存消耗没有任何影响,真正实现了完全流式处理。
这张图展示了我们在AI领域所提供的整体能力概览。我们预期,最左侧的是客户端,客户端通过一种统一的访问协议连接到网关,像Open AI的业界实际标准一样。在网关这一端,我们提供了多个插件集合。首先,它可能会经过AI开发插件集。接下来,我将逐一为大家介绍这些插件集的具体内容。
首先,我来介绍一下多模型适配这一环节。HiGress AI网关主要解决了大模型流量的代理问题。目前,我们已经支持接入了二十多个大模型,这些模型涵盖了国内外主流的一些通用大模型,左上角列出了一部分。在AI代理插件中,我们可以进行模型的协议转换,以及从事fall back逻辑。在解决了模型的统一接入问题之后,我们提供了安全防护功能。安全防护分为内容安全防护、脱敏限流、配额管理,以及对后端服务的保护式限流等多种安全防护功能。
然后,最左侧的是开发插件集,其中最上面的插件是缓存。缓存的应用场景主要适用于企业内部的一些答疑机器人等场景,在这些场景中,用户可能会反复提出相同的问题。此时,如果采用缓存机制,可以基于问题本身或问题的语义进行缓存。这样一来,当类似的问题再次出现时,系统就可以直接返回缓存中的答案,从而有效降低RT,并减少对于token的消耗,进而节省成本。
第二个是提示词模板与提示词装饰器。这一功能针对到达网关的请求,网关会统一对提示词进行改进,以辅助大模型获得更佳的回答效果。接下来是请求转换与响应处理,它基于大模型进行智能的请求与响应转换。此外,向量检索功能能够与阿里云向量检索服务对接,为大模型注入额外的信息。稍后,我们将通过一个例子来演示这些功能的具体使用方法。
在可观测性方面,我们提供了一个AI统计插件。该插件实现了在日志监控和链路追踪这两大方面的可观测数据投送,能够分别对接阿里云的日志服务和云监控服务。用户可以在日志服务和云监控平台上进行数据的报表设计,以及配置告警等功能。
最后,我们意识到尽管提供了一系列插件,但用户可能仍有其个性化的需求。为了降低用户开发插件的门槛,我们在产品中集成了一个Web IDE。在这个Web IDE中,用户只需即点即用,打开后即可看到一个预配置好的开发环境。用户只需专注于编写代码,而编译与调试工作则由我们负责解决。完成编译调试后,用户可以一键将VSM插件上传至网关,从而快速验证自己的业务逻辑。
接下来,我将介绍HiGress常见的业务应用场景。其主要存在两种场景:第一种是HiGress作为大模型的接入层网关;第二种是AI应用开发者利用HiGress提供的AI能力,快速开发一个AI原生的应用。
对于大模型接入层网关这一场景,它主要面向大模型厂商的需求。通常,这一需求涉及的功能包括大模型之间的负载均衡、fall back、灰度流量分发以及观测功能,这些功能便于进行AB测试。此外,还提供了长连接支持以及无损的热更新机制。在用户升级网关或修改配置时,对于大模型厂商的用户而言,他们的体验并不会受到影响。典型的用户包括灵异万物。
第二种场景是AI应用网关。以企业客服机器人为例,开发者可以利用AI网关提供的各项功能,如改进提示词、增强内容检索能力,以及加强内容安全防护等。同时,通过token限流机制,以及可观测性统计每个消费者的top用量,从而使开发者能够更有效地进行成本管控。
然后,我列举了两个典型用户,一个是郑坤航,另一个是国泰产险。郑坤航是一家工业互联网公司,他们主要应用的场景是模型的request/response处理以及后备方案fall back。他们拥有自建的大模型,当流量到来时,会首先请求自己的大模型。如果请求失败,则会启用后备方案,将请求转向fall back到fall back,或fall back 到千万,fall back到豆包等国内的大模型进行处理。此外,他们还应用了AI缓存的场景。
而国泰产险则主要应用于内容安全领域,因为他们会对外提供咨询服务,所以在内容安全和可观测性方面使用了较多的功能。内容安全功能是通过我们的插件来实现的,同时他们也希望能在统一的内容安全检测服务基础上,针对自己的业务进行细粒度的调整,而我们也支持这一功能。在可观测性方面,他们在网关上实施了统一的认证鉴权,为每个服务消费者颁发身份标识。随后,基于这些身份信息,他们会追踪每个消费者token的使用情况,以及请求是否触发了内容安全的风险检测,这些数据可用于内部审计。
除了外部客户,HiGress内部也有一些实际落地的应用场景。首先是通义千问的APP,该APP后端正是通过HiGress网关进行服务的。在这个场景中,主要利用了HiGress的长连接支持、无损热更新能力,以及高效的流式传输功能。同时,也充分利用了HiGress提供的丰富安全防护措施,如token限流等。
除了上述C端应用外,我想了解一下在座的各位是否了解灵玑和派灵机。它们实际上是通义千问大模型的API提供方,以及像百炼这样的应用也接入了HiGress作为流量网关。另外,派灵机还是一个人工智能模型的训练及推理平台,用户可以在上面便捷地进行模型的训练、微调,并实现一键部署。
在这里,HiGress解决了一个关键问题。由于派灵机采用的是多租共享集群模式,因此用户数众多,导致ingress数量庞大,路由和域名规模也十分巨大,最多时达到了三万多条。之前,在运维网关和进行发布变更时,网关配置的生效速度非常慢。但在切换到HiGress之后,路由配置的生效时间从十分钟缩短到了30秒内。此外,借助HiGress完善的可观测体系,派灵机还能够进行自定义的观测和分析。
最后是一个实践案例,该案例展示了如何基于HiGress快速构建一个钉钉答疑机器人。为了更直观地了解这个过程,我为大家准备了一个视频,大家可以观看一下。当然,我也会现场为大家讲解一下这个案例。
根据视频的节奏,我们来看看钉钉答疑机器人的实践案例。这个案例主要利用了HiGress提供的插件集,展示了一个通用的架构。首先,通过AI Proxy接入不同的大模型,在这个例子中,我们使用的是通义千问。接着,通过AI Reg插件与阿里云的DashVector向量数据库对接,进行知识增强。在架构图中,前面还展示了其他的一些Optional Plugins,用户可以根据自己的需求进行增减。在流程的开始部分,有一个自定义查询模块,它负责将消息格式转换为OpenAI兼容的格式。
首先实现的是一个最基础的功能,即通过钉钉机器人能够与大模型进行对话。在这个过程中,我们只使用了一个A插件,用于将钉钉的消息格式转换为OpenAI的格式,这个过程相对简单。这里有几个例子来说明,从钉钉接收到的请求,如左上角所示,会被转换成OpenAI的格式。而对于响应,则是将OpenAI的响应转换回钉钉能够接受的格式。
而在创建一个实例后,会生成一个NRP地址。基于这个地址,我们会进一步创建一个域名。域名创建完成后,需要建立一个Dash服务,这个服务是用来调用通义千问的。服务创建好之后,还会设置一个路由,这个路由是用于钉钉访问的。但需要注意的是,此时创建的路由还不能直接使用,因为协议格式存在差异。
接下来,我们将进行AR代理插件的配置。在这个配置环节,我们可以设置模型的映射规则,其具体含义是无论请求指向OpenAI的哪个模型,都会被重定向到“千万max”这个模型上。配置完成后,此时就已经可以通过钉钉访问大模型了。为了实现这一点,还需要添加一个钉钉机器人,并配置一个出口IP地址段。这是因为钉钉本身有一些安全限制,需要指定特定的IP地址段才能进行通信。在“auto going”中,填写的POST地址应该是网关对应的路由地址。最后,当我们与这个钉钉机器人进行对话时,就可以直接与大模型进行交互了。
之后我们将进行额外的知识注入,并通过提示词修改插件来优化提示词,以便大模型能够返回更加符合预期的答案。首先,我准备了一份关于网关常见问题的QA文档,为了方便处理,我将其整理成了G40格式。此外,我还编写了一个简单的脚本,该脚本包含两个主要函数。第一个函数用于调用通义千问,以获取词向量。关于这些代码的示例,我们有一个详细的实践文档,里面包含了整个流程。稍后我会在群里分享这个文档,大家可以很方便地试用一下。第二个函数则是将获取到的词向量上传到阿里云的内容检索服务中,以构建一个知识库。
这是内容检索服务的界面。从界面中可以看到,向量数量是基于55个QA文档的。度量方式采用的是余弦相似度。在这里,我们可以预览向量数据,即看到我们上传的QA内容以及对应的向量表示。
配置完成后,接下来需要配置一个名为“that market”的服务,通过这个服务可以访问向量检索服务。这里的配置是一个DNS类型的服务。配置好“that market”服务后,我们需要进一步配置AR rag插件,不过具体的配置细节在此可以先跳过。在配置AR rag插件时,主要涉及两个服务:向量数据库和通义千问。向量数据库用于词向量化,而通义千问则用于检索额外注入的文档。配置完成后,还需要安装一个提示词修改工具,该工具会指导如何使用检索到的额外文档。此时,我们可以来体验一下加入了额外知识注入后的钉钉答疑机器人的效果。
首先,我们向机器人提出了一个简单的问题,即支持多少个自定义插件。机器人的回答非常精确,明确指出只能支持五个自定义插件。
接着,我们又问了一个稍微复杂一点的问题,由于回答的长度较长,所以RT稍微高了一些。从回答效果来看,大模型根据检索的文档,从两个方面进行了讨论,这两方面的原因都与我们的预期相符。此外,回答中还给出了具体的操作步骤,并建议除了已使用的插件外,还可以加入一些可观测性插件。加入这些插件后,我们就可以查看到一些日志和监控指标的产生,这对于系统的运维和观测将非常有帮助。同时,我们也可以考虑加入内容安全插件。通过加入内容安全插件,可以确保钉钉机器人的回答内容是合规的,符合相关规定和要求。此外,我们还可以额外添加一个token限流插件。这个插件可以限制每个用户可以使用的token数量,或者每秒可以调用的请求数量,从而有效控制资源的分配和使用。
以上就是整个演示过程的概述。左侧群聊是我们第一位讲师所提及的Spring AI与阿里巴巴的交流群,而右侧则是HiGress的交流群。我们诚挚地邀请大家加入这些群聊,与我们进行更多的交流与探讨。
06. 问答
问题:我看前面有一个报文比较大,它是怎么解决的呢?
回答:它主要是通过流失处理机制来解决的。无论是网关自身的底层机制,还是基于N沃构建的底层网关,由于N沃是用C++编写的,因此对于处理大报文可能会导致流失的请求,其处理速度是非常高效的。然后,我们还考虑到了用户可能会编写一些自定义插件。这些自定义插件在处理大报文时,默认会处理所有报文。如果此时请求量较大,网关的内存使用会有明显的增加。为了解决这个问题,我们提供了一个流失处理接口。通过这个接口,用户可以实现一个完全自定义的流失处理插件,而且这个插件是用Go语言编写的,开发起来非常方便,同时也能保证性能。