17 篇博文 含有标签「data-engineering」

典型的 AI 叙事往往是这样的：你构建一个产品，添加一个 AI 功能，用户就能获得更智能的输出。这种框架虽然正确，但并不完整。更持久的优势根本不在产品层，而是在其底层运行的数据流水线中。

越来越多的工程团队悄然将 ETL 流水线中的正则规则、自定义分类器和手写解析器替换为 LLM 调用。结果是：流水线可以处理非结构化输入，适应模式偏移（schema drift），并对数千个类别的记录进行分类——而无需为每一个新的边缘情况重新训练模型。大规模运行这种模式的团队正在构建具有复利效应的数据资产。而那些仍将 LLM 纯粹视为产品功能的团队则不然。

在大多数 RAG 架构中都存在这样一种信念：如果检索返回了正确的区块（chunks），LLM 就会生成正确的答案。团队在嵌入模型选择、混合检索策略和重排序流水线方面投入了巨资。然而，在部署到生产环境三个月后，回答质量悄然下降——这不是因为模型变了，也不是因为查询模式发生了剧变，而是因为底层的语料库腐烂了。

企业级 RAG 的实施失败率约为 40%，而从业者最容易低估的失败模式既不是幻觉，也不是检索召回率低，而是文档质量。一项分析发现，通过引入文档质量评分，一个实施方案在不改变嵌入模型或检索算法的情况下，将搜索准确率从 62% 提高到了 89%。语料库是唯一的变量。语料库一直都是变量。

大多数团队把 embedding 生成当作一次性的 ETL 任务：跑一个脚本、填充向量数据库、然后就不管了。这在演示中行得通，在生产环境中却是慢动作式的灾难。你的向量索引不是一个静态的产物——它是一条持续运行的流水线，有自己的故障模式、数据新鲜度保证和运维手册。与主数据库不同的是，它出问题时没有任何异常会被抛出。系统照样返回结果，只是这些结果悄悄地、自信地错了。

如果你在运行一个检索增强生成（RAG）系统、语义搜索功能，或任何依赖 embedding 的产品，你的向量索引值得获得与 PostgreSQL 集群同等的严谨对待。以下是大多数团队在这件事上犯错的原因，以及生产级 embedding 基础设施究竟应该是什么样子。

用模型自身的输出训练模型，再用该模型的输出训练下一个模型，三代之内你就构建了一台逐渐变笨的机器。这就是模型崩溃——一个退化过程，其中每一代合成训练数据都会缩窄分布，直到模型遗忘罕见但重要的长尾模式。Nature 上的一项里程碑式研究证实了从业者的经验观察：即使微小比例的合成数据污染（低至千分之一的样本）也会引发词汇、句法和语义多样性的可测量退化。

然而合成数据并非可选项。真实世界的标注数据昂贵且在专业领域稀缺，在前沿模型所需的规模下日益枯竭。2025-2026 年成功交付微调模型的团队并非在回避合成数据——他们正在设计管道架构以确保生成过程不会崩溃。一个高效管道与一个自我中毒管道之间的区别在于多样性保持、验证循环以及知道何时该停下来。

你的 RAG 系统在三个月前上线，检索准确度令人印象深刻。如今，它对用户提问中三分之一的内容都给出了“自信的错误”回答——而你的监控系统完全没有察觉到这种变化。没有错误日志，没有延迟激增。语义相似度得分看起来很正常。但检索到的文档已经过时，而模型却充满了信心地回答，因为检索到的上下文看起来非常权威。

这就是 RAG 的新鲜度问题：语义相似度并不关心时间。一个已弃用的 API 参考文档的 Embedding 得分可能与当前最新的文档一样高。上个季度的政策文档可能会排在更新版本之前被检索到。系统不知道，也无法分辨。大多数团队只有在收到用户投诉后，才发现他们的索引已经过时了数周甚至数月——而到那时，用户已经悄然失去了对系统的信任。