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

五十年来，数据管道通过“宕机”来强制执行它们的契约。上游团队重命名了一个列，下游解析器抛出异常，任务崩溃，有人在凌晨 2 点收到告警，到了早上，契约要么被修复，要么被正式重新协商。没有人将其设计为一种治理机制。它只是源于这样一个事实：僵化的代码无法处理它预期之外的输入。崩溃就是执行。告警器就是审计追踪。


接着，我们让 LLM 坐上了消费者的位置，于是破损不再导致崩溃。

模型在读取格式错误的数据记录时不会抛出解析错误。它会“自适应”。缺失的字段变成了看似合理的猜测。重命名的字段变成了略微错误的解读。单位的变化——从分到元，从 UTC 到本地时间——变成了一个自信的答案，而其偏差倍数模型从未提及。管道端到端显示为绿色，仪表盘保持静默，而破碎的契约在三周后才浮出水面，表现为一种谁也无法进行二分定位（bisect）的弥散性质量投诉。我们没有消除故障。我们消除的是“信号”。

你的智能体（agent）用上个季度的价格回答了客户的计费问题，复盘报告会将此归咎于模型。但不应该如此。Prompt 组装正确，检索评分很高，模型对所给的所有信息进行了合理的推理——而所给的一切在三天前都是真实的。在 CRM 导出、文档同步和向量索引重建之间的某个环节，“世界的当前状态”悄然变成了“截至周二的世界状态”，而你的技术栈中没有任何环节在衡量这种差异。

数据工程师在几年前就解决了这类问题。一个消费十张上游表的下游仪表板拥有血缘关系（lineage）、新鲜度检查以及一个在夜间任务出错时进行呼叫的轮值机制。你的智能体所消费的上下文窗口也是同样的东西——一个由文档、工单、代码、CRM 和记忆连接而成的物化视图（materialized view）——只不过没有人负责这个连接（join），没有任何东西衡量它的陈旧度，当它提供昨天的真相时，失败却被归类为“模型幻觉”。

Text-to-SQL 演示从不会因为语法而失败。模型生成的 SQL 非常流畅 —— 说实话，比大多数初级分析师写得都好 —— 查询可以运行，并且返回了一个数字。演示在三周后的生产环境中宣告失败，因为 CFO 注意到智能体的 “Q2 营收” 与董事会报告不符。这不是因为 SQL 格式错误，而是因为数据仓库中有三种说得通的营收定义 —— 预订额 (bookings)、已确认营收 (recognized) 和扣除退款后的净值 (net-of-refunds) —— 而模型自信地选择了其中一个。恰恰不是财务部门使用的那一个。

这是最关键的失效模式，而且在你见过的每一个基准测试中都是不可见的。解决方案不是更好的模型或更长的提示词。而是一项大多数数据团队已经构建了一半然后放弃的基础设施：语义层 (semantic layer)。你为 BI 仪表板编写的指标定义 —— dbt metrics、LookML、Cube 定义 —— 事实证明是数据智能体缺失的工具契约。交付可靠智能体的团队意识到，构建顺序与大家的假设恰恰相反：语义层优先，智能体随后。

每个人都在担心模型崩溃，将其视为一个互联网规模的问题：AI 废话充斥网络，下一代基础模型基于这些数据进行训练，导致质量在一个缓慢的文明反馈循环中衰退。这种表述让人感到宽慰，因为它把崩溃变成了别人的问题——这是发生在 OpenAI 和 Anthropic 身上、以年为单位的事情，并且由成群的数据清洗博士负责缓解。

这里有一个令人不安的版本：同样的反馈循环已经在你公司内部运行，而且它的收敛速度比互联网规模的循环快得多。每一个被标记为“黄金示例”的日志补全、每一个进入 RAG 语料库的模型编写文档、每一个通过 LLM 生成答案并由 LLM 评判的评估——每一项都是在利用你自己的“数据废气”进行训练的微小行为。你不需要九代的递归预训练就能感受到它。在一个从自身日志中挖掘少样本示例和微调数据的生产系统中，第二代产品下个季度就会发布。

一名支持工程师在值班频道发了消息。一位客户粘贴了助手上周检索到的一个句子，合规团队回复说：我们已经不再这么说了。他们已经停用这句话四个月了。CMS 中的文档显示是正确的。但向量索引中的嵌入分块（chunk）仍然是旧的内容，且拥有极高的相似度得分，并在每次相关查询时被提供给模型。没人改过检索代码。没人改过模型。真相源（source-of-truth）变了，而索引却对此一无所知。

这是摄取流水线（ingestion pipeline）的一种失败模式：它最初是为“创建”而设计的，后来演变成了一个也要处理“更新”的系统，却没有人专门为“更新”进行设计。“创建时嵌入”的任务在每份文档首次写入的那天运行。一个季度后，CMS 团队发布了一个编辑端点，由另一个团队负责，他们将其接入了搜索、面向公众的渲染器和变更日志 feed —— 接入了每一个消费者，除了那个隐藏在不同名称下的派生数据集。数月过去，语料库发生了漂移。检索系统开始回答那些公司早已正式抛弃的问题，而唯一的信号来自于一位困惑的客户。

观察一个客服智能体处理一段对话，数一数它计算了多少次“流失风险”（churn risk）。第一次是在它对工单进行分类时。第二次是在它决定是否提供折扣时。第三次是在它起草升级摘要（escalation summary）时。每一次，它都会重新读取原始订单表，重新运行内联聚合，并生成一个数字。这三个数字并不匹配。没人注意到这一点，因为它们从未被放在一起记录过。

