AI时代下的PolarDB：In-DB一体化模型训练与推理服务
内容介绍：
一、回顾PolarDB关键能力
二、使用AI后，资源支持的硬件结构和软件结构
三、PolarBD4AI典型应用场景
四、合思实践：AI对话机器人提升客户响应效应
本次分享的主题是AI时代下的PolarDB：In-DB一体化模型训练与推理服务，由阿里云智能集团数据库产品事业部资深产品专家贾新华和合思信息数据库研发总监刘桐烔分享。
本次演讲将分享PolarDB for AI的关键核心能力，以及在互联网、金融、汽车等行业的最佳实践案例，并邀请行业头部企业的专家进行现身说法。本话题将带你了解AI和数据库在各行业应用中遇到的各种挑战以及PolarDB对这些挑战的应对思路和最佳实践。
一、回顾PolarDB关键能力
首先是polarDB，下面有一个专门用于数据库做专项优化的一个大的高性能的存储polarstopre，polarstopre可以支持500T的数据量。单个数据库集群可以支持到500G的数据量，这是高性能的，另外在AI时代肯定有大量的非结构化数据得到结构化的数据,还支持存在EBS甚至OSS上面，提供一个更高性价比的存储空间，共享在存储上面，支持多种能力。
polarDB又叫乐高架构或者积木架构,对于这个架构的理解是可以根据需要取多个几点或者可以取多个的只读节点用于做只读负载，还可以取几个用于做分析，也可以做缓存，会自动的保持数据之间的一致性，在AI场景下，可以取AI起点专门用于做AI的任务，它们之间的负载是可以互相隔离，互不影响，整个节点根据业务情况自由的选择，所以它本质上像搭乐高和搭积木一样。
从生产端：支持多写，这样可以把生产作为数据，因为在消费端可以基于AI分析之后用于我们HTAP做at来分析，把分析的结果产生价值，在整个底层用两个非常核心的能力，一个就是serverless能力，serverless能力就可以根据我们刚刚说我们写多种节点，serverless可以根据节点的情况，自动去调度下面的资源，让整个的性价比能够得到最好，另外我们用能力是polarproxy能力，可以提供整个的多维度的这种polarproxy能力，包括跨滤镜的部署等。
二、使用AI后，资源支持的硬件结构和软件结构
1、硬件情况
存储是可以500T的高性能存储，在OSS上存储的时候，是没有空间限制的，在计算资源上可以提高，可以提供到63个计算机点，每个节点是4C到32C的纵向节点、任务可以在这里面并行的执行，但每个节点都会支持一张gpu卡，可以选择不用gpu，也可以选择有gpu。这是节点之间通过100GB的rdma网络给连起来，这样能够提供的一个可扩展的并行计算的计算资源这是硬件的情况。
2、软件情况
在数据准备阶段，有几种能力，第一种情况就是有可能数据里面已经特征化了，在外部特征化了，以结构化的方式存在。第二种情况是半结构化的数据处理，经过进行特征处理和半加工把它变成一个特征化的数据。
第三种情况，可能是一个最原始的数据，也可能是一个文档，图片或者其他的，通过就是格式处理和预处理能得到一个半结构化的数据，那在经过一些特征加工，最后变成一个加工完的数据。
在模型使用的时候，提供两个大的能力，一个大的能力，是自定义式模型，提供了下面一系列的算法，可以进行模型的创建、训练等，最后训练出一个适合业务场景的一个模型最后用于推理和使用。第二种是polarDB针对大家可能用的比较多的一些通识性的场景，提供了一个内置模型，像比如说Charbi，还有通义千问以及RAG等。另外还可以调用，用百炼平台去做能力拓展。整体来说，这是polardb在AI里面的整体的软件架构。
三、PolarBD4AI典型应用场景
具体业务场景里面现在polarDB用的最多的三个场景：
第一个场景是MLops，就是在讲两个架构的时候，基于数据去做训练和推理。
第二种场景是ChatBI，可以基于企业内部的知识去做知识库做智能问答。
第三种场景就是智能搜索，基于我们的向量，基于我们的全文检索，搜索更高的更好的能力。
1、第一个应用场景——MLops
MLops和专业的做训练，核心的区别是什么？
第一点，作为最专业的训练需要非常深的知识，要了解很多系统甚至要去做损益函数，非常复杂。
但polarDB，最大的特点就是所有的这些过程，我们做简化、做减法。很多客户，关心业务场景，而不是去做大量的分工，去找算法工程师，找数据工程师，找业务工程师等等去做这些事情，所以在里面所有的逻辑都是在用SQL语句解决问题，不需要去学那么多的语言，那么多的系统。
第二点是会针对最通用的场景。提供的这些算法，这么多的算法的本质就是基于业界的大家用的最多的。这是场景固化了，里面的损益函数参数，都调好了只然后就可以使用了，所以大家的门槛会非常低，在里面只需要你根据数据把它通过SQL去调对应的表，这样的算法去训练，这参数就会设定好，再去用它去做调度就可以了，这是我们最后n of400的使用方法，通过SQL统一管理。
讲两个例子，第一个是说菜鸟，它里面有个典型的场景，就是说我们经常会有那个用户是快递员去把你的包裹给你送到送上门。但这里面就是会存在一种情况，有的是虚假送上门的，他对他来说，他就要解决有没有人是虚假送上门了，他这样的话去对客户继续打电话去回访，但就会变成一个骚扰工作。对去回访本身也是个巨大的工作量，那他要解决的一个问题是什么？先通过AI算法去做一些初筛，把可能的虚假上门的这种情况识别出来，然后再做电话回访，发现是不是这样的，这是它的一个典型场景，原来它是专业的方式去使用的，从数据分析一直到最后的集成推理会涉及到非常多的系统，也会涉及到非常多的语言，给大家带来了两个问题，一个就是说我整个的门槛会非常高，
第二个，成本也很高，那最后后面后来它采用PolarDB，本质上就是要一门语言，就是SQL语言，也只要一个系统，就是polarDB系统，因为它的原来的业务系统就在polarDB里面，这样他通过SQL收获调用就完成了这样的工作，那整体来说可以看出它的开发工作量和这种资源成本都得到了很好的降低。
再来看第二个场景，第二个场景是mlops，它主要是游戏行业，对我们来说，用户流量是非常重要的，要投流，那投流我就要投向比较精准的客户是比较合适的。这样的话，我的成本会有一个很好的一个效率会很好的提升，它的逻辑就是说也是用我们的C口去调对应的模数。调用之后完成训练，最后推理，那整个就是准确率都得到很好的提升，整个它的投放效率提升了50%以上。
2、第二个应用场景——ChatBI，
它的特点支持两种场景。第一种场景是数据在ChatBI中，已经是一个结构化的数据，希望用一种传统方式，直接用SQL来访问数据，现在这种它在ChatBI场景的时候，可以用自然语言去访问这些数据，在里面，首先自然语言出来之后，它会把它转换成SQL语句，然后再去查询数据，最后得到了一个数据，这是第一层数据，是结构化的这一层。另外，这一层还可以支持非结构化，就是结构化的和非结构化的整个数数据知识库里面整合起来，提供一个比较好的答案。
举一个例子，雅迪的这种场景，做雅迪电动车的，他的门店分布在全国非常多，人员需要及时的获取到一些信息给客户去做定档。对他来说是写一套SQL太复杂了也做不到，或者就是说业务系统自己去提前10个客户可能会问的问题把它做到一个系统里面，但是不够灵活，对于整体的用户，我们方案解决了两个问题，第一个问题，就是可以去通过ChatBI实时的访问数据里面的存在里面的数据的内容。第二个能够解决什么问题，就是我们开门店很多可能会要产生一些文案，因为我们是整个下面是内置通义的，还可以给你产生一些文案的准备工作。把知识问答就存在数据库里面的支持率和文案处理，整个等等结合起来，提供你的一个端到端的一个智能问答的能力。
再看一个案例，是个叫视野数科这样一个公司，它本质上最大的价值就是数据资产，那数据资产有核心的痛点：有几千张表，里面大量的数据，我是给一个a公司的时候，他去用的时候门槛非常高，这几千张四五千张表的时候，我怎么我知道每个表干什么的，可能对我来说，学习成本都很高，那在里面就是用ChatBI能力之后就可以把数据价值变成业务价值。
3、第三个应用场景——智能解锁
第三个场景就是能够支持以向量或者传闻解锁，变成一个把结果反馈给你，那在这里面就是说这是数据可以是在我们的in the db里面也可以是在OS对象里面，最后变成了一个向量引擎，里面的数据。
整体来说，就是说PolarDB，当前有1000万家的用户，整个数据规模也非常大，现在我们有差不多100万的核数，全球80个可用区，所以在里面的话，成熟度上是非常高的，大家可以规模化的去使用，并且结合AI场景，所以用我们的polar db AI能力。进一步提升了隐私保护的能力，我们可以在整个方案当中去识别出数据当中存在的隐私数据和高价值的义务数据，对于我们的开发团队，对于我们的合作伙伴，对于第三方我们在使用数据处理过程当中可以采用十多种数据脱敏的策略，帮助我们去保护这些高价值数据和防止隐私数据的泄露，另外在模型训练的阶段我们提供了加噪训练的能力也提供了相应的密太计算的能力，通过这两种能力的叠加，我们能够保证AI模型在最终的推理阶段，对于用户隐私的数据的处理能够达到一个更好的安全保护的效果。
在整个的第二个关键要素，也就是算法可靠性上我们怎么识别算法是否存在偏见，是否存在错误性，可以利用PAI提供的公平性和错误性检测的组件，这样的话我们就可以评估我们的算法是不是存在因为性别、因为地域、或者因为人种导致推理结果存在偏见，如果存在这样的偏见的话是因为哪些参数引起的，我们可以做相应的微调，确保最终达到理想的效果。在效果可靠性的另外一个层面，我们在实际的用户的输入输出的使用过程当中，如果用户输入的就是一个错误的参数，那我们通过这样一个算法可靠的增强的组件，可以保证我们对不合规的不安全的用户的请求进行一个聚扎。另外，我们在模型产出的推理结果会增加一个保护，这个保护可以保证我们的模型推理结果做进一步的安全合规的检查，如果这个保护确认应答不符合安全合规的标准，那我们应该撤回这个推理结果，不应该让用户看到，或我们要让模型从新生成一个更优的结果然后再推给客户，这样我们可以在整个算法推理结果上进行一个拦截和过滤。
四、合思实践：AI对话机器人提升客户响应效应
1、公司背景及开发机器人原因
合思创立于2014年，致力于财务数字化服务的应用与创新，并用前瞻的对象会计理念和先进的AI数字科技服务未来财务人作为一家to b的saas公司，合思已经赢得了7000多家付费客户的信赖与合作。去年来到云栖的时候，数字还是6000多家，很高兴在这一年来，保持了稳健的增长，那新的客户，意味着新的机遇也意味着新的挑战在to b领域深耕的同仁们，或许有共鸣。企业端的客户具有高度的多样性，以合思的标杆客户为例，他们有软件、互联网的，有高端制造的，有生物医药的，也有同属财务行业的不同行业对安全的标准不一样，相应的，他们对供应商的要求也有侧重。通常而言，在我们像客户推介产品之后，如果他对合作感兴趣，会对我们进行资质评估，并且发送一份包含法务it技术等多个维度的安全问卷。问卷，涵盖的题目数量几十到几百不等，大家可以想象我们签了这么多客户，作为内部的员工，也是没少填问卷的。
经过脱敏处理和内容精简之后的视力问卷，大家能看到覆盖范围非常广，从合规层的安全资质，安全团队的设置到物理安全。比如说办公室是不是有门禁机房是不是有监控、这些再到产品上，比如说密码复杂度的设置，然后登录多长时间过期，还有就是技术层面的系统间调用的鉴权，这些它实际上是涉及到了多个部门的职责范围，那以前我们要怎么做，通常而言，在销售和售前过程中，同学的里里面会选拔一个项目负责人，他按照他理解的安全域对这问卷进行拆分，然后发送给不同部门的接口人进行填写，那最后人填着发现说不是自己的业务域，那还要把问卷退回出去。那接口人通常而言，比较朱尼尔一些，他在填写的过程中难免会要，比如说问一些更资深的同学，或者说查询团队，历史上积累的一些文档来填写，填写完成之后，发送给团队的leader进行审核，审核无误之后，然后再返回给项目负责人，由他进行整理合并，最终汇总提交给客户。以前客户发一份评估问卷回来到他收收到完整的答复，通常需要2~5天的时间。这种延误主要是因为涉及到的部门和人员众多，环节繁杂，所以整体效率低下，不得不让客户久等。有的同学可能会问，说你们难道就不能把相关的安全制度和证明文件打一个包，统一发给客户嘛，做事主动一点。我们能，但是客户不愿意客户，通常倾向于设计一套统一的安全问卷发给自己的各个供应商，要求他们填写，而不是在文件海洋中搜索信息还无法确定是不是最新有效版做项目的都知道那各种文件V1.1V1.2V1.5也不知道哪个是最终版。
为了提升响应速度，让客户让我们的问卷平均答复时间缩短至一天以内，我们开发了一个机器人来帮我们自动填写，希望能够确保信息的准确性和一致性.避免过时信息和人际传递中可能出现的错误。
2、目标
目标共有三个。第一是改变人工填写频繁交互的这种低效模式。当智能机器人成为填问卷的主力，提升效率，释放人力。
第二众所周知，安全无小事，我们给客户的答案一定要精准，比如数据是怎么做的，分类分级分了几级，这些都要如实的给客户，不能推理出一个实际上没有落地的策略，给一个假的答案。
第三是事要最短落进最短路径落地，毕竟就是现在只有roi高的项目才能投人去做。
为了达到这些目标，对历史上的定稿文件进行了收集，并且分析经过问题相似度计算，我们发现各家客户在安全问卷中提到的问题具有高度的多样性.比如说所有的客户他都关心数据安全，常问的就是是否有对敏感问题进行加密，进行加密算法选用的是什么？第二个就是大家都会关注，说你们公司已经取得了哪些安全资质，那这种问题它就非常通用，还有一些问题，它没那么通用，比较特殊，但是通常我们也都提前预演过这些问题在文档中也都能找到答案。
3、小机器人落地形态及SQL实现的核心流程及未来展望
基于这些明确了小机器人的落地形态。
第一个是对于70%以上的通用问题，我们希望通过匹配相似问的方式来返回精准的答案。对于剩余的那些问题，我们采用ig模型，对内部知识库进行深度检索来生成推荐答案。
用了哪些SQL来实现的核心流程：
第一步是在Polarbd结构化表，用于存储历史的问题和历史的答案。
然后使用polar for AI的circle，create一张vector table，用于存储这些原始文本向量化之后的信息。使用upload file语句导入将历史文件导入到原始的结构化表中。调用text like对结构化的数据做向量化处理，使用，create model来创建canopy聚类模型，调用predict方法来预测聚类结果，预测离聚类中心最近的就是我们的标准问题，其他的在阈值范围内的就是相似问题，会把相似问挂载到标准问的这一行数据上。
问所对应的答案就是推荐的标准答案，那推荐的标准答案毫无疑问是需要经过人工审核才能作为精准的答案的。所以说，安委会就会使用诸如SQL客户端来查看并修正标准答案。甚至觉得没有任何必要开发一个额外的数据管理平台。现在如果说你需要权限控制，SQL能做到。如果说你需要搜狗需要审计的话，搜狗洞察也能做到那一旦安委会对数据进行审计和维护之后，维护人就会update成安委会，那这一部分的数据就可以用于精准匹配了，大家能够看出来核心的流程，实现总共也就是几条SQL的调用，几乎不涉及到额外的代码开发，非常的简洁，容易落地。
向量化表是生成完成之后，我们通过意图理解开始处理向量化等手段进行全文检索和向量检索的双录召回。通过计算标准问和相似问的计算得分，找到分数最高的这条数据的标准答案来作为问题的答案。返回就是我们的一个检索过程。小机器人，现在已经处于了试运行阶段，它的填写能力整体来说还比较让人满意。安委会也释放了更多的精力来提升标准问答的准确性和实时性。现在我们还保留了最后一步的人工审核，并在需要的时候加盖公章 这是为了确保信息的权威性。
尽管在不太遥远的将来，小机器人的准确性和实时性大概率就会超过人类审核者。但是，人类的介入对建立客户的信任至关重要。他向客户传递了一个明确的承诺。合思将全力支持并负责我们的服务。
那对于刚才提到的安全问卷场景，有一些尚未纳入标准问答的环节，这一部分我们是基于知识库的智能问答机器人来辅助生成。
4、参考答案
智能机器人的场景绝不仅限于此，以合思为例，何思，这是创立的第10年，很多我们之前用的开源组件可能已经停止维护了，贸然的替换组件可能会引入新的风险，大家就会问，说某某某中间件历史上发生了多少次故障，或者说在我们的系统里面发生问题最多的中间件的Top5是什么？那随着企业规模的扩大，我们也经历了知识管理工具的变迁。从vicky到保安M内置的各种文档塞到direct偏扣的等项目管理工具上，每个平台可能都会挂载一些重要的文件，那我们要查这些信息，重新到就安排搜索一遍这些系统也不现实，所以为了保证企业知识的有序传承，防止因为工具切换，甚至人类员工的流动带来的知识损失，我们使用私有知识库加Polar forAI来集中存储和管理信息，它不仅能够保证数据安全，同时可以通过提升检索和智能分析能力，使得知识充分的释放价值。对于知识库的自动构建，这是一个相对普遍的需求。
Polar forAI也提前，集成了很多能力，所以我们在上面实现的流程就更简单了，就首先还是create一张结构化表，然后upload file，上传语句，它会自动的根据标记标题级别等进行切分，将文档和已经定义好的类目进行关联，同时我们也会使用SQL来构建分词和倒排索引。为了提高结果的准确性，我们还使用掉了大模型中的keyword的能力来对文档的关键字进行标识，比如说像刚才提到的maxwell，我们会发麦克风的故障，复盘文档上达标。Maxwell中间件。
其二，故障，但这一部分我们期望的是能利用。nl图SQL的能力，实现一个相对准确的召回。说回rag检索，那在检索的时候我们还是采用了分词和向量检索，这种混合召回策略，通过设置召回数量，得分阈值问题改写以及风险词过滤等条件，精选出top n的最相关结果，对这些结果进行排序之后，我们可以生成答案，同时很多信息是不能有错的，所以我们要保证信息的可追溯性。在返回结果的时候也会带着原始文档的连接，以及它这部分的内容来返回。在技术选型的时候，我们除了Polar forAI，也调研了一些其他的开源的AI平台以及IM中自带的AI能力。对比下来， powerful db这种搭积木的设计在已有的数据库集群上添加AI节点，通过SQL来操作文件，上传解析，向量化内置了常用的分类聚类回归生成这些算法，通过SQL来生成和调用小模型，并通过SQL来访，问对接的大模型，并进行一定程度的反衬。这种易用性缩短了，我们从需求到实现的路径，使我们的重心可以放在业务上，在自己更擅长的领域创造价值。23年的时候，我们已经在线上应用了HTAP能力，那今年又在探索AI的能力，这种设计使得把模型推向数据显得非常合理。数据转化成知识。帮助我们更高效，更明智的做出决策，也是指日可待的。在生产的业务上正式跑AI能力之前，会选择在一些内部的平台上进行试水，以确保自己充分的理解其能力边界，并积累最佳实践。比如问卷，还涉及到英文问卷的问答。未来polar能够结合其翻译能力，帮我们更精准，更高效的回答，那么在线上的业财业务中，也希望利用polar的AI能力来提供个性化的业态服务，比如风险控制，合规管理，预算规划，决策支持。很期待polar的AI能力能像乐高的轮胎组件一样提供更多的灵活性和创新性。
