每个把 LLM 接入生产系统的开发者，迟早都会遇到这样一个场景：模型的返回看起来完全正确——JSON 格式合法、字段齐全、数据类型都对——但当你把结果送进下游业务系统后，才发现里面的数值逻辑矛盾，或者某个字段虽然格式正确但内容完全是编造的。JSON 解析没有报错，程序没有崩溃，只是业务结果错了。这种错误比解析失败更难排查，因为系统本身"认为"一切正常。
这不是模型能力的局限，而是 AI 应用工程中一个系统性缺失：输出验证。传统的 API 返回要么是 200（正常），要么是 4xx/5xx（错误），边界清晰。LLM 的输出则不同——它永远返回 200，同时返回的内容可能完全不可用。这意味着，把 LLM 接入生产系统的工程团队，必须额外建立一套输出质量保障体系，否则每一条不可靠的输出都会无声地污染下游数据。
输出不可靠的三个层次
理解 LLM 输出验证，首先要理解"不可靠"具体体现在哪些层面。
格式层： 模型返回的不是约定的结构。比如你要求 JSON 但模型返回了 Markdown 代码块包裹的 JSON，或者字段名拼写错误、数组边界不匹配。这是最外层的问题，也是最容易被 JSON Schema 捕获的。
语义层： 格式正确但内容不可用。比如你让 LLM 从合同中提取甲方名称，它返回了一个格式正确的字符串，但内容其实是乙方的名字。或者让 LLM 判断一段文本的情绪，它返回 "sentiment": "positive"，但全文明显是负面情绪。语义错误是 AI 应用中最难检测的问题。
业务规则层： 内容本身似乎合理，但违反了业务约束。比如 LLM 生成的报销单中金额超过了单笔上限，或者生成的时间序列中结束时间早于开始时间。这类错误需要将领域知识编码为可执行的验证规则。
这三个层次中，格式层最容易解决，语义层最难自动化，业务规则层依赖于团队对领域边界的定义。一个完整的输出验证体系应该覆盖所有三个层次，而不是只做 JSON Schema 检查就认为够了。
格式约束：从"期望 LLM 做好"到"让 LLM 做不好也发现"
在格式层面，最好的策略是让模型难以输出格式错误的结果，而不是事后补救。
目前主流 LLM 平台都提供了结构化输出能力：OpenAI 的 Structured Outputs 支持 JSON Schema 约束，保证输出严格符合定义的 schema；Anthropic 的 tool use 机制通过工具定义约束输出结构；vLLM 和 llama.cpp 等本地推理引擎则支持 grammar-based 的约束解码，从 token 生成层面就限制输出格式。
这些能力的核心思路是相同的：把格式约束从"验后"提前到"生成时"，让模型无法输出不符合格式的内容。比如用 OpenAI 的 Structured Outputs：
from openai import OpenAI
client = OpenAI()
response = client.chat.completions.create(
model="gpt-4o",
messages=[{"role": "user", "content": "提取合同中的关键条款"}],
response_format={
"type": "json_schema",
"json_schema": {
"name": "contract_terms",
"strict": True,
"schema": {
"type": "object",
"properties": {
"party_a": {"type": "string"},
"party_b": {"type": "string"},
"effective_date": {"type": "string"},
"amount": {"type": "number"},
},
"required": ["party_a", "party_b", "effective_date", "amount"],
"additionalProperties": False,
},
},
},
)
这保证了输出一定是合法的 JSON，且只包含 schema 中定义的字段。但注意：它不保证 party_a 的值是真正正确的甲方。这就引出了第二层验证。
对于无法使用结构化输出 API 的场景（比如本地模型或某些第三方推理服务），建议在解析层做两级防护：第一级用 JSON Schema 验证器（如 jsonschema 或 pydantic）做结构校验，第二级用 fallback 策略处理解析失败的情况。不要假设模型会一直输出你的解析器能处理的格式。
语义验证：最难也最需要工程投入
语义验证是输出质量控制中最核心也最困难的环节。一个 JSON Schema 只能检查"格式对不对"，无法回答"内容对不对"。
目前工程上可行的语义验证策略主要有三种。
规则引擎式验证： 对于可以形式化的语义约束，写成可执行的规则。比如提取的日期必须在合理范围内、提取的金额不能为负数、分类标签必须在预定义集合中。这种方法可靠但覆盖面有限，只能处理"有明显错误特征"的情况。
交叉验证： 用不同的方法验证同一结果。比如让同一个 LLM 用不同的 prompt 重复提取同一字段，比较结果的一致性；或者用一个小模型做快速筛查，大模型做精确验证。这种方法能发现"偶然性错误"，但会增加成本和延迟。
LLM-as-Judge 验证： 用一个独立的 LLM 调用验证前一个 LLM 的输出质量。这是目前最通用的语义验证方案，尤其适用于"没有明确对错标准、只有质量高低"的场景。
def validate_extraction(text: str, extracted: dict) -> dict:
"""用独立的 LLM 验证提取结果"""
validator_prompt = f"""验证以下从合同中提取的信息是否正确。
原始文本：
{text}
提取结果：
{json.dumps(extracted, ensure_ascii=False)}
请检查：
1. party_a 是否确实是合同中定义的甲方
2. amount 是否与合同中约定的金额一致
3. 是否有提取错误或遗漏
以 JSON 格式返回验证结果：
{{"valid": true/false, "issues": ["问题描述"], "confidence": "high/medium/low"}}
"""
validator_response = client.chat.completions.create(
model="gpt-4o-mini",
messages=[{"role": "user", "content": validator_prompt}],
response_format={"type": "json_object"},
)
return json.loads(validator_response.choices[0].message.content)
LLM-as-Judge 方案的核心工程考虑是：验证模型不需要和生成模型一样强，但 prompt 设计必须独立于生成 prompt。如果验证 prompt 和生成 prompt 使用相同的语义假设，验证就会失去独立意义。
业务规则层：把领域知识变成代码
业务规则验证是最直接也是最容易被忽视的环节。很多团队花大量精力优化 prompt 让模型"理解"业务规则，但从不把这些规则写成可执行的代码。
常见的业务规则验证包括：
- 逻辑一致性检查（"合同开始日期必须在结束日期之前"）
- 引用完整性检查（"引用的 ID 必须在已存在的记录中"）
from pydantic import BaseModel, Field, ValidationError
class ContractTerms(BaseModel):
party_a: str
party_b: str
effective_date: str
expiration_date: str
amount: float = Field(gt=0, le=1_000_000)
@field_validator("expiration_date")
@classmethod
def end_after_start(cls, v, info):
if info.data.get("effective_date") and v < info.data["effective_date"]:
raise ValueError("expiration_date must be after effective_date")
return v
这里的要点是：不要依赖 LLM 去理解业务规则。把规则写在 validation 代码中，而不是 system prompt 中。前者是确定性的，后者是概率性的。两者可以互补，但不能替代。
重试与降级：输出验证的最后一环
当验证发现输出不可用时，策略应该如何设计？
最简单的做法是重试：把验证发现的问题和原始输入一起送回模型，让模型自行修正。
MAX_RETRIES = 3
for attempt in range(MAX_RETRIES):
response = generate_llm_output(prompt, input_data)
validation_result = validate_output(response)
if validation_result["valid"]:
return response
if attempt < MAX_RETRIES - 1:
prompt = f"""上次生成的输出存在以下问题：
{validation_result["issues"]}
请修正后重新生成。保持输出格式与之前一致。
原始任务：{original_task}"""
else:
# 最后一次重试仍然失败，进入人工处理流程
send_to_manual_review(response, validation_result["issues"])
raise OutputValidationError("all retries exhausted")
重试策略的关键参数是重试次数和降级路径。对于不同的错误类型，应该有不同的处理方式：格式错误通常一次重试就能解决；语义错误可能需要 2-3 次；业务规则错误可能是 prompt 设计的问题，重试再多也难以解决，应该及时报警并转人工。
不是所有场景都适合重试。对延迟敏感的场景（如实时对话），重试带来的额外延迟可能比输出略微不准确更不可接受。这时候的降级策略可能是：接受已验证通过的字段，对未通过的部分使用默认值或标记进行替代。
生产监控：让输出质量可观测
输出验证不是一次性的代码检查，而是需要在生产环境中持续监控的能力。
核心监控指标包括：
- 验证通过率： 每次 LLM 调用经过校验后的通过比例。这个指标持续下降可能说明 prompt 或模型出了问题。
- 各层错误分布： 格式错误、语义错误、业务规则错误的比例。格式错误占比高说明结构化输出配置有问题；语义错误占比高说明 task 本身对 LLM 来说难度太大。
- 重试次数分布： 大多数请求应该 0 次重试通过。如果 2 次以上重试的比例升高，说明基础策略需要调整。
- 人工介入率： 最终需要人工处理的请求比例。这个指标直接衡量了自动化系统的成熟度。
# 输出验证指标的 OpenTelemetry 打点示例
from opentelemetry import metrics
meter = metrics.get_meter("llm-output-validator")
validation_counter = meter.create_counter(
"llm.validation.outcome",
description="Count of LLM output validation outcomes",
)
validation_counter.add(1, {
"layer": "schema",
"outcome": "pass", # or "fail"
"model": "gpt-4o",
"task": "contract_extraction",
})
将这些指标接入现有的监控体系（Prometheus + Grafana、Datadog 等），设置合理的告警阈值——比如验证通过率低于 95% 时触发告警。
分层架构：把验证体系组织起来
综合以上讨论，一个完整的 LLM 输出验证体系应该采用分层架构：
输入 → [生成] → [格式约束 / 结构化输出] → [Schema 校验] → [语义验证] → [业务规则] → [输出]
↑ ↑ ↑
(模型层约束) (独立验证) (代码规则)
↓
[重试 / 降级策略]
↓
[监控 / 告警]
每一层解决一个特定的问题，层与层之间有清晰的职责边界。模型层的结构化输出约束解决格式问题；代码层的 Schema 校验作为兜底；独立的语义验证模型处理内容正确性问题；业务规则引擎确保领域约束被严格执行。
这种分层设计的好处是：每一层的失败都被下一层捕获，不会出现"看起来正常但实际错误"的情况。同时，每一层可以独立优化和迭代——不需要因为改了一层而影响其他层。
边界：验证不能做什么
输出验证不是银弹。有几类问题验证体系很难有效处理：
知识边界错误： 如果 LLM 对某个专业领域完全不了解，无论怎么重试，验证结果都可能无法通过。这时需要的是 RAG 或更精确的 prompt 设计，而不是更多的验证。
主观判断错误： 如果输出的正确性本身是主观的（比如文案创意、代码风格），LLM-as-Judge 可能无法给出可靠判断。这类场景更适合人工审核或 A/B 测试。
成本权衡： 每一层验证都要消耗额外的 API 调用和延迟。在实时性要求高的场景下，可能需要牺牲一部分验证覆盖率换取响应速度。关键是要知道自己在牺牲什么，并监控被牺牲的部分是否真的可以承受。
输出验证不会让 LLM 变得完美，但它能让不可靠的输出被及时捕获，而不是无声地污染下游系统。在 AI 应用的工程化进程中，输出验证不是可选项，而是和输入验证、错误处理一样，是基础工程设施的组成部分。把验证做在模型层、代码层、监控层三个层次上，才能让 LLM 输出真正达到"可交付"的标准。
#大模型应用开发 #AI 应用工程 #LLM 工程 #输出验证
粤ICP备14082021号
免费POC，
零成本试错
