查看原文
其他

智能NPC的多维进化:腾讯在AI领域的探索与应用

邱东洋 DataFunSummit
2024-09-11

导读 本文将分享腾讯游戏在智能 NPC 方面的实践。

主要内容包括以下四大部分:

1. AI 带来的机会

2. 我们的实践

3. 未来思考

4. 问答环节

分享嘉宾|邱东洋 腾讯 游戏知几技术负责人

编辑整理|晏世千

内容校对|李瑶

出品社区|DataFun


在正文开始前,首先来介绍一下游戏知几产品。

我们致力于提供创新的、维系和活跃游戏用户的产品解决方案。最早的解决方案为,内置在游戏中的知识问答,纯文本的交互,解决用户的攻略资讯问题,以及陪伴用户聊天。当时的 slogon 是“懂游戏、更懂你”。
在 2020 和 2021 年的时候,我们与和平精英项目组一起探索研发了“和平第五人”的解决方案,期望设计一套没有任何可视化界面的纯粹依赖语音交互的 AI 助手,能力上也从战前战后的文本咨询,升级到战中的沉浸式的策略指导、语音指令、语音聊天。接着,我们把语音指令的功能横向扩展到了天天象棋游戏中,和项目组一起推出了“天天象棋”无障碍版本,让更多的玩家也能享受到游戏的乐趣。同时,也把这套交互方案推广到了游戏外的智能屏——浙江卫视的谷小雨智能屏,而且除了语音,还增加了动作等多模态驱动。
到 2023 年,随着 LLM 的来临,我们在游戏内落地了多模态的 NPC 交互方案——天涯明月刀的“绝智阿暖”,这也是本次分享的重点。

01

AI 带来的机会

NPC,即 Non-Player Character,指 RPG 游戏中非玩家控制的角色,玩家通过与 NPC 的互动去完成任务,推动剧情的发展。在游戏中,好的剧情设计和 NPC 对话脚本设计,能让用户更好的带入到游戏世界观中,更加沉浸的体验到游戏的乐趣—— 用户也更愿意为游戏买单。
传统的解决方案,是内容创作的同学通过脚本来配置的,若想让对话丰富就得配置更多的对话,通过策略树来组织。这种方案的缺陷也是显而易见的:制作成本高,内容重复,用户体验缺少新鲜感,并且不够真实。

近两年随着 LLM 的快速发展,也给游戏 NPC 能力的拓展带来了新的机会。
下面举四个例子:
(1)2023 年 Nvidia 发布的云端 AI 生成服务 ACE for games 工具,利用 LLM 提供更丰富的对话能力,极大提高了游戏研发的效率。根据设定,以幽默、毒蛇、和善等不同的性格语气来和用户进行对话,当用户述说着店里因为更换口味使得人流降低的状况,这个 NPC Jim 甚至还会调侃玩家的提问多此一举,宛如真实生活中随处可见的对话一样。
(2)斯坦福虚拟小镇的例子:通过 LLM 实现一个驱动多个智能体的虚拟社会,利用提示工程实现了 25 个智能体的规划、总结、反思等能力。虽然只是一个学术 demo,但让我们看到 LLM 除了提供开放对话的能力外,还可以很好的应用于构造智能体的规划、反思、总结等能力,甚至多个 NPC,NPC 与社会环境之间进行交互成为可能。
(3)在游戏里已经落地的例子。在黑客帝国这款游戏中,在社交媒体上有很多转发的。利用 LLM 来为游戏中的很多 NPC 的对话,很多用户调侃他是 AI,看他会有什么反应?
(4)还是在这个游戏中,一个多 NPC 交互的例子,他们在陪玩家玩一个游戏——反图灵测试的游戏——看在座的中间,谁是人类?都被用户玩坏了
看过这几个例子后,自然会想:好的 NPC 需要具备哪些特征?

总结来说,一个好的 NPC 的基础特征就是具备基础开放对话的能力和多模表现能力,高级特征包括决策能力、游戏行为能力、感知能力和记忆能力,更高级的则是一些社会特征,包括剧情涌现生成和协作的能力。

