Java与AI：让模型“稳定返回 JSON”靠 Prompt 约束、JSON Mode 和 Schema 校验三层递进，但语法合法不等于语义正确——Java 侧到底该在 Schema 校验之后再加哪些业务断言，才能拦住“结构对但值荒谬”的输出？

00 / ABSTRACT摘要

让大模型“稳定返回 JSON”这件事，工程界已经形成了三层递进的共识：Prompt 约束、服务端 JSON Mode（或结构化输出）、以及客户端 Schema 校验。这三层解决的是语法与结构问题——输出能被解析、字段齐全、类型正确。但生产事故的绝大多数并不发生在这三层：它们发生在“结构完全正确、值却荒谬”的区间里。例如金额为负、起止时间倒置、枚举值合法但业务上不可能出现、百分比之和不为 100、ID 指向一个已删除实体、单位从“元”漂移成“分”。

本文提出一条贯穿全文的分析主线：把 LLM 输出视为一个“不可信外部输入源”，用与对待第三方 API 响应同等的敌意去对待它。据此，Schema 校验只是“反序列化契约”，真正的防线是紧随其后的业务断言层（Business Assertion Layer, BAL）。本文按“约束分层 → 领域不变量 → 跨字段一致性 → 单位与量纲 → 时序与因果 → 数值分布漂移 → 语义等价与幂等”七个维度展开，给出 Java 侧可落地的断言设计模式、代码骨架、误杀率控制方法与可观测性方案，并讨论该层与形式化验证、约束解码等前沿方向的衔接。

01 / CONTENTS目录

02 / PROBLEM背景与问题定义：三层防线为何仍然漏

2.1 三层防线的能力边界

先厘清三层各自解决什么。Prompt 约束是概率性引导：它提高模型输出符合格式的倾向，但不提供任何保证。JSON Mode 与结构化输出（OpenAI 的 Structured Outputs、Google Gemini 的 responseSchema、Anthropic 的工具调用参数约束等）是解码期约束：通过受限解码（constrained decoding）在 token 采样阶段屏蔽非法分支，从而在结构层面提供接近确定的保证。Schema 校验（Java 侧的 Jackson + Jakarta Validation、JSON Schema Validator 等）是接收期校验：对已生成的文本做结构复核。

三者的共同点是：它们都在描述“形状”。JSON Schema 的 type、required、enum、pattern 能表达“这是一个整数”“这是三个枚举之一”，但无法表达“这个整数必须是本季度已结算订单的净额”“这个枚举值在当前租户下必须可用”。

本文评述：业界常把“JSON Mode + Schema 校验”宣传为“结构化输出的可靠性方案”，这是一种契约层与语义层的混淆。结构化输出保证的是“可被程序消费”，而非“可被业务信任”。把二者等同，等于把 Integer.parseInt 成功当作“这个数字是对的”。

2.2 失效模式的分类学

把“结构对但值荒谬”拆开，可以归纳为若干可枚举的失效族。下表是笔者在工程实践中整理的分类，用于指导断言层的覆盖设计（分类为经验归纳，非某单一文献结论）：

这张表本身就是设计清单：每一行都对应断言层的一个子模块。需要强调的是，Schema 并非完全无用——把 minimum/maximum/pattern 写进 Schema 是划算的：能在解码期就屏蔽掉一部分非法值，成本最低。问题在于 JSON Schema 的表达力上限——它无法表达跨字段算术关系、无法查询数据库、无法表达状态机。这正是业务断言层的存在空间。

2.3 一个具体的事故切片

考虑一个报销审批场景，模型需要输出结构化审批建议：

{
  "decision": "APPROVE",
  "approvedAmount": 12500.00,
  "currency": "CNY",
  "lineItems": [
    {"category": "TRAVEL", "amount": 8000.00},
    {"category": "MEAL",   "amount": 4500.00}
  ],
  "confidence": 0.97,
  "policyRefs": ["POL-2023-07"]
}

