2024寿险科技应用高峰论坛——会后实录（下午）

中科软科技执行高级副总裁 孙熙杰

非常高兴今年又在古北水镇和大家见面，每年这个时候我都非常开心，因为有很多新老朋友在此相聚。

今天我们主要会和大家分享寿险MaaS平台的演进和应用，上午很多合作伙伴也都讲了，包括华为、阿里、腾讯都讲到MaaS平台，我们知道这个平台有两个大的方向：To C的大模型，To B的垂直领域大模型。两个方向其实有很大的差别，因为在通用大模型讲究的是大而全，垂直领域讲究的是小而精，所以应用就有很大的不同。大模型的专业能力依赖于模型、依赖于数据、依赖于训练、依赖于微调、依赖于如何与你的应用结合。我们知道大模型有着不准确的地方，这些地方在行业应用中需要避免，怎样通过行业解决方案解决这些问题。

中科软每年都会讲应用参考模型，其中一部分就是AI的MaaS平台。保险的专有知识包括词根表、样板程序，甚至是代码、产品库，包括开发运维过程中的各种Bug和问题的总结。这些知识在MaaS平台中是作为重要内容之一，模型需要很多知识的管理。我们也有很多的场景，原来讲的是保险+、互联网+，其实还有AI+，这跟传统的To C相比不同，ChatGPT可以回答所有的问题。行业中不存在这样的大场景，而是包括销售、产品、运营、风控，各个方向的各个细节需要借助人工智能的能力，AI加入这些场景以后，需要特别精细化的管理和评估，不同场景和应用需要的能力、数据和方法，我们就需要在这些场景解决大模型提供的能力和面临的困境。

无论是模型基座还是算力基座，我们需要开展一些数字化的工作，包括数据的训练和数据库的建立，评估训练效果好不好，在此过程中需要和应用场景结合，然后才能知道需要达到的能力。这些不是一次完成的，这个过程需要反复循环，原来这个模型的能力不太好，又有一个新的模型出来，可能需要实验这样一个过程。这是一个持续往复的开发过程，AI模型不仅需要应用平台，其实还需要开发平台，包括数据库的整理、模型的管理以及微调、数据库的处理和切片能力，怎么和保险数据、业务进行关联，通过关键词切片还是根据相关蓝图结构切片，都会造成很大的不同。我认为这种开发平台是工具很重要的抓手，所以要把我们的精力重点放在开发平台，然后跟我们的应用结合。

去年开始，我们就在开发MaaS平台，经过了三代迭代：刚开始是纯文本的单一模型，后来形成多模态，现在支持多用户、多模态，20多种大模型的发布，提供独立而个性化的服务。今年我们也会讲到场景的实验效果和实验成果，大量的产品库和合同条款，怎样学习这些条款？怎样围绕合同条款生成保险参数模型？怎样通过这些条款给客户选择更好的产品提供指导？原来的大模型很多东西是做不了的，包括费率问题，传统大模型不太准确。最近两天传得很火的就是9.9和9.1哪个更大，大模型回答的是9.11更大，因为11比9大。我们当然不希望给客户的回答中出现这样的结果，所以一定要结合大模型以及行业应用API一起解决客户的问题，所以这也是垂直领域大模型和传统大模型在行业应用中主要的不同。

平台功能+数据集管理需要大量的行业数据，包括产品和各种各样的问答，销售知识和销售管理提供25万以上的初步数据集和8万以上的语料数据集，为行业提供更多的便捷，能够做到快速试错。

我们也会提供模型管理能力，现在是百模大战，7B、13B的模型在训练和使用的过程中算力并不是很大，垂直领域的数据和推理能力、参数模型并不需要通用大模型那么大的算力，所以行业垂直领域需要小模型私域化部署，解决行业应用的功能，所以需要辅助模型进行管理。根据不同场景，模型的效果也不一样，包括文本识别、条码识别、Call Center、产品库等等，不同模型的效果和能力也是不太一样的。我们需要在合适的场景找到合适的模型，然后让我们的应用得到体现，所以需要跨模型的使用、管理、评估，下一次会有更好的升级，能够用一个模型解决所有的问题。

经过我们的测试和评估，我们认为MaaS模型在保险场景的能力已经完善，所以尽量通过这种模型进行训练和微调。

大家知道模型应用有两种方向：一种是微调，一种是RAG。微调是改变模型，RAG是在模型以外增加更准确的回答能力，可以进行微调和训练，准确度也会很强，我们会结合RAG工程和模型一起给客户场景提供服务。其中涉及到大量的分词技术和向量数据库技术，把保险的关键词汇切割，包括终身重疾切割成为多个词汇，理解和训练都是独立的。我们结合保险场景和产品条款、专业词汇，通过不同的分词方法建设不同的向量数据库和知识库的内容，结合模型回答各种各样的问题，解决客户的特殊需求，可以说是必不可少的关键点之一。

刚才讲到9.11和9.9谁大？问得好，模型会说9.9比9.11大，问得不好就是9.11比9.9大。我们针对保险场景增加提示词模板，进行提示词的增强，告诉模型这是什么产品、什么背景、什么方式，可以做到模型能力的增强，其中也有大量的训练、评估、测试的过程，可以提供很多训练的模板。

我们知道一个场景可能是多个Agent的组合和编排，所以可以定义应用市场，一方面是模型的能力，另一方面是RAG数据库的能力，可以接入系统API，通过内部的方式方法选择结果，是用大模型回答还是用RAG结合大模型回答，或者是用API得出一部分结果，所以我们会有一套编排方法和标准，通过我们的API在销售管理系统和知识系统中得到准确的数据，然后结合RAG和模型给出客户很平衡的回答。关键数据可能不是大模型出来的，而是应用出来的，完完成应用的调入、编排和组合。

服务的接入方式也有很多种，包括SDK、Web或者API，每个应用都相当于提供发布接口，能够很容易嵌入到应用场景，然后可以在场景中更方便地应用AI和大模型的能力。我们下一步会进行自动化运维，通过客户的描述准确地判断问题出在哪里。我们需要知道应用是怎么回事、存储是怎么回事、业务逻辑是怎么回事。

下面把时间交给我的同事张荣，为大家带来“新会计准则领航、AI驱动寿险管理创新”的介绍。

中科软科技寿险事业群技术总监 张荣

感谢在座的各位领导聆听我们的介绍和汇报。大家知道，今明两年I17的应用就会全面落地和推广。从会计的角度来讲，I17是一套新的准则，但它的影响是非常深入而长远的，会对寿险公司整体经营方法和产品设计提出直接的发展要求。I17作为发展的起点，我们看一看未来的业务管理方向会有哪些创新的要求，AI能力又可以在其中发挥怎样的价值。

