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

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

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

为什么管道而非聊天机器人才是真正的业务负载

直觉很简单：聊天机器人按需一次为一个用户服务，且有处于回路中的人类（human in the loop）能立即发现胡言乱语。而批处理管道在夜间针对成千上万条记录运行，没有人类审查员，生成的输出默默流向下游数据库和仪表板。

团队从显而易见的收益开始：从格式变化过于频繁、模板解析器无法处理的 PDF 中提取结构化字段；当分类法（taxonomy）不断变化时，按类别对产品描述进行分类；在源数据是自由文本字段的情况下规范化地址数据。对于基于规则的系统来说，这些确实很难。LLM 自然地处理了这些变异。第一个管道在测试中表现良好，并得到部署，然后默默地积累起无人追踪的错误。

失败模式并不戏剧化。一个在第一季度准确率为 92% 的分类模型，随着输入记录分布的变化，到第三季度准确率可能会漂移到 84%。没有人注意到这一点，因为没有可以对比的基准真相（ground truth）。下游分析团队开始看到奇怪的模式。有人提交了一个 bug。经过三周的调查，最终发现根源是一个 Prompt，它假设了某种特定的记录格式，而供应商在六个月前就停止使用该格式了。

德勤（Deloitte）2024 年的一项调查发现，38% 的商业高管曾根据 AI 生成的输出做出错误的战略决策，这些输出后来被发现包含错误。在批处理管道的世界里，这些错误在大规模累积并浮出水面之前是无声无息的。

质量衡量难题

在批处理管道中运行 LLM 最难的部分不是 Prompt 工程或基础设施，而是你通常没有基准真相。

对于分类任务，你可以生成标注样本并衡量准确率。但以有意义的规模生成该样本成本很高，因此团队通常在启动时做一次，声明管道良好，然后就继续下一步。他们不会在每个季度输入分布变化、模型更新或上游数据架构更改时重新生成该样本。

有一些无需持续人工标注即可衡量质量的实用策略：

LLM-as-a-Judge 评估。在输出样本上运行第二个模型，让其根据输入评估提取或分类是否合理。这不能取代基准真相，但它能捕捉明显的退化：与输入相矛盾的输出、缺失必填字段、格式违规。

行为异常检测。对管道进行插桩，以跟踪输出值随时间的分布。如果一个通常将 40% 的记录分配给类别 A 的分类管道突然分配了 70%，那么说明发生了某些变化 —— 要么是输入分布，要么是模型行为。在未经调查的情况下，这两者都是不可接受的。

交叉验证。对于可以通过多种方式推导的字段 —— 例如，提取的公司名称也可以在现有数据库中查找 —— 实施独立验证。LLM 提取与查找结果的一致性确认了结果；不一致则标记为待审查。

基于风险的采样。与其随机审查 1% 的输出，不如将审查精力投入到风险最高的地方。对于提取财务数据的管道，对具有高下游价值或异常特征的记录进行不成比例的采样。

核心见解是，“我们在启动时测试过，它运行良好”对于一个持续运行且面对不断演变的数据系统来说，并不是一种质量策略。批处理 LLM 管道的质量测量需要是持续性的，而非一次性的。

无人规划的成本问题

批处理管道与 LLM 成本的交互方式不同于交互式应用，大多数团队在设计时没有正确建模。

朴素的计算方法：取每 Token 价格，乘以每条记录的平均 Token 数，再乘以记录总数。由于以下几个原因，这得到的估计值通常比实际成本低 3-10 倍。

输出 Token 的成本比输入 Token 高出 4-5 倍。一个从文档中提取结构化 JSON 的管道会产生显著的输出成本，而不仅仅是输入成本。在迁移到更丰富的 Schema 时，那些使用简短提取进行原型设计的团队严重低估了这一乘数。

模型选择是最高杠杆的成本决策。经济型模型（Haiku、GPT-4o-mini、Gemini Flash）的成本比旗舰模型低 15-50 倍。对于分类和简单的提取，质量差异通常可以忽略不计。行之有效的模式是：将所有流量默认发送到最便宜的模型，对输出进行置信度评分，仅将低置信度的记录升级到旗舰模型。在实践中，70-80% 的记录永远不需要升级。

批处理 API 折扣未被充分利用。每个主要供应商都为异步批处理提供 50% 的成本降低。如果你的管道没有严格的延迟要求 —— 大多数夜间批处理管道都没有 —— 那么没有理由不使用批处理 API。这纯粹是一个调度和集成问题。

Prompt 缓存对于具有长系统提示词或固定上下文的管道至关重要。当相同的长指令块作为每条记录的前缀时，缓存该前缀可显著降低成本和延迟。像 Anthropic 这样的供应商在 API 级别实现了这一点；对于其他供应商，语义缓存层可以达到类似的效果。一项分析发现，在正确配置缓存的情况下，高重复工作负载的成本降低了 73%。

