电商分析Agent多轮追问：超越聊天记录的深度洞察方法

背景

上一篇文章，我们完成了电商分析Agent从问答Demo到处理单次业务问题的最小闭环。核心验证了“单次业务问题能否跑通”：用户查询GMV，系统能返回数据；用户追问下跌原因，系统能沿着区域、订单结构、用户规模、品类、漏斗、退款这条预设分析链进行深度挖掘。

然而，当这条主线跑通后，一个更贴近现实的挑战立刻显现：真实的业务人员不会在每次追问时都完整复述所有条件。如果说上一篇解决了“系统能否分析”，那么本篇要攻克的核心难题是“在连续追问中，系统能否准确继承并管理关键业务参数”。

典型的业务对话场景是这样的：

用户：昨天 GMV 怎么样？
系统：昨天 GMV 为 3841.30。
用户：那华东呢？
系统：继承“昨天 + GMV”，只把范围切到华东。
用户：那女装呢？
系统：继续继承时间和分析上下文，只切到品类。
用户：那退款率呢？
系统：继承上一轮范围，把指标切到退款率。

如果系统仅将对话视为普通的聊天记录，全部塞给大语言模型让其自行“推测”上下文，结果会怎样？在严谨的业务分析场景下，这种“推测”极不稳定。“那华东呢”缺失了指标和时间信息；“那退款率呢”则缺少分析范围；而“活跃用户怎么样”本身就可能存在口径歧义。让模型猜对一次不难，难的是让它每次都依据同一套业务规则精准理解，并在出错时能快速定位根源。

因此，在这个项目中，我们将宏大的“多轮对话”命题，收敛为一个更具体、更务实的目标：对于业务型Agent，首要任务并非构建复杂的长期记忆，而是必须建立一套“最小业务记忆”体系。

聊天记录的局限性

设计多轮对话时，一个常见的初步方案是“完整保存历史聊天消息”。这固然有用，但对于一个电商分析Agent而言，仅依赖于此远远不够。

根本原因在于：业务场景下的连续追问，本质是“参数继承”，而非开放式的闲聊。

缺乏结构化的继承逻辑，下面这种看似简单的对话极易出错：

用户：昨天 GMV 怎么样？
用户：那华东呢？

第二句“那华东呢”，本身并未指明要查看GMV、订单量、退款率，还是进行根因分析。大模型或许能根据聊天历史猜测，但从系统设计角度看，它无法明确这句话具体继承了哪些参数。若下次用户先问“退款率怎么样”，再问“那华东呢”，同一句追问的含义就彻底改变了。

“那华东呢”真正的业务语义是：

沿用上一轮的指标、日期和问题类型，仅替换 region = 华东。

同理，“那女装呢”意味着：

沿用上一轮的时间和范围，将分析维度切换到 category = 女装。

“那退款率呢”则更为特殊，它不是切换区域或品类，而是将当前上下文中的核心指标切换为退款率。如果系统仅保存聊天全文，大模型或许能理解；但若要让此过程稳定、可测试、可复用，就不能仅依赖模型的临场发挥。

这正是多轮对话理解必须拆解为结构化状态管理的原因。

定义“最小业务记忆”

在这个项目中，我们并未一开始就设计复杂的长期记忆或完整用户画像。当前定义的“最小业务记忆”，仅记录与分析链条强相关的几类状态信息：

session_state:
  last_intent
  last_metric
  last_date
  last_region
  last_category
  pending_clarification

这些字段数量不多，但精准覆盖了电商运营追问中最易丢失的关键参数类型。

last_intent 记录上一轮是标准查询、区域对比、用户分析还是根因分析。last_metric 记录上一轮查看的是GMV、订单量、DAU、活跃买家还是退款率。last_date 专门解决“那昨天呢”“那前天呢”这类时间延续性问题。last_region 和 last_category 则应对“那华东呢”“那女装呢”这类维度切换追问。而 pending_clarification 状态，用于处理系统已发起提问、用户下一句仅回答“DAU”或“活跃买家”的澄清场景。

这层设计的重点，不在于让系统记住更多，而在于只记住那些会影响业务分析口径的关键参数。因为在业务分析中，真正的风险并非遗忘闲聊内容，而是错误地继承了日期、指标、区域或品类。

指标词典：稳定业务口径的基石

建立多轮记忆有一个重要前提：系统必须明确知晓，用户口中的词汇究竟对应哪个确定的业务指标。

例如，用户可能提及“成交额”、“销售额”、“流水”、“营业额”，但在当前项目中，它们都应被收敛至同一指标：GMV。用户提及“订单量”，在交易分析场景中默认理解为支付订单数。而当用户提及“活跃用户”时，系统就不能随意猜测，因为它可能指DAU（日活跃用户），也可能指活跃买家。

为此，项目补充了一层 metric_dictionary.yaml 配置，将口语表达、业务定义、计算口径和常见混淆项整合在一起。其目的并非构建庞大的术语库，而是先将最高频指标的口径稳定下来。

示例：