I17和I9让会计准则发生了巨大的变化，让保险公司的利润更加清晰，披露的内容更加公开。作为每个企业来讲，这让我们原来经营管理的过程中被忽视、被掩盖的一些问题更加透明、更加公开。我们不得不面对和解决这些的以往经营中的风险点，包括收入的分拆和长期、分期地记录，直接影响到我们的承保利润，或者保险久期缺口等。这些一直存在的问题，现在更加凸显，资产和负债的波动性加大，或者是未来的考核体系也会随着现在计量方式的变化对精细度产生影响。未来保险行业的经营发展思路肯定要有一定的转变，这里选取几个方向给大家介绍。

首先是业务、财务、投资一体化。今天上午左总介绍的所有思路其实都在围绕这个观点，这也是未来的整个经营管理体系，原来是各自经营、独立管理，将来要强调更加协同和完整。

优化产品结构，快速应对市场。原来主要是在监管层面，给保险功能要求，现在通过财务会计准则的变化把压力转变成内生性的，不再是监管要求产品如何发展，而是从自身经营的要求、自身产品的承保利润角度，会更加关注保险产品的本质。

续期年限及继续率重要性加大。期缴业务的稳定持续，保证有效性才是未来发展的关键。

持续稳定计量，提升业务连续性。说这也是I17应用建设以后的关键能力。

今天上午左总提到管理会计，我们在做业务、财务、投资一体化的中枢就是管理会计。新的管理会计体系其实就是引导或者规划未来对企业经营以及内部管理的考核体系，所以我们提供了一套管理会计新的解决方案。

产品不仅是要优化结构，更重要的是未来应对市场端、投资端的变化，需要不断调整产品，所以产品的应变和响应能力才是未来对产品要求最关键的一点。现在这个领域也有很多智能化的方法，我们也会详细介绍。

续期的核心就是提升继续率，保证承保业务的价值，需要通过长期的继续率来实现，我们借助AI和大数据建立了全新的续期催收的能力。

智能运维的建设也是未来需要考虑的。

下面我们先看一看新会计准则给管理带来的变化。I17对保险经营影响就不详述了，对管理人员而言，关注的重点就是业务计划、财务预算和绩效考核，这是需要我们在I17框架下重新构建的。我们需要建立一套指标体系，面向指标体系进行数据分析和计算，建立辅助明细帐就很重要，是构建新的管理会计分析的基础。我们需要面向新的管理要求，从企业经营的偏差角度、市场变化的角度、监管方向的角度、绩效考核的角度引导业务发展并进行规划。

原来我们也有一些财务指标体系，现在需要在新的准则下进行细化调整，所以我们列出一些大的方向，就是监管的角度、财务分析的角度、绩效考核的角度以及业务管理的角度对整个指标体系有些方向性的变化，在每个方向都需要细化，落地到具体的应用场景。例如偿付能力是每个月都要计算和上报的，未来在新的会计准则下会发生变化，所以需要我们重点关注。风险管理体系也是如此，原来是注重过程，现在更注重新会计准则下带来的新的经营风险。业务指标对于新单承保价值，我们需要考察新的会计准则体系下在合同服务边际的变化带来的新单价值计算方法。

承保业务涉及到产品，不同产品在原来的体系下对保费收入的差别是不大的，但在新的会计准则下却有巨大的变化。这里的示例，展示了重疾险产品在旧的会计准则和新的会计准则下，一些会计指标的变化，包括收入的变化、支出拆分的变化，新旧体系下都有一些不同。这些差异，会带来业务端、销售端绩效考核指标的变化。

新准则下管理会计的经营分析体系是建立在大量数据采集的基础上，涉及到现有的所有业务端管理系统的数据、业务过程的数据，然后以财务的视角进行流水帐的拆分，细到每个业务过程中按时间、按行为的管理，把每个业务环节、每个涉及到的部门发生的业务，包括所有的支出和经营收入的来源都要细化，然后在明细帐上体现，我们才能建立起科学分析的应用。对上可以支撑企业管理人员经营决策，对下直接影响到管理会计对接所有业务端系统、投资端系统甚至精算系统，通过系统之间的互联实现业务过程中的直接影响。

面对这么庞大的数据，未来的管理会计体系需要进行呢大数据处理，所以我们应该引入大数据和AI算法模型，驱动和实现经营分析体系的建立。由于大模型的发展，之前很多厂商也在讲大模型发展下个阶段的方向，我们也会把这些经营分析的能力转化成为能够实现经营决策能力，直接影响业务流程，将所有业务过程中的决策由原来的个人判断转变为基于管理会计体系下经营分析数据支撑的智能体。当然，目前这个方法仍然处于发展过程中，需要不断地在应用中摸索，风险管控与经营效率二者之间达到相应的平衡。

接下来，举例看看要在新会计准则下，如何连接资产端和负债端，实现资产负债匹配的方法。首先从偿付能力出发做资产负债的策略规划，需要达到投资风险与财务目标之前的平衡，风险与收益的平衡，构建资产配置原则。在此大原则的基础上，在中间建立资产负债匹配的模型能，左边是负债端，右边是资产端，左边是承保业务，右边是投资业务。将所有承保的数据、产品的数据、再保险业务的数据，汇总到匹配模型来看负债端的需求，或者负债端能够提供的收入规模。我们在资产端需要满足这些负债端的需要，进行资产配置，衡量可能会产生的相应风险，然后看负债端是否能够承担和覆盖相应的风险。

前面我们是把管理会计的部分讲完了，接下来看一看产品管理。I17的政策落地使得产品结构优化一定是每家公司必不可少需要去做的，传统的产品结构体系下，利润考核会发生很大变化，所以就要求通过产品中心的建设提升产品管理手段。

原来很多保险企业已经构建产品中心，主要面向的是基本产品管理和基本产品交易服务。产品管理主要是实现产品参数化定义，把产品的资料，无论是条款还是相关的管理制度转化成为业务系统中可以识别的参数和相应的规则，这些是产品中心或产品工厂进行产品管理的主要内容，但其实这些对我们对产品的需要远远不够。我们构建参数化的产品模型，其实是把庞大的产品信息进行高度的抽象和提取，转化成为相应的指标数值或者编码，是信息量的高度压缩。好处就是带来很高的效率，能够对业务流程、规则的判断和计算快速支持，但我们面临营销、服务，包括政策的解读，这些涉及到对产品有更完整的、全貌的信息表达，仅靠产品模型是远远不够的。

