作者 | 姚奕玮

导读

在 AIGC 的时代背景下，向量数据库井喷式发展。不少人理解向量数据库就是在传统数据库之上新增一个向量索引，然而随着大模型应用逐渐拓展到核心业务领域，通过复杂代码工程来拼接大模型、向量索引和结构化数据分析结果会阻碍规模化复制。同时并发查询性能、数据一致性、高可靠和弹性伸缩等特性会变得越发重要。

阿里云瑶池旗下的云原生数据仓库AnalyticDB锚点未来 5 年企业数据架构智能化升级需求，全自研了企业级向量数据库，它也是国内云厂商中唯一被 ChatGPT 和 LangChain 推荐的向量引擎。本文带大家一起了解阿里云 AnalyticDB 技术负责人姚奕玮在 QCon 全球软件开发大会（北京站）2023 上的精彩演讲，解密 AnalyticDB 全自研企业级向量数据库核心技术，以及新一代向量数据库在云原生存算分离和 AI 原生上的技术演进路线。

完整PPT下载：https://qcon.infoq.cn/202309/beijing/presentation/5454

企业为什么需要向量数据库？

在AIGC时代，企业需要向量数据库扮演什么样的角色？首先看下向量数据库和 LLM 的分层，最底下是通用大语言模型层，它能回答一些通用问题。比如你问它零售的定义是什么，它能够很清晰的告诉你答案。

再往上面一层是行业模型，它是模型提供商为行业专门定制的行业大语言模型，比如可以为金融、安全、零售等行业去定制大语言模型，它会把一些特定的行业知识语料喂给这个模型来加强训练。举个例子，行业模型能回答这样的问题：零售行业的具体业务流程是什么，它能够回答得非常精确，这个是普通的大语言模型没法回答的。在行业模型上面，就进到了企业私有模型领域，企业私有模型也分为两层。第一层是企业专属模型，它是企业通过在行业模型基础之上，用自己专有的内部知识去fine-tune的结果。它能回答的问题是，公司主售的是一些什么样的产品。但是 fine-tune 有一个问题，就是 fine-tune 的代价其实非常高，并且每一次 fine-tune 的时间比较久，企业无法经常去做这个事情，因为它的 cost 非常高。

在大数据规模爆炸的时代背景下，企业数据知识源源不断地流入，所以这种场景下我们就需要第四层，也就是企业的专属知识库，这个专属知识库通常是由向量数据库来实现的，通过向量数据库，它能回答的问题是，比如我们公司最近三天被搜索得最多的产品是什么？我们公司最近卖得最火的产品是什么？它有实时性的特性。很多时候你也可以用向量数据库这一层去修正大语言模型的幻觉问题。

这里我举一个具体的例子，在向量数据库增强的场景下，我们怎么利用向量数据库+大语言模型去做智能问答服务。

大家首先看下面这一部分，下面这一部分讲的是整个数据的导入流程，包括说我们有文档，然后文档进行了切片，切片好以后调用 embeddings 算法去产生 embeddings，然后把原始内容加上它 embeddings 后的向量一起存入向量数据库。

当我们进行搜索的时候，因为有可能是个多轮对话的过程，所以我会把过往的聊天的记录加上新的问题，一起扔给 LLM，然后 LLM 会给出 summarize 后的一个独立的长问题，接着我再拿这个长问题去做 embedding，之后到向量数据库里面去搜索，这样我们就会实时搜索出跟这个问题最相关的知识块，然后我再把这个知识块结合独立问题 （知识块通常是通过 prompt 的形式结合独立的问题）投递给 LLM，这时 LLM 就能够给出解答，这个解答其实是包括向量数据库里面存储的实时知识的。

bedding，之后到向量数据库里面去搜索，这样我们就会实时搜索出跟这个问题最相关的知识块，然后我再把这个知识块结合独立问题 （知识块通常是通过 prompt 的形式结合独立的问题）投递给 LLM，这时 LLM 就能够给出解答，这个解答其实是包括向量数据库里面存储的实时知识的。

阿里云AnalyticDB向量引擎核心技术解密

接下来我们来看一下如果去实现一个向量数据库。首先介绍一些基础知识，向量数据库到底要做什么事情？其实本质上就是给定一条向量，我们要搜索离它最近的 k 条向量，那最近的这个距离的定义可以是，比如说，内积或者欧氏距离、或者余弦距离。有了距离的定义以后，我们还要定义一些向量的搜索算法。

