每一个大模型应用都需要一个 AI 网关|场景和能力

本文涉及的产品
函数计算FC,每月15万CU 3个月
日志服务 SLS,月写入数据量 50GB 1个月
内容审核增强版开发者实践包,10万次资源包1年有效
简介: 本次分享的主题是每一个大模型应用都需要一个 AI 网关|场景和能力。由 API 网关产品经理张裕(子丑)进行分享。主要分为三个部分:1. 企业应用 AI 场景面临的挑战2. AI 网关的产品方案3. AI 网关的场景演示

每一个大模型应用都需要一个 AI 网关|场景和能力


内容分析:

1. 企业应用 AI 场景面临的挑战

2. AI 网关的产品方案

3. AI 网关的场景演示

 

今天分享的主题是 AI 网关的产品方案,我是 AI 网关产品经理,我叫张裕,今天由我给大家做部分的介绍。

image.png

今天要介绍的内容分为三个部分。首先、我们概要地介绍一下企业应用 AI 场景面临的挑战。第二、我们会简单的介绍一下 AI 网关的产品方案以及我们背后的设计思想。第三、我们会基于第二部分介绍的产品方案以一个具体的场景来进行演示。

image.png

 

01. 企业应用 AI 场景面临的挑战

首先我们简单的介绍一下企业应用 AI 场景时所面临的挑战。

image.png

上图描绘了一个企业利用大模型 API 的场景,其中企业既拥有 AI应用,也拥有普通应用。企业的开发者及其他人员可直接调用如百炼等各大模型服务。在此场景下,调用的链路呈现出多对多的复杂形态,使得企业管理者难以从单一入口全面监控和管理整个调用流程及现状。这种复杂性引发了几个关键问题:

首要问题是集成成本高昂。各大模型供应商,包括百炼在内,其接口设计并非统一标准,接口差异导致访问方式各异,LLM API 间难以无缝切换。例如,AI 应用在调用百炼 API 与另一 LLM 服务模型 API时,需根据接口差异进行适应性调整。因此,接口的非标准化阻碍了应用在不同供应商间的灵活切换与并行使用。

第二个显著问题是 AI 管理的复杂性加大。企业在应用 AI 时,各场景下的优先级差异显著。高优先级调用应获优先处理,而低优先级请求则需适当限制。然而,在上述场景中,难以实现对大模型使用者的精细化权限管理与资源控制,也难以针对不同使用场景灵活采用不同模型和策略。这导致企业 IT 基础设施管理者在 AI 管理方面缺乏有效的手段。

更为严峻的是安全风险问题。企业在调用 LLM API 时,需遵循两项基本原则:一是遵守国家及政府的合规要求,二是确保企业内部数据的安全。若各应用及开发者自行调用大模型服务,则极易引发内部数据泄露风险,并可能触及数据合规红线。

最后,接口稳定性不足也是一大挑战。大模型服务因限流或自身稳定性因素,其接口的响应时间(RT)和成功率均不够稳定。一旦大模型服务出现故障,依赖其的 AI 应用也将受到可用性影响。

综上所述,这四个问题构成了当前企业在使用大模型 API 时所面临的主要挑战。

image.png

所以在这个情况下,我们认为企业应该引入一个叫 AI 网关的产品来在中间充当企业应用和开发者与大模型服务之间的桥梁。这个图是我们认为作为企业来讲一个非常典型的两层网关的一个架构。

image.png

首先作为任何的一个业务的流量,不管是普通的应用还是 AI 应用,它都要在前面有一个统一的网关去做防护,在这一层去解决掉证书、协议的支持以及一些全局的认证和安全等方面的诉求。而在 AI 应用和开发者以及大模型服务之间,我们认为应该引入一个 AI 网关,在 AI 网关上统一的处理掉背后的各个大模型供应商,并且在 AI 网关上进行像内容安全、限流、观测等等这样的 AI 应用的治理。于是经过这样两层网关之后,那么企业所访问 AI 的服务的时候,它其实都会有统一的 AI 网关来承载,而它对应的协议和地址也就固定下来了。那么通过 AI 网关可以同时承载不同的模型服务,而对于应用来讲是可以无感知的。

