大模型系统的分层设计与体验优化思路
在大模型落地这件事上，单靠 Prompt 往往只能解决'怎么让模型答得像样'这一层问题。真到业务里，边界、稳定性、知识更新、成本控制这些麻烦会很快冒出来。与其把所有压力都压给模型，不如把它当成系统里的一个核心能力，再拆出几个配套模块一起工作。
先把场景分清楚
做大模型应用做久了，通常会遇到几类很典型的问题：有些请求不该回复；有些请求要按不同策略回复；有些问题模型本身答不好，但手里其实有正确答案；还有一些领域问题，得先识别出来，再走专项流程。
这些问题背后其实都绕不开一个词：边界。模型不是万能接口，系统得先判断'用户在问什么'，再决定'该怎么回'。在传统对话系统里，这一步通常叫意图识别，放到 NLP 里，就是文本分类。
意图识别怎么做
以客服里的售后维修为例，这类问题往往高频、敏感，还经常需要带一点安抚语气。要优化这类体验，先得把它识别出来。
实现方式不少，选哪种主要看问题特征、数据量和延迟要求。我一般会按下面几种思路去看：
- 规则、关键词、正则：适合特征很明显、变化不大的场景，快，也好维护，但扩展性一般。
- 经典分类模型：比如 fasttext、TextCNN、BERT for Classification，数据量中等时比较稳，延迟也可控。
- 检索式划分：把意图当成向量空间里的近邻问题来做，意图经常变动时比较顺手。
- 用大模型做分类器：靠 Prompt 做零样本或少样本分类，上手快，但成本和延迟都更高。
这里我更倾向把它当成一个独立模块，而不是'交给模型顺手顺一下'。很多时候，分流做得越早，后面的回复策略越容易控。
回复策略别只想着生成
场景一旦分出来，后面的事反而更具体了。对话系统里，不同类型的问题，回复方式通常完全不是一回事。
拒绝回复
有些请求本来就不该进入正常回答流程，比如超出支持范围的问题、观点争议类问题、带诱导性的安全风险问题，或者知识库压根没内容。这时候硬答，通常只会把体验弄得更差。
常见做法有三种：
- 固定回复：像'这方面我还不太确定，需要再学习一下'。简单直接，缺点是比较硬。
- 大模型生成安抚语：让模型按提示生成更自然的拒答内容，语气会更柔和，但不一定每次都稳定。
- 推荐问或追问：把用户往可回答的方向拉，比如'你是不是想问 XX？'或者'能补充一下具体情况吗？'。这类方式在实际产品里往往更实用。
很多场景里，写死回复并不丢人。它不优雅，但稳，尤其在边界很明确的时候，比让模型自由发挥省心得多。
拆解用户提问后再回复
用户一句话里常常混着好几层信息。先拆，再回，通常比直接生成更靠谱。
- 情绪识别和安抚：客服场景里，先判断用户是不是在抱怨，再决定语气和措辞。
- 关键词强调：有些词必须保留，或者必须被明确提到，这就需要提前提取并约束输出。
- 端侧适配：手机端通常要短一点，桌面端可以展开一些。不是所有场景都适合一股脑输出长回答。
- 指令执行：像'播放音乐'这种请求，光给文字不够，还得返回结构化结果，让客户端去调起对应能力，这里就会用到 Function Calling 或 Tool Use。
这类流程里，模型更像最后一公里的表达层，前面的识别、提取、路由，还是得靠系统自己做。
多轮对话管理
多轮对话最麻烦的地方，不是'能不能聊下去'，而是'该记什么、什么时候记、记多久'。最简单的做法是把历史全拼进去，模型确实能扛一部分，但上下文一长，噪声也会一起上来。
常见方案大概有几类：
- 直接拼接历史对话：适合上下文依赖不强的场景，实现最省事。
- DM 模块 + NER：把对话管理和槽位继承单独做出来，结构化更强，适合任务型对话。
- 摘要压缩：把历史对话压成摘要，减少 Token 占用，也能降低无关信息干扰。
如果系统已经开始依赖多轮上下文，我更倾向尽早把 DM 从大模型里拆出来。这样可控性会高很多，后面排查问题也更容易。