向量搜索算法总体来说分为两类，第一类是精准搜索，比如说像 FLAT，一个向量一个向量地去检索，然后取 top k，召回率会很高，但是它的执行的性能会比较差，因为要做全局扫描。大家熟悉的 KD tree 也是这个范畴，就是你能找到最精准的 top k，属于 KNN 算法。

第二类是 approximate nearest neighbor，就是 ANN，那这类算法它可能回答的并不是最精准的 top k 的向量，但是这一类算法的好处是执行效率比较高。

比如说像 IVF，本质上它把所有的向量扔入到一个向量空间里去，这个向量空间你可以用 k means 算法去找出一些中心的点，然后把所有的向量都归于离它最近的中心点，最后当做搜索的时候，你只要找到这个中心点，在中心点的这个小空间里面去搜索 top k 就可以了。当然有可能出现的一些情况是，离你最近的这些点，它并不在同一个所属 k means 的这个中心空间里，这时候你可能要扩展一下，去额外找一些相邻的空间，但大体思路上是这样的。

除了 IVF 之外，ANN 中还有一类是基于树的算法，比如 ANNOY 算法，这是 Spotify 提出的一个算法，本质上和 IVF 比较类似，就是把空间不断地切分，然后不断地二分，直到二分到最后一层的树的叶子节点上，它只有少于 k 个向量，这时候构建过程就停止了。基于树的算法也有和 IVF 有同样的问题，当你搜索的时候，有可能最后找到叶子节点里并不包含你所需要的所有的 top k 节点，这时候你也可以采用比如像加入优先级队列，辅助构建一些森林的方式，多构建一些树，来达到更好的召回率。

ANN 中的最后一类是图的算法，它其实就是大家都比较熟悉的 NSW 的算法以及 HNSW 的算法。HNSW 其实就是在 NSW 上做多个 NSW 的叠加。接下来我会详细地介绍 HNSW，因为通过实测， 无论是高维向量的执行效率，还是召回率，HNSW都是比较优秀的。所以我们选择 HNSW 作为 AnalyticDB 默认的向量检索算法。

2.1 HNSW 向量检索算法

首先介绍 NSW 的搜索和插入算法的实现，这里我写了一段伪代码，它其实非常简单，就是随机选一个节点，随后把它扔入一个优先级队列里，用来 bootstrap。

接着你不断地从这个优先级队列里面去拿节点。如果它离你要搜索的节点距离已经大于所有你已知答案的距离，这时候就做贪心裁剪，不继续搜索下去了。否则，会把它的所有邻居都标记成已经访问过，并且也加入到 candidate 的优先级队列里面去，并且把它们也都加到结果集里面去。当完成这个步骤时，要么我是把所有的节点都访问过或者裁剪掉了，要么是达到了规定访问节点的个数上限，那这时算法就返回，这样我就得到了离这个节点最近的近似的 k 个节点。插入的流程也非常简单，插入时运行一遍找离它最近的 k 个节点的算法，然后跟它们都建立连接就可以了。

HNSW 本质上是在 NSW 上做一个阶层的叠加，它本质上就是一个类似于 skip list 的数据结构，它能通过上面的那些层去加速进到离查询节点最近的那个点的步骤。那具体它是怎么做的？搜索的时候其实非常简单，在搜索的时候我只需要从最顶上开始搜索，然后每一个都搜索离它最近的节点，直到倒数第二层。然后到了倒数第二层之后，就通过那个节点作为最后一层的起始节点，然后在最后一层的这个节点开始去进行 NSW 的查询，具体就是用到前面一页 PPT 讲的搜索方法。

那插入的时候它是怎么做的呢？插入的时候还有些不一样，因为像 skip list 这种数据结构，插入的时候必须要保证把节点在最底下的 lc 层都插入。这种情况相当于先掷一个硬币，由这个硬币的结果来决定要插入到最高的是哪一层。具体插入的时候，对于上面从最顶层到要插入的这一层的上面一层，算法仍然是一样的，就是找到离它最近的节点，然后从要插入这一层到最底层开始，对于每一层我都会去找离它最近的 top n 个，这跟前面 NSW 算法不同的是，我们多加了名为 SelectNeighbors 的函数。

