Notion最近发布的一篇工程文章，复盘了他们过去两年如何构建向量搜索基础设施。读完之后，一种强烈的似曾相识感扑面而来：他们描述的每一个问题、每一次迁移、每一个临时方案，几乎都能在大数据发展史中找到近似对应。这既是Notion工程团队的胜利——他们用两年时间解决了大数据领域花了十五年才逐渐收敛的长期架构问题，也是行业尚未成熟的标志——选型一开始就出了问题，未来还会有更多AI agent产品重走老路。

故事始于2023年11月，Notion推出AI Q&A。底层架构上，他们的向量数据库运行在pod集群上，存储和计算绑定在一起，按workspace ID分片。产品一经推出，几百万workspace立刻挤破了等待列表，仅仅一个月，向量数据库容量就出现告急。团队选择了应急方案：启动带generation ID的新索引集群，新workspace走新集群，老的留在原地不动，再用Spark和Airflow做调优。四个月内，他们清空了等待列表，每日onboarding能力提升了600倍。但代价是generation路由逻辑问题在接下来两年里一直存在，成为困扰团队的新难题。

2024年5月，Notion从pod架构迁移到serverless，存储和计算被解耦，成本立刻下降50%，generation routing的复杂度也随之消失。2024年底到2025年初，他们又从原来的serverless provider迁移到turbopuffer，并借机升级了embedding模型。2025年中，他们发布了Page State功能：每个文本片段用xxHash 64-bit哈希并存入DynamoDB，页面更新时先比较hash再决定是否需要重新embedding，如果只是metadata变化则直接patch向量数据库。不久后，embedding生成也从Spark加外部API迁移到基于Ray和Anyscale的自托管模型，CPU预处理和GPU推理运行在同一条pipeline中。两年时间，五个重大决策，成本从峰值下降90%。

展望未来，Notion面临的挑战只会更大。他们可能还需要解决如何在不影响服务的情况下升级embedding模型，如何将一亿个workspace迁移到新的向量空间，以及如何构建离线context engineering让AI拥有持久记忆。这些挫折与经验，将成为整个AI agent行业的宝贵财富。对于正在构建AI基础设施的团队，Notion的教训值得深思：过早绑定特定架构会付出高昂的迁移成本，存储计算分离是长期趋势，增量更新机制应尽早设计。行业尚未成熟，但正是这些先行者的探索，才让后来者少走弯路。