大模型在数据管理和应用领域的实践

本文链接：https://blog.csdn.net/a2875254060/article/details/144220789

导读非常荣幸能在此与大家分享壹钱包在大模型应用领域的实践，本次分享内容将主要聚焦于大模型在数据管理与数据应用方面的实现策略。

前排提示，文末有大模型AGI-CSDN独家资料包哦！

具体分为以下五个部分：

壹钱包大模型应用现状
大模型在数据管理领域的应用
大模型在数据风控领域的应用
大模型技术架构及平台建设
问答环节

壹钱包大模型应用现状

壹钱包大模型的应用场景主要包括以下几大类：

营销触达：主要应用于中石油、商城以及积分等业务领域，可显著提升智能运营能力。
宠物智能社区：在社区中为宠物主人提供养猫养狗的专业知识，同时也会推荐和介绍与猫狗相关的产品，以此进行产品营销。
数据管理：将数据模型应用于数据治理场景，例如数据的分类分级、元数据的检索等。
风控运营：在这一领域，我们利用数据模型对风控可疑事件进行判定，包括地域风险、交易风险以及使用习惯上的风险等。

大模型在数据管理领域的应用

1. 场景 1：辅助安全&监管对数据的分类分级要求，可实现节省 90% 人力

数据分类分级是大家在日常工作中经常遇到的一项任务。过去，我们主要依赖人工进行打标，但这种方式存在一些问题。为了提升效率和准确性，我们今年建设了自己的数据资产管理平台，该平台集成了资产盘点、分类梳理、原数据接入、数据资产清单和信息检索等功能。

传统的分类分级方式，如依赖研发人员逐个对表进行标注，存在诸多挑战。首先，规则学习耗时费力，需要对研发人员进行大量培训。其次，由于每个人对分类分级的理解不同，字段注释也不确定，导致分类分级的准确性较差。最后，人工处理效率较低，无法满足大规模数据处理的需求。面对这些问题，同时考虑到集团对数据分类分级结果的高要求，我们决定尝试利用大模型来解决这些问题。大模型对规则和文档具有强大的理解能力，非常适合处理这类任务。

我们的做法是，将分类分级的规则作为基础知识，通过向量化，存储在向量数据库中作为知识库。同时，我们引入了 Prompt 工程，对我们的工作进行提示词的规范化编写，以便更准确地控制大模型的输出结果。我们的 Prompt 结构包括任务、上下文、示例、角色、格式、语气，并进行结构化的应用，以确保大模型能够产生符合预期的输出。例如，当我们询问金额的分类分级时，大模型能够产生一个标准的XML 格式输出，方便我们进一步处理。

2. 场景 2：大模型尝试实现元数据检索

数据检索对数据的注释及数字标注提出了较高要求。以往，我们主要依赖固定的关键字进行模糊匹配，但这种方式存在诸多局限，比如定位不够精准，查找过程繁琐，功能单一，缺乏扩展性回答和交互能力，且受众范围狭窄，主要局限于具备相关技术背景的数据开发人员。引入大型语言模型后，数据检索体验得到了显著提升。大模型能够自动生成元数据的中文描述，并精确查找相关信息，无需用户进行繁琐的预选择和预处理。

举例来说，当我们询问关于“年龄”的信息时，大模型会自动关联并呈现与年龄相关的表和字段，如“年月日”等字段，为数据研发人员快速定位所需信息提供了极大的便利。

再举一个例子，当我们询问关于“财富等级”的字段时，大模型迅速列出与财富等级相关的表和字段。同时，它还智能地联想并呈现出与财富等级类似的其他信息，如“风险等级”和“信用卡等级”，进一步丰富了数据研发人员的信息获取渠道，提升了数据研发效率。

3. 场景 3：大模型打标商品标签并迁移至用户，提升用户标签丰富度

我们利用大型语言模型对商品进行全面打标，模型会根据商品的品名及详细描述，智能生成多个相关标签。随后，结合用户与商品间的交互行为，我们将这些标签按一定权重合理地分配给用户，使得每个用户都拥有丰富且个性化的标签集合。在此基础上，我们进一步利用用户标签与商品标签之间的向量关系，为用户提供精准的商品推荐。相较于传统的关联分析方法和手工配置关联关系，这一创新方式显著提升了商品推荐的效率和准确性。