02

我们的实践

在分析完行业的 case 之后,接下来是本次分享的核心部分——我们团队的 NPC 落地实践。

天涯明月刀是一款武侠题材的 RPG 类游戏。早期的阿暖是一个纯文本的攻略知识问答。这次升级主要实现了刚才提到的 NPC 特征的上半部分,包括:开放对话、多模态驱动、记忆等高级的策略等。

我们把做这样一个 NPC 的技术点梳理为 3 条主线:
  • 对话(基础与核心),包括基础的开放对话能力,和高级的记忆和策略等能力;
  • 表现(包括:语音、面部、动作),主要是表现层面的能力;
  • 系统(多模态系统整体运行的性能),NPC 是一个在线的能力,其次是如何让这些能力更好地作为整体来提供服务,主要是解决系统的时延和吞吐上的研发。

1. 开放对话

开放对话是 LLM 最擅长的能力,“绝智阿暖”是基于腾讯自研的混元大模型精调的模型。在 NPC 场景下,我们除了利用好 LLM 的优势,还要追求游戏垂域下更高的目标:准确、拟真、安全。
(1)开放对话的准确性

那么,为什么准确是排在第一位的?LLM 的出现,行业都在讲距离 AGI 更近了。但是在实际业务使用中,还是会存在幻觉和编造的问题,游戏垂域下的问答准确率不高,达不到上线的标准。
解决方案就是 RAG 知识嵌入。当用户提问时,不是直接就去访问 LLM,而是通过检索相关知识,然后将检索结果用来构造 prompt,最终调用 LLM 给出答案。
如右图这个例子,这样做的好处是领域知识更加准确,更新的实时性高(LLM 的 zero shot 优势),复用了 QA 的沉淀。
这里的技术关键是:知识库构建和检索器能力。

知识库构建看似简单,但如果构建不当,会对最后生成的准确率造成很大影响。行业里,大家经常也听到 chunk 大小对最后知识召回影响很大。这里介绍 2 个实践中的关键点:首先,不仅仅是保存切片,在此基础上进行多维度知识总结;其次,对关联知识进行聚类后 LLM 增强。通过这两个方法,准确率从最初的 62% 提升到了 67%,并最终提升到了 74%。

关于检索器的设计,先来看一下如何适配多维知识库。
首先是编码器选型。近两年业界在向量编码模型器上有很多优秀的开源工作,对比传统的表示模型有很大的提升。基于开源模型,我们在游戏通用数据和阿暖业务数据上进一步做 2 阶段的领域微调,得到了业务场景的基础编码器。最终选择了基础性能合格并且进一步微调稳定性高的 m3e 模型。
再来看看如何适配多维度的知识库内容。可以来看一下多维度检索的例子,对于用户输入“孤独若虚和公孙剑谁更厉害”,我们从多个索引中检索内容,内容的形式差异很大,不仅要考虑 question_list 中有相似句意的问句,还要考虑在其他的维度中有不同抽象程度的相关内容,编码器要能编码这些异构的信息。我们采取的方案为多维度的索引。
由上图中的性能评估数据可以看出,领域微调的效果显著,并且引进多维度索引能一步提升检索召回率。

检索器设计的第二个问题是:如何支持有上下文关联的内容召回?这一问题的背景是,在对话中经常会出现指代或者省略的用户输入,使得用户输入的意思是不完整。
我们实践了两种方案来解决这个问题:
  • 一个是结合上文利用 Query 改写能力来恢复当前句意后再做检索召回;
  • 另一个思路是微调编码器,直接让编码器具备编码复杂上下文的能力。
通过下表数据可以看到多轮编码器的方案更好,因此我们最终采用了多轮编码器的方案。
这里特别提一下,对于多轮编码器的训练,重点要考虑语料要包含上文相关和无关的情况,使得编码器具备编码复杂上文的能力。
这里有个问题:为什么不两者同时使用?这个问题留给大家思考。
(2)开放对话的拟真性