这段 JSON 在 Schema 层面完全合法：枚举正确、类型正确、金额是数字、引用是字符串数组。但它可能同时踩中多个语义陷阱：approvedAmount 与明细之和不等（12500 ≠ 12500，本例相等，但换一组数就不等）；MEAL 类目可能超出该员工职级对应的日限额；POL-2023-07 可能已被废止；confidence 0.97 可能是模型对“格式正确”的自信而非对“结论正确”的自信。这些都需要断言层逐条核实。

03 / MODEL约束分层模型：从语法到语义的六级阶梯

为了让“该在哪一层拦”有统一语言，本文提出一个六级约束阶梯。它借鉴了形式化方法中“语法—类型—契约—不变量—行为—演化”的分层思想，但针对 LLM 输出场景做了重新切分。笔者认为，工程团队应把每一级明确归属到某个组件，避免“以为别人会拦”的真空地带。

这个阶梯的价值在于责任可追溯：任何一次“荒谬输出”事故，都能定位到“本应由哪一级拦截而没拦”。L1–L2 由框架与 Schema 承担，L3–L6 由业务断言层承担。本文后续六个章节，正好对应 L3–L6 的展开。

笔者认为，很多团队的问题不是“没做校验”，而是“校验都堆在 L2”。把 L3–L6 的规则硬塞进 JSON Schema，会导致 Schema 膨胀到不可维护，且仍然表达不了跨实体关系。分层不是形式主义，它是让每一类规则待在它最擅长、最便宜的位置。

04 / DIMENSION 1第一维：领域不变量与值域断言

4.1 不变量（Invariant）的准确定义

在软件契约设计中，不变量指“在对象生命周期内必须恒为真的谓词”。Bertrand Meyer 在 Design by Contract 中把它与前置条件、后置条件并列，作为契约的三要素之一。本文借用这一概念，但把它从“对象方法调用”迁移到“LLM 输出实例”：一条不变量就是对该输出实例的一个布尔谓词，谓词为假即判定该输出不可信。

与 Schema 的 minimum 相比，不变量的表达力更强，因为它可以引用上下文、查询外部状态、做算术。例如“报销金额不得超过该员工剩余预算”就是一个不变量，它需要查询预算服务，Schema 无能为力。

4.2 值域断言的工程写法

Java 侧最省事的做法是复用 Jakarta Bean Validation，把 L3 的值域规则写成注解，再用 Validator 统一执行。好处是规则声明式、可组合、错误信息结构化；坏处是注解只能表达静态阈值，动态阈值需要自定义 ConstraintValidator。

public record ReimbursementDraft(
    @NotNull Decision decision,
    @DecimalMin(value = "0.00", inclusive = true) BigDecimal approvedAmount,
    @NotBlank @Pattern(regexp = "[A-Z]{3}") String currency,
    @NotEmpty List<@Valid LineItem> lineItems,
    @DecimalMin("0.0") @DecimalMax("1.0") double confidence,
    List<String> policyRefs
) {}

public record LineItem(
    @NotNull Category category,
    @DecimalMin(value = "0.00", inclusive = true) BigDecimal amount
) {}

但注解只是起点。真正拦得住“荒谬值”的，是那些依赖上下文的断言。下面给出一个断言接口的骨架，它把“规则”与“执行”解耦，便于组合、排序、短路与观测：

public interface Assertion<T> {
    String id();                       // 稳定标识，用于监控与豁免
    Severity severity();               // BLOCK / WARN / REPAIR
    AssertionResult check(T value, AssertionContext ctx);
}

public record AssertionResult(boolean passed, String code, String detail) {
    public static AssertionResult ok() { return new AssertionResult(true, null, null); }
    public static AssertionResult fail(String code, String detail) {
        return new AssertionResult(false, code, detail);
    }
}

public interface AssertionContext {
    EmployeeProfile employee();
    BudgetService budget();
    PolicyRepository policies();
    Clock clock();
}

关键设计点有三个。其一，severity 区分“硬拦截”与“软告警”：并非所有不变量都值得阻断流程，有些只应记录并降级。其二，id() 稳定，才能做“某条规则误杀率”的统计与灰度。其三，AssertionContext 显式注入外部依赖，避免断言内部偷偷查库导致不可测。

