Agentic 数据流水线：大规模离线富化与分类

你有一个批量任务，一夜之间可以对 1,000 万张客户支持工单进行分类。你将正则分类器换成了大语言模型（LLM），准确率从 61% 飙升至 89%。然后你上线了它，却发现：这项任务现在的成本增加了 40 倍，运行速度慢了 12 倍，当模型返回无法解析的输出时会静默跳过 3% 的记录，而且由于标签架构（label schema）在无人察觉的情况下发生了偏移，你的下游分析团队正在不断提交 Bug。

Agentic 数据管道的损坏方式是 ETL 工程师以前从未见过的，修复它们需要一套不同于传统批处理或实时 LLM 服务的思维模型。

核心设计转变：单条记录的可变计算量

传统的 ETL 有一个便利的属性：每条记录的处理成本大致相同。你可以通过将记录数乘以单条记录成本来预测任务时长、确定集群规模并设置成本预算。

Agentic 管道打破了这一属性。当 Agent 必须对一条记录进行推理时 —— 获取相关上下文、决定是否调用工具、迭代提取过程 —— 每条记录的计算预算就变成了一个分布，而不是一个常量。有些记录通过一次模型调用就能解决。而另一些则会触发三次工具调用、一个澄清循环和第二次提取尝试。处理相同架构的同一个管道，在不同数据集上的成本可能相差 2 倍，纯粹是因为数据处理起来更难。

这会带来具体的架构后果：

• 任务规模估算是概率性的。 如果不了解输入数据的复杂度分布，你就无法估算运行时间。上个月在 4 小时内完成的 1,000 万条记录的任务，在你为模糊案例添加推理步骤后，可能需要 11 小时。
• 成本上限需要针对单条记录进行限制。 如果没有针对单条记录的明确 Token 预算，一小部分复杂的记录可能会消耗掉任务成本的绝大部分。为单条记录设置最大 Token 上限；当超过上限时优雅地失败，而不是让少数极端案例耗尽预算。
• 并行计算的逻辑发生了变化。 批处理吞吐量取决于并发处理记录时的 GPU 利用率。如果 5% 的记录需要 10 倍的计算量，你要么在等待长尾记录时导致资源利用不足，要么就让它们拖慢整个批次。

实际的解决办法是在处理前根据预估的复杂度对记录进行分段。一个轻量级的预分类器（基于规则或小型、廉价的模型）将记录路由到快/慢车道。快车道以最大并发量并行运行。慢车道则在更严格的并发控制和明确的成本追踪下运行。这种模式 —— 而不是简单地将所有内容都投入到最大并行度中 —— 是让 Agentic 管道运行可预测而非产生账单冲击的关键。

将置信度阈值作为操作契约

在传统的分类器中，你有一个模型评分和一个阈值。高于阈值的记录被打上标签；低于阈值的记录被标记为待人工审核。这很常见。

在 Agentic 管道中，问题变得更难：当 Agent 产生分类结果时，谁拥有决策权？是 Agent 还是人工审核员？

答案不应该是 “始终是 Agent” 或 “始终路由给人工”。答案应该是你在管道设计时定义的层级化契约：

• 高置信度、低风险记录（产品类别打标、情感分类）：无需审核，自动提交
• 高置信度、高风险记录（欺诈标记、合规分类、医疗代码）：提交，但写入审计日志并进行强制抽样审查
• 低置信度记录（无论风险高低）：路由至人工审核队列

阈值不是魔法数字。它们应该根据你具体的模型和数据经验性地得出：在带有标签的保留集（holdout set）上运行管道，绘制不同置信度截断点下的精确率/召回率曲线，并在权衡结果符合你下游容忍度的地方设置阈值。一个在你特定任务上能达到 99.5% 精确率的 95% 置信度阈值，比通用的 “使用 0.8 置信度” 规则要有意义得多。

组织层面的陷阱是将置信度阈值视为一次性的校准。模型会漂移。数据分布会改变。由于进入管道的记录类型发生了变化， 1 月份设置的阈值到 7 月份可能已经严重失准符。将重新校准纳入你的操作节奏中，由以下情况触发：新模型版本、数据源更改或季度审查。

一个团队经常忽略的结构化细节是：将低置信度记录路由到审核队列，并将其反馈到你的训练集中。置信度边界边缘的人工审核记录是你所能获得的最具价值的训练信号。如果你正在进行任何形式的微调或 RLHF，这就是数据的来源。

面向下游消费者的架构设计

你的管道生成的结构化输出架构（schema）是一个分布式契约。每一个下游消费者 —— 仪表板、API、数据仓库、其他管道 —— 都依赖于它。由于架构是由 LLM 调用而不是确定性代码生成的，它失效的方式与传统架构不同。

原则 1：枚举类型优于自由文本字符串。 如果一个字段只能取有限的一组值，请在输出架构中将其声明为枚举（enum）。LLM 会自信地生成看似合理但错误的自由文本标签。它们很少会违反定义良好的枚举。这是你能做出的投资回报率（ROI）最高的架构设计决策之一。

