AI数字人为什么聊几轮就“记混了”？会话上下文与状态管理是关键

---

一、什么叫会话上下文？

人与人聊天时，很少每句话都把完整信息重新说一遍。

例如：

用户：“Growth版本多少钱？”

数字人回答后，用户接着问：

“那企业版呢？”

这里的“企业版呢”实际上省略了大量信息。

完整意思应该是：

“那企业版的价格是多少？”

再例如：

“它支持API吗？”

系统必须知道“它”指的是刚才讨论的哪个产品。

所以数字人不能只看用户当前这一句话。

它还需要知道：

• 前面聊了什么
• 当前正在讨论哪个产品
• 用户刚才问的是价格还是功能
• “它”“这个”“那个”分别指什么
• 当前话题有没有发生变化

这些信息合起来，就是会话上下文。

---

二、为什么只把聊天记录全部发给大模型还不够？

最简单的实现方式是：

每次用户提问，都把之前所有聊天记录一起交给大模型。

例如：

第一轮问题 + 回答；
第二轮问题 + 回答；
第三轮问题 + 回答；
第四轮再一起提交。

刚开始确实能用。

但随着聊天越来越长，会逐渐出现几个问题。

上下文越来越大

聊天历史越长，每次请求需要处理的文字越多。

这会直接增加：

• Token消耗
• 模型处理时间
• 首字响应延迟
• API调用成本

聊几十轮以后，为了回答用户一句很简单的问题，系统可能要重新处理前面几千甚至几万字。

显然效率很低。

---

三、上下文太长为什么反而可能回答得更差？

很多人认为：

给大模型的信息越多，回答应该越准确。

实际上并不一定。

例如用户现在正在咨询：

“企业版能不能私有化部署？”

但是上下文里同时还有之前讨论的：

Growth版本价格；
iOS SDK；
语音服务；
知识库功能；
其他产品资料。

大量旧信息混在一起后，大模型需要判断哪些内容仍然重要。

如果没有进行上下文管理，就可能出现：

重要信息被大量历史内容淹没。

甚至可能发生产品串线。

例如上一轮讨论A产品，这一轮已经切换到B产品，但旧上下文里A产品出现次数更多，模型可能错误地继续围绕A产品回答。

因此，多轮对话不是简单地“保存聊天记录”。

还需要判断：

哪些信息现在仍然有效。

---

四、什么是Session会话状态？

企业数字人通常会给每一次对话分配一个Session，也就是会话。

一个Session里可以保存当前用户的重要状态。

例如：

当前咨询产品：企业版数字人
当前问题类型：部署
用户关注点：私有化部署
上一轮产品：Growth
当前语言：中文
是否已经留资：否

这样，当用户接着问：

“那需要几张显卡？”

系统不需要完全依赖大模型猜测。

它已经知道：

当前正在讨论的是企业版私有化部署。

于是这句话可以被理解成：

“企业版数字人私有化部署需要几张显卡？”

这就是结构化会话状态的作用。

---

五、为什么数字人需要“短期记忆”？

数字人的记忆并不一定意味着永久记住用户说过的所有内容。

对于一次实时交流来说，更重要的是短期记忆。

例如用户在当前会话中已经说明：

“我们公司大概需要20个并发。”

后面用户问：

“那我应该选哪个版本？”

数字人就应该结合刚才的“20个并发”进行回答，而不是再次询问用户需要多少并发。

短期记忆通常包括：

• 当前需求
• 产品偏好
• 用户已经提供的信息
• 当前讨论对象
• 已经回答过的问题
• 尚未解决的问题

做好这一层以后，数字人才能真正有“连续交流”的感觉。

否则每一轮都像第一次见面。

---

六、“这个”“那个”“它”为什么特别考验数字人？

自然语言中存在大量指代。

例如：

“Growth版本支持10个并发吗？”

“它能接知识库吗？”

“这个可以自己部署吗？”

“那企业版呢？”

第二句中的“它”，指Growth版本。

第三句中的“这个”，可能仍然指Growth版本。

第四句突然出现“企业版”，代表用户已经开始比较另一个产品。

系统需要不断维护当前实体。

可以简单理解成：

当前主实体 = Growth

当用户说：

“它支持API吗？”

系统把“它”解析成Growth。

当用户说：

“那Enterprise呢？”

系统则更新：

当前主实体 = Enterprise

后续再出现“它”，默认指Enterprise。

这种技术通常叫实体状态跟踪。

它对产品咨询型数字人尤其重要。

---

七、为什么不同产品容易“串参数”？

假设一家企业同时有三个套餐：

Basic
Growth
Enterprise

用户先问：

“Growth支持多少并发？”

之后又问：

“Enterprise能不能私有化部署？”

再继续问：

“价格是多少？”

这时候“价格是多少”应该指Enterprise。

如果系统只从整段历史记录里做模糊判断，很可能重新抓到Growth。

于是就会出现：

用户明明在问Enterprise，数字人却回答Growth的价格。

因此，对企业数字人来说，产品名称、版本、套餐等关键对象最好不要只保存在自然语言聊天记录里。

还可以维护结构化状态：

current_product = Enterprise
current_topic = price
previous_product = Growth

这样可以明显减少参数串线。

---

八、用户突然换话题怎么办？

用户不会一直围绕同一个问题聊天。

例如：

