我要投稿

LLM 在腾讯游戏数据分析的实战

发布日期：2025-08-16 18:18:07 浏览次数： 1521

作者：DataFunSummit

微信搜一搜，关注“DataFunSummit”

导读大语言模型（LLM）的发展正在改变数据分析的方式。从传统的代码驱动查询，到自然语言直接交互，LLM 赋能的“AI+BI”能够提供更为智能、灵活的高的数据分析体验，大幅提升工作效率。
在游戏行业，这一变革也正在发生。游戏业务数据量庞大且实时性要求高，分析场景复杂多变，从玩家行为分析到运营活动效果评估，都需要依赖大量的数据分析作为支撑，“AI+BI”也自然成为了一个重点方向。然而，在实际业务场景中，LLM 处理复杂数据需求的能力以及交付结果的准确性，仍旧面临诸多挑战。
腾讯游戏数据团队从早期便开始了 LLM 在数据分析工作上的应用探索，在服务腾讯游戏旗下多款千万级 DAU 头部产品的过程中，积累了大量实战经验和技术方法论。在近期举办的“DataFun AI+BI 智能驱动峰会”上，腾讯游戏数据技术负责人刘岩围绕 LLM 在游戏数据分析中的实战展开了分享，涵盖数据提取、分析链路构建及业务落地等关键环节。

内容目录：
1. 基于大模型的数据提取

2. 从数据提取到数据分析

3. 从工程验证到业务应用

4. 未来展望
分享嘉宾｜腾讯游戏数据技术负责人刘岩

编辑整理｜DataFun志愿者峰宾

内容校对｜郭慧敏

出品社区｜DataFun

01
基于大模型的数据提取

1. 数据分析的流程

游戏精细化运营时代，数据分析的重要性在不断提升。游戏数据分析的常见场景主要包括可视化经营分析、明细数据提取，到归因和预测，因此，我们探索的主要方向也是 AI 在这几个方向上的提效和赋能。

数据分析的流程体系本质都是这几个步骤：第一，理解业务需求；第二，理解数据；第三，准备数据，对数据做清洗加工；第四，数据建模；第五，验证数据并最终交付。这个流程是固定不变的。如何让 AI 参与到这个流程的各个步骤里？AI 的能力边界是什么呢？这些便是我们工作的重点。

2. AI 代理的模块化架构

AI 代理的模块化架构可划分为记忆系统、推理执行系统及环境感知系统三大核心：

（1）记忆系统

参数记忆：基于模型训练参数构建的底层能力，包含预训练模型固有的知识与技能（如 DeepSeek、OpenAI 等大模型的基础能力）
工作记忆：通过提示词工程实现的即时任务指令，当前多数 Agent 系统通过提示词直接调用模型完成任务
语义记忆：通过构建领域知识库、语义资产库及上下文扩展机制，增强模型对专业领域（如 Text2SQL）的语义理解与知识调用能力
情景记忆：记录用户交互历史及应用环境状态，包含多轮对话记录与场景上下文信息

（2）推理执行系统

采用 ReAct 循环机制，集成模型的推理能力与工具调用能力：

逻辑推理：基于当前上下文与任务目标进行多步骤推理
工具调度：动态选择适配的外部工具与知识源
自适应优化：根据任务进展实时调整推理路径

（3）环境感知系统

构建多模态感知能力，实现环境交互验证：

界面感知：通过浏览器自动化等技术实现网页操作的环境感知（如 Manus 的订票场景实现）
数据感知：建立输入输出校验机制，确保数据操作符合业务规则与预期结果

该架构通过模块化设计实现智能体的认知闭环，参数记忆与工作记忆构成基础认知层，语义记忆与情景记忆构建知识上下文，推理系统驱动任务执行，环境感知系统则通过实时交互验证确保行动的准确性和可靠性，共同构成具备自主决策能力的智能代理系统。

3. 数据工程应用

在数据提取场景中，核心挑战在于 Text2SQL（文本到结构化查询语言）生成的准确性。当前主流模型在测评数据集（如 Spider 2.0、BIRD）的性能表现不尽如人意：在理想条件下，表现优异的模型可达到约 70% 的 SQL 生成准确率，尤其在处理复杂查询时准确率显著下降，无法满足实际业务场景的需求。