image.png

在过去的一年我们的 API 网关依靠插件的方式提供了丰富的一个插件机制来帮助企业进行插件的方式形成 AI 网关的解决方案。在这个方案里面我们用了各种各样的插件集来解决掉企业进行 AI 的模型适配、 AI 的观测、安全防护等等各方面的诉求。在这个方案里面作为 AI 服务的调用者,其实看到的还是一个 API ,在这个 API 之上开启了很多的插件,通过这个插件与背后的大模型以及相应数据库和内容审核等等的服务进行连接。这个方案就是帮助很多的企业从零开始构建了自己的 AI 网关。

image.png

然而,这一方案本身也伴随着一些问题,我们主要将其归纳为两点。首先,插件的配置与维护成本相当高。由于所有功能均以插件形式实现,整个插件的配置依赖于 Yaml 格式,并且插件还涉及执行顺序等复杂问题。一旦出现问题,定位和排查的难度极大。

其次,该方案的集成与使用体验并不理想。从产品形态上看,它并未针对大模型的使用场景进行优化。因此,在 AI 场景下,用户所接触到的仍然是普通 API 的概念和使用方式。这导致用户难以将实际 AI场景中的概念与现有使用方式相对应,不得不学习如何在普通 API框架下构建 AI 场景的应用。这正是我们当前基于 AI 插件解决方案所面临的主要问题,也是促使我们下定决心开发 AI 网关的初衷。

 

02. AI 网关的产品方案

  image.png

我们 AI 网关的产品方案又是什么样子呢?简单来说,我们认为 AI 网关其实相当于引入了一个新的 API 类型,叫 AI API 和一个新的服务类型 AI 服务。我们通过在现有的模型之上去扩展这两种类型来支撑了 AI 网关的整个诉求。

image.png

对于企业开发者或 AI 应用而言,所有请求都将首先通过 AI 网关。AI 网关以 API 的形式对外提供服务,这些API经过统一的认证鉴权等策略后,接入到 AI 服务中。在AI服务内部,会处理服务的接入、API 密钥的管理、负载均衡以及故障转移(Fallback)等相关策略。同时,AI API 可以外挂多种内置策略和插件,如缓存、令牌限流、内容安全等。

通过这种方式,AI服务能够连接到不同的大模型服务,如阿里云的通义千问(基于百炼技术)、OpenAI ,以及我们基于 Llama 自建的大模型服务。我们的策略和插件又依赖于众多阿里云内部和外部的服务,如 SLS、Redis、内容安全等。

这一架构为企业提供了一个统一的AI访问入口,并实现了统一管理。所有AI请求都通过 AI 网关进行传输,我们可以在网关上执行统一的大模型服务管理、认证鉴权、安全防护和监控观测等操作。同时,AI 网关内置了 API 密钥管理、负载均衡和故障转移等能力,使得其提供的服务相比直接使用 LLM API 具有更高的可用性。此外,AI 网关的多可用区部署也进一步提升了整体大模型服务的可用性。

第三,我们能够帮助企业实现更高效的成本控制。这主要分为两个方面:一方面,我们可以根据不同的请求和特征实施精细的限流策略;另一方面,我们可以与缓存或 RAG等集成,使高频问题直接命中缓存,而无需调用大模型服务。这样,在提升响应效率的同时,我们可以有效减少大模型服务的调用次数,进而降低整个 AI 相关的成本。

 

03. AI 网关的场景演示

  image.png

接下来就以一个场景来给大家做一个演示。在一个实际的场景中,我们是怎么用 AI 网关来做到企业大模型服务统一的入口和治理中心的目的。

image.png

这是我们整体场景的描述。对于企业开发者或应用而言,所有请求的入口都集中在 AI 网关上。AI网关背后连接着三个模型:阿里云百炼、Azure OpenAI ,以及我们基于 Llama 自建的开源模型。

