腾讯游戏数据领域大模型：如何让AI更“懂行”

近年来，大模型在人工智能领域取得了显著进展。从ChatGPT的横空出世到DeepSeek的迅速崛起，AI正在重塑各行各业的未来。其中，DeepSeek凭借低成本、高性能以及开源策略，迅速成为行业焦点。随着其广泛应用，DeepSeek成功破圈，进入更大众的视野，使AI技术逐渐平民化。

然而，尽管DeepSeek这样强大的通用大模型能够在广泛的任务中表现出色，但在一些特定领域落地应用中，仍面临诸多挑战。例如，在医疗、法律、游戏等高度专业化的领域，通用模型可能无法充分理解复杂的领域知识或满足严格的合规要求，从而限制了其提供更深层次服务的能力。

因此， 为了在特定场景中实现更好的效果，自研领域大模型成为必然选择。 领域大模型通过针对性的数据训练和优化，能更好地捕捉领域特有的模式和知识，从而在实际应用中提供更精准、可靠的解决方案。当前，已有多个自研领域大模型面世。

在构建领域大模型的过程中，常见有三种方案，如下图所示，即 检索方案、微调方案和预训练方案 。这三种方案的应用，使得自研领域大模型能够更精确地理解和处理特定领域的数据与问题，从而在各种专业领域中发挥更为显著的作用。需要特别注意的是，这三种方案并非相互排斥，而是可以在构建领域大模型时被综合运用。

•  检索方案

通过检索相关信息来辅助大模型的输出，业界又称为检索增强生成。此方案，首先使用检索系统来查找与输入查询最相关的信息，然后将检索到的信息作为额外的输入传递给大模型，帮助模型更好地理解上下文并生成更准确的输出。此方案主要依赖于现有的检索系统和较小的生成模型，所以成本相对较低，但效果通常受限于检索系统的准确性和覆盖范围。

•  微调方案

在特定任务或数据集上调整预训练模型的参数。常见微调方案分为全参数微调和参数高效微调。全参数微调是指调整模型中的所有参数，而参数高效微调则是只调整模型中的一部分参数，或额外增加一部分微调参数。微调大模型的方案直接针对特定任务进行优化，通常需要更多的计算资源来调整模型参数，相比检索方案的成本较高，但通常能够获得更好的效果。

•  预训练方案

在大量的无监督领域数据上预先训练大模型。为了确保模型具备更好的表征和泛化能力，通常会在训练数据中加入通用数据。预训练方案可分为从头预训练和继续预训练。从头预训练是指完全从零开始训练大模型，继续预训练则是在一个已经预训练的模型基础上继续训练，以适应更特定的数据或任务。预训练方案需要大量的数据和计算资源来训练模型，所以相对前两种方案的成本最高，但因为模型能够学习到更丰富和更广泛的知识，所以通常提供的效果也更好。

智能商业分析，是大模型落地的一个重点方向。在该场景下，用户提出一个分析需求，系统先给出取数的SQL代码。然后运行SQL获取数据。再对数据进行分析，产生洞见并做可视化展示，以此辅助经营决策。该场景下最基础的技术是Text2SQL能力，即用户输入一段文本，模型给出正确的SQL查询代码。

在大语言模型的赋能下，Text2SQL的效果不断取得突破，但在实际应用过程中，仍面临诸多挑战。这里以一个生活的例子做比喻：如果把大语言模型比做大厨，用户比作顾客，则SQL查询就是大语言模型提供给用户的美食。食物若想做得美味，除了厨师的厨艺要好，还需要几个关键要素：一份清晰的菜单，明确顾客想吃的食材、烹饪方式以及口味等；一批合适的食材，正所谓巧妇难为无米之炊；以及一套趁手的厨具，用以将原始的食材烹饪成最终的美食。想象一个极端的例子：顾客上来点了佛跳墙，而厨师手里只有一条鲈鱼一口锅。

具体到Text2SQL所面临的挑战，首先用户提的需求往往是口语化表达，存在歧义、省略等问题，会对大模型的理解造成挑战；其次业务的数据资产往往是海量的，大模型需要全面了解数据资产，选取合适的库表来完成需求；最后对于复杂的需求，如嵌套子查询、窗口函数等，大模型往往很难一次性做对，也会影响最终的使用。

为这些应对挑战，腾讯游戏数据搭建如下的系统架构，来提升大模型在Text2SQL场景下的准确性和效率。

其中，需求理解算法通过检索业务知识，识别并消解歧义，补全缺省的业务知识，从而生成更加准确的SQL查询意图。需求匹配算法通过多路召回、统一粗排和大模型精排，帮助大模型快速定位和选择合适的库表。最后需求转译算法通过提示工程，引入分步推理和迭代优化的机制，提升复杂SQL查询的准确性和执行效率。