针对这个问题，通常会通过构建“新一代 AI 数据资产”和“人机协同的 Workflow”两种方式进行优化。“人机协同的 Workflow”方面，我们将数据提取流程进行精细化拆解，明确界定人工介入环节与智能代理（Agent）的执行边界；通过需构建多轮交互机制，持续的信息确认与反馈迭代替代单一查询指令，以提升复杂场景下的任务完成质量。

我们构建了“新一代 AI 数据资产”，这套资产体系的核心评价标准聚焦于“AI 可理解性”，通过系统化的知识表征与语义建模，确保各类数据资产（包括但不限于结构化数据、业务规则及领域知识）能够被 AI 系统有效解析与应用。这要求资产体系在构建过程中遵循语义标准化原则，通过元数据标注、概念图谱构建及语义关联建模等技术手段，实现从数据存储到知识表达的范式转换，从而为 AI 系统的智能推理与决策提供可靠的支撑。

基于 AI 数据资产，腾讯游戏数据通过工程化的方法提升 AI 在复杂需求上的交付准确率。举例来说，和数据工程人员的工作流程一样，当大模型接到一个复杂的提数需求时，第一步会先把这个复杂的需求拆解成若干个子需求；第二步就是根据每个子需求生成 SQL，这一步会跟 AI 数据资产进行联动；第三步则是资产沉淀，每个需求对应的资产和特征，通过子需求进一步拆散，这样可以沉淀更细粒度的资产，下次会被其他需求用到。

通过这一技术方案，腾讯游戏数据团队的 AI 游戏数据提取在场景下能做到 90% 的准确率，已经达到实际业务应用的及格线。

扫码入群参与讨论

✅ 对分享有疑问？群里问！

✅ 有心得体会想分享？群里聊！

✅ 想深入某个点？群里讨论！

扫码入群参与讨论

02 从数据提取到数据分析

回到整个数据分析流程来看，数据提取只能帮助业务准备基础数据，但到了数据的分析和解读环节，之前一直没有合适的开源模型可以完成，因此业务拿到数据后还是需要人工进行分析——然而，今年年初 DeepSeek 的发布，让事情有了新的转机。

1. DeepSeek-R1 带来的变化

如上图所示，左边是闭源模型在不给到企业业务数据的情况下可以安全使用的能力：资产上，只能给一些源数据、专业术语和语义资产；推理上也只能做一些代码生成的推理；在工作流上，也无法选择 MCP 的协议或者 ReAct 等模式；在应用上，只能止步于找资产、写 SQL 这样的应用。

上图右边则显示了 DeepSeek-R1 带来的变化，可以看到，开源模型部署到本地打开了很多想象空间。同时，因为 DeepSeek 也开源了自己的训练方法，给我们提供了很有价值的技术思路，提升了我们对于做游戏领域本地小模型的信心，并且也获得了一些成果。我们还可以把数据给开源模型，做更复杂的 WorkFlow 架构，以及数据总结、框架分析、探索研究等更多的应用。

2. AI 原生数据分析

基于 Agent 或者 ReAct 架构，有一个理想的数据分析状态：用户提出问题，做完意图识别，直接交给大模型，让大模型去做流程编排，自主选择工具、选择资源、选择 Agent，一步一步自动完成整个任务。

然而，这一理想状态也面临着现实挑战。大模型在 BFCL、Tau-bench 等基准测试上单次任务执行时准确率能达到 70%，但如果要求连续 8 次尝试均保持正确结果时，准确率会骤降至 20-30%。这也揭示了当前 Agent 架构在复杂任务执行中的核心问题：在复杂任务执行时存在准确性与一致性矛盾。这一问题在需要严格保证结果一致性的数据应用场景中，单纯依赖当前 Agent 架构存在显著风险，必须谨慎评估其适用性。

03 从工程验证到业务应用

1. AI 流程架构的选择

如今主流的 WorkFlow 架构有下图这四种。

第一种是经典的 Agent 架构，就是让模型来做即时的实时推理。这个架构最大的问题是回溯能力，也就是大模型对于自己出错的问题无法追溯，比如第 5 步错了，大模型不知道是因为第 4 步导致的，这可以说是现在 Agent 架构最致命的弱点。

第二种是在即时循环的基础上进行，在任务来了之后，先做一个 todo，然后模型再按照计划一步步执行。

第三种是基于决策树的深度搜索，简单来说是预先给模型一些规则，让模型在这些规则的基础上自主规划流程。这样的话，稳定性就会提高，但是灵活性会丧失。

