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

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

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

这篇文章探讨了在数据流水线中引入 LLM 的工程现实：它们取代了什么，在何处会失败，如何使它们的输出可靠，以及为什么由此产生的数据飞轮在结构上难以被复制。

LLM 在传统 ETL 流水线中取代了什么

传统的 ETL 流水线处理四个核心操作：从源提取记录，转换记录（分类、丰富、规范化、去重），验证输出，以及加载到目的地。这些操作中的每一个都有经典的实现方式，也都有经典实现失效的瓶颈。

分类（Classification） 通常意味着正则规则或经过训练的分类器。当类别改变时，规则会失效。当遇到未经训练的类别时，分类器会失效。LLM 可以同时处理这两者：你可以使用平实的语言描述，在零样本（zero-shot）的情况下，将记录分类到模型训练时并不存在的分类体系中。Shopify 每天使用视觉语言模型运行 3000 万次产品分类预测，涵盖 26 个垂直领域的 10,000 多个类别，商家采纳率达到 85%。他们不会为新类别重新训练分类器——而是描述它们。

丰富（Enrichment） 通常意味着与查找表进行连接、运行正则提取器或针对每个字段类型调用专门的 API。这在自由文本字段上会失效。LLM 将任意文本转换为结构化元数据：提取实体、分配情感、推导规范化数值、推断意图。MotherDuck 发布了一个 prompt() SQL 函数，可以按行应用 LLM 丰富功能并支持自动批处理——可直接在 dbt 模型中使用。你编写 SQL 查询；LLM 填充丰富列。

实体解析（Entity resolution，即去重） 通常使用字符串编辑距离和分块规则（blocking rules）。这在名称变体、缩写和跨语言等价物上会失效。根据 2024 年的一项 ACM 研究，LLM 配合基于嵌入（embedding）的近似最近邻分块技术，在处理未知实体类型时，其性能比经过微调的基于 BERT 的系统高出 40–68%。其模式是：使用嵌入进行候选分块以保持问题的可处理性，然后使用 LLM 进行两两消除歧义。

非结构化到结构化的转换——将 PDF、电子邮件和工单转换为类型化记录——在经典方法中没有对应物。它过去需要为每种格式编写自定义解析器，或需要大量的标记人员。LLM 以极高的速度将非结构化文档转换为结构化记录，使得人工审核在经济上仅对抽查可行，而不是作为主要路径。

可靠性问题：在确定性流水线中放入随机模型

难点不在于让 LLM 在流水线中工作，而在于让它们安全地失败。

经典 ETL 有一个令人舒适的特性：给定相同的输入，你会得到相同的输出。流水线就是建立在这种假设之上的。将 Temperature=0 的 LLM 调用虽然减少了方差，但并不能消除它——而且模型版本升级、供应商端的基础设施变更以及提示词（prompt）的变化都会在无预警的情况下改变输出分布。静默失败（Silent failures）是最危险的情况：LLM 返回了结构上有效但语义上错误的响应，下游系统在没有任何错误信号的情况下摄取了损坏的数据。

能在生产环境中存续的工程模式是“双层验证三明治”：

1. 结构验证（Structural validation）：在解码层面强制执行模式（schema）。原生的结构化输出 API（如 OpenAI、Anthropic）和受限解码（constrained decoding）可以在你看到错误之前消除解析错误。这是必选项——仅通过提示词实现的 JSON “模式”会产生各种富有创意的变体（如尾随逗号、包裹 Payload 的 Markdown 代码块），从而导致真实流水线中的解析器崩溃。

2. 语义验证（Semantic validation）：结构一致性是必要条件，但并不充分。一个包含 {"confidence": "medium"} 或 {"status": "complete", "result": null} 的响应是有效的 JSON，但在语义上是错误的，没有任何类型检查器能捕获这一点。Instructor 库（每月超过 300 万次下载）通过将 Pydantic 验证错误作为上下文传回给 LLM 并自动重试来处理这一问题。这实现了闭环：模型看到自己错在哪里并进行纠正。

除了验证层之外，还有三种操作模式能让 LLM 流水线步骤表现得更像确定性转换：

• 幂等键（Idempotency keys）：在写入下游之前，将 LLM 的输出记录到持久化存储中。如果流水线在运行中途重启，你从日志中重放，而不是重新调用 LLM。
• 断路器（Circuit breakers）：对每条记录的成本和轮次进行硬限制。如果没有这些限制，递归模式可能会导致 API 成本从每周 127 美元飙升至 47,000 美元——这是一个真实的生产事故，由于流水线没有成本上限，导致事故在未被检测的情况下蔓延。
• 固定模型版本（Pinned model versions）：将模型版本视为依赖项，而不是浮动指针。每个主流供应商都提供版本固定功能。当供应商升级基础设施时，未固定的模型可能会悄然改变输出分布。

成本与延迟：批处理何时胜过实时

人们对 LLM 进入流水线的反射性担忧是延迟。这种担忧通常是被错置了。

分类、富集、去重和文档解析并不需要实时延迟。夜间的富集运行、每小时一次的批处理作业、事件驱动的回填——这些任务都没有人类在同步等待。使用批处理推理 API 与实时推理相比可以降低 50% 的成本，通过优化的并行化实现更高的吞吐量，且大多数作业在不到一小时内即可完成。

