尊敬的各位来宾、合作伙伴、新老朋友们，大家下午好！每年峰会的下午第一场都是中科软团队的主题汇报，每年一次的汇报，都会针对一些行业关注的热点和痛点问题，给出我们的观点、看法和一些探讨思路，同时也汇报一下我们相关工作的进展和落地实践。
中科软成立以来，我们每年都会举办一些技术比赛，近几年的技术比赛内容都是有关大模型的。大模型已经成为现在的热点，我们作为行业头部的ISV，一直关注并紧跟技术发展趋势，同时不断探索如何把先进技术转化成落地应用的生产力，给客户进行赋能。我们技术比赛的内容包括了对大模型基座的选择，如何蒸馏并简化基座，包括领域知识库的构建、领域知识的数据治理，提示词工程构建以及RAG的构建和搜索技术等等，以及包括对一些流行开源软件的工具和平台的技术路线选择和使用中要注意的要点等等。作为行业的头部ISV，希望能够站在客户角度去思考，摸清相关技术的脉络和相关技术难点，以及落地到场景应用的探索，先行先试，我们先探探路，踩一些坑，这样可以给我们的客户提供更可行的技术和应用路线的选择，同时也能提前储备一些人才。
今天我的演讲题目是“基于小模型的保险认知管理模型驱动保险价值链重构”。
大家都知道现在人工智能的发展越来越快，大模型的能力也越来越强，大模型无论是数据规模还是参数规模都有了显著的增长，展现出来更高的准确性和更出色的泛化能力以及更低的应用门槛。而且大模型本身的进化速度非常快，远超过了摩尔定律。按照METR团队的研究表明：大模型能力每7个月就会翻倍。过去6年的数据也验证了这个预测。现在大模型在TO C端，表现的非常好。我在手机上每天都在用秘塔搜索、豆包、Kimi等等，的确给我们的工作和生活带来了极大的便利。但在TO B端，对于企业应用来讲，我们也有很高的期望值，但一直没有爆款的应用。大家都在说要打通最后一公里，为什么这么难呢？有很多因素，其中一个因素就是领域知识，涉及到大模型要跟领域知识库的深入融合，因为像保险行业这样受到强监管的行业，它需要精准的答案，不能是大概、可能什么的模糊的答案。
我们知道大模型都是以多模态数据存储的，包括文本、文档、图片、语音、视频等等。它的推理方式是基于归纳推断的，也就是从个别到一般的推断，是一种联合概率推断。使用的是向量的计算，而向量计算方式是相似度计算，比如余弦相似度。通过这种方式进行概率统计，所以精准度上会有一定差距，
为什么大模型会有幻觉？其实最根本的原因就是大模型的本身生成机制，大模型本质上是一个概率模型，既然是概率，就一定有偏差。在大模型的底层机制没有改变的情况下，我们更多是通过工程化的手段，去降低风险，约束偏差。年初的DeepSeek爆红也是一样的，虽然没有大的技术范式创新，但是带来很多工程化的创新，也是革命性的，包括用的MOE的专家模型，包括FP8的混合精度训练，多头注意力机制等等。正如咱们国家的基建工程能力世界第一，工程是咱们最擅长的领域。
我们说大模型的落地场景应用本身是个系统工程，既然是工程就要用工程方式去解决，其中构建领域的知识库至关重要。领域知识库以关系型数据库及知识图谱的半结构化文案或图数据库存储为主。他是我们的标准答案，是长期积累、锤炼而成的成果物。他以形式推断为主，是通过键值查找，所以查询速度更快。我们解决大模型的幻觉的方法是，可以给大模型划定边界，让他在边界内回答问题，就相对比较精准。而这个边界就是领域知识库。
在没有大模型的时候我们的领域知识库也是应该去构建的，保险属于典型的数据密集型行业，拥有大量的数据。而数据是我们的核心资产，但是以前数据的作用基本上还是辅助性为主。随着大模型时代的到来，保险公司数据的价值被极大释放，数据被赋予了更高的战略价值。从现阶段来讲，他可能受重视的程度和投入方面可能还是有一定的差距，但应该是个趋势。因为数据越来越成为驱动保险价值链的重要力量。
现在大模型落地场景应用有两种技术路线并行发展：一个是大而全，一个是小而精。大而全就是大模型，大算力、大数据、大参数，动辄几百亿、上千亿，整个计算能力、理解能力、泛化能力都会比较强，但往往意味着高成本的投入，制约大模型应用落地很重要的因素之一就是算力成本。小而精顾名思义就是小模型，小算力、低配置、可本地部署，同时又是比较少的数据量。大模型应该是越大越好，小模型就应该是越小越好，因为投入成本很低，训练和迭代速度都很快。而行业落地是以实用和精准为目标，所以小模型是我们认为行业垂域大模型落地到场景应用的一个比较可行的路线。大模型和小模型是相对的概念，因为大模型的发展才促进了小模型的机遇，二者并不矛盾，选择小模型更多的是基于投产比的考虑。现在保险行业已经进入到新的发展阶段，从追求速度和规模向以价值和效益为中心转变，都在精细化管理方面下功夫，强化算账经营。
我们现在的小模型是基于大模型蒸馏而来的，在性能损失可以接受的情况下，成本却下降了99%，所以在企业端应用小模型逐渐成为趋势。未来行业落地场景应用是以小模型为主，大模型为辅，需要的时候可以调用位于远端的大模型。
行业应用为什么没有大面积铺开？根本原因在于行业垂域应用有它的特殊要求，就是三个条件“低成本、高精度、强安全”。
“低成本”，就是成本越低越好，低到什么程度？能够在现有BI的运行环境下，不需要增加太多额外的成本就能够运行，是我们可供参考的指标。当然这除了基座选择，以及尽可能的简化优化之外，还涉及到需要把业务场景细化，把场景细化到更小的粒度，让小模型只处理单一一个功能。细化的核心思想在于化整为零、分而治之的方式，其实我们处理很多问题也是这种思路。因为现在底层技术更新得太快，我们需要考虑兼容性，尽量保留已有的工作成果。从设计角度来讲我们希望是最优解，但是具体到落地应用时寻求一种满意解，达到一种平衡。所以我们未来场景应用的时候可能会有很多小模型。
“高精度“，我们的保险行业是强监管的行业，需要标准的数据集比如权威的语料库，因为要精准。大模型主要是基于对多模态数据的处理，所以领域知识库建立本身也是系统工程，除了把数据收集过来还需要清洗、去除数据噪声，进行聚合性的预处理，包括聚合和叠加。要形成高质量的数据集才能让大模型的落地应用更精准。现在都是一些结构化数据存储在SQL数据库，可能只占到20%-30%，70%-80%的非结构化数据更加丰富，还没有被充分利用。随着大模型技术的发展，会给我们提供更丰富的多模态数据的融入手段。所以说企业自身领域知识库的建立至关重要，有了优质的数据才能使大模型的能力发挥得更好。这是最基础也是最重要的工作，台上一分钟，台下十年功，在数据方面投入再多都不过分。所以我们说对于行业大模型的落地应用，是三分大模型，七分知识库。一会儿我们同事会针对数据治理、数据管理方面做详细汇报。希望大家明白数据资产要远远重要于所谓的技术壁垒。
“强安全”，涉及到数据保护整体的机制问题，包括访问控制、权限管理、隐私计算等等，还有数据脱敏的问题。保险是强监管的行业，本身还有合规性的考虑，也包括大模型的训练数据来源合法性问题，输出内容的合法性问题，模型的权重和版权问题等等。我们使用了大量的开源的东西，需要遵守相关开源的规则。开源并不是无主之地，尊重原创是我们技术创新的底线。
今年6月份腾讯科技和Linux基金会创始人吉姆泽姆林有个对话，吉姆是开源运动的领导者，他预测未来AI基础模型可能都是要开源，而竞争只在应用端。开源和闭源大概的界限在哪里？离客户越近的地方越容易闭源，越远的地方越容易开源，谁对应用端理解能力更强、用得更好会形成一定的壁垒，这就是行业Know-How。
今年年初DeepSeek的爆红引发了行业应用落地的加速，各行各业都出现了相应的大模型，但是没有出现爆款级的应用，也就是银弹。主要是没有满足低成本、高精度、强安全等三个落地应用的条件，更多是实验室验证或者POC，就是证明可以用，但是能不能好用这个不好说，所以离落地还有很长的路要走。
涉及到很多场景，包括文案创作、代码编排、知识问答等等，总结起来就是对半结构化数据的四个处理功能：搜索、摘要、对比、生成。搜索就是找到相似的文档集合，因为精准的需要，所以尽量使用监管以及权威的语料库。摘要就是要简化所需内容纲要，是特征分类的概括表达。而对比是做定性定量处理的关键，所有定性的东西都存在约束层（条款及规定等约束文件），但是我们相关的数据存在记录事实层（检测及监测记录文件），对比就是要做约束层特征分类和记录事实层分类的匹配。生成是由有经验的领域专家形成高权重数据集，与约束层标准答案数据一道，成为精准计算数据集。在黄金范文指引下生成各种报告。这个报告有点像公文一样，有严格的要求，力求精准，要极低幻觉的。
我们来看企业认知模型资源管理平台，首先看行业应用的管理模型，它分成环境层、记录事实层、约束层和评估层，包括合同的全周期管理和运营管理，运营管理包括计划、完成以及相关的人财物协同的安排。在新的数字化浪潮中每一层都在发生变化，变化最多的就是环境层，包括各种各样资源虚拟化，包括合同发票电子化、行为数字化以及服务线上化等等，会融入更多多模态的数据。之上是记录事实层，就是业财一体化，把数据按照某种主题联系起来。而环境层和记录事实层是我们现在行业应用软件主要发挥作用的地方。再上面的约束层和评估层分别是交易分析一体化和智能化评估，是人工智能大模型加入之后引发变革最多的两层。
我们再看看企业认知模型，就是企业怎么构建知识体系或者知识管理的模型，包括数据、信息、知识和智能，这四层跟我们的管理模型每一层都是一一对应的。数据是真实的记录，信息是有上下文的结构化数据及非结构化数据语义对齐。我们现在的行业应用软件系统群主要是对数据和信息的操作。而知识是有意义的信息，经过人工/自动标注的半结构化数据织料，是多模态数据的预处理部分。智能是富有洞见的知识，是基于小模型的垂域模型MAAS平台。而未来现有的行业应用软件系统群也会扩展到广义行业应用软件，也就是智能行业应用软件，他包括了现有的行业应用软件系统群，多模态数据预处理管理软件和基于小模型的MaaS平台，这三者的集成就构成了广义行业应用软件。保险是知识密集型行业，基于半结构化数据的知识管理会成为下一步的热点。
大模型的到来扩展了我们认知边界，使我们认知能力有了极大的提升。而认知能力的提升带来了我们对于保险价值链的重构。从原来的线性价值链变成了从风险感知、智能一体化服务、客户运营、口碑营销、规模效应和生态网络，正向循环的飞轮效应价值链。
首先来看风险感知，由于生态多模态数据的聚合，形成了更强的标的和风险感知能力，才能开发出更丰富的产品和组合方案，满足客户的个性化需求。曾有一个保险公司领导开过一个玩笑，他说我们精算师费劲巴拉在算费率精准到小数点后面几位，而我们的业务人员在谈判时一下子就把小数点前面一个1去掉了，因为小数点前面是由市场决定的。你永远挣不到你认知范围之外的钱。因为我们对风险的洞察很多是不够的，所以产品同质化比较严重，没法开发出更丰富的产品组合。随着更多的多模数据聚合之后就有了可能性，对客户也有了智能一体化的全方位服务，通过模型能力的加持，把优秀的业务人员的经验加以积累和沉淀，提升整体人员的专业素质，为客户提供专业化的服务。通过对客户全过程数据的洞察，为客户提供全方位的智能服务,包括智能核保、智能客户服务、自动理赔服务等，提高客户体验，增加客户粘性，获得客户的高满意度与信任度。
保险行业是服务行业，客户运营至关重要。而保险行业也是渠道费用很高的行业，原有的返佣方式在强监管和报行合一的穿透式监管下其实已经很难维系了。所以基于权责发生会计准则和强监管下的“全组织、全核算”智能管理会计体系，打造以销售服务为核心的会员机制，利用增值服务、风险减量服务实现区域内的客户锁定，产生较强的地域压强效应，获得稳定的客户基础。我们原来和客户的接触点主要是在营销和理赔端，特别是理赔端，所以为了提高客户满意度，才有了极速理赔、快速理赔，提高时效化，让客户提交的材料也尽量简单化。现在通过风险减量服务把风险管理前移了，和客户的接触机会更多了。在增加了客户粘性的同时，还通过服务降低了风险发生概率，在风险发生时也能极大降低损失的程度。除了从事后赔付过渡到事前预防的风险减量服务之外，还有更多服务的着力点。前些天某寿险公司开了一个全新客户权益体系的发布会，口号是：通过金融保险的力量整合相关行业资源，给客户提供更好的服务。的确，保险是为千行百业和千家万户提供风险管理服务的行业，要琢磨他们的诉求是什么，在给客户提供风险保障之外，帮助客户获得高品质的会员增值服务，包括应急救援，医疗、文体娱乐活动等等。从“传统风险保障”转向“全生命周期守护”，让保险回归保障本源，让服务穿透保险表层。把服务延伸到更为广阔的生活场景中，为客户提供更多的高品质服务。满足客户多样化的需求，提升公司差异化竞争能力。
优质的产品、服务、价值认知与会员体验可以产生良好的客户口碑，实现低成本的口碑营销。口碑营销是保险行业用得最多的方式，也是成本最低的方式。我本人买保险时都会咨询相关的朋友。我们私域运营的目的是最大化的挖掘客户的价值，他的终身消费价值，以及他的社交价值。口碑营销是留得住老客户并持续吸引新客户的最佳方式。
随着专业化领域客户基数的扩大和业务量的增加，可以产生规模效应。遵循保险大数法则，可以实现更低的单位成本、更强的风险防御能力和更高的单位利润，获得稳定的总体盈利能力。
有了规模化效应，才能吸引更多的相关企业、科技公司、行业平台的关注，和保险公司开展战略合作，保险公司可以构建以保险为核心的生态圈，实现业务、资源、数据等方面的协同与共享，产生强大的网络效应，推动保险业务高速发展。
产业生态化的网络效应会融入更多的细分场景的多模态数据，而 更多的多模态数据聚合，会形成更强的标的及风险感知能力，开发出更加丰富的产品与组合方案,吸引更广泛的客户群,获得更高的市场占有率。由此形成一个正向的飞轮效应。
刚才给大家勾画了基于小模型的保险认知管理模型驱动保险价值链重构的蓝图，其实这里的每个环节都有大量细致的工作要去落实，很多都涉及工程化的问题。下面我的同事会从中科软通过业务咨询、风控建模和运营协同的三位一体实践的角度，来汇报一下如何构建垂直生态，推动保险价值链的重构。
谢谢大家！
在今天这样的保险科技创新的盛会上，我们或多或少都会谈到数字化转型，当我们谈论数字化转型时，有一个问题是始终绕不开的：为什么很多蓝图最后成了空中楼阁？今天，我就带着大家来探讨可落地的解决方案，中科软业务咨询-风控-运营三位一体实践，这套方案不是凭空而来的，而是基于小模型驱动价值链重构，它不仅仅是停留在ppt上的文字更能转化为实实在在的业绩增长。
下面我将从五个部分展开介绍：业务蓝图解析 “三位一体” 的顶层逻辑、业务咨询、风控建模、运营协同，以及中科软同频共跑的服务模式。
首先要做好价值树的落地，其实左面的图是价值树的图，从企业利润如果想增加的话，我们要做好利润和投资收益的双轮驱动，承保利润分解为保费收入分解以及成本控制的细化。在投资收益部分主要是资金用的效率和资产配置的策略优化。其实左面看到是一个清晰的价值分解，但是实际在运行过程却处处碰壁。
从概念感知层面看，财务和业务对保费收入、赔付率的理解各执一词，常为数据口径争执；从风险感知维度看，以车险为例：我们想扩大规模，承保新能源汽车、自卸车，但保了怕赔付率高，不保又怕规模不达标，风险感知能力明显滞后；从价值认知层面看，保险公司有百万、千万级客户，但续保时仍靠 “广撒网”，缺乏客户洞察能力，无法了解客户真实意图，更多依赖人为判断。可见，这些都是数字化转型的执行鸿沟，中科软三位一体实践将以保险垂域小模型为桥梁，下面通过三个一线故事，讲讲如何跨越这道鸿沟。
先看业务咨询部分：一线管理者的核心任务是抓经营结果，但在过程中，需要拼凑多个系统的数据，最后口径还不一致。看到数据后，明明知道保费下滑了，却只看得懂数字，说不清是哪个渠道、哪类客户出了问题，只能凭经验瞎猜根源；要做决策时没依据，全靠 “拍脑袋”；下了任务像断了线的风筝，执行效果没法评估，后续业绩能不能达标更是心里没底…
这些痛点的根源，还是价值树讲解中提到的：概念认知不统一、风险感知不及时、价值认知不到位，具体表现为数据分散、标准混乱、归因模糊。我们咨询服务的第一步，就是把这些痛点显性化、可量化。
小模型化身为管理引擎：我们能为我们的机构负责人提供了专职的智能助理。首先我们看业务数据，我们以车险为例，能清晰呈现保费多少、与目标的差距及分解方式，还会给出当月经营情况并生成归因分析。通过归因分析，能明确是渠道、团队还是其他问题，看到归因路径和具体情况，甚至每个归因项对应的主机厂合作丢失情况。系统会给出决策建议，一线管理者如果采纳的话，就可以按此直接执行。
这个执行的环节可直接分配到人，我们还能跟踪任务进度，以及判断在当前执行情况下能否达成任务；若能达成，最终当月经营目标会呈现何种状态。这整套体系，从经营结果、到归因分析、业务决策、业绩追踪、效果评价，全有数可依--让数字真正驱动决策
通过陪伴式服务，不只是提供一套系统或更不仅仅是一份报告，而是从数据基线梳理、小模型工具落地到日常运营陪跑，确保保险公司真正具备用数据说话、用数据决策的能力。
刚才探讨了咨询部分，我们再看一个一线故事：车险部王经理又被总经理质疑 ——“现在咱们赔付率确实降了，品质做得不错，但保费规模下滑的厉害，别的兄弟公司都在做自卸车，我们为什么不能做？” 王经理心里苦啊，燃油车货车赔付率高，放开做就是每月亏损，只能靠“严控单三、交三”或只保品质好的平板车 品质保住了，规模越来越小；自卸车倒也想做，但传统风控模型‘一刀切’，比如把‘市政短途合规车队’和‘长途散户野车’全归为‘高风险’，眼睁睁看着 优质业务被其他保司抢走。规模和利润两难！
我们通过风险管控及资源整合，通过整合静态数据与动态数据，对模型进行场景细分，对优质客户进行更精准的评级和筛选。将模型评分转化为差异化定价，适度放宽承保标准，提升优质业务承保率和市场份额，同时有效控制赔付成本，提升盈利水平。：
通过我们两年的实际经营案例可以看出，在陕西地区的实际成果：2023 年开展业务，保费 1200 万，满期赔付率 61%；2024 年保费达 3600 万，当前赔付率 48%。这是与陕西中小型公司合作的成果，我们还与大型公司合作了燃油私家车业务，目前每月保费 200 万，赔付率 50%。
以前拼 “胆子大不大”，现在比 “风险算得准不准”—— 车险终于从 “被动缩圈” 变 “主动扩界” ，规模和利润两手抓！ 这就是小模型的魔力！
确实导致优质自卸车业务被采用精准化模型的竞品系统性收割。这种竞争格局的本质，是数据驱动的风险量化能力对传统经验主义的降维打击。
其实达成这样的结果，并非只给保险公司一个风控模型就能解决。我们做了这些工作：一是验证模型与保险公司的匹配度，通过背靠背数据评估验证模型；二是制定业务方案并整合业务渠道 —— 刚才的案例中，业务渠道就是我们通过生态业务提供的；此外，还包括风控模型的假设设定；最后，每两周我们会与保险公司一起做数据分析 —— 就像精算专家与保险公司共同陪跑，这样才能把事情做好，才能达到预期效果。
我们现在也在做的业务类型，除了 “优中选优”，我们还在高风险业务中筛选可控风险的可保业务，自卸车、冷藏车、新能源车都是拓展方向。有了风控模型后，过去做业务更多是 “拼胆子”—— 敢不敢做，蒙对了就盈利，不敢做业务规模就逐步缩减；现在则要比 “算得精不精、准不准”。车险也从被动缩圈转向主动扩界，本质上是靠数据驱动的风险量化，对传统经验主义形成降维打击，实现规模与利润双抓，为保险公司提供更强业务支撑。
如果说我们刚刚车险案例是风控的「点突破」，中科软这套 以保险认知管理模型为基座，小模型 + 数据 + 场景接入 的智慧平台，正实现「面覆盖」的风控进化。
比如我们雇主团意险，市场普遍亏损，我们通过智能风控模型的接入，核心是把好入口关；工程险的风控通过体系实现了全面风险减量；安责险在承保前会做智能风险评估，再整体承保，推动保险公司从风险承担者向风险管理者转变；诉责险专业性较强，我们采用法律垂域模型，支持案件一键上传、秒出法审报告，解决了专业性问题；网安险方面，我们与战略合作伙伴一起，实现保前扫漏洞定可保，保中动态监控降损失及应急响应。
基于上述内容，中科软可提供三方面支持：左侧两项是技术支持 —— 在保险公司原有核心系统基座上扩展风控能力，同时支持 SaaS 化服务；运营方面，我们支持业务运营及过程的全面跟踪；第三，我们帮保险公司做业务引流，技术、运营、资源三重赋能，提升保险公司的市场竞争力。最终实现从被动买单到事前主动防险、事中防损的转变。
运营协同，我们还是从一个一线人员的故事说起，续保员小钱的一天，曾是 “焦头烂额” 的循环：早上面对一堆分配的客户清单，客户只有客户的基本信息，客户的痛点、意愿全像 “猜谜”，方案全凭直觉给；之前的断点客户人工跟进完全没有效率，忙活一天承单效率低；傍晚复盘只剩 “糊涂账“。
结合中科软推出的拥有小模型能力的ai私域运营体系，解决了几个问题：
一、客户洞察方面，首先要把这些客户变成活跃客户，不仅仅是数据流量，在这里面要打客户标签，要进行客户洞察，以及在这个过程中我们要通过话术洞察，要把各种信息打标签，变成可对应的信息。我们可以看到系统中展示了客户的基本情况、客户标签、客户偏好以及对这个客户推荐的话术。
二是流程驱动 自动监控断点、推送策略，跟进不再漏网；对于断点的情况，客户在某个环节停住了，比如客户在某个环节因开会暂停，系统会自动生成进度跟踪并提醒，让小钱知道下次该在什么时间点跟踪什么事。刚才提到了会有智能话术和产品推荐，也会根据他的客户类型推一些非车险的产品。
三在管理驱动，对续保人员我们给他进行智能的质检，告诉他现在做的工作哪些是做得好的，哪些需要提升的，甚至哪些话术需要完善的，服务标准被牢牢卡住。续保员从 “重复工具人”，转身成 “客户价值经营者”。除此之外我们还给续保人员配置上了中科软的出单机器人也实现了智能出单。保司的投入，也终于精准砸向 “能赚回报的客户” 。这就是运营协同的魔力：把每天的忙碌，变成可沉淀、可复制的增长密码 。
整个过程中，不仅车险续保，新保、非车险等业务，都能通过这套 AI 私域运营模式全面跟踪并提升能力。我们通过 AI 运营模式，识别了客户意愿，能进行更多产品推荐并提升能力。但保险是低频交易业务，产品和服务相对同质化，竞争力较弱，该怎么办？我们引入了 “权益服务体系 + 会员制管理”：第一，中科软有完整的权益服务平台，不仅提供工具，还接入了 60 多家生态伙伴，涵盖健康、娱乐等服务，能增强对一线客户的支撑，让客户有更多获得感；通过会员体系，结合业务支撑让会员持续成长，实现定期互动，提升销售可能性。
通过权益服务平台和会员体系，我们把低频交易客户变成了活跃客户，但接触的客户仍有限，如何进一步扩大客户群体？中科软的做法是：一方面与众多合作伙伴拓展业务 —— 比如与网安科技公司合作网络安全险，与律所共同探讨诉责险及受众更广的法律费用补偿险，面向 B 端推广；另一方面，中科软自身及众多生态合作伙伴都在做 C 端私域运营，我们可以提供风险预测、健康支持等服务，包括面向高净值客户推广。过程中，一方面将保险嵌入异业场景，为保险公司引流；另一方面，将异业产品以低价或免费形式作为权益赋能保险客户，把非保险客户转化为保险客户。
在这个过程中我们可以看到，左侧是中科软行业私域运营全景图，右侧是服务能力：一、私域运营规划，根据各保险公司情况制定不同方案；二、提供私域运营全套解决方案，包括工具、运营、服务及落地陪跑；三、引入权益服务及异业经营模式，异业合作伙伴涵盖汽车、金融、医美等，大家有需求可随时探讨。若保险公司想做初步尝试验证，我们也支持托管代运营服务。总之我们的运营服务由浅入深，希望与大家共同打造新生态。
综上所述，我们讲了业务咨询、风控建模、运营协同三个场景，构成三位一体服务方案。在此基础上，我们叠加资源支持（整合渠道与服务商）、能力支撑（小模型 + 生态打造）、服务支撑（咨询 + 运营陪跑），以数据驱动价值，陪您共同跨越数字化转型的鸿沟。
最后和大家做个分享：保险科技的浪潮如同离心力场，只有不停奔跑，才不会被甩离赛道。让我们以小模型驱动保险价值链重构，借三位一体实践锚定圆心，永不停步，共赴保险行业新未来。
各位领导、同事，大家下午好，我是来自中科软财险团队的孙维，分享的话题围绕数据管理工作，主题是：基于数据关系图谱的智能化数据管理体系。
财险行业自2018年起普遍开展数据治理工作。在2022年保险大会上，我分享了中科软财险行业数据治理框架4.0版（即图中“飞机图”），涵盖建设目标、管理体系、工具体系、实施内容、实施方法五大模块，并总结了当时行业实践的五大典型切入点：标准建设、质量管理、监管数据专项提升、数据目录构建等。
在过去的几年里，我们也一直在参与监管单位以及人保、平安、大地、永安等众多公司的数据治理工作，积累了一些新的心得体会和成果，今天的分享，我尝试着从三个方面向各位领导汇报。
一、中科软在数据管理领域的咨询规划服务
1、数据战略
图片我们发现，各家财险公司的业务战略和科技战略都做得不错，但是很多公司的数据战略要远远落后于业务和科技战略，数据能力建设缺少顶层设计。图中展示的是我们在2024年推出的财险公司数据战略蓝图的最佳实践，供大家参考。
我解读一下这个数据蓝图，概要的说是“1-5-5-6-3”的数据战略：
顶层：数据能力建设的1个愿景和5个目标；
中枢：5个数据中心，包括数据资产中心、大数据中心、主数据中心、数据分析中心和监管报送中心，基本上各家财险公司建设好这5个数据中心就能满足各类数据管理诉求了；
支撑：为了打造5个数据中心，各家公司要开展6类数据治理举措，包括安全管理、质量管理、标准管理等等；
底座：最下方是为了做数据战略的落地和实施，需要同步建设的3类保障体系。
在整个过程里面中科软可以提供的咨询服务，包括顶层设计、蓝图规划、路径梳理等，以最佳实践为蓝图，我们协助了多家公司完成了自己战略的制定。
2、项目规划。
有了数据战略做整体指引，但路还要一步一步的走、项目要一个一个的做。而每一个数据项目又有很多要关心的内容，我们可以辅助完成项目规划工作，图中右侧列了四点：
项目的边界在哪？工作范围是什么？
项目交付物有哪些？
项目时间安排如何设计？
相关的资源需求有多少？尤其是人力资源，包括甲方和乙方，也包括对甲方领导的资源要求、业务部门的资源要求等，都要在项目规划之初思考清楚。
图中展示的是中科软数据治理项目规划的最佳实践，也是供大家作为参考，尤其对于初建数据治理的：
首先，建议以整体规划为基础，盘点现状、对照DCMM国标完成能力自评、理清差距
然后，打造一个集制度、工具和标准为核心的数据体系
最上方，是速赢专项的选择，每家财险公司根据各自的情况可能有不同的选择，常见的五个专项：标准化专项、架构专项、指标专项、质量专项以及安全专项。而因为任何一个专项工作不可能在一个项目内完成，很多财险公司会挑选一个数据切片作为项目范围，最常见的是以监管数据为切片，大家最开始做数据治理时，最好是以监管范围为切入点。
3、DCMM的评估
中科软在2020年推出的数据治理体系时，就是以DCMM为基础设计的，这些年来也围绕DCMM给众多财险客户提供服务，图中列了两类客户：
第一类：中科软+第三方机构+客户共同完成认证评估工作，最终拿到认证证书，就像中科软自己也过了DCMM的三级，目前也有很多公司在进行三级评估，个别公司目标是四级；
第二类：更多公司目标不是拿证书，而是为了对标国家标准，找到自身差距，明确目标。
中科软可以结合自身丰富的服务经验以及和第三方评测机构的深度合作，帮助各家财险公司完成能力自评、差距分析、能力提升、等级认证等等。
二、数据关系图谱
相较一般的咨询公司，中科软不光关注顶层规划，也非常注重实施落地。第二个分享点，也是本次汇报的重点，就是我们经历了很多教训、走过了很多弯路，通过经验积累总结了一个想推荐给大家的好方法：围绕数据关系图谱开展数据管理工作。
图中左侧是各家财险公司日常在开展的各类数据管理工作，包括标准管理、质量管理等等，尤其去年底和今年，监管总局和人民银行分别下发了数据安全管理的要求，相信各位领导今年都有做数据安全，最起码做数据分级分类的计划。
但是数据管理工作逐步在面临进退两难的风险，我相信大家都应该有右侧的四个困扰：
1：多项数据管理工作之间的重复工作很多。
2：相反，这些工作往往是项目制，缺乏一个传承和复用。我们做一个小测试，请在座的各位领导思考一个问题：“如果您的公司过往几年开展过数据治理工作的话，那么今年做数据分类分级时，能复用以往数据治理项目多少的成果积累？”这个复用度如果比较低的话，就隐含着一个严峻的问题，我们要反思，在过往的数据治理项目中，做了什么？留下了什么？又能给未来数据管理工作带来什么？
3 & 4：如果自己都说不清楚数据治理工作的价值产出和延续性，就会产生第3、第4个困扰：业务方无感、领导不认同。
带着这四个困扰我们往下看，现在各家公司的业务系统已经非常强大了，但是这个强大带来的衍生问题就是产生的数据非常杂乱，数据之间的关系就像是埋在地下的树根一样，难以描述、难以理解。我在图中左侧下方列举了几个常听到业务老师提出的问题：数据在哪里？数据关系是什么？我应该怎么用数据？
以EAST监管报送的具体场景为例：现在监管要求业务部门是本领域数据的负责人，最近刚刚发的一个监管文件中也有明确写到：谁管业务、谁管数据，但是业务部门有时候也很委屈，虽然我在很多会议上也是摇旗呐喊让业务老师参与到数据管理工作中来、承担起管理责任来，但是当最终报送结果要求业务部门签字的，业务老师往往很为难的说：“我只了解我的业务流程，但是业务系统具体是怎么完成技术实现生成数据的，我不了解；数据仓库又是怎么处理数据的，我不了解；EAST报送程序最终又是怎么加工数据生成报送文件的，我也不了解。你现在给我一个数据表，里面有几万、几十万、几百万的数据清单让我确认，我怎么确认？”
如何让业务老师更懂数据、更容易的参与数据管理工作？这是摆在所有财险公司数据管理工作者面前的现实问题。
我们中科软探索的解题思路是：用好数据关系图谱，尝试让地底的复杂的根系关系展示在地面上，就像我们看到无论再庞大的大树，没有一片树叶是悬在空中的，它们之间都是有一个脉络关系来支撑，并且不光有树干、树叶，还有果子、花朵等，所有的内容都是有关联的。
基于“数据关系图谱”开展数据管理的核心理念，可以归纳为四句话：
一张图谱，呈现数据脉络；
按图施策，统一数据认知；
一处治理，赋能多类场景；
以用促管，驱动持续运营。
那么数据关系图谱具体包含哪些内容呢？这张图是中科软财险公司数据关系图谱的核心内容示意：目前是12+6的结构，是将数字世界里面的12个元素抽象出来，梳理他们之间的6类关系，组成了整个数据关系图谱。
12元素：包括系统、数据库、字段、代码及码值、指标、质量规则、数据类别级别等；
6类关系：包括引用关系、对应关系、对照关系、血缘管理等。
数据关系图谱的内容比较复杂，想要做好也确实是比较难的事情。我们尝试着弱化这件事的复杂度，做了一些技术上的支撑辅助，比如说我们中科软自研的大禹数据治理平台，提供了各类功能模块协助数据关系图谱的梳理和展示，也融入了一些AI的能力增强功能。
关于关系图谱，我想结合今天大会智能化的主题再谈两点：
1、AI技术蓬勃发展的今天，很多公司开始在做数据标注，重点往往放在很多非结构化的数据，通俗来说例如一张照片标注哪里是人、哪里是物，但是很多人忽视了数据库里的结构化的数据就不需要标注了吗？就已经非常可用了吗？其实还远远没有达到。而我们提出的数据关系图谱的构成过程就像数据标注一样，识别数据之间的关系，给数据赋予生命力。
2、科技人员现在面临着很多编码开发人员要做转型，领导在前面的分享中提到了可以转型AI编排、提示词工程等，我觉得也需要有转型到数据关系图谱的维护当中来。
接下来，我们来看看有了这样的数据关系图谱，它能怎么使用？能带来怎样的价值？
1、数据标准管理
过往，很多公司开展数据标准管理工作容易两张皮的问题：标准是标准、系统是系统。要么无法落标、要么代价太大难以常态化维护。我们并不建议要求所有的系统数据结构定义都改为跟公司标准完全一致，但是我们建议公司要将自己公司系统中的各个字段、代码和公司标准建立关系，只要有了关系网络，每个系统里的字段定义已经不再重要，例如咱们财险公司很多系统里都有销售渠道代码这个字段和代码，各个系统中无论叫什么名字，无论码值是A、B还是01、02这样的序列，都可以通过关系将他们的含义对齐，达到数据可知、可用的效果。
2、数据质量管理
有了数据标准关系这个基础，大家做质量管理就简单了。以前大家做质量管理都是逐个字段单独治理，缺少关联性，比如说监管报送的字段，可能对报送结果做了质量检查，但却没有管理对应的源端字段。
而如果我们有了第一点提到的数据标准的关系网络，那么我们可以针对数据元标准进行质量规则的设计，在关系建立的那一刻，质量规则就已经完成全部关联字段的覆盖，质量管理工作变得简单、有序。
3、数据安全分类分级
同理，前面提到过数据分类分级工作，也可以复用数据标准关系的基础，对数据元标准开展分类分级就可以，比如说【个人身份证号码】这一数据元标准，设定好类别和级别后，无论各系统此类字段的元数据如何命名，只要关联到【个人身份证号码】这个数据元标准，它的类别和级别就自动完成了打标，无需反复盘点。
4、智能问数ChatBI
对于数据和AI的结合，我们详见第三个分享点。
三、Data和AI的双向奔赴
AI -> Data：前面的分享中向大家汇报了一方面，是我们在“中科软大禹数据治理平台”里嵌入了AI能力去做一些功能增强。
Data -> AI：另外一方面，是数据关系图谱助力AI应用。
2023年底，我们建设了面向业务人员的对话式智能数据分析助手：ChatBI，如右图所示，可以让全部数据分析用户通过自然语言对话的方式，完成数据的获取和分析，并且可以提供数据洞察和根因分析的能力，大大的降低了数据分析的门槛，得到了业务用户的好评。
但是建设之初经常遇到AI理解用户语义不准确的情况，因为保险行业的领域知识复杂，各家公司又有各自的“方言”和习惯，这一问题制约了ChatBI应用的实际效果。
我们分析，保险公司在AI应用上的功效取决于AI的能力×保险公司的数据基础，可能AI的能力它是有更多的大厂在解决，我们不用太关心，但是保险公司自己的数据基础应该想办法做好，当技术成熟那一刻我们可以快速拥抱。我们将保险公司数据基础分为L1-L4级别，L4级别是指所有系统、所有字段统一命名，这个很难，但是最起码咱们可以做到L3，就是构建关系图谱，这是一个比较好的平衡点，它的成本可控，效果也比较好。
在ChatBI应用上，如何让AI了解我们保险公司已有的数据指标和报表？我们想到了数据关系图谱，利用RAG技术将“数据关系图谱”作为知识源接入大模型准确、快速、动态的完成大模型对企业知识的应用。
右侧视频展示的是在中科软自研的ChatBI智能化数据分析助手里，通过流程编排，将数据关系图谱里面12元素和6关系投喂给大模型，大模型通过调用数据库就可以快速动态掌握到企业知识，在编排时我们要告诉它哪一个是12元素、哪一个是6关系，完成了编排之后就完成了知识的接入，因为刚才咱们说整个关系图谱是动态运营的，因此提供给大模型的知识也是动态更新的。
在这里还是强调一个非常重要的点：数据关系图谱的动态更新。我们现在的实践经验就是：要将数据关系图谱的维护工作嵌入在应用系统的变更发布流程中，从核心系统的存量数据盘点开始，到增量的需求环节、设计环节，数据团队都要进行介入，开展应用系统DDL的评审，无论是表变更还是字段变更，只要涉及到数据元素，我们就要监测数据关系是否同步建立和维护。这样一来，像刚才提到的标准化、质量管理、安全管理等数据管理工作，以及AI应用，都可以利用数据关系图谱完成管理工作，也可以最大化的挖掘数据价值。
今天概要分享了中科软在这几年的时间里关于数据管理方面的进展，包括咨询规划、数据关系图谱方面、数据跟AI的结合。这三个话题每个话题都能展开深入的探讨，我们有很多储备和积累，希望后续可以和大家详细汇报和交流相关内容。尤其是数据关系图谱这件事，我认为到了关键阶段，原来咱们IT老师更多关心是业务系统如何满足出单流程，现在随着数据是生产要素、随着AI技术的不断成熟，越来越紧迫的需要把公司数据变成可用的资源。但是这件事上有很大的距离，如果用原来方法开展数据治理，依然会面临之前的困扰，经过反复的思考，关系图谱应该能解决这件事，我们也已经在多家公司实践，取得了不错的效果。
希望这个领域上跟大家多碰撞，共同迎接拐点时刻，让我们数据更可用，希望为财险行业数据能力的建设献策赋能，谢谢大家！
各位领导、各位同仁，大家上午好！
我是来自江南科友公司的李根，今天非常荣幸站在这里跟大家分享有关密码技术、数据安全、合规这一重要议题，即如何“以密码之力，助保险业务从安全合规迈向创新增长”。
我们在座的保险科技部同仁，相信大家都有一个共同感受，近年来我们的合规政策不断出台，合规要求也越来越细，而业务创新需求越来越急。我们常常会遇到这样的困扰：
业务系统刚刚上线，又出现合规新要求，为了应对和满足新要求，则业务系统又面临着改动。
其次就是业务系统的安全建设是烟囱式，如核心系统、保单系统等各类系统，在遇到密评要求、数据安全要求时，各自为战独立建设，合规检查时才发现密码设备、密钥管理散落在各个环节，很难梳理密码运行现状和密钥证书状态，既增加管理成本，又埋下隐患，以及当新系统面临安全需求时，原有的密码资源又难以复用，这不仅加大了科技团队的投入，对业务发展也有一定的影响。
更关键的是，我们围绕着数据要素的创新业务，如我们保险客户分析用数，以及基于AI智能应用的用数，在非常多的用数场景，我们既想用好这些数据，但又担心踩红线出现安全风险，这都是咱们科技同仁们共同面临的困惑。
近两年当中监管机构发布了有关数据的管理办法，以及两个密码应用的技术标准。第一就是银行保险机构数据管理办法，目的从制度设计到技术规范，全面构建了覆盖数据全生命周期的安全管理框架，落实数据安全保护管理要求，建立数据安全保护基线。当然这也是一脉相承的来自密码法、个人信息保护法的导向，无论是保险还是银行基于自身发展所需，或政策要求，都应建立相应的安全体系。第二就是在今年5月13日发布的两个标准，一个是《保险交易服务商用密码密码技术要求》，另一个是《保单登记平台商用密码应用规范》，这两个标准的内容基本来自密评的39786的密评标准，39786是密评的GB标准，从2017、2018年起在政府行业、很多行业开始落实，基本上等保三级系统需要通过密码评测。
其实银行业是在2022年底发布的0255的密评行标，与咱们5月13发布的标准有很多相通之处，都是围绕金融机构的等保三级系统，在物理与环境、网络与通信、设备与计算、应用与数据，以及管理制度等八个方面提出了54项指标要求，最终是在每个环节的数据应该如何保护，如应用与数据环节涉及的是身份鉴别数据、访问控制、业务重要数据，总体来说密评本质是使用密码技术，对数据资产进行安全保护。
问题来了，随着保险行业数据安全、密评等安全合规要求日趋严格，如何才能做到高效合规呢？比如保险核心系统、保单系统、理赔系统对于密评要求，若各自独立建设安全模块，各自满足？这种烟囱式的建设方法，对于科技团队来说，工作量及成本投入太大，如何能形成一种体系化的合规方法，统筹规划安全体系，系统化满足合规要求，这是大家比较关注的问题。
其次，如何既能满足合规的同时，又能促进业务的增长？按照原来的建设方法、传统视角来看，合规则是被动处理、应对模式，因为系统各自为战，每次的合规改动制约业务灵活性，加大了数据要素在业务创新场景下的复杂度。
但从新视角来看，其实合规这种可以通盘考虑，可以改变原来孤岛式、烟囱式的建设方式，合规建设可以是主动服务，统筹安排，合规是一种业务，我们可以把满足数据安全、密评合规的密码安全体系做成业务，即安全业务，与咱们的核心业务、渠道业务是一样的，由安全系统为业务系统提供一揽子场景化的密码服务能力、数据安全保护机制，这样不单单是满足本次合规，而可以去灵活应对合规要求的变化，为不同业务系统围绕数据要素的流通环节提供场景化的保护能力，可以让数据要素在安全状态下释放价值，从而达到促进业务增长的目的。
说到这里，其实保险与银行有着极其相似的背景和发展路径。
都是面临合规政策不断出台，银行的合规要求可以追溯到2014[6]号，要求业务系统使用国密算法，以及2017年[170]的风险管控要求弱密码识别、双因素认证，2020[140]金融信息系统国密改造基线，2024[245]号文要求的两高一弱，每个时期都会提出不同的要求，大家面临的是一样的问题，合规要求多，密码技术有专业性，大家对密码相对陌生，业务也是各自适配密码模块，对合规实现都认为有难度。
随着数据成为核心生产要素后，银行、保险机构基于数据的业务日益增加，如理赔用数、核保AI的用数，这些用数的场景非常多，按照监管要求对数据进行保护，大家现状是敏感数据太多了，其次这些数据分散到不同系统当中，我们也看到一些金融机构由于数据管理粗糙，而被处罚的事件，数据不敢用、担心出问题。
所以说，银行和保险曾面临同样的现状，痛点是一样的：
都是由于业务系统孤岛式、烟囱式的密码体系建设，造成了内部缺乏统一的密码接口规范，从而难以管理、难以复用的困境，如电子保单平台建设时采用的密码标准，核心系统不能直接用。
业务系统为满足合规要求，需要进行多次的改动，而业务改动非常困难。
面对密码评测、数据安全的规范标准，对既有业务场景有一定影响、业务性能是否下降也需要考量。
不过，银行的密码安全、数据安全相对来说走在前面，银行也走过孤岛式、烟囱式的模式，但银行是十年前国密改造时，就开始改变思路，将合规和数据安全改为主动服务、统筹安排，我们江南科友为80%以上银行建设了新的密码安全体系，深度应用各类业务系统中。整体的解决思路是：
一、从孤岛式、烟囱式密码应用转变为业务系统提供全密码应用支撑。
二、全面转向以业务场景和安全管理为驱动，覆盖核心系统、渠道系统等近100多业务系统。
三、形成了面向业务系统的一揽子密码能力。
通过全密码应用的场景化能力，对数据在业务系统的各个环节进行安全保护，让业务系统可以放心地去用数，用于创新场景，为业务增长提供安全的环境。
保险行业构建全密码的应用，实现两个目标：一、高效合规，二、数据保护。
保险机构业务系统在交易环节主要是数据形成的过程，形成之后会围绕数据做数据使用，合规原来主要针对数据形成的环节，但是增值主要是在数据使用环节。全密码应用是站在数据共享和应用的视角，以合规为前提，以满足业务用数为驱动，从技术和功能导向转变为业务和管理导向的数据安全管理体系。
我们不但要满足数据形成环节的核心系统、ESB系统、理赔等系统安全支撑，还要实现覆盖数据使用环节的数据分析、用数、保单报送等安全支撑。全密码应用可实现四个“统一”。
第一，形成了统一安全服务，包含密码服务、认证服务、数据安全服务、大模型AI安全服务，以标准化、体系化给业务系统去供给的模式。
第二，形成统一密码计算，就是高效利用密码设备，将所有密码设备统一设备管理起来，实现统一密码计算。
第三，形成统一密钥和证书管理，将分散的证书和密钥有效管理起来，解决保险机构业务系统有数字证书数量不清晰，存放在什么位置不清楚，是否快到有效期等问题。之前金融机构就遇到过由于密钥、证书管理分散造成数字证书过期，导致生产事件。这些数字证书在业务系统上线时大家比较记录，但是两三年之后由于分散存放，缺乏台账和交接记录，就出现管理混乱的情况了，统一管理可以帮助保险机构建立规范和方法，形成密钥和证书使用流程。
第四，形成统一密码监控，让整个密码应用体系是可监测的，其运行状态、资源情况、每个业务系统使用情况，一目了然。
通过全密码应用为保险业务系统提供所要求的数据机密性、完整性、抗抵赖，满足每个业务系统所有安全需求，全密码应用架构是场景化、插件式模式，可为每个业务提供场景化的密码安全服务，如核心系统、电子保单的安全服务就有一定的差异。其次插件式，每个安全服务其实都是插件，最后是云架构，适用于保险机构数据中心现有的技术标准，云下、云上均可支持。
当前，全密码应用已在银行业和部分保险机构深度使用。第一，提升合规的效率，提供一揽子服务，可以共用我们所有的场景化密码能力。第二，助力降本增效，原来分散在每个业务环节的加密设备将近上百台，但是全密码应用平台建设之后，可以节省50%乃至更多的密码设备资源，因为通过这种平台就整合了加密能力，然后通过场景化的服务接口或者免改的接口去适配业务，让业务做更少的改动去满足合规的要求。第三，可视掌控安全，安全也是一种业务，从默默无闻的后台让大家可看到、可监测。第四保护了数据安全，促进数据要素业务的创新。
我们来看一个保险交易服务系统保护的全流程，通过全密码应用覆盖八个场景：
用户访问场景，实现对用户身份的认证和确权。
交易传输场景，对用户交易的数据保护。
数据存储场景和用数场景，这也是密评、数据安全要求最重要的场景，更多聚焦数据存储和数据使用安全，数据如何加密存储，以及加密存储后，围绕用数怎么办？首先就是数据如何抽取？其次是密文数据DBA如何维护？如何基于数据做数据分析？生产环境数据如何向测试环境脱敏提供？向外机构数据报送怎么办？全密码应用围绕数据从形成到使用的这个场景，能够提供完整的场景化方案和能力，满足数据流通中的各种保护要求，让业务系统可以安全地去使用数据。
面向未来，我们其实也是在积极的布局抗量子密码算法和大模型AI安全，金融机构走过了从国密算法替换国际算法过程。当前面向量子的威胁，如何能够抵抗量子攻击，这也是保险机构需要考量的问题，因为量子计算机发展速度超预期，强大的密码破译能力威胁传统密码学，去年美国NIST已发布了抗量子密码算法标准，国内今年2月份开始征集，我们江南科友也发布抗量子密码方案和密码产品系列，并在去年9月份与我们母公司三未信安一同发布了《抗量子密码技术与应用白皮书》。针对大模型AI安全这一块我们也是针对大模型的模型应用安全、模型安全以及基础安全，形成了围绕软件、硬件服务，提供身份认证、数据安全和人工智能多维一体的解决方案，同时也发布了《大模型安全密码应用白皮书》，这两份材料在我们公众号都有发布，欢迎大家下载。
最后，介绍一下我们江南科友，江南科友成立于1991年，是三未信安科技股份有限公司（股票代码:688489）的全资控股子公司。科友总公司位于广州，在北京、上海、深圳、杭州、成都、武汉六个公司，我们的业务范围和服务网络覆盖全国。我们一直专注于密码技术、数据安全在金融行业的深度应用。在银行的覆盖率达到85%以上，服务的金融客户数超过1000家，专注信息安全行业27年，我们在金融科技安全领域是头部领军企业。
今天所分享的全密码应用服务已成为银行业务密码应用的标配，已广泛用于股份制银行、城市商业银行、省级农信社和保险机构。
我们江南科友具有全国产化的密码产品，涵盖密码芯片、密码板卡、密码设备、密码系统等系列化产品，深耕金融场景多年，形成了围绕政策合规类、业务场景类、新技术应用类等诸多安全解决方案。
当大家在面临合规、数据安全要求时，我们江南科友可为保险机构提供密码现状评估，以及共同进行场景突破、形成场景化的能力，在帮助保险机构达成高效合规同时，实现保险数据的全流程保护，助力业务创新增长。
各位同仁，我今天的演讲到此结束，感谢大家！
大家保险集团科技部总经理 郝晓波
非常高兴有这个机会分享一下我们公司在AI这方面的一些探索，今天是关于未来中台在AI时代应该如何建设的一些自己的思考和探索的成果。
为了敏捷支持我们的业务发展，在业务变化时快速调整我们的IT系统，我们很多企业的科技建设中都研发了企业中台,就是对各类业务系统的原子功能进行API化封装，并做编目，其中包括自适应的元数据描述，自动的SDK生成、自动化的测试、甚至统一的权限管理、部署运行、性能管理等。中台让我们能快速在组建业务流程、快速适应业务变化。
现在到了新的AI时代，中台建设是否有一些新的方法论？有没有一些新的技术策略与工具？最近我们也有一些思考和探索的成果，这正是我今天想和大家一起探索的话题。
要回答上面的问题，就要先回答几个问题：一，AI的核心能力是什么？二，企业数字化平台的发展趋势是什么？然后我们才能知道，AI的核心能力能为企业数字化平台的发展做到什么。
我们先讨论第一个问题：AI的核心能力是什么。
大家现在用AIGC,也就是“生成式Ai”来称呼现在的大模型。说它是“生成式”AI，我是反对这个说法的。其实大模型AI的关键能力不是生成内容，生成内容只是它能力的表象。为了生成我们能接受、质量良好的内容，其底层支持是知识、常识、逻辑，甚至符合人类的观念的价值观，这其实是AI最核心的东西。也就是说，AI不只是一个内容生成的工具，它是认知工具。它只是在诞生时用生成内容这种方法向我们表现了它的认知能力，我们称它叫“生成式AI”就像是我们看到一个新生的婴儿哇哇哭时，就命名这个婴儿为“哭人”一样片面。
认知是什么？一、检查分析信息，二、作出判断和决定，三，制定执行方法，第四项付诸实施的能力，现在AI还不能直接做到，所以我先对实施这一条划个删除线，接下来我们就来看看如何帮助AI做到。
认知能力把计算机从规则机器升级为认识机器。能用新的方法解决问题，也能解决我们之前用规则编程的方式很难解决的非线性问题，这个是我们数字化建设的新的范式。
另外一个问题是，我们企业数字化平台的发展趋势是什么？
数字化平台的发展要紧跟、甚至引领企业转型趋势：工业化时代，企业的主要问题是解决生产问题，做出什么产品客户就买什么；工业化成熟之后技术升级，生产能力加强，可以满足不同需求了，于是转了需求导向；到互联网时代，信息技术让我们有能力根据客户的个性的要求来去灵活适配不同的产品、营销策略等，于是成为客户导向市场。
我们可以总结出一个趋势来，就是技术让客户的权利越来越大，技术也让我们企业的应变能力越来越高，这也是前些年“数字化转型”这一课题的主要任务。在AI时代，是否可以继续推演，把这些变化趋势推向极致？未来在AI时代，有没有可能在人类的监管下，让AI去主动执行业务，而不需要人类的参与？有没有可能通过AI实现真正理性、高效的沟通，消除人类带来的不理性的环节？有没有可能用Ai来实现快速高质量的科技实施能力？
个人认为，AI认知能力正是可以做到这些的东西，那怕是现在的AI还有些笨拙，但是大家不要忘了，一年之前的AI和现在的AI相比的变化，在认知能力的升级和逻辑能力的提升。从前我们总在讨论AI幻觉多么严重，现在已经没什么人提到幻觉了，因为模型的调优和训练数据的进化，使得这种幻觉问题有了很大改善，就像是人类儿童时期的幻想一样，随着成年脑功能的成熟，这种问题就慢慢消失了。而且如果把AI使用放在认知判断，而不是生成内容的场景，AI幻觉也不再是问题。因为企业内部各种场景是高度上下文限定性的，做认知判断、做决策就不会有幻觉。但是如果要生成内容会有幻觉的。所以企业应该使用AI的认知能力，而不是生成能力。它的认知能力实际上将有助于AI帮助我们实现自治化的企业。
现在，我们企业的数字化转型，现在可能要准备进入AI化转型时代，最终愿景将会是一个AI自治型的企业，我们所有业务不再通过人，而是给AI最大的效率支持，让AI自主决定如何执行我们的业务，包括AI和客户的交互、AI的决策和执行等等。这是未来可能的一个最终目标。
如果基于这个目标，我们的数字化中台应该怎么规划呢？
在大模型AI技术出现之后，我们很多企业在前台和中台之间，加了一个AI中台，大家会在其中用AI Agent技术（比如fast GPT）来响应各个业务领域的智能化任务，这些Agent和前台程序进行交互，甚至直接与用户对话，根据用户需求让AI来处理判断，接到任务之后做一些判断，编排各种流程，来调用各种业务，基于中台的各种功能来完成工作。有一些公司做得比较进取一点，还会做到一些让AI自动执行客户的数据查询、实现智能报表等。领导和AI一谈话，他就调用已经设定好的报表，把报表展示出来给领导看，或者生成SQL查询出来给领导看。这是通过AI Agent加持过的数字中台的建设。
加入了AI中枢层的企业操作系统的设计，是否能解决全部问题呢？AI Agent形成了AI中枢层，一定程度上可以让AI决定后续的业务逻辑，但是还是有痛点的：当Agent做出判断，决定要执行的任务时，比如预定一个会议室，或是查询一个报表等，这些定会议室或者查询报表的业务操作本身，还是需要技术人员去编排，去写程序，去完成这个东西的。
不知道大家有没有亲手做过Agent，一般是设一个提示词，加一些知识库，后面设计各种任务时，就要用所谓高代码模式、低代码模式来编排。低代码模式就是画流程图，高代码就是写程序，调用API……这是现在的工作方式。这个流程编排或是写流程代码的工作还是需要人去做的。而且因为这个程序是人编的，就要求人要理解业务需求，去学习现在中台的API文档，把程序编出来；而且这些程序是传统的基于规则的程序，运行时遇到意外的问题时也没法处理；有新的基础业务规则变化时，我们程序也没有办法自适应来去应对这些新的变化。有新的API能完成更多功能时，比如定会议室时支持借投影仪了，AI也没办法加以利用来给用户提供新功能。
在认知型AI的条件下，这些问题能不能解决呢？答案是肯定的。我找到了一个答案，就是“MCP”。
MCP他是Anthropic公司发明的“模型上下文协议”。人们为了让AI能执行任务，做了很多程序，调用一些服务来完成一些实际操作。因为AI只能说话，比如说你让AI给你写个小游戏出来，AI只能回复说这个程序应该是什么样子，但是没有办法执行，没有办法把它的代码真正写到文件里面，那就需一个服务来执行写文件的操作，这个实实在在完成真实工作的服务就叫做执行器。
现在已经有无数种执行器，写文件的、提交代码的、构建代码的、发布代码的等等。但这些功能的实现太多样化了，他们就说，干脆发明一个标准协议，这个协议规定了所有执行器如何向AI平台“自我介绍”，我自己是什么样的，我能做什么工作，我的内部逻辑是什么，我在什么条件下工作，我的参数有什么。有了自我介绍的机制，把所有工具都让他们自我介绍给AI，然后把执行权交给AI，然后AI就可以在工具里面找到自己要完成某个任务时所需要的那些工具在哪里，根据这些可用的工具来计划第一步、第二步执行什么，然后AI自己去执行。
MCP协议出现之后，立即引起了全世界AI社区的大力支持。现在有个口号叫万物接可MCP，就是大家把自己的现有功能，跟AI沾边的或者不沾边的都MCP化了，比如说写日记、读写本地文件、读写PPT等等这些都是太简单了。当你要求豆包读一个PDF时，都是在后台调用MCP的协议。你能想象到的东西都可以MCP化，就是现实的所有执行真实工作的功能都可以MCP化。
最近看到微信把他的生成支付码的功能给MCP化了，就是说AI可以帮你生成你的付款码，展示给你的客户，让他们给你付款。
自从MCP这个东西出来之后，很多厂商立即开始支持，包括上午腾讯的产品中介绍的Agent全面支持MCP。
右面是几个MCP的市场，阿里的MCP市场，腾讯的，第三个是字节代码编辑器trea里也内置了一个MCP市场……市场里有成千上万的MCP工具等着大家去应用，可以做到一键导入到你的AI，你的AI就不仅能跟你对话，还能读写本地文件了，还可以调用本地的BLENDER生成3D数字人。
那么有个问题，我们业务中台那些API能不能也MCP化？
肯定是能的，而且这个工作做起来蛮简单，而且蛮有趣的。如果有MCP，我们就可以把之前数字化平台再增强一下。大家可以看到，在AI中枢这一层还是Agent，名字没有变，但是已经变成MCP Agent。上午腾讯说他们的Agent可以支持MCP，以前Agent只能支持调用编排好的代码执行，现在可以自主选择MCP服务来执行。
为了让这些AI能够调用业务功能，只要把我们的业务中台再加上一层MCP的包装，让我们的服务变成MCP服务。做好这个以后再也不用写什么程序了，只要把API搁到那里，说明自己调用方式，AI就会选择来去调用它。
应该说，目前的AI还是有点问题，有时候调用MCP服务时会出错，比如参数会组装错误。但是我相信将来一定会能够完美调用这些MCP服务的。大家可以想象一下，我们不再需要编第一步要调用什么，第二步要调用什么，不用了，只要扔给AI一堆API，把业务系统的功能暴露给它，它就能根据客户要求，去主动调用业务系统的功能，替我们去直接完成一个保全申请或者保单理赔、保单审核等。你有什么新的API出现了，AI也会发现，就可以应用这些功能。
这就是未来下一代我们的企业操作系统可能会有的样子。
如何实现中台的MCP化呢？
一、我们把自己业务领域分类，比如说用户管理、订单管理、库存管理，各种做个分类，决定哪些是比较安全一点的，可以尝试的优先做MCP化。
第二，根据业务角色对MCP服务做权限管理，因为MCP协议本身是社区里面正在蓬勃发展的协议，它还不是特别完整，所以有些细颗粒度的权限管理还需要我们自己处理。
第三，在现有API的MCP化这一步上，可以用OpenAI的这些描述文档直接来实现MCP定义的，这个代价是不高的，而且已经取得了很大进展。这个大家想到了吗？我们原来做中台时有中台的元数据定义，OpenAPI、swagger、WSDL等API描述规范，可以直接用这个自动生成MCP定义的，只要做一个转换层，甚至在JAVA里面做一个AOP的标注插入来解决这个问题，最后就是运行时去解决一些协议问题，这个今天不细说了。
第四步，MCP Host如何根据AI的反馈调用对应MCP工具，这个实际上我们不需要做很多，因为现在Agent、各家AI的SDK里面都开始支持MCP，我们不需要做很多的工作了。
通过这种方式实际上我们把中台完全就给MCP化了，让AI可以自由调用，让AI决定业务流程是什么样的。
有一种做生态的办法，就是现在有很多做入口交互的AI平台，比如说现在的豆包AI浏览器、智能音箱，还有未来的眼镜，豆包的智能耳机，这些都是很棒的交互入口，完全可以做成MCP的生态平台。
让我们设想一个真正的应用场景：比如说我们有养老社区、居家养老等服务。我们为我们的客户，也就是居住的老人们，配置AI音箱，养老机构、服务机构可以把自己定餐服务、定车服务等实际服务注册在这个音箱的MCP市场当中。这些老人日常与AI音箱聊天的过程中，AI已经收集了用户的很多信息，比如他喜欢的食物、他昨天的菜单、他的慢病与医嘱用药等。当老人说：“你可以给我定个餐吗？”AI音箱就可能回答：“好啊，我建议你今天来点低热量的，比如上周那家轻食鸡肉杂粮饭，你当时说很喜欢的。”老人说“可以啊，那谢谢你！”AI就可以调用养老院提供的MCP API，就完成了对老人的服务，对于养老机构来说，他们用MCP实现这些业务服务，实现价值。
我们也做了一些尝试探索，包括MCP的定义生成，以及新一代的MCP的中台交互等，虽然现在不很完美，但是我坚信未来一定会往这个方向发展，因为这符合AI终极能力和企业创新和应变能力的要求。通过MCP中台的规划，我们可以提前做好布局，为未来AI友好型的下一代企业操作系统做好准备！
众诚汽车保险IT负责人 陈晓岚
大家下午好，非常感谢中科软邀请我来做主题分享，作为信创试点单位，信创过程中最难的就是核心业务系统的信创化，而难中难的就是数据库的信创过程，且实现单轨运行。我分享的主题就是去年2024年底我们完成的核心业务系统数据库的换芯之旅。
今天分享六个部分：
一、背景情况。
介绍一下众诚保险，2011年成立，广汽发起的，国内首家挂牌新三板的专业汽车保险公司，注册资本22亿。截止到2024年单季度的保费是突破10亿，全年保费突破37亿。众诚保险是响应信创化的号召，创新采用了全栈的信创数据库切换模式，一次性推进核心系统的数据库的替换，化解渐进式的切换弊端。
这是本次涉及到的换芯的整个应用系统的架构，一共涉及到40多个应用系统，共8.8T的数据。在座各位可能对于核心业务系统就是承保理赔出现问题带来的影响大家比较清楚，我再举一个简单的例子。
当你们公司承保系统出现问题时，客户要投保时投保不了，客户就会转投到其他保险公司，这个对你来说是一个利润的损失。但是当你理赔系统的数据有问题时，可能这个时候如果是说客户车辆在半路出险了，他打你的呼叫中心的电话打通了以后没有办法查到保单，这个影响的不仅仅只是你利润问题，而且影响到你整个的社会稳定的问题。所以确保核心业务系统的稳定运行，其实是重中之重，而我们做这么一个系统切换风险非常大。而整个过程中我们顺利完成了。
第二、难点的技术挑战。
这个是整个旧芯的数据库架构，原来用的Oracle的，用到Oracle专有特性，用到大量的存储过程，耦合性非常高。这是大部分中小保险公司的应用系统的一个情况。
整个技术难点：一、你做数据库切换，数据兼容性是非常高的要求，本身数据类型、存储结构有比较大的差异，那你数据迁移过程中容易出错，也容易产生丢数据。第二、数据同步过程中也是非常难的课题，因为你要做 数据迁移要保证双向数据同步的一致性和完整性。第三、应用适配问题，因为有40多个业务系统，其中大量的部分的业务系统还依赖于Oracle专有特性，需要大量修改我们的代码确保功能正常、性能稳定。第四、在金融保险业务的场景它是比较复杂的，对于数据库的性能要求也是非常高的，这个是几点技术难点。
在实施难点方面，因为目前来讲在行业中缺少切换的案例的，虽然有一些大保司做了一些切换，但是大保司整个应用系统还是解耦做得比较好，各个系统相对独立，但是像中小保险公司来说，在应用系统解耦方面做得很差，这是面临的缺少相应的案例。
第二、这个项目要8个月之内就要完成，项目压力还是非常大的。
第三、涉及到40多个应用系统，涉及到多方协同，复杂度非常高。
第三方面就是技术创新方面做了一些什么工作。
第一、选定国产的数据库替换Oracle。
第二、统一升级到OpenJDK8以上。
第三、中间件创新，研发众枢中间件，满足信创的要求。
第四、旧系统改造，建立系统中不可能确保所有系统都用最新的组件，其中就有大量依赖于旧系统，这种系统就是通过定制研发相应的数据源Druid，兼容OpenJDK8，让它能够连上新的数据库。
关键步骤四步：高效管理、应用系统层攻关、数据库攻关、测试验收攻关。
高效管理方面：一、成立项目组织，由我负责管理。二、设立挑战性目标，我们没有随意变更这个目标，大家有一种习惯，遇到比较难的项目经常调时间计划，我们是严格按照时间计划去执行的。三、深度管控整个项目过程，这是项目成功的关键。我们用了一个比较低的方式，每周召开周会的方式，这个方法非常有用。四、这个过程中引入了相应的工具解决项目管理的一些问题，来提升整个管理的效能。
一、成立项目组织，以公司总裁作为领导小组，我负责这个项目。有一个重点，我起用了应用支持负责人作为项目管理经理的角色。因为她是在开发、基础架构和业务之间中间核心点的一个人，比较适合做整个全盘项目的管理。
二、深度管控过程，召开周会的形式，我是全程参与，每周都参与，都是现场参与的，从来没有缺席。要做闭环管理，通过每周周会形式实现，这个非常有用，我们会形成周会的待办事项，对于重要的待办事项做一些跟进，这个是防止把重要事项遗漏，对一些新的关键事项也会在这里登记，靠这个表完成整个项目。
因为这个项目非常复杂、非常庞大、时间非常长，整个过程中不可能所有事情都放到周会上讨论，有一个重点就是所有方案先评审，到周会上做整体决策。
涉及到多方团队，关键点就是消除跨团队的信息差，通过周会形式来消除。
在过程中我们应用到大量管理工具：通过引入缺陷管理方式，引入智慧调度的迁移任务管理系统，我是60个人同时作业的。这是工具的界面。
应用系统层攻关，有Oracle有大量存储过程，在新数据库不支持，就要对不支持的存储过程进行改造，这个工作量比较大。另外就是底层组件的兼容也是比较大的技术难点，我们在这个过程中修正了这个反射问题，修改源代码解决CPU占用率过高问题，还有承保条线优化。
因为Oracle是集中式的，改成新数据库之后是分布式，我们这里做了分布式方案的确定。语法兼容方面也是做了相应的方案去提高兼容性，最复杂的SQL做了一些调优，借助数据同步工具解决数据同步问题，数据迁移借助了数据同步工具才能保证数据迁移的正常进行。
在测试验证攻关方面也是比较重点的，因为在一年的时间里面，你做信创改造你的业务系统还要不停的改造，怎么确保你的业务系统不停改造，不去影响你的信创的进程，你的信创进程必须要跟你的改造也要匹配，这也是一个重点需要去考虑的点。在这个过程中功能测试也是做了全面覆盖，来去确保功能修改，不去影响到信创的改造，信创改造也不影响业务功能，必须在上线前完成所有业务场景的功能测试。数据库替换，兼容性也是很大的重点，也是做了旁路流量回放测试，确保SQL执行成功率。还有性能测试。自动化测试，我们研发人员和测试人员是15：1，在整个过程中怎么确保大量测试能够完成，自动化测试也是帮到起到了很大的作用。
第五是整个上线的效果跟亮点。
在切换当天，除了一条SQL执行计划问题之外，基本上是平稳运行的，经过一周的业务验证也是能够顺利扛下来，性能也可以达到相应的标准。
在切换之后整个低峰期QPS达3000，高峰期飙升至12000，TPS平均300，单轨，不是双轨运行情况。 换芯之后基本上把核心库移到新的库，去到相应的存储特性。
换芯的亮点：一、用户体验得到提升。二、不追求大而全的重构，而是聚焦在数据库关键技术的微创新的方式改动来实现目标，也避免重复的开发投入，这个给中小的机构提供轻量化的信创改造的经验。三、这种高效项目管理方面，也是具有众诚特色的，这是顺利落地的关键点。四、核心自主可控，这是最主要的关键点。
未来展望，整个换芯的实践启示：一、数据一致性问题，迁移最大的问题点就是米的数据必须保持一致，因为核心业务系统的数据处问题肯定死定了。在这个过程中有一个经验就是你单一同步工具比较容易出现错漏的问题，最好用两套数据同步工具做复核校验，确保没有问题。二、数据库性能问题，在切换前一周压侧时，当时4.2.1.7版存在BUG，应用连接不释放导致问题，紧急进行了版本升级。三、切换过程中也出现了数据乱码，后面是因为字符集问题，GBK字符集不同数据库会存在解析不一致的问题。
换芯并不是终点，众诚继续保持我们的探索，深化技术应用，为行业提供更多解决方案和经验。