4.3 动态阈值：把“合理”变成可计算

静态阈值（如“金额 ≤ 100000”）容易写，但误杀率高。更好的做法是基于历史分布的分位数阈值：对同一类请求，取近 90 天该字段的 P99 作为上限，超出则告警而非直接拦截。这借鉴了异常检测中的稳健统计思路。本文评述：分位数阈值不是“真理”，它只是把“荒谬”的相对标准锚定在历史行为上；当业务本身发生结构性变化（如大促），阈值必须能被人为覆盖，否则会把正常波动误判为异常。

05 / DIMENSION 2第二维：跨字段一致性与条件依赖

5.1 算术一致性

最容易被忽视、也最容易出事故的一类：聚合值与明细值不一致。模型能生成一个漂亮的总额，也能生成一组漂亮的明细，但它不保证两者在算术上闭合。断言层必须显式重算：

public final class SumConsistency implements Assertion<ReimbursementDraft> {
    private static final BigDecimal TOLERANCE = new BigDecimal("0.01");

    @Override public String id() { return "sum.lineItems.eq.approvedAmount"; }
    @Override public Severity severity() { return Severity.BLOCK; }

    @Override public AssertionResult check(ReimbursementDraft d, AssertionContext ctx) {
        BigDecimal sum = d.lineItems().stream()
            .map(LineItem::amount)
            .reduce(BigDecimal.ZERO, BigDecimal::add);
        BigDecimal diff = sum.subtract(d.approvedAmount()).abs();
        if (diff.compareTo(TOLERANCE) > 0) {
            return AssertionResult.fail("SUM_MISMATCH",
                "sum=" + sum + ", approved=" + d.approvedAmount() + ", diff=" + diff);
        }
        return AssertionResult.ok();
    }
}

注意 BigDecimal 与 TOLERANCE 的细节：金额必须用 BigDecimal 且显式指定 scale，否则 equals 与 compareTo 行为不同会埋坑；容差是为了吸收四舍五入，但容差本身不能成为掩盖系统性偏差的借口——若 diff 长期稳定在容差附近，说明上游存在系统性舍入错误，应单独告警。

5.2 条件依赖与互斥

很多字段之间存在“若 A 则 B 必填/必空”的依赖。这类规则在 JSON Schema 里可以用 if/then/else 表达一部分，但一旦涉及多字段组合与外部状态，就必须落到断言层。常见模式包括：

• 互斥：decision=REJECT 时 approvedAmount 必须为 0 或缺失；
• 蕴含：currency=CNY 时 policyRefs 必须包含至少一条境内政策；
• 基数约束：lineItems 中 MEAL 类目至多一条；
• 排序约束：明细按金额降序，或按发生时间升序。

实现上，建议把这类规则写成“谓词组合”而非“if 嵌套”，便于生成可读的失败原因。例如用一个小型 DSL 或直接用 Java 的 Predicate 组合，失败时输出“哪条子句为假”。

本文评述：跨字段一致性是“结构对但值荒谬”的高发区，因为模型在生成每个字段时是局部决策，缺乏全局约束求解。指望 Prompt 里写一句“请保证总额等于明细之和”并不可靠——这不是模型不听话，而是自回归生成在数学上就不保证全局一致。断言层的重算，是把“生成问题”转成“验证问题”，这是更可控的方向。

06 / DIMENSION 3第三维：单位、量纲与精度断言

6.1 单位漂移为何难以察觉

单位漂移（unit drift）指同一语义字段在不同输出中使用了不同计量单位，而数值本身仍在合法区间内，因此 Schema 与值域断言都拦不住。典型例子：金额在“元”与“分”之间漂移（100 元 vs 100 分，都合法但差 100 倍）；时长在“秒”与“毫秒”之间漂移；温度在摄氏与华氏之间漂移。

这类问题的危险在于它不会报错，只会算错。一笔 100 元的报销被当成 100 分入账，系统一切正常，直到对账时才发现。断言层必须把“单位”显式建模，而不是隐含在字段名里。

6.2 显式量纲建模

