这两年只要稍微关注AI基础设施的人基本绕不开Vector Database这个词。大模型一火所有做知识库、做RAG、做智能体记忆的团队都在疯狂往向量数据库里灌数据。Pinecone估值飙升Chroma成了开发者的玩具pgvector更是被当作“真香平替”到处安利。但很多人可能不知道在2017年左右这还是一条被绝大多数人当成“伪需求”的赛道。那时候你到处跟人聊“非结构化数据需要专门的数据库来处理相似度检索”对方大概率会觉得你在讲科幻故事。Zilliz就是在这个时间点入场、并且一路活到风口兑现的公司。它做的是Milvus一个开源向量数据库。更值得琢磨的是这家公司的判断路径——它不是等到ChatGPT出来之后才慌忙调头而是在向量数据库连名字都没有几个人听过的时候就把整个公司押了上去。这种“过分早熟的远见”放到今天来看其实比任何技术方案都值得复盘。这篇文章我就以Zilliz为切片把向量数据库背后的技术逻辑、工程取舍、产品节奏和商业化路径拆开聊聊。目的是帮做AI应用、做数据基础设施、以及正在纠结“要不要自研向量检索”的团队理解这件事的本质而不是停留在“大家都在用Milvus所以我也用”的跟风层面。1. 2017年的“冷启动”那时为什么没人做这件事要理解Zilliz的“超前”你得先回到2017年前后的技术环境。那一年TensorFlow刚站稳脚跟PyTorch还没完全长大AlphaGo带来的浪潮开始让普通人听说“深度学习”但产业界的落地场景其实还很有限。彼时主流的检索手段依然是Elasticsearch、Solr这样的全文检索系统以及关系型数据库里SQL做精确匹配。相似度检索、语义搜索、以图搜图都是实验室里的课题不是生产环境里的刚需。在这样的背景下一个做数据库的团队说要搞“专为向量设计的数据库”面对的质疑可以想象。第一没人有这么多向量数据需要存第二当时AI模型产出的向量质量也一般用词袋、TF-IDF或者简单Embedding就能对付第三就算你真有几百万向量用Faiss、SIFT这类算法库本地算一算也能跑通为什么非要单独一个数据库这三条质疑分别对应市场需求、技术供给和产品形态哪一条都在说“你太早了”。但Zilliz押的不是当下而是一条趋势线。它判断非结构化数据的规模会持续爆发AI模型会从分类走向生成所有内容都会变成向量形态那么检索向量的需求就一定会从“算法工程师的本地实验”变成“业务系统的在线服务”。一旦变成在线服务就需要数据结构化地管理、持久化地存储、稳定地扩展、统一地接口——这活算法库干不了Elasticsearch的向量插件也只是附加功能撑不住大规模所以一定会有专门的系统形态出现。现在回头看这条判断链几乎每一步都兑现了。大模型的Embedding能力让文本、图片、音视频全部变成高维向量RAG的落地让企业私有知识库成了向量数据库最大的增量场景而在线检索的高并发和低延迟要求则彻底淘汰了“在脚本里调Faiss”这种玩法。这里有一个特别微妙的地方。好多人觉得Zilliz是“赌对了AI”但准确地说它赌的是“数据形态的变化趋势”而不是某一个具体的AI模型。ChatGPT没出现之前向量数据库做的是推荐系统、以图搜图、去重、异常检测这些业务ChatGPT出现之后多了一个RAG的盘子。这说明什么说明向量数据库本身是独立的赛道不是某款模型的附庸。这种底层的“数据视角”才是它活下来的关键。还有一个外部条件容易被忽略2017年到2020年这段时间GPU的成本性能比在持续改善NVMe SSD普及内存越来越大。向量数据库属于典型的“算力密集存储密集”系统没有这些硬件基础设施的进步软件做得再花哨也跑不动。Zilliz敢在那个时间点All in说明它对底层硬件演进有一定的预判这也解释了为什么它早期会那么执着于GPU加速方案——硬件趋势是看得见的模型趋势往往是突然爆发的两者结合才让“未来”变得可等待。2. 向量数据库的“技术深水区”从算法到工程很多人对向量数据库的理解停留在“用HNSW做近邻搜索”好像索引一建、召回率一调就完事了。真进去做一段时间你会发现索引算法只是水面上的一角底下全是工程问题。先看索引本身。向量检索面对的核心矛盾是高维空间里没有天然的“顺序”你没法像B树那样对一维数字做范围剪枝。维度一高数据点之间的距离区分度急剧下降这就是常说的“维度灾难”。举个例子二维平面里你可以把点排成网格快速定位但到了128维、768维甚至更高的空间每个点几乎都是“孤岛”传统的树形结构效率会退化到和线性扫描差不多。业界应对这个问题的套路基本分成四类。第一类是暴力检索Flat就是一条一条算距离结果绝对精确但速度只能用在小数据集上。第二类是倒排IVF先把向量做聚类把空间切成一个个桶查询时只进最近的几个桶里搜牺牲少量召回换速度。第三类是量化PQ把向量切分成子空间每个子空间单独做码本用短码代替原始向量大幅降低内存占用和距离计算成本代价是精度损失。第四类是基于图的索引HNSW是代表把向量构造成多层图查询从顶层粗粒度节点开始逐渐下沉用“跳表”的思想在高维空间里找路是目前召回质量和性能平衡得最好的方案之一。但索引算法本身其实已经相当成熟Faiss、HNSWLib、DiskANN这些开源库都做得很好。真正的差异在于数据库怎么把这些算法组织成一个高可用、可扩展、支持CRUD、支持标量过滤的系统。Milvus从1.0到2.0的架构演进很能说明问题。早期版本大量借力Faiss用GPU做加速当时看起来性能很猛但有个致命问题GPU内存有限数据量一大就装不下而且主从模式下写路径和读路径耦合扩展性受限。到了2.0Milvus干脆推倒重来改成云原生架构核心思路是存储计算分离数据存在对象存储里计算节点负责索引和查询通过消息队列做数据变更的流转用etcd管理元数据。这个架构带来的好处很直接——计算节点可以水平扩缩容存储成本被大幅压低系统终于能像个真正的数据库那样去运维。这背后其实是两个工程团队思路的分水岭。算法库解决的是“怎么算得快”数据库解决的是“数据来了怎么不丢、查询并发来了怎么不崩、集群加了机器怎么不重导”。后者才是专门向量数据库相对于裸用算法库的核心价值。另一个被反复低估的点是标量过滤和向量检索的组合。真实业务场景里几乎没有“纯向量查询”这种需求更多是“2024年之后的商品、价格在100到200之间、按语义匹配排序”。这就是典型的混合查询。要实现得好要么用“先过滤再检索”的Brute Force在过滤结果集里暴力计算要么用“先检索再过滤”的粗排加精排要么用更复杂的联合索引。每种方案各有优劣但要做到千万级数据量下的毫秒级响应里面全是血泪调优的功夫。Milvus 2.x版本里大量迭代花在“标量过滤对向量检索的剪枝”上比如用位图、倒排、范围索引辅助降低进入向量索引的候选集这个方向是通用的系统能力不是单靠一条HNSW就能解决的。写到这里必须说一句如果你的向量数据量只有几十万条QPS也不高那用pgvector或者直接在内存里跑Faiss就够了没必要上专门数据库。专门数据库的价值曲线是随着数据规模、并发规模、可用性要求和标量过滤复杂度上升而显现的。一个小卖部不需要上ERP系统但一个大型连锁商超一定需要。3. 押注未来Zilliz的产品哲学与商业化判断技术只是地基产品路线的选择才真正决定一家公司能不能活到风口。Zilliz有几个关键决策复盘起来很有意思。第一是坚定的开源路线。Milvus从2019年开源后来在2020年捐给了LF AI Data基金会托管。开源的直接好处是降低了用户尝试的门槛让Milvus在早期没有任何商业品牌背书的时候靠GitHub上的Star、技术社区的口碑慢慢扩散出去。2019年到2022年大模型还没火你靠销售去推“向量数据库”这个概念非常困难但开源可以绕过销售环节让一线工程师先用起来。这其实是数据库类创业公司被验证过多次的打法——先让大家用起来再谈商业化。第二是云服务的节奏。Zilliz Cloud全托管Milvus在2022年底前后陆续上线到2023年大模型爆发的时候正好赶上需求放量。全托管服务解决的是用户“懒得运维”的痛点而Milvus本身复杂有一定门槛的架构反而在这种服务模式下成了优势——你不需要懂Kubernetes、不需要调Pulsar、不需要盯消息积压Zilliz帮你把复杂的部分全部抹平。这里有一个判断我很认同数据库这类基础软件纯开源很难养活团队纯闭源又很难在早期获得社区信任开源自建云的混合模式是目前最现实的商业路径。第三是对“非结构化数据”这条主线的坚持。Zilliz官方的叙事里高频出现的词是“非结构化数据的未来”。这不是营销话术而是它产品决策的支点。结构化数据有SQL、有关系型数据库统治了几十年而文本、图片、音视频、代码这些非结构化数据数量是结构化数据的几十上百倍但一直没有一套好的基础设施去管理它们。向量数据库的本质不是替代关系型数据库而是给非结构化数据建立起属于自己的“数据底座”。这三个决策放在一起形成了一个完整的产品哲学用开源降低认知门槛用云服务实现商业闭环用非结构化数据的长期叙事来保证方向不发生偏移。表面上看Zilliz好像在等风口但实际上它是在风口来临之前已经把该做的产品、该建的社区、该跑通的商业化模型都走完了。当然这中间也不是没有犹豫和弯路。早期GPU加速的执念在一段时间内确实成了Milvus的标签但GPU方案在真实业务里暴露出部署复杂、成本高的问题之后团队及时调整了重心把CPUGPU混合、云原生架构放到更优先的位置。这种“敢押注也能低头认错”的节奏对一家靠“远见”起家的公司来讲可能比一开始就选对方向更重要。4. 风口到来之后向量数据库的现状与竞争格局2023年之后风向彻底变了。大模型把RAG变成了刚需RAG把向量数据库变成了“标配”。一个特别直观的现象是之前向客户解释“什么是向量数据库”要花一小时现在客户自己跑过来问“你们能不能扛住千万级向量”。风口是真的来了但风口也带来了黑压压的竞争对手。目前这个赛道的玩家可以粗略分成四类。第一类是专门的向量数据库除了Zilliz的Milvus/Zilliz Cloud还有Weaviate、Qdrant、Pinecone。第二类是“数据库附加向量功能”的通用玩家比如PostgreSQL的pgvector、Redis的向量搜索、Elasticsearch的dense_vector。第三类是轻量级的开发者工具类产品Chroma比较有代表性定位于快速验证和原型开发。第四类是云厂商内置能力AWS的OpenSearch Serverless、Azure AI Search都支持了向量检索走的都是“平台内置”的路子。竞争格局里最让人纠结的是第一类和第二类的边界。pgvector能在PostgreSQL里直接建向量索引如果你本身就是PG的用户且数据量不是特别夸张引入pgvector几乎零成本何必再部署一套MilvusElasticsearch同理已经有文本检索集群的团队叠加一个向量字段就能做混合搜索为什么要再学一个新系统这些问题非常现实也是很多团队在选型时反复讨论的点。我的个人判断是这个问题的答案取决于数据的规模和复杂度。几十万到几百万级向量、简单查询场景pgvector完全够用硬上专用向量数据库反而增加运维负担。但到了千万级向量以上、高并发低延迟、有复杂的标量过滤叠加或者需要向量和时间戳、用户ID、租户ID等多维度权限一起过滤的场景通用数据库的优化深度就不太够了。另一个区分点在于可用性能力专业向量数据库在多租户隔离、滚动升级、动态扩缩容、监控告警这些“生产级特性”上普遍更完善因为这是它的主业而通用数据库的向量功能更像附加题。还有一种观点认为向量检索长期会被“消灭在模型内部”——大模型上下文越来越长也许未来不需要外部检索系统。我对这个观点持保留意见。长上下文确实解决了一部分“记忆”问题但企业级知识库里动辄千万级文档每次请求把所有内容塞进上下文既不经济也不现实。检索增强的核心价值是用最低的成本定位最相关的信息这个需求不会消失只会越来越精细化。所以现在的向量数据库竞争本质已经不是“要不要用向量检索”而是“在什么规模下用什么方案”。Zilliz的优势在于技术积累和开源社区基本盘挑战在于越来越多的一线工程师会在日常工作中先接触到pgvector、Chroma这类更轻的方案如果Zilliz不能把“全托管高性能复杂查询”这个组合的服务体验做到碾压级它很有可能被挤到“只有重度场景才选它”的位置。这个局还在演化远远没有定论。5. 一家“看见了未来”的公司到底做对了什么回到标题那个问题——当Vector Database还不是主流时Zilliz到底看见了什么我觉得它看见的不是“某个具体的技术风口”而是三个更抽象的判断。第一人工智能一定会把所有内容变成向量表达Embedding会像当年的URL一样成为数字内容的基本形态第二数据量一旦大到某种程度通用工具一定包不住专用需求也就是说必然会跑出专门的基础设施公司第三这件事的落地时间窗口会很长但一旦启动会非常陡峭所以必须“提前把摊子铺好”。三个判断里第三个最关键也最容易被忽视。很多创业公司能看见趋势但熬不到趋势兑现的那一天。Zilliz能熬到2023年的大爆发靠的不仅仅是信念还有开源社区带来的低成本的用户触达、云服务带来的可预期的收入模型、以及6年时间里不停迭代出来的技术护城河。这里有一个很反直觉的经验远见本身不值钱值钱的是“在远见变现之前的存活能力”。你可能在两年前就预判到RAG会火但你的公司如果在两年前就开始烧钱做营销、四处讲PPT而产品没跟上风口来的时候你已经死了。Zilliz的方式是典型的“闷头做产品开源养社区”它没有在大众舆论层面刷存在感而是在工程师社区里一点一点建立信任。等风口来临大家发现这个东西不是PPT是真正能跑的系统信任瞬间转化为使用量。另一个做对的地方是节奏感。2021年融资环境宽松的时候Zilliz完成了B轮融资手上有足够的弹药2023年风口来了之后它没有急着去迎合每一类用户而是把资源集中到Milvus 2.x的稳定性和Zilliz Cloud的托管体验上。这种“缺钱时谨慎、有钱时不飘”的节奏控制在创业公司里相当难得。还有一个可以学习的点它对“生态位”的意识。Zilliz一直在强调“AI的数据基础设施”这个定位而不是单纯说“我做得比别人快”。当一个新赛道出现时最先占据用户心智的公司往往会获得巨大的惯性优势。大模型带火向量数据库之后Milvus作为最早被大量开发者使用的开源向量数据库自然成了很多人认知里的“原生向量数据库”的代名词。这种心智卡位对后来者来讲极难撼动。6. 写在最后的一些个人想法这几年看了不少AI基础设施公司的起起落落Zilliz是少数让我觉得“这家公司是真的在当初没人相信的时候就开始干”的案例。不是因为它的技术有多炫而是因为它在方向选择上表现出了一种少见的固执与清醒的结合——固执在于始终相信非结构化数据会成为主流清醒在于每一次技术路线调整和新产品发布都踩在用户真实的痛点上。如果你现在也在做一个看起来很超前的方向Zilliz这个案例最值得记住的一点是不要试图预测风口的准确日期而要确保风口来的时候你还在牌桌上。这意味着你要在无人喝彩的时候把产品做好把社区维护好把现金流管好把团队的心气留好。远见的最大风险不是方向错了而是死得太早。最后分享一个我自己的小习惯评估一个基础设施类项目时我通常不看它当前的性能指标多好看而是看它能否回答“三五年后数据量翻一百倍时这套架构还撑得住吗”。拿这个标准回头看Milvus从1.0到2.0的云原生重构你会明白Zilliz在2017年看见的“未来”其实从第一天起就是用工程结构去提前布局的。这个思路比记住任何一家公司的名字都更有用。