智能化产品中心的核心就是构建一套产品知识体系，我们在这套体系下，除了提供最基本的保险交易支持，还可以提供应用服务。这套知识体系不是单一的某个知识库或者数据库的概念，我们称之为多信源产品知识库。我们的产品可以区分不同知识表达的形式，需要通过不同的数据结构承载相应的信息。不同的信息有不同的表达方式，也就有不同的应用，这就是多信源知识库体系中已经涵盖的不同种类的知识。

最传统的就是产品参数、产品定义、产品业务规则，涉及到精算计算和业务规则校验，此外有基于图数据构建的产品知识库，通过向量数据库建立的向量化文本信息，通过对产品信息的分析、加工和归纳建立产品画像，也就是产品标签库，文本标注和提示词的应用库，最后还一套监管规范，用来保证产品条款的合规性、规范性。这些知识库，有的是面向产品信息的，有的是面向产品AI应用的，有的是面向特定业务需求的，后续产品提供的服务也是对这些能力综合运用。

我们构建产品知识库以后，产品中心提供的智能化能力，包括资料的采集、产品的定义、产品的测试都有引入AI能力，以及产品中心对外赋能的能力，包括对产品的调研、检索以及各种内容的生成，都是通过这些应用完成的。

传统的产品定义都是由IT部门人工完成，好一点的公司有可视化界面，然后交给业务部门和产品部门，这就算做得好的了，但其实还是靠人工。我们现在提供的智能化方案是实现自动化产品定义，所有的产品介绍、产品制度的文本信息都可以进行数据采集，采集以后进行分类，分成若干类别，整理出具体内容条目，然后基于AI数据提取方案有两个方式,针对相对比较明确的定义和信息，或者是比较明确的标量，也就是数字信息，可以通过精准的匹配规则进行快速提取，对于描述性的信息需要通过文本标注摘取其中特定的信息，可以抽取复杂的、对产品的描述信息，特别是涉及到业务的规则，根据复杂的语言表述提取出这样规则的表达。我们依靠产品模型数据结构进行最终的数据汇集，批量生成产品定义。

这个应用，我们现在放到很多保险公司的核心业务系统更新换代项目中使用。核心系统替换，必须要在项目过程中把所有历史产品，无论是在售还是停售都需要迁移到新系统，让新系统满足所有产品对应的业务处理。一家保险公司可能有数千款历史产品，要是整个迁移过程都靠人工来做肯定需要耗费很大的工作量，所以通过这样的平台，我们可以快速完成。中科软也在打造行业端通用的产品知识库，只要对外发布产品条款，我们都会采集下来，通过这样的方式能够快速生成，构建产品知识图谱。

大家知道现在保险产品说明书也好、对外品宣的材料也好，监管都有非常明确的合规性要求或者规范性要求，当下都是保险公司自己的人在看。发布条款需要监管报备，营销需要宣发材料，都要找到各个部门审核，审核产品相关、业务相关或者法律相关的内容，但这个过程中会消耗大量人力，而且无法保证真正解决合规性要求的方方面面。我们通过这样一个智能审核的功能，事先已经采集70多个跟产品相关的监管机构不同时期的文件，涉及3000多个政策条目，最后大概有500多个业务规则，我们形成特定的提示词，这些就是大模型应用很有价值的一个场景。说白了，这个应用就相当于阅读理解，当你知道要达到什么目的的时候，就看阅读理解能力是不是到位，语言的理解恰恰是大模型最擅长的。我们能够把规则在提示词层面清晰表达和明确约束，就可以交给大模型来审核。先把条款内容都要进行条目化，然后针对具体条目针对性地检查需要面对的监管领域的合规性要求，逐条对条款内容进行审计。要是不满足某个监管描述性要求就会提示，甚至监管有相应的负面清单能力的话也会把相应的事例拿出来。

我们还有很多智能化产品应用服务，包括产品解读、产品问答，可以帮助我们对专业条款文件、产品资料通过通俗的语言、图文的方式为客户展示。我们要跟客户交流的话，怎么才能解释清楚呢？至少可以作为一个相对标准化的解读，包括To C和代理人培训的应用可以逐渐实现。个性化推荐不再是基于关键要素，而是基于宽泛的需求或者客户个人的特点，能够匹配某一类而不是某一个，同时，对于匹配有推荐价值的产品，以图谱的形式展现关联点在哪里，相关的关系可以做到更加精准化的筛选。

产品条款的自动化生成，和刚才讲的产品定义刚好相反，当产品知识库里面已经有非常多的产品，现在产品部门和精算部门想出一款新的产品怎么做？只需要在产品库选择、复制和适当调整，能够构建出新的产品，这个时候就可以用条款生成功能快速生成标准制式、符合公司自己要求和格式的条款。另外，客户也可以通过勾选方式，客户可以选择其中的一部分结构交给AI生成。

刚才讲到未来续期非常重要，对于如何才能有效和高效地提升？其实没有方向，没有手段，于是我们是对续期业务问题进行梳理，分析了哪些因素影响续期。一些保单根本收不上来，完全不值得花费精力。原来保险销售模式必然会给一些机构和代理人套利的机会，这一部分业务收不上来的可能性非常大。还有是因为客户关怀不够，客户都会抱怨买了一家保险公司的保险，从来没有联系我，只有续期收费的时候才来联系我，客户能满意吗？所以我们需要客户关怀。代理人可能只注重展业不注重续期，或者是薪资考核体系对续期业绩重视不够，导致客户的续期意愿不高。第三是续收管理体系太粗糙，我们只是要求给指标就要达成，但没有分析客户构成怎样，优质件、困难件占比到底有多少，通过详细分析才能真正给出指导。最后以往基本上没有什么信息化的手段，很少在续期层面建设系统，但我们认为这里是可以做文章的。

续期需要从几个环节分别入手，每个优化都要优化和改进，然后才能提高续期率。我们分为续前、续中、续后，新单、续收过程中、收费业务结束以后的每个环节都有相应的工作帮助代理人提升续期率。

想要提高续收业务，需要从根源上解决问题，新单业务质量高，续期就不会太差。现在有些套利业务，或是是存在所谓的灰产和黑产，确实是为了钻销售的空子，刻意地制造假的投保业务，我们要在新单进行筛选和防范，从客户的历史行为、客户的数据、客户的画像、代理人的历史行为、既往的记录，包括跟客户之间的关系、销售机构或者销售渠道的相互关系，把这些数据都汇总起来分析才能判断一个客户、一个代理人是不是存在风险。要是一个客户历史上退保率比较高，一个代理人以前因为市场促销活动带来利益陡增，这些都是可疑的。