这就是特征工程（feature engineering）。智能体在每一轮对话中都在进行特征工程，而且是用自然语言进行的，其表现甚至不如十年前那些会被你在代码审查（code review）中嘲笑的流水线。

机器学习领域已经解决了这个问题。解决方案被称为特征存储（feature store），它所强制执行的纪律——计算一次特征、为其命名、对其进行版本控制、一致地提供服务——正是当你交给智能体一个数据库工具时，它立即抛弃的纪律。你的智能体并没有避免构建特征流水线。它构建了一个，只不过它构建的是整栋楼里最烂的一个。

你在周二发布了一个更好的内存格式。新架构将自由形式的 summary 字符串拆分为结构化字段 —— entities、preferences、last_verified_at —— 因为旧的 blob 难以检索且无法干净地更新。这个改动显然是正确的。它通过了评审，并上线了。

你没有注意到的是，周二之前写入的每一条内存现在都微妙地出错了。有些记录仍保留旧的 summary 字段而没有 entities，因此现在以 entities 为键的检索代码会跳过它们。还有一些记录的 summary 被新解析器解释为空的偏好集。智能体没有崩溃。它只是悄悄地遗忘了积累了一年的上下文，而且没有人提交 Bug，因为看起来并没有什么坏掉 —— 智能体依然在回答，只是表现变差了。

向量索引感觉就像一个数据库。你向其中写入文档，查询它，它返回结果。但它并不是数据库——它是存储在其他地方的数据的“派生、非规范化副本”。你的事实来源是 wiki、工单系统、CRM 或 PDF 文件夹。嵌入 (embeddings) 是这些事实的投影，冻结在你运行摄取任务 (ingestion job) 的那一刻。

这使得你的向量索引变成了一个缓存。就像所有缓存一样，它会失效。不同之处在于，大多数团队是有意识地构建缓存层，带有 TTL 和失效钩子 (invalidation hook)，而几乎没有人会有意识地将向量索引作为缓存来构建。他们将其构建为“知识库”，然后在它提供三周前就已经过时的知识时感到惊讶。

你的 RAG 系统存在一个不会抛出异常的 Bug。它不会拉高错误率，不会在延迟仪表盘上留下痕迹。相反，它会悄悄地给出听起来自信、合理却错误的答案——而没有人在数周内察觉。

这就是 RAG 中的数据契约问题：你的摄取管道是下游所有环节的事实来源，但它没有 Schema 校验、没有新鲜度保障，也没有在外部世界的形态悄然改变时发出告警。每当上游数据源新增字段、分块参数发生偏移，或者嵌入模型被更新，检索质量就会无声地退化。

80% 的企业级 RAG 项目在生产环境中会遭遇严重故障，而其中最隐蔽的那些故障从不宣告自身的存在。

AI 功能拥有仪表板。提示词（Prompt）有版本控制。评估套件（Eval suite）有轮值表。然后是一个写于 2022 年的上游定时任务（cron job），由一个在两次重组前就退出了分析部门的团队负责，它生成了构建你的检索索引所需的 CSV 文件。那个定时任务没有 SLA。那个 CSV 没有 Schema 契约。负责它的团队根本不知道它正在为一个 AI 功能提供数据。当它发生变化时——它一定会变——AI 团队将花费三周时间去调试一个完全没有出错的提示词。

你即将追踪的 AI 质量回退几乎从来不是 AI 问题。它是一个穿着 AI 外衣的 ETL 问题。需要落实的规范是两者之间的衔接点——契约、血缘（lineage）、新鲜度信号、成对的轮值——而没有将其正式化的团队，所交付的 AI 功能的可靠性将受限于公司里最不受待见的定时任务。

两年前，一个团队将他们的检索索引指向了 Wiki、Zendesk 导出文件以及公共文档的快照。上周，同一个索引返回了一个已弃用的运行手册（runbook），告诉 SRE 去重启一个已不存在的服务。该运行手册已经废弃了 18 个月。没人负责它的下线工作，所以没人把它删掉。Agent 自信地引用了它。模型没有错；错的是语料库（corpus）。

这是检索评估（retrieval evals）中不会出现的故障模式：语料库被视为一次性的工程决策，而实际上它是一个持续的治理问题。负责初始摄取（ingestion）的团队早已解散。本应标记出客户机密 PDF 的法律审查从未发生，因为没人告诉法务部门存在这个流水线（pipeline）。“新鲜度策略”（freshness strategy）只是一个在第三季度离职的人留下的 Slack 消息。检索索引变成了任何人抓取过的每一份文档的共享收件箱，而纳入标准已逐渐演变为“任何容易摄取的内容”。

这个方案听起来很诱人：将遗留记录输入 LLM，描述目标 Schema，让模型自行找出字段映射。无需手写解析器，无需数月的转换逻辑，也不依赖领域专家。已有团队实践后，在传统 ETL 所需时间的一小部分内达到了 70–97% 的准确率。问题在于，剩余 3–30% 的失败不像失败——它们看起来像是正确的数据。

这种不对称性——错误输出在结构上是合法且合理的——才是让 LLM 驱动的数据迁移在没有正确验证架构时真正危险的根源。本文介绍了那些成功落地的团队实际构建了什么：LLM 在流水线中的适用场景、它静默出错的地方，以及能捕获传统工具无法发现的错误的验证层。