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）：将模型版本视为依赖项，而不是浮动指针。每个主流供应商都提供版本固定功能。当供应商升级基础设施时，未固定的模型可能会悄然改变输出分布。

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

加载中…