前几天在中科软内部的互动平台上看到一个保监局的文件，要求报送代理人信息，一年内新单首期业务占比达到80%以上，首年续期继续率低于40%以上，从我们的视角来看，这个业务已经是相当可疑，有点过分了，从监管的角度也在关注。现在需要加强和提升承保的真实性，监管层面也是这样，保险公司不是早就应该把这个指标做好吗？

到了续收业务发生的阶段，前两个月或者前一个月就是宽限期末，在此期间怎样帮助代理人？如何分配业务？怎样帮助分析客户的状况？如何督导和预测？这些就是需要通过科技手段赋能续期的关键环节，为客户进行分类。一些客户是好的、优质的客户，一些客户就存在困难或者各种因素、各种情绪。我们需要针对不同客户进行能力划分，匹配对应的不同业务。

续期刚开始，我们需要让代理人主动拜访客户，或者通过自动化的外呼接触客户，了解客户的意愿。优质客户没有问题，有风险的客户就要加强跟踪和支持，服务的时候就要随时监控客户后续变化，包括进一步触达客户、尝试性地划分。我们需要建立风险预警，什么时候风险预警需要达到很高？细化的能力才是能够真正提高续期率最有效的因素。

除了某一个业务、某一个代理人的支持以外，公司层面也要有统一的指导方针，就是需要进行偏差预警。公司需要自上而下对续期业务足够的重视，给予足够的考核管理体系，针对历史数据分析，建立起基线标准，然后把任务下达到具体机构、具体渠道、具体团队，然后他们要基于这些业务分析实际的续期率，检查风险，提早干预和指导。

I17的建设其实是一个比较复杂的项目，最近两年保险公司的经营困难，I17投入依然不小，动辄上千万，这么庞大的项目不是建完了就没事了，这是一种长期应用，未来需要持续不断地运行，而且还要不断增强。以后业务规模越来越大，计量的复杂度也会越来越高，包括管理会计的体系都是基于I17计量的效率，在此基础上才能实现。I17稳定持续运营的能力其实是直接影响到企业经营的稳定性，所以重要性是很高的。

一个系统建设完以后，连续性的关键就是运维。运维是综合的、全体系的，不可能针对某个系统单独去做运维，所以是一体化的综合运维架构。运维管理中心作为中枢，主要是进行业务管理，基础就是集中监管平台，负责采集所有的细节数据，这些数据是运维最基础的保障。通过智能化分析进行数据分析、数据挖掘，包括异常行为的识别和对未来系统运行状况的预测，综合解决和防范系统风险，然后通过自动化操作完成日常临时的各种运维工作，此外还包括涉及各个组织架构的具体人员，也包括数据的应用和智能化。

全体系监控为高效运维提供保障，原来是基于不同的应用场景分类监控杆，现在变成全体系的监控，需要覆盖基础设施、计算服务、基础软件和业务应用，这里还需要涵盖业务交互，所谓的端到端应用都要纳入。I17业务不是单独的系统，会从核心业务系统贯穿到整个数据平台，然后再流转到财务相关的总帐、分摊、投资端，最后还要汇集到计量平台，这个时候就要监控平台贯彻整个系统架构，进行完整的监控信息展示。

在此基础上，我们构建AI Ops智能化运维体系，关键就是趋势预测和故障诊断。原来的运维是设定一定的阈值，触发以后就会预示可能发生的风险，但阈值的高低不应该是固定的，因为会随着业务状况和多个系统之间的组合而变化。通过这套AI能力，我们建立起了一套预测体系，不是针对某个具体指标来看是否达到关键的风险点，而是要看整个体系的运行状况，继续按照现有的负载发展下去，按照这样的趋势推测接下来会面临的状况。现在的重点不是发现问题、解决问题，而是预防问题，防患于未然。自动诊断就是需要建立一套知识库，帮助系统自动快速定位可能出现的风险点或者异常的原因，问题的本源都是通过既往的信息归纳，然后我们给出若干分析，需要包括大模型在内的综合AI能力。

总结一下：AI Ops要在经营管理、产品设计、渠道建设各个方面面向提升企业真正的核心价值，从利润的角度出发转变业务发展的基本思路，所以我们提供很多解决方案，包括智能化运维的能力。中科软希望通过我们的产品方案和技术实力为客户业务的稳定持续发展保驾护航。

南大通用金融部总经理 吴罡

各位领导、各位嘉宾，大家下午好！我是GBASE南大通用金融部总经理吴罡，下面由我与大家分享GBASE南大通用在金融业的全栈技术的创新与应用实践。

GBASE南大通用是干什么的？南大通用是专注于国产数据库产品研发与技术服务的专业数据库厂商。数据库又是干什么的？数据库是信息系统最为重要的底层基础设施。如果将企业所有业务系统对外扩展、罗列出来，数据库就是所有这些系统的数据安全基座。那么如此重要的基础软件，选择国产数据库需要注意哪些方面？到底是选择OLAP型数据库还是OLTP型数据库？主要数据类型都有哪些？需要离线分析还是在线挖掘？

在GBASE南大通用看来，这些问题没有标准答案，没有最好的技术，只有最合适的技术。

GBASE南大通用提供全栈国产化数据库产品，即：GBase 8Aa、GBase 8c、GBase 8s和GCDW，满足客户和合作伙伴的数据库使用需求。

为什么叫做全栈？我们是将产品融入实际场景中。任何金融机构都会有若干业务系统，包括承保、理赔、销售和400（客服系统）。不同的业务处理完成后会将相应事务放入交易型数据库，可以是集中式，也可以是分布式，因此我们提供了集中式、分布式两款不同的事务/交易型数据库，即GBase 8s、GBase 8c。整个交易完成后，根据甲方的业务需要，将所有全量数据存储到数据仓库，基于云化和非云化，南大通用提供云数仓GCDW和GBase 8a两款产品。经过大量数据的清洗、计算、筛选、管理，为后续的运营分析和显示提供业务决策支持，也为开发、运维、决策提供相应的数据支撑。

GBase 8a MPP逻辑数据仓库兼具OLTP、OLAP、NoSQL等多种大规模结构化与非结构化数据处理技术，通过数据虚拟化、数据联邦技术建立引擎间高效数据交换通道，融合复杂关联分析、流计算、图计算、批量处理等计算模型，构建对外统一，对内可扩展的大数据平台能力，能够适应不同业务场景，是构建企业大数据平台的重要基础设施。其主要应用于金融机构中的数据仓库、数据集市、报表系统、决策支持系统、运营分析系统、客户关系管理系统以及之前嘉宾提到的I17新会计准则等需要海量数据分析查询的场景中。

