跳到主要内容

7 篇博文 含有标签「validation」

查看所有标签

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

· 阅读需 11 分钟
Tian Pan
Software Engineer

这个方案听起来很诱人:将遗留记录输入 LLM,描述目标 Schema,让模型自行找出字段映射。无需手写解析器,无需数月的转换逻辑,也不依赖领域专家。已有团队实践后,在传统 ETL 所需时间的一小部分内达到了 70–97% 的准确率。问题在于,剩余 3–30% 的失败不像失败——它们看起来像是正确的数据。

这种不对称性——错误输出在结构上是合法且合理的——才是让 LLM 驱动的数据迁移在没有正确验证架构时真正危险的根源。本文介绍了那些成功落地的团队实际构建了什么:LLM 在流水线中的适用场景、它静默出错的地方,以及能捕获传统工具无法发现的错误的验证层。

生产环境中的结构化输出可靠性:为什么 JSON 模式并非契约

· 阅读需 9 分钟
Tian Pan
Software Engineer

一个团队发布了一个文档提取流水线。它使用了 JSON 模式。QA 通过了。监控显示解析错误接近于零。六周后,一个隐蔽的失败浮出水面:语料库中的每一份风险评估都被标记为 “低” —— JSON 格式有效,字段名称正确,但答案是错的。该流水线已经在以符合架构(Schema)的格式自信地撒谎了好几周。

这是将 JSON 模式视为可靠性保证的核心问题。结构一致性(Structural conformance)和语义正确性(Semantic correctness)是系统的不同属性,混淆两者是生产级 AI 工程中最代价高昂的错误之一。

结构化输出不等于结构化思维:大多数团队跳过的语义验证层

· 阅读需 11 分钟
Tian Pan
Software Engineer

一个医疗排班系统从其 LLM 提取层收到了一个合法的 JSON 对象。Schema 验证通过,类型检查通过,必填字段齐全。然而,当下游任务尝试预约时,却发现 end_timestart_time 早了三个小时。两个字段都是格式正确的 ISO 时间戳,没有任何一个违反 schema。预约悄悄失败,患者没有收到任何通知——没有错误,没有告警。

这就是当 schema 验证被误以为是正确性验证时的样子。模型遵循了格式,却没有遵循逻辑。

Schema 问题:在生产环境中驯服 LLM 输出

· 阅读需 11 分钟
Tian Pan
Software Engineer

你上线了一个功能,使用 LLM 从用户文本中提取结构化数据。你进行了彻底的测试。它工作正常。三个月后,模型提供商悄悄更新了权重,在没有修改任何代码的情况下,你的下游流水线开始静默丢弃记录。没有抛出异常。没有触发报警。只是错误的数据在系统中流动。

这就是 Schema 问题。尽管结构化输出 API 已经改进了多年,它仍然是 LLM 驱动的系统中最少被讨论的故障模式之一。

语义验证层:为什么 JSON Schema 不足以应对生产环境中的 LLM 输出

· 阅读需 12 分钟
Tian Pan
Software Engineer

到 2025 年,每家主流 LLM 服务商都已推出结构化输出的受约束解码功能。OpenAI、Anthropic、Gemini、Mistral——它们都允许你向模型传入一个 JSON Schema,并保证返回结果在结构上完整无误。各个团队纷纷采用这一功能,长舒一口气:解析错误消失了,重试循环缩短了,监控面板一片绿色。

然后,微妙的故障开始出现。

一个情感分类器在两周内对每个输入——包括乱码——都锁定在 0.99 的置信度,无人察觉。一个信贷风险智能体返回了合法的 JSON,批准了一笔本应被拒绝的贷款申请,风险分数高出了五十分。一条金融数据管道将 "$500,000"(字符串,技术上符合 Schema)强制转换为整数字段中的零,破坏了六周的风险计算数据。这些故障全部通过了 Schema 验证。

教训是:结构有效性是必要条件,但并不充分。你需要一个语义验证层,而大多数团队并没有这一层。

JSON 模式救不了你:生产环境 LLM 系统中的结构化输出故障

· 阅读需 11 分钟
Tian Pan
Software Engineer

当开发者第一次接入 JSON 模式时,响应结果感觉就像解决了一个大问题。LLM 不再返回 Markdown 围栏、文字道歉或靠近花括号的乱码。输出可以解析了,测试通过了,生产环境上线了。

然而,三周后,一个后台作业悄无声息地失败了,因为模型在 Schema 要求 {"status": "completed"} 时返回了 {"status": "complete"}。由于一个必填字段返回了 null 而不是被省略,数据流水线崩溃了。智能体工具调用循环(agent tool-call loop)提前终止,因为模型在字符串值中嵌入了一个异常换行符,导致下游解析器卡死。

JSON 模式保证了语法上有效的 JSON。它并不保证该 JSON 的含义与你的预期一致,不保证它包含你的应用程序所期望的字段,也不保证在多次请求之间保持语义一致性。这些是不同的问题,需要不同的解决方案。

生产环境中的结构化输出:让 LLM 返回可靠的 JSON

· 阅读需 10 分钟
Tian Pan
Software Engineer

在生产环境中的某个阶段,每个由 LLM 驱动的应用都需要停止将模型输出视为散文,而开始将其视为数据。当你尝试从语言模型中可靠地提取 JSON 对象——并将其输入到下游的数据库、API 调用或 UI 中时——你会发现这有多少种出错的方式。模型会将 JSON 包裹在 Markdown 栅栏中。它会生成一个有效的对象,但遗漏了必填字段。它在多次调用中格式化日期的格式不一致。它会幻觉出枚举值。这些失败中的任何一个都会静默地破坏下游状态。

结构化输出已经从一个事后才考虑的问题演变成生产级 LLM 系统的一等公民。这篇文章介绍了强制执行结构化输出的三种主要机制、各自失效的场景,以及如何在约束下设计高质模式(Schema)。