原则 2：必填字段应在操作上是必需的。 诱惑是把所有字段都标记为必填。操作上的问题是，模型经常无法填充的必填字段会产生部分失败链：记录无法通过架构验证，被跳过，并静默消失。只有当某个字段的空值会破坏下游消费者时，才将其标记为必填。否则，请使用可为空（nullable）的类型，并为 Null 值制定明确的处理规则。

原则 3：将架构变更视为破坏性的 API 变更。 增加必填字段、删除字段或更改字段类型对于每个下游消费者来说都是破坏性变更。明确地对架构进行版本控制。维护变更日志（changelog）。在移除字段前给消费者一个废弃窗口。这是标准的 API 契约管理，但团队往往在 “内部” 数据管道中忽略它 —— 直到下游仪表板崩溃且无人知晓原因为止。

原则 4：包含溯源元数据。 每条增强后的记录都应携带描述其产生方式的字段：模型版本、提示词版本、置信度评分、处理时间戳和源记录 ID。这不是额外开销 —— 它是审计追踪，能让你调试下游异常，在模型更新后重新处理受影响的记录，并追踪哪些记录是由哪个管道版本生成的。

监控：模型不确定性 vs. 数据歧义性

在代理型数据管道（agentic data pipelines）中，最困难的监控问题是：当一条记录返回低置信度时，究竟是模型在处理清晰记录时表现挣扎，还是该记录本身就存在歧义？

这两种情况从外部看完全一样——都会产生低置信度评分——但它们需要不同的应对措施：

• 清晰数据上的模型不确定性是一个信号，表明模型需要重新训练、提示词（prompt）需要改进，或者该记录包含了模型尚未见过的边缘案例。修复工作的重点在你这一侧。
• 数据歧义性意味着记录本身就不清晰——存在多个合理的标签、源数据相互矛盾，或者任务规范没有涵盖这种情况。在模型层面上可能无法修复。

如果你混淆了这两者，就会将真正具有歧义的记录路由到人工审核队列中。审核员会难以达成共识，从而产生低质量的标签，降低你的训练数据质量。针对大语言模型（LLM）不确定性量化的研究证实，当在故意设置的歧义输入上进行测试时，当前的方法无法可靠地区分这些类别。

实际的区分策略：

• 测量审核队列中的标注者间一致性（inter-annotator agreement）。 如果人工审核员在某条记录上的分歧率与模型一致，那么该记录就是真正的歧义记录。请将这种测量机制集成到你的审核工具中。
• 按数据分段跟踪校准曲线（calibration curves）。 如果特定数据分段的置信度评分未校准（高置信度，错误答案），这指向的是模型在特定分布上的不确定性，而非数据歧义性。
• 使用辅助信号。 跨源不一致（同一个实体在两个源系统中标注不同）、模式不完整（缺失输入字段）以及异常特征值都是数据质量问题的指标，而不是模型故障。在 LLM 步骤之前建立这些检查，并在处理前给记录打上数据质量信号的标签。

一个代理型数据管道的监控仪表盘应该为每次管道运行显示：置信度评分分布、各层级路由百分比（自动提交 / 审计 / 审核）、模式验证失败率，以及——在有标注真值（ground truth）的情况下——按置信度分桶拆解的精确率（precision）和召回率（recall）。当置信度分布发生偏移或路由百分比发生意外变化时，你就能在下游消费者察觉之前获得早期信号。

局部故障恢复

批处理任务会失败。任务期间的网络分区、模型 API 的速率限制、意外记录格式导致的模式验证失败——任何这些情况都可能导致任务中途停止。关键问题在于，你是可以从中断处恢复，还是必须重新处理所有内容。

从一开始就为检查点（checkpointing）而设计：

• 一次性写入中间状态。 在处理记录时，将结果写入以源记录 ID 为键的中间存储（对象存储、数据库暂存表）。在处理任何记录之前，先检查结果是否已存在。这使得局部重新运行在默认情况下是安全的。
• 区分瞬态故障与永久故障。 模型 API 超时是瞬态的——应使用退避算法（backoff）进行重试。针对特定记录的模式验证失败是永久性的——记录日志、跳过该记录，并在任务摘要中报告，而不要阻塞批处理的其余部分。
• 报告故障粒度。 任务级的成功/失败指标隐藏了单条记录的失败率。一个“成功完成”但跳过了 2% 记录的任务实际上并未完成。跟踪并报告失败记录 ID 的确切集合，以便操作人员进行检查，并决定是否需要重新处理。

这种运行模式是：每个批处理任务产生三个输出——增强后的记录、带有失败原因的跳过记录日志，以及包含每种失败类型计数的摘要。只有当跳过的记录数量在定义的容差范围内时，任务才被视为完成。

总结

代理型数据管道绝非简单的“用 LLM 调用取代基于规则转换的 ETL”。每条记录的可变计算预算、嵌入置信度阈值的操作契约、结构化输出模式的分布式特性，以及模型与数据不确定性的区别，每一项都需要深思熟虑的设计选择，而这些是传统批处理工程所不涵盖的。

成功运行这些管道的团队将其视为分布式系统：在每一层都具备显式的故障模式、版本化契约、可观测状态和优雅降级路径。而不这样做的团队，其管道可能在周一运行良好，到周四就悄无声息地漂移并产生垃圾数据——直到下游仪表盘出现问题，才有人察觉。