Prompt 中的 Token 浪费很容易被忽视。一个在返回 JSON 提取之前要求模型“逐步思考”的提示词，正在为你不需要的推理 Token 付费。具有约束解码（constrained decoding）的结构化输出模式直接产生提取结果，而无需思维链开销 —— 而且由于它们在数学上约束了输出格式，实际上更加可靠。

架构决策：是否使用 LLM

在 LLM 驱动的数据流水线中，最重大的工程决策不是使用哪个模型，而是哪些任务根本应该使用模型。

这种区别通常被表述为“结构化 vs. 非结构化数据”，但这并不准确。更好的视角是：这项任务是否需要理解与解释？

在以下场景使用传统代码：

• 按字段值过滤记录
• 基于已知键进行表连接
• 计算派生指标
• 映射关系确定时的架构映射（Schema mapping）
• 通过精确或近精确匹配进行去重
• 格式已知时的格式标准化（电话号码、日期、货币）

在以下场景使用 LLM：

• 从布局随源而异的文档中提取字段
• 当分类体系涉及语义判断而非关键词匹配时进行记录分类
• 来源真正自由且变化无限的数据标准化
• 识别文本中实体间的关系
• 为人工复核生成摘要或描述

在以下场景使用混合方案：

• 任务大部分是确定性的，但存在长尾边缘案例 —— 对确定性路径使用传统代码，并将边缘案例升级交给 LLM 处理
• 流水线分为两个阶段，第一阶段过滤大量记录，第二阶段对较小子集进行更深入的分析 —— 先进行低成本过滤，再进行高成本分析

ELT-Bench 引用的基准测试让这种复杂性变得具体：在端到端 ETL 流水线生成任务中，表现最好的 AI Agent 仅正确完成了 3.9% 的数据模型，平均每个流水线耗时 89 个步骤，成本为 4.30 美元。全自动 ETL 生成距离生产就绪还很遥远。但在人工设计的流水线中，针对特定的子任务使用 LLM —— 这才是真正取得成效的地方。

真正能发现问题的监控

标准的数据流水线监控（行数、架构验证、空值率）对于 LLM 驱动的流水线是必要的，但还不够。你还需要：

输出分布追踪。 存储分类输出或提取值随时间变化的分布情况。即便没有架构错误且行数看起来正常，分布的突然变化也是一个值得调查的信号。

置信度得分追踪。 如果你正在使用模型置信度得分或 LLM-as-a-Judge 评估，也要追踪这些分布随时间的变化。置信度逐渐趋向低迷通常预示着可见的质量退化。

输入分布监控。 追踪输入记录的特征 —— 长度分布、词汇偏移、结构模式。当输入分布发生漂移时，你的流水线在该分布上的表现可能不再符合你在初始验证期间测得的数据。

显式数据契约。 对于消费其他 LLM 系统输出的流水线，应将这些输出视为外部 API：用架构验证它们，检查预期的取值范围，并在违反契约时响亮地报错，而不是将畸形数据传给下游。

做得好的公司会以对待事务性数据库同样的运营纪律来对待他们的批处理 LLM 流水线：为数据新鲜度设立 SLA、为质量退化设置告警，并对地面真值（ground-truth）样本进行定期审计。这种严谨程度听起来理所应当，但很少有团队在发布时真正落实。

季度审计协议

由于批处理流水线在运行时没有持续的人工复核，因此需要定期的质量干预。最小可行版本包括：

• 每季度：从近期流量中重新生成 200–500 条记录的打标样本。对照标签衡量准确性。将其与发布时的基准以及上季度的结果进行比较。
• 每次模型更新时：在切换到新模型版本之前，重新运行打标样本。将模型更新视为一个潜在的破坏性变更（breaking change），而不是一次免费升级。
• 每次上游架构变更时：将其视为触发器，立即对消费这些字段的任何流水线进行重新验证。
• 每次下游分析团队提交异常 Bug 时：通过流水线追溯根因。你会发现，根因出现在 LLM 提取或分类层的情况比你预想的要多。

这不是什么光鲜亮丽的工作。这不是任何人开始用 LLM 构建系统时所憧憬的。但这正是能将一条在 18 个月内悄悄退化的流水线，与一条保持可靠的流水线区分开来的关键。

结论

LLM 在数据流水线中确实非常有用。它们所实现的提取和分类任务 —— 针对以前无法大规模处理的文档和记录 —— 代表了三年前尚不具备的真实能力。从中获得价值的团队并不是那些使用最复杂模型的团队。而是那些严谨对待哪些任务真正需要 LLM、每条记录的成本是多少，以及流水线是否仍保持着初始验证时的准确性的团队。

下一代数据基础设施基准测试需要以对待查询引擎和流处理器同样的严肃态度来衡量 LLM 流水线。在那之前，仔细监测自己流水线的团队将比那些“部署后就撒手不管”的团队拥有显著优势。