别让错配阶段的Data Infra，拖垮你的AI项目

这几年和各类 AI 团队、互联网企业打交道，我发现一个常见问题：很多团队的 AI Infra 选型本身并不差，真正的问题是它和项目所处阶段不匹配：过早工程化，会在早期严重拖慢产品迭代速度；但低估未来的业务规模与复杂度，又会在后来的业务爆发期，顶着业务压力被迫做infra的推倒重构。

AI 项目在不同发展阶段里，围绕 Data Infra 常踩的坑也往往不一样。结合过往用户支持经验，我们把它拆成四个典型阶段来聊一聊，希望这些总结能帮大家少走一些弯路。

一、原型期：快速跑起来就是最高美德

原型期速度远比数据基础设施重要。或者更准确地说，这个阶段甚至不需要所谓的数据基础设施。可扩展性，治理能力、性能优化这些，在这阶段都不用做重点考虑。

这个阶段的目标只有一个，让应用先跑起来。

这阶段最常见的错误，是把复杂度、高级能力认为是产品能力的底层保障：团队还没有多少文档需要导入，就先搭起了流式数据摄入管道；还没有一个真实用户，就开始配置生产级复制；数据规模还远没有大到需要认真考虑一致性，就已经开始担心多个系统之间的数据同步问题。

团队花了好几周做的基础设施，服务的可能只是一个一周时间就会被否掉的产品思路。而这时间其实已经足以去验证一些关键的产品想法。

如果对生产级向量数据库的熟悉度不高，那这一阶段使用它的必要性其实不高。这一阶段团队需要的其实是：

• Milvus、pgvector、Elasticsearch，或者一个轻量级搜索Library
• 本地文件系统

总之，不同选型之间的检索质量差距，远远小于“有一个能工作的原型”和“什么都没跑起来”之间的差距。先让团队在几天内把应用跑起来的就是最优解。

二、PMF 期：数据库越多，问题越多

一旦用户开始上量，团队的重点就会从做一个 demo 转向持续改进产品。

这时候，很多企业会走入一个误区：数据库类型越有针对性，检索质量就越好。

然后团队就开始为每一种检索任务配一套系统：PostgreSQL 用来做过滤，Elasticsearch 用来做关键词搜索，MongoDB 存文档，Milvus 存向量，Neo4j 处理图关系。

检索栈的增长速度，甚至超过了产品本身。

于是，怎么做数据的同步管理，以及多套数据库系统的维护，成为了新的困扰。

文档存放在一个系统里，embedding 存在另一个系统里，元数据又放在第三个系统里。于是每一次写入，都变成了一个异构分布式系统的数据一致性问题。一次删除失败，会留下孤儿向量；一次部分插入，会产生过期 embedding；一次 schema 变更，意味着多个pipeline都要同时更新。

这一阶段，PMF 期最容易误判的是：把检索质量问题归因于数据库能力不够。但其实，检索质量很少取决于你接入了多少种数据库。

这一阶段改善数据pipeline本身带来的提升效果，可能会更明显，比如：query rewriting 改写、迭代式搜索、渐进式信息展开、更好的 reranking。站在数据层看，新增一个 embedding 字段，或者支持一种新的模态，往往比再接入一个专门数据库更能提升检索质量。

更不用说，现代向量数据库的能力边界，早已不只是存向量。全文搜索、JSON 过滤、地理空间搜索、混合检索——多数成熟系统基本都已经原生支持。过去那种每种任务配一个专门数据库的假设，正在变得越来越过时。

这时候，用一个系统覆盖完整的检索需求，不仅运维起来更简单，也能为下一阶段的演化打下更干净的基础。

很多团队在增长中期被迫重建数据infra，有时候不是因为他们选错了数据库，反而是因为他们选了太多数据库。

所以，infra选型，看三点能力就好：

• 是否可托管：让供应商负责可靠性，让团队把精力集中在产品本身
• 一个系统支撑多种检索：支持向量、全文、JSON、过滤、混合检索，而不是为每个任务配一套数据库
• 足够的增长余量：能够支撑下一个数量级的增长，而不必重构

三、规模化阶段：不是所有工作负载都该共享同一套计算资源

到规模化阶段，成本压力会成为团队的第一考量。原因很简单：数据增长速度通常比收入增长速度更快。

这个阶段最常见的错误，是以为过去的传统数据库方案已经带来了如今的成功，自然也能顺利支撑团队的下一个阶段需求。

但这时候，infra上已经没有多少轻松重构的空间了。对高增长团队来说，做infra迁移，要么极其昂贵，要么极其危险，往往两者兼具。

这时候，应该把所有的数据都直接放在S3之类的对象存储上。因为在存储层，对象存储是现有方案中最便宜、最可靠、最具扩展性的选择。

而对象存储在架构中，承担的角色不只是一个持久化存储层，更是整个检索架构的基础层。

在基础层之上，我们可以只在有需要的业务中引入合适的计算资源。比如，对延迟敏感的服务使用长期在线的集群；数据导入和索引构建使用临时计算资源；分析和批处理任务使用按需计算。每种工作负载只获得它所需要的计算资源。

这就是 Vector Lakebase 的核心：存储层始终在线，计算则不必常驻，而是只在需要时、只针对具体工作负载启动。 最重要的是，所有计算资源——无论是长期运行的，还是按需启动的——本质上都只是对象存储层的缓存。数据始终只存在于存储层里，计算只是不同访问数据的方式。比如：

