技术实践｜莉莉丝《远光 84》项目组是如何快速验证并落地多个生成式 AI 应用的？...
关于莉莉丝
莉莉丝游戏是中国中生代游戏公司代表，在中国游戏市场保持领先地位。莉莉丝游戏自主研发运营多款精品游戏，包括《远光 84》、《战火勋章》、《剑与远征》、《万国觉醒》、《剑与家园》、《艾彼》等。2020 年 4 月，根据第三方统计机构 AppAnnie 、SensorTower 发布的数据，莉莉丝游戏在“中国游戏公司收入榜”中位列第三。同年 1 月 – 4 月，莉莉丝在“中国游戏公司出海收入榜”排行榜稳居冠军宝座。2022 年 4 月 25 日，莉莉丝游戏宣布，在新加坡成立发行公司 Farlight Games，总部设于新加坡，为莉莉丝游戏的全球发行提供支持和服务。
莉莉丝官网：
https://www.lilith.com/
关于《远光 84》
《远光 84》是一款多端互通的大逃杀英雄射击游戏。相较于传统吃鸡游戏，Farlight 84 会通过其独特的喷气背包、英雄技能、武装载具、局内成长系统和多次复活机会，为大家带来上手更快、节奏更紧凑、更加“横冲直撞”的对局体验——在这里，相比于“苟”在角落里，你将看到更多激情“刚枪”的身影。Your Farlight, Your Highlight！
《远光 84》官网：
https://farlight84.farlightgames.com/
《远光 84》项目组在生成式 AI 的技术实践
随着各类大语言模型的闪耀登场，2023 年可以说是生成式 AI 元年，我们看到在游戏行业，也有很多生成式 AI 的落地案例。《远光 84》项目组以开放的胸怀拥抱生成式 AI，采用小步快跑的方式，在多个业务场景中，通过 Amazon Bedrock + Claude2 的方案，快速验证并落地多个生成式 AI 应用，积累丰富经验。
Amazon Bedrock 是一个完全托管的服务，通过单一 API 为头部 AI 公司如 AI21 Labs、Anthropic、Cohere、Meta、Stability AI 和 Amazon 提供高性能的基础模型选择，以及构建具有安全性、隐私性和负责任 AI 的生成式 AI 应用程序所需的广泛功能。Claude 模型基于 Anthropic 公司对于创建可靠、可解释和可控制的 AI 系统的研究。Claude 使用 Constitutional AI 和无害训练等技术创建,在思考对话、内容创建、复杂推理、创造力和编码等方面表现卓越。
应用 1：大模型文本分类 – Text2API
业务场景
在项目组内部有一套 FAQ 聊天系统，开发与测试人员会通过该 FAQ 系统，输入指令，对游戏与玩家信息进行查询。总共 50 多条指令，对于新用户，需要在短时间内记住这么多条指令，比较挑战。为了提升用户体验，方便开发与测试人员对相关数据的查找，项目组在该工具上对生成式 AI 进行初次尝试。
技术方案
与亚马逊云科技技术团队讨论大模型的应用场景和技术手段后，觉得该场景以提示词工程的方式进行接入较为合适。作为初次业务尝试，需要快速落地与快速验证，以确定项目组对大模型能力的理解符合预期，并且能快速获得生成式 AI 工程化的第一手经验。
在技术上，我们直接将 50 多条指令的 help 文档，在格式上做统一调整后，直接作为提示词给到大模型；大模型理解用户的自然语言，并根据此 help 文档进行分类，转化成对应的 API。
用户在聊天窗口进行讯问，调用大模型将自然语言转换为 API 后，立即执行 API，获得数据后，直接在聊天窗口进行输出。考虑到聊天窗口存在上下文的逻辑关系，我们在提示词工程中进行了上下文保留与优化，让该 FAQ 系统更具逻辑性。
架构示意图
提示词示例
Human: 你是一名资深的技术文档编辑，已熟知，负责组织输入
根据格式来输出可以执行的指令。
{commands}
1.一条完整的信息包括以下属性：指令和参数，输出格式参考，对指令和参数用<>必须进行整体前后包裹，如: 。
2.如果匹配到对应指令，参数从信息或者上下文中获取，参数是可选的。
3.如果匹配到对应指令但缺少参数，输出结果需要提示缺少什么参数，比如：你输入的信息中缺少UserID。
4.如果匹配不到对应指令，输出结果要给出相似指令建议，参考。
{references}
{datetime}
{context}
根据{content}的上述条件，只输出一个结果。
有关输出，请参阅。
让我们共同创造。
Assistant: 业务提升点
从用户角度，使用经验保持不变，都是从聊天窗口进行提问并获得对应数据。对于老用户，依然可以直接使用指令获取信息；对于新用户，该系统则变得非常友好，可以通过自然语言去表达需求并获得信息，从而提升开发与测试团队的工作效率。
通过该应用的快速落地，项目组对大模型的能力有了初步的认知，并开始在不同的场景中尝试使用大模型进行业务改造。
应用 2：大模型代码生成 – 网页生成
业务场景
通过提示词工程和知识库等技术，项目组对原有的一些工具进行技术改造与升级。与此同时，对于新工具或者新业务，大模型是否可以帮助项目组简化开发工作，也纳入了研究范围。
经过研究讨论，针对新工具，项目组决定采用提示词工程，以自然语言的方式生成定制化的网页工具，并提供给团队内部使用。
技术方案
通过实践，我们发现大模型具有比较强大的代码能力。在进行工具开发时，我们只需要告诉大模型，该部份组件的功能，以及代码模式等信息，大模型即能快速生成相关代码。在经过代码的多轮迭代后，就能呈现出一个很好的工具。
提示词示例
现在有一个网页需要你帮我来制作，要求如下：
我们是一个用于展示用户信息的网站，请使用bootstrap ui来美化网页，网页的布局从上到下分为三个部分
第一个部分为搜索部分，用于填写搜索信息，包含三个内容，用户ID、开始日期和结束日期，还有一个搜索按钮。
第二个部分为用户的基本信息部分，一个用户会包含以下内容：
平台:win
UserID:xxxxxxx
PlayerID:xxxxxxxxx
昵称:玩家#xxxxxxx
账号创建时间(UTC+08:00):2023-11-27 16:21:43
上次登录时间(UTC+08:00):2023-11-27 16:21:43
最后登录IP:xx.xx.xx.xx
第三个部分展示用户在搜索条件范围内的一些战斗记录，使用列表的形式显示。业务提升点
凭借大模型强大的代码能力，我们可以快速地响应业务需求，开发对应工具；降低开发门槛、节省人力成本、加快工作效率。针对游戏行业的开发工程师，帮助他们快速构建前端代码。
应用 3：大模型数据分析 – 用户体验分析
业务场景
有了可以快速开发迭代的新工具，在新业务的探索上，项目组也在不断进行尝试。其中，针对 FPS 游戏而言，DAU 数据对该游戏至关重要。从游戏登陆到对战结束的一整套环节，玩家体验如何，直接关系到游戏 DAU 的发展趋势。在传统的玩家信息系统中，针对玩家体验、流失风险的分析，都是提取各类数据指标进行综合计算与分析，面向整体游戏大盘，提供分析结果。但此类技术，对于单个玩家，缺少了力度与温度，我们从整体大盘数据中无法了解到单个玩家的游戏体验如何。特别是当单个玩家进行投诉或者游戏反馈时，我们无从快速得知玩家体验和痛点，从而丧失了挽留该玩家的机会。所以，我们需要一个更细力度的工具帮我们对单个玩家的游戏体验进行分析与归纳总结。
针对这一特定需求，项目组尝试利用大模型，将单个玩家的各类数据作为输入，让大模型对玩家体验进行分析总结；再将此网页工具提供给客服人员，以帮助他们在与玩家交流时，能够快速了解该玩家的游戏体验与痛点，从而挽回玩家、提升游戏反馈。
技术方案
通过新开发的工具，我们可以将现有的玩家数据快速地提供给大模型，采用提示词工程，对玩家的数据进行描述；大模型对玩家数据描述进行分析、归纳、总结，并以我们规定的格式，输出玩家体验分析结果。
目前，玩家数据主要包括以下几方面：设备情况、网络情况、对局情况。
架构示意图
玩家体验结果示例
玩家设备评分：设备评分90，iPhone11性能良好，能够流畅运行游戏
大厅网络评分：大厅网络评分80，平均延迟在可接受范围内
战斗网络评分：战斗网络评分90，平均延迟极佳
战斗帧率评分：帧率评分85，iPhone11在当前图形设置下能够保持较高且稳定的帧率
战斗KD评分：KD评分75，平均KD一般，属于新手级别玩家
综合评价概述：玩家设备与网络环境良好，但游戏水平有待提到，可以适当调整难度曲线业务提升点
项目组利用大模型，基于现有数据，快速建立了针对单个玩家的体验分析工具，填补了业务空白。基于数据的玩家体验结果，可以让客服人员在最短时间了解客户感受，帮助客服人员展开后续工作。
数据的接入、提示词的修改都非常灵活，这为我们后续接入更多的玩家数据以提升结果准确性，提供了非常便捷的优化手段。同时，以此类数据信息解读为方向，通过快速地开发、验证与迭代，利用大模型实现业务创新，这给项目组提供了非常大的想象空间。
应用 4：大模型知识库 – FAQ 专家
业务场景
由于游戏逻辑复杂，项目组划分为多个业务小组，包括：游戏策划、前端项目组、后端项目组、游戏 QA 团队等。日常工作中，业务小组之间有较高频率的技术咨询问题。游戏主程希望基于大模型建立一套内部知识库，提供给项目组做知识查询，以减轻项目组成员的工作负担，提升工作效率。
技术方案
项目组通过 Amazon Bedrock 的知识库功能，构建了一套比较完善的内部知识库。该系统采用 Opensearch Serverless 做向量数据库，采用 Titan Embedding 模型做知识嵌入，再结合 Claude 模型进行自然语言理解与知识归纳。将知识库文档定期放入 S3 桶，再定期调用文档 Sync API，则完成了知识库定期更新操作。
在业务应用上，延用了原有的聊天系统，用户在聊天窗口，通过自然语言进行知识讯问，代码与 Amazon Amazon Bedrock 进行交互并获得相关信息后，将结果返回聊天窗口，保持用户使用体验不变。
知识库架构图
业务提升点
在用户使用习惯与检索质量保持不变的情况下，解放了项目组成员的部份人力，提升项目组工作效率。知识库支持 txt、PDF 等文档格式，且对表格数据有较好支持。原始文档转化为 PDF 后，无需额外加工，直接导入 S3 即可，这使得该内部知识库具有极强的扩展性和可复制性。
考虑到知识内容较多，存在信息干扰的可能性，针对一些特定业务，可以单独创建知识库。同时，知识库部署非常简单，操作人员只需关注文档内容质量，而不用在系统搭建上花更多时间。
应用 5：大模型 Agent 助理 – 流程助手
业务场景
设计、实现和优化能够充分发挥大模型潜力的工作流程，需要投入大量精力和专业知识。自动化这些工作流程具有巨大价值。随着开发人员开始创建越来越复杂的基于 LLM 的应用程序，工作流程势必会变得更加复杂。自动化工作流程的业务需求，催生了 LLM Agent 这一概念。LLM Agent 利用大模型以自主的方式计划和执行相关任务，自主利用工具完成复杂工作流程，从而实现工作流程自动化。
在对提示词工程与知识库有充分了解后，项目组也努力开拓 LLM Agent 的业务落地。只有依靠 LLM Agent 实现自动化的工作流程，才能大幅度地减少生成式 AI 开发与接入工作，对后续生成式 AI 业务的持续开展至关重要。
技术方案
Amazon Bedrock 提供了 LLM Agent 功能，并实现与知识库的集成。项目组计划采用 Amazon Bedrock Agent，根据知识库里的基础设施巡检流程，自动完成生产环境巡检。
在产品设计上，Agent 完成构思与计划后，会调用 Lambda 进行实际业务处理，并根据该业务的返回结果进行下一步的构思与计划。但项目组主要的业务逻辑，都已经用 API 封装完成，单独为 Lambda 设计一套调用接口，工作量比较大。故此，在 Lambda 的调用设计里，直接将 Event 信息以 Get 方式发送给本地 OpenAPI，本地 OpenAPI 根据 Event 信息做业务处理，再将 response 发回给 Lambda，而 Lambda 则负责将 response 转发给 Agent。
完成这样的设计，可以将 Amazon Bedrock Agent 与后端工具解耦，即 Agent 调用的后端资源，可以不用被限定在亚马逊云科技上，只要该资源可以提供 OpenAPI 的访问，即可参与进 Agent 的自动执行中。该方案大大地延伸了Amazon Bedrock Agent 的能力范围，也提升了工具接入的灵活性。
架构示意图
业务提升点
Agent 在自动巡检业务的落地，代表着项目组对生成式 AI 的业务展开，进入到一个新的阶段。以往需要人力去进行代码设计与执行的流程性工作，都可以交给 Agent 智能执行，而开发人员只需要定义好业务接口，并在知识库中设计好工作流程即可，这大大降低了生成式 AI 项目的开发与接入门槛，同时也为今后的智能业务创新，拓宽了道路。
项目组在生成式 AI 上的经验与最佳实践
项目组在 Text2API、知识库 RAG、AI 辅助创建新工具、AI 辅助创建新业务、Agent 智能执行工作流程等场景中，不断实践与优化对大模型的使用方式，从而总结了一些经验与最佳实践：
从哪里开始
生成式 AI 从哪里开始，这是第一个基本问题，也是一个非常关键的问题。随着各家大模型的闪耀登场与不断升级，以及各类行业分享如雨后春笋般的不断涌现。在 2023 年年末，生成式 AI 的应用，着实有些“乱花渐欲迷人眼”的感觉。我们是否要采用参数最大的模型、是否要多模态、是否可以将那些已经公开的案例直接复制到我们的业务中，这一系列的问题，我们相信在初次接触生成式 AI 应用时，大家或多或少都会进行考虑；也因为可考虑的因素实在太多，从而导致了一定程度的迷茫与犹豫。从我们项目经验上，建议可以从当前的实际业务、实际工具出发，首先在较小范围内考虑生成式 AI 对业务与工具的改造，再总结经验，并逐步扩大到其他业务。因为小范围的快速尝试，可以让我们对大模型的能力在较短时间内形成一个初步认知，再基于这些认知，不断调整生成式 AI 业务目标，以小步快跑的方式，逐渐深化生成式 AI 应用。
上下文保留
在 FAQ 与知识库等工具中，为了让 AI 更具有逻辑性，我们需要在提示词工程中进行上下文保留，以确保 AI 了解过往对话，从而生成更适合当前对话的内容。在提示词工程中，我们用一个字符串不断累加之前提问的信息，以达到上下文保留的目的。在最开始阶段，我们尝试将“提问”与“回答”，这两方面的信息都做保留；但实践下来，随着不断的提问与回答，给到大模型的信息过多，导致在多轮问答之后，大模型给出的答案开始变得不可控。为了精简信息，我们只将过往 10-20 条提问信息做保留，即让大模型知道我们提问的历史记录，在保证答案质量的情况下，让大模型更有逻辑性。另一方面，我们也对该字符串做定期刷新，因为累积过多的问题，也有可能造成答案质量不可控。
时间问题
在 Text2API 的场景中，会有针对时间的查找，比如找到“今天”的玩家对战结果。对于自然人，我们肯定知道“今天”代表具体哪个 timedate；但是，由于大模型的离线训练方式，我们发现它对“今天”的理解，与我们自然人有很大差异。实践发现，如果我们只讯问“今天”的对战结果，很有可能返回的是几个月前的查询结果。所以，在任何涉及到时间的查询中，我们都需要在提问时、或者在代码中，有意识地将此类相对的时间，转化为标准的 timedate 值，以确保大模型获得准确的时间信息。
“常见”问题
在知识库场景的测试中，我们试图将一些代码的 exception 报错直接提供给大模型，并让大模型根据特定的知识进行回答，但我们发现大模型给出的结果，与我们的期望，差距非常大。在排查该失真问题的过程中，我们首先判断向量数据库的 KNN 搜索，是否存在差异。为此，我们调用 Amazon Bedrock 的 retire API，对该问题进行回答，发现向量数据库精准匹配了问题，并将问题与答案一并发给了大模型；所以，从结果上看，大模型拿到问题与特定答案后，还是按它自己的理解进行了回答。进一步测试，我们发现如果将 exception 报错信息的格式做一些修改，让该问题看起来不这么“常见”，大模型则会按照我们给定的答案进行回答。由此，在建立知识库时，针对一些“常见”问题，或者以“常见”字符串开头的问题，我们都需要特别注意，对该问题进行适当修改，避免该问题因为过于“常见”，而让大模型自行发挥。
减少冗余输出
在使用大语言模型时,需要注意它可能产生过多冗余输出的问题。这种冗长而无条理的内容会带来以下两个方面的影响：
给用户的体验下降。过多无效信息会降低内容的可读性，用户需要花费更多时间筛选有价值的内容。
token 使用量增加，对项目成本形成压力。冗余输出直接导致 token 使用增多，提高了项目的运营成本。为了应对这种“啰嗦”输出，我们在进行提示工程时，需要明确告知大语言模型需要提供“简明扼要”的内容。此外，在提示词中举出详细例子，说明什么样的输出格式符合“简明扼要”的要求，也是非常必要的。通过这两种手段，可以显著减少冗长无效输出的情况。
文档命名与引用
在查询知识库的返回结果中，大模型会附上引用文档的文件名。我们可以将文档原地址与入库时的文件名直接挂钩。当用户对结果进行展开时，点击文件名，就能直接跳转到文档原地址。此操作不仅为用户访问文档提供方便，同时也简化了文档本身内容，无需在文档内容里再额外添加文档原地址。
多个知识库
在推广知识库应用时，我们发现知识内容的相互叠加，有可能对大模型回答问题的准确性造成影响。因为知识文档来自不同团队，可能在内容上有重叠，但向量数据库的 KNN 算法只根据向量临近关系进行查找，当重叠较多时，可能导致大模型回答不准确。一些业务场景一定要保证高准确率，建议单独针对此业务场景构建知识库。从成本上，OpenSearch 数据库已经无服务器化，按使用量计费；Amazon Bedrock 模型按使用的 token 计费，所以多个知识库不会在成本上有额外开销。
记录召回失败
在 Text2API 与知识库场景中，需要对召回失败的问题进行记录，并根据这部份记录，分析召回失败原因，并从中提取问题信息，通过优化提示词或者更新知识库文档，完成对应问题的补录。
建立反馈机制
在 Text2API 与知识库场景中，我们还可以建立反馈机制。用户得到结果后，对结果进行评价，直接评判大模型返回的结果是否符合用户预期。记录召回失败，是为了扩大问题覆盖面；而反馈机制，则是用来评判大模型处理问题的准确率。针对准确率较低的问题，则进行提示词或者知识库更新优化，从而提高整体准确率，提升使用体验。
建立知识库统计指标
针对知识库的质量，另一个比较重要的指标是它的访问频次。只有越来越多的人开始习惯使用它，我们才能判断该知识库是一个高质量且受欢迎的内部系统。所以建立统计指标，是知识库工程化的一项重要操作。可以针对问题类别、用户角色、涉及产品等方面，进行指标统计，从而更全面地了解知识库的使用情况。
搭建智能 Agent 的心得
在定义工作流程时，流程步骤要清晰，且尽量精简，以确保流程执行的稳定性和执行速度；如果 Agent 与 Lambda 之间的交互过多，有可能导致流程超时。对于每一步流程的执行细节，Agent 提供了 Trace 功能，Trace 里的信息非常丰富；建议以实际业务为导向，将 Trace 信息做适量筛选，以做 Agent 交互展示，确保流程执行的每一步结果，都可以被用户感知到。在知识库中定义的流程，需要有逻辑性，其引用的参数保持上下文一致；同时该参数在 OpenAPI schema 中的定义，也需要与知识库保持一致；确保同一个参数，在知识库和 schema 中，上下文都一致。
经验总结
《远光 84》项目组在生成式 AI 上的不断实践，也是对大语言模型的能力与应用场景不断学习不断创新的过程。在这个过程中，来自业务的实际需求，与对生成式 AI 技术原理的理解，两者相辅相成，才能不断涌现出新的想法与创意。
合作经验
Amazon Bedrock 提供了开箱即用的大语言模型和知识库产品，Claude 模型在语言归纳与总结上也颇有优势，亚马逊云科技技术团队则给项目组带来了生成式 AI 技术原理与客户案例；《远光 84》项目组提供了分层递进的业务场景与敏捷高效的研发环境；在两者的默契配合下，生成式 AI 在多个业务场景实现了快速落地，并为今后的发展与创新，提供了丰富的想象空间。
《远光 84》主程张星评语：“使用亚马逊云科技的 Amazon Bedrock 产品对我们来说是一个技术转折点。通过其先进的 AI 能力，我们成功地升级了多种工具链，大大提高了我们的工作效率。
总体而言，Amazon Bedrock 不仅满足了我们的期望，而且超出了我们的预期，为我们的团队带来了巨大的价值和便利。强烈推荐给需要提高工作效率和优化工具链的团队。”
本篇作者
张星
莉莉丝游戏 Farlight84 项目服务器主程。拥有十多年的互联网游戏项目开发经验，参与并上线了多款成功游戏。专注于游戏服务器分布式系统和容器相关技术栈，并具备丰富的多云架构实战经验。
付小飞
亚马逊云科技资深解决方案架构师，负责基于亚马逊云科技的云计算方案的咨询与架构设计。专注于游戏行业，帮助客户利用亚马逊云科技全球基础设施与强大的技术能力打造爆款游戏，降低游戏运行成本。
万曦
亚马逊云科技解决方案架构师，负责基于亚马逊云科技的云计算方案的咨询和架构设计。坚实的 Amazon Builder 文化拥抱者。拥有超过 12 年的游戏研发经验，参与过数个游戏项目的管理和开发，对于游戏行业有深度理解和见解。
郑昊
亚马逊云科技 AI/ML Specialist SA。主要专注于 Language Model 的训练及推理、搜推算法及系统基于 Amazon AI/ML 技术栈的相关优化及方案构建。在阿里，平安有多年算法研发经验。
星标不迷路，开发更极速！
关注后记得星标「亚马逊云开发者」
听说，点完下面4个按钮
就不会碰到bug了！
