亚马逊云科技与牧童游戏合作,将生成式AI应用于游戏玩家社区服务

关键字: [亚马逊云科技中国峰会2024, Bedrock, 生成式Ai应用, 玩家社区服务, 舆情分析系统, 辱骂识别系统, 大语言模型优化]

本文字数: 6300, 阅读完需: 32 分钟

导读

在亚马逊云科技中国峰会2024上,李开元分享了牧童游戏与亚马逊云科技合作应用生成式AI的案例。他介绍了牧童游戏如何利用生成式AI进行舆情分析和辱骂识别,提高了运营效率。他还分享了基于Amazon Bedrock和OpenSearch构建生成式AI系统的最佳实践,包括Prompt工程、RAG(检索增强生成)架构、嵌入模型微调和重排序等技术细节,以提高系统的准确性和效率。此外,他还探讨了未来将专家模型与生成式AI相结合的可能性,以期获得更好的性能。

演讲精华

以下是小编为您整理的本次演讲的精华，共6000字，阅读时间大约是30分钟。

非常感谢今天能够站在这里跟大家一起分享我们去年到今年一直在做的这样一个案例。我是来自亚马逊云科技的解决方案架构师李开元。今天看到这么多人在现场我也是比较激动的。我分享的主题是我们去年和牧童游戏一起做的有关于生成式AI的整个合作的一个分享,加上了我们去年的一些实践以及我个人的一些想法。

首先,我们要介绍一下,这个可能现在对于我们这个会场的人来说已经是一个比较大的共识了。这个是Gartner在去年10月10号一篇文章里面说的一句话,就是生成式人工智能也许是这个迄今为止最具颠覆的创新,将影响80%的职业。我对什么时候对这一点有一个比较深的感触的是,因为我发现不管是我的以前的律师朋友们,还是说就是我的律师朋友们,以前有很繁重的这种翻译的工作,然后他们现在已经在尝试一起,因为Google翻译其实在对他们以前这种很专业性的领域来说,可能没有办法做到非常的准确的这样一个表述。而目前他们使用这种大规模模型对他们的工作的辅助是比较大的。更有甚者,其实现在很多初中生、小学生已经开始使用大语言模型来完成自己的学业了,我觉得这是一个相对来说比较大的一个跨越。

然后我也是比较有幸运,比较幸运能够跟我们的牧童游戏从去年一直合作,我们的这整个生成式AI的这个项目到现在。他们是一家在东南亚以及全世界非常成功的一家游戏公司,主营的这个游戏就是我们的这个决胜巅峰,是东南亚的一款国命级游戏。每年S赛就是这个,腾讯就是那个撸撸,结束以后就是在东南亚就办M赛,非常的成功。我去年也看了,然后他们现在的累积下载量已经超过了14亿次,且月活跃用户数已经稳定在了1.1亿以上,这是一个非常大量也是非常成功的一个案例。

在这整个合作的过程中,这个是来自我们的客户也在现场,就是我们的智能张文文老师,牧童的这个人工智能的负责人。然后去年也是一年的时间,非常有幸我们一起能合作,在这个过程中我们也是对这个整个Amazon的这个Bedrock这个功能,这个服务和牧童的整个场景做了一个比较好的一个结合。

今天我们会主要讲到的两个场景: 第一个场景是我们的牧童做的舆情分析的这一整套系统。第二个是他们一个量更大的一个TOC的一个辱骂识别的一个系统。

但是如果说我觉得就是跟牧童合作最幸运的地方,我觉得第一点就是他们是一家很务实的公司。刚刚肖峰老师其实也说过,在做整个生成式AI的时候,或者说所有的技术演进的时候,如果你是拿着锤子找钉子,这是一个很错误的一个思想。而牧童的做法是一开始就找到了一个极小的可以被落地的,能够验证生成式AI的整个ROI的投出就是投入产出比的这样一种场景。

