跳转到主要内容

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

阅读需 2 分钟Tian PanTian Pan

关于生产环境中的 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

会员专享

余下内容仅对会员开放。

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

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

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

参考资料

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

阅读需 10 分钟

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

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

insider
data-engineering
阅读需 9 分钟

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

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

insider
data-engineering
阅读需 10 分钟

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

大多数 AI 质量退化实际上是伪装成 AI 问题的上游数据问题。数据契约、血缘关系和结对轮值机制能将隐形的 ETL 接缝转化为一等公民工件。

insider
data-engineering
阅读需 10 分钟

多区域 LLM 服务:没人警告过你的缓存局部性问题

在不同区域部署 LLM 推理会产生无状态 HTTP 服务所没有的一致性和延迟问题。本文将介绍一种既能解决这些问题,又不会让你的运维负担增加三倍的路由架构。

insider
llm
阅读需 8 分钟

不会崩溃的合成数据管道:大规模生成训练数据

模型崩溃会悄然降低在自身输出上训练的 LLM 的性能。了解累积混合、多源生成、验证堆栈和多样性监控等管道架构,让合成训练数据保持高效而非自我中毒。

insider
synthetic-data