推荐做法是引入一个轻量的量纲类型，把数值与单位绑定，禁止裸 BigDecimal 在业务层流转：

public record Money(BigDecimal amount, CurrencyUnit unit) {
    public Money {
        Objects.requireNonNull(amount);
        Objects.requireNonNull(unit);
        if (amount.scale() > unit.maxScale()) {
            throw new IllegalArgumentException("scale exceeds unit precision");
        }
    }
    public Money to(CurrencyUnit target, ExchangeRateTable rates) {
        if (unit.equals(target)) return this;
        BigDecimal rate = rates.rate(unit, target);
        return new Money(amount.multiply(rate).setScale(target.maxScale(), RoundingMode.HALF_UP), target);
    }
}

断言层随之增加一条“单位一致性”规则：同一请求内所有金额字段的单位必须相同，或必须能通过显式汇率表换算且换算后闭合。对于时长、温度等同理。本文评述：量纲建模的成本主要在改造现有 DTO，但它把“单位”从注释里的约定变成类型系统里的约束，这是用编译期换运行期的经典权衡，长期收益远大于改造成本。

6.3 精度与舍入断言

精度问题同样隐蔽。模型可能输出 0.1 + 0.2 = 0.30000000000000004 这类浮点痕迹，也可能输出超过业务精度的小数位。断言层应检查：小数位数不超过业务定义（金额 2 位、比率 4 位）；舍入模式符合约定（银行家舍入 vs 四舍五入）；换算前后满足精度守恒。这些规则看似琐碎，但它们是财务类系统“值荒谬”的主要来源之一。

07 / DIMENSION 4第四维：时序、因果与状态机断言

7.1 时序一致性

时间字段是最容易“结构对但值荒谬”的领域之一：endTime 早于 startTime、createdAt 晚于 updatedAt、时间落在未来或过于久远。断言层应至少覆盖：区间有序、时区一致、与服务器时钟的偏移在合理窗口内、时间粒度符合业务（如按天聚合的字段不应带毫秒）。

时区是高频陷阱。模型可能输出 2024-03-01T00:00:00 不带偏移量，Java 侧用默认时区解析，结果在不同部署环境得到不同时刻。断言应要求时间字段带显式偏移，或统一按 UTC 存储并在边界转换。

7.2 状态机断言

当输出涉及“对实体执行某操作”时，必须校验该操作在当前状态下是否合法。这本质上是把领域状态机作为断言源：

public enum OrderState { CREATED, PAID, SHIPPED, REFUNDED, CLOSED }

public final class TransitionGuard {
    private static final Map<OrderState, Set<OrderState>> ALLOWED = Map.of(
        OrderState.CREATED,  Set.of(OrderState.PAID, OrderState.CLOSED),
        OrderState.PAID,     Set.of(OrderState.SHIPPED, OrderState.REFUNDED),
        OrderState.SHIPPED,  Set.of(OrderState.CLOSED, OrderState.REFUNDED),
        OrderState.REFUNDED, Set.of(OrderState.CLOSED),
        OrderState.CLOSED,   Set.of()
    );

    public static boolean allowed(OrderState from, OrderState to) {
        return ALLOWED.getOrDefault(from, Set.of()).contains(to);
    }
}

把状态机显式化之后，断言就变成一次查表。本文评述：状态机断言的真正价值不在“拦截”，而在“把隐含的领域知识写下来”。很多团队的状态迁移规则散落在 service 的 if-else 里，LLM 输出一旦绕过这些路径，就无人校验。把状态机抽成独立组件，既服务断言，也服务文档与测试。

7.3 因果与引用完整性

“引用悬空”是幻觉的典型形态：模型引用了不存在的订单号、政策条款、文档 ID。断言层必须做存在性校验：对每个引用字段，查询权威数据源确认其存在、未被删除、且对当前租户可见。这一步的代价是额外的 IO，因此需要缓存与批量查询设计。

更进一步是因果校验：不仅要求引用存在，还要求引用与结论之间存在合理关联。例如“因政策 POL-2023-07 而拒绝”要求该政策确实覆盖当前类目。这类校验往往需要规则引擎或人工定义的关联表，成本较高，建议按业务风险分级实施。

