Taylent Labs
EN
返回博客列表
LLMAI应用开发工程实践

LLM 应用的模型输出验证策略:从格式校验到业务规则的完整方案

构建可靠 LLM 应用的关键在于验证层设计。本文梳理从 JSON Schema 到业务规则的四层验证体系,给出工程化落地建议。

为什么需要验证层

LLM 的非确定性输出是把双刃剑:它带来了自然语言交互的灵活性,也让下游系统面临格式错乱、逻辑矛盾、甚至注入攻击的风险。许多团队在生产环境踩过的坑都指向同一个教训:永远不要假设模型输出是安全可用的。

验证层的职责是在模型输出流入业务逻辑之前,用确定性规则筛掉不合格的响应。这不是对模型能力的不信任,而是工程系统必备的防御性设计——就像 Web 后端永远要验证前端传来的参数一样。

四层验证体系

第一层:格式校验

最基础的一层是确保输出符合预期的数据结构。假设你要求模型返回 JSON 格式的商品信息,至少需要检查:

  • 是否为合法 JSON(能被 JSON.parse 解析)
  • 必需字段是否存在(name、price 等)
  • 字段类型是否正确(价格是数字而非字符串)

推荐使用 JSON Schema 或 Zod 这类工具定义验证规则。以 Zod 为例:

import { z } from 'zod';

const ProductSchema = z.object({
  name: z.string().min(1),
  price: z.number().positive(),
  category: z.enum(['electronics', 'books', 'clothing'])
});

// 验证模型输出
const result = ProductSchema.safeParse(modelOutput);
if (!result.success) {
  // 处理格式错误,可能需要重试或降级
}

对于非 JSON 输出(如 Markdown、代码块),可以用正则或专用解析器提取关键信息后再验证。

第二层:取值范围约束

格式正确不代表数值合理。这一层检查字段值是否在业务允许的范围内:

  • 日期是否在未来(订单交付日期)
  • 数量是否超过库存上限
  • 枚举值是否在预定义列表中

假设一个库存管理场景,即使模型返回了合法的 JSON,{quantity: 999999} 这样的输出仍需被拦截。可以在 Schema 中加入自定义校验:

const OrderSchema = z.object({
  quantity: z.number().int().min(1).max(1000),
  deliveryDate: z.string().refine(
    (date) => new Date(date) > new Date(),
    { message: "交付日期必须在未来" }
  )
});

第三层:业务规则验证

这一层处理跨字段的逻辑一致性。例如:

  • 折扣金额不能大于原价
  • VIP 客户才能选择加急配送
  • 退款金额不能超过订单总额

这些规则通常无法用静态 Schema 表达,需要编写业务函数:

function validateBusinessRules(order, userProfile) {
  if (order.discount > order.totalPrice) {
    return { valid: false, error: '折扣金额异常' };
  }
  if (order.expressShipping && userProfile.tier !== 'VIP') {
    return { valid: false, error: '普通用户不可选加急' };
  }
  return { valid: true };
}

第四层:安全过滤

最后一层防御注入攻击和有害内容:

  • SQL/命令注入特征(如果输出会拼接到查询中)
  • XSS 风险字符(如果输出会渲染到前端)
  • 敏感信息泄露(身份证号、密码等)

即使使用参数化查询,也建议对模型生成的 SQL 片段做白名单检查。对于面向用户的输出,可以集成内容安全 API 或用正则过滤高风险模式。

工程化落地建议

1. 分离验证逻辑与业务代码
把验证规则抽成独立模块,便于测试和复用。避免在调用模型的函数里写一堆 if-else。

2. 设计降级策略
验证失败时的处理方案:重试(带修正提示词)、降级到规则系统、人工介入。不同场景容错度不同——聊天机器人可以回复"我没理解",但支付流程必须阻断。

3. 记录验证失败样本
把不合格的输出存到日志或数据库,定期分析失败模式。这些样本可以用来优化提示词,或训练专门的格式修正模型。

4. 渐进式加固
不必一开始就建四层防线。从格式校验起步,根据生产环境暴露的问题逐步加固。过度验证会增加延迟和维护成本。

结语

验证层的本质是用确定性规则补足概率模型的不确定性。设计良好的验证体系能让 LLM 应用在保持灵活性的同时,达到传统软件系统的可靠性标准。

如果你的团队正在构建 LLM 应用,需要在架构设计阶段就考虑验证策略。Taylent Labs 在 AI 应用开发中积累了从提示词工程到生产加固的完整方法论,欢迎联系我们探讨具体场景的解决方案。