1. 项目背景为什么我们需要Stateful Analytics最近在给某个业务域搭数据分析门户我们内部叫DataAI Portal的时候遇到一个特别典型的问题现有的AI问答分析工具单个问题答得还行但一进入多轮深入分析就明显撑不住。用户问完“这个周期工单量为什么涨了”AI给了原因用户接着问“那这个原因对应的部门分单趋势呢”AI直接懵掉或者把上一轮已经确认过的筛选条件给忘了重新给你一套驴唇不对马嘴的答案。这个问题说白了就是无状态分析。传统BI工具是典型的无状态每次拖拽一个图表系统只执行一次查询。ChatBI做得好一点的也就是在单轮对话里做NL2SQL把自然语言转成SQL执行完就结束。但数据分析本身是一个逐步收敛的过程分析师的工作流是看概览、发现异常、下钻维度、验证假设、对比方案、输出结论——这中间每一步都依赖上一步的上下文。如果AI每次回答都“失忆”用户的思路就得反复重述分析效率甚至比纯手工做报表还低。所谓Stateful Analytics就是把“对话状态”和“分析上下文”真正持久化下来让AI在同一个分析会话里记住已经确认的业务口径、已经选定的筛选条件、已经生成的中间结果、甚至用户否定了哪些方向。这套思路不完全是新技术但它改变了AI数据分析的产品形态从“问答工具”变成“分析伙伴”。这篇实验报告是DataAI Portal在works_cycles这个场景上的一个阶段性预览。works_cycles是我们内部一套工单生命周期数据记录工单从创建、分派、处理到关闭的完整链路。我们把它跑在持久上下文框架上对比了无状态模式和老式ChatBI的差异结果还是挺有参考价值的。如果你正在做数据产品、AI Agent、或者企业内部智能分析平台这篇内容应该能帮你避开一些我们踩过的坑。2. 整体设计拆解持久上下文的架构思路2.1 我们理解的“状态”到底包含什么把上面的需求翻译成工程问题首先得定义到底什么东西需要被记住我们盘了一圈最终分成四类。第一类是对话状态。也就是用户和AI之间多轮对话的记录包括每轮的问题、生成的SQL、返回的结果摘要。这部分看起来最简单但真正做起来麻烦的是“长度控制”——上下文窗口是有限的全量塞进去很快就把模型窗口撑爆。第二类是业务上下文。比如works_cycles场景里涉及工单状态枚举值待分派、处理中、已解决、已关闭、部门维度层级、SLA计算口径工作日还是自然日、异常判定阈值。这些属于“不说但默认要知道”的知识如果不固化下来AI每次回答都可能自行发挥。第三类是数据血缘状态。某条结论是从哪张表、哪段SQL、哪个筛选条件下算出来的这类信息如果不记录用户追问“你这个数字怎么来的”时AI就没法自证。第四类是探索路径状态。用户已经看过哪些图表、否定了哪些假设、下钻到了哪一层。这决定AI下一步推荐什么方向也是“分析伙伴”和“问答工具”最本质的区别。2.2 为什么用“三层记忆”而不是单一大缓存一开始我们很天真打算把所有状态都塞进Redis或者MongoDB里每次请求全部加载。结果跑了一轮就发现不对上下文一长token开销爆炸响应延迟从2秒变成10秒而且模型被大量历史噪声干扰注意力被稀释。后来参考了一些Agent记忆管理的做法我们把状态拆成三层短期工作记忆、业务长期记忆、探索路径摘要。短期工作记忆对应当前分析会话的操作序列保存最近3到5轮的原始SQL和结果摘要直接注入提示词。业务长期记忆是预置的指标字典和业务规则用向量库存储每次会话开始时做一次检索召回把最相关的口径说明注入系统提示词。探索路径摘要则是把用户已经完成的分析步骤用自然语言浓缩成一小段“分析进展”每轮动态重写。这套设计的好处是该省的省、该留的留。原始查询日志不用全量待在上下文里需要追溯时再按会话ID查而业务规则这种高价值信息不占对话窗口又能稳定提供。下面是两层结构的对比。记忆层级存储内容注入方式更新频率短期工作记忆最近N轮SQL、结果摘要、筛选条件全部注入提示词每轮写入业务长期记忆指标口径、维度枚举、规则字典向量检索Top-K注入低频预置探索路径摘要已完成步骤、已排除假设、当前结论压缩文本注入每轮重写数据血缘SQL与表字段映射、结果来源按需回溯查询追加写入2.3 会话状态如何与持久化存储联动状态光在内存里不算持久真正的持久上下文还要落到存储层。我们的做法是给每个分析会话分配一个全局唯一的会话ID所有状态写入和读取都绑定这个ID。存储引擎用的是PostgreSQL加JSONB字段短期工作记忆和探索路径摘要都以JSON文档形式保存业务长期记忆单独放向量库。读取策略是分层加载每次新对话进来先根据会话ID加载探索路径摘要和业务上下文然后加载最近几轮的工作记忆最后把这三块内容拼接成系统提示。这样既保证每次都带着完整状态又不会把历史全量灌给模型。需要强调的一点是所有状态写入都做异步化处理。用户在对话中点击“下一条分析建议”时接口先返回结果后台再把这一轮的操作记录和状态摘要落库。如果同步等待状态更新完成才返回用户体验会差很多实测里这个优化把平均首字延迟降了大概40%。3. 核心实现与实验过程在works_cycles场景跑起来3.1 works_cycles数据到底是什么先交代一下实验数据。works_cycles是我们内部沉淀的一套模拟业务数据表结构核心是fact_work_order_cycle包含工单ID、创建时间、分派时间、处理完成时间、关闭时间、归属部门、优先级、工单类型、当前状态等字段。从这张表可以衍生出核心分析指标工单平均处理时长、SLA达成率、超时工单占比、部门积压量、时段吞吐量。选择这个场景做实验是因为它有几个很适合验证Stateful Analytics的特征多维组合多可以按部门、优先级、工单类型、时间段任意组合下钻、状态流转复杂工单有明确的阶段变迁、分析链条长用户经常会从总量一路追到单工单明细。这些特征正好能压测出无状态方案的短板。3.2 实验分组与评测指标我们设计了两组对照A组是传统ChatBI模式也就是无状态NL2SQL每轮问题独立解析、独立执行不带任何记忆。B组是DataAI Portal的Stateful Analytics版本使用三层记忆框架每轮都注入业务上下文和探索摘要。两组使用同一个大模型底座、同一套SQL生成链路确保差异只来自状态管理这一层。评测指标定义了四个多轮任务完成率用户发起一个包含“发现问题-下钻-归因”三步的复合任务统计AI是否能在用户不重复信息的前提下完整走完流程上下文一致性第二轮回答中是否仍然命中上一轮确认过的筛选条件比如部门、时间范围平均分析轮次完成同样一份分析报告用户和AI之间来回对话的次数用户修正次数用户因AI忘记或搞错前置条件而做的澄清式修正次数。3.3 状态注入的模板结构持久上下文的核心实现就在提示词组装这一步。我们把状态拼接做成模板化每次请求前动态渲染。简化版结构如下实际线上版本会比这个复杂但骨架就是这个。你是一个数据分析助手正在为用户分析工单生命周期数据。 ## 业务规则 {{ business_context }} ## 当前分析进展 {{ exploration_summary }} ## 最近几轮操作 {% for turn in recent_turns %} [第{{ loop.index }}轮] 用户问{{ turn.question }} 执行SQL{{ turn.sql }} 结果摘要{{ turn.result_summary }} {% endfor %} ## 用户当前问题 {{ current_question }}business_context来自向量检索Top-K召回exploration_summary是路径摘要器实时重写的结果recent_turns只保留最近的3轮。这里有个细节SQL不一定要完整放进去如果SQL很长可以用参数化的方式只放语义摘要比如“按部门维度统计近30天工单量筛选条件是状态为处理中”。语义摘要的好处是大幅压缩token同时保留分析意图。3.4 探索路径摘要的生成策略这个模块是整个系统里最花心思的部分。探索路径摘要不能用简单的“把对话历史拼接起来截断”来糊弄那样会保留大量无关细节还会让模型分不清哪些是用户已经放弃的方向。我们的方案是每轮对话结束后调用一次轻量级摘要模型把“已完成步骤”和“当前结论”提炼成两到三句话。提炼时附带一个强制约束必须包含当前生效的筛选条件。举一个实际例子用户已完成对比3月和4月工单量发现4月上涨23% 进一步按部门下钻定位到技术二部贡献了80%的增量 当前结论技术二部4月工单异常上涨主要集中在中优先级 生效筛选条件时间范围2024年3月1日至4月30日部门全部门下钻前状态全部。这段摘要每次注入系统提示词后模型再回答“为什么涨”之类的问题时就不会再问用户“请问您要看哪个部门”这种蠢问题而是直接接着分析技术二部的线索继续。3.5 评测结果与数据解读跑完一个周期后结果非常明显。B组的多轮任务完成率从A组的52%提升到87%上下文一致性从43%提升到91%这是最核心的两个指标。平均分析轮次从7.2轮下降到3.6轮用户修正次数从平均2.8次降到0.7次。还有一个有趣的副产物B组生成的SQL整体质量也更高。原因可能是业务上下文注入后模型对指标口径的误解变少了不需要在SQL里反复试错。我们统计了SQL首次执行成功率B组是79%A组只有61%。老实说这套方案并不是没有代价。B组的单轮响应延迟比A组高了大概600毫秒主要花在向量检索、摘要重写和提示词组装上。后面我们做了并行化优化把业务上下文检索和探索摘要重写并行处理延迟差距缩小到了200毫秒以内业务上完全可以接受。4. 我们在实现过程中踩过的坑4.1 上下文污染最隐蔽的问题做持久上下文之后我们首先要面对的问题不是“记不住”而是“记太多”。早期版本的探索路径摘要里包含了太多中间推导过程比如“用户先看了总量然后按部门分了一下又看了优先级分布然后切换了时间范围”。这些过程信息灌进去之后模型容易把用户的当前意图和旧意图搞混经常回答到一半突然扯回前几轮的话题。后来做了一版强制收敛摘要只保留“结论”和“当前生效条件”不保留“中间探索过程”。至于用户中间看过多少个分组完全不管。这个收敛效果立竿见影一致性指标从70%出头直接跳到85%以上。本质原因是大模型做多步推理时上下文里的“未完成动作”越多越容易产生幻觉和意图漂移。把已完成的步骤全部标记为“已完成”状态就干净了。4.2 状态过期持久的东西也可能错另一个坑是状态只存不更新。works_cycles是流水型数据每天都有新工单进入如果会话开了一个月之前摘要里写的“当前结论”可能已经过时。我们一开始没做时效处理结果用户隔一周回来继续分析AI还拿着上周的数据说话。解决方式是在探索路径摘要里加时间戳标记并且在业务上下文注入时带上数据集的最近更新时间。每次生成SQL之前系统会检查摘要中的时间条件和数据最新分区是否匹配如果不匹配就自动提示“数据已更新至最新分区是否基于新数据重新分析”。这看起来是个小功能但对实际业务场景来说非常关键。4.3 token成本失控状态不是越多越好持久上下文最容易引发的一个冲动是“什么都有用什么都想存”。有一版我们尝试把最近10轮的操作全部注入结果单轮token消耗翻倍成本上升不说效果反而下降。窗口被历史占满模型给当前问题的注意力就少了。最后我们把短期工作记忆限制在3轮以内再加一条规则如果用户在连续多轮里反复问同一个指标就把这个指标固化为“重点关注项”单独放进业务上下文的临时标记里而不是反复在对话轮次中出现。这样既保证了重点信息不丢失又控制了token总量。4.4 多租户场景下的状态隔离我们的门户对接了多个业务域不同域之间的指标字典完全不同状态绝对不能串。最开始我们只用小范围灰度测试没做严格的租户隔离结果有一次一个业务域的测试账号查到了另一个域的表名虽然只是测试数据但也足够吓一跳。后来在会话ID生成时直接绑定租户编码同时在向量检索业务上下文时加上租户过滤条件确保召回结果只来自当前租户的知识库。这属于架构基础问题建议在动手设计时第一时间考虑不要等出问题再补。5. 实验结果背后的技术要点解析5.1 为什么“语义摘要”比“原始SQL”更适合做上下文有个朋友问过我们为什么工作记忆里不直接放原始SQL而是放语义摘要。这里有个很实在的原因SQL是面向执行引擎的语言它包含的信息对模型理解分析意图并不友好。比如一条SQL里可能写了七八个JOIN和三个子查询模型看到它的第一反应是“这查询好复杂”但它未必能从中理解用户真正想找什么业务答案。语义摘要则是面向意图的语言比如“对比技术二部与其他部门的中优先级工单处理时长差异”。这句话直接把分析对象、对比维度、关注指标都标明了模型拿到之后后续生成SQL的准确率反而更高。当然原始SQL也并非完全没有价值。我们的做法是存储层保留完整操作日志包含原始SQL和返回结果提示词层只注入语义摘要。这样既照顾了上下文效率又保留了追溯能力。5.2 状态版本化未来值得投入的方向做持久上下文做久了你会开始思考一个新的问题如果用户对AI说“不对你换个角度分析”怎么处理呢。这个动作意味着用户希望在此基础上开辟一条新的探索路径而不是继续沿着原路径往下走。我们现在用的是比较简单的方案也就是把探索路径摘要重置为当前的系统问题描述保留业务上下文清空结论信息。更理想的方案是做状态分叉像git分支一样保留原始的探索路径在新分支上重新分析。这样用户可以随时切回之前的分析思路对比结果。这次实验没有做分叉但接下来的迭代版本里我们准备把它纳入规划。5.3 评测方式本身也要讲究最后聊一下评测。很多团队做这类系统习惯用单轮问答的准确率来评价这在无状态方案上是合理的但放到Stateful Analytics上就远远不够。你真正要测的是“跨轮能力”类似于考试里的综合应用题而不是单道填空题。我们后来的评测集专门设计了多轮任务脚本比如“先查A部门工单量再让你给出排名前三的部门再让你针对排名第一的部门做SLA分析最后和全行业平均水平对比”。每个步骤之间都有上下文依赖如果AI在某一步忘记前面的条件后面的答案就全部跑偏。这种评测方式更接近真实用户的使用习惯也更能暴露系统设计中的短板。6. 从Stateful到Contextual下一步的演进方向实验做完之后我们对这套框架的边界也有了更清醒的认识。Stateful Analytics解决的是“记住之前说了什么”但数据分析的下一步是“理解整个业务语境”这已经不是单靠会话状态能覆盖的范畴了。举个例子同一个问题“本月工单处理时长怎么样”放在售后服务场景和放在生产设备维护场景背后隐含的指标关注点完全不同。前者更关心用户等待时间后者更关心停机损失。Stateful只能记住用户在这个会话里表达的内容而Contextual Analytics还需要理解这个业务域的指标体系、组织架构甚至行业基准。我们已经开始尝试在DataAI Portal里引入“数据集画像”概念在分析会话启动时自动加载当前数据集的特征摘要包括表的粒度、关键字段的业务含义、常见分析场景推荐。这本质上是把无状态时代沉淀的数据字典变成一种随时可用的长期上下文。和会话状态的短期上下文配合起来分析体验还会有一次明显提升。另外还有一块是多人协同场景。现在的状态是绑定单个会话的但如果一个分析师把分析会话分享给另一位同事对方能不能接着这个上下文继续分析这涉及到状态的序列化和权限映射目前还没有完全跑通。不过这个方向上我们已经验证了可行性只要把探索路径摘要和业务上下文持久化新用户加入时重新加载一次就能无缝接入之前的分析进度。回到这次works_cycles实验本身我能给出的最直接建议是如果你正准备在团队内落地AI分析工具不要只盯着NL2SQL的准确率一定要把状态设计和评测设计放在同等重要的位置。持久上下文不是让AI多记住几句话而已它是整个分析交互范式变化的基础。这个方向后续能扩展的东西还非常多我们也会持续把实践中的发现更新到后续报告中。