GCDW是南大通用推出的基于海量分布式大规模并行处理的多实例弹性云数据仓库，其核心特性是存算分离。根据业务的不断扩大，我们会将业务分为敏态和稳态两种，根据相应的需要可以决定我们的某些业务是否需要上云。上云的产品可以基于用户的需要将计算资源和存储资源进行弹性扩展和弹性扩充，这些就是云数仓的存在价值。目前，GCDW已经和国内主流的云厂商完成适配并上架商场，包括华为云、阿里云、腾讯云、金山云等，用户可以在这些云商城中登录，免费试用GCDW。以上就是南大通用两款面向大数据分析的产品，存算一体的GBase 8a和存算分离的GCDW。

GBase 8s是一款基于共享存储的集中式事务型数据库，其核心价值就是支持金融核心业务99.999%的高可用性。在2017年信创建设还未普及时，GBase 8s就已经替换了某城市商业银行的核心交易系统。核心交易系统作为金融机构最重要的信息系统，是核心中的核心，南大通用在2017年就实现了替换，证明了GBase 8s杰出的高可用能力。作为银行或者金融机构的DBA，数据库有多少炫酷的功能并不是大家关注的重点，基础软件产品是否可以安全、稳定、高效运行才是大家最为看重的。而南大通用GBase 8s其99.999%的高可用性，可以为金融机构提供安全、稳定、高效的数据处理能力，这是GBASE南大通用作为一家专业数据库供应商的底气。

GBase 8c是一款多模多态的企业级分布式数据库，支持行存、列存、内存等多种存储模式，支持单机、主备式、分布式等多种部署形态，可以部署在物理机、虚拟机、容器、私有云和公有云上，也可以达到99.999%的高可用性。南大通用在金融领域已经实现规模化的部署应用，具有大量的成熟案例及丰富的工程实施经验，尤其具备深厚的分布式技术沉淀，能够充分支撑金融机构核心业务系统基于分布式技术进行信创改造。

截至目前，GBASE南大通用已服务超过150余家金融客户，其中以银行业客户居多，包括四大国有银行的三个，建设银行、中国银行和中国农业银行，也包括政策性大行中国人民银行以及众多的股份制银行和城商农信机构，保险领域包括PICC财险、寿险，中投保等等。

PICC财险替换的亮点是使用GBase 8a替换原有的Oracle，采用Shared-Nothing架构解决了Teradata和Oracle不能线性扩展的问题，加上X86服务器以后，我们的性能提升10倍以上，2019年6月上线，迄今为止已经运行五年多的时间，依然在安全稳定运行。

中国农业银行总行的亮点是采用国产PC Server支持，开源的Hadoop框架加上自主研发的全流程配套工具，该项目荣获中国人民银行颁发的2017年银行科技发展一等奖。截至到今天，GBase数据库在中国农业银行运行的数据节点超过5800多个，总数据量超过100PB。该项目是2014年7月上线，已在中国农业银行安全平稳运行十余年。

中国银行数据湖仓项目最大的亮点是在国内首次采用国产服务器+国产操作系统+国产数据库的全国产化环境，很好地证明了GBase数据库在全国产化的环境下依然可以健康稳定地运行。

最后我想引用一首词作为本次演讲的收尾，这是我在国内一所中学看到的，让我非常深有感触：

目光所至皆华夏

五星闪耀皆信仰

愿以吾辈之青春

捍卫盛世之中华

生于华夏见证百年

愿山河无恙

祖国繁荣昌盛

此生无悔入华夏

来世还做中国人

作为一个深耕国产数据库二十年的专业数据库供应商，南大通用愿意将所有产品和解决方案贡献给所有中国企业，让我们一起为守护中国金融数据安全、推动国产化改造和数字化转型贡献力量，这是南大通用这样一个二十年致力于自主研发国产数据库的民族企业的信仰！

大家人寿信息技术部总经理 赵杰

行业峰会提供了很好的学习交流平台，大家人寿几年来个险数字化转型的情况向各位领导、各位专家做一个汇报。

近几年，监管对数字化转型与金融科技发展提出了明确要求，自上而下提出了金融数字化转型的总体要求。2019年大家人寿启动个险业务转型，对数字化建设提出了提出了极为迫切的要求。产品要回归保障，要从无到有建立个险渠道，我们有19家机构，但是网点很少，当时线上化服务几乎没有。从科技侧来说，有很多的技术债，核心系统已经用了10年，技术栈陈旧，对保障型产品缺乏支持，各端基本没有数字化应用提供业务支持。

大家人寿乃至集团的决策层、管理层基于多年对市场的深刻理解，对个险业务设计了非常好的转型蓝图，一是扁平化的分账模式。改变金字塔的交易结构。二是事务所和合伙人的组织载体。用“合伙制”探索组织发展模式。三是专业的支持体系。建立数字化、平台化的专业体系。

个险转型走的这条路可能是别人没有走过的，控制试错成本非常重要。因此我们必须选择一种敏捷的方式，业技充分融合，科技需要走到业务前面一点，用数字科技帮助业务快速迭代。

具体的建设路径，我们提出“五化”策略，“客户服务线上化、业务支持场景化、运营风控智能化、费用管理精益化、支撑能力平台化”，要建立新一代数字化平台，用数字化手段破局。

数字化平台的建设我们认为必须分层来做。但是这个层怎么分？我们首先要锚定服务对象，保险公司有合作伙伴、有内勤员工、有渠道、有客户，这些服务对象都需要有各自的数字化应用，但是应用开发很容易做成一个个烟囱，能力很难积累。所以要有支撑各端应用的“数字基座”。

“数字基座”我们分三层，最上面是业务中台服务，下面是数据交换平台，中间是核心，换言之，服务要上升，数据要下沉，然后让核心可以向分布式进化。

我们的新核心系统2020年用6周就完成上线，去年启动并完成老核心数迁，完成了数百款产品千万件保单的迁移，先盖好房子再搬家。我在20年前经历过核心系统换代，当时光是业务验证团队都有上百人，现在我们没这个条件，只能创新科技手段完成任务，我们这一次核心数迁是不停机迁移，按产品逐单迁移，业务完全无感。

对于最下层的基础设施，我们的策略是实现资源云化，现在从头自建机房太贵了，时间也不允许，我们用云化资源实现应用上云。

应用建设从架构的角度来讲，所有数字化应用都使用新的技术栈，迈向分布式，前后端分离，不做大单体应用。在客户端，我们建立了新一代的线上服务数字化平台，所有服务应上尽上。保单签收、回访、保全、理赔全部线上化。我们今年一季度有100万件保单满期，满期领取几乎全部都是客户在线上完成。线上还有我们的养老服务，包括养老权益查询、函件的确认签收以及行权。我们的养老服务很有特色。我们的养老社区建在市中心，在北京我们的三个养老社区都在二环边，不仅离医院很近，还能够感受到人间烟火气。

