Article body
正文
引言
单轮问答只是 ChatBI 的入门门槛。真正考验产品成熟度的是多轮对话：用户问完「上月华东区销量 top 5 的产品」，紧接着说「那再看看华北呢」「把时间改成今年」「换成按销售额排」。
这些后续问话里充满了省略和指代——「那」指的是前一轮的分析对象，「华北」承接上一轮的「地区」维度，「今年」替换的是上一轮的「上月」。如果 ChatBI 每轮都当成独立问题来处理，它会完全听不懂这些话，因为单看「那再看看华北呢」这句话，没有任何完整语义。
衡石 ChatBI 构建了一套对话状态管理（Dialogue State Management）引擎，让系统能够跨轮记住上下文、消解指代、增量修改查询计划。 本文将拆解这套引擎如何让连续追问像和人聊天一样自然。
一、多轮对话为什么是 ChatBI 的硬骨头？
1.1 单轮 vs 多轮的本质差异
单轮问答可以建模为「问题 → 查询 → 答案」的纯函数。多轮对话则是一个有状态的过程：当前轮的理解严重依赖历史轮积累的信息。
用户真实的探索路径往往是这样的：
「上月华东销量 top 5 产品」（建立基线）
「华北也加上」（扩展维度）
「只看数码品类」（追加过滤）
「改成按销售额排」（修改排序指标）
「这块帮我导出」（触发动作）
这五句话单独拿出来大多是不完整的。第 2 句的「华北」要依附第 1 句的「地区」维度才有意义；第 4 句的「改成」是对第 1 句排序方式的覆盖，而非新增。
1.2 三种典型的跨轮依赖
指代消解（Anaphora Resolution）：「那」「它」「这个」等代词指向历史对象。例如第 2 句「那再看看华北」中的「那」，指代第 1 句构建的「地区销量排名分析」。
增量修改（Incremental Edit）：后续问话是对前一轮查询计划的局部调整，而非从零新建。例如「改成按销售额排」是替换排序指标，其余条件（地区、时间、top N）全部保留。
上下文继承（Context Inheritance）：后续问话省略了前文已明确的约束。例如第 3 句「只看数码品类」省略了「上月、华东+华北」这些前置条件，但语义上它们依然生效。
二、对话状态：多轮理解的「工作记忆」
2.1 什么是对话状态
衡石 ChatBI 在每一轮交互后，都会维护一份对话状态（Dialogue State），它是当前分析任务的完整结构化描述，包含：
当前查询计划（指标、维度、过滤、排序、时间窗）
已确认的口径与消歧结果
本轮新增/修改的意图
用户身份与权限上下文
会话历史摘要
这份状态就是 ChatBI 的「工作记忆」。每一轮新问话进来，引擎先加载对话状态，再在此基础上做增量更新，而不是从空白开始理解。
2.2 状态的更新机制
当新的一句话到达，引擎执行「状态差量更新」：
提取增量意图：识别这句话相对于当前状态，是「新增条件」「修改条件」还是「纯追问（无结构变化，仅要求解释）」。
合并到状态：把增量意图合并进对话状态。修改类意图覆盖原值（如排序指标从销量改为销售额），新增类意图追加（如过滤条件增加数码品类）。
重新生成计划：基于更新后的状态，重新生成语义计划与查询，保证整轮对话始终映射到一份一致的、最新的查询定义。
这种「状态驱动」的设计，让用户的每一句后续问话都能被准确理解为「对当前分析的某一处调整」，而不是孤立的碎片。
三、指代消解：让「那」「它」不再迷路
3.1 代词回指
当用户说「那再看看华北呢」，引擎需要确定「那」回指什么。衡石采用「最近焦点 + 维度一致性」策略：
最近焦点：对话状态中最近一次激活的分析对象（这里是「地区销量排名」）。
维度一致性校验：「华北」是地区维度的成员，与最近焦点中的「地区」维度匹配，确认回指成立。
如果代词回指的对象在维度上不一致（例如上一轮在讲「产品」维度，这一轮突然说「那换个销售员」），引擎会识别出维度切换，重建分析焦点而非强行套用。
3.2 省略补全
用户常说「再细一点」「拆到省份」「按月看」这类极简指令。这些指令省略了主语和对象，但对话状态里有完整上下文。引擎从状态中提取被操作的维度（如「地区」），再把「拆到省份」理解为「把地区维度下钻到省级成员」，「按月看」理解为「在时间维度上按月份粒度聚合」。省略补全的本质，是把模糊指令映射到状态中具体的、可执行的维度操作。
3.3 跨轮实体绑定
当用户在第一轮说「华东」，引擎不仅解析出「地区=华东」，还会在状态中标记「用户当前关注的地区成员是华东」。后续如果用户对「华东」做进一步操作（「它增长了多少」），实体绑定保证「它」能精确定位到华东，而不是重新猜测。
四、增量修改：用「改」代替「重建」
4.1 修改意图的识别
「改成按销售额排」「时间换成今年」「只要数码品类」——这些都属于修改意图。衡石把修改意图细分为四类：
替换（Replace）：用新值覆盖旧值，如排序指标替换。
追加（Add）：在原有基础上增加条件，如新增品类过滤。
删除（Remove）：去掉某个条件，如「不要华北了」。
切换（Toggle）：在同一维度的不同粒度间切换，如「按周看」↔「按月看」。
4.2 修改的安全边界
增量修改不是无限制的。衡石设定了修改的安全边界：
不可删除核心指标：用户可以说「换成销售额」，但不能让一个分析「没有任何指标」——引擎会拒绝并提示。
权限不可越界：追加的过滤条件如果涉及用户无权查看的维度成员，会被自动拦截。
计划一致性校验：每次修改后，引擎校验新计划是否自洽（例如排序指标必须存在于当前查询的指标集中），不自洽则回滚到上一轮有效状态并提示。
4.3 修改的可追溯
每一轮修改都会在对话状态中留下痕迹。用户可以随时查看「当前分析是怎么一步步变成这样的」，甚至可以回退到某一轮的状态。这种可追溯性在严肃分析场景中非常重要——分析师需要向他人解释「为什么这张图是现在这个样子」。
五、上下文压缩：长对话不「健忘」也不「爆内存」
5.1 为什么需要压缩
真实业务对话可能长达十几轮甚至几十轮。如果把每一轮的原文都塞进上下文窗口，不仅会超出大模型上下文长度，还会引入噪声（早期无关轮次干扰当前理解）。
5.2 衡石的压缩策略
结构化状态优先：既然对话状态已经用结构化方式保存了当前分析的完整定义，那么喂给大模型做理解的「上下文」就可以是这份状态摘要，而非全部历史原文。状态摘要只有几百字，却包含了理解当前轮所需的所有关键信息。
历史轮次摘要化：对于早期轮次，引擎定期生成摘要（例如「前 5 轮完成了地区销量排名分析，涉及华东华北、数码品类、按销售额排序」），用摘要替代原文，既保留脉络又节省 token。
关键锚点保留：用户明确确认过的口径、消歧选择等「决策点」作为锚点长期保留，不被压缩，确保后续对话不会偏离用户已确认的方向。
六、多轮对话的工程挑战
6.1 状态漂移
长对话中，状态可能因为某轮的误解析而逐渐偏离用户真实意图（状态漂移）。衡石通过两个机制对抗漂移：
用户确认点：在关键节点（如口径选择、维度切换）主动请用户确认，把状态锚定。
显式重述：每轮回答开头用一句话重述「当前分析视角」（如「当前查看：华东+华北地区，数码品类，今年，按销售额排序的 top 产品」），让用户随时发现偏差并纠正。
6.2 多用户并发
企业场景中，同一份看板可能被多个用户同时对话探索。衡石的对话状态是按会话隔离的，每个会话有独立的 state 实例，互不干扰。会话结束后状态可按策略保留一段时间（便于用户回来继续），超时则清理释放资源。
七、技术对比
| 能力 | 无状态单轮 | 规则式多轮 | 状态驱动多轮（衡石） |
|---|---|---|---|
| 连续追问 | 不支持 | 有限（靠硬编码模板） | 完整支持 |
| 指代消解 | 不支持 | 弱 | 强（维度一致性校验） |
| 增量修改 | 每次重建 | 部分 | 完整（替换/追加/删除/切换） |
| 长对话稳定性 | 易出错 | 易漂移 | 压缩+锚点保障 |
八、FAQ
Q1：用户中途切换了完全不相关的主题，ChatBI 能处理吗？ 能。当新问话与当前对话状态在维度、指标上完全不相关时，引擎会识别为「话题切换」，自动开启新的对话分支或重置状态，而非强行关联。
Q2：多轮对话会泄露其他人的分析上下文吗？ 不会。对话状态严格按会话隔离，并受行级权限约束，用户只能在自己有权限的范围内做多轮探索。
Q3：如果某一轮 ChatBI 理解错了，会影响后面所有轮吗？ 由于每轮都有显式重述和确认点，错误通常会被尽早发现。即便发生，用户可以用「不对，我是说……」纠正，引擎会基于纠正更新状态，不会让错误无限放大。
九、总结
多轮对话是 ChatBI 从「问答玩具」走向「分析伙伴」的分水岭。衡石 ChatBI 通过对话状态管理 + 指代消解 + 增量修改 + 上下文压缩四件套，让系统能够像人一样记住前文、理解省略、接受纠正。
核心思想只有一句话：把每一轮对话都看成对「当前分析状态」的一次有控制的更新，而不是一次孤立的理解。 当用户说出「那再看看华北」时，ChatBI 听到的不是这六个字，而是「在刚刚那个分析里，把地区维度扩展到华北」——这才是真正的自然语言分析体验。
下一篇我们聊：当 ChatBI 给出了答案，你怎么知道它答得对、数据从哪来？