面试题 · RAG
在实际应用中，如何处理大模型生成的输出结果？有哪些方法可以检测和过滤格式错误、内容不合理或不符合要求的输出？
Function Calling / JSON Mode
response_format={"type": "json_object"}或工具调用接口Prompt工程
学习内容与项目面试，在同一条路上。
| 层级 | 检测内容 | 处理方式 |
|---|---|---|
| 语法层 | JSON合法性、字段完整性、类型匹配 | 异常捕获+重试/解析修复 |
| 语义层 | 数值范围、枚举值有效性、逻辑一致性 | 规则引擎校验，失败则重生成 |
| 业务层 | 是否符合业务规则、用户权限、场景约束 | 业务规则拦截，触发降级 |
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() # 人工审核场景切入
我们有个电商客服场景，模型会生成订单查询结果，但有时输出格式不对，比如字段名拼错或者多了一行废话。你一般怎么确保模型输出的格式和内容都是可用的？
层层追问
大模型生成的文本你通常怎么处理？……如果要求输出必须是JSON，但模型偶尔会多出markdown或解释性文字，你怎么检测和修复？……再深入一点，假设字段值不在合理范围内，或者逻辑上矛盾，你怎么过滤？
直球架构
聊一下大模型输出的后处理与校验机制。你从哪些层面做检测？具体用什么方法处理格式错误、内容不合理或不符合业务规则的情况？异常时怎么降级？
这道题其实问的是，大模型输出不可控时，我们怎么在工程上兜住质量底线。说白了，模型生成的内容再漂亮，如果格式不对、逻辑不通、甚至违规，那业务根本不敢用。所以核心思路是：从源头约束到多层校验，再到异常兜底，最后靠反馈持续优化，形成一个闭环。
先讲源头控制。我倾向于用 [[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]]能力怎么结合？ 比如让模型自己先检查一遍输出再返回，这能减少很多后处理负担，但代价是延迟和成本。怎么权衡，我觉得值得深入探讨。
所以整体上，我更倾向于把输出质量控制看作一个系统工程，不是单靠某一个环节。源头约束要强，校验要分层，异常要有预案，最后用数据反哺。这样上线我才放心。