在销售端，个险“大家王牌”APP不仅覆盖到代理人个人营销活动的方方面面，还支持事务所的经营。对于代理人高频使用的功能，我们的目标是做到简捷快捷。比如我们提供家庭版的计划书，客户通过计划书可以在线上“一次投保、一次缴费、一次双录”，保单也整理成一册。对于业务一定会用到的功能，我们早做准备，比如名单全生命周期管理，我们提早动手，从名单筛选到名单下发，再到任务推送和营销追踪，在业务有想法的时候，功能已经就绪。我们把这些能够做的、应该做的事情放到最优先的位置。我们的个险业务非常给力，去年就做到了12.6亿，新开个险渠道的公司，我们是最快达到10亿规模的。

在运营端，我们的目标是数智化，能让机器做的，就不让人来干。特别是运营风控，我们花了很大力气建立了覆盖事前、事中、事后嵌入式智能风控体系。比如前面提到的百万件保单的给付，即便是万分之一的差错率，也将给公司造成很大损失。我们通过自动化风控手段，在给付前把保单历史轨迹拉出来，账户价值从头到尾背靠背再算一遍，哪怕有1分钱的差异，阻断并报警，尽最大可能保证交易安全。我们的智能双录平台把双录与投保流程无缝集成，单证自动展示，语音自动播报，质检实时智能，完成一笔双录平均只需8分钟。

在费用端，对各家来说防住“跑冒滴漏”都是很大的难题。我们的财务很给力，建立了端到端全流程覆盖的销售费用管理模型，费用怎么赚，账户怎么建，费用怎么花，弄得明明白白，然后全流程实现线上化、标准化。这背后其实是财务的精益化管理，我们通过规模摊薄成本，然后在边际上寻求突破。我们这么大体量的一家公司，银保位居市场第二，费差不仅打平还有费差益。

平台端就是业务中台，行业里凡是大张旗鼓做中台的几乎都失败了，我们觉得中台是沉淀下来的，不是做出来的。中台我们是边干边建，把各端需要公共能力，可复用的能力沉淀成共享服务。比如通过建设个险销售移动端，我们积累了线上投保服务能力，现在这个能力就可以直接复用到银保，乃至新开通的渠道。对于服务而言，合理的抽象服务定义是很重要的能力，IBM提出SOA服务导向的架构，以及CBM、SOMA等方法论都是很好的可借鉴的财富。

基础设施我们实现了全面云化。要感谢集团的大力支持，支持我们使用公有云服务，前面介绍的各端应用以及中台目前都已经上云，所有的微服务部署在容器云平台，资源可以实现秒级弹性扩展。同时我们通过公有云具备的能力实现了同城双活，今年的灾备演练是实打实的，停掉了一个AZ区，流量自动实现了切换，应用使用完全不受影响。仅是灾备这一项就节省了大量的投入。我们数字化平台使用的云上的中间件和基础软件都是国产厂商提供的，平台安全自主可控。

通过业务、应用以及基础设施的转型，我们个险业务大踏步的往前走，去年新保保费12.6亿，新业务价值3.9亿。去年保费市场排名第十八，现在已经到了第十二。我们线上化客户比例近9成，官微绑定客户超过500万，客户服务的自动化水平领先行业，中台服务已达到10亿次的服务调用，支持2000TPS出单。全部数字化应用100%实现容器化部署，100%实现应用上云。最近几年我们也获得很多行业的奖项，新一代分布式核心建设荣获人行“金发奖”二等奖，公司荣获中国银行保险报2022年“数字化转型十佳机构”，这些肯定和鼓励更加坚定了我们转型的决心。从投入来说，去年IT全部投入占到整个公司营收的0.18%，行业平均大概0.65%，大公司0.56%，IT全部投入占到公司年度总投入费用的1%。我们用较小的成本，实现了对业务转型的支撑。

数字化没有完成时，永远都是进行时。个险数字化未来要做的事还很多，我们还要埋头苦干，一力向前，希望各位领导、给专家能够给予更多的指导和帮助。

中电信数智科技有限公司金融企业客户部总经理 朱为佳

尊敬的各位来宾，我是中国电信数智公司金融企业部负责人朱为佳，非常荣幸有这样一个机会给各位嘉宾汇报这样一个题目“中国电信大模型赋能保险行业数智化转型”，主要分为四个章节：

第一部分既不谈发展也不谈技术，聚焦一个问题，就是垂类大模型在当前中国社会存在的价值和意义。我们谈到人工智能大模型就会听到两种截然不同的声音，一种认为是无所不能的，包括铺天盖地的广告宣传语，另一种认为是名实不符的，我们自己其实也说不清楚到底解决什么问题。要是论成本的话，性价比摆不到台面上，要是说场景大模型，其实是不够普遍的。因为大模型的公平性、鲁棒性和准确性不能同时兼具，就是由于大模型的不确定性和随机性导致在很多垂类应用场景不能寄予太高的期望。

前不久有一个机构做了实验，保险合同文本的解析，提供五级大模型，输入“截肢”两个字，有的判定为轻症，有的判定为烧伤，只有一个判定为重大疾病。我们跟保险公司聊天的时候他们也说科技应用研发的成果，我们没有胆量使用。实话实说，当前的社会除了高端智能包括军工产业，大模型既没能营收创利也没能降本增效，为什么国家还在千行百业布局大模型？回答这个问题可能要从更高的站位、更宽广的视角审视，得出一个相对客观的结论：

中美博弈一个主战场就是科技战，其中的核心是芯片战，再其中的核心是算力战。中美科技战2019年达到最高峰，华为发布第一款人工智能国产化芯片，此后的三年中国放话，芯片实现国产化，至少说明一个问题，中美科技战的爆发点就是人工智能的智算算力。

现在全世界都有一个共识，2024年是第四次工业革命的历史元年，标志性事件就是人工智能。什么叫做工业革命？就是生产效率100倍的提高，要是提高3-5倍顶多算是高质量发展。人类历史上有三次工业革命：蒸汽机时代、电气时代和信息互联网时代，每次都是100倍以上的效率提高。人类历史正是由于这三次工业革命，创造的GDP相当于人类五千年历史生产总值的90%。第四次工业革命也不例外，过去拍个小电影几十个人干十天，现在有了大模型一个人干三天。

人工智能是什么？就是效率、就是博弈、就是未来，如果能够从中美博弈和第四次工业革命的角度来看行业中的垂类大模型，大家就会理解为什么国家密集出台这些红头文件，能够在千行百业布局大模型。前不久国资委开会，97家央国企董事长齐聚一堂，只探讨在行业中部署大模型，场面壮观，历史罕见。