• 内存型：适合高 QPS、低延迟场景，例如 AI 推荐系统、实时检索
• 内存 + SSD：适合上下文、记忆、知识库等在线服务
• 分层存储型：适合访问频率较低的冷内容
• on demand型：适合批处理、内部分析、测试环境

如果采用更灵活的架构设计，相比统一计算资源的设计，至少能降低 50% 甚至更多的基础设施成本，同时还能让每类工作负载获得更好的服务质量。

而一些团队更青睐的Serverless 方案往往也难以解决这一阶段的成本困境。因为数据一旦进入 TB 级别，写入成本和存储成本就会开始占据主导。但serverless 架构会把资源池化开销、索引成本、持久化数据成本都打包进写入和存储的溢价里。在这一模式下，用户其实已经不是在为实际用量付费，而是在为抽象层付费。

总之，这一阶段：你的基础架构必须匹配你的数据规模增长，不要和你的数据规模对抗。 如果强迫一种架构同等服务所有工作负载，最终结果往往是没有任何一种工作负载被真正服务好。而这种妥协的成本，会随着每GB数据的增加而持续累积。

这个阶段，企业真正需要的是：

• 以对象存储，例如 S3，作为基础层和底层检索层：持久化、始终完整规模在线，所有计算都从这一层读取数据
• 一个 Vector Lakebase：数据不移动，计算按工作负载启动
• 为不同工作负载匹配合适的计算层级

四、企业级规模：信任本身成为产品能力的重点

这个阶段最常见的误区是：团队仍然以为自己面对的是一个技术问题。

他们已经优化了基础设施，也控制住了成本，于是自然会认为，走向企业级市场只是继续扩容，再补上一些安全能力。

但事实并不是这样。

真正阻碍打企业级客户的问题，往往和性能无关：

• 我的数据和其他客户的数据是否物理或逻辑隔离？
• Access control怎么做？谁访问过哪些数据，能不能证明？
• 你能在我们的地区提供服务吗？
• 你们能部署到我们自己的云账号里吗？

第三阶段，企业面临的异构问题还只是技术层面的：不同工作负载，需要不同计算层级。

但到了如今的第四阶段，异构的来源变成了你的不同客户结构：免费用户，他们需要的是成本高效的共享服务；付费个人客户，他们期望更好的可用性；企业客户，他们要求完整的数据隔离、专属计算资源，以及一切都可审计。而这，需要平台级数据基础设施来支撑。

如果用同一套架构服务这三类客户，要么会在免费层上花太多钱，要么会无法满足企业客户需求，甚至两种问题同时发生。

这时候，我们就该考虑为基础设施分层，匹配不同客户群体

• 免费用户和个人用户使用共享集群：资源池化，成本优化
• 企业客户使用独立集群：专属计算、专属存储、专属访问控制
• 对于要求部署在自己云账号内的客户，提供 BYOC（Bring Your Own Cloud）

这里要注意的是，这些都只是部署形态差异，不是架构分叉。SaaS 和 BYOC 最好使用同一套 data plane 抽象、同一套控制接口、同一套版本模型、同一套升级路径。否则团队会长期维护两套系统，两套代码库、两套部署流水线、两套运维手册，而且两套系统一定会逐渐不一致。

另外，对于超大规模的全球性客户， global cluster的建设也应该被早日提上日程。不同地区的企业客户不会接受长期单区域部署， SLA 也撑不住这种设计。如果没有一套跨云、跨区域统一的数据基础设施接口，团队就会被迫在不同环境里运营不同的数据层。实时同步会变成一个新的异构分布式系统问题，运维的复杂度也会随之不断增加。

我们之前和一些全球化经营的超级企业聊过，他们基本都有一个共性痛点：一些企业级能力，都是在后期演进中才勉强硬加进去的，有些甚至花了四个月，强行为没有数据隔离架构的infra增加隔离能力。眼前的问题是解决了，但这套系统到底有多脆弱，后续要为此付出多大的运维成本，所有人都心知肚明。

总结来说，企业级就绪不是一张清单，它是早期就应该构建好的一系列架构决策的结果。

这一阶段的企业，需要的是

• 一个统一的数据基础设施接口：具备跨云、跨区域一致的能力
• 为高可靠和多地域服务设计的 global cluster
• 分层服务能力：免费用户使用共享集群，企业客户使用专有集群
• SaaS 和 BYOC 共用同一套架构。相同数据平面，不同部署目标。
• 有开放标准以及开源产品背书：在企业级规模下避免厂商锁定。

尾声

总的来说，企业的不同阶段会面临不同问题：

第一阶段，核心要解决的是速度问题；第二阶段，要解决的是架构复杂度问题；第三阶段，成本和架构成为关注重点；而第四阶段，核心是信任与平台。

几乎所有平稳走过架构演进升级的团队，他们不会频繁去问“我现在需要什么数据库？”而是已经在思考：“下一个阶段会需要什么？我今天的选择，会不会把通往未来的可能堵死？”

在第一阶段，很多团队，需要的，只是一个基础的向量数据库；但第三阶段开始，Vector Lakebase会成为所有企业必须的data infra，它具备统一的存储底座，能让你用一个平台、一套架构下支撑不同的工作负载；并匹配付费、免费、企业级场景的不同客户类型。

而顺利走最后阶段的团队，有时候也不需要更强的资金或者顶级人才配置，只需要想清楚一件事：infra决策不是一个临时选择，是之后所有创新与业务发生的地基。