非“典型”向量数据库AnalyticDB PostgreSQL及RAG服务实践
内容介绍：
一、行业发展
二、AnalyticDB for PostgresQl产品介绍
三、RAG行业探索
四、企业级解决方案设计
五、典型场景案例
今天分享一下非“典型”的向量数据库 AnalyticDB ，以及现在服务几百家客户所带来相关的服务事件。
第一介绍整个销量行业的发展。
第二介绍这款产品。
第三介绍在整个外部服务的过程中对行业进行的相关性探索，包括各个客户整个的开发习惯、使用方式、场景化的服务，进行深度的解读。
第四个部分介绍面向多个企业承建了行业解决方案，企业级的智能化应用的构建方法。
第五介绍相关的客户实践分享供大家参考。
一、行业发展
首先第一部分从大圆模型整体的发展历程来看，在3月份的时候 chatGPT 发布了 Retrieval plugin ，实际上是将向量的概念到了正式引入到的web方法体系里，让企业可以用自身的知识结合大模型一起完成多种场景的解决方案，帮助企业真正能够用到自身知识来进行行业性的服务。
随着链路的发展，包括大模型的演进、百模大战多个工作模式的整体演进。
在今年6月时 OpenAI 收购了 Rockset ，大模型正在与数据进行更加紧密的整合，对于场景、大模型、数据的支持和数据对大模型的辅助，两者之间能够产生更多火花。数据库也是进一步的把视野拉到数据库的一侧。
1、AIGC 分层能力一览
整体上简单将其分为两个部分，企业层的服务，包括了企业的核心知识库，以及企业自身及与自身知识和大模型结合的 fine-tune 优化调优的模型。对于模型服务商更多以大模型为基础，有很多垂直行业的模型都在不断的衍生。最上面知识库的承载实际上用到的是企业级的相关数据库能力，再加上相关的检索能力，无论是大模型、行业模型、企业专属模型、结合知识库，整体上构建企业的 2.53 的一套应用。
2、向量数据库图谱
当下数据库的向量数据库是非常火爆的概念，非常多在香港成功的厂商， chroma 、 gldrant 、 ROCKSET ，它们能够快速的基于自身过往时间的积淀，比较好的承接当下的纯向量测的相关的需求。同时这一次面临的不仅仅是向量单纯的检索，而是企业级知识库的搭建，所以也看到了很多数据库的厂商，它们将自身的能力开始向量进行相关延展，支持原来的结构化的数据，非结构化的数据，面向向量的相关性的支持， AnalyticDB 有点像从另外一个视角进行切入，它自身是一款非常强大的数据分析引擎。在2019年自研相关的向量引擎，解决在当下对于图像检索、人脸识别相关场景下需求的能力。它拥有非常完备的企业级能力，类似于 ROCKSET 。在这种情况下对于企业级的相关知识支撑，这款引擎有相关的、独特的竞争优势，同时也非常契合在企业级上的构建，在 REG 这个时代需要的语义检索以及数据处理的能力。
二、产品介绍
1、AnalyticDB for PostgresQL 数据库介绍
AnalyticDB 是阿里云自研的原生的向量数据仓库，对标的能力也是国家的头部友商，例如 Redshfit等...分析性能是非常完备的。在2019年自研了向量引擎。向量引擎是全量适配了整个的产品架构，在做了相关测试上相较于开源的产品是有优势的。
2、AnalyticDB for PostgresQL社区合作
随着开源社区整体的演进， AnalyticDB 在服务客户时实际上也看到当下的主流开发形态，更多的是用户基于开源的社区、基于开源的 Framework 来构建自身的 Retrieval 体系。无论单长源还是构建企业的 AI 中台，对于开源的支持，AnalyticDB还是紧紧的跟着社区进行相关的支持。包括 OpenAI 的ChatGPT Retrieval Plugin 、Langchain 、Llamalndex、 Streamlit & dify 高速增长的社区，目前已经适配相关的 引擎，对于核心的场景，长短时期的记忆、整体时期的召回策略，在 ADB 进行了相关适配，虽然是自研的相关产品，但与开源社区还是紧紧的组在一起的。
3、AnalyticDB for PostgresaL 架构介绍
关于 AnalyticDB 核心的架构介绍，首先它是一款 MPP的数据库，在服务客户时，客户经常会提出疑问，当数据量变大时，只用向量数据库，比如重的内存管理的数据库时，随着业务变大，内存开销变多，数据量变大，这款数据库经常会产生运维过难，然后数据量过大导致的性能变低，或者是整个的内存过高，导致整个使用成本过高整一类的成本问题。
ADB 这款产品实际上是一个数据库，它在整个的延展性的服务范围上，是可以做到从用户的早期陪着用户，随着数据量不断的增多，服务的面积不断的变大，可以进行非常顺滑的延展性的支撑，去满足随着业务上的低运维成本下的高性能的持续性的拓展。
同时 AnalyticDB 也支持用户进行磁盘的融合查询，也就是索引的查询不一定要全部放在内存内，可以更好的平衡性能和成本。这里也是独特的相关的能力。对于整个的执行逻辑来说，它是一个分布式执行策略，即使在向量的检索，包括语义查询的检索上，也能够做到每一个语义的分布式执行。在这种检索上，随着节点增加，可以提升整体的查询的能力。 AnalyticDB 支持的向量查询、全文检索以及结构化查询的融合查询，客户可以用一站式的方式来进行混合的查询逻辑，同时进行整体性召回准确率上面的提升。
在这些改造之上， AnalyticDB 保证所有企业级能力的完备，包括负载隔离、事务性的保证，并且进行包可用、包可靠的架构，以及相关的备份恢复、这些能力是非常完备的。目前有非常多的企业希望用高可靠、低运维成本的方式去构建自身可延展知识库的。
4、ADB-PG 一站式融合查询查询优势
上图是 ADB 相关的融合查询的案例，在这个方案里使用了一句SQL 进行了全文检索和向量检索的融合查询。当下融合查询的需求越来越多，包括今天的使用稠密向量加上全文检索，有的客户在使用稠密向量加系数向量，同时复以结构化的查询的方式，能够更好的进行基于业务语义、整体更高质量的召回。这些高质量的召回实际上帮助我们的企业在做大模型做推理时，有更好更完整的相关语义。在这一套引擎里使用方式其实是真正的卡点，原来需要用多款引擎进行拼凑式的使用，当 ADB 可以使用一站式进行全部的查询策略时，极大程度上的减少了用户在多个引擎拼凑过程中所带来的相关的复杂性的成本，能极大的帮助用户去减轻服务成本。
5、AnalyticDB for Postgresal 向量能力架构及优势
AnalyticDB 自身是做了非常多优化，相较于算法策的优化，从底层的指令层就进行相关优化，包括面向阿里云上多元的芯片的服务、SIMD 的芯片、intel芯片，这些有非常低层以及深度的合作，进行整体性能上的重大的提升。
其次从算法上，分区的典型的改造能够做到对于向量上的非常完备的支持，做到分布式下性能整体可以进行线上提升的能力。同时执行计划侧，也进行基于代价的相关性的优化，支持用户基于自定义的性能的方式来进行相关性的调整，增强的能力，开放给高阶的客户可以进行自主的管理。
6、企业级专属RAG解决方案:通义百炼专属大模型
目前基本上所有的向量引擎都能够做到比较高的召回的精准度，可能在企业级的完备能力上不同的厂商提供的服务等级是不一样的。 ADB 的企业阶段比较完备，更多依赖于多年打造的数仓完备。对于实时和离在线一体，更新事务型的管理，包括融合查询、分区、高可用、超存、多个向量支持，这些能力可以提供很丰富的能力给到用户，去构建更丰富的场景。
三、RAG行业探索
1、企业AIGC应用设计-企业基于LLM+知识库构建聊天机器人
RAG 的逻辑是在构建 RAG 上的方法论和流程图。
2、AnalyticDB for PostgresQL生态全景
当前 ADB 在整个的全景支撑生态上，支持结构化的数据源进入到支部，包括飞行半结构化 mongo 、其他的引擎，还有开放的数据平台，例如 Hadoop 、 HIVE ，或者是数据湖的，例如文档图片视频声纹，对于这些 ADB 可以做到有相关的接口，包括方法论数据的加载，能够做到比较完备的前置的数据建仓，数据知识库的构建的流程。
整个的服务过程中，在原来的核心的数据能力的服务上，构建 API 的服务层，服务层更多的是面向全场景应用来进行搭建，其中包括了三块，一个是整个创建流程中，从文档的处理、文档的切分、数据的存储，结构化语义的召回，结果的精排。对于这些方式，全部提供了独立的 API ,帮助用户面向应用进行创建。同时也提供数据服务的 API 和资源管理的 API 。也就是说使用 ADB 的用户，不一定要用 SQL 来进行整个的创建，而是可以全链路的通过 API 的形式来进行相关的服务。
随着 API 的成熟，60%的客户都在使用 API 对于开源框架的支持。比如说 Dify 的用户、Streamlit 的用户、Llamaindex 的用户。目前对于这一套集成相关的、完备性的支持，以及这些社区生态的支持，他们更愿意将自己的核心的企业知识库托管在 ADB 上，而面向应用做到灵活的多租户的开发，也是服务客户的主要能力。
这一套能力在服务外部之外，也服务阿里云的商业化的产品，包括阿里云百链是阿里云的大模型核心的商业平台，阿里云的析言是阿里云 SQL 的核心服务平台，还有点金、灵码场景化的，例如代码助手、点金财报研读、阿里云小蜜的客户支持， ADB 目前都是作为核心的、向量的、基础层来进行服务。对于海量客户以及海量产品的服务，有比较多的技术积淀和方法论的积淀。
3、ADB-PG一站式AI服务及仓内智能
在整个的服务层以及 SQL 层全部进行了相关性的支持，同时也支持使用 AI 或者 DB ，大模型的能力可以在数据分析场景上对数据分析进行相关性的加持，比如使用通义的大模型进行客户问题的质检，对用户相关性的评论进行情感性分析。在仓内支持原生的调用方式，ADB 是一款既可以 DB FOR AI 的产品，也可以是 AI 或 DB 的产品。做到了整个数据分析加上整个的企业级数仓，一站式的构建的体验。对于整个的存储层，也支持这种多模态的存储，可以帮助客户可以用一套引擎更好的的管理所有的企业数据资产。
4、ADB-PG RAG Service -站式满足业务应用开发
这是整个的 RAG Service 的一站式，可以看到从整个文本的处理，包括文本、图片、文本加图片，视频，对于这些方式，都支持独立的每一个原子力度的 API 服务，这些服务之间可以连续调用，也可以独立的进行调用。
对于 Embedding 也是在持续的去支持开源的算法以及阿里云独有的算法，包括通义比较高阶的 Embedding ，这种 Embedding 的算法能够有更好的召回率。
对于多模态，进行基于语义的通排，去保证制作给到大模型时，这些内容是有更为相关性的语义更靠前的，能做到整个的召回结果更为精准。对于垂直行业，包括专利的处理，电商领域的应用，也是做了相关的特定的、文本处理开发的能力。
四、企业级解决方案设计
面向不同的企业时，实际上也有多套的解决方案。
1、企业级专属RAG解决方案:通义百炼专属大模型
首先第一个推荐的是使用阿里的通义百炼的产品，通义百炼的产品提供了全链路的整个模型相关的所有服务，包括模型的训练，模型的使用模式，基于模型进行微调，在整个的百炼的应用部分，支持去创建用户的智能体，支持为企业去创建独立的专有知识库。企业可能非常担心我们将数据投递给了百炼平台，百炼平台是否会有数据的相关的风险或者合规的要求。企业可以将自己的核心知识库，是在企业域内购买一台 AnalyticDB ，将这台数据库连接到百炼平台，所有的数据处理后，将切块的文本全部存回到企业私域内的知识库，进行相关的投递到百年模型平台，进行相关的场景化的语义生成。
通过这样的方式，能够做到所有的数据保存到私域，但是对仅有用于推理的逻辑的数据而进行部分的透传。而在企业内部的 AnalyticDB ，它可以做到对于企业所有的 prompt ，进行所有的 order 。例如今天不希望提供对外的服务，可以将这个知识可以进行整个的所有网络的断连，可以保证所有的知识都在内部，全部在企业私域，而不在进行透出。这种情况下是可以满足绝大部分场景下对于数据安全上的顾虑。也是我们提供给客户非常可靠的数据层面的保护，同时结合大模型使用的标准的方法论。
2、RAG核心技术-OCR/IDP
在整个服务的过程中，对于数据处理也有文本上传后的 OCR 的识别，阿里已经有一款叫做智能文档处理。它对于文档的提取相较于开源产品，可能有更好的段落分析，整个的内容解析，并且进行切分的优化的定义。这些能力都会在使用百链的过程中，为各位服务提供便利和准确性的支持。
3、RAG核心技术-GTEembedding
在与百炼服务的过程中，很多都有相关性的增强，使用的Encoder-Only 长短文本的训练模型，对于可能全文加上稠密向量的
查询准确率，不如 Sparse&Dense ，可以提升20%左右准确率。通过这样的方式，可以更好的为客户提供召回准确率上的支持。包括几种主读语言后，演化出多语言相关性的支持。对于这些，实际上都可以在使用百链的过程中进行相关的服务。
4、开源模型半托管解决方案-计算巢服务部署(on PAI)
除了使用阿里云自身的这样的方案，客户更倾向于当下继续使用开源的框架，甚至说企业构建了一套，面向企业自身内部的多场景的应用。这时 ADB 也是支持面向这种场景进行比较高质量的服务，这个是在计算槽上帮助用户快速部署的一套方案。例如用户可以在 ECS 上也就是计算资源上构建一个多场景的能力。通过 AnalyticDB 的使用，再加上向量支持库上进行的独立租户的隔离，可以做到对于不同的应用进行独立的知识管理，独立的权限管理，独立的使用管理。同时也支持这套框架里面去调用阿里的另外一个服务叫 PAI EAS ，它可以部署多种的大模型，开源的模型都可以进行布属同时进行训练。集群可以使用 GPU server less 帮助进行管理，这三者结合可以帮助企业最大程度上实现开源的使用，不被整体厂商进行绑定，同时也可以利用开源优势，对企业内部的多场景进行相关性的支持。目前现在也有大概10~15%左右的客户，在使用此类方案进行平台的搭建。
5、开源模型全开放解决方案-全开放的部署能力
当模型是外部的商业模型时，整体的框架上也可以支持用户去独立去调用海外的开源模型或者基于自己部属的 GPU 进行相关的支持。总体上这一类可能是出海的客户会比较关注，比如服务框架依然使用这些面向 ADB 进行独立创建，同时进行海外模型框架的支持。以上三种都是现在主流支持的形态。
6、基于ADB-PG 构建的RAG多租户服务
对于一些客户，同样在 AI 一侧的服务上，面对的更多的是作为服务商会有很多的 RAG 场景和海量的客户，如果是小的基模的服务商或者，在支持阿里云内部多个产品时，构建多租户的一套方法论，用户可以对于中长尾的客户和独立的 VIP 客户进行资源的综合管理。通过 RAG 服务层，可以将整个的资源进行中长尾的多租户的构建，每个 namespace 都是一个租户，他们下面的每个知识库都对应一张表，通过这样的方式进行逻辑的隔离。对于头部重要的客户上，还是需要独立的资源服务时，可以创建专属资源实力进行物理层面的隔离。这种方式可以最大程度上保障有限的资源服务更多的客户，同时对于头部的客户进行独立资源的支持，保障头部客户的体验。下面存储的部分可以做到水平的扩容，满足日益增长的用户和日益增长的数据量的体验。这里可以面向基模服务厂商可以提供比较好的架构支持和最佳实践。同时 ADB 也支持私有化部署，现在在国央企上，也通过这样的方式进行一些相关性的输出。
五、典型场景案例
1、游戏行业-游戏客服升级
首先是游戏行业的客服，游戏行业实际上在新游的发布，运维期间或活动期间会有大量的客服的客诉产生，但是游戏没有办法去快速的把整个的客服人员进行快速的招聘和弹升，这两者的服务不对等导致在游戏这边是有极大程度上需要大模型，通过自动化的方式，去提供高度人性化且是可以完成用户意图的客服的系统。大模型加上我们近百款游戏的独立的世界观，可以做到这样的方式。也就是说每款游戏有相关的世界观以及相关知识的能力，同时客服的语气语调，通过大模型加上知识库的方式，两者进行自动化的相关客服的升级，可以实现多轮对话式的支持。
2、全新AI智能客服游戏体验
在一些客户上进行了相关的实践，在对于整体的准确率上有20%的提升，同时服务成本有较显著的降低。对于新游的接触实际上快速构建游戏的基础的信息和体系，以及持续性的更新游戏的活动，可以做到客服框架的支持。同理，对于游戏内的 NPC ，也看到了非常多的客户在使用这一类方案进行相关的支持。
3、阿里云产品博士落地实践
第二个部分的话是阿里云自身的产品改造，随着的业务的发展，阿里云有非常多的员工，需要很大的企业级的知识大脑的支持。
对于企业进行核心支持需要对企业所有的知识进行相关性的梳理，同时用大模型方式进行核心问题的回答并提供支持高效率的传播。阿里云内部实际上也在去年进行了非常深度探索，目前这一款阿里的产品博士的能力目前也在服务于阿里云内几千个客户，整体的方案的话就是阿里云的百炼加上阿里云的私有化部署，两者结合起来进行相关性的实践。
4、阿里云产品博士落地实践
在整体的服务过程中也分为4个阶段，第一个阶段更多的是企业级的业务梳理完成 POC ,完成基础能力的搭建，网络环境的搭建，能够通过当下的语料完成整个流程上的支持。第二个部分基于质量的召回的内容进行持续性的质量性的改进，包括 RAG 在检索上使用体验的升级，对于 chunk 和 embedding 的相关性的优化，服务的能力目前都已经沉淀到百炼上，也就是用户如果需要再使用，都可以将这些能力进行开箱即用的给到各位。
第二部分是企业内配套的质量内容的规划，还是需要企业内部持续的去对松散的格式进行支持，对于产品内部的支持。第三个部分也可以进一步研究大尺寸的模型，在核心准确性要求较高的产品上进行相关的支持，同时也会对内部的内容进行一系列的分类覆盖，通过检索时，前置引入了相关的 AGE ,对于不同类别的问题、不同门类的内容，进行了指向性的方向。
对于 ADB 可以用融合查询的方式去收敛的更为关联性、更高的内容。最后是在应用体验上进行升级，去帮助用户在体系感上进行相关性的升级。目前非常多的企业了解到这款产品后，希望能够在自身的企业内落地这样的服务。
以上为分享全部内容。