Prompt 缓存进一步放大了这些节省。对于那些记录共享通用系统 Prompt 或模式定义（几乎总是如此）的流水线，缓存共享前缀可将输入 Token 成本降低多达 90%。一个将 Prompt 缓存应用于分类流水线的团队，在不更改任何其他内容的情况下，将 LLM 成本削减了 59%。

数据流水线真正的成本指标不是单 Token 成本，而是“单条成功转换记录的成本”。在这个层面，当你考虑到维护规则系统和重新训练分类器的工程时间时，LLM 增强型流水线的总成本通常低于其他替代方案。

在极端规模下——例如 DoorDash 每天进行 100 亿次预测——无论如何优化，基于 API 的 LLM 在经济上都是不可行的，此时的答案是自托管的微调模型。但大多数团队并未达到那个规模，在数字迫使你做出不同决定之前，基于 API 的批处理推理是正确的默认选择。

哪些环节会出问题：上线生产后的陷阱

LLM 流水线演示与生产级 LLM 流水线之间的差距比看起来要大。常见的失败模式包括：

静默数据损坏比崩溃更糟糕。 报错退出的流水线是立即可见的。而一个静默地向分析数据库写入错误分类的流水线，可能在运行数周后才有人注意到仪表板是错误的。置信度门控（Confidence gating）——丢弃或标记低于阈值的记录，而不是接受所有输出——是第一道防线。

多步流水线中的上下文腐烂。 无论模型标称的上下文长度是多少，一旦超过 50,000–150,000 个 Token，LLM 的性能就会出现明显的下降。长期运行的、会累积上下文的 Agent 富集流水线会触及这个天花板。解决办法是即时上下文注入：只传递与当前步骤相关的信息，而不是累积至今的所有信息。

Prompt 的脆弱性。 微小的 Prompt 更改会导致输出分布的巨大偏移。一个在预发布环境中运行良好的流水线在生产环境中崩溃了，原因可能只是有人为了改进一个字段而编辑了系统 Prompt，却无意中改变了另一个字段。这里的纪律与代码纪律相同：将 Prompt 视为带有版本的工件，对每次更改运行评估（Evals），并且不要在升级模型版本的同一天发布 Prompt 更改。

80/95 问题。 将流水线质量提升到 80% 很快。但剩下的 15% 到达生产就绪水平——处理边缘情况、特定领域失败模式、分布偏离的极端案例——所花费的时间与前 80% 一样长。那些在流水线达到 80% 水平时进行基准测试并宣布生产就绪的团队，会以惨痛的方式发现这一点。在承诺交付日期之前，为长尾情况预留充足的时间。

数据资产飞轮

LLM 增强型流水线的运营效率是真实存在的，但它是次要的。主要的战略价值在于这些富集后的记录为下游带来的可能性。

每条经过 LLM 富集的记录都是一个带标签的样本。当拥有 50,000–500,000 个高质量的带标签交互（阈值因领域而异）时，微调后的小模型在特定任务上的表现会大幅超过任何通用 API，且成本仅为后者的一小部分。今天富集记录的团队正在生成训练数据，使他们的下一代模型具有领域特定性且运行廉价。而那些仅将 LLM 视为产品功能的团队虽然生成了用户交互，但并没有产生这种闭环所需的结构化、带标签的数据集。

反馈循环是单向叠加的。更丰富的富集数据集能带来更准确的下游模型、更好的检索和更可靠的 Agent 行为。每一次改进都会解锁下一次。12–24 个月后，专有的富集数据集和微调模型将创造出巨大的切换成本，这是通用型竞争对手无法通过接入同样的顶级 API 来克服的。

这就是构建 AI 功能的团队与构建 AI 驱动的数据资产的团队之间的结构性差异。产品功能是可见且可复制的。而富集的数据集是不可见的、专有的，且是通过实际运营积累起来的——这使得它更难被模仿。

从何处开始

务实的切入点是选择一个目前处于脆弱规则系统中或需要人工审查的分类或富集任务，并用验证层背后的批处理 LLM 调用来替换它。

从批处理开始，而不是实时。使用结构化输出 API，而不是要求生成 JSON 字符串。从第一天起就添加带有自动重试机制的 Pydantic 校验——后期改造比看起来要难。固定你的模型版本。添加置信度门控，将低置信度记录路由到人工审查队列，而不是静默接受它们。

为流水线添加监控，以跟踪单条记录成本、校验失败率和置信度分布。这三个指标可以告诉你流水线是否健康，以及在哪里投入优化精力。

从基于规则的 ETL 向 LLM 增强型 ETL 的迁移不是一个一蹴而就的项目。这是一系列的小规模替换，每一次替换都能提高数据质量并减轻维护负担，从而逐步将脆弱的规则系统转化为灵活的、自我修正的流水线。在 2025–2026 年系统性开展这项工作的团队不仅是在削减成本——他们正在构建使 2028 年的模型无法被复制的数据基础设施。

数据流水线中发生的这场悄无声息的变革，值得获得比现在更多的关注。