2023 年可以说是大模型元年，借着大模型的东风，向量数据库也迎来了大爆发，被带到了更高的关注度上。
一方面，向量数据库和 RAG 得到广泛的关注和认可，是因为他们的确可以解决一些短期内大模型无法攻克的难题，比如模型幻觉问题等。同时，在尝试用向量数据库和 RAG 做场景落地的时候，效果也还不错。
不过另一方面，我们也无法回避对他们普遍的困惑与争议，比如向量数据库是否已经凉了，以及如今势头正盛的 RAG 是否会被长文本杀死等等。
那此刻距离 ChatGPT 的发布已经有一年多的时间，站在当下的这个时间点上来看，向量数据库和 RAG 究竟发展到了什么阶段，他们的现状如何，未来又将走向哪里呢？行业专家是如何看待向量数据库和 RAG 所面对的争议和质疑呢？从业者又将以何种技术视野来进行工作安排和职业规划呢？所以有了我们这次的对谈。
本次对谈的嘉宾是：
苏鹏：向量检索实验室的主理人，Datawhale 上海负责人 汤林鹏：MyScale AI 数据库的联合创始人兼 CTO
两位对谈嘉宾都曾经是机器之心 AI 技术论坛「大模型时代的向量数据库」的特邀嘉宾，也再次感谢机器之心策划了这么一场直播。
同时，汤林鹏老师的团队近期开源了 SQL 向量数据库 MyScaleDB，它究竟是什么、解决了哪些问题、为什么聚焦在 SQL 方向，未来又将如何发展呢？让我们也在这次对谈中一探究竟。
本篇文章在直播内容的基础上进行了系统化的整理和补充，也补充了直播中几乎所有用户的提问，希望能给大家带来些启发与收获。
一、前置知识为了方便大家能顺利进入两位老师的对话，这里插入一段前置知识：
1. 向量数据库
向量数据库最核心的，其实是非结构化数据搜索的问题。什么是非结构化数据呢？比如像文本、图片和视频等形式的数据集都叫做非结构化数据。那非结构化数据如何实现搜索呢？我们拿以图搜图来说。
把一张图片丢进一个模型里，它就会生成一堆数字，那这堆数字本身就是向量。多张图片经过相同的模型，都会生成相对应的一堆向量。向量本身是数字，所以就天然支持这种算数的运算。
来看个具体的例子。有一个查询的图片进来，我们可以通过模型将它转化为一堆数字。然后直接拿这堆转出来的数字和数据库中原有的数字挨个相减，哪个结果最接近于 0，那我们就认为他们是最相似的。
反推回来，我们就知道了哪两张图片是最相似的，这就实现了一个简单的以图搜图的功能。对应到上面的示意图中，我们输入进去的查询图片（query），经过向量化后，和数据库中第三张图片的向量相减，最终结果更接近于 0，所以我们可以认定这两张图片是最相似的。
向量数据库需要解决什么问题呢？假使你有 100 亿个向量数据，那系统架构应该怎样设计？如何实现快速检索？数据如何分片？它的索引又该如何建立呢…… 诸如这些工程挑战，其实都是向量数据库本身要解决的一些问题。
向量数据库对比：https://superlinked.com/vector-db-comparison
2. RAG
Retrieval Augmented Generation（即 RAG）的提出最早可追溯到 2020 年发表的一篇论文，论文题目为《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》，中文翻译成检索增强生成。
论文链接：https://arxiv.org/abs/2005.11401
那向量检索就是其中的一种，除了向量检索外，还有比如关键词检索、基于图的检索（知识图谱的检索）等等其实都是检索的方法。
图片来源：https://www.rungalileo.io/blog/announcing-rag-and-agent-analytics
典型的 RAG 系统具有三个关键过程：检索、增强和生成。检索对输出质量、延迟和成本的影响最大。
RAG 的出现重点解决了现有大模型的三个挑战：
幻觉问题：生成内容不正确，与事实不符，甚至荒谬 实时问题：无法给出时效性较强问题的答案，或者给出错误答案 私域数据问题：企业私域数据因为合规等问题无法在公网作为大模型的训练数据，所以大模型无法回答针对企业的专有问题
不过 RAG 解决上述问题的时候，也同样带来了如下挑战：
引入其他组件，系统复杂性较高 有较多工程性问题亟待解决 知识库需要不断更新维护 依赖 Embedding 质量以及检索效果
我们上面说的向量数据库，其实就是 RAG 的一种关键架构元素。所以大家现在谈到向量数据库，就一定会想到 RAG。我们这次的对谈也是两者融合来讨论。
大模型出现之后，大家都是基于文本来交互，那语言、文本这种非结构化数据，它最适合的就是向量检索，所以现在向量检索、向量数据库和 RAG 结合得这么深，或者当大家聊到 RAG 时，就会说我需要个向量数据库，需要个大模型才能做。
二、对谈1. 向量数据库历史及发展现状
图源：https://myscale.com/blog/what-is-sql-vector-databases/
苏鹏：向量数据库包括向量检索的技术，其实它的历史很长，并不是在大模型之后诞生的。那为什么在大模型诞生之后，向量数据库才迎来了如此多的关注呢？它的发展现状又如何呢？
汤林鹏：我先简单介绍一下向量数据库的历史和演变过程。大模型出来之前，其实向量数据库在很多垂直场景上已经有应用了，比如以图搜图、语义检索、互联网上的常用的推荐、工业场景中的异常检测等等，核心都是将非结构化数据映射到向量空间中，完成向量检索后，来实现上面的各种功能。
当然在大模型出来之前，这些技术可能还只是应用在一些局部的领域，不过也已经非常重要了。我们在开发 MyScale AI 数据库之前，也在一些垂类的生物识别场景中构建过千亿级别的向量系统，当时就已经开始了相关技术的积累。后来大家就把这种垂类系统也逐渐地做成了相对通用化的系统。比如：
Pinecone：硅谷知名的闭源向量数据库 SaaS 产品 Milvus：开源的向量数据库产品 当然还有其他像 Qdrant、Weaviate 等等
这些产品基本上都是为向量检索而设计的，基于向量检索库做一些封装、分布式的系统设计等等。不过他们也有一些缺点，比如在较为通用的数据管理和查询方面没有得到足够多的锤炼，导致很多功能上是有一些缺失的。
从大模型普及之后，向量的重要性一下得到了认可，于是又出现了很多集成向量数据库，比如原来文本做的最好的 Elasticsearch，以及后来改了协议的 OpenSearch 也都加上了向量的功能。
PostgreSQL 是一个开源的事务型数据库，也是用得最广的事务型数据库，因为它的插件系统设计得比较好，也被加上了向量的功能。但这些系统我们其实做过非常多评测，我个人认为，它的架构本身的一些局限性，还有包括对向量理解优化的不够，导致了它们的性能和精度在稍微复杂一点的场景上会有些问题，比如资源占用高，复杂查询速度慢、精度低等。
苏鹏：其实如果大模型没有出现，向量检索也一定会在某个时间，比如今年或是明年，还是会被大家所关注和重视到。因为整个非结构化数据本身就是增长的趋势，大家也在逐渐意识到，处理非结构化数据大概率会是一个单独的课题，会变成一种很重要的检索方法。这一天到来的话，向量检索的发展就能得到显著加速了。
2. 长文本 vs. RAG
图源：https://www.vellum.ai/blog/rag-vs-long-context
苏鹏：向量数据库也经历了所谓的“黄金时代”，比如国外做向量数据库的 Chroma 也融到过大笔资金。但是现阶段，很多做向量数据库的厂商也在担忧，国内的模型厂商会不会下场做向量检索的产品，或是某些垂类应用。尤其最近长文本的出现，比如支持 200K 文本的 Kimi，那这种长文本会不会冲击 RAG 场景，未来 RAG 还存在吗？是不是模型本身就已经解决了类似需求呢？
汤林鹏：我觉得长文本的出现的确让某些场景的 RAG 变得没那么重要了，比如原先也可以通过一些技术把长文档用 RAG 的方法来做一些问答和总结。但是现在对于单篇文档的体量，比较先进的支持长窗口的大模型在大多数的情况下都是能支持的，所以原先这些比较小的应用场景就变得没有那么重要了。虽然长窗口比较贵，有时候也比较慢，但是应付单个文档是没有太大问题的。
不过另一方面，企业、行业或是整个社会的数据量还是非常庞大且繁杂的。比如一个中大型企业，它可能有数十万的文档或是各种异构数据，文档之间还会有不同的版本关系等等，那在这种复杂和海量的数据下，窗口再大还是没办法都放进去。这个时候就需要通过检索的方法，精准定位到相关段落，然后排除掉不相干的信息。对于这种知识的快速理解、问答等场景，RAG 还是一个必要的手段。
另一方面，我们和一些合作伙伴正在做的工作中，也看到了 RAG 和 LM 有更深入的融合，比如最近 Cohere 发布的 Command R+ 就是专门为 RAG 优化的；还有 Contextual AI ，也提出了 RAG 2.0 的技术。我认为之后 RAG 可能不仅仅是一个外挂，而是会和知识库、大模型有更加深度的融合。当然有时候也可能会以 Agent 复杂的 workflow 形式来融合，来降低成本提升效果，这些技术也都会有一个融合发展的趋势。
苏鹏：像汤总刚刚说的，我个人也认为长文本确实会杀死掉一部分场景。比如说你有一两篇文档的话，其实根本不需要 RAG 技术，你直接丢给现存的任何一个模型，它应该都能处理得很好。但这里边可能存在一个问题，当你给模型更多不相关的内容时，其实它的回答效果是存疑的，虽然你把文档都放进长文本 200K 的窗口里了。
但是当你问某一个问题，它会把不相关的东西也获取到，那它回答的效果其实也是难以保证的，所以这可能也导致了 RAG 和长文本的争议会长期存在，我们这里也保留个可能，长文本与 RAG 一起向前走的可能。
3. 向量数据库产品现状、变化及商业化思考
苏鹏：站在2024年的时间节点上，我们回头看，刚刚我们提到的数据库的厂商乃至产品，他们目前的发展有哪些进展/变化，商业化的脚步又如何呢？
汤林鹏：这里我们先不提不适合公开场合分享的内部数据。不过整体来看，我认为有些产品的增长还是非常好的，甚至有些产品已经预期今年会提前完成原定目标。但是另一方面，大家都能感受到竞争依然非常激烈，这两年 AI 是大家的关注点，所以无论是大模型还是向量数据库的赛道都很卷。
哪几个厂商能坚持在赛道上长跑并赢得最终的市场，可能还是要看对技术以及市场的把握，还有是否能抓住机会把技术、产品和市场做一个好的结合。
从 MyScale 的策略上来说，对于我们刚刚提到的长文本的发展，一些数据量比较小的场景可选择的产品的确太多了，也就显得不那么重要。所以 MyScale 还是更聚焦在数据量比较大、数据模态比较复杂、企业需要做综合管理的场景上。
MyScale 所支持的 SQL + Vector 功能，在性能、数据密度和性价比上的优化会比较有优势，所以我们还是更加倾向于中大型企业/行业的场景。当然我们也认为大模型 + 大数据的模式会是一种新时代的发展趋势，希望 MyScale 能够成为这种新范式下一个重要的数据底座。
苏鹏：从国内的视角来看，由于经济形势等原因，在大模型这块，大家大部分还是雷声大雨点小，向量数据库更是如此，大家在选型阶段更偏向于开源、易用、生态等。但是一些 SaaS 场景还是有一定需求的，尤其国内做出海的一些企业，也会更偏向于采用 SaaS 的模式。
4. 专有向量数据库 vs. 传统数据库拓展
图源：https://mp.weixin.qq.com/s/JvyKnEbdOSb1fTwhiQTO5A
苏鹏：刚刚汤总提到 MyScaleDB 是基于 ClickHouse 做的，那现在也有个问题想探讨一下，比如现在有像 Pinecone、Milvus 这种的专有向量数据库，也有像 pgvector、Oracle 和 TiDB 这种支持了向量检索的传统数据库。
那这种传统的数据库厂商，他们兼容了一部分向量检索的能力，是不是意味着未来向量检索的技术，可能会变成数据库的标准功能呢？如果是这样的话，它对于未来向量数据库的整个市场空间和商业格局有什么影响呢？
因为我们买了一个关系型数据库或是分布式数据库，它本身支持了向量检索功能，我就不太会再单独买一个专用向量数据库了。
汤林鹏：我认为这个肯定会对市场格局有很大影响的。
首先开源的向量数据库已经有很多，那现在大家普遍看到了向量数据库的重要性，做一些集成也很正常。所以技术演进到后面，当向量数据的量没有那么大，查询的需求也没有那么高的时候，用户会有很多选择，一般也会考虑原有的厂商加个集成，这样系统很简单，也能够满足基本使用要求。这部分市场，可能占比较大的市场比例，的确会被吃掉。不过另一方面，向量作为一种新的数据模态，它的重要性得到了大家的认可，而且会越来越受重视，所以向量的数据量一定是越来越大的。再者，向量本身处理起来是非常吃资源的，因为一个向量可能至少是 512 维，现在高的可能已经到了 3000 多维，从处理难度上来说，它其实是比传统的数据库，甚至大数据系统处理起来更难。所以传统的厂商加上向量的功能并不难，难的是真正把它做好，做得有竞争力。
从我们团队的角度看，我们认为这两种向量数据库会长期存在。但是从我们目前的研发结果和对工程的细节来看，我们认为列式的数据库和向量是没有本质冲突的，两者融合好是能够达到基本没有性能损失的，同时也获得了很多新的优势，包括数据统一管理查询带来的优势，节省掉一些工程开发的代价等。当然这个融合也需要做大量工作，我们只是刚刚开始。我们认为这条路是能满足很大一部分数据量大且要求复杂的场景。
苏鹏：我的个人想法，也是个粗浅的理解和预测，未来向量检索的能力很有可能是所有数据库的标配，甚至也会具备一定的 AI 能力，例如 AIOps，Text2SQL 等。所以在一些场景下用户可以直接拿传统数据库拓展向量检索来解决问题，这个“一些场景”能做到多大，还要取决于数据库拓展的方式能够处理的向量数据规模以及性能等等，现阶段看来还没有定论。
5. 向量会是未来世界统一的数据表示方式吗？
图源：https://unsplash.com/
苏鹏：您刚刚说当向量数据比较少的时候，其实用户选择是比较多的，因为数据量小基本上总能解决问题。但是当数据量逐渐变大的时候，其实我们更需要一些优化手段，或者一些专业的方法。
我最近看到一种观点，说向量的表示未来有没有可能成为世界统一的数据表示方式？那如果是这样的话，其实相当于向量规模会爆发式的增长，或者它很有想象空间，您对这种说法怎么看？
汤林鹏：这个问题我们已经思考了快 10 年了。我们之前做的生物识别，它也是用向量表征，而且是多个向量，你可以认为是一个 Tree / Graph of Vectors。现在来看的话，大模型肯定是个很好的契机，而且历史本身也是回旋上升的。
在大模型之前，其实我们接到最多的需求是图像视频类的需求，大模型兴起之后更多的需求是语言类的。现在有一些比较大型的场景，比如金融、科研等重知识类的行业，它的数据量其实非常大，所以我们的产品会有比较大的优势。现在大模型又在往跨模态的方向演化，之后可能文本、图像和视频又会做融合，比如自动驾驶现在可能也在往 Transformer 大模型的技术路径上走、具身智能有了大模型的加持，它的想象空间和落地的可能性也一下子变大了。所以总体来讲，非常感谢 OpenAI，因为是他们的坚持把 Scaling Law 走出来，我们才能看到 AI 从去年开始到今天依然有着加速爆发式增长的势头。我们对这个领域是非常看好的，也在和我们的合作伙伴以及客户，积极探索面向未来的大模型加大数据的新范式。
苏鹏：其实万物皆可 Embedding 的共识在 ChatGPT 没出现之前大家就已经达成了，确实是任何数据都可以用向量来表示，而且产生了一个很大的想象空间，例如一张图片 + <蓝色背景、红色背景> 的文字描述就可以产生两张图片，这个如果从原始数据是没办法直接操作的，如果不依靠模型，而是看作两个向量的算术运算，能够实现这样的效果是很有想象力的一件事。向量是否会是未来世界统一的数据表示方式，这个还要看技术的演进究竟达到了如何程度。
6. MyScaleDB 为什么选择从 SQL 的角度切入
图源：https://myscale.com/blog/why-sql-for-rag/
汤林鹏：MyScaleDB 是我们结合列式的 SQL 数据库 ClickHouse 来做的，更多结合了 SQL + Vector 的存储查询联合的优化，同时也在向量算法上做了很多优化。
像 ClickHouse 这种列式的数据库，它对于结构化数据、向量、JSON、空间、时序，以及各类的数据类型都有比较好的支持和优化，而且在 trillion 级别的数据上有过非常多的打磨。我们当时做选型的时候，的确也考虑过直接包 Faiss 来做个系统，这个肯定也是最快的。但是另一方面，我们还是想做一些长远来看比较有影响力的东西，所以就想要做个 AI 数据库。而 AI 数据库就不能只支持向量了，还是得把其他模态的数据都包进去。当然我们并不想重复造轮子，因为开发一个数据库需要各种场景的打磨，投入还是比较大的。
MyScale 的技术路径是在高性能的列存 SQL 数据库 ClickHouse 上做了深入改造，把 SQL 和向量的执行、存储引擎融合在一起，同时在向量算法上也结合整个执行、存储做了很多优化。
ClickHouse 自己也有向量的功能，但一直到现在还是实验性的功能。MyScale 会聚焦于 AI 的场景，把向量和 SQL 联合查询，还有相关的一些 AI 周边生态工具做好，这也是基于我们对这个行业有足够深的理解和 know-how，同时也是一个团队长期的优势。因为对一个行业没有足够的了解，是无法比客户想得更长远的。那又怎么能开发出领先的功能，又怎么能赢得市场呢？这些都需要长久的积累和思考。
我们的出发点还是想给这个世界带来些独特的创造和贡献，所以就尽量地去利用已有的 SQL 数据库。因为的确 SQL 数据库的历史也有 50 年了，中间经历了大数据、NoSQL 等等，现在反而又回到了 SQL 架构上，所以也可以说 SQL 数据库越来越有生机了。
MyScale 其实是第一个，据我所知也是世界上唯一一个支持 SQL，而且性能和综合性价比大幅超越专有数据库的产品。SQL + 向量的优势比较突出，因为它兼容了很多传统数据库、大数据处理的模式。但是 SQL 怎么和向量联合在一起，如何把结构化和非结构化的数据管理好，以及与大模型更好地结合，这当中也有很多没有解决的问题。我相信在大家的努力下，未来几年这个领域一定能往前走。
尽管挑战非常大，我们还是把代码迭代了 4-5 个版本，当中也涉及到了非常多的技术挑战，现在大家看到的是我们打磨出来的比较满意的版本了。大部分功能都已经在开源版本推出，开源版完全可以满足数据量不太大时候的需求，欢迎大家去使用。
GitHub: https://github.com/myscale/myscaledb
当然如果大家有更大需求量（比如数千万甚至更多），以及其他商业化的需求，欢迎联系我们或者使用我们 SaaS 版本（myscale.com）。
7. 兼容 SQL 会带来哪些变化？
图源：https://myscale.com/blog/why-sql-for-rag/
苏鹏：您觉得对于向量数据库来说，兼不兼容 SQL 语句，或者是接口的方式，从现在或是未来来看，您觉得会有什么差距？您当时做这种选择的背后是基于什么思考呢？
汤林鹏：全球知名的数据库专家 Andy Pavlo 教授有这么一个观点，他认为向量数据库未来可能会存在两种形式：一种是集成式的数据库，而 SQL 加向量肯定是其中非常重要的一个品类，因为 SQL 是结构化数据库查询的最主要语言，不过把两个系统融合起来优化好，还是很有挑战的。另外一种存在的形态，是像 Pinecone 这种专用向量数据库，它会有自己的空间。不过这类专用向量数据库要想长期生存的话，最好是要和 SQL 这种更加主流的数据系统来集成并做好配合，也就是做好外挂，并在易用性和性价比上有极致的优化。
苏鹏：那为什么选择在 2024 年 4 月这个节点推出呢？包括开源版本的出来。
汤林鹏：倒是没有什么特别的考虑，因为代码迭代了4-5个版本，我们才觉得可以推出了。不过很可能大家也会想，我们做得挺早，大约 2020 年前就开始设计和开发了，现在市场已经很热闹了，是不是推出得有点晚呢？很多朋友和投资人也会这么问。不过这个在我看来并不担心，因为大模型的深化落地，以及大模型和大数据的范式可能才刚刚开始。
去年整个市场可能噱头和炒作多一些，今年我们看到了更多的落地，也算是个比较好的时机吧。当然我认为大模型的技术也需要再向前发展，我也希望我们的这套范式之后可以和大模型有更深度的结合，或是有更好的 AI 系统的呈现。
8. SQL 语句规则是自己设计的吗？
苏鹏：那咱们 SQL 语句的规则相当于是咱们自己设计的吗？
汤林鹏：我们是给 index 加了一个特殊的类型，也就是一个 Vector index。当然我们有一些默认的推荐类型，尽量把配置、参数等等给大家简化掉，所以大家基本不需要指定太多参数。
另外在检索的时候，我们有一个 UDF 叫 distance function，它能根据索引返回最近的一些向量。当然这个可能之后还要拓展，比如我们最近已经把倒排表加进去，之后可能还要把向量和倒排表的联合查询加进去，再之后可能还有 multi-vector 多向量表征和检索。
除了上面说到的，我们还会对更多的行业做集成和拓展。现在很像信息化系统的早期，当时像 Oracle 这种公司就是赋能各行各业的，我们现在其实也希望能够通过这种 SQL 向量数据库的形式去赋能千行百业，所以也是需要不同行业的需求去做各种优化，或者说加各种算子，这些我们都在跟客户合作，一起打磨中。
苏鹏：我感觉现在确实有好多厂商也在考虑通过 SQL 的方式来实现向量的检索。各家厂商也都在做自己的，可能未来会反过来，推着 SQL 的规范再拓展呢？
汤林鹏：我觉得不会大变，SQL 本来也是有 UDF 和各种 dialect。SQL 发明 50 年没有大变过了，所以我觉得问题不大，有些拓展而已。
9. 为什么选择开源？
图源：https://kinsta.com/knowledgebase/open-source-vs-closed-source/
苏鹏：MyScaleDB 为什么会考虑开源出来，而不是直接推出个商业版本呢？
汤林鹏：其实我们是有商业版本的。我们最先进的 SQL 向量的引擎还是在商业版来提供的，毕竟公司还是得生存下去。不过我们的开源版本处理 500 万以下的向量是完全够用的，我们也提供了完整的 SQL 加向量的支持以及倒排表功能。相较于其他产品，我们认为 MyScaleDB 是有足够大的差异化和优势的。开源出来也是希望大家可以先去尝试一下，毕竟商务周期也是挺长的，先用开源产品体验一下我们的技术实力，增进一下对 MyScaleDB 的技术理解和信任。所以发布开源版本一方面是希望为社会做点贡献，另一方面也希望扩大一下公司和产品的影响力。
苏鹏：目前国内做 Infra 的团队，选择开源这条路还是挺多的。从 PingCAP 开始开源后，很多做 Infra 的创业公司都会先开源出来，然后再做商业化的探索。其实开源并不是我们说的商业模式，粗暴来说它更可能是一种市场手段，来获取用户的信任。试用开源功能的同时，另有一些功能是收费的，是有商业版本的支持的。
另一方面，开源是把技术开放出来，让更多人看到，以此来获得更多反馈，再回过头助推技术的进步，也是种对技术的贡献，这个层面来讲就不单纯是商业行为了。
汤林鹏：是的，这个我很认可。同时，我也觉得开源是公司行为，但其实也不单纯是个商业行为，如果纯粹是为了赚钱而去做公司的话，肯定有更多更轻松的方式。但是既然选择了 infra 和技术，肯定是希望通过技术去赋能行业，并且实践在商业上的可行度。
不过我们的确承载了一些技术理想和社会责任感的，开源可以增加互信，这对于 Infra 来说还是很重要的特性，可以帮助用户更低成本，甚至零成本来试用，后面其实也会更愿意为我们的产品买单。包括 Infra 产品，也需要广泛培养各行各业的生态合作伙伴，很多时候先让大家用开源版本来试会更容易一些，所以我认为开源和商业是可以很好结合的。
10. MyScaleDB 的下一步规划
图源：https://mp.weixin.qq.com/s/JvyKnEbdOSb1fTwhiQTO5A
汤林鹏：近期我们上线了倒排表功能，这个对很多客户来说还是比较关键的。现在像 Pinecone、Qdrant、 Weaviate 应该都有了这个功能，不过我们发现功能还是比较弱的，和 Elasticsearch 是没法比的。当然我们也不可能从周边功能上全面超越 Elasticsearch，他们毕竟也积累了 20 年，是个国际知名的大公司。我们现在至少在基本的使用场景上可以满足用户的需求，后面再根据客户的需求去迭代。我们在向量方面比 Elasticsearch 有很大优势，也包括 SQL 接口也比 Elasticsearch 有一定的独特性和优势，我们希望不会用太长时间，就能成为 Elasticsearch 的替代，也能有一定的市场空间。
另一方面，我们也看到了很多行业的机会，也和不同行业的公司去合作，比如金融、工业、科研、教育、医药等领域的公司，根据他们的需求去优化，整个 SQL + 向量领域是有很多工作可以做的。我们根据客户的需求去优化查询、增加更多的功能，包括分布式的向量查询在海量数据下也有很大的优化空间等等，这些都是我们希望和客户、合作伙伴一起合作推进。
在 SQL 数据库的时代，很多厂商也会把精力投入在周边的生态工具开发中，来增加产品的易用性。那 AI 时代的周边工具，其实就是数据的解析、向量化，包括 RAG/Agent 的 Workflow 等。
我们其实也会沉淀自己的工具和方法论，后面也可能会考虑部分开源出来。不过我们对待开源是比较谨慎的，还是希望做得足够好再开源。其实能做的事情很多，还是要面向未来，从真正能够服务客户和合作伙伴的角度去做。
11. AI 数据库的未来如何？
苏鹏：我们回到向量数据库。MyScaleDB 定位是 AI 数据库，不是一个单纯的向量数据库。那从向量数据库到 AI 数据库的这个阶段，汤总觉得未来的发展方向，或是可能的演进趋势是什么样的？
汤林鹏：如果定位在 AI 数据库，那就需要把 AI 相关的数据都管理起来。当然它不是 one size fits all，但是我觉得是 one size fits most。比如说我们的技术选型，那注定了它对于事务的处理不够高效。如果你的业务场景中事务很多，那可能还是得去选 pgvector 或是 TiDB。TiDB 和 MySQL 是兼容的，它也加了向量检索，当然这种系统的向量功能是有本质缺陷的，比如行存在复杂查询和数据分析中就会比较难优化。
而如果你有海量的数据做分析、查询等等，而且数据还是不同类型和不同模态的，那这个都算在我们定位的 AI 数据库的范畴内，我们都会根据客户市场的需求，把这些功能做打磨。为什么做倒排表，也是因为语言模型市场的需求最旺盛，这是客户需要的功能，所以我们就安排加上。
那说到其他的模态，后面如果我们想服务一个生物蛋白质 DNA，或者自动驾驶、具身智能的数据库，我们肯定得把他们相关的一些模态和相关函数做个匹配。还有刚才说到的非结构化数据的导入（Unstructured Data Pipeline），或者整个 RAG 相关的 workflow 的支持需求等。我们认为还是要带一点技术的前瞻性，参考市场中比较前沿的客户需求来迭代产品。
12. 技术理想主义者
图源：利用 OpenAI DALL-E 创作
苏鹏：从刚才和汤总的对话中，我感觉您对于技术还是有相当高追求的，包括我们前段时间看到的像杨植麟、王小川和朱啸虎他们所引发的关于技术理想主义的讨论，受到了大家广泛的关注。那您觉得，您自己是技术理想主义者吗？
汤林鹏：我认为我是带有一定的技术理想主义色彩的。比如我们之前做的生物识别领域，其实当时对整个行业都有着颠覆式的提升，我们把原有的系统做到自动化，性能上也是有几百到一千倍的提升，破获了数万起重大案件。不过后面很有意思的是，这个市场需求本身就有限，所以我们其实从技术角度把市场给做小了。从商业角度上来说，这肯定不是个特别成功的尝试。但从公共安全方面，我们的努力还是比较显著地改善了社会的运行方式。尽管商业上不算成功，但是对我个人而言，相关的成就感都是长久以来印象都非常深刻的，这可能就是理想主义的部分。
AGI 会更加复杂一些，也带来了很多争议。比方说 Sam Altman 可能从市场的角度上来宣传，他认为 AGI 很快就会来到，AI 也会从根本上改变社会运行的方式，大家要考虑 Universal Basic Income （UBI）等。某种意义上讲，我认为他提出的这个 UBI 机制是需要被好好设计的，我的确认同 AI 很大意义上会改变社会，但是从什么方面去改变社会，好的方面还是不那么好的方面，我认为我们还是有一定的影响力和发言权的。说到底我们需要的一个大模型，它是相对静态的虚拟存在，在很多方面与人竞争，也会被用在一些产品上，让大家沉浸在不良嗜好当中。那我们会希望之后生活在这种社会中吗？或者会希望我们的子女生活在这种社会中吗？至少我是不太能接受的。
我们的出发点还是更看重数据这块儿，我们认为数据其实是链接大模型和世界、也是链接大模型和用户的纽带，如果我们能把大模型和数据结合起来，无论是产品角度，还是系统角度，或是更深层次的大模型内在运行机理，把数据很好地结合进来，也会更加高效。这几项工作我们已经在做，或是和合作伙伴一起在做。我认为我们是有机会去打造更加专业、实时、和人协作更加高效的 AI。而且这种协同协作起来也能更加感受到价值和成就感，也包括让社会文明不趋向于收敛或是崩塌，而是爆发出更大的生机出来，向外拓展。在这些层面上我们正在努力，也会非常希望能促成上述这种图景。
这些其实也是需要和我们的合作伙伴和客户共同打造的，而且这个过程我认为是有机会创造更大价值的，因为这个系统本质上更加符合人性，和商业并不违背，或者讲也是一种向善的商业模式，所以我认为两者是可以结合的。因为之前的确走过一些弯路，所以商业上我们还是比较小心的。
苏鹏：是的，良性的商业模式还是会存在的。那我理解技术理想主义可以从两方面解读，第一个是 Don't be evil。我们需要用技术来改变世界，但是不能从恶的角度出发，要用技术创造社会价值。第二个是坚信技术的创新性和引领性，哪怕现在不被大多数人所理解。
对谈的内容就告一段落了，下面是直播时用户的提问，汤总集中做了解答，苏鹏老师也做了补充，供各位参考。
三、Q&A向量就是近似计算吗
向量并不是近似计算的同义词。近似计算是与向量有关的机器学习的过程中会用到的方法。比如，在推荐系统或文档检索中，可以使用近似最近邻搜索（Approximate Nearest Neighbor，ANN）算法来加速搜索过程。
向量数据库可否部署在端侧，在端侧的应用前景如何？
向量数据库可以部署在资源比较多的端侧，比如车端，边缘端服务器等，就像 MyScale 也支持 ARM 编译。端侧的能力越来越强，之后也会更多地与云端结合，所以前景不错。
如何看待在像 RAG这类场景中似乎向量检索的效率并不是目前的瓶颈问题相反准确率才是瓶颈问题
RAG 场景中，向量检索的效率和准确率都是非常关键的因素，向量数据库在其中则扮演着至关重要的作用。通过优化搜索策略（如前过滤和后过滤），向量数据库可以帮助提高检索效率；而结合结构化数据过滤以及向量和关键字检索可以综合提高准确率。
这个准确率也不完全体现在anns的召回率而是原始数据的相关度，对于向量数据库来说效率和精度不再是一个重要的数据库衡量指标了吗
召回结果跟原始数据的相关度与文档解析、分块、向量化的算法相关，单就向量数据库来说，还是主要衡量效率和精度。另一方面，随着客户数据量的增长，支撑同样数量的向量，需要的成本也是一个比较重要的指标。
现在线上 ANN 推荐的单元是多少个向量，多少维的？（一台机器/实例是一个单元 ）
一般来说，单机能够放的下，就不要上分布式。以 MyScale Cloud 为例，目前单机最大能存放 3.2 亿 768 维向量。
是否可以认为 SQL 就是向量数据库的一个 web 前端？
大部分向量数据库提供自己定义的 RESTful 接口。MyScaleDB 采用 SQL 作为接口，SQL 作为通用的数据库语言，允许 MyScaleDB 实现更丰富的功能。
MyScaleDB 支持哪些索引，都开源了么
MyScaleDB 开源版本支持 ScaNN、HNSW(SQ)、IVF(SQ/PQ) 索引，我们比较推荐 ScaNN，考虑向量检索性能和向量索引的构建时间等，ScaNN 是综合表现最好的。在企业版本中，MyScaleDB 推荐 MSTG（Multi-Scale Tree Graph, MSTG）向量引擎，在数千万或者更大数据量上数据密度有 10x 提升，性能也有近一个数量级的提升。
MyScaleDB 有做知识库相关的计划吗，知识库和向量库的差异在哪
MyScaleDB 本身是 SQL 向量数据库，而知识库需要提供更加完整的接口，比如文档的入库、解析、向量化，还有语义检索等。我们会考虑在其他产品模块或开源项目中提供这些功能。
事务的逻辑对于向量是否有必要呢？还是说主要是为了向量表里的其他标量字段
向量数据库名为数据库，使用上用法更接近于搜索引擎；因此事务在这里并不关键，一般的向量数据库也只保证最终一致性，而没有事务的机制。
多模态的数据如何做到向量的统一对齐，是通过模型做了编码对齐在存储到向量数据库吗？
这个一般是向量化模型考虑的。比如 CLIP 模型可以将图片和文本统一到一个向量空间。
向量数据库还有什么值得探索的科研方向吗？
异构硬件实现更大的向量加速 非结构化数据的多向量表征（multi-vector），实现更精准的匹配 混合查询 动态数据查询 数据安全与隐私
针对不是很大的场景（如：50w * 128dim 类似常规场景），向量库和向量数据库之间，应该如何选择和取舍？
如果只是实验性质的需求，而且如果没有其他的元数据，对于带过滤条件的向量搜索没有什么需求，可以考虑只用向量库的。 如果是生产级别的需求，或者需要结构化、向量、关键字等联合查询，还是推荐用数据库。