08 / DIMENSION 5第五维：数值分布漂移与统计断言

8.1 为什么单点断言不够

前面几维都是“逐条实例”的断言。但有一类问题只在批量层面才显现：模型输出的置信度全部是 0.99、所有分类都偏向同一类、金额分布突然整体右移。单条看都合法，整体看明显异常。这类问题需要统计断言。

8.2 可落地的统计断言

统计断言不必复杂，几个简单指标就足够覆盖多数场景：

本文评述：统计断言与逐条断言的关系，类似“单元测试”与“集成监控”。前者保证单点正确，后者捕捉系统性偏移。很多团队只做前者，结果模型升级后整体行为漂移，逐条断言全部通过，业务指标却悄悄恶化。把统计断言纳入发布门禁，是防止“静默退化”的关键。

8.3 分布漂移的检测方法

工程上常用 PSI（Population Stability Index）或 KS 检验比较当前窗口与基线窗口的分布。PSI 的计算简单、可解释，适合监控；KS 检验对连续分布更敏感。需要说明的是，这些方法来自风控与模型监控领域，迁移到 LLM 输出监控时，基线窗口的选择（按天/按版本/按租户）会显著影响灵敏度，需结合业务节奏调参。此处不展开公式，读者可参考模型监控相关文献。

09 / DIMENSION 6第六维：语义等价、引用完整性与幂等

9.1 语义等价与规范化

同一实体可能有多种合法表示：手机号带不带国家码、地址的省市区顺序、公司名的全称与简称、金额的 100.0 与 100.00。如果断言层不做规范化，就会出现“同一条记录被判定为不同实体”，进而破坏幂等、产生重复写入。

做法是在断言之前插入一个规范化阶段：对每个字段定义 canonical form（如 E.164 手机号、ISO 3166 地区码、统一小写去空格的标识符），断言与后续持久化都基于规范化后的值。本文评述：规范化看似是“数据清洗”，实则是断言层的前置条件——没有统一表示，“一致性”无从谈起。

9.2 幂等键设计

LLM 输出可能被重试、被多次调用、被人工重放。若同一语义请求产生两条不同记录，就会造成重复。断言层应参与幂等键的构造：用“业务实体 + 规范化关键字段 + 操作类型”的哈希作为幂等键，在写入前检查是否已存在。这样即便模型两次输出的措辞不同，只要语义等价，就能被识别为同一操作。

public static String idempotencyKey(ReimbursementDraft d, String employeeId) {
    String canonical = String.join("|",
        employeeId,
        d.currency().toUpperCase(Locale.ROOT),
        d.approvedAmount().setScale(2, RoundingMode.HALF_UP).toPlainString(),
        d.lineItems().stream()
            .map(li -> li.category().name() + ":" + li.amount().setScale(2, RoundingMode.HALF_UP))
            .sorted()
            .collect(Collectors.joining(","))
    );
    return DigestUtils.sha256Hex(canonical);
}

注意 sorted()：明细顺序不应影响幂等键，否则模型换个顺序就变成新操作。这类细节正是“语义等价”断言要处理的核心。

9.3 引用完整性的批量校验

对 policyRefs 这类引用数组，逐条查库代价高。工程上应做批量查询 + 本地缓存：一次请求收集所有引用 ID，批量查权威源，返回存在性映射，再逐条断言。对高频引用的政策、类目等，可加多级缓存并设置合理 TTL。本文评述：引用完整性校验的成本主要不在逻辑，而在 IO 组织；把它设计成“批量 + 缓存”的独立组件，才能避免断言层成为性能瓶颈。

10 / ENGINEERING工程落地：断言层的架构、误杀率与可观测性

10.1 架构位置

断言层应位于“Schema 校验之后、业务执行之前”，作为一个独立管道（pipeline）存在，而不是散落在各个 service 里。推荐的分层是：

LLM 调用
  → 反序列化（L1）
  → Schema 校验（L2）
  → 规范化（canonicalize）
  → 断言管道（L3–L6，按 severity 短路/收集）
  → 决策：PASS / REPAIR / BLOCK / ESCALATE
  → 业务执行（带幂等键）
  → 观测上报（指标、日志、样本）