gmv:
  aliases: ["成交额", "销售额", "流水", "营业额"]
  business_meaning: "用于衡量平台最核心的交易规模"dau:
  aliases: ["日活", "活跃用户", "活跃人数"]
  disambiguation_required: true

这一步至关重要。如果连指标词都未事先收敛，那么所谓的多轮记忆，记住的很可能只是一堆不稳定的自然语言表述。业务型Agent需要的是：允许用户自由表达，但系统内部必须映射到稳定的指标ID和确定的计算口径。

语义模型：为追问制定业务规则

指标词典解决了“这个词指代什么指标”的问题，但还不够。多轮追问还需要一套规则，来明确“当前这句追问，应该继承什么、替换什么”。

这就是 semantic_model.yaml 的作用。它并非一个完整的数据语义层，而是项目当前阶段的第一版业务语义模型，沉淀了几类简单但极其实用的规则：

conversation_follow_up_rules:
  - pattern: "那华东呢 / 那华南呢"
    interpretation: "继承上一轮的指标、日期和问题类型，只替换 region。"
  - pattern: "那女装呢 / 那家电呢"
    interpretation: "继承上一轮的指标、日期和区域，只切换到 category_l1。"
  - pattern: "那退款率呢"
    interpretation: "继承上一轮的日期和 scope，把指标切换为 refund_rate。"

这层规则让系统的行为更像一位训练有素的初级数据分析师：它无需每次都从头理解整个问题，而是清楚地知道，在当前上下文中，哪些信息应该沿用，哪些信息应该被替换。

例如，用户先问“昨天GMV多少”，再问“那华东呢”，系统不应将“华东”视为孤立的新问题，而应理解为“查询昨天华东地区的GMV”。若继续追问“那退款率呢”，系统应继承当前的日期和范围（华东），将核心指标切换为退款率，而非跳回大盘数据或默认日期。

这也是多轮业务记忆与普通聊天上下文最本质的区别：其首要目标不是让对话更自然流畅，而是确保业务参数在追问中不会丢失。

歧义澄清：一种业务安全机制

初期，我们可能认为用户提问后，系统最好立刻给出答案。但在业务分析场景下，这个想法需要调整。

有些问题若直接回答，反而是一种不负责任。例如：

用户：活跃用户怎么样？
系统：您说的活跃用户，是指 DAU（日活）还是活跃买家？
用户：DAU
系统：继续按 DAU 口径回答。

这里的重点不在于“系统会提问”，而在于“澄清之后，分析链路能够无缝接续”。如果系统只会问一句“你指哪个”，但用户回答后整个分析流程就中断了，那它依然没有完成业务任务。在当前项目中，我们会将待澄清的问题状态存入session state，当用户下一句回答“DAU”或“活跃买家”时，系统能自动接回原来的分析意图、日期和范围，继续执行分析。

这件事看似微小，但对业务型Agent至关重要。因为许多业务词天然存在歧义：活跃用户、转化率、订单量、退款率，都可能对应不同的计算口径。系统可以设置默认值，但绝不能在关键业务口径上持续“隐性猜测”。

实践中的经验与教训

第一个教训，是将多轮对话简单等同于“延长历史消息上下文”。这在通用聊天场景中或许可行，但在数据分析场景下极不稳定。因为系统真正需要继承的是结构化的业务参数，而非整段聊天文本。

第二个教训，是过早追求完整的语义层。初期很容易试图将所有指标、维度、业务域都设计得尽善尽美，但这会让项目变得异常笨重。更稳妥的做法是，先覆盖当前主分析链最需要的高频指标（如GMV、订单、用户、区域、品类、漏斗、退款），确保核心的连续追问能够跑通。

第三个教训，是认为澄清就意味着“系统能力不足”。更准确地说，澄清是一种业务安全机制。尤其在指标口径不明确时，系统主动询问清楚，远比给出一个看似流畅但口径错误的答案更有价值。

第四个教训，是多轮链路必须纳入自动化测试。像“昨天GMV多少 -> 那华东呢 -> 那女装呢 -> 那退款率呢”这样的典型追问链，如果仅依赖手工测试，后续代码改动时极易在不知不觉中破坏逻辑。因此，我们将这类核心链路也纳入系统启动时的验证环节，确保每次启动都能检查多轮追问的逻辑是否依然稳固。

当前方案的边界

必须明确，这套“最小业务记忆”方案，尚不是一个完整的企业级对话系统。它目前主要解决电商经营分析场景下的短链连续追问问题，并未涉及长期的用户偏好记忆、跨天跨会话的记忆，也未覆盖所有复杂的指标口径。

此外，metric_dictionary.yaml 和 semantic_model.yaml 也只是第一版。它们当前更接近于一个轻量的业务语义层，核心作用是将高频的用户表达收敛到稳定的系统口径，而非一个面面俱到的数据治理平台。

尽管如此，这个阶段的价值已非常清晰：系统不再仅仅是“记得用户刚才说了什么”，而是开始理解“当前的分析任务还缺什么参数、哪些参数应该被继承、哪些关键口径绝对不能模糊处理”。这，正是业务智能体走向真正实用的关键一步。

来源：互联网