我们系统支持根据模型名称自动进行负载路由。具体而言,当模型名称以“Qwen-”开头时,请求将被导向阿里云百炼的模型;若模型名称以“gpt-”开头,则请求会被发送到 Azure OpenAI 。若这两个模型出现可用性问题,系统将自动回退到我们在函数计算平台上自建的开源模型上。

在请求大模型之前,我们会引入 AI 安全能力,通过与内容安全服务的对接,确保敏感信息和安全屋数据不会直接暴露给大模型 API 。同时,我们还会外接 AI 观测、限流和缓存等能力,以确保整个 AI 处理过程可追溯、可控制、可治理。其中,缓存功能能够显著加速高频请求的处理速度。

这三个服务又依赖于阿里云的其他服务,如 SLS(日志服务)和 Redis(缓存服务)。我们将逐步实现这一场景。

首先,我们从最简单的场景入手,即引入一个 AI API 网关,并使其能够支持两个不同的大模型服务,根据模型名称进行路由。

image.png

进入到云原生 API 网关的控制台,点击API,在这里可以去创建一个 AI API。

image.png

给API 起名字并且可以选择调用的一个域名和一个具体的实例环境。

image.png

如果我们没有创建过实例需要先创建一个实例。默认的情况下 AI 请求观测就是处于开启的状态。

image.png

在这里选择我们背后的大模型的服务,并支持三种类型的模型服务调用。

image.png

首先是针对单个模型的服务,其次是针对多模型服务根据模型名称去路由的,第三是根据比例去路由的。

image.png

这里我们从最简单的场景开始,即创建一个单模型服务的实例。我已经提前配置好了三个大模型的服务,分别连接到了 Qwen、OpenAI和 Llama 。现在,我们直接选择 Qwen ,并点击确定。随后,API会进入发布状态,待发布完成后即可使用。

为了实际查看一下效果,我们可以点击这里的调试按钮。

image.png

在这里,我们可以选择是使用域环境的默认域名,还是使用我们刚刚自定义配置的域名。在模型选择部分,我们可以选定一个对应的模型。例如,如果我们直接提问“你是谁”,通义千问就会给出相应的回复。

image.png

如果在这种情况下,给他请求了一个叫 GPT 的模型的话会发生什么。同样的问你是谁,这时他告诉我返回了一个400的 Code ,因为我们通义千问并不支持请求 gpt-4o-mini 的一个模型。

image.png

我们可以在“原始输出”部分查看到更多的内容细节,同时,也可以通过“CURL命令”功能,将刚刚的请求以命令行的形式在控制台进行回放操作。

至此,我们已经成功搭建了一个非常简易的AI网关,该网关能够代理请求到通义千问上。此时,可能会有疑问产生:我们在请求过程中并未输入 API key ,那么 API key 的管理是在何处进行的呢?为了解答这一疑问,请大家回到我们的服务页面进行查看。

image.png

我们在创建服务时有一种新的类型叫 AI 服务,在这个服务里面可以选择我们不同的大模型、供应商。

image.png

以百炼为例,在该服务中,我们需要填写 API key ,并且支持填写多个 API key 。当服务被调用时,系统会自动在这些 API key 之间进行轮换使用。因此,对于之前提到的 Qwen ,我们的 API key 其实是在这里进行配置的。

image.png

如果你后续 API key有变更,也可以直接更新这里就可以了。

  image.png

接下来修改一下我们的 AI API,我们需要让它同时支持 Qwen的模型和 GPT 的模型。这时我们会改成多模型服务,按模型名称这种方式。

image.png

首先我们先选择 Qwen ,我们认为对于 Qwen-*的模型的调用都应该转发给 Qwen ,同时我们选择 Azure ,我们认为所有对 gpt-* 的调用都应该传给 Azure 。这个时候点击一个确定。我们再来调试界面去看一下。同样的我们还是拿刚刚的“你是谁来看一下它回复的是什么。

image.png