“Enterprise支持多少并发？”

“能不能私有化部署？”

“对了，你们公司在哪里？”

第三句话已经完全换了话题。

如果数字人没有话题切换判断，可能会继续尝试把“公司在哪里”与私有化部署关联起来。

所以系统需要判断：

当前问题是上一轮的延续，还是一个新的话题？

例如可以通过：

• 语义相似度
• 用户当前意图
• 关键词变化
• 当前实体变化
• 大模型意图判断

来识别Topic Shift，也就是话题切换。

检测到明显的新话题后，就应该降低旧上下文的权重，而不是继续强行关联。

---

九、历史消息应该怎么压缩？

长对话不能无限保存全文。

比较常见的处理方式是：

保留最近几轮原始对话

例如最近5轮保持完整。

因为最近内容与当前问题通常最相关。

更早的内容生成摘要

例如原来的20轮聊天：

用户先咨询价格；
随后重点了解企业版；
用户需要约20个并发；
关注私有化部署；
目前尚未确定购买方案。

这样几千字的聊天记录，可以被压缩成几百字的状态摘要。

提交给大模型时变成：

会话摘要 + 最近几轮聊天 + 当前问题。

这样既能保留关键记忆，又能控制上下文长度。

---

十、哪些内容应该长期保存，哪些不应该？

并不是用户说的每句话都值得长期保存。

例如：

“好的。”

“我知道了。”

“嗯。”

这些内容对后续对话价值很低。

真正值得保存的是结构化业务信息，例如：

用户需要20个并发；
用户希望支持私有化部署；
用户对iOS SDK感兴趣；
用户已经询问企业报价。

但这里还要区分：

当前会话状态和长期用户资料。

当前会话结束后，一些临时信息可以清除。

如果涉及跨会话记忆，则还需要考虑用户授权、隐私和数据保存策略。

因此，成熟的数字人系统不应该什么都记，而应该：

只保留后续业务真正需要的信息。

---

十一、为什么对话状态还能减少重复提问？

一个比较让用户反感的问题是：

数字人反复询问已经回答过的信息。

例如：

数字人：“您大概需要多少并发？”

用户：“20个。”

聊了几轮以后，数字人又问：

“请问您预计需要多少并发？”

用户会明显感觉：

刚才不是已经告诉你了吗？

如果系统维护：

required_concurrency = 20

后面就不应该再次询问。

它可以直接说：

“按照您刚才提到的20个并发需求……”

这种细节会明显提升真人交流感。

---

十二、会话状态还能和Function Call结合

状态管理不仅影响聊天。

它还可以直接影响业务动作。

例如用户说：

“帮我预约下周的产品演示。”

系统还需要确认：

姓名；
联系方式；
时间；
产品版本。

用户逐步提供：

“张先生。”

“周三下午。”

“主要看企业版。”

系统可以持续更新：

name = 张先生
time = 周三下午
product = Enterprise
phone = 未提供

系统发现还缺手机号，就只需要继续询问手机号。

信息完整以后，再触发预约接口或Function Call。

这样，数字人就从普通聊天升级成真正可以完成业务流程的智能入口。

---

十三、企业应该怎么测试数字人的多轮对话？

不要只测试一问一答。

可以专门设计下面这样的连续对话：

第一轮：

“Growth版本多少钱？”

第二轮：

“那企业版呢？”

第三轮：

“它支持私有化吗？”

第四轮：

“需要什么服务器？”

第五轮：

“对了，你们支持iOS吗？”

第六轮：

“那刚才私有化的最低配置继续说一下。”

这里同时测试了：

• 指代识别
• 产品切换
• 话题切换
• 上下文恢复
• 多轮记忆

还可以故意加入：

“不是Growth，我刚才说的是Enterprise。”

观察数字人能不能修正之前的状态。

真正好的多轮对话系统，应该允许用户自然纠正，而不是错误状态一旦产生，后面每一轮都继续错下去。

---

十四、金福来数字人的多轮对话体验为什么要做好状态管理？

金福来数字人应用在官网接待、产品咨询、知识问答和客户留资场景时，用户通常不会只问一个问题。

一次真实咨询可能连续经历：

产品了解 → 功能比较 → 价格询问 → 部署方式 → 技术细节 → 联系销售。

如果每一轮都当成独立问题，数字人虽然“每句话都会回答”，但整体体验仍然会非常机械。

因此，多轮交互需要重点处理：

• Session会话管理
• 最近对话上下文
• 当前产品实体
• 用户已提供的信息
• 当前业务意图
• 话题切换
• 历史消息压缩
• 关键信息结构化
• Function Call状态衔接

这些能力做好以后，数字人才能真正做到：

记得刚才聊了什么，也知道现在正在聊什么。

结语

AI数字人聊几轮以后开始答非所问，不一定是大模型变笨了。

很多时候，是系统没有管理好对话状态。

上下文负责保留前后关系；
Session负责区分每一次会话；
实体状态负责知道“它”到底指哪个产品；
话题检测负责判断用户是不是换了问题；
历史压缩负责避免上下文越来越长；
结构化状态则负责记住用户已经提供的重要信息。

真正自然的AI数字人，不应该只是每一轮都能回答。

更重要的是，连续聊十轮之后，它仍然知道：

你刚才问过什么、现在在说什么、下一步还缺什么。