大多数团队把 embedding 生成当作一次性的 ETL 任务：跑一个脚本、填充向量数据库、然后就不管了。这在演示中行得通，在生产环境中却是慢动作式的灾难。你的向量索引不是一个静态的产物——它是一条持续运行的流水线，有自己的故障模式、数据新鲜度保证和运维手册。与主数据库不同的是，它出问题时没有任何异常会被抛出。系统照样返回结果，只是这些结果悄悄地、自信地错了。
如果你在运行一个检索增强生成（RAG）系统、语义搜索功能，或任何依赖 embedding 的产品，你的向量索引值得获得与 PostgreSQL 集群同等的严谨对待。以下是大多数团队在这件事上犯错的原因，以及生产级 embedding 基础设施究竟应该是什么样子。
用模型自身的输出训练模型，再用该模型的输出训练下一个模型，三代之内你就构建了一台逐渐变笨的机器。这就是模型崩溃——一个退化过程，其中每一代合成训练数据都会缩窄分布，直到模型遗忘罕见但重要的长尾模式。Nature 上的一项里程碑式研究证实了从业者的经验观察：即使微小比例的合成数据污染（低至千分之一的样本）也会引发词汇、句法和语义多样性的可测量退化。
然而合成数据并非可选项。真实世界的标注数据昂贵且在专业领域稀缺，在前沿模型所需的规模下日益枯竭。2025-2026 年成功交付微调模型的团队并非在回避合成数据——他们正在设计管道架构以确保生成过程不会崩溃。一个高效管道与一个自我中毒管道之间的区别在于多样性保持、验证循环以及知道何时该停下来。
你的 RAG 系统在三个月前上线，检索准确度令人印象深刻。如今，它对用户提问中三分之一的内容都给出了“自信的错误”回答——而你的监控系统完全没有察觉到这种变化。没有错误日志，没有延迟激增。语义相似度得分看起来很正常。但检索到的文档已经过时，而模型却充满了信心地回答，因为检索到的上下文看起来非常权威。
这就是 RAG 的新鲜度问题：语义相似度并不关心时间。一个已弃用的 API 参考文档的 Embedding 得分可能与当前最新的文档一样高。上个季度的政策文档可能会排在更新版本之前被检索到。系统不知道，也无法分辨。大多数团队只有在收到用户投诉后，才发现他们的索引已经过时了数周甚至数月——而到那时，用户已经悄然失去了对系统的信任。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