当我们选择模型为 Qwen-max 时,模型返回的回复表明它是 Qwen 。为了避免混淆,我们清空当前会话,然后请求 gpt-4o-mini 模型,并再次提问“你是谁”,此时它回复说“我是一个人工智能助手”。

image.png

接着,我们具体询问“谁创造了你”。回答指出这是由 OpenAI 开发的人工智能,由此我们可以确认,此时已经成功调用了 Azure 的大模型接口,而非 Qwen 。

image.png

所以通过这个方式我们就实现了根据不同的模型去路由到不同的大模型供应商的效果。

image.png

这也就是我们第一阶段(Phase-1)所要实现的效果。此时,我们拥有了一个统一的 AI 网关,能够根据不同的模型路由到不同的 API供应商。

接下来,我们会进一步增强其功能,特别是在这一步中,我们将增加观测和安全的能力。重点来关注一下安全能力是如何被引入的,以及如何让我们的 AI 请求得到安全防护。

image.png

点击这里的策略与插件,在这个里面有三个预制的策略,我们可以把他开启。

image.png

比如说第一个是内容安全防护,它要求我们有内容安全的服务权限。当我们开启之后,这里面会有一个防护服务的地址,我们建议大家选用 VPC 的地址, 跟我们的 Region 相同。比如说我这里是个上海,那我用的是上海 Region 的地址。

我们可以选择是检查请求内容、检查响应内容,还是两者都进行检查。通常情况下,为了保持流畅性,我们一般会仅检查请求内容。如果开启对响应的检查,大模型的回答就会从流式处理(流式传输)变为非流式处理。这里有一个防护等级的选项,我们提供了四级防护:低、中、高和观察模式。如果选择观察模式,系统不会进行任何拦截,而是会将所有可能带有风险的请求都检测并记录下来。我们这里选择低等级,即仅拦截高风险的请求。此时,我们的API正在进行发布,发布完成后,我们可以点击调试进行测试。

我们先尝试输入一段文字,比如,如果我们在内容安全防护中设置了限制,禁止出现涉及宗教的词语,那么当我请求讲一个佛经故事时,理论上系统应该能够识别出这个请求的风险并进行相应的处理,比如拒绝回答或给出提示信息(但根据当前设置,它可能会仅记录而不拦截,因为我们选择的是低等级防护)。

image.png

我们再来批判一下,这时我们发现他被我们的内容安全给挡住了。

  image.png

系统提示我们,作为AI助手,它不能提供涉及政治、宗教等相关信息。在这种情况下,由于整个安全防护机制的存在,我们可以确保那些我们认为敏感的、涉及政治或宗教的信息不会流传到大模型的API上,从而避免合规性风险。同时,为了保障我们企业自身的内容安全,我也在这里设置了一个限制,即有一些特定的词汇是不能够传递给大模型的。例如,有一个特定词汇叫“打卤面”,它就被列入了限制传递的词汇列表中。

image.png

如果我提问如何制作这道面,在通常情况下,大模型会直接返回打卤面的制作方法。但是,由于我在内容安全设置中做了相应的防护,所以此时它会直接告诉我它不能回答这个问题。我们可以进行一下测试,如果我关闭内容安全防护功能,看它是否能够正常响应并给出打卤面的做法。

image.png

我们来试一下。我们看到模型在返回了,告诉我们打卤面该怎么做,然后具体把步骤都一个个列出来。

image.png

我们来看一下到底内容安全防护背后是怎么样去配置的,我们来实际的看一下它的使用情况。

image.png

我们进入到阿里云内容安全防护的产品里。

image.png

在内容安全的产品控制台我们可以看到 AIGC 场景整个的检测的情况。

image.png

我们点击 AIGC 场景的一个规则配置,可以看到在这个时候大语言模型输入文字检测的状态是在使用中,其实我们是可以去编辑它的相关的一些规则的。