这是最简单的,就是游戏社区,说白了就是用大语言模型去做翻译。我不知道就是之前就是大语言模型出来之前,是不是大家都很诟病,就是Google Translation这样,或者说就是相应的这种翻译服务对吧?我相信全场应该大家以前都用过。现在我想就是大家举个手我看一下,就是有多少人在翻译的场景下是在用生成式AI,并且就是很信任生成式AI的翻译结果的。大胆一点,我们可以做一下互动,还是很多的。我相信一定会比Google Translate或者说类似的这种细粒度的这种系统是要更好的。

我自己想是为什么呢?是因为以前的这种翻译系统,它其实是单一的翻译,它虽然做了很多的这个语义翻译的功能,比如说即使你现在拿着大语言模型的这个翻译结果和这种细粒度的这种算法的这个翻译结果去做比如说NOUS这种语言的这个测试,对比的话,会发现那种翻译系统可能在语义关键词上它会更精准,但是它缺少的是对于语言的情感的识别的这样一个功能,以及说对于整个的这个在语言的进化过程中,我使用这种俚语或者说平替语句的这样一个功能。

第二是啊,比如说我们牧童其实在这个海外服务的人群是非常多的,国家是非常多非常多的,他们使用的语言也很多。那古牧童在以前在很多比如说小语种上面是做了很多自己的,这种积累的效果可能比很多当时的线上的已经在商业化的这种翻译产品还要更好一些。而真正的这个GenAI Translate这样一种功能,特别是Cloud,像支持不管是GPT还是Cloud这种支持这个上百种这种普适性的这种翻译的大语言模型出来以后,应用到这个场景下就起到了非常好的作用。

通过这一点,他们实际上就验证了说诶,大语言模型在我们的实际的工程化的这种场景里面是可以被用的,且有相对来说比较高的ROI,你不用再去做很多很多的工作,它是一个大而全的一个功能。那在验证了这一步以后,这个地方再打个广告,就是这个是我们的客户,正言就是Clonesense,在语言翻译的这个场景下,特别是在小语种的这个表现上有非常明显的优势,这个我们也欢迎,就是我们的这个其他的客户也能够做大量的这种验证的工作,看是否能够验证这一点。

然后在我们做了基本的ROI验证以后,牧童就做了第二件事情,就看这个事情是否能够去做一个中型的这样一个项目,来验证它大语言模型是不是真正能够被放在内部的生产的这种Pipeline里面去。那当时我们这个比较有远见的这个AI团队想到的这个场景其实就是舆情分析。

我自己分析是因为这个,第一它跟之前的翻译的整个系统是隔离不开的,就是说它是一脉相承的。第二是如果说你是运营一款产品,比如说像那个Mobile游戏,我或者说游戏你上线一个皮肤,上线一个玩法,上线一个产品的时候,很难像以前传统的方法,你很难去很快地去获取你的用户的反馈。那在这样一个情况下,你没有办法说第一时间除了你诶看到这个诶可能流水上去了,DAU上去了,这个获客上去了之外,没有办法第一时间能够拿到一个诶,用户到底觉得这个玩法怎么样?用户社群到底觉得这个玩法怎么样?一个很好的一个反馈。

那么如果是比较传统的方式,我们知道就是可能就是做词云,做抽样,基于以前的那种老方式做词云,做抽样。第一它是一种既定的,就是我已经有固定的Metric,我已经有固定的维度去做分析的这样一种方式。第二是他肯定没有办法做这种全量的分析。那我们怎么样能够第一既快,第二做全量不做抽样,第三能够做这种更精细化的分析,那这个就是一种可实现的这种舆情分析的这种解决方案。

这个地方其实分两部分,第一个是这个Step Y,Step A跟Step B,这个就是分类打标,先到这个舆论信息入库的这个部分。第二个就是通过这边去做分析的部分。我想问一下,就是在场我相信这个做技术的同学其实有挺多,我想问一下为什么需要这个左边那个部分,有没有人这个回答一下,我相信大家一定脑子里面有想法,但是我在这说两个场景,就是能够给大家一个解释。第一,我看一天的消息,但是我只想知道我今天上线的这个玩法它好不好用,我是不是最好的方式是把我所有的这个一天的所有的消息里面关于这个玩法的信息筛选出来,然后再做分析,它是最有效的。

