让LLM输出可靠结构化数据的工程实践

一个返回漂亮段落的 LLM，对需要消费它的函数毫无用处。真正的系统不需要散文——它们需要数据。能够从模型中获取可靠的结构化数据，这才是将 demo 变成产品的关键能力。

"酷炫的 LLM demo"和"生产环境中的 LLM"之间的差距几乎总是在这里：demo 打印出供人类阅读的文本，而产品需要机器解析输出并据此行动。自由文本正是问题所在。以下是关闭这个差距的方法。

为什么自由文本在管道中失效

假设你让模型从一封支持邮件中提取客户姓名、订单号和问题。它愉快地回复："当然！客户是 Priya，她的订单是 4471，她反映的是商品破损。"对人类来说很不错。现在写代码来可靠地从这三个字段中提取数据——面对成千上万封邮件，模型每次的措辞都不同，有时加上前言，有时重新排序。你做不到。用正则表达式去匹配 LLM 的散文是一个你会一直维护下去的陷阱。

解决方案不是更聪明的解析器，而是首先强制模型以结构化格式回答。

可靠性阶梯

有一条从"希望"到"保证"的演进路径：

1. 在提示中要求 JSON。"用 JSON 对象回复，包含 name、order_id、issue 字段。"这比没有强，但模型仍然可以用 markdown 包裹它、添加注释，或产生格式错误的 JSON。这是希望式的。

2. JSON 模式 / 结构化输出模式。大多数正经的模型 API 现在都提供一种保证语法上有效 JSON 的模式。这完全消除了"它是否可解析"这类 bug。

3. Schema 约束生成。你提供一个 schema——确切的字段、类型以及哪些是必需的——然后输出被约束为匹配该 schema。现在你得到的不仅仅是有效的 JSON，而是你需要的 JSON。

4. 函数 / 工具调用。同样的机制，但表述为"用这些类型化参数调用这个函数"。这就是 Agent 如何与世界交互：模型发出一个结构化调用，你的代码执行它。它只是穿了不同外衣的结构化输出。

在边界处验证

即使有结构化输出，也要将模型的响应视为进入系统的不可信输入。用一个 schema 定义你期望的数据形状——在 Python 中，像 Pydantic 这样的库是标准——并对每个响应进行验证。如果不符合，你就立即捕获它，而不是让一个格式错误的对象传播三层深，在远离原因的地方崩溃。

模式是：模型产生结构化输出 → 根据 schema 验证 → 将一个干净的、类型化的对象交给系统的其余部分。这个验证步骤是模型概率世界和代码确定性世界之间的接缝，这是我在我构建的所有东西中都坚持的一条纪律。

为什么这比提示词措辞更重要

人们花好几天调优提示措辞，却忽略了真正使 LLM 可集成的东西：其输出的类型化、经验证的契约。一个平庸的提示配合严格的 schema，每次都胜过用自由文本的漂亮提示，因为前者你的系统可以信任，而后者你只能希望。

在真实系统中看到它

类型化契约是基础性的，不是装饰性的。在"Saturday MK1: an AI assistant that's a system, not a prompt"中，整个服务构建在 FastAPI 和 Pydantic v2 之上——每个请求和响应都是一个类型化的、经验证的模型，所以 Agent 引擎之间的边界是契约而不是希望。这使得独立构建的组件可以组合在一起，而不会悄悄破坏彼此的数据。

不要再让 LLM 与你的系统对话。让它填写你的系统定义的表单。这一个转变就是区分玩具和工具的关键。

更多内容请访问 www.divyakush.com。

Divyakush Punjabi · Full-Stack & AI Engineer Portfolio · GitHub · LinkedIn