比如说涉及到宗教相关内容的检测是否开启。刚刚为什么打卤面会被拦截呢?是因为这里面我们设置了一个词库,用于命中的词库,这个词库我们叫它敏感词。敏感词有什么呢,可以看一下在这个敏感词里面我们自己加了两个敏感词。

image.png

所以当我输入的内容里面包含这两个敏感词的时候,它就会被拦截掉。

image.png

我们可以在这个结果查询里面看到,整个内容安全的防护情况。比如说打卤面怎么做呀,他就告诉我他被拦截掉了,并且是一个 Customize 拦截的方式。所以这个就是我们整个安全的基本的防护的机制。到这里就是我们整个内容安全的集成。我们再把它打开,这个时候肯定有同学在疑问,刚刚我们还说到有一个可观测,那这个可观测的部分是怎么进去的。我们对于 AI 的大模型调用的可观测和普通的可观测有什么差别。

image.png

从实践上来讲,它最大的差别在于是对于 AI 的可观测,其实我们要去把 AI 的 Body 中的部分也去记录下来并且去做一定的相关的统计。比如说对 Token 的统计等等这样一些统计。所以看到在这个简单的一个统计报表里边我们可以看到在这段时间里我们输入的 Token 的情况以及我们整个首包 RT 的时间。

image.png

在日志这个地方我们可以看到,在中间我们都请求了哪些问题,并且是以什么样的形式去返回的,在这里面我们就可以做一个相关的审计。相对于普通的网关的质来讲,治理的 AI 的场景下,我们的日志记录会更多一点。

image.png

这个就是我们 Phase-2 的部分,这部分的时候,我们在这里借助阿里云的内容安全和 SLS 产品实现了 AI 的安全检测以及 AI 的观测能力。

为了提升我们 AI API 的整体稳定性,并确保在实际使用过程中重点应用的可用性,同时降低时延并提高 AI API 的调用成功率,我们会采取更多措施。例如,我们会提供 Fallback 模型的能力。当我们的主要模型,如百炼或 OpenAI 的模型无法使用时,能够 Fallback 到我们自建的开源模型上,从而避免 AI 应用调用完全不可用的情况。此外,我们也会针对特定请求实施限流策略,并希望对于高频问题能够进行缓存。这样,我们就可以引入 Fallback 、限流和缓存的功能。接下来,我们具体看看如何在我们的场景中进行配置。

首先,我们先配置一个 AI 请求的 Fallback 机制。

image.png

关于这个 Fallback 机制,大家可以在 AI API 的编辑界面中找到相应的配置。在这里,我们可以将请求 Fallback 到一个 OLlama 模型上,具体地,我们可以指定在 OLlama 上所使用的模型为 Llama 3:8b ,并填入相应的模型名称。配置完成后进行发布,随后我们依然先进行调试,以 Qwen-Max 为例。此时,如果我们提问“你是谁”,Qwen 会直接回答他是 Qwen 等相关内容,这说明 Qwen 此时是可用的。为了测试 Fallback 机制是否生效,我们可以故意修改Qwen 的 API key ,比如在其后添加一个字符,使其失效。

image.png

在这种情况下,我们再次发起请求“你是谁”,来看看会发生什么。

我们注意到,这次的请求运行时间明显比刚才要长。趁着这个时间,我们可以来了解一下背后的自建模型是如何运行的。实际上,我们在函数计算 3.0 上配置了一个运行 OLlama 模型的函数。在这个配置中,我们直接采用了 VPC 访问方式,通过这种方式,我们利用 API 网关将整个服务作为唯一的对外接口进行暴露。

image.png

此时,系统提示我们是由 Llama3:8b 回复的,也就是说,我们的Qwen 请求已经成功 Fallback 到了自建的 OLlama 模型上。接下来,我们来看一下这个模型的配置情况。在大模型供应商选项中,它选择的是“自定义AI”,服务地址则是我们之前看到的VPC中的一个函数计算(FC)地址。这里的 API key 字段为空,因为不需要填写API key。

现在,我们将刚才故意添加的字符删除,并再次请求 Qwen ,看看它是否已经恢复正常工作。