因为我们知道大模型这个东西有个东西叫集中度,如果你放的内容太多了,它可能集中不度不够,或者说它会出现一些幻觉,所以说自己本身去做一次过滤是不是效果会更好,这是第一点。

第二点是如果我要分析的不是今天的评论,我要分析的是一个月的评论,一个月对于某个玩法的一个评论,那我如果我不做这样的前面的这个分类入库的这个过程的话,我是不是相当于说要把这一个月的评论全部塞进去?那这本身是一种从成本上很高,从技术上它的精确度也很不够的一种方式。

所以说整个系统分两个部分,第一是通过这个把所有的这个评论,以这个通过这种小模型,就是嗨库我们最便宜的小杯的这个模型做分类打标签的一个形式,入到我们的库里面去做日期,做玩法,你到底是针对于音乐的,还是皮肤的,还是这个英雄本身的,等等等等等等。

然后做了这种细致的入库以后,当我们的用研同学真的要去做相关的分析的时候,就通过我们的模型,我这个地方写的是function call,但是实际的可能大家会用这个ai agent等等方式,我自己比较喜欢就是function code,然后直接去这个elecse search里面把相关的数据调用出来,然后丢给我们更强的这种大模型去做总结分析,能够得到更好的一个结果。

ok,这个是这样一个系统。但是这个对于这个系统,其实今天我在看的时候,我忽然想到一个点,就是我发现说它不仅能够对于,就是我们本身的这个它对于,就是相比起以前的不管是词、语音,还是说以前的这种先验的我们把metric定好的是系统而言,它有一个更好的一个优势是什么呢?

就是其实我们可以在这个分类的时候给它打一个标签,就是对某一些评论打个标签,叫做其他,这个其他里面的标签是我们还没有被还没有想过我们要分析的,我们还没有找到合适的维度去分析它的。那对于这种其他这个标签的所有的评论,我们定期地定时地去做我们大源模型的总结,我们反而可以通过大源模型去总结出一些标签来,这些标签是我们没有发现的,但是可能对我们的游戏玩家确实非常重要的一些信息。那最后我们再把这些标签再丢给我们的这个大模型,再去做一次分类,这个其实是一个优化,但是这个只是我一个脑洞,并没有做这种工程化的验证。

对啊,那这个的话就是一个相对来说比较好的一种这个舆情分析的方式。然后我们亚马逊云科技的这个sa的老师们也自己做了一套基于那个creo ai加agent加这个大模型的一个方式,做了一个从我们主流的应用商店去获取所有的评论,然后去做这个应用的分析的这样一个啊工具。大家可以直接通过下面这个blog去获取这个工具,去分析咱们家的不管是游戏还是任何的应用,都可以有一个比较好的一个,就是可以做一个试用,这个是一个这个系统是完全开源的,然后只是可能需要用那个advice的一些服务,大家可以去对,如果是咱们自己运,再运营一些这个app等等的话可以用到。

ok,那么说到了,在我们上一步认证验证了整个的一个这个内部的这个pipeline是可以走通的一个情况下,我们就走到了最终的一个比较成熟的,也是比较大的一个场景,叫做这个辱骂分析,我不知道就是在场有多少人打过,那个就是这种陌拜游戏手游,陌拜游戏就是社交货币,这个应该很多人都玩过对吧,大家在这个游戏里面被骂的时候是不是觉得也挺惨的,就是特别是这个你之前是就是才新手,就是玩这种游戏的时候,如果这个战场环境相对来说比较恶劣,其实对于这个用户的留存是会有比较大的一个影响的。

但是对于牧童这一家要服务这么多语言的这个用户而言,我们想一下这个工作流,如果你点一个举报以后,你首先要有相应的懂这个语言的人能够去帮你分析这个到底是不是骂人对吧?然后这个肯定是需要在这个我木桶这么大的这个mau muu mau的这样一个情况下,它决定有两点,第一,它需要有足够的专业的人去做这个事情,第二,他即使有足够专业的人去做这个事情,他也没有办法得到一个及时反馈,那可能在我们的这个人员给到这样的反馈的时候,这个用户就已经流失掉了,而这个一定不是我们希望能够看到的。

