Lindorm：基于多模数据服务的一站式智能检索基础设施
内容介绍：
一、Lindorm：基于多模数据服务的一站式智能检索基础设施
二、MiniMax Date Infra在AI场景下的探索 数据库、数据湖赋能大规模快速迭代
一、Lindorm：基于多模数据服务的一站式智能检索基础设施
分享的主题是关于多模数据库如何为AI时代的应用来提供一站式的智能搜索搭建的基础设施。随着AI模型能力的不断的爆发，越来越多的AI应用在蓬勃的生长，这些AI的应用越来越多的依赖在云上提供的基础设施，为他们提供生长的土壤，今天的分享的内容可以分成三块。具体针对大规模的智能搜索领域，首先看AI的大模型是如何推动类似于search gpt这一类智能检索的技术的发展，再看新一代的智能检索系统的技术特点和挑战，最后深入了解Lindorm，看一下针对AI的应用提供的一站式智能检索基础设施如何能够帮助企业AI开发者快速的去开发和迭代他们的AI智搜相关的应用。
1、AI大模型推动searchGPT智能检索的发展
（1）AI大模型带动searchGPT智能检索产品迅猛发展
随着AI模型的发展，模型能力一天比一天进步，而且越来越快。但是当我们在讨论模型能力的进步的时候，有一点是我们不能够回避的，那就是要如何实现AI的商业价值。不久前correct的AI宣布解散，这是世界上用户量最多的聊天的app，宣布解散加入谷歌，这意味着AI模型能力的变现不是一帆风顺的。在三四个月以前openAI收购了rock set，随后不久就推出了searchGPT的新一代搜索应用。类似于微软、谷歌、一些其他的创业公司都纷纷把AI大模型的能力和他们的传统的搜索做了深度的结合。因为回顾过去20年互联网发展的黄金时代，最后是搜索和广告场景的技术和业务取得了最大的商业价值。背后隐藏的逻辑是整个数据业务它最大的一个价值的实现就是在人们对于数据的消费和决策环节上。
基于大语言模型，整个搜索的领域都面临着一个巨大的革新，这也是所有的搜索引擎的巨头和众多的创业公司纷纷加入这一个领域的原因。阿里云作为云上基础设施的提供方如何为越来越多的AI的创业公司以及开发者提供足够好的基础设施，来让他们能够快速的去开发基于大语言模型的各类智能问答式搜索的应用，这就是今天讨论的主题。
（2）大模型时代智能检索的产品革新
在大语言模型智能搜索这个场景，从用户的视角，它至少带来了三个改变。
第一个是用户和搜索的交互方式发生了改变，过去是基于关键词的搜索，现在基于大语言模型的智能搜索应用已经演化成了基于对话聊天式的一个搜索交互方式。
第二个是对于内容的消费角度也改变了，过去搜索是要通过关键词搜索出内容，然后再依靠人去逐个地阅读每一篇文档提取相关的信息，现在通过智能搜索应用，只需要让大语言模型去阅读几十上百篇相关的文档，然后就能总结出相应的答案。
第三个是人们对于搜索方式习惯的改变，过去使用各种搜索的应用，我们期待输入内容到搜索框之后，搜索结果在一秒钟之内返回给我。现在基于大语言模型用户可以忍受几秒甚至十多秒的这个时延以获取一个更满意的答案。所有的这些改变，对于设计下一代的智能搜索问答的基础设施的基础及架构，都带了深刻的影响。
在技术角度，基于AI的智能搜索和传统的搜索都在发生变化。通过不断的迭代embedding模型和reranking模型，基于向量和AI模型做出来的搜索系统它能达到的效果是能够实现相对于传统基于全文检索的一个赶超，但基于AI模型和向量的搜索结果，它消耗的成本也是巨大的，至少比传统的全文检索高出了一个数量级甚至两个数量级。我们可以预测未来AI搜索会逐渐过渡到一个以AI搜索为主全文的传统搜索为辅的搜索框架，越来越多的企业把他们的私域知识当做一个知识库，去试图使用大模型来以基于搜索问答的方式使用他们私域的数据，换句话说就是这个RAG的系统。在未来绝大多数AI的应用中，智能检索问答将成为这些AI应用的基础原子能力。
2、智能检索系统的特点与挑战
构建下一代的智能检索问答系统有许多的技术挑战。从high level来看，它实质上是传统的基于全文检索的系统架构和embedding向量、reranking模型等等技术，做的智能搜索两者的一个融合。这么一套特别复杂的，这里面的技术挑战具体总结为三个维度。
第一就是构建大规模尤其是规模扩大以后的资源成本非常的昂贵，如果用多套子系统去搭建一个infra，会面临着非常多的数据冗余以及资源的碎片，还要搭建非常多种不同的链路去链接这些子系统，整体的系统搭建成本是非常高的。
第二是运维的压力，因为要分别运维多套不同的这个子系统，每一种子系统它都有自己的技术特点，需要去深入的了解各自的资源使用、弹性、资源、智能管理等等，都非常的复杂。所以如果想要长期运维一套如此复杂的智能搜索的infra，挑战是非常巨大的。
最后就是如果用原子组件去搭建，实际的应用开发效率会很低下，因为需要去学习不同的子系统的特点。在AI快速发展、迭代的现在，如果开发者把绝大部分精力放在学习底层的各种子系统上，显然会影响它的开发迭代效率。
3、Lindorm:构建一站式智能检索基础设施
（1）Lindorm:为AI时代而生的多模数据服务
阿里云的多模数据库Lindorm能够帮助我们的AI运作开发者来处理上述的一些挑战。我们把Lindorm叫做为AI时代而生的一款多模数据服务，是因为在AI时代各种各样的数据源非常泛滥，产生了大量的结构化、半结构化和非结构化的数据，这些各种各样的数据需要非常非常多的繁杂的不一样的计算服务来处理它们。针对这样一个特点设计了一款多模数据服务，它是一个完全云原生的架构。首先在最底层会提供一个完全云原生的分布式存储文件系统，来支撑存储各种各类有结构的或者是无结构的数据。
最上层给用户封装了一层统一的apiSQL接口，能够让用户去访问和使用它存储在Lindorm里面的各种数据资源，并且调用Lindorm的各种计算功能。中间层我们帮用户隐藏掉了所有的复杂性，能够存储各种结构化、半结构化多种格式的数据，同时Lindorm提供多种计算的能力来分析和处理不同类型的数据。这样就使得用户在AI的时代，应对多种类型的数据和多种数据分析需求的时候，它不需要去分别维护、去学习、去开发这些各自的子系统，只需要使用Lindorm来隐藏掉底层的复杂性。Lindorm能够让用户以比较低的成本和更高的开发效率去迭代它上层的应用，所以它获得了广泛的开发者，尤其是AI应用开发者的欢迎。
（2）Lindorm一站式多模能力构建SearchGPT
在这个架构里面，它分成在线的搜索请求和离线的数据处理。Lindorm它针对刚才提到的复杂性提供了一些特别的处理能力，比如用户把数据写入以后，就能够自动的把用户的数据从写入宽边以后同步到用户的向量引擎或者是相应的全文检索，使得用户不用自己处理数据的同步。又比如Lindorm内部提供了AI的推理能力，它能够使得用户开发它的应用的时候，不需要额外的在外部去部署它的模型和调用它的模型的推理，对于reranking、invading这些模型的使用，就可以把它当做一个简单的步骤在数据库内部完成。
（3）一体化架构降低运维和开发的复杂度
用户只要把它的数据从Lindorm的api写入我们的宽表或者是写入我们内存，我们内部就会自动根据用户的配置，对这些数据构建相应的搜索索引或者是向量索引或者是列存的索引。底下的数据不论如何，当用户有数据更新的时候，相应的对应的索引也会得到相应的更新。这就使得用户完全不用担心他需要去分别维护数据同步和更新的状态，只用关心使用我们提供的统一接口来完成他的开发任务。
（4）极致弹性，助力业务腾飞
在提供了多种存储和计算引擎之后，在AI时代应用的使用量的爆发是非常难以预测的。所以Lindorm无论是它的存储还是上层的计算，都具备分别扩展的弹性能力，这就使得业务的开发者不用太担心他对资源的过度使用或者是资源不足的情况，随时用随时弹。
（5）高性价比全文+向量双路召回
Lindorm具备针对AI搜索的三个关键能力。第一个是Lindorm的搜索引擎是一个内置的全文搜索，AI搜索问答它是一个AI搜索加上全文搜索的一个组合，除了提供非常好的性价比之外，它也是完全兼容ES API，这是一个对开发者非常友好的生态金融。然后对于Lindorm的向量引擎而言，特别针对SearchGPT这样海量数据的场景，实现了分布式的磁盘索引能力，不仅能够支持数据的插入和删除，同时也能够提供极致的性能，最低延迟能够低到10毫秒。Lindorm的AI引擎是基于英伟达的传统加上pythonRT的一套软件站，在数据库内部实现了分布式的推理引擎来处理这些搜索金融所需要的模型的调用。
（6）Serverless计算，能离线ETL，也能交互分析
Lindorm也提供传统的兼容spark和mpp的能力，能够方便用户去调用批处理任务，启动任务去清洗处理的这些原始的数据。而且Lindorm的所有计算引擎都是按需拉起，然后随时可以弹性的扩展。
（7）Lindorm:AI时代的一体化开发平台
针对AI时代应用的开发，我们把Lindorm设计为一个AI时代的一体化开发平台，它能够以极低的成本提供非常海量的互联网级别的规模和业务吞吐。Lindorm在基础设施之上针对智能检索提供了融合检索的能力，包括高度可扩展、低成本的向量、标量、全文、AI推理的辅助能力，能够帮今天的这个AI应用的开发者去快速的构建AI应用并且迭代他们的业务，而不用太多关心底层的研发细节。
二、MiniMax Date Infra在AI场景下的探索 数据库、数据湖赋能大规模快速迭代
1、AI场景下数据的挑战
主要分享一下MiniMax在AI场景下面的使用数据上面遇到的一些挑战以及是怎么去解决的。
首先大家都会碰到的挑战，就是会有文本、图片、音视频这样的一些非结构化数据，这些在传统的数据库里面是天然的没有支持的，怎么去处理这些数据，把这些数据做好，训练我们的模型，是一个非常复杂的过程。
第二就是存储在这方面已经变成了gpu算力之外的第二大成本，经内部统计，公司内部的成本最大的就是gpu的算力，第二大的就是存储，包括对象存储、数据库这些方面。
第三就是在做数据使用的过程当中，是gpu跟cpu都要混合使用的这样一个场景，我们有很多AI训练数据预处理的过程，需要把互联网上抓取到的各种数据做一个数据过滤，以及把视频文件做一些转化切帧之类的操作，那这种场景下面就必须使用到gpu。一些传统的场景比如要把一些文件做一些合并，这些用cpu处理就可以了。我们的业务负载的主要场景就是cpu跟gpu的组合的这样一个需求。
第四就是会有公有云跟自己自建的IDC机房混和使用的场景，因为MiniMax毕竟是一家专门做大模型的公司，所以自己采购的gpu相对来说比供应商要便宜很多，使用到gpu的场景基本上都是在自建的IDC里面去用的。cpu价格卷的比较厉害了，使用共有云跟自建来说，如果自己运维一套cpu的集群其实是不划算的，同时的阿里云以及各个云厂商能够提供一些非常弹性的cpu的资源，这个其实就比较合适。
第五就是在做搜索还有一些训练的场景当中，肯定都是全文搜索跟向量检索多路召回的场景。
2、技术架构介绍
主要介绍一下我们现在整个基础架构方面的一些组件。最下面是我们整个的基础架构都是构建在K8S上面的，一个好处就是我们无论是在自建IDC还是在公有云上面都是统一的计算调度逻辑，不会说在云上面用的是一套逻辑，然后在自建IDC又要重新换一套技术架构，所以整个技术架构层面是非常统一的。
存储方面我们是用标准的对象存储这样的协议，因为对象存储都是兼容的SCI协议，哪家云厂商兼容的好，对于开发者还有infra的运维来说其实是更友好一些。同时还会使用juiceFS或者CpFS这样的一些文件系统，在数据处理完之后如果制造数据集要做训练的场景当中，肯定还是需要一层 协议才能把数据用起来，把模型训练出来。然后再之上就是服务层，服务层会有一些Dolphin Scheduler这样的一些调度框架，比较关键的就是Ray的集群，同时会把Spark放在Ray上。
第三部分就是数据管理这方面，我们会用一些比较开源的业界规范的数据湖的一些组件，比如说Iceberg、Lance，Catalog可能就会用Unified Catalog这样的一些数据目录的组件。然后再之上就是一些给算法、业务同学使用的Application层。会提供一些notebook、OLAP、Search这样的一些应用。
3、存储引擎和计算引擎
（1）存储引擎-Lindorm+Iceberg+OSS
存储的主要使用的场景其实比较简单，主要用的组件其实就有三种。一种是Lindorm去做搜索，一种是Iceberg管理整个的数据湖，最底层的就是对象存储（OSS）或者是兼容SCI协议的对象存储都可以。整个的基础架构首先跟开源式生态是非常兼容的，其次就是运营起来的成本非常低。因为OSS是完全托管在阿里云上的，如果是在自建的IDC上面，我们可以找一些对象存储的厂商，这样对整个使用来说接口都是统一的。另外Iceberg是统一管理数据湖，把我们的文本、音频、视频还有图片统一都放在对象存储上面，然后再通过中间的一层kafka写入到我们的数据湖里面。对于用户来说，他在使用的时候其实只要访问数据湖里的数据就可以，它无论是通过Spark还是Ray，都是可以直接拿到数据湖里的数据，然后自己再做各种各样的加工，这个就比较方便灵活。在Iceberg之外，我们会把数据按需导入到Lindorm或者是Doris里面去做一些搜索和交互式的分析。
（2）计算引擎-Ray+Spark
计算引擎是重点建设的一个部分，因为在AI场景里边如果只用Spark或者是map reduce的话，其实是不太灵活的。Spark如果写Rdd、Dataframe等都是要用cpu或者处理表格的数据会比较合适，如果一旦涉及到文本或者图片的数据的话，其实是没有办法的。同时还有另外一个比较大的问题就是在AI场景里很多计算的逻辑都要用到一些模型或者gpu，整个的生态都是建立在python上面。用过Spark+hadoop就多少都会有一些痛点，要把hadoop打造成一个很大的zip包，然后传到某一个地方，启动的时候还要加上一堆参数，还要指定python环境，最后才能把整个的逻辑写下来。启动的过程当中，需要把hadoop包下载下来，还要driver跟excutor来回传一遍，启动时间基本上是要在三分钟以上，而且hadoop包可能在4、5g这个量级。Ray在设计之初天然就是为AI场景去设计的，所以Python是它的first class语言，在用Ray的过程当中，只要指定runtime的env就可以在上面指定自己Python的依赖。
还有环境变量等一些东西，在启动的过程当中，就会直接去派派员里面把依赖下载到本地，然后去启动。我们不需要再把hadoop包传到什么地方，只要写一个非常简单的压膜文件就可以。而且这个算法在开发的过程也会非常简单，只要进行一个 命令就可以将开发环境、生产环境一键式的提交上去。而且它这个程序还可以反复调试，只有在第1次调试的时候会去下载依赖，然后第2次调试的时候，因为虚拟环境已经准备好了，所以不需要再重新装一遍，就会很快看到一个结果，这对算法同学去做开发任务、做实验非常友好。它可以在一天之内反复迭代，而不用去准备各种各样的环境依赖的问题。在使用Ray的同时，spark也丢不掉，因为在数据湖，做数据分析，还有一些简单的数据处理的场景里面，spark是一个非常成熟的组件，而且大家也用的比较熟悉。要把spark和Ray结合在一起，之前英特尔开源的Raydp组件可以把spark跑在Ray上面。我们把这个代码复刻了一遍，然后做了一些修改，让他能够更好的去适配我们这样一个场景。Spark On Ray逻辑上其实是比较简单，依赖于Spark非常好的抽象，Spark在启动的时候只需要指定一个master,然后对这个master申请相应数量的executor就可以了。
这个master默认支持就是kys、yarn、standalone这几种，只要在之上再支持一个Ray的master就可以了，所以我们在启动的过程当中启动了一个Ray master这样的一个actor，然后让它负责在Ray上面去调度跟申请资源，把Spark任务启动起来。我们只改了这一层，对于spark的接口等其它的根本都没有改动，这是一个非常轻量级的改动，运维起来也比较简单。但是对于用户使用角度来说就简单很多，这是我们在计算型方面做的一些工作。
4、场景介绍
（1）基于数据湖和Lindorm的训练、搜索统一的数据链路
我们现在主推一个训练跟搜索一体化的数据链路，就是我们这个数据既用来做模型的训练又用来做搜索，因为我们整个数据的处理链路其实是大致相同的，而且对于训练跟搜索来说，他要的都不是一个非常脏乱的数据，要的都是一个清洗过后的高质量的数据。所以我们整个的链路还有整个的数据，其实让用户有希望能够统一的管理。整个链路其实就是先把数据源通过kafka各种的技术存到Iceberg统一管理在数据湖里。这个里边的数据其实是很多的，可能是在PB级别的数据，真正有用的数据，可能只有其中的10%或者5%，那这里边就需要做一个清洗的去重。去重完之后的结果就会走到不同的路径里面，比如说训练，就要走chunking、tokenizer到训练，搜索我们就需要把它导入到Lindorm的宽表里面，然后再用Lindorm的搜索引擎、向量引擎和AI引擎，去做各种各样的检索引，给我们的最终的用户或者算法的同学去做一个搜索。
然后使用Lindorm还有一个好处就是相对来说这个体系比较开放，对于我们一些离线使用的场景，比如说内部的封控、安全这样一些场景，其实平时也不怎么用，可能也就公司里面10来个人在用，这时候我们就可以用Lindorm内置的搜索引擎搜索一下就可以了。对于一些twoc的场景，要求要在几毫秒之内把这个结果搜出来。可以在Lindorm的宽表之外再自己做一个index server,使用一些自己的搜索引擎技术去做优化，使用Lindorm的好处就是数据既可以统一在一起，又可以相对来说比较灵活的开放给我们其他的一些业务去做定制。
（2）高性价比的Lindorm双路召回能力
首先最重要的就是成本，毕竟做一款搜索的场景，如果没有每年千万级别的预算的话，就别趟浑水，我们在千万级别的成本上面哪怕只有20%、 30%的一些优化，其实也是每年几百万的成本的节省。Lindorm在这方面可以做一个很好的权衡，比如这个数据太大了，暂时不想做embedding，只想做全文搜索，我们就可以先用Lindorm的全文搜索先把数据索引好先用起来，过一段时间之后再想把向量搜索加上，这时候也可以在Lindorm上面再把这个项目再加回来。
这时候可以按需的使用数据，其实我们内部也是这么做的，在一些比较大量的场景里面，只用了全文的倒排索引，在一些中等体量的场景里边全文索引和向量索引都用了。同时在Lindorm里面内置了AI引擎，可以把embedding推理这部分也都内置掉。我们对外使用的时候只有一个es和rest的接口，对于运维体验上来说就比较简单，如果是一些专有的向量数据库，embedding部分还得我们自己做，还要去找一些专门做embedding的一些卡,这个其实不太方便。
（3）基于Ray的高性能多模态数据处理
我们用Ray做高层的多模态的数据处理，前一段时间发布了一个视频智能的大模型，生成的质量还可以,跟其它产品对比各有千秋。这只是我们初代的一个训练模型，这个文件还在持续的迭代当中。我们这里边的数据可以跟大家分享一下，我们现在只用了200张卡去做这种数据处理，每天可以产出1291个小时，用Ray优化之后可以处理3000多小时，视频的处理其实也是保留一部分，大概只有保留8%，也就是说我们其实产出了3000小时，但其实处理的数据在上万个小时。另外我们在调度策略方面去做一个优化，监控的截图可以看到我们这个任务在启动的一开始，所有的gpu的抵扣使用率是百分之百。
在做数据处理或者使用gpu的场景里边，最重要的就是gpu的使用率，因为gpu其实是很昂贵的一个资源，人可以闲着，但是gpu不能闲着。最重要的怎么让这个数据的产出能够达到效率最高，就是要让gpu的使用率达到100%或者接近100%的一个水平。经过一系列的优化之后，能够让数据处理任务，gpu的使用率是100%。后期为什么有一些波动？也是因为有一些长尾的数据要去做处理，如果这个数据量足够长的话，那它的线应该一直是一条直线。
（4）技术探索
首先我们现在使用Iceberg去做数据湖是一个权宜之计，因为Iceberg现在是数据湖这个方向的一个业界标准，未来会探索一个叫做lance的数据湖，它对于多模态以及非结构化数据更友好，而且是对于训练更友好的一个数据格式。能够帮助我们解决数据存储上的一个非常大的痛点。另外就是我们会基于这种Lindorm的多模态的一些检索能力，来扩展非结构化数据的搜索的一些功能，因为现在全文索引虽然好、便宜，但是它只能做文本场景的搜索。
但是如果一旦涉及到图片、视频、音频这样的搜索一定会涉及到向量检索的一个使用。然后会探索一些serverless的方案去降低离线搜索的成本，还有一些数据流失的改造，包括把flink跑在Ray上等等这样的一些建设。