“准”的方案介绍完,接下来是“真”。
我们希望 NPC 更加拟真,不是以假乱真,不是让用户辨别不出是真人还是 NPC,而是让用户在体验 NPC 时更加真实,不重复有新鲜感。
从业务的要求看,我们把拟真分为两个层次:
  • 拟真基础要求:符合人设、游戏世界观;
  • 高级类人策略,比如:长期记忆、规划、反思、话题引到等。
行业上关于类似场景的解决方案,主要是通过提示工程,大模型效果能否被激发出来,关键看 prompt 设计的是否到位。此外,还有模型本身的理解力,高级策略的 prompt 一般都会很长,所以支持长输入是底层模型需要具备的关键能力。

之所以要做长输入理解优化,主要基于三方面的考虑:
  • 业务场景的需求:基于 RAG 的人设扮演 prompt 通常很长
  • 模型能力的要求:当前模型随着长度增加,对话效果骤降
  • 系统能力考量:放宽检索长度限制,减轻检索模块压力
我们来思考下解决方案,如果模型在开始训练时,要支持长输入,只需要将最大输入长度改大就可以。但如果让已有模型支持长输入,就需要通过一些技术扩展上下文长度,然后用领域数据在增量预训练提示效果。现在主流的大模型都是基于 RoPE 旋转位置编码来扩展上下文长度,其好处是能不从 0 开始预训练,这很关键,极大降低了模型预训练的成本。
我们的做法是:
  • 先做二次增量预训练,用少量的数据来让模型适应更长长度的 RoPE 基频(24k 上下文,训练 6.3B token);
  • 其次,对短输入、长输入做 2 阶段 SFT,这样做的好处是可以保证不降低短指令输入的同时提高长指令输入性能。
最后在业界公认的 benchmark 集合上进行了评测。Line retrieval 评测,经过长输入优化后,随 prompt 长度增加性能下降是缓慢的,准确率和 GPT3.5 接近(在 10k 输入以内准确率高于 90%)。在阿暖业务上的评测,长输入理解力的提升能带来 10% 的对话回答准确率的提升。

接着以记忆能力为例,介绍我们基于 prompt 如何开发高级拟真策略。
首先,用户在进行对话时,会旁路拿到对话信息,用大模型进行总结,当用户再一次有输入到来的时候,先用 RAG 检索记忆库,将检索的知识组装到提示词里,最后放入大模型。
(3)开放对话的安全性
我们在安全合规上的方案主要包括三个部分:
  • 首先是对输入进行识别,一方面利用传统方法对敏感词进行检测,可以过滤掉一大批敏感内容,另一方面还利用大模型对于敏感内容进行识别。
  • 第二个部分是,模型在生成的时候,要规避风险问题,更加委婉地回复。
  • 第三个部分就是事后解决,如果有些用户问到敏感内容,那么会对用户进行封号,封几个小时或者几天,或者更长。
通过密集型有害问题进行评测,最终的结果是有害率低于 0.5%。
(4)开放对话的效果

上图展示了几个实际的例子:
  • 游戏世界观的提问
  • 引导式反问,通过反问控制对话主动权
  • 展示的是记忆能力
  • 安全边界的控制


关于开放对话解决方案的整体收益是非常明显的,除了上面的例子外,再来看下数据:
  • 这里左边展示了阿暖 NPC 开发优化的离线评测,蓝色线展示的是我们在历次评测中通过不同的优化手段,逐步提高对话准确率。绿色的是 GPT3.5 的效果,我们模型目前的效果超过了 GPT3.5 的效果。
  • 在 2023 年底,阿暖 NPC 正式在天刀游戏上上线的数据情况:整体线上的回复准确率达到 94%,人设符合率 99%,有害率是 0%。

2. 多模表现

以上是关于“灵魂”部分的介绍,接下来看下表现的部分。灵魂的部分是提升的 NPC 体验效果的底线,而表现做到好,会极大提升用户体验的上限。这部分主要介绍我们在语音、面部部分的收益。
(1)多模表现之语音