以一个具体案例来说明，当用户购买了一支球杆时，我们即可迅速判断其为体育爱好者。随后，若我们推出体育竞猜活动，便能迅速锁定这一用户群体，实现精准营销。这一过程不仅实现了标签的自动化打标，还形成了一个高效、全自动的业务处理流程，大幅提升了整体业务效率。

大模型在数据风控领域的应用

1. 场景 1：风控运营案件处理（30min->1min）

作为一家支付公司，壹钱包每天都会面临大量的风险支付案件，如反洗钱、账户被盗用、账户被盗刷等。在过去，我们主要依赖系统预设的风控逻辑来识别这些风险，并由风控人员人工处理。这种方式处理过程相对繁琐，风控人员需要综合多种信息来分析账户风险，可能涉及多个信息维度和多个查询页面，使得处理过程非常复杂且耗时。另一方面，风控知识庞杂且不断更新，不同的案件可能涉及不同的场景、知识和作案方式，要求风控人员具备广泛的知识面和快速学习的能力。对于新手来说，上手难度较大，需要长时间的实践训练才能逐渐适应。

为了解决这些问题，我们采取了以下三步策略：

第一步，我们构建了一个综合风控平台，将所有与风控相关的信息（如交易信息、身份信息、操作信息、余额信息和反查信息等）进行聚合。这样，风控人员可以在一个平台上获取所需的所有信息，无需频繁切换页面，大大提高了工作效率。

第二步，我们引入了大型语言模型对知识和问题的理解能力。我们采用 Agent 技术来判断用户风险，建设了工具代理、任务切分、记忆管理、分析反馈和总结输出等功能模块。这些模块协同工作，对案件进行多步判断，以更准确地识别风险。

第三步，我们利用大型语言模型生成最终的风控风险概括和处置建议。这些建议包括用户概况、处置思路和处置建议等，为风控人员提供了清晰明确的指导。

通过大模型的加持，风控运营案件的整个处理过程仅需一分钟左右，相比之前至少需要 30 分钟的处理时间，效率得到了显著提升。

接下来分享一下我们在处理复杂业务中应用大型语言模型的经验。在风控业务分析初期，我们采用了 OneAgent 方式，期望在一次对话中就能解决所有问题。我们的理想状态是构建一个强大的风控运营专家系统，这个系统基于大型语言模型，结合数据聚合、复杂 Prompt 和丰富的 Tools。

然而，在实践中，我们遇到了不少挑战。首先，对大模型能力的要求非常高。在前期测试中，我们发现 GPT4 等国外模型能够给出准确答案，但切换到国内模型时，效果却不尽如人意，这反映出国内大模型在能力上还有待提升。其次，处理大量 token 需要大模型具备一定的思维链能力。然而，在今年上半年，国内大部分大模型还不具备像 GPT4 那样的思维链能力，无法进行链式输出，这也是我们在实践中遇到的一个难题。此外，对 Prompt 的要求也很高，我们需要编写一个结构非常复杂、内容庞杂的规则集。但规则越复杂，调试就越困难，稍微改动规则中的一点内容，结果就可能发生巨大变化。这不仅增加了调试的复杂性，还降低了系统的稳定性。

鉴于 OneAgent 在实践中遇到的问题，我们逐步推出了 Workflow。由业务运营主导，把所有工作形成工作流进行分解编排，接着根据工作流对大模型进行多次调用，然后简化每一步的 Prompt，最后综合得出一个最终的结果。

2. 场景 2：电话照会剧本生成

第二个场景聚焦于电话照会剧本的自动生成，这是案件处理过程中的一个重要环节。有时，我们的风控人员需要致电客户，以询问相关信息来补充案件分析的细节。这就要求打电话的风控人员不仅需要对信息有较高的掌握程度，还需要全面了解情况，力求在一次通话中尽可能全面地提出问题，以减少对客户的打扰。这无疑对我们的风控人员提出了很高的要求。

在这个场景中，我们采取了以下措施来应对这些挑战。首先，我们将案件的基本信息、风控运营的指导规范以及类似案例的剧本整合成一套全面的知识库，并将其输入给大型语言模型。然后，大型语言模型会根据案件的具体信息，生成有针对性的询问思路，并自动生成召回剧本。有了这个召回剧本，风控人员只需按照剧本进行一问一答，基本上就能够在一次通话中获取到需要补充的大部分信息。这不仅大大提高了我们的工作效率，还降低了工作的难度。通过简单的培训，风控人员就能利用这个辅助系统快速上手进行召回工作。

