AI 问数的多轮追问，难点不在聊天，而在上下文

AI 问数的一个重要体验，是用户可以继续追问。

用户问：“上周华东销售怎么样？”

系统回答后，用户接着问：“拆到门店看一下。”

再问：“为什么上海这几家下降？”

再问：“去掉异常门店后趋势如何？”

这就是多轮问数。

看起来像聊天，难点却不在聊天本身。

多轮追问要保留分析上下文

企业数据分析里的上下文包括很多内容：

• •当前分析对象是哪个区域、门店、渠道或商品；
• •当前时间范围是什么；
• •使用了哪个指标口径；
• •上一轮筛选条件是什么；
• •用户有什么权限；
• •已经发现了哪些异常；
• •下一步正在验证哪个假设。

如果系统只把历史聊天文本拼给模型，很容易丢失这些结构化信息。

省略表达很常见

业务用户追问时，经常不会把问题说完整。

他们会说：

• •那去年同期呢？
• •再看一下抖音渠道。
• •把退款去掉。
• •只看直营店。
• •为什么这几家差？

这些问题必须结合前文理解。

如果上下文管理不好，系统可能把“这几家”理解错，把时间范围重置，或者把上轮筛选条件丢掉。

多轮上下文也要受权限约束

权限不是第一轮检查一次就结束。

用户在追问中可能从汇总数据钻到明细数据，从区域数据钻到门店数据，从销售额钻到利润或会员信息。

每一步都需要重新判断权限。

否则系统可能在多轮追问中泄露敏感数据。

需要可回放的分析路径

多轮问数不应该是一串不可追踪的聊天。

企业需要知道用户从哪个问题开始，系统做了哪些查询，使用了哪些过滤条件，得出了什么结论。

这对审计、复盘和错误修正都很重要。

AskTable 的方向

AskTable 的多轮追问应该围绕业务分析过程，而不是单纯模拟聊天。

系统需要维护结构化上下文：问题、指标、维度、过滤条件、权限、图表、结论和下一步建议。

BuildTable 提供稳定的数据模型和语义信息，让多轮分析不至于在字段和口径上漂移。

结论

AI 问数的多轮追问，核心不是让 AI 更会聊天。

核心是让系统记住正在分析什么、按什么口径分析、用户能看什么、下一步要验证什么。

只有上下文可控，多轮问数才能真正服务业务决策。

参考来源

• •Databricks：What is AI/BI Genie?
• •Microsoft Fabric：Create a Fabric data agent
• •Snowflake：Cortex Analyst Semantic Model Specification