第四种是纯 WorkFlow 引擎，用工作流引擎把每一步执行什么都规定好，一个任务来了，就按照这个步骤去调 Agent 执行。

这四种模式可能会永远并行下去，在做整个应用的模型架构时，最终都呈现混合架构，在不同的场景选择不同的流程方式。

那么，腾讯游戏数据又是怎么做的呢？前文提到，数据分析的流程是固定的：业务理解-数据理解-数据准备-建立模型-模型评估，这五个步骤。我们认为，在做 Agent 的应用时，期望大模型一步到位完成这件事并不现实，应当从“人是怎么做的”这个角度出发来规划工作流程。基于这个理念，我们搭建了下图这个流程架构。

数据准备的过程相对来说是固定的：理解需求、找数、取数，然后最终看数据和数据质量是否合适，这样的规则可以提前预制给模型的，用预制结构加上节点 MCP 自主调用，这样既能保证准确性，又有一定的灵活性。

而数据分析的过程则涉及相关性、因果性分析及分类，需根据需求灵活选择算法与模型。其核心流程为：先通过模型制定分析计划并执行；再基于前序输出与原始数据进行评估，模型自主选择合适的算法，形成基于 ReAct 架构的分步执行与反馈机制。

在整个数据分析的体系中，我们会在不同的流程阶段将不同的架构和技术进行组合使用，让大模型在每一个主流程里，根据不同的问题，单节点去选择还需要调用哪些外部能力来完成流程协作。

2. 从模型能力到工程能力

在从传统 Agent 架构向 Agent AI 体系过渡的过程中，安全与架构体系发生了根本性变革，主要体现在两个关键维度：其一是数据作为核心输入要素直接作用于模型训练，其二是架构体系从单一本地模型向分布式混合架构演进。这要求我们必须重新审视安全风险防控体系：如何确保数据使用的可信性、构建可验证的安全机制、建立模型行为的可度量标准，成为架构设计的核心命题。

对于业务应用而言，以下两个关键问题始终是上线审核的前置条件：

数据权限管理是否完善？（包括数据访问控制、权限隔离、审计追踪等机制）
数据准确性是否有保障？（涵盖数据清洗、验证、溯源等质量保障体系）

以“游戏知识库 MCP”为例阐述一下如何通过工程化的方式保证召回准确性。

在 RAG 方面，最简单的做法是把游戏官网的数据爬下来放到本地，去做 Embedding、做召回、做 Rerank，甚至做知识图谱。但是这样无法解决 Embedding 和 Rerank 的精度问题。我们在实践当中发现，如果只用模型和算法技术来解决问题是不够的。因此，我们的游戏知识库把一部分数据结构化解析，例如道具信息，时间信息，活动信息结构化存储，除了做向量的召回，还需要做标量的召回。

例如：用户发起一个问题，“SS31 赛季 M416 相比上个赛季有什么变化？”解决这个问题，首先需要先得到赛季时间，确保搜索到的所有知识都在这个赛季里。如果用向量查询只搜索 M416，就会得到很多与这两个赛季无关的东西，这样最终提供给业务的数据就是不准确的。在得到赛季时间之后，去找到想要的实体，在实体里根据标量查询的信息，再去做向量查询，这是一个整体的逻辑。

3. 从工程到应用的要点

第一，速度和稳定性是体验的核心

腾讯游戏数据团队在实践中发现，我们在选择模型的时候考虑安全、性能、速度、成本等因素，而是应当根据需求选用最优方案，也就是选择最合适的模型。

举个真实场景的例子，在用户发起一次 query 之后，我们需要给用户回答，在这里我们意图识别模型使用 DeepSeek-R1，问题改写使用 DeepSeek-v3，知识库检索用的是 qwen3-235b，时间范围识别模型用的 GPT-4o。只是在识别用户意图的环节，我们就用了这些 Agent，并尽量保证每个 Agent 都选用性价比最高的模型。

第二，准确性是用起来的底线

大模型的幻觉是一个绕不过去的坎。针对这个要点，业界一个主流的方案就是做一个校验 Agent。虽然校验 Agent 也会有幻觉，但相比输出分析结论的 Agent，校验 Agent 的关注重点在数据的准确性上，这样能缓解幻觉的问题；此外，校验的过程也是拆分步骤进行的，不需要一次校验太多，分片校验再把最终结果返回，也能提升准确性。