那最终我们用大模型是否能够加快这个分析的一个这个进度,从而帮助我们的用户留下来,这些用户留存,那这个就是我们的实际的一个操作的一个形式,就是原来是一个比较传统的,就是如果有人举报了以后,先去拿关键词匹配,如果匹配度比较match,可能我们就直接判罚了,那如果说一些不是很确定的部分,我们会给到这个海外的客户团队去做一个这个判断,那如就是如果是判断是骂人的话,我们就直接那个,那这个流程就像我刚才说的,第一人力比较开销比较大,第二,我们还要去维护那个关键词库,而这个关键词库本身可能是比较重运营的,也可能会被污染的比较厉害。

那通过大语言模型的一个方式,大语言模型一个很好的一个问题是要很好的一个点是它是一个足够强大的过滤器,它是一个足够强大的过滤器,而且它可以帮你去判断这个过滤的程度到底是什么样子的。那在这样一个情况下,我们通过大圆去处理以后,把置信度相对来说较高的我们就可以直接做判罚,置信度相对来说较低的我们再给人工,这样的话可以让我们的这个海外团队本身做一个精简,且它相对来说就不那么再需要依赖我们的这样一个运营团队了。

那么在我们实际使用大语言模型的时候,最重要的几个部分,第一步一定是去年所有人在所有的平台上都听到了,到现在为止都听到了一个词叫做prompt engineer,这个点也是让很多人就觉得我是不是真的用不好当模型要去,因为要去学这样一个技术,叫做我们要去写提示词。

那我现在可以告诉大家不太需要了,我们现在其实有很多主流的这种prompt的生成器,它已经能够给大家生成一个大概能够75分可用的这样一个prompt。包括我现在在下面也列了一个网址,这个是也是咱们亚马逊云科技出的一个这个prompt的生成器,可以帮大家把这个prompt的调优时间从以前的可能比如说一个月、两个月的时间,不也没有那么夸张,一个月的时间缩减到就比如说至少是一个周,我们可以对它做一个比较合理的验证。这个也大家也能理解,因为这个prompt的验证是一个很痛苦的一个过程,因为模型是一是概率模型,它不是像以前我们写代码就是0跟一。你改了一个prompt以后,最痛苦的就是你要验证它是否成功,你肯定要走做大量的测试。那像这样一套系统的话,就可以帮我们把你说得很简单一句话,比如说我要把中文翻译成英文,你就把这句话丢进去,它就会给你生成一个看着比较复杂,但是效果非常好的一个prompt,然后你在这个上面再做相对应的修改,这个prompt就可以被你用来做一些这个工程化的尝试了。

那这是第一步,第二步是什么呢?第二步其实就是我们现在非常多人都在谈论的一个词叫做rag,叫rag,其实我觉得rag这个词就是其实是那个新瓶装舅舅舅,我在这个地方就介绍一个,就是我们advice,我目前用在这个文本处理上,我觉得相对来说非常好的一个。这个存储引擎就是我amazon的open search,首先open search它是一个开源项目,然后亚马逊在这个里面的贡献也是数一数二的,它给我感觉最好的一点是它本身就首先它在这个向量化这个引擎这个层面它已经耕耘了将近20年的时间了,且它本身就是一个支持混合召回的,就是关键词召回,加上这个这个我们的向量召回的这样一套系统,基于这个bm25,它能够做到把我们在做这种知识召回的时候,能够把这个精确度做到一个比较好的一个程度,且这个实际召回的时候,如果你不想用bm25或者说这个算法,你可以换成自己的,然后他自己性能也非常强大。我觉得现在最吹黑的一点就是大家盲目地在使用这个这个向量模型,向量数据库的时候,有的时候会遇到很多可用性或者说是这个性能上面的瓶颈,但是这些在这种就是已经做了很多年的传统的这种数据引擎上,其实是早就已经被解决的问题,所以说我非常推荐大家可以去用一下这个数据引擎去做我们的rag。