image.png

此时,Qwen 已经恢复正常,我们的请求将不会再触发 Fallback 机制。至此,我们已经完成了 Fallback 的配置和测试。

接下来,我们来看一下限流和缓存的开启和使用方法。首先,我们来看限流。限流和缓存的一个共同特点是它们都依赖于 Redis 服务。我们直接使用云上的 Redis 服务,并获取其地址和端口。接下来,我们需要配置限流策略。例如,我们可以按照 Header 进行限流,具体地,如果 Uid 这个 Header 的值为 123,则每分钟只允许它发送十个请求(即消耗十个Token)。这样,基本上每次请求都会被拦截(因为Token很快就会被用完)。而对于 Uid 不是 123 的请求,我们可以设置每分钟允许一千个 Token ,这样它们就可以正常请求和使用。配置完成后,我们保存设置。

现在,我们在请求中添加一个参数,即 Uid 为 123 ,并请求讲一个笑话。

image.png

image.png

image.png

image.png

image.png

image.png

image.png

这时候我们重新再让他讲个笑话,发现他已经被限流拦住了,返回了一个329。

image.png

我们把 Uid 改一下是1234就又可以正常的去返回了。我们重复的再来一次,显然1234没有命中每分钟10次的 Token 的一个限流,而123是命中了。

image.png

通过这个方式把一些非常高频的、重要的一些请求和业务有不同的限流策略。我们再来看一下缓存是怎么回事。

image.png

在 AI 应用场景中,我们经常会遇到一些高频出现的问题。由于每次请求都需要经过大模型 API 处理,这会产生较大的开销。为了解决这一问题,我们可以采取一个简单的缓存策略。通过将高频问题的回答缓存下来,我们可以让请求直接返回缓存中的结果,而无需每次都经过大模型 API 处理。这里的缓存时长我们默认设置为 1800 秒,但大家可以根据实际需求进行调整。现在,我们再次尝试请求讲一个笑话,看看是否能够从缓存中获取结果。

image.png

这个时候他讲了一个笑话。然后我们把这个清掉再讲,看他讲的是不是同一个笑话。

image.png

这个时候我们发现他整个的输入输出变成了0,我们看一下原始的输出。这 ID 变成了 From Cache 说明这个时候他已经命中了缓存。

image.png

然后我们重复的请求讲个笑话。我们发现他始终讲的同一个问题。

image.png

image.png

这个时候我们可以明显的看出整个流式请求在不断的响应,显然它是经过了大模型的处理。

image.png

我们可以观察到,在原始输出中,它的 ID 是一个正常的 ID ,这表明该请求并非从缓存中获取的。为了验证缓存的效果,我们再次请求它讲一个故事。这次,我们可以看到原始输出已经变成了从缓存中获取的结果。

image.png

至此,我们已经对 AI 网关的一些常见特性进行了简单的演示。当请求进入 AI 网关后,所有对模型的请求都会通过AI网关进行转发和路由。在 AI 网关上,我们会实施 AI 安全防护,进行AI观测,并配置限流和缓存策略。同时,当某个服务不可用时,我们会配合一个兜底模型(Fallback)来避免整个 AI 网关服务的不可用。这样,我们就实现了在一开始演示场景中所描述的完整场景。

这就是我们今天演示的全部内容。当然,作为 AI 网关,它其实还具备更多的能力,我们并没有一一介绍。大家可以直接访问我们的 API 网关控制台进行体验和探索。

image.png

这个体验有一个非常便捷的方式,大家可以在创建实例的时候直接勾选上 AI 的这个选项,开启 AI 网关并且在这个里面可以直接的创建一个最简单的 AI API 去体验跟大模型的连接方式,这样可以简化大家整个的配置的过程。

image.png

今天整个的演示和产品方案的介绍就到这里,大家如果有什么问题的可以接下来把问题放出来,我们会在线上做一一的解答。