这个函数的作用是做一些 heuristic ，也就是启发式搜索。那引入它是为了避免什么问题呢？它是为了避免形成两个 cluster 孤岛（如图所示）。我们希望 HNSW 的图里面这两个 cluster 是连接起来的。那它采用的算法是什么呢？假如有某一个候选节点，我计算离这个节点到目标节点的距离，那它已经比到之前的某一个添加的节点的距离是更远的话，那我就跳过暂时跳过这个节点，因为这个节点也可以通过那个节点来相连。所以如果你用常规算法，这里面的所有节点都会被加到 candidate 里面去，但是如果你用刚才我说的那个算法，会跳过一些节点，那这样这个比较远的另一个 cluster 的节点就有机会被加进去，因为对于它来说，它离这个绿色节点的距离比它离其他已经加进去的这些节点距离都要近，所以这个节点会被加入，部分概率上解决了孤岛问题。

2.2 向量存储设计

有了刚才介绍的算法之后，我们还需要有一个数据结构以及存储方式，去实现向量数据库。AnalyticDB for PostgreSQL 是基于 PostgreSQL 来改造的，它原生支持 PostgreSQL 的索引接口， PostgreSQL 提供了一个可插拔的索引结构，在这种情况下，我们采取了段页式的存储方式，我们把刚才的这个 HNSW 的点和边都分开来进行存储，点它自己有自己的 page，边也有自己的 page，每一个边的 page 是包含了这个点在所有层的以这个点为初始节点的这些边，这样的话方便对所有边进行查询。那之所以把点和边分开来存储，有以下几个好处：

第一，能很大程度地节省 IO。这是为什么？因为在搜索的时候我有可能搜到这个点，但是我计算距离以后，发现这个点不符合过滤条件，我把它裁剪掉了。那如果采用的是点和边合起来存储的话，相当于是把整个节点的边也顺带都读出来了，那这其实是没有意义的，所以说这种做法减少了 IO。

第二，点和边分开存储，因为点的数据量会比边少很多，这种情况下基本上所有的点的 page 都可以 cache 在内存里面，减少打开 page 的数目。

第三，为了处理并发场景，我们对所有的点和边的访问，都是要加锁的，以 page 为粒度进行加锁，那点和边分开来存储的时候可以减少冲突，增加整个系统的并发量和吞吐。

2.3 高维查询性能优化

有了这个磁盘上的数据结构，再加上刚才描述的算法，我们其实已经有了一个可以跑起来的向量数据库。但我们在线上运行的时候，发现它有一个问题，它的执行效率并不是很高，尤其是碰到了现在 AIGC 场景，因为 AIGC 场景下面都是非常高维度的向量，比如说 1536 维的向量，那这种情况下它执行就比较耗费时间。所以我们做了一个优化，相当于把每一个向量都进行了降维，进行了编码，称之为 PQ 编码。

那具体 PQ 是什么意思？它其实理念上非常简单，就是你有一个向量，你把它切成 m 块，然后对于每一块你对所有的向量都去做 k means，做完之后你去用它归属的离它最近的 k means 节点来替代这个向量的这一部分，然后你对向量的每一部分都做这个操作，这样其实相当于把整个向量的维度和精度给减少了。在这种场景下做计算时，耗费的 CPU 少了，整体速度会快很多。并且因为存储的向量长度也会减少，所以总存储 size 也会减少。但这里其实有一个是鸡和蛋的问题，业界 PQ 码本的训练，其实是用离线的数据去训练好之后，才能够去做编码。

但是AnalyticDB作为实时数仓，它的数据都是实时导入的，有可能用户数据进来的时候，里面一条数据都没有，所以我们怎么去解决这个先有鸡还是先有蛋的问题？我们采取了增量方式，也就是当你没有任何数据的时候，我们用的是原始向量来进行计算。当达到一个阈值，比如说当有 10 万条数据时，那我在后台会起一个进程，去对这个 10 万条数据去进行码本的计算。当算完这个码本之后，会逐渐地去回填已经写进来的向量的数据，与此同时，新写进来的向量数据也可以用新训练的码本来进行编码。我刚刚描述的这个过程，其实是一个迭代式的过程，也就是说你有 10 万条的时候，你可以做这个操作，然后你有 30 万条的时候，当你数据的分布变的时候，你可以再进行一次这样的操作，来提升精度，比如说 100 万条的时候，当你数据分布已经比较稳定的时候，你还可以再做一次这样的操作。这样的好处是精度在不断提升，并且在训练过程当中，用户对查询和写入都是无感的。在进行上述优化之后，AnalyticDB实现了 QPS 提升 5 倍的效果，并且存储大小压缩到原来的 1/3。

2.4 CRUD 事务处理

这里再介绍一下删除的实现。大家都知道，市面上很多向量数据库是不支持删除的，但是AnalyticDB向量数据库支持删除，主要原因之一是AnalyticDB是实时数据库，所以用户可以随意地去对数据进行删除。