NPC 场景对语音的要求:
  • 首先不再像是 QA,回答内容都是提前制作好的,声音也可以可离线制作好,回复内容都是实时生成的,语音也必须实时生成;
  • 其次,是希望更加自然、且表现丰富。
传统的 TTS 解决方案,在自然度上及韵律上,都较为机械。我们采用了大模型的解决方案,不仅在自然度上有突出表现,而且还可以用很短的语音 prompt 自定义 NPC 的音色,这就为 NPC 玩法提供了更多的想象空间,比如让用户来为 NPC 捏声音。
在实时性上,我们通过算子级别的加速,TTS 合成的实时率从 0.5 优化到 0.085,完全满足实时在线的要求。
(2)多模表现之表情

面部是情绪表达的重要部分,NPC 对口型的要求准确、泛化性好、情绪表情丰富。解决的思路是输入语音,让模型预测出控制器序列,来驱动 3D 模型。准确率、泛化性,指的是能支持更多样的语言和语音形式。我们通过高质量的平行数据基于预训练语音模型,通过少量的参数微调,达到了良好的效果。
这里的主要挑战是从语音到 3D 控制器参数的平行数据很难获取的挑战。解决思路是语音-2D 图像和控制器-3D 渲染图像平行数据成本都不高,解离表情潜在表达 z 并进行对齐,我们的方案已发表在 23 年的 ICCV 会议上(ICCV2023. Semi-supervised Speech driven 3D Facial Animation via Crossmodal Encoding)。
这套 3D 面部动画生成方案,除了用在阿暖 NPC 之外,还落地在了图中所示的其它一些场景。
我们开源的语音预训练在 git 上已有 800 stars,地址如下:
https://github. com/TencentGameMate/chine se_speech_pretrain

3. 系统性能

前文介绍的这些能力如何作为一个整体来提供服务,接下来将介绍性能问题的解决方案。

性能挑战主要来自于模块多,且多为大模型。我们主要通过架构设计和模型推理加速两个维度来提升系统的性能。
(1)架构优化

在架构上,我们采用了并行、流式架构。之所以可以并行是因为虽然涉及到的 AI 能力很多,但并不是所有能力之间都有依赖关系。这样我们就能将没有调用依赖的调用进行并行调度,这样可以极大地减少整个链路的调用耗时。
比如图中所示:对话内容生成后,动作标签的生成和 TTS 的调用就可以并行调度;动作生成和面部驱动也可以并行调度;此外输入的敏感词检测和输出的检测也可以并行。

架构设计的第二点是流式设计。大家都明白 LLM 本身因为极大的参数量,在生成时耗时很高,所以行业内进行流式的输出,类似打印机一样展示到前端,这样用户可感知的时延,就仅仅是首 token 的耗时。在 NPC 的整体架构上,我们也借鉴了这个思想。但具体实施时,还是遇到了挑战,TTS 生成的时候,需要一个完整的句子来提升整句的自然度,怎么办呢?我们最终采用了基于短句的流式方案,即 LLM 生成的文本,如果是一个完整的短句时,就及时推送给下游。这样从用户角度看,首句时延就是用户体验到的延时。
(2)模型服务推理加速

近年来随着 LLM 的落地,大模型推理技术也有了快速的发展。针对文本大模型,我们通过int8 量化压缩了数据,优化了显存、访问带宽和时延,采用 prefix cache,采用 flash decoding,进一步优化了首字时延。动过动态 batch 技术优化了整体系统的并发。针对其他视觉、语音能力也进行了算子级别的加速优化。
最终请求时延,加速架构等多个阶段的优化后,从图上可以直观,整个端到端的时延,从10s+ 降至约 1.5s。

03

未来思考