3. 场景 3：管控建议及案件小结生成

第三个场景，在召会结束后，生成核查结果与管控建议。这一环节运用了两项关键技术。首先，我们将召回的剧本以及电话通话的语音转录文本同时提供给 GPT，GPT 则基于这两部分信息，自动判断该案件的具体管控结果与相应的管控建议。在生成管控建议后，若该建议指向结案，我们会进一步将风控判断报告、召回剧本以及审查结果等关键信息整合，提交给整体的大模型。大模型则利用这些信息，自动生成案件小结。需要强调的是，每个案件都需配备这样的小结，因为它是提交给人民银行的重要文件。

大模型技术架构及平台建设

1. 整体平台架构

接下来将介绍我们的大模型技术框架与平台建设情况。整体而言，我们的大模型建设遵循三层架构：技术底座、工程建设与平台建设。

2. 通过 RAG 技术实现基于知识库的智能回复

在实践过程中，我们发现，对于规模相对较小且需求多变的公司来说，微调的成本与效率并不十分契合，RAG 技术显得更为合适。但在实际应用 RAG 技术时，也遇到了一些挑战。首要问题是其召回效率相对较低，其次是大模型给出的召回结果整体质量不佳。

为了解决这些问题，我们经历了多次技术迭代，最终将传统的 RAG 架构升级为三层架构。第一层，引入了 IUR 组件，这是一个历史信息管理组件，旨在补充问题中的历史信息，从而提升召回的相关性和准确性。第二层，在向量知识库的基础上加入了 HiveToCache 架构，这一架构能够显著提升检索效率，无需再遍历整个数据库，即可直接从 Cache 中获取答案，从而大幅提高了检索速度。第三层，从向量知识库进行召回时采用 Rerank重排算法，对召回的知识进行排序，然后将排序后的知识传递给大模型，使得召回结果的匹配度得到了进一步提升，并提高了大模型对整体问题的回答质量。

3. 解决多轮对话问题 IUR（Incomplete Utterance Rewriting）

为什么我们要特别关注并解决多轮对话的问题呢？因为在很多实际场景中，尤其是在多人交流的场合，客户往往会引用一些隐性的代词。例如，当客户说“我没有壹钱包 APP”时，如果我们单纯地从这句话出发去做向量检索，很可能会一无所获，因为向量数据库中并没有直接对应的信息。

然而，在我们对系统进行了优化之后，情况就完全不同了。当客户提到“我没有壹钱包 APP”时，我们的 IUR 组件会立即从历史信息中进行搜索和匹配。它会发现，在客户提出这个问题之前，曾经询问过关于“怎么用积分兑换加油券”的问题。结合这些历史信息和回答，我们的系统能够重新排布并补全问题，将其改写为“我没有壹钱包 APP 应该怎么使用积分兑换加油券”。这样一来，原本缺乏上下文的问题就被转化为了一个与上下文紧密相关的问题。通过这个问题，我们的系统就能够有效地检索出相关的知识，并给出建议“你可以使用我们的‘小安加油’微信小程序”。

通过这一层的 IUR 组件进行问题补全，显著提升了召回的效率，对我们有着非常重要的意义。

4. 通过 Workflow Agent 技术处理复杂业务

我们也定义了一个内部的 Workflow 框架，该框架支持多 Agent 协同工作，并通过工作流和工具调用来完成任务。

那么，我们如何将 Workflow 技术应用于处理复杂的风控案件呢？我们主要将其分为三个 Agent 来处理。第一个 Agent 是规划者，负责理解问题并判断需要调用哪些工具和工作流。第二个 Agent 是观察者，负责观察工具调用的结果，生成数据分析结论，并判断是否需要再次调用工具。第三个 Agent 是总结者，负责总结现有的数据，生成任务的最终回复。这就是我们的整体流程设计。

以处理用户问题为例，规划者会首先理解问题，并将一个问题分解为多个步骤并生成一份处理流程报告。接着，观察者会分析规划者提供的处理流程报告，并分析用哪个具体的工具来执行每个分支流程，并依次执行，执行完后会得到多个中间报告。最后，这些中间报告会交给决策者，由决策者生成一个最终的答案。目前，我们通过这三个 Agent 的协同工作，已经能够完成整体的风控事件处理。

读者福利：如果大家对大模型感兴趣，这套大模型学习资料一定对你有用

对于0基础小白入门：