那实际这套系统是怎么实现的?就这只是一种实现方式,我们可以从左边往右边看。这个系统就是我想的比一个比较完善的系统,就是分三层,第一层是我们的语料数据进来以后先做关键词的过滤,为什么这个地方关键词可能包含两个方面,就第一是运营团队本身给的一些关键词,第二是在就是分地区分国家,有一些关键词就是不能出现在这个地区的,比如说你在某些地区出现了一些政治不正确的词,那肯定是不行的对吧,那有一些地区可能你出现种族的,出现这个这个出现一些这个性别不平等的这种政治不正确的这种内容的时候,它就会被屏蔽掉,这个就是第一层过滤第二层就是到我们的这个基于这个open search的这个库的时候,它做第二层就是我们的这个混合召回,通过关键词加上这个我们的这个向量召回的一个形式,把这一层做一个。就是当语义过来说,我们做一个语义上的相似的一个匹配,如果匹配度达到了一个相对来说比较高的一个程度,他可能就不用再往后走了,他到这一步就已经被判定,然后去做实际的判罚过滤了。第三层就是如果前两者还解决不了,那我们就把这个可能就把这个库里面的信息拿出来作为fewshot丢给我们的prompt,然后丢给大模型去做分析,在这一层我们再去做一判定,然后再做判罚,所以说这是一个三层过滤系统。

但是这个图还有一种看的方向,就是从右往左看,从右往左看这是一套,我觉得这是一套,就是自成长的一套系统,为什么这么说,因为我们可以想象,就是这个例子。其实我讲了,我也讲了很多遍了,我们人脑在思考问题的时候,我们是怎么思考问题的?我们在第一次接触一个事情的时候,我们是先思考,思考过的内容我们会把它变成记忆,第二次遇到这个问题的时候,我们就不思考了。我们就比如说我们思考3+7等于几,大家想一下。10我下次再问这个问题的时候,大家就全记,就把这个东西拎出来了。而被调用多次的知识,就会从记忆变成直觉。

这套系统就是这个思想,我们被大模型已经分析过的内容,我会把它存到rag里面,作为新的记忆去迭代更新,然后当这个库里面,这个rag库里面,这个open search库里面,被频繁召回,被多次召回。比如说某一词,如你出现95%的时候,95%甚至90%的,有的时候这句话就是一句骂人的话,那我们还需要给他给向量去做召回,给他给这个这个库去做召回吗?不用吧,我们直接在前面一句,我们把它加到关键词里面去,这个话就基本上就成了,就是一个就。所以说我们这个系统本身也是一个从思考到记忆到直觉的一个系统,所以说这套系统本身应该是越用越好的。

这套系统最大的一个意义是什么呢?大家都知道,即使现在降价了,我们真的要把这个大模型这个东西,api call放到线上去调用的时候,它的成本是很高的。它的成本是很高的,但是我们期待的一定是这套系统不是在跑离线数据,而是在跑在线数据。那如果说前两者足够健壮,只有少量的流量需要流到第三层,这个成本是不是就省下来了?前两者大家都熟,关键词过滤也就是一个string match的一个过程,第二个就是我们的数据库的一个召回的,就是数据库的一个召回的一个过程,对吧?

那这个就是我的一个想法,那这套系统本身是不是还就是就是还有没有优化空间?其实就是玩的比较深的就是rag的一些比较高端的玩法。

第一个就是我们的embed,对,特别是我是推荐,就是我自己的思想里面,我是推荐所有的客户都应该做自己的embed模型的,fine tune的。因为每一家客户的数据不一样,场景不一样,你们真正在做这种精确化匹配的时候的这个embed的效果也是不一样的。在一个场景里面,这个模型可能好,在ui一个场景里面,可能这个模型不行了,需要做final。特别是对于多语言的场景来说,如果你有多个语言,可能你要用的inbad模型就不止一个,这是一个点。所以说对于embed模型的调校,能够极大地去优化我们的这个整个rag系统召回的一个质量,这是第一点。

