大模型输出怎么检测和过滤?

30 秒回答

1. 输出结构化约束（JSON Schema/Function Calling）
2. 多层级校验机制（语法、语义、业务规则）
3. 内容安全过滤（敏感词、合规检测）
4. 异常处理与降级策略（重试、兜底、人工审核）

回答与解析

答案要点

• 输出结构化约束（JSON Schema/Function Calling）
• 多层级校验机制（语法、语义、业务规则）
• 内容安全过滤（敏感词、合规检测）
• 异常处理与降级策略（重试、兜底、人工审核）
• 反馈闭环与持续优化

一、输出结构化约束（源头控制）

Function Calling / JSON Mode

• 强制模型按指定Schema输出，减少格式错误
• 设置response_format={"type": "json_object"}或工具调用接口

Prompt工程

• 在Prompt中嵌入Few-shot示例，明确输出格式要求
• 添加"请确保输出为合法JSON，不要添加markdown代码块标记"等约束

二、多层级校验机制

三、内容安全过滤

• 敏感信息检测：正则+模型识别PII（手机号、身份证号）
• 合规审核：调用内容审核API（如火山引擎、阿里云绿网）
• 幻觉检测：RAG场景下对比检索片段，计算语义相似度；关键事实要求模型提供引用来源

四、异常处理与降级

try:
    result = parse_and_validate(raw_output)
except FormatError:
    result = retry_with_stricter_prompt()  # 重试
except ValidationError:
    result = fallback_template()           # 模板兜底
except SafetyError:
    result = human_review_queue()          # 人工审核

五、反馈闭环

• 收集异常样本，用于SFT数据或Prompt优化
• 建立输出质量监控看板，追踪格式错误率、过滤拦截率

口语版讲法(约4分钟)

• 本质定位：输出质量是系统最后一道防线
• 源头控制：结构化约束与Function Calling
• 多层级校验：语法、语义、业务三层过滤
• 异常处理与降级：重试、兜底、人工
• 反馈闭环与持续优化

这道题其实问的是，大模型输出不可控时，我们怎么在工程上兜住质量底线。说白了，模型生成的内容再漂亮，如果格式不对、逻辑不通、甚至违规，那业务根本不敢用。所以核心思路是：从源头约束到多层校验，再到异常兜底，最后靠反馈持续优化，形成一个闭环。

先讲源头控制。我倾向于用 Function Calling 或者 JSON Mode 来强制模型按指定 schema 输出。举个例子，客服退款场景下，我需要模型输出退款金额、原因、订单号这几个字段，那我会在 API 调用时把工具定义传进去，模型只能按那个结构返回。这样格式错误基本就杜绝了。当然，Prompt 里也要加 few-shot 示例，明确说“不要加 markdown 代码块标记，直接输出合法 JSON”。但这里有个坑：结构化约束不是万能的，它对模型的理解能力有要求，如果模型本身不强，或者任务太复杂，它可能硬套 schema 但内容填错。所以这只是第一道防线。

接下来是多层级校验。我会把它分成三层。第一层是语法层，最基础，比如 JSON 解析、字段类型对不对。如果解析失败，我会直接捕获异常然后重试，或者用一些修复策略，比如补全缺失的括号。第二层是语义层，更关键。数值范围、枚举值是否合法、逻辑是否自洽。比如退款金额不能大于订单金额，状态必须是‘已退款’或‘退款中’之一。这里我会用规则引擎来校验，不通过就触发重新生成，但重试次数要有限制，不然延迟会爆炸。第三层是业务层，比如用户权限、场景约束。比如只有 VIP 用户才能申请加急退款，普通用户走普通流程。这一层校验不通过，我会直接拦截并返回友好提示，而不是重试，因为业务规则是硬约束。

再一个重点是内容安全过滤。敏感信息，像手机号、身份证号，我会用正则加模型识别来检测。合规方面，可以调用第三方审核 API，比如阿里云绿网。对于 Hallucination 检测，在 RAG 场景下，我会对比生成内容与检索片段，计算语义相似度，如果相似度太低就认为有幻觉，要求模型重新生成或者直接返回检索原文。关键事实还可以要求模型提供引用来源，方便人工复核。

异常处理与降级策略也很重要。我会写一个 try-catch 流程：如果解析或校验失败，先重试一次，但用更严格的 prompt；如果还失败，就用模板兜底，比如直接返回“系统繁忙，请稍后再试”；如果涉及安全风险，就进入人工审核队列。降级不是失败，是工程上的理性选择，总比给用户一个错误结果强。

最后是反馈闭环。我会把拦截下来的异常样本收集起来，分析是模型问题还是 prompt 问题，然后用于 SFT 数据或者 prompt 优化。同时建一个监控看板，追踪格式错误率、拦截率这些指标。如果某个场景错误率突然飙升，我会立刻排查是模型版本变更还是业务规则调整。

这里我想提一个延伸点：输出质量校验和模型本身的Self-RAG或Self-Refine能力怎么结合？ 比如让模型自己先检查一遍输出再返回，这能减少很多后处理负担，但代价是延迟和成本。怎么权衡，我觉得值得深入探讨。

所以整体上，我更倾向于把输出质量控制看作一个系统工程，不是单靠某一个环节。源头约束要强，校验要分层，异常要有预案，最后用数据反哺。这样上线我才放心。

关键一句:输出质量校验与模型自检能力的结合

面试官还可能这样问

1. 问法 1 · 场景切入

   我们有个电商客服场景，模型会生成订单查询结果，但有时输出格式不对，比如字段名拼错或者多了一行废话。你一般怎么确保模型输出的格式和内容都是可用的？

2. 问法 2 · 层层追问

   大模型生成的文本你通常怎么处理？……如果要求输出必须是JSON，但模型偶尔会多出markdown或解释性文字，你怎么检测和修复？……再深入一点，假设字段值不在合理范围内，或者逻辑上矛盾，你怎么过滤？

3. 问法 3 · 直球架构

   聊一下大模型输出的后处理与校验机制。你从哪些层面做检测？具体用什么方法处理格式错误、内容不合理或不符合业务规则的情况？异常时怎么降级？