跳转到主要内容
TianPan.co Logo

你的 AI 功能可靠性受限于无人负责的上游 ETL 流水线

阅读需 1 分钟Tian PanTian Pan
insider
data-engineering
etl
ai-reliability
data-contracts
observability

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

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

隐形的依赖​

AI 功能是一个流水线。这条流水线的最后 20%——提示词、模型、评估框架（eval harness）——是工程投资集中的地方，也是每次复盘开始的地方。而前 80%——摄取任务、规范化步骤、去重处理、每日快照、从第三个上游系统合并进来的列——是在任何人在会议中提到“Agent”这个词之前就构建好的。它由那些认为自己拥有的是一个面向分析用户的数仓的人负责。他们不知道下游有一个 LLM。

这种不可见性就是故障模式。数据团队像对待 Tableau 后端一样对待他们的流水线：重命名一个列是常规清理，每日运行延迟到隔天运行是可接受的降级，Schema 的“改进”只是在 Slack 的分析频道发个通知。这些沟通都没有传达到 AI 团队，因为 AI 团队从未被注册为消费者。没有任何契约规定嵌入（embedding）流水线依赖于 customer_segment 是字符串而不是整数。没有任何消费者注册表会在下游 RAG 索引读取数据团队的输出时向他们发送告警。

与此同时，AI 团队将上游视为绝对真理。他们的评估是针对过去某个时间点拍摄的数据快照进行的。他们的检索之所以有效，是因为列都在他们预期的位置。他们的微调是在他们假设平稳的分布上训练的。每一个假设都是一份从未签署的契约，而上游团队今天下午就可以随意违反其中的每一项，因为没有人告诉过他们自己曾经达成过任何协议。

被记录为“模型回退”的故障模式​

这种模式重复得如此频繁，以至于几乎成了一种典型。AI 团队注意到每周评估中的质量下降了四个百分点。延迟正常，错误率正常，模型版本没变，提示词也没变。他们花了一周时间调整提示词。又花了一周尝试不同的分块（chunking）策略。第三周对检索流水线进行消融实验。最终，有人将一批糟糕的输出追溯到某个特定文档，找到了该文档，查看了它最后一次摄取的时间，发现上游流水线在两周前开始过滤掉某一类记录，原因是进行了一次“无害的清理”，删除了标记为“内部”的记录。而该 AI 功能正依赖于这些记录。

第二种模式：上游流水线开始输出精度不同的列。以前是以毫秒为单位的时间戳，现在变成了秒。检索层原本使用时间戳来解决相关性排名的冲突。突然间，冲突解决变得不可预测，同样的查询在不同的日子返回不同的文档，评估套件开始出现波动。模型没问题。检索没问题。数据差了一个小数点。

第三种：由于缩减成本的计划降低了非关键任务的优先级，上游流水线的运行频率从每小时降到了每天。RAG 索引现在有长达 24 小时的滞后。AI 功能开始用落后一天的数据回答关于“最新”信息的问题。没有任何地方触发告警——流水线运行成功，索引更新成功，模型响应成功——唯一的信号是客户满意度在一个季度内悄然下降。

第四种：上游流水线由于有人更改了数仓列类型，静默地将一个长字符串字段截断为 256 个字符。RAG 索引现在包含的分块（chunk）在每个长文档的后半部分都缺失了。检索仍然返回分块。只是分块是不完整的。模型基于不完整的上下文进行回答。幻觉率上升。团队归咎于模型。

在所有这些案例中，AI 团队的前三个假设都是关于模型的。这些假设没有一个是正确的。第四个假设最终指向了数据。数据几乎总是答案，而几乎从来不是人们首先寻找的地方。

会员专享

余下内容仅对会员开放。

会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。

  • 完整文章，包含未公开存档的部分
  • 可落地的工作框架，附带权衡与决策依据
  • 新文章抢先看，先于公开发布

随时取消 · 一次订阅，畅读全部

参考资料

保持联系，关注我获取更多内容

TwitterLinkedInTelegramDiscord小红书

相关文章

阅读需 10 分钟

LLM 驱动的数据流水线：那个没人做基准测试的 ETL 层

大多数 LLM 基准测试衡量的是聊天机器人的质量。但企业在 LLM 上的大部分支出其实都投入到了批量处理流水线中 —— 而几乎没有人去衡量这些流水线是否真的有效。

insider
data-engineering
阅读需 9 分钟

LLM 作为 ETL 原语：AI 不仅是产品功能，更是数据管道的核心

大多数团队都在产品中构建 AI 功能。而真正的变革正悄然发生在数据管道内部。在这里，LLM 大规模地对记录进行分类、增强、去重和路由——从而创造出那些仅关注产品的团队无法复制的复合数据资产。

insider
data-engineering
阅读需 10 分钟

RAG 数据契约问题：摄取管道如何悄然破坏检索质量

Schema 漂移、嵌入模型更新和过时文档可能在数周内悄然降低 RAG 检索质量，而不产生任何错误日志。数据契约和摄取层监控能在用户察觉之前阻止质量腐化。

insider
rag
阅读需 10 分钟

LLM 驱动的数据迁移：大规模实践中真正有效的方法

一篇面向工程师的实践指南，介绍如何使用 LLM 完成 Schema 迁移和 ETL 自动化——涵盖静默失败模式、分层验证架构、基于 Schema 的提示方式，以及何时不应用 LLM 替代传统流水线。

insider
data-engineering
阅读需 8 分钟

无法回滚的功能开关：提示词

提示词的修改会瞬间改变所有用户的生产环境行为，既没有金丝雀发布，也没有有效的回滚机制。本文将探讨提示词和模型版本固定为何脱离了发布规范，以及将其重新纳入规范的五个原语。

insider
llmops
返回所有帖子