为了减少用户感知的删除延迟，在删除的时候，第一步我们仅仅是去标记删除这个图上的节点，标记删除完之后，用户的删除操作就返回了。因为用户越删数据他标记删除的点会越积越多，我们不可能永远带着这些点的图去做搜寻。所以定期的当标记删除的点达到一定数目的时候，我们也会起一个后台的进程去做清理的操作。

那第二、三、四步的操作它要做的是什么？它要做的是首先它会遍历这个图，然后找到所有指向被删除节点的这些边，然后删除这些边，删除这些边以后，就可以正常地去删除这个节点了。但删除完这个节点以后，大家可以看到这个图是有一定的问题的。因为在建 HNSW 索引的时候，我们其实是尽量保证这个图是具备连通性的，但是当你删除完之后，这个图可能就变成两个孤岛这样的样子，那它会对我们的召回率造成影响。这种情况下面我们会进行第四步，它其实是一个补边的过程，我们会用一定的算法，如果探测到这个点的入度边或出度边并不是很充足的情况下，会进行一个补边的操作，让它和其他的这个被删节点的周围的边去连接起来，去修复整个图的这个连通性。

2.5 并发查询吞吐优化

此外，我们做了非常多优化，今天主要分享其中一个：减少锁的冲突。我们在做 HNSW 算法的时候，为了保证并发的正确性，是会对 page 加锁的。如果直接去实现，可能你对 page1 进行一个加锁操作，加完锁之后要去找它的相邻边，接着会对 page10 和 page11 也去加锁，并且只有计算完毕后才会对 page1 解锁，这里虽然我只画了两个点，但其实这个 page 里面可能有很多的点需要计算。另外，可能这里要访问的 page 也非常多，这样的加锁方式会导致整个系统的吞吐下降，因为其他的查询并发可能要等锁。

为了缓解这个问题，我们做的操作也非常简单，对 page1 加锁后，把要计算的 tuple 拷贝出来，然后再解锁，带着无锁的 tuple 去计算向量距离。对于写写冲突，我们会做 optimistic 检测来保证写写冲突不会造成写丢失。

2.6 数据分区并行处理

再来介绍下分区并发执行。大家都知道，数据库是可以分为分区的，比如有时间的分区，这种情况下，对于每个分区都有一个 HNSW 的索引，每一个索引都会去取这个 top k 乘以一个放大系数。之所以有这个放大系数 （即使不是分区表，我们也会有放大系数），是因为刚才做了这个 PQ 编码以后，其实会降低它的召回率，所以我要乘以一个放大系数去补充损失的精度。本质上每个分区都是线程的并发去执行，然后执行完之后会首先每个分区都取 top k 乘以这个放大系数。第二步会做归并排序，这里所有的归并排序用的是真实的向量距离，所以是一个精排的过程。通过这步我们加速了分区表的 ANN 向量检索的效率。

2.7 分布式架构实现

刚刚讲的都是在单机上怎么去实现一个向量引擎，以及在单机上怎么去做优化。AnalyticDB 是分布式系统，所以它天然地把分布式能力带入了整个向量数据库里，AnalyticDB 是 MPP 的架构，数据是通过哈希分片的，通过对我们的分布键去做哈希，会决定每条数据是进到了哪个节点上面。

所以这里的并发力粒度有两个，第一个是节点级别的并发粒度，第二个是在节点内的分区级的并发粒度，所以是节点乘以分区的并发。并且我们为了保证高可靠和高可用的场景，可以认为每个节点上面的 shard 我们都是有主备的，主和被之间是通过 write ahead log 去做同步，所以数据其实是存了两份，保证了高可靠。当主挂掉宕机的时候，我们会有检测系统自动地把它切到备，整个过程在十秒内完成，所以通过这个架构做到了高可用。最后，除了刚才说的那些距离计算的方法之外，我们也支持集成算法厂商自研的这些距离算法，这些算法通过距离的插件也能够集成到我们的向量数据库里面。

2.8 多模数据融合分析

下面我详细地介绍一下融合查询，融合查询要解决的是什么问题呢？我们的理念一直是一套数据系统里面，同时去解决结构化和非结构化数据的查询，一条 SQL 其实可以同时查向量、并且同时做结构化数据的 filter 等。融合查询要解决的问题就是用尽量高效的执行方式去完成这个 SQL 的执行。

第一，我们通过 CBO 去决定选择下面四条路径的哪一条。

