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

加载中…