第二点就是我一直说这个系统其实是一个新瓶装旧酒的过程,为什么呢?是因为其实这个东西就是我们传统的这个to stage的这种retrieval system,是我们的传统的搜索引擎玩烂的一个东西,它已经形成了这种,就是这种相关的一个模式。

我在这摆了两个数据,可能大家都看不太到,这是现在目前做工程化非常好的一个模型,叫cohere,他在advice的byterock上也有提供的两个数据,第一个是如果我们只是通过bm25的算法去做这个,召回以后他的精确度可能不太高,但是如果我们加了一个re rank,整个数据就提高了12.7%。re rank就是把所有的数据你召回以后,我再做一次排序的这个过程。那如果说是我们做了embed以后再去做这个,这个就re rank的效果是多少?还能提供提高13.1%。

这个其实大家可能会觉得是不是口黑,而为了介绍自己的re rank模型,但是我其实在之前参加了就是不少的这种ai的交流峰会,我发现不同的,即使不管是学术侧还是商业的应用侧,所有的人共同的认知就是re rank是一个你投入非常少,但是能够把你整个系统的精确度提高非常大的这样一个方式。大家可能会问,为什么我一开始就用re rank来做这个事情就算了,那这个需要解释一下,因为re rank本身也是个模型,embed模型,它最好的一个点是它开销小,速度快,适合从大量的这个文本里面,把你需要的这个文本做召回,然后把这些文本再做召回以后再做一次精细化的排序,你能够得到的这个效果就会更好一些。这个对于医疗行业、法律行业的这种大模型来说,几乎是必不可少的。

然后基于这个思想的话,其实最后的这个系统就变成这个样子了。我们可能在做召回的时候,从这个向量那这个就是我的一个想法,那这套系统本身是不是还就是就是还有没有优化空间?其实就是玩的比较深的就是rag的一些比较高端的玩法。

第一个就是我们的embed,对,特别是我是推荐,就是我自己的思想里面,我是推荐所有的客户都应该做自己的embed模型的,fine tune的。因为每一家客户的数据不一样,场景不一样,你们真正在做这种精确化匹配的时候的这个embed的效果也是不一样的。在一个场景里面,这个模型可能好,在另一个场景里面,可能这个模型不行了,需要做fine tune。特别是对于多语言的场景来说,如果你有多个语言,可能你要用的embed模型就不止一个,这是一个点。所以说对于embed模型的调校,能够极大地去优化我们的这个整个rag系统召回的一个质量,这是第一点。

第二点就是我一直说这个系统其实是一个新瓶装旧酒的过程,为什么呢?是因为其实这个东西就是我们传统的这个two-stage的这种retrieval system,是我们的传统的搜索引擎玩烂的一个东西,它已经形成了这种,就是这种相关的一个模式。

我在这摆了两个数据,可能大家都看不太到,这是现在目前做工程化非常好的一个模型,叫cohere,他在亚马逊云科技的Bedrock上也有提供的两个数据,第一个是如果我们只是通过bm25的算法去做这个召回以后,它的精确度可能不太高,但是如果我们加了一个re-ranker,整个数据就提高了12.7%。re-ranker就是把所有的数据你召回以后,我再做一次排序的这个过程。那如果说是我们做了embed以后再去做这个re-rank,这个就re-rank的效果是多少?还能进一步提高13.1%。

这个其实大家可能会觉得是不是在推销自己的re-rank模型,但是我其实在之前参加了不少的这种AI的交流峰会,我发现不同的,即使不管是学术界还是商业应用界,所有的人共同的认知就是re-rank是一个你投入非常少,但是能够把你整个系统的精确度提高非常大的这样一个方式。大家可能会问,为什么我一开始就用re-rank来做这个事情就算了?那这个需要解释一下,因为re-rank本身也是个模型,embed模型,它最好的一个点是它开销小,速度快,适合从大量的这个文本里面,把你需要的这个文本做召回,然后把这些文本再做召回以后再做一次精细化的排序,你能够得到的这个效果就会更好一些。这个对于医疗行业、法律行业的这种大模型应用来说,几乎是必不可少的。