第四次工业革命这个赛道的玩家现在只剩下美国和中国两个玩家，核心竞争力还不太一样。美国的核心竞争力是两点：一个是数据，因为全球联网，所以他们的语料是中国的数百倍。另一个是智算算力的制高点，以NVIDIA和马斯克为代表。中国的核心竞争力在于拥有全产业链制造能力，也是唯一垂类大模型可以在行业进行渗透的国家。整个人工智能竞争的本质其实就是美国To C的AI对阵中国To B的AI+。如果能够了解大模型历史发展经纬的本质，回头看一看发展垂类大模型是否还有必要聚焦那一点价值，应该投入国家千行百业布局大模型的伟大事业，共同见证第四次工业革命中美在人工智能领域的又一场巅峰对决。

大模型全栈产业链的视角，下面的是算力、数据、通用大模型、智能体，制造业的话可能还有智能制造，包括X光机、机器人等等，这里还有运维、安全和交付。整个大模型的产业链中，每个服务商都有自己准确的定位，不管是腾讯、阿里、百度、华为还是三大运营商。有的是工业大模型，有的是研究算力，有的是做数字一体化工具。中国属于全技术栈的大模型一体化，布局时间比较早。中国电信本身也有公有算力和私有算力的布局，提供数据的输出和服务，包括自研的一体化平台和智能化平台。

目前大模型的商业模式主要是两种：工业化布局，通过通用大模型引流公有算力资源池，包括GPU租赁获取一部分的价值和壁垒。私有化部署，智算中心的建设、GPU的集采、通用大模型的调用、工具的代销、数据标签的组成。既懂数据，又懂业务。

保险行业垂类客户的应用主要包括几个场景：营销、运营、风控、客服。营销主要是高效触达、精准获客，运营主要是通过智能图像、语音、场景，风控包括风险识别，客服主要就是智能客服和座席培训。

银行和保险应用比较多的就是个人征信平台，传统的风控模型能够解读300-400个不同维度的数据，但通过图计算、自然语言处理锻造出来的智能征信大数据平台至少可以理解40万字，通过优化模型降低投保和信贷的风险。智能客服包括安全选择、语音导读，但识别不出对象的情绪价值，更不要提二十四小时不间断的服务，可以通过数字人和大模型提高用户感知度。

目前保险行业垂类大模型包括几个主要痛点：算力资源、数据隐私、专业人才、合规监管，中国电信针对这些痛点提出相关的解决方案：

算力在私有化部署的过程中，千行百业基本都差不多：稳定性不足，网卡、服务器、内存和硬盘，能想到的地方都不太好使。平台搭建成本很高，至少需要两到三天，自己还需要考虑服务器的管理、算法的融合、系统安全等等，方方面面一个都少不了。最要命的就是性能和成本，大模型训练是以月计的，微调是以天计的，每秒算力的效率只有50%，要是再加上H800、A800就更加困难。

中国电信提供两套解决方案：依托于云网资源顶部打造公有云智算底座，超大规模的智算中心2500台GPU服务器，31个省都有自己的算力资源池，也把算力延伸到边和端，整个架构耗资100个亿，我们也有打造智能计算的架构平台，就是AI的IaaS，其实就是网络计算存储资源的总和，把基础资源层和训练虚拟层的性能进行优化。私有算力布局，主要包括这样几个方面：GPU集采+智算总集、跨域多云算力调度，面向计算、智算和超算的资源整合实现跨区域、跨服务商和跨技术架构算力的整合。以租代建算里租用，因为场景不是很明确，大部分拿到的标书基本都是算力租用。算力车满足轻量化需求，银行对这方面非常感兴趣。

我和很多保险公司合作的时候，他们上来就提对中国电信的很多用户数据很感兴趣，中国电信的用户数超过10亿，全部加起来125PB，每天新增1PB的数据量，都是To C，包括通讯、消费、位置等等，中国电信也是首家把大模型运用到湖仓一体化的运营商，对外提供更高质量的数据服务，包括数据治理、数据标签、数据安全等等。

2023年初，中国电信发布百亿参数级的星辰大模型和千亿参数级的语音语义多模态大模型，虽然排名不在前三或者前五，但至少中国电信的星辰大模型是三大运营商中首个发布的通用大模型，央国企首个开源通用大模型也是首个在网信办备案的通用大模型。

训练、推理、研发、运营、服务一体化的大模型平台，要是非要问我们跟BAT这些大厂有什么区别，BAT的大模型平台确实成熟度、标准化程度都很高，但不能提供定制化开发，我们可以结合用户的场景进行定制化开发，提高大模型训练、研发和交付的效率。

其实大模型的研发和交互最核心、最要命的就是大模型的工程化，底座、人员、数据训练出来的大模型千差万别。中国电信虽然能力一般、水平有限，但架不住千行百业赋能，我们总结出了一套大模型工程化的方法论，包括场景选择、高质量数据集建设、融合、研发和交互等等。

最后做个广告，中国电信数智是中国电信的全资子公司，也是中国电信下属专注于产数业务的专业化公司，全国3.5万人，去年收入300亿，云网数智安赋能金融、央企、政府、军工、运营商五大行业。我们在大模型的市场定位和布局是依托中国电信资源禀赋，包括算力、通用大模型，市场竞争中也有形成三个差异化优势：智算总集，既是集团化也是市场化，拓展的过程中肯定是中国电信的产品、能力、资源，同时更多的还是第三方，因为我们的目标是市场、核心是客户。训推一体化服务，可以帮助客户进行聚焦和产业升级，让金融客户把有限的时间和精力放在核心竞争力上面，把低端的工作甩出去，形成技术密集型，劳动密集型，相得益彰，各取所需。

路虽远，行则将至。中国电信数智愿意和广大保险客户在大模型时代凝心聚力，携手同心，与时俱进，共创辉煌。

招商信诺保险信息科技部总经理 张琦

今天很高兴和大家一起交流和分享，我代表招商信诺跟大家分享I17的方案供大家参考。

I17应该是从2017年正式开始，已经运营了七八年，这些年来已经经历了很长时间，应该是2020年以后，国内的I17逐步开始落地和实施，我们其实对I17也是很重视的。在此过程中，我们经历了很多思考和研讨，有些经验可以跟大家分享，可能这些介绍更多的是从厂商的角度或者专业人士的角度。最近几年，保险公司的声音很小，好像都失声了。

