5 篇博文 含有标签「etl」

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

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

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

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

你手写的 ETL 管道处理了 95% 的记录。那些边界情况——带有逗号的货币字符串、格式不一致的日期、不统一的国家代码——流向了你的数据仓库，并悄悄地破坏了你的仪表板。直到季度报告看起来不对劲时，才有人注意到。你又在管道中添加了一个特殊情况。循环往复。

LLM 可以解决这个问题。它们能从原始样本中推断模式（schema），处理任何工程师都预料不到的杂乱边界情况，并能以极短的开发时间将非结构化文档转换为结构化记录。已经有几个团队推出了这种方案。其中一些团队也经历过 LLM 悄无声息地将 "$1,200,000" 转换成 1200 而不是 1200000，在结构完全有效的情况下将严重程度分数从 "high" 切换到 "low"，以及以通过了所有模式检查的方式连接了错误的业务外键。

问题不在于 LLM 不擅长数据工程。而在于它们的失败模式对 ETL 来说恰恰是完全错误的：高置信度、不报错、且输出结构有效。

关于生产环境中的 LLM，大多数讨论都围绕着聊天界面、Copilot 和自主代理。但如果你审计企业 LLM Token 的实际消耗去向，你会发现一个完全不同的景象：绝大多数的使用都发生在批处理数据管道（batch data pipelines）中 —— 从文档中提取字段、对支持工单进行分类、规范化混乱的供应商记录、为原始事件添加语义标签。没有人为这个层级编写会议演讲，也没有人认真地对其进行基准测试。而这种沉默正让团队付出真金白银和准确性的代价。

这是从业者最先构建、最后辩护、且监控最少的 ETL 层级。对于大多数组织来说，这也是 LLM 支出杠杆率最高的一层，同时也是产生隐形失败潜力最高的一层。

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

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