大模型系统的分层设计与体验优化思路

在大模型落地这件事上，单靠 Prompt 往往只能解决'怎么让模型答得像样'这一层问题。真到业务里，边界、稳定性、知识更新、成本控制这些麻烦会很快冒出来。与其把所有压力都压给模型，不如把它当成系统里的一个核心能力，再拆出几个配套模块一起工作。

先把场景分清楚

做大模型应用做久了，通常会遇到几类很典型的问题：有些请求不该回复；有些请求要按不同策略回复；有些问题模型本身答不好，但手里其实有正确答案；还有一些领域问题，得先识别出来，再走专项流程。

这些问题背后其实都绕不开一个词：边界。模型不是万能接口，系统得先判断'用户在问什么'，再决定'该怎么回'。在传统对话系统里，这一步通常叫意图识别，放到 NLP 里，就是文本分类。

意图识别怎么做

以客服里的售后维修为例，这类问题往往高频、敏感，还经常需要带一点安抚语气。要优化这类体验，先得把它识别出来。

实现方式不少，选哪种主要看问题特征、数据量和延迟要求。我一般会按下面几种思路去看：

规则、关键词、正则：适合特征很明显、变化不大的场景，快，也好维护，但扩展性一般。
经典分类模型：比如 fasttext、TextCNN、BERT for Classification，数据量中等时比较稳，延迟也可控。
检索式划分：把意图当成向量空间里的近邻问题来做，意图经常变动时比较顺手。
用大模型做分类器：靠 Prompt 做零样本或少样本分类，上手快，但成本和延迟都更高。

这里我更倾向把它当成一个独立模块，而不是'交给模型顺手顺一下'。很多时候，分流做得越早，后面的回复策略越容易控。

回复策略别只想着生成

场景一旦分出来，后面的事反而更具体了。对话系统里，不同类型的问题，回复方式通常完全不是一回事。

拒绝回复

有些请求本来就不该进入正常回答流程，比如超出支持范围的问题、观点争议类问题、带诱导性的安全风险问题，或者知识库压根没内容。这时候硬答，通常只会把体验弄得更差。

常见做法有三种：

固定回复：像'这方面我还不太确定，需要再学习一下'。简单直接，缺点是比较硬。
大模型生成安抚语：让模型按提示生成更自然的拒答内容，语气会更柔和，但不一定每次都稳定。
推荐问或追问：把用户往可回答的方向拉，比如'你是不是想问 XX？'或者'能补充一下具体情况吗？'。这类方式在实际产品里往往更实用。

很多场景里，写死回复并不丢人。它不优雅，但稳，尤其在边界很明确的时候，比让模型自由发挥省心得多。

拆解用户提问后再回复

用户一句话里常常混着好几层信息。先拆，再回，通常比直接生成更靠谱。

情绪识别和安抚：客服场景里，先判断用户是不是在抱怨，再决定语气和措辞。
关键词强调：有些词必须保留，或者必须被明确提到，这就需要提前提取并约束输出。
端侧适配：手机端通常要短一点，桌面端可以展开一些。不是所有场景都适合一股脑输出长回答。
指令执行：像'播放音乐'这种请求，光给文字不够，还得返回结构化结果，让客户端去调起对应能力，这里就会用到 Function Calling 或 Tool Use。

这类流程里，模型更像最后一公里的表达层，前面的识别、提取、路由，还是得靠系统自己做。

多轮对话管理

多轮对话最麻烦的地方，不是'能不能聊下去'，而是'该记什么、什么时候记、记多久'。最简单的做法是把历史全拼进去，模型确实能扛一部分，但上下文一长，噪声也会一起上来。

常见方案大概有几类：

直接拼接历史对话：适合上下文依赖不强的场景，实现最省事。
DM 模块 + NER：把对话管理和槽位继承单独做出来，结构化更强，适合任务型对话。
摘要压缩：把历史对话压成摘要，减少 Token 占用，也能降低无关信息干扰。

如果系统已经开始依赖多轮上下文，我更倾向尽早把 DM 从大模型里拆出来。这样可控性会高很多，后面排查问题也更容易。

知识问题还是要单独处理

大模型在通用知识上看起来很强，但一碰到领域知识、最新信息，幻觉就会冒出来。这个问题绕不开。

常见的两条路是：

微调（Fine-tuning）：把领域知识灌进模型里，效果更内化，但成本高，更新也慢，还可能把通用能力带偏。
外挂知识库（RAG）：先检索，再把相关内容塞进 Prompt，让模型基于检索结果回答。灵活，更新快，但很吃检索质量。

RAG 其实已经把'知识维护'从模型里拆出来了。拆出来之后，很多老问题就能借搜索和检索系统的思路继续优化：召回、精排、多路检索、混合检索，这些都不是新东西，只是以前服务的是搜索，现在服务的是模型。

比如混合检索就很实用，关键词匹配和向量相似度一起上，通常比单打一更稳。

Chunking 也别小看。切得太碎，上下文不完整；切得太大，召回回来一堆噪声。元数据过滤同样重要，尤其是知识库规模上来以后，不先过滤，后面很多计算都是浪费。

监控和迭代要跟上

系统上线后，体验能不能持续变好，关键看有没有把反馈接住。

日志追踪：记录输入、输出、Token 消耗、耗时、命中的策略模块，排障会省很多时间。
用户反馈：点赞/点踩这类轻反馈，虽然简单，但很能反映真实体验。
A/B 测试：新策略别急着全量，先对比再放开。
成本监控：大模型调用费用不低，Token 用量和异常峰值必须盯住，不然很容易失控。

收尾

大模型系统的优化，不是单纯把模型换得更大，很多时候反而是把职责拆得更清楚。意图识别负责分流，策略路由负责决策，知识库负责补知识，多轮管理负责上下文，监控负责把问题暴露出来。模型留在最擅长的地方，系统其他部分各做各的事，整体体验通常会更稳。

我比较认可这种做法：把大模型从'什么都做'慢慢收敛成'做好最核心的生成和理解'，其他能力交给更适合的模块。这样不一定最炫，但上线以后更耐用。