低成本 Serverless AI 检索介绍和实验
内容介绍：
一、AI检索介绍
二、表格储存介绍
三、实验：RAG
四、总结
本次分享的主题分为四个部分，第一介绍简单例子，由浅入深的了解什么是AI检索；第二介绍表格存储的AI检索；第三通过具体生动的例子做实验；第四做总结。
一、AI检索介绍
首先通过电商客服的例子，了解什么是AI检索以及AI检索有什么需求。以此为例，在网上买各种东西，会和各种电商客服机器人交流，比如问发货时间，机器人会基于规则去回答问题，但问题会比较死板，这样的回答会感觉没有价值。但是通过智能的 AI 回答后，就可以让用户更加满意。首先从历史订单中找到哪些产品没有发货，回答用户每个产品的发货时间以及送达时间。通过传统规则向智能转变，可以用简单的图让大家更好去理解。
用户询问发货时间，分两个流程，第一用户去寻找历史的 QA 文档（由电商客服来支持）。把历史文档中有用的信息检索出，比如说江浙沪三天送达，还有历史的 Meta 信息之类。
第二从数据库里寻找用户最近没有发货的商品。而商品可以统计出相关类似的产品发货时间，做到精确的分析，最终把这两部分数据一起交给通义大模型。此时要注意模板生成或者提示词，告诉它问题是什么，基于以下材料来回答，通义大模型就能生成完美的答案。回到上面关键的问题，如何去寻找类似的 QA 文档。当问的是发货时间，比如说发货和时间。但是检索出来的文档，不仅只有这些问题。它是根据语义的检索，突破了传统的基于关键字和全文检索。那检索技术是什么呢？是接下来要介绍的向量检索。向量检索有什么使用场景？首先引入概念什么是向量？以二维数组为例，二维向量是一串数字，这里代表的是三行文本。用户输入的问题转化成向量，向量和这三行文本在数学里可以用二维坐标轴画出，每个向量之间的夹角是相似度。向量如何生成？向量叫做词嵌入模型，英文叫做 Embedding model，可以把用户输入的像文本、图片、视频、音频全部转换成向量。利用用户输入的向量和历史文档里的向量求相似度，最终在这篇多维空间中找到最相似的向量，这样就完成了向量搜索。
使用场景在文本，图片，语音视频各个领域都比较丰富。第一点以常见的文档搜索为例，它可以突破传统的关键词的搜索，能更方便找到答案。第二点以图搜图、听歌识曲还有以图搜剧的能力，这都是向量检索的能力。了解向量检索后，重新把电商客服的例子画成RAG 场景的流程图，就做到了从检索文档到智能生成。回答的过程中，用户首先输入 prompt 的文本，在历史的资料库中寻找答案，寻找相关的文档。经过 Embedding model，再转成向量，从向量数据库中找到相关的文档。
拿到相关的文档后，将原始问题和相关文档放到一起，经过提示词的模板，最终一起交给通义大模型，通义大模型帮我们生成答案，这是标准的 RAG 流程。AI 检索有什么需求？首先向量检索是核心，因为突破了传统的以关键字和全文检索的检索能力。其次是混合检索，以电商客服为例，电商客服不仅卖衣服，还卖食品。那么在检索衣服关键词时，客服回答食品相关的答案是不合理的，所以在查询相关文档时就需要做过滤，比如限制类别等于衣服，时间在什么范围，这是混合检索的场景。
除此之外，还有衍生的能力，比如Serverless可以做到即开即用，减少运维成本和低成本。AI场景所有的东西都比较贵，比如GPU内存以及CPU各方面。所以希望用最少的成本来提供增值能力时，会给用户带来价值。
此处要提到一个新概念：三方生态。普通的用户在开发产品时，如果直接使用一款数据库，会比较麻烦，但如果数据库它的上下游以及各种三方组件联合密切，可以很快的时间来接入。
二、表格储存介绍
接下来介绍表格存储的 AI 检索，表格存储英文名叫Table store，它是简单高效的结构化数据存储，以表为核心同时结合各种索引，向量检索也是通过索引的能力来提供的。表格存储是Server less自动弹性扩展高可用低成本的同时它还有各种各样的上下游，能让数据流动，方便快速的去接入各种计算引擎以及 AI 应用。
接下来是向量检索的架构图也是核心能力，向量检索相关的能力分为四个部分，从下往上看，第一层是存储层，存储层是底下的分布式文件系统，飞天盘古。第二层是索引层，索引层最左侧是向量引擎。向量索引目前有三个FLAT、PQ和DiskANN。中间是索引的通义能力，就是标量索引以及全文索引能。除了使用向量检索之外，还可以使用索引构建把数据检索出来。索引构建有一些其它的策略。上部分查询层希望尽可能动态避免用户选择以及调优，全部由内部基于一些代价或者基于规则来进行查询和优化。最上层是接入层，接入层有像各种语言的 SDK ，统一接入语言SQL 以及各种三方平台，这些平台是目前在 RAG 领域比较火的应用框架，都做了集成。
将开源Milvus和Elasticsearch功能进行对比。在传统维度，距离算法和索引方面差距不大。在索引方面Milvus提供了DiskANN的能力。在结构层面，比前者多Circle 能力，上述在全文检索标量向量混合检索实时更新和删除实时写入可见。
下面是超过内存大小的向量检索。以传统HNSW为例子的图算法，它需要把所有数据缓存在内存里，但此时内存成本非常高，所以当超过内存大小时，很多向量数据库是不可用的。自动选择方面，尽可能让用户减少选择。多租户隔离可以让用户多个数据库不受影响。规模是相对比较大的所以采用了DiskANN算法。底层用盘古飞天文件系统，突破了传统的磁盘限制，让IO上限更高。动态扩容和运维难度对于开发和运维非常重要，比如新上的产品，因为很难预估产品到底未来有多大量，所以如果能动态的扩容以及免运维遇到问题时能够自动处理，这对于研发和应用来说是非常好的事情，而对传统的 ES 功能来说，当数据量以及数据规模达到一定程度后，需要非常高的运维。
通过以上总结出向量检索的两个核心能力，第一是低成本给大家带来极致的性价比。第二是Serverless能让大家兼具灵活与效率。在低成本上，比如存算分离，混合索引，自适应的查询策略以及灵活的索引构建。在Serverless方面，可以做到快速部署，按需计费，弹性伸缩和3AZ 容灾。
接下来给介绍在向量检索的写入和查询能力，首先左侧的向量写入的架构图。当用户图片文本之类的数据，经过Embedding model生成向量。写入到表格存储里。把表格存储内部在向量检索领域叫计算节点也就是处理，查询，处理写入的东西。但构建向量的过程会非常慢，而且特别的需要CPU和内存。为了上述解决问题，引入了远端构建节点，它能够处理大规模的向量数据构建，而且不会影响存量的计算节点。避免影响传统的查询，远端节点构建好数据后，直接会写到分布式的盘古文件系统里，在查询时由计算节点去盘古分支分布式文件系统里拿到数据文件。
在架构中引入三个概念，第一智能构建策略，根据不同的场景以及不同的规模动态的去构建，完全不需要用户去进行一些参数的选择；第二实时更新，能做到急增集查以及大规模的数据写入；第三远端构件。通常来说，如果向量数据库不具备远端构建这样的能力，当数据突然有很大的量写入时，会影响在线的业务。通过远端构建节点，将速度进行两到三倍的提升，同时可以动态弹性扩容和缩容的，减少用户的成本。也会减少用户的毛刺，能降低两个量级。查询是有自适应的查询策略。当数据量比较少时，通过线性的暴力扫描，其和图索引的检索性能是相当的。这时会做出智能的策略，比如在索引构建时，根据向量的规模选择是构建图索引还是构建线性索引。在数据查询时，根据用户本次查询的规模，如果规模比较大，就可以走图索引，如规模比较小，就可以走很快的线性索引。
后置提供了后置过滤，后置过滤在一些多字段的组合查询方面，可以满足不同场景的需求。总体来看限量能力是功能丰富，除了限量检索以外，还提供了丰富的多值组组合查询、全文检索、模糊查询、全文地理位置，还有尽量级的分析。在应用性方面，设计的初衷是做到开箱即用，没有复杂的参数。查询策略也完全是动态的，扩展性能做到在横向和纵向都能够动态的去扩容，免去运维的负担。使用方式方面，能力也非常丰富，各种语言的SDK，还有支持Circle三方框架控制台 CLI 等。目前支持的三方生态是Lang chain、Llama index等，后面会基于这些框架来做简单的示例。
三、实验：RAG
利用类似电商客服的例子，演示基于表格存储的RAG。
首先演示场景分为两个部分，第一部分是直接以通义大模型问问题。
第二部分是基于表格存储的RAG流程来问问题，接下来观看产品的效果。首先代码。因为集成了三方框架，所以在写例子时，代码会非常的简单。比如说以Java为例，只需要18行代码，就能很简单的构建应用。
只需要简单的配置表格存储的实例，导入了一行数据，再把框架进行组装。且框架是由三方框架，也是拉伸服务器提供的，后续只需要提问，你叫什么名字？就可以回答之前的回答：名字叫小明。上述是Java的例子，还有Python的例子，其实也是类似的。
Python在AI领域比较火，Java在传统的应用比较热门，所以集成了各种语言的例子。接下来看演示，我们使用了表格存储和通义大模型，所以配置了表格存储的实例名表以及账户密码还有通义千问的账号密码，配置好密码。demo启动一开始会比较慢，因为demo内置了词嵌入模型，词嵌入模型会占点内存。所以demo启动一开始会比较慢。
第一部分是实例的初始化，比如创建实例，创建表，还有清空数据文档，方便进行演示数据管理。可以添加文本，以及添加PDF将数据导入，这样就能够基于我们的文本和文件做RAG问答。
第二个部分基于RAM。通过通义大模型看效果。这里演示创建实例，只需要在控制台上或者在命令行界面点击就完成了。以控制台为例，创建按量付费的实例。实例名可以按照提示进行选择。实例规格可以用高性能的或者容量型的，可以根据自己的成本问题来选择，默认提供同城容灾。同城容灾能力完全不需要用户负担额外的费用。为了方便演打开了公网。创建好实例后，打开实例，可以看到实例里面的信息，访问的域名还有描述信息。拿到公网endpoint，可以直接进行使用。展示创建表和索引表，使用框架记录历史聊天记录信息，这样它就具有上下文的能力。
第三部分是Embedding model和Mandy store是记录历史文档信息，比如将QA文档写进去，进行问答时，就可以基于QA文档，进行问答。把数据清空后，打开创建表，有历史聊天信息和文档信息，能够方便的去使用控制台。
首先数据管理，因为数据是空的，所以数据是零行，第一个例子表格存储支持向量检索，直接使用LLM，通过通义大模型问它是否支持。可以看到它答案是不支持向量检索，但是可以通过三方的框架或者是三方的能力来提供。所以它的回答是错误的。这时导入从控制台上导下来的表格存储的功能介绍的文档。点数据详情，看到历史数据，这是通过Embedding model生成的向量，下面是它的原始的文本信息。
把数据导进去后，可以通过RAG来问用户问题，表格存储支持向量检索。并且还给出向量检索的一些通用的场景和能力。它在推荐系统图像检索以及自然语言处理方面是非常擅长的。
第二个例子表格存储的多元索引是什么字段类型。如果不了解表格存储，会感觉回答的非常好，因为列举准确，并且每种类型都头头是道，但其实回答的是主表的Table类型，不是索引的能力，而是表的能力。因为它是根据训练数据获得的答案，而不是根据我们的相关历史文档，是技术文档来回答的答案。接下来通过RAG来问相同的问题，它会根据历史文档、技术文档，找到相关的问题,此时的回答让人满意，其不仅列出了每个字段支持的类型，同时把每个字段支持的查询展示出来。提问RAG典型的场景，以2024的云栖大会在哪举行为例，通义大模型会告诉我们它没有答案，因为通义大模型的训练数据在2023年4月之前。
为了弥补这问题，临时添加一行文档到数据库中，告诉它时间，地点和主题的问题。这时就能根据相关文档回答问题。
由于数据量庞大，定位特定行数据变得异常困难。而采用多元索引技术，即便是在百亿乃至千亿级别的数据规模中，也能迅速定位到每一行数据。这些数据原本以文档形式存在，我们将其设定为分子类型。借助短语匹配功能，只需输入“云栖大会”，便能迅速从海量文档中检索出相关行数据及其历史信息。数据导入完成后，若再次询问相同问题，系统会明确指出地点为“云栖小镇”，并附上具体时间。若询问“云栖大会的主题是什么”，系统同样能迅速给出答案，这一切均基于之前导入的文档内容。这便是RAG的魅力所在，它打破了传统大模型为主导的局限，允许通过训练导入特定数据来解决问题。
综上所述，表格存储中的通义千问RAG具备以下特点：首先，回答精准度高，能有效减少因信息不准确而产生的误解或幻觉现象。其次，它扩展了知识范围，实现了知识的实时更新。任何新数据都可以即时导入，基于最新的历史文档，系统能迅速提供准确答案。再者，它具备生成质量与灵活性的双重优势。以云栖大会为例，将相关信息实时导入后，系统能立即生成最新的答案。
这在日常生活中极为重要。比如，当需要修正某个答案时，由于通义大模型具有通用性，可能无法在某一细分领域发挥最佳作用。此时，通过导入相关的历史信息，可以显著提升其灵活性，同时保证生成答案的高质量。这得益于大模型的能力，使得回答既精确又通顺。
四、总结
最后，对表格存储中的AI技术检索进行总结。
首先，其核心能力是向量检索。向量检索能够同时实现Serverless与低成本的混合检索，这在RAG场景以及其他AI技术场景中显得尤为重要。由于底层采用了DiskANN技术，使得它不完全依赖于内存，从而突破了内存瓶颈。这一技术利用磁盘的低成本特性，既降低了成本，又提升了规模。
其次，易用性也是我们在设计之初就着重考虑的因素。我们尽量减少各种参数和选择，以便开发者能够迅速在技术方面入门，轻松上手。
紧接着，接口丰富性也是重要特点。这主要体现在两个层面：第一层面是查询层面，查询功能支持多种类型，包括分词全文检索、多值查询、嵌套查询、地理位置查询以及空间查询等。第二层面是对外接口层面，我们提供了多种语言的SDK，支持控制台CLI，以及丰富的第三方组件，即三方生态。对于三方生态，我们一直在积极维护与拓展，因为AI领域变化迅速，需要不断适应并维护上下游的生态环境。