然后基于这个思想的话,其实最后的这个系统就变成这个样子了。我们可能在做召回的时候,从这个向量库里面做这种混合召回前25%的这种数据,这种query,然后再做这个对这个query去做一个re-rank,最后取前三的这样的一个可能性的一个数据,去做我们实际的一个判定,它能够达到一个更好的一个效果,这套系统能不能再优化,这套系统能不能再优化,这是我昨天看了一篇文章以后,我也想到一个点,我现在跟大家交流一下,大家有没有想到能不能再优化,有没有做这种细分行业模型的同学能够说一下?

今天没什么人回答问题,那我就直说了,我昨天就是我前段时间看了一个分享,然后也是一个交流,他最后给我提出的一个很大的一个想法,就是专家模型加大模型加rag串联的这种方式,最后能够达到比专家模型或者说大模型加rag本身更好的一个效果,专家模型可以给我们的整个的大模型加rag的整个系统去提供足量的这种离线数据的不足,以及在线数据的二次判定,这是一个相对来说非常精妙的一个技术上的设计,我觉得是一个很好的想法,我虽然自己还没有做这个技术验证,但是我觉得这个想法本身非常酷,所以说跟大家也在这个地方留下这个引子。

然后这个就是我今天所有的交流了,非常感谢大家。然后大家可以扫个码什么的。

下面是一些演讲现场的精彩瞬间：

亚马逊云科技解决方案架构师李开元在亚马逊云科技中国峰会2024上分享了与牧童游戏合作开发生成式AI的经验和见解。

亚马逊云科技推出了一款先进的Prompt生成器,可以大幅缩短Prompt调优时间,为AI模型开发提供了高效便捷的解决方案。

亚马逊云科技中国峰会2024上,演讲者介绍了使用亚马逊开源项目Open Search作为存储引擎,结合向量召回和关键词召回,能够提高知识召回的精确度和性能。

亚马逊云科技中国峰会2024上,演讲者详细阐述了一套三层过滤系统,用于确保内容合规和语义相关性。

亚马逊云科技中国峰会2024上,演讲者强调了针对不同客户数据和场景进行Embed模型微调的重要性,以优化整个RAG系统的召回质量。

重排序模型在医疗和法律等领域的大型模型中是不可或缺的,能够以较小的开销显著提高系统精确度。

专家模型与大模型加RAG串联,能达到更优效果,专家模型为大模型加RAG系统提供离线数据补充及在线数据二次判定,是一种精妙的技术设计。

总结

生成式人工智能(AI)被视为一项颠覆性创新,影响深远。亚马逊云科技与东南亚游戏公司牧童游戏合作,将生成式AI应用于游戏玩家社区服务。他们首先验证了生成式AI在语言翻译场景下的高投资回报率,然后将其应用于舆情分析系统,实时获取玩家对新功能的反馈。最终,他们构建了一个三层过滤系统,用于识别辱骂言论,提高了效率和准确性。

这个案例展示了生成式AI在实际工程化场景中的应用价值。通过分阶段验证和优化,生成式AI系统不断迭代,从思考到记忆再到直觉,成本逐步降低,效果不断提升。未来,专家模型与生成式AI的结合或将带来更佳表现。

生成式AI正在重塑各行业,为企业带来新的机遇。亚马逊云科技致力于与合作伙伴共同探索生成式AI的无限可能,推动技术创新,提升客户体验。

2024年5月29日，亚马逊云科技中国峰会在上海召开。峰会期间，亚马逊全球副总裁、亚马逊云科技大中华区总裁储瑞松全面阐述了亚马逊云科技如何利用在算力、模型、以及应用层面丰富的产品和服务，成为企业构建和应用生成式 AI 的首选。此外，活动还详细介绍了亚马逊云科技秉承客户至尚的原则，通过与本地合作伙伴一起支持行业客户数字化转型和创新，提供安全、稳定、可信赖的服务，以及持续深耕本地、链接全球，助力客户在中国和全球化发展的道路上取得成功。