Schema 驱动的 Prompt 设计：让你的数据模型主导 Prompt 结构

你的数据模式（schema）就是你的提示词。大多数工程师将这两者视为独立的事物——你设计数据库模式是为了满足范式规则，而你设计提示词是为了清晰和具描述性。但实体模式的形状对 LLM 输出质量有着直接且可衡量的影响，忽视这种关系是生产环境 AI 系统中最昂贵的错误之一。

一家中型电子商务公司的团队在他们的产品提取流水线开始生成幻觉模型年份时发现了这一点。修复方法并不是更好的提示词，而是将 {"model": {"type": "string"}} 更改为一个具有明确描述和正则表达式约束的字段。这单一的模式更改——记录在 PARSE 研究中——在他们的提取基准测试中带来了高达 64.7% 的准确率提升。

问题比字段描述更深。它触及了规范化、字段排序、嵌套深度、枚举设计，以及一个根本问题：LLM 能从你提供给它的结构中推断出什么，以及不能指望它推断出什么。

规范化陷阱

关系数据库设计教导你要进行规范化：消除冗余，将关系推入外键，将每条数据保存在一个地方。一个 orders 表通过 product_id 引用 products 表。整洁、高效、规范。

对于 LLM 提示词来说，这恰恰相反。

当你的模式要求模型在大脑中重构一个连接——找出哪个 category_id 对应哪个类别名称，或者哪些属性属于哪个产品类型时——模型会利用其训练分布来填补空白。它会进行猜测。而在复杂的模式中，它猜错的概率会不断累积。

PARSE 研究（发表于 EMNLP 2025）分析了针对 LLM 使用优化模式时究竟发生了什么变化。在所有提高提取准确率的修改中，55% 是结构扁平化——即将规范化的模式进行去规范化，从而使模型永远不必推断关系。另外 34% 是增强的字段描述，使字段范围更加明确。

实际影响是：如果你的数据模型为了存储效率而进行了规范化，你需要一个独立的、为 LLM 使用而优化的去规范化“提示词模式”。模型应该接收 product_name、category_name 和 category_type 作为兄弟字段——而不是指向它无法访问的查找表的 product_id 和 category_id。

嵌套深度如何破坏准确率

现代 JSON Schema 支持任意深度的嵌套。LLM 无法统一处理。

DeepJSONEval 基准测试测试了跨嵌套层级的提取准确率，并发现了一个陡峭的下降悬崖。在中等嵌套（深度 3–4）时，严格准确率得分在 54% 到 71% 之间。在困难嵌套（深度 5–7）时，得分下降到 43–53%。即使是该研究中表现最好的模型，在深层嵌套模式上的严格准确率也仅为 52.63%。

故障模式是不对称的。格式错误——如缺少键或类型错误等结构性问题——在参数超过 70 亿的模型中基本消失了。LLMStructBench 研究（22 个模型，2026 年 2 月）发现，大型模型中 97–98% 的剩余错误是错误值错误——即结构完美但内容虚假或归因错误的语义失败。更深的嵌套增加了模型必须解决的语义模糊性，而它通过编造听起来合理的数值来解决。

可操作的阈值：将提取模式保持在 2–3 层嵌套。当你的领域需要更强的复杂性时，将提取分解为流水线：

1. 先分类：使用一个带有文档类型枚举的小型专注模式。
2. 按类型提取：使用一个仅包含与该文档类别相关的字段的特定类型模式。
3. 验证交叉引用：运行最后一遍以验证提取的值是否一致。

每个阶段都使用更简单的模式。更简单的模式在每个层级都能产生更高的准确率。

字段顺序是因果性的，而非修饰性的

LLM 按顺序处理令牌。它们无法预测未来。这使得模式字段顺序在因果上处于输出质量的上游，这在传统软件开发中是无法比拟的。

具体例子：如果你的模式将 answer 字段放在 reasoning 字段之前，模型在生成任何思维链推理之前就已经确定了答案令牌。随后出现的推理是事后合理化——它是从答案开始的，而不是导向答案。

反转顺序——先 reasoning，后 answer——迫使模型在回答之前进行思考。这是在提取和分类任务中提高语义质量的最具杠杆作用的模式更改，且除了意识到字段顺序很重要之外，不产生任何成本。

同样的原则也适用于更广泛的模式设计。为后续字段提供上下文的字段应该更早出现。一个缩小 status_value 含义的 document_type 字段应该出现在 status_value 之前。模型对每个字段的理解都取决于它之前的所有内容。

枚举是安全护栏，而非风格选择

当你为分类值定义字段为 {"type": "string"} 时，你是在告诉模型任何字符串都是可以接受的。在约束解码（OpenAI 的 Structured Outputs、Guidance 及类似框架背后的机制）下，模型的 logits 在每一步都会被过滤，以便只有有效的 token 才能被产出。如果没有枚举约束，有效 token 的词汇表是无界的。

有了枚举约束，无效值将变得在语法上无法生成 —— 而不仅仅是可能性低。这就是“希望模型选择 'pending'”与“保证它无法选择 'in-progress'、'PENDING' 或 'awaiting'”之间的区别。

来自 JSONSchemaBench 的基准测试显示，约束解码框架在它们支持的 schema 上保持了近 100% 的格式合规性。更广泛的影响是：一项跟踪生产案例的研究发现，JSON schema 在结构化提取任务中将解析错误从 40% 降低到 2%，而函数调用（function calling）在金融服务应用中将审核准确性从 70% 提高到 95%。

加载中…