当你开始频繁说“模型这个回答有点问题”，问题往往不在模型
在很多大模型项目里，都会出现一种非常熟悉的场景。
模型上线后，偶尔会出现一些“让人皱眉”的回答，于是会议室里开始出现这些声音：
- “模型这里理解错了。”
- “这个场景模型还是不够聪明。”
- “要不要再微调一版？”
一开始，这些讨论是合理的。
但如果你发现：
- 同一类问题反复出现
- 每次都在讨论“要不要再调模型”
- 却很少有人问“这个判断本来该不该交给模型”
那这通常意味着一件事：
你已经开始让模型背它不该背的锅了。
而这，往往是系统走向失控的起点。
一个先讲清楚的前提：模型不是“责任主体”，系统才是
在工程上，有一个非常重要、但经常被模糊掉的事实：
模型只是系统的一部分，
但风险的责任主体，永远是系统。
模型负责的是：
- 生成
- 语言理解
- 模式匹配
- 统计推断
而系统负责的是：
- 能不能用
- 该不该用
- 出问题怎么办
- 最坏情况谁兜底
如果你把“系统责任”直接压给模型，
那你其实是在做一件非常危险的事：
用一个概率模型，去承担确定性风险。
模型职责 vs 系统职责边界示意图
第一类模型不该背的锅：合规与法律风险
这是最典型、也是最致命的一类。
很多团队一开始会想：
- “模型已经很聪明了”
- “我们在微调里把规则喂给它”
- “它应该能记住哪些能说，哪些不能说”
但这里有一个必须直视的现实：
合规不是“知识问题”，而是“责任问题”。
模型的问题包括：
- 无法真正理解法律责任
- 无法感知语境变化带来的风险
- 无法保证在所有问法下行为一致
你可以让模型知道规则，
但你永远不能让模型承担规则失效的后果。
所以这类风险，必须交给系统层：
- 规则引擎
- 黑白名单
- 强制拒答
- 人工介入
而不是靠模型“记得住”。
第二类：该不该答的问题（而不是怎么答）
这是很多项目最容易混淆的一点。
模型非常擅长解决的问题是：
“如果要回答，该怎么组织语言”
但它并不擅长、也不该负责：
“这个问题现在该不该回答”
比如：
- 是否涉及隐私
- 是否超出服务范围
- 是否需要人工确认
- 是否存在歧义或风险
如果你把这些判断交给模型，就会出现一种非常危险的情况：
模型在“能回答”和“该回答”之间，永远倾向前者。
因为从统计学习角度看，
“回答点什么”几乎总比“拒绝”更容易拟合训练数据。
这类风险，必须由系统层解决：
- 问题分类
- 风险判定
- 流程分流
而不是靠模型“自觉”。
第三类：极端输入与恶意试探
这是线上系统迟早会面对的一类输入。
包括但不限于：
- 刻意绕规则的问法
- 多轮引导、诱导
- 组合条件试探
- 利用上下文“挖坑”
很多人会说：
“那我们把这些例子加到训练数据里不就好了？”
这在规模上是不可行的。
原因很简单：
- 极端输入是组合爆炸的
- 模型永远学不完
- 而攻击者永远有耐心
如果你指望模型“学会所有坏输入”，
那你迟早会被现实教育。
正确做法是：
在系统层，限制模型能接触到的输入空间。
包括：
- 输入预处理
- 模式检测
- 风险拦截
- 强制打断对话
模型不该背“防御无限输入”的锅。
极端输入防御：系统层 vs 模型层对比
第四类：业务规则的确定性执行
很多业务规则看起来“可以解释”，但它们本质上是：
- 有严格条件
- 有明确优先级
- 有责任后果
例如：
- 退款条件
- 权限校验
- 状态机逻辑
- 流程分支
你可以让模型“解释这些规则”，
但不能让模型来执行这些规则。
原因在于：
模型生成的是“看起来合理的结果”，
而不是“保证正确的结果”。
只要你允许模型在这些地方“灵活发挥”，
那你就是在用概率系统替代确定性系统。
这不是智能，这是失控。
第五类：错误的兜底逻辑
这是一个非常隐蔽、但非常常见的设计错误。
当系统设计不完整时，很多团队会下意识做一件事：
“如果前面都没命中，就交给模型兜底。”
听起来很合理，但实际上极其危险。
因为这意味着：
- 模型接到的，往往是最不确定的输入
- 而这些输入，恰恰是风险最高的
于是模型成了：
- 最后一道防线
- 也是最不可靠的一道防线
正确的兜底逻辑，应该是：
- 明确失败
- 转人工
- 提示限制
而不是：
“那就让模型随便说点什么吧。”
模型不该背“兜底失败”的锅。
第六类：行为一致性的保证
很多人会在评估中发现：
- 同样的问题
- 不同时间
- 模型回答略有差异
于是开始想：
- 再微调一轮
- 再调 temperature
- 再加强约束
但你要清楚一件事：
模型天然是概率系统，
它不可能保证 100% 行为一致。
如果你的业务场景要求：
- 强一致性
- 可复现性
- 可审计性
那这就是系统层该承担的责任：
- 模板
- 固定回复
- 规则覆盖
- 决策缓存
而不是让模型“每次都别变”。
一致性要求：系统锁定 vs 模型概率输出
一个非常重要的工程转折点：你开始区分“能力问题”和“责任问题”
成熟团队和初级团队的一个关键区别在于：
初级团队：
“这个地方模型不行，得再调。”
成熟团队：
“这个地方，本来就不该交给模型。”
当你开始做出这种区分时，你会发现：
- 模型突然“变稳定”了
- 风险下降了
- 调参需求反而变少了
不是模型变强了，
而是你把不该给它的锅拿走了。
一个非常实用的自检问题（强烈建议你用）
当模型在某个点上反复出问题时，你可以问自己一句话：
如果这个判断错了，
我们愿不愿意让模型来承担后果？
- 如果不愿意 → 这就不该是模型的责任
- 如果愿意 → 那才是模型可以介入的地方
这个问题，往往比任何技术讨论都有效。
一个简化但非常清晰的责任分层示意
输入是否合法？ → 系统
是否允许回答？ → 系统
是否需要人工？ → 系统
回答如何表达？ → 模型
自然语言生成 → 模型
只要你把这条线画清楚，
很多“模型问题”会自然消失。
在很多项目中，模型之所以“背锅”，并不是它能力不足，而是系统没有把责任边界画清楚。用LLaMA-Factory online把模型微调、行为评估和系统策略拆开验证，能更早识别出：哪些问题该继续优化模型，哪些问题本就应该交给系统解决。
总结：模型不是替罪羊，系统才是负责人
我用一句话，把这篇文章彻底收住：
真正成熟的系统，不是模型什么都能做，
而是模型只做它该做的事。
当你开始：
- 不再让模型兜底
- 不再让模型背合规锅
- 不再让模型执行规则
你会发现：
- 模型反而更稳定
- 项目反而更可控
- 上线反而更安心
这不是“削弱模型”，
而是让模型回到它该在的位置上。
而这一步，
正是从“模型驱动”走向“系统工程”的标志。