目录
打赏
0
1
1
0
1007
分享
相关文章
OmAgent:轻松构建在终端设备上运行的 AI 应用,赋能手机、穿戴设备、摄像头等多种设备
OmAgent 是 Om AI 与浙江大学联合开源的多模态语言代理框架,支持多设备连接、高效模型集成,助力开发者快速构建复杂的多模态代理应用。
143 72
OmAgent:轻松构建在终端设备上运行的 AI 应用,赋能手机、穿戴设备、摄像头等多种设备
Baichuan-M1-14B:AI 助力医疗推理,为患者提供专业的建议!百川智能开源业内首个医疗增强大模型,普及医学的新渠道!
Baichuan-M1-14B 是百川智能推出的首个开源医疗增强大模型,专为医疗场景优化,支持多语言、快速推理,具备强大的医疗推理能力和通用能力。
57 16
Baichuan-M1-14B:AI 助力医疗推理,为患者提供专业的建议!百川智能开源业内首个医疗增强大模型,普及医学的新渠道!
VideoChat-Flash:上海AI Lab开源高效处理超长视频的多模态大模型
VideoChat-Flash 是上海人工智能实验室等机构推出的多模态大模型,通过分层压缩技术高效处理长视频,支持长达数小时的视频输入,推理速度提升5-10倍。
33 1
VideoChat-Flash:上海AI Lab开源高效处理超长视频的多模态大模型
OS Copilot——面向未来的AI大模型
阿里云的智能助手`OS Copilot`是一款基于大模型构建的操作系统智能助手,支持自然语言问答、辅助命令执行、系统运维调优等功能。
43 8
OS Copilot——面向未来的AI大模型
微软开源课程!21节课程教你开发生成式 AI 应用所需了解的一切
微软推出的生成式 AI 入门课程,涵盖 21 节课程,帮助开发者快速掌握生成式 AI 应用开发,支持 Python 和 TypeScript 代码示例。
80 14
Chainlit:一个开源的异步Python框架,快速构建生产级对话式 AI 应用
Chainlit 是一个开源的异步 Python 框架,帮助开发者在几分钟内构建可扩展的对话式 AI 或代理应用,支持多种工具和服务集成。
25 9
大模型进化论:AI产业落地将卷向何方?
大模型进化论:AI产业落地将卷向何方?
43 11
Tablestore深度解析:面向AI场景的结构化数据存储最佳实践
《Tablestore深度解析:面向AI场景的结构化数据存储最佳实践》由阿里云专家团队分享,涵盖Tablestore十年发展历程、AI时代多模态数据存储需求、VCU模式优化、向量检索发布及客户最佳实践等内容。Tablestore支持大规模在线数据存储,提供高性价比、高性能和高可用性,特别针对AI场景进行优化,满足结构化与非结构化数据的统一存储和高效检索需求。通过多元化索引和Serverless弹性VCU模式,助力企业实现低成本、灵活扩展的数据管理方案。
45 12
AI实践:智能工单系统的技术逻辑与应用
智能工单系统是企业服务管理的核心工具,通过多渠道接入、自然语言处理等技术,实现工单自动生成、分类和分配。它优化了客户服务流程,提高了效率与透明度,减少了运营成本,提升了客户满意度。系统还依托知识库和机器学习,持续改进处理策略,助力企业在竞争中脱颖而出。
30 5
淘天算法工程师玩转《黑神话》,多模态大模型如何成为天命AI
淘天集团未来生活实验室的算法工程师们以ARPG游戏《黑神话:悟空》为平台,探索多模态大模型(VLM)在仅需纯视觉输入和复杂动作输出场景中的能力边界。他们提出了一种名为VARP的新框架,该框架由动作规划系统和人类引导的轨迹系统组成,成功在90%的简单和中等难度战斗场景中取得胜利。研究展示了VLMs在传统上由强化学习主导的任务中的潜力,并提供了宝贵的人类操作数据集,为未来研究奠定了基础。

热门文章

最新文章

AI助理

你好,我是AI助理

可以解答问题、推荐解决方案等