其中 REPAIR 是一个值得单独设计的出口：当断言失败但可修复时（如单位换算、字段补齐），可以走一次受控修复（调用规则或二次 LLM），修复后重新断言；修复失败再降级为 BLOCK 或 ESCALATE（转人工）。

10.2 误杀率控制

断言层的最大风险不是漏拦，而是误杀正常输出导致业务不可用。控制误杀率的工程手段包括：

• 灰度上线：新断言先以 WARN 模式运行，观察命中样本，确认无误杀再升级为 BLOCK；
• 样本回放：用历史通过的输出回放新断言，统计误杀率；
• 豁免名单：对已知合法边界（如大促期间的高额订单）提供白名单；
• 可解释失败：失败信息必须包含“哪条规则、哪个字段、期望什么、实际什么”，便于快速判断是误杀还是真错。

本文评述：断言层的成熟度可以用“误杀率 / 漏拦率”二维来刻画。初期应偏向低误杀（宁可漏拦，不可误杀），随着规则打磨与样本积累，再逐步收紧。一步到位追求“零漏拦”，往往以业务不可用为代价。

10.3 可观测性设计

每条断言都应上报结构化事件：assertion_id、severity、passed、model_version、prompt_version、tenant、耗时。这样在模型或 Prompt 升级时，可以按版本对比断言失败率，快速定位回归。指标命名建议统一前缀，便于聚合。

此外，建议保留“失败样本的脱敏快照”，用于离线分析与规则迭代。注意合规：快照中不得包含个人敏感信息，需做字段级脱敏与访问控制。

10.4 与现有 Java 生态的衔接

Java 侧已有成熟的校验生态：Jakarta Bean Validation 负责声明式约束，Jackson 负责反序列化与自定义 Deserializer，Spring 的 @Validated 负责方法级校验。断言层不必另起炉灶，而应复用这些基础设施：把静态规则写成注解，把动态规则写成自定义 ConstraintValidator 或独立的 Assertion 管道。对于 JSON Schema 校验，可使用 networknt/json-schema-validator 等成熟库，避免自研解析器。

延伸阅读方面，JSON Schema 官方规范（json-schema.org）是理解结构约束边界的必读材料；OpenAI 关于 Structured Outputs 的工程博客详细说明了受限解码的保证范围与限制；Jakarta Validation 规范文档说明了类级约束与跨字段校验的写法。视频方面，可搜索“Constrained Decoding LLM”相关技术分享，理解解码期约束的原理与代价。

11 / LIMITS对比与局限：BAL 不能解决什么

11.1 与形式化验证的对比

业务断言层本质上是运行时检查，它只能验证“这条输出是否满足我写下的谓词”，不能证明“系统对所有输入都正确”。形式化验证（如用 TLA+、Alloy 对状态机建模）能在设计期发现规则冲突与遗漏，但成本高、门槛高。二者是互补关系：形式化验证保证“规则本身自洽”，断言层保证“运行时遵守规则”。本文评述：对高风险领域（金融、医疗），值得在关键状态机上做轻量形式化建模；对一般业务，断言层 + 充分测试已足够。

11.2 与约束解码的边界

约束解码（constrained decoding）能在生成阶段就排除非法结构，近年也有研究把它扩展到更丰富的语义约束（如正则、文法）。但它的表达力仍受限于“可在解码期高效判定的谓词”，无法表达需要查库、需要全局算术求解的约束。因此，约束解码是 L1–L2 的强化，不能替代 L3–L6。

11.3 断言层自身的风险

需要诚实指出：断言层会引入新的失败模式。规则写错会误杀；规则过时会漏拦；规则膨胀会拖慢链路；规则冲突会让系统行为不可预测。缓解手段是：规则即代码、纳入版本管理与评审；规则有 owner 与过期时间；定期用样本回放评估；对规则数量设软上限，超限时重构而非堆叠。

🔒 复制本站文章内容需登录并达到 L3。当前：未登录