第二，HNSW 的 scan 的算子，它具备能够把 filter 或者说 bitmap 给下推到它上面去执行的这个能力。那具体是什么意思？假如说我有一个查询条件，是查向量的 top k，并且说我有另外一个结构化的 field，比如说满足过滤条件大于 3 或者小于 5 这种，那我会通过我的优化器首先去决定这个结构化数据的筛选率是不是很高。如果它筛选率非常低，也就是说只会筛出几条结构化的数据，那执行方式非常简单，就先把这些数据全都取出来，然后对于取出来的这些数据，再进行向量的暴力扫描，这种方式是最高效的。如果说优化器告诉我它的筛选率并没有那么低，那我会首先执行一个 bitmap 的 index scan，去先过滤这个结构化的这些数据，然后我再把这个 bitmap 给推到我的向量索引里面去执行。

第三，如果说我的筛选率再高一点的话，可能我的 bitmap 都非常大了，那这个时候把整个计算的表达式去推给这个 HNSW scan 算子。

第四个场景，是整个 filter 基本上没有起到什么过滤的效果，那这种情况下肯定是先计算 HNSW，然后再 filter，因为这个 filter 它也 filter 不了多少条数据。那大家有可能会问，为什么我不直接就是一直去执行第四个流程呢？这个缺点就是说我有可能 HNSW 算了 top k 条，但是这 top k 条的数据它都是不符合那个 filter 的条件的，那就导致最后会出很少条的数据，不符合用户的查询需求。

AIGC应用落地实践

3.1 构建高并发的以图搜图系统

下面和大家分享一些具体的线上案例。

第一个案例是纯向量检索的以图搜图的过程。为了脱敏，我用的是我家狗 （它叫史努比）的照片，但其实大家可以想象，假如是想要查车牌、查人脸的话，也是相同的效果。那这里的场景是什么？假设我有很多 IoT 设备，它一直在拍照，并且一直会把照片实时地传到向量数据库里。如果有一天我的狗丢失了，我想知道它在什么地方。我会把“史努比”的照片放进向量数据库去搜索，这些相似照片会在整个向量数据库里以毫秒级的速度快速被找到。

所以我想表达的是，第一，我们的向量数据库具备支持万级 QPS 实时写入的能力。第二，每个查询都能以毫秒的延迟返回结果。

3.2 端到端的一站式 AI 服务

在 AIGC 场景下面，尤其是过去半年，我们发现用户需要的不仅仅是向量数据库的能力，还需要额外两个能力。

这额外的两个能力是什么？第一个是我刚才已经讲的，要有能够理解文档的能力。比如有一个文档，它有一级标题、二级标题、三级标题，然后再是正文。如果在切分文档的时候随意切的话，可能正文切到的一段是属于一级标题的，由于切分方式导致丢失了一级标题的信息，那做检索的时候它的效果可能并不会很好。通过文档理解的这个能力，我们能够把这个一级标题再重新 attach 到这个切好的文本上面，能够增加它在语义上面的表达力。

除此之外，客户也需要很好的切分算法，尤其是对于中文能够有很好的切分算法。并且能够有生成 embeddings 的能力，那我们都把这些能力包含到我们这个向量数据库的部署的 HTTP 服务里面去。第二部分是我们目前正在做的和大语言模型结合的能力，我们希望能够在向量数据库里面去 fine-tune 模型，并且能够去做基于模型的 inference。

总而言之，我们的理念是在一套数据系统里面把用户的结构化数据，像 structured data，还有像 JSON 文本以及像向量数据都存储在一套数据系统里面，去解决用户所有的数据分析类场景的问题。

3.3 和通义千问的落地实践

这里是我们和通义千问协作的具体示例，在这套融合系统里，用户可以在通义千问里面做自己模型的 fine-tune，用户可以把实时数据写入到 AnalyticDB 里，然后通过刚才的流程去做 LLM 加上 AnalyticDB 里的知识召回和智能问答。

我们同时支持两种部署模式：一种是如果客户对数据的安全性、敏感性非常 serious 的话，采用单租户的模式；还有一种是并没有那么敏感，我们也支持多租户的部署模式。通过我们数据库的 user 加 schema 的权限隔离，以及通过 resource group 在资源上面做的 CPU、 memory、 IO 的隔离来保证系统的隔离性，所以它是一个类似于 SAAS 的部署方式。

新一代向量数据库演进趋势

4.1 云原生存算分离架构

