很多人做大模型应用时，只盯着 Prompt、RAG、Agent、模型选型，却忽略了一个非常关键的环节：大模型后处理。
说白了，大模型后处理就是：
模型回答完之后，不要马上把结果丢给用户或业务系统，而是先做清洗、校验、修正、补全、安全过滤、格式转换、质量评分和兜底处理。
因为大模型不是传统接口，它可能会：
输出格式不稳定、JSON 少字段、内容跑题、出现敏感信息、编造事实、重复废话、答非所问、把 Markdown 写乱、把工具调用参数写错、把不该展示的内部内容说出来。
所以，真正能上线的大模型系统，绝对不是：
用户提问 → 大模型回答 → 直接返回
而应该是：
用户提问 → 检索/工具/模型生成 → 后处理 → 校验 → 修复 → 安全过滤 → 质量判断 → 返回结果
OpenAI 官方也专门提供 Structured Outputs，用来让模型输出符合 JSON Schema；LangChain 也有结构化输出、Output Parser 等能力；NVIDIA NeMo Guardrails 则强调在大模型应用中增加可编程护栏，对输入、检索、对话和输出进行约束。
一、大模型后处理到底是什么？
1.1 后处理不是“美化文本”，而是“结果治理”
很多人以为后处理就是把模型回答润色一下，比如：
“把语气变自然一点。”
“把 Markdown 格式整理一下。”
“把多余空格删掉。”
这只是最浅层的后处理。
真正的大模型后处理，至少包括 8 类事情：
第一，格式处理。
比如模型必须返回 JSON、表格、数组、SQL、Markdown、代码块、固定字段。
第二，内容清洗。
去掉无意义前缀、废话、重复句、乱码、非法字符、模型自我解释。
第三，结构校验。
检查字段是否完整、类型是否正确、枚举值是否合法、数字范围是否合理。
第四，安全过滤。
过滤敏感信息、违规内容、内部提示词、个人隐私、危险操作建议。
第五，事实校验。
检查模型有没有胡编乱造，尤其是 RAG 场景下，要看回答是否基于检索资料。
第六，业务规则校验。
比如营销文案不能夸大承诺，客服回答不能越权承诺退款，金融建议不能直接保证收益。
第七，自动修复。
JSON 解析失败要修，字段缺失要补，答案不符合规则要重新生成或走兜底。
第八，质量评分。
判断答案是否完整、是否相关、是否可用、是否需要人工介入。
一句话总结：
Prompt 决定模型怎么答，后处理决定这个答案能不能安全、稳定、可靠地进入业务系统。
二、为什么大模型一定要做后处理？
2.1 因为大模型输出天然不稳定
传统接口返回的是固定结构：
{
"code": 200,
"data": {},
"message": "success"
}
但大模型可能今天返回：
{"title":"活动方案","summary":"…"}
明天返回：
好的，以下是你要的JSON：
{
"title": "活动方案",
"summary": "…"
}
后天返回：
{
"标题": "活动方案",
"摘要": "…"
}
如果下游系统直接解析，就容易报错。
所以后处理第一件事就是：把大模型不稳定的自然语言输出，变成系统可消费的稳定数据。
2.2 因为大模型会“看起来很对，实际不对”
大模型很擅长生成流畅文本，但流畅不等于正确。
比如用户问：
“帮我生成一个优惠券发放策略。”
模型可能回答得很专业：
“建议给所有用户发 100 元无门槛券，可快速提升转化率。”
听起来很合理，但业务上可能完全不能用，因为：
成本太高、规则违规、没有考虑用户分层、没有考虑预算、没有考虑库存、没有考虑风控。
所以后处理不仅要检查语法，还要检查业务可用性。
2.3 因为大模型输出可能带来安全风险
OWASP 2025 大模型应用风险中，专门提到了 Prompt Injection、Sensitive Information Disclosure、Improper Output Handling 等风险。也就是说，如果大模型输出没有经过验证、清洗和安全处理，可能导致敏感信息泄露、XSS、SQL 注入、越权操作等问题。
比如模型输出：
<script>alert('xss')</script>
如果前端直接渲染，就可能造成 XSS。
再比如模型生成 SQL：
DROP TABLE user;
如果系统直接执行，后果非常严重。
所以大模型后处理不是可选项，而是上线必备项。
三、大模型后处理的完整流程
一个比较成熟的大模型后处理流程，可以设计成下面这样：
3.1 第一步：原始结果接收
模型返回后，先不要急着展示。
先把原始结果保存下来，包括：
为什么要保存？
因为后面排查问题必须用。
比如用户投诉：
“AI 回答错了。”
你不能只看最终答案，你要知道：
当时用户问了什么？
检索到了什么资料？
Prompt 是哪个版本？
模型返回的原文是什么？
后处理有没有改动？
有没有触发安全过滤？
有没有走兜底？
没有这些日志，大模型问题基本没法排查。
3.2 第二步：基础清洗
基础清洗主要解决“脏输出”问题。
常见清洗包括：
3.2.1 去掉模型废话
比如模型返回：
当然可以，以下是你需要的JSON：
```json
{
"name": "张三",
"age": 18
}
希望对你有帮助。
系统真正需要的是：
```json
{
"name": "张三",
"age": 18
}
所以后处理要去掉：
“当然可以”
“以下是”
“希望对你有帮助”
Markdown 代码块标记
多余解释文本
3.2.2 去掉非法字符
比如：
不可见字符、控制字符、乱码、异常换行、特殊符号。
尤其是模型输出要进入数据库、Excel、PDF、HTML 页面时，这一步很重要。
3.2.3 统一换行和空格
模型输出经常会出现：
多余空行、缩进混乱、中英文标点混乱、列表层级错乱。
后处理可以统一成：
段落之间一个空行
标题使用固定 Markdown 级别
列表统一用数字或短横线
去掉连续多个空格
3.3 第三步：格式解析
这是后处理里非常核心的一步。
大模型常见输出格式有：
JSON
Markdown
HTML
SQL
CSV
YAML
XML
函数调用参数
工具调用参数
代码块
自然语言文本
如果是业务系统使用，最推荐的是：尽量让模型输出结构化结果。
比如：
{
"intent": "refund_query",
"confidence": 0.86,
"answer": "您可以在订单详情页申请退款。",
"need_human": false
}
不要让模型只返回一段话：
用户应该是想问退款，可以告诉他去订单详情页申请退款。
因为自然语言很难稳定解析。
OpenAI 的 Structured Outputs 就是为了让模型输出符合开发者定义的 JSON Schema，避免缺字段、字段类型错误、枚举值乱写等问题。
四、结构化输出应该怎么做？
4.1 先定义输出协议
不要上来就写 Prompt，而是先定义结果结构。
比如做“用户意图识别”，可以定义：
{
"intent": "string",
"confidence": "number",
"slots": {
"productName": "string",
"orderId": "string"
},
"needHuman": "boolean",
"reason": "string"
}
这里每个字段都有明确作用：
intent：用户意图
confidence：置信度
slots：关键信息
needHuman：是否需要人工
reason：判断原因
这样下游系统就能稳定消费。
4.2 字段不要太随意
很多人设计结构化输出时会犯一个错误：字段太自由。
比如：
{
"type": "xxx"
}
type 到底有哪些值？
模型可以随便写：
refund
refund_query
退款
售后退款
用户要退款
after_sale_refund
这就麻烦了。
正确做法是定义枚举：
{
"intent": "refund_query | order_query | product_consult | complaint | unknown"
}
也就是说，大模型只能在固定选项里选。
4.3 重要字段必须加校验
比如：
confidence 必须在 0 到 1 之间。
needHuman 必须是 true 或 false。
intent 必须在枚举范围内。
orderId 必须符合订单号格式。
phone 必须符合手机号格式。
price 必须是数字。
date 必须是合法日期。
不要相信模型“应该会按要求返回”。
上线系统里，必须假设模型会犯错。
4.4 解析失败要有修复机制
比如模型返回：
{
"intent": "refund_query",
"confidence": "高",
"needHuman": "否"
}
这不是严格 JSON 业务结构，因为：
confidence 应该是数字
needHuman 应该是布尔值
这时候有几种处理方式：
第一种：规则修复。
把“高”映射成 0.8，把“否”映射成 false。
第二种：再次调用模型修复。
把错误结果和错误原因发给模型，让它只修复格式。
第三种：重新生成。
重新请求模型，要求严格输出。
第四种：兜底返回。
如果连续失败，返回默认结构：
{
"intent": "unknown",
"confidence": 0,
"needHuman": true
}
LangChain 的 Output Parser、Structured Output、Retry Parser 等能力，本质上就是在解决模型输出解析和失败重试的问题。
五、大模型后处理的 10 个核心模块
5.1 模块一：格式标准化
格式标准化解决的是“输出能不能被系统读懂”。
常见处理：
JSON 提取
Markdown 修复
HTML 转义
代码块提取
表格转数组
日期格式统一
数字格式统一
中英文标点统一
字段名统一
换行统一
例如模型返回：
姓名：张三
年龄：18
城市：上海
后处理可以转成：
{
"name": "张三",
"age": 18,
"city": "上海"
}
这一步非常适合用规则做，不一定什么都交给大模型。
5.2 模块二：Schema 校验
Schema 校验就是检查结果是否符合预期结构。
比如要求输出：
{
"title": "string",
"tags": ["string"],
"score": "number"
}
那么后处理要检查：
title 有没有？
title 是不是字符串？
tags 是不是数组？
score 是不是数字？
score 是否在合理范围？
如果不符合，就进入修复流程。
5.3 模块三：敏感词与合规过滤
大模型输出可能包含：
手机号
身份证号
银行卡号
邮箱
地址
内部系统名
接口地址
密钥
Token
违法违规内容
不适合展示的内容
不应该承诺的业务话术
后处理需要做：
敏感信息识别
敏感信息脱敏
违规内容拦截
高风险内容替换
必要时转人工
例如：
用户手机号是 13812345678
可以处理为：
用户手机号是 138****5678
再比如：
我保证你一定能盈利。
金融、投资类场景就必须拦截或改写为：
相关内容仅供参考，不构成收益承诺。
5.4 模块四：幻觉检测
幻觉检测是大模型后处理里最难的一块。
所谓幻觉，就是模型说得很像真的，但其实没有依据。
在 RAG 场景中，可以用一个简单原则：
答案里的关键结论，必须能在检索资料中找到依据。
如果找不到，就不要让模型强答。
可以设计几类判断：
第一，回答是否引用了检索内容。
第二，回答是否出现检索资料里没有的数字、日期、政策、价格。
第三，回答是否扩大解释。
第四，回答是否把不确定内容说成确定。
第五，回答是否出现“编造来源”。
比如知识库里只写了：
“退款将在 3-5 个工作日处理。”
模型却回答：
“退款会在 24 小时内到账。”
这就是风险输出，后处理应该拦截。
5.5 模块五：引用与来源校验
如果是知识库问答、企业文档问答、法律政策问答、医疗资料问答，最好让回答带来源。
后处理要检查：
是否有引用来源
引用来源是否真实存在
引用片段是否支持答案
引用编号是否错乱
引用内容是否过期
是否引用了低可信资料
如果模型回答：
“根据资料可知……”
但没有任何资料来源，那就要降级成：
“当前资料中没有找到明确依据，建议进一步确认。”
5.6 模块六：业务规则校验
这是很多技术团队容易忽略的地方。
大模型回答不只是技术问题，还要符合业务规则。
比如电商客服：
不能承诺一定退款
不能绕过平台规则
不能泄露用户隐私
不能引导线下交易
不能承诺未公开活动
比如营销文案：
不能虚假夸大
不能使用极限词
不能违反广告法
不能承诺百分百效果
不能过度诱导用户
比如企业内部助手：
不能泄露内部文档
不能回答越权内容
不能输出敏感数据
不能绕过审批流程
所以后处理一定要接入业务规则。
通用安全规则只能解决一部分问题，真正决定系统可不可用的是业务规则。
5.7 模块七：重复与啰嗦处理
模型很容易重复。
比如：
这个方案可以提升转化率。通过这个方案，可以进一步提升转化率，从而让转化率得到提升。
后处理可以做：
重复句删除
相似句合并
口水话压缩
标题层级整理
无意义开头删除
无意义结尾删除
尤其是生成文章、报告、复盘、总结类内容时，这一步很重要。
5.8 模块八：风格统一
不同模型、不同 Prompt、不同温度参数，输出风格会不一致。
后处理可以统一成：
正式风格
客服风格
营销风格
技术文档风格
短视频口播风格
公众号文章风格
头条爆款风格
企业内部汇报风格
比如客服场景中，不希望模型输出：
“这个问题很简单。”
因为用户可能会感觉被冒犯。
可以改成：
“这个问题可以按以下步骤处理。”
5.9 模块九：结果评分
模型输出后，可以给结果打分。
评分维度包括：
相关性
完整性
准确性
可读性
安全性
格式正确率
引用可信度
业务合规性
是否需要人工复核
比如：
{
"relevanceScore": 0.91,
"safetyScore": 0.98,
"formatValid": true,
"needHumanReview": false
}
评分可以由规则完成，也可以由小模型或另一个大模型完成。
注意：评分模型最好和生成模型解耦。
也就是说，不要完全让同一个模型“自己生成、自己判卷”，否则容易互相包庇。
5.10 模块十：兜底降级
后处理一定要有兜底。
常见兜底方式：
重新生成
格式修复
走小模型
走规则模板
返回固定话术
转人工
只返回检索原文
提示用户补充信息
拒答高风险问题
进入审核队列
比如：
当前问题涉及的信息不完整，暂时无法给出准确结论。建议补充订单号或联系人工客服处理。
比模型胡编一个答案要安全得多。
六、不同场景下的大模型后处理怎么做？
6.1 智能客服场景
智能客服最怕什么？
不是回答不够优美，而是：
答错政策
承诺过度
泄露隐私
绕过流程
误导用户
用户情绪升级
所以客服场景后处理重点是：
意图校验
答案来源校验
敏感信息脱敏
业务政策校验
语气柔和处理
高风险问题转人工
拒答话术标准化
例如用户问：
“我这个订单能不能立刻退款？”
模型原始回答：
可以，马上给你退款。
后处理后应该变成：
退款需要根据订单状态和平台规则判断。您可以在订单详情页提交退款申请，系统会根据实际情况处理。如订单状态异常，建议联系人工客服进一步确认。
这才是可上线的回答。
6.2 RAG 知识库问答场景
RAG 场景后处理重点是：
引用校验
答案是否基于资料
资料是否过期
是否出现知识库之外的结论
是否需要提示“不确定”
是否返回来源片段
推荐策略：
如果检索命中率低，不要强答。
如果资料冲突，提示存在不同版本。
如果资料过期，提示更新时间。
如果没有依据，明确说未找到。
如果涉及关键决策，建议人工确认。
比如：
根据当前知识库资料，暂未找到该问题的明确说明。建议补充更具体的关键词，或联系相关负责人确认。
这比硬编答案更可靠。
6.3 Agent 工具调用场景
Agent 场景后处理尤其重要。
因为 Agent 不只是回答，它可能会调用工具：
查数据库
发邮件
创建工单
改配置
调用接口
执行脚本
创建日程
提交审批
这时候后处理要重点检查：
工具名是否合法
参数是否完整
参数类型是否正确
是否越权
是否需要二次确认
是否属于高风险操作
是否命中黑名单
是否超过调用次数
是否需要人工审批
比如模型想调用：
{
"tool": "delete_user",
"params": {
"userId": "10086"
}
}
后处理不能直接放行。
应该判断：
用户有没有权限？
这个操作是否危险？
是否需要二次确认？
是否只能查不能删？
是否有审批流程？
Agent 场景的后处理，本质上就是“刹车系统”。
没有刹车的 Agent，很危险。
6.4 文案生成场景
文案生成看似简单，其实也需要后处理。
重点包括：
标题是否吸引人
是否有违规词
是否夸大宣传
是否重复
是否口水话太多
是否符合平台风格
是否符合品牌调性
是否包含敏感承诺
是否适合目标人群
比如营销文案里出现：
“全网最低价”
“永久有效”
“100%治愈”
“保证收益”
“国家级第一品牌”
这些都可能有合规风险，需要过滤或替换。
6.5 数据抽取场景
比如从合同、PDF、图片 OCR、网页中抽取信息。
后处理重点是：
字段完整性
字段类型
日期格式
金额格式
单位统一
缺失字段标记
置信度评分
原文位置回溯
多字段一致性校验
例如抽取合同金额：
模型输出：
{
"amount": "100万"
}
后处理可以标准化为：
{
"amount": 1000000,
"currency": "CNY",
"rawText": "100万"
}
这样系统才能继续处理。
七、大模型后处理的推荐架构
一个比较稳的大模型后处理架构，可以分成 7 层。
7.1 第一层：Raw Output 原始输出层
保存模型原始返回。
不要覆盖，不要丢弃。
原始输出是排查问题的证据。
7.2 第二层：Cleaner 清洗层
处理：
空格
换行
乱码
代码块
无关前缀
无关后缀
Markdown 包裹
非法字符
7.3 第三层：Parser 解析层
处理：
JSON 解析
Markdown 解析
HTML 解析
表格解析
工具参数解析
函数调用解析
7.4 第四层：Validator 校验层
处理：
字段校验
类型校验
枚举校验
范围校验
业务规则校验
安全规则校验
7.5 第五层：Repair 修复层
处理：
格式修复
字段补全
类型转换
重新生成
局部重试
规则替换
7.6 第六层：Guardrail 护栏层
处理：
敏感信息过滤
内容安全审核
越权拦截
高风险操作拦截
提示词泄露防护
恶意输出防护
NeMo Guardrails 文档中也强调，可以在大模型应用中加入可编程护栏，对输入、检索、对话和输出等阶段进行约束。
7.7 第七层：Formatter 最终格式化层
处理：
返回给前端
返回给接口
返回给下游系统
生成用户可读文本
生成结构化结果
生成日志记录
八、后处理规则怎么设计？
8.1 规则一：先规则，后模型
能用规则解决的，不要都丢给大模型。
比如：
JSON 提取
手机号脱敏
邮箱脱敏
HTML 转义
字段类型转换
枚举值映射
空行清理
敏感词替换
这些用代码更稳定、更便宜、更快。
大模型适合处理：
语义判断
复杂改写
模糊分类
质量评分
语气调整
事实一致性判断
8.2 规则二：后处理要可配置
不要把所有规则写死在代码里。
建议把规则做成配置：
{
"scene": "customer_service",
"sensitiveWords": ["保证退款", "一定赔偿"],
"requiredFields": ["answer", "intent", "confidence"],
"maxLength": 500,
"needCitation": true
}
不同业务场景使用不同规则。
8.3 规则三：每一步都要有状态
后处理不能只返回最终文本，最好返回处理状态。
比如：
{
"success": true,
"formatValid": true,
"safetyPassed": true,
"repaired": false,
"fallback": false,
"riskLevel": "low",
"finalAnswer": "…"
}
这样线上排查会非常方便。
8.4 规则四：失败不能静默
后处理失败不要假装成功。
比如 JSON 解析失败，就应该记录：
解析失败原因
失败字段
原始输出
修复次数
最终是否兜底
否则系统看起来正常，实际全是脏数据。
8.5 规则五：高风险场景必须人工介入
以下场景不要完全自动化：
资金操作
删除数据
修改权限
法律建议
医疗建议
投资建议
人事决策
账号封禁
大额退款
合同审批
大模型可以辅助，但不应该直接拍板。
九、一个完整的大模型后处理示例
假设用户问：
帮我生成一个营销活动方案，要求输出活动标题、目标人群、优惠策略、风险提示。
模型原始输出：
当然可以，下面是方案：
{
"title": "全网最低价，错过再等一年",
"targetUser": "所有用户",
"coupon": "发放100元无门槛券",
"risk": ""
}
这个方案一定能提升转化率。
这个结果有什么问题？
第一，“全网最低价”可能有合规风险。
第二，“所有用户”太粗糙。
第三，“100 元无门槛券”可能成本过高。
第四，risk 为空。
第五，“一定能提升转化率”是绝对化承诺。
第六，外面包了废话，不是纯 JSON。
后处理流程应该这样：
第一步：提取 JSON
得到：
{
"title": "全网最低价，错过再等一年",
"targetUser": "所有用户",
"coupon": "发放100元无门槛券",
"risk": ""
}
第二步：Schema 校验
发现字段完整，但 risk 为空。
第三步：合规检测
发现：
“全网最低价”风险
“一定能提升转化率”风险
第四步：业务规则校验
发现：
目标人群过宽
优惠策略成本可能过高
缺少预算控制
缺少风控限制
第五步：自动修复
修复后：
{
"title": "限时福利季，老客专属加码",
"targetUser": "近90天有浏览或加购行为、但未完成下单的高意向用户",
"coupon": "按用户分层发放满减券，例如满199减20、满399减50，并设置每日预算上限",
"risk": "需控制优惠券总预算，避免被羊毛党批量领取；活动文案避免使用绝对化承诺。"
}
第六步：最终返回
活动标题：限时福利季，老客专属加码
目标人群：近90天有浏览或加购行为、但未完成下单的高意向用户。
优惠策略：按用户分层发放满减券，例如满199减20、满399减50，并设置每日预算上限。
风险提示：需控制优惠券总预算，避免被羊毛党批量领取；活动文案避免使用绝对化承诺。
这才是一个真正可用的结果。
十、后处理常见坑
10.1 坑一：只靠 Prompt 约束格式
很多人会在 Prompt 里写：
“请严格返回 JSON，不要输出其他内容。”
但模型依然可能输出：
“好的，以下是 JSON。”
所以不能只靠 Prompt，必须有解析和校验。
10.2 坑二：解析失败就直接报错
线上系统不能动不动报错。
更好的方式是：
第一次解析失败 → 自动修复
第二次失败 → 重新生成
第三次失败 → 兜底
高风险场景 → 转人工
10.3 坑三：只校验格式，不校验内容
格式正确不代表内容正确。
比如：
{
"answer": "用户一定可以退款",
"confidence": 0.99
}
JSON 是对的，但业务内容可能是错的。
所以必须做业务校验。
10.4 坑四：把后处理全交给另一个大模型
有些团队会这样设计：
模型 A 生成答案。
模型 B 检查答案。
模型 C 修复答案。
看起来很智能，但成本高、延迟高，而且仍然可能出错。
更好的方式是：
规则优先。
模型辅助。
高风险人工。
关键链路可追踪。
10.5 坑五：没有日志
大模型系统没有日志，基本无法运营。
至少要记录：
输入
Prompt
模型
检索内容
原始输出
后处理结果
失败原因
重试次数
安全命中规则
最终返回结果
十一、大模型后处理和 Prompt 工程是什么关系？
Prompt 工程是“提前约束”。
后处理是“事后治理”。
两者不是替代关系，而是配合关系。
Prompt 做得好，可以减少后处理压力。
后处理做得好，可以兜住模型不稳定。
比如 Prompt 里要求：
你必须输出 JSON，字段包括 title、summary、tags。
后处理里仍然要检查：
是否真的是 JSON
字段是否完整
tags 是否数组
summary 是否为空
是否有敏感内容
成熟的大模型应用，一定是：
Prompt + 结构化输出 + 后处理 + 安全护栏 + 评测监控 一起做。
十二、大模型后处理如何落地到工程代码？
可以抽象成一个 Pipeline：
ModelOutput
↓
CleanProcessor
↓
JsonParser
↓
SchemaValidator
↓
BusinessValidator
↓
SafetyChecker
↓
RepairProcessor
↓
ResultFormatter
↓
FinalResponse
伪代码如下：
public ProcessResult process(String rawOutput, ProcessContext context) {
// 1. 原始输出清洗
String cleaned = cleaner.clean(rawOutput);
// 2. 结构解析
ParseResult parseResult = parser.parse(cleaned);
if (!parseResult.isSuccess()) {
parseResult = repairService.repairFormat(rawOutput, context);
}
// 3. Schema 校验
ValidateResult schemaResult = schemaValidator.validate(parseResult.getData());
if (!schemaResult.isPass()) {
parseResult = repairService.repairSchema(parseResult.getData(), schemaResult);
}
// 4. 业务规则校验
ValidateResult bizResult = businessValidator.validate(parseResult.getData(), context);
if (!bizResult.isPass()) {
return fallbackService.handle(bizResult, context);
}
// 5. 安全校验
SafetyResult safetyResult = safetyChecker.check(parseResult.getData());
if (!safetyResult.isPass()) {
return fallbackService.handleSafety(safetyResult, context);
}
// 6. 最终格式化
return formatter.format(parseResult.getData(), context);
}
核心思想不是代码多复杂，而是流程要完整。
十三、大模型后处理的最佳实践
13.1 结构化输出优先
凡是要给系统用的结果，尽量不要让模型自由发挥。
优先使用：
JSON
Schema
枚举
固定字段
固定类型
固定模板
13.2 重要链路必须可回放
线上出现问题时，要能完整复现：
同一个输入
同一个 Prompt
同一个检索结果
同一个模型参数
同一个后处理规则
否则问题很难定位。
13.3 对不同场景设置不同规则
不要一套规则打天下。
客服、营销、代码生成、数据抽取、Agent、知识库问答，后处理规则都不一样。
13.4 低风险自动化，高风险人工化
低风险场景可以自动修复。
比如格式错误、错别字、换行问题。
高风险场景要人工审核。
比如合同、资金、医疗、法律、权限、删除操作。
13.5 后处理规则要持续迭代
后处理不是一次写完就结束。
上线后要根据真实问题持续补规则：
用户投诉了什么？
模型经常错在哪里？
哪些字段经常缺失？
哪些场景经常触发兜底？
哪些答案经常被人工驳回？
这些都要反向优化 Prompt、规则和评测集。
十四、总结：大模型后处理，是AI应用上线的最后一道防线
大模型后处理，表面上是在处理模型输出，本质上是在做一件事：
把不确定的生成结果，变成确定的业务结果。
没有后处理的大模型应用，通常只能做 Demo。
有后处理的大模型应用，才有机会真正上线。
最后记住这 6 句话：
第一，模型输出不能直接信。
第二，格式正确不代表内容正确。
第三，Prompt 约束不能代替后处理。
第四，后处理要同时做格式、内容、安全、业务校验。
第五，高风险场景必须有兜底和人工介入。
第六，所有后处理过程都要可记录、可追踪、可复盘。
真正成熟的大模型系统，不是让模型“自由发挥”，而是让模型在规则、结构、护栏和业务流程里稳定发挥。
这就是大模型后处理的核心价值。