招商信诺认为I17是缺少可参考成熟经验的复杂系统工程，本身是缺少成熟的业务实践作为参考的，面对的挑战如何解决？背后的结果还是保险公司的信息化。大家知道2020年以后，一些大型公司已经在落地实施，但我们也是遇到了很多的挑战。招商信诺一直非常关注这个过程，可以看到实施的过程中遇到了很多的问题。招商信诺2023年具体启动实施，大概是今年7月，围绕这几点认真思考：

I17有着大量的新增数据，其实对信息化建设和系统设计会带来巨大的挑战，无论是成本还是性能。

I17属于一个全新的流程，至少是在I4的基础上新增完整的业务，整个实践应该是I4的3-5倍。我们如果2025年到2026年真正实施I17，内部的人员操作也会加倍，而且不止1倍。

I17跟我们息息相关的就是整个方案设计，不管是前期四大咨询公司还是后续方案，其实都提得很清楚，但会遇到一个问题，本身逻辑是对的，没有问题，但实际上会有大量的数据增量，也会带来巨大的挑战。

保险公司会计帐本身来看其实和其他公司没有太大差异，I17就是针对寿险公司来做的，中国是充分拥抱I17，所以给了我们一个巨大的机会和挑战，就是实现欧美不可能实现的事情。保险公司的会计帐到底是什么？基本逻辑是很清楚的，就是保单，所以2023年7月以后围绕保单记帐进行认真分析，I17的保单到底发生了什么事情？整个前期方案为什么会有大量复杂度的分析？

图中显示方案需要确立基本范畴，就是一张新保单记帐，毕竟还是以新规则为主，我们认为把原来的很多流程进行放大，原来是实收实付，现在已经不是那么简单了，因为有精算专业，能够把原来保险公司里面的运作模式全部展开，带来的问题就是现金流处理，当前处理和将来处理，理论来说每个月都要处理，整体上是全量数据。

现金流处理分为两步：原来业务数据传过来就行，现在变得相当复杂，等于是完全展开在实际业务系统中展现，实际上比我们当时想象的还要复杂和困难。第一年需要处理，后面十几年还要处理，而且每个月都要对全量保单定义出来，数据的计算量变得非常大，存储量也会变得很大，查询量会变得更大。

I4原来是中小型保险公司，费用分摊不会特意拿出来，但是I17是真处理，所以出现子帐和费用单独分摊，造成至少需要新增2-3个系统。

测算虽然不是特别精确，但量级是相对比较现实的。我们按照每月10万张保单，涉及到数据中台，包括存量的数据，如果是10万张保单新增的话，按照1：3就是将近6000万，1：2的话就是4800万，后面的计算都是以4800万计算。存量保单的数据就是30亿，每年新增就是12亿，要是涉及到分单和子帐，这里的问题是光有数据量并不足够，所以不是单份，大概是6份，相比招商银行可能不大，他们是我们1000多倍，但对我们后面的设计、方案的选型和实施都有非常大的影响。要是选择错了，即便上线也跑不动，就算能跑动，一个月的数据需要跑两个月，运维成本可能是我们无法承受的。

我们自己的运维预测分为三步：充分考虑技术可行性，切忌不切实际，一切需要从数据计算和评估出发。充分考虑数据一致性，业财一致非常重要，我的理解是对不上，唯一能够对上的只有现金流，上半个月财务、IT加上绩优精算，下个月又开始了，所以是非常痛苦的事情。我们充分考虑一致性，不光是一套规则，至少需要考虑两套。现金流层面一定要对上，对不上的话很多问题可能就无法解决。充分考虑流程复杂性，要是I4没有做这件事情，流程复杂了3-5倍，现在不管是业务部门还是IT部门，很少有哪家公司专门为I17准备业务，流程变得更复杂的话，数据需要上传下载修改，可能会影响整个流程的处理。不管方案最初怎么设计，这三点都是非常重要的。

技术层面和设计层面相关的有几点，我们2023年就在考虑哪些技术上用得上的：

传输的问题非常大，传递的过程中还要保证时效性、准确性，包括自身的数据处理效率非常重要，T+1很难满足，要是没有标准手段的话，信诺觉得还是很重要的。

存储主要是成本和性能，去年到今年其实有些差异，我们选择需要一些取舍，信诺这样的保险公司唯一选择的就是存算分离的结构。因为我们的数据量没有达到那个层面，所以在设计上去做存算分离，翻上10倍也是够用的，但是百倍千倍作用可能就不是那么明显。

计算也是I17带来的巨大问题，因为可能产生非常大的计算量，要是传统的关系型数据库SQL，即便是目前常见的计算方法，性能也是有上限的，造成的风险极大。但正好赶上AI技术大发展，我们利用华为昇腾910B GPU显卡计算方法替代传统cpu计算，实现IFRS17高性能计算和低成本的突破。在去年年底就做了基本测试，使用1个亿的保单数据，得到满意的结果，新质生产力在行业中得到突破，树立保险行业标杆。

查询主要针对的就是高性能，传统的存储或者查询方式基本上无法承受，最近两年我们也在考虑这样选择。目前来看成本下降非常明显，性能给了我们很大的信心，包括硬件投入和分摊计算都可以提供高性能。

I17的基本方案就是基于保单，其实没有太多的特殊性，整体上就是前面介绍的那个逻辑，所以总帐其实挑战不大。我们可以说3-5倍都是比较保守的，原来就是精算和财务的过程，面对I17的挑战没法完全展开。

系统技术设计包括几点：流批一体决定数据处理是实时的，既然流程那么复杂，如何进行非流一体的数据处理？存算分离主要是涉及到查询、存储和私有，核心业务数据会归档，回到MySQL。这样带来的优势就是成本非常低，要是单纯考虑一体化数据库，MySQL是不够的。要是把存算分离拆开来看，基本就是X86服务器，甚至都不需要存储，因为本来就是分布式。如果只是为了存和查，DORIS倒是一个很好的选择。

最后分享一些我们的实测情况，主要介绍关键指标：存储和查询，无论是DORIS还是MySQL，我们的4800万保单就是当时做的费用分摊标准的SQL，标准的X86服务器应该就是21分钟，按照现在的要求，这么大的数据量基本上扩展MySQL和DORIS都是做不到的。MySQL至少需要20小时以上，DORIS大概只需要7-10秒钟。我们总共做了6000万数据，1200万是新单数据，加上5000万的存量，按照标准的方式可能是乘以10，计算的速度大概是1分钟跑完，所以计算速度是完全可以接受的，剩下的主要是加载数据，毕竟有20GB的数据需要加载，然后还要至少1个来回，所以需要9分钟。我觉得这也可以接受，至少作为招商信诺是完全可以接受的。