上述三个算法模块，都有涉及构建领域大模型的相关实现，限于篇幅，下文将以 需求匹配为例，具体阐述如何自研领域大模型。

需求匹配是从庞大的数据资产库中，筛选出与需求相匹配的数据资产一起喂给大模型，从而才有可能写出正确的SQL代码。如果不给数据资产信息，则大模型会幻想资产信息来生成SQL代码，得到的结果往往不能满足需求。此外，如果多添加额外的资产表，也会对大模型的理解造成干扰，导致生成的SQL代码效率低下或者错误。在下例中，用户查询活跃人数时，实际仅需活跃用户表即可满足需求。然而，如果额外添加一张付费用户表，大模型会错误地将活跃用户表与付费用户表进行关联（join），从而生成一个查询活跃且付费的用户子集的SQL代码。

因此，为了获得正确的SQL代码，还需要精确地检索到与用户实际需求相契合的数据资产。借鉴传统的信息检索方案，提出如下的需求匹配方案：首先使用多种策略，从资产库中多路召回候选资产表。其次通过粗排流程，进一步缩小候选资产表。最后通过精排流程，用来筛选出最终的资产表。召回和粗排考虑性能因素，采用了传统NLP模型来实现，而精排是通过微调大语言模型来保证准确性。

精排流程的输入是用户的需求描述+候选资产表的结构信息，输出是精确匹配需求的资产表。该流程要求模型具有很强的语义理解能力，既需要理解用户需求，还需要理解资产表的结构和关系等，因此选用大模型来实现。而通过微调，可以使大模型更好地学习业务知识及分析人员的用表习惯，从而更精准地为需求匹配合适资产。

在实现时，是使用Lora算法对大模型进行参数高效微调。Lora算法通过优化适应过程中，密集层变化的秩分解矩阵，来间接训练神经网络中的一些密集层，同时保持基座模型的权重不变。Lora算法相比全参数微调对计算资源的需求小，对比其他参数高效微调方法更加稳定。在微调后，通过将秩分解矩阵融合进原始的权重矩阵，可以避免在推理时引入额外的推理耗时。

在微调大模型过程中，会面临诸多问题。

首先，是训练数据的缺失。用户的需求描述很口语化，例如：“A渠道春节摇心愿、普通活跃”。基于这个原始的需求，很难匹配精确的资产表。为此，首先使用数据增强技术，将业务信息输给大模型，让大模型反向生成清晰的需求描述。如下图所示，越丰富的输入信息，大模型生成的需求描述将越清晰。其次使用数据合成技术，进一步丰富训练数据的数量和多样性。

其次，在微调过程中，因训练数据存在部分过长样本，导致微调后的模型会有概率输出为空，影响选表。这里设计了一个提示压缩算法来压缩过长样本，在保留样本量的前提下，解决输出为空问题。同时为提升模型在实际落地时，推理的效率，优化了大模型输出编码的方式，减小大模型选表的时间。

最后，为了保证大模型的精度，会为每个业务单独微调一个模型。同时为了控制成本，在部署时，采用了一个基座模型+多个Lora的部署方式，可以同时支持多个业务的请求。这里逐步尝试了串行、并行以及如下的CUDA算子融合方案，不断地提升大模型的服务吞吐量。

在经过需求匹配算法的处理后，上述例子可以匹配到正确的数据资产，从而让大模型生成正确的SQL代码。

通用大模型的技术在持续地快速升级，前期的幻觉问题，知识实效性问题，当前都能得到较好的优化。然而，当在具体业务场景落地时，因为缺乏业务知识，导致通用大模型要产生实际应用效果还面临一些挑战。通过自研领域大模型，可以有效地解决这些挑战，使得大模型更好地服务业务。

在自研领域大模型时，如果领域数据不会高频地发生变化，而且有足够的计算资源和领域数据，可以优先选择参数高效微调。其在生成的效果和使用效率上，会比检索方案更高。而检索方案更适合领域数据更新频繁，或对可解释性要求高的场景。此外需要特别注意的是，这两者彼此之间不是互斥关系，可以在微调的基础上，再进行检索增强生成，以便取得更优的效果。

>>>延伸阅读推荐

腾讯游戏数据团队发布了《大模型工程化：AI驱动下的数据体系》技术书籍，总结沉淀腾讯游戏数据工作的实践经验及技术方法论，系统阐述了如何利用大模型技术打造高效的数据资产体系，为AI时代的企业新基建和智能化转型提供参考。

点击下方，立即购买👇