最后来分享一下我个人对游戏 NPC 未来发展的思考。
首先,整个行业在 NPC 上的探索才刚刚开始,相信在未来半年、甚至持续较长的时间内,游戏 NPC 和 AI 的结合会在很多游戏不断落地、持续迭代,所以 NPC 的未来远不止于当前。
其次,像其他 LLM 落地应用一样,模型推理的成本是落地中遇到的关键挑战,NPC 也是如此,尤其在游戏内如果多 NPC,PCU 又很大的时候,成本成为了绕不开的话题。该怎么解决?本身模型推理近 1 年来已经在快速提效,未来必然也会保持高速的进展,包括应用架构的创新,比如端云协同推理;另外在 NPC 落地层面上,也可以分层来看,哪些能力使用 LLM,哪些可以不使用,是需要持续打磨和平衡的。

最后,游戏成功的本质是什么?游戏好玩是因为有了 AI 么?玩法本身才是游戏游戏成功的关键,但 AI 为游戏设计和给游戏策划提供了更宽的思路和更强大的基础能力。虽然 AI 不是好玩的直接原因,但经过一段时间的时间,一定会催生出更加不同、甚至颠覆性的玩法。

04

问答环节

Q1为什么选了 m3e 又选了 bge?是否会去检查 NPC 的回答是否合理?

A1开始 embedding 模型都用了,但是最稳定的回答是 m3e。在研发阶段是都会用的。上线了后,会定期的抽查,抽查完了一个人工标注的结果,准确率是 94%。人设这一块还是比较好。

Q2:NPC 落地肯定要符合游戏的世界观(如问香港是否是这个世界?回答不知道香港),如何做到符合游戏的世界观?是做微调还是什么办法?

A2:(1)能拿到游戏的白皮书来做训练。(2)拿宋朝的数据来训练模型,阿暖相关的数据训练,用更加专业的数据来做指令微调。最困难的事情是数据的准备。

Q3:基于大模型的系统和传统的系统的对比是什么样的呢?

A3之前的系统是 QA,做检索的方式,需要做很多内容。在游戏里做攻略资讯,已经能做很高的匹配度。闲聊在原来的系统里,攻略处理的不好。解决方案就是  RAG。

Q4:除了三个指标【准确度,拟人度,有害性】以外,是否还有别的指标来检测结果呢?

A4算法的指标已经了解了,准确度类似的、人设符合型的。生成模型的就是看这些。标注数据都是靠人标注的,很多数据不能通过太多的标注指标来完成,容易标注不好,所以只能通过数据量上的增加来完成效果。

Q5是会对每一个角色单独训练模型还是会统一训练
A5:每一个角色都会微调,基底模型都是一个,能力比 GPT4 差,但是又追求一个线上比较好的效果,所以用的是小模型。
以上就是本次分享的内容,谢谢大家。


分享嘉宾

INTRODUCTION


邱东洋

腾讯

游戏知几技术负责人

西北工业大学计算机硕士,腾讯游戏 AI 工程师,腾讯智能交互产品“游戏知几”技术负责人。研究与实践领域主要聚焦于 NLP、模型推理加速、系统架构与性能优化等。代表产品:游戏知几知识问答、“和平第五人”AI 语音助手、天天象棋(无障碍版)、知音语音大模型、“绝智阿暖”智能 NPC、基于 LLM 的人机协同智能客服解决方案等。

活动推荐

往期推荐


让大模型更懂情感,我看到了巨大的市场潜力

大模型在小爱同学应用实践

基于 Doris 湖仓一体分析系统在快手的实践

金融大模型数据治理与应用创新

面向大规模向量数据的云原生存储解决方案:Milvus 向量数据库的经验

生成式AI带来的冲击与改变,我们讨论得还远远不够

多模态在京东内容算法上的应用

LLM+RAG:大模型在金融场景的落地探索

智能电销新纪元:大模型技术的应用与未来趋势

Apache Hudi 从零到一:初识表服务:压缩、清理及索引(五)


点个在看你最好看

SPRING HAS ARRIVED

继续滑动看下一个
DataFunSummit
向上滑动看下一个

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存