最后来分享我们目前在做的工作。第一个是向量的存算分离，大家刚才听我的描述其实很容易能够理解，我们是用本地存储来存向量的，对于 HNSW 索引我们需要高频的去做 update 和 delete 操作，这对云原生的 append only 或者 write once never modify 的这种类型的 DFS 是非常不友好的。

在开始的时候，我们采取是下图方案一的实现方式。因为我们的整个数据写入流程是数据会先写入行存的这个 Delta 表，然后当行存的 Delta 表积累到一定程度的时候，我们会把它下刷到 DFS 上面去，以列存的形式存储，这样能够加速扫描。所以每次下刷成一个 fragment，这个时候因为这个 fragment 是 immutable 的，与此同时我们会构建一个小的 HNSW 索引。然后当我查询的时候其实就是把这些索引分别做查询，然后 merge 起来。如果有 delete 操作，我们也是先存在内存里面，当你 delete 的个数达到一定量的时候，才跟下面的这些 fragment 去做一个 compaction，然后重写这个 fragment。我们发现方案一的问题是永远没有办法达到一个 sweet point：比如说如果你要召回率高的话，可能每个 HNSW 的召回你都要调得非常高。但是注意这里跟我刚才描述的存算一体的架构不符，在存算一体的架构下我们是一个 shard 一个 HNSW，但这里是一个 fragment 一个 HNSW，所以做了向量检索以后还要合并，那这些非常小的结果合并起来它其实开销是非常高的。但是如果你把这个取 top k 的操作，把这个 k 给调小的话，又会发现这个召回率达不到效果，所以最后我们摒弃了这个方案，采取了方案二。

方案二的理念非常简单，就是大家不要被局限于存算分离只能是纯 immutable 的共享存储。这里我们自己建了一个多租户的存储池，这个存储池它会存储 HNSW 点和边的这些 page，并且是多个实例去共享的，所以说它的资源规划是我们在 region 级别做的，并且它并不会发生很多次的扩缩容。当有写入的时候，先写入 log keeper 的这个 service 里面，然后 log keeper 会把这些 log 给传给 page server，读取时 page server 会基于原来的 page，再去按需地 apply 这个 log，形成新的 page。计算节点的本地是不存任何数据的。这种做法的好处是，性能和之前调的召回率有保证；对于原有代码的入侵性和修改也比较少。

4.2 AI 原生的向量数据库

最后讲一下我们的向量数据库是怎么去和灵积模型去做结合的。

本质上用户要去精调一个模型，那这个数据必然是一个清洗完毕后质量非常高的数据，我们希望这些数据的清洗是在 AnalyticDB 里完成的，与此同时，我们还可以去 AnalyticDB 里去做模型训练。所以当你写了这条 SQL 语句后，我会先执行这个 SQL，把 ETL 清洗完的数据写入到 OSS 里面去。然后在具体执行模型训练的时候，我们会去调用灵积服务，让它把这个数据拖进来，随后进行基于某个具体的模型进行微调。比如这里我选的 base model 是通义千问 v1。微调之后我们可以去触发整个模型的上线和部署，所以我们把模型的微调和上线部署也结合到这个 SQL 语句里面来。同时，我们也可以通过 AnalyticDB 来做 inference，用户可以自己写一个 UDF，然后去调用之前训练并部署完的模型，基于这个模型做 inference。

可以看一个具体例子，比如有一个售后问答服务，通过人工回答的高质量售后问答的数据，先去做模型的 fine-tune， fine-tune 完后，如果后面有新的问题，我只需要通过调用这个模型就能够自动去给未回答的问题写回复，提升了用户的使用体验。

我的分享就到这里，谢谢大家！

作者简介

姚奕玮，阿里云云原生数据仓库 AnalyticDB for PostgreSQL 负责人，阿里巴巴资深技术专家，致力于构建超大规模 Serverless 云原生数仓。

2011 年毕业于斯坦福大学计算机系，获得硕士学位。之后分别在 Amazon 和 Google 工作。在 Google 期间担任主任工程师，成功开发并部署处理数百 PB 级别数据量的系统以及线上大规模使用的千万级 QPS 的存储系统，用于服务 Gmail、Google Drive、Google Calendar 等应用。2020 年加入阿里巴巴后，致力于攻克离在线一体、湖仓一体、Serverless 等技术难关，实现实时在线数据服务的秒级弹性、冷热混存、极致的压缩和高性价比的自研数据格式、智能优化器、混合负载及多租户的场景下的资源隔离、AIGC 场景下的自研向量能力等。