随着大模型技术成熟，AI 正在推动数据分析从“工具辅助”到“决策建议和工作流协同”的质变，基于大模型的智能分析技术正在吸引越来越企业的关注。在 InfoQ 举办的 QCon 全球软件开发大会（北京站）上，来自数势科技的 AI 负责人李飞带来了题为《AI 引领的企业级智能分析架构演进与行业实践》的分享，围绕智能分析如何在企业落地，实践中有哪些要点等内容展开。
以下是演讲实录（经 InfoQ 进行不改变原意的编辑整理）。
在过去十几年的中国数字化转型浪潮中，企业的数字化建设进度可以分为三个层次。第一层次是数据仓库，大部分企业已经完成了数仓的建设；第二层次是 BI 系统，这类系统可以通过很多低代码工具帮助业务人员提效。但 BI 系统主要落地在业务域，针对整个公司或集团的数据进行统一汇报时，不同业务域的口径之间并没有拉齐，每个人对数据的口径和理解也是不一致的。到了第三个层次，部分企业已经基于业务场景搭建了指标平台。
要对企业数据进行智能分析，就需要考虑以上这三个层次。当企业存在三层数据系统时，智能分析平台应该建立一个统一的标准来衔接这三层，然后形成上层应用的统一入口，这就是所谓的 MCP。有了 MCP 这样的统一协议，上层的智能分析就可以理解并使用这些数据了。
在工具层面，企业内部也有很多能力和系统。例如研发人员会使用 Python、SQL 做分析，业务人员会用低代码平台开发各种组件等等。一家成熟的，经历了数字化转型的企业，内部的工具和组件的数量会很多，而大量的技能会分布在不同的角色、平台、系统上。面对这样的情况，智能分析平台如何整合多样化的分析能力，如何缩短漫长的分析链路，如何唤醒沉睡的技能，都是需要解决的问题。
那么要解决上述的问题，为什么要在数据智能分析中结合 Agent 技术？考虑我们获取信息的几种方式，搜索引擎检索出的内容是需要人工过滤的，而推荐系统是结合用户偏好来推荐内容，这就会造成信息茧房效应。如今的大模型则有希望更进一步，通过精准的生成和检索能力来打破信息茧房。此外，在物理世界中，人除了检索信息，还要检索工具。而 Agent 就可以将各类信息和工具整合在一起，提供一个检索通道，起到“检索连接”这样的作用。因此 Agent 可以成为企业内部落地智能分析系统的良好立足点。
除了检索连接，Agent 还可以提升效率。 早期的数据分析工具都需要用户编写代码来操作，接下来出现了更易用的图形化工具，如今又出现了对话机器人这样使用自然语言交互的形式。近年来火热的语言模型应用也让很多用户养成了使用习惯，他们开始希望在数据分析这样的专业领域也用自然语言交互来完成任务。
但需要注意的是，从 BI 系统到大模型分析是需要有数量级的效率提升的，如果没有显著的效率提升，在数据分析场景应用大模型的意义就不明显。而 Agent 的意义就在于可以帮助大模型实现这样的提升效果。
Agent 在应用落地时还要考虑思考的“快”与“慢”的问题。每一个业务环节都有不同的快慢需求，例如一些基本的任务需要足够迅速地完成，减少用户等待时间；一些复杂的任务下，用户可以容忍较长的处理时间，但对结果的质量要求很高。此时就需要在产品机制中设计不同类型的 Agent，满足不同场景的需求。
结合上述三点本质，我们认为 Agent 可以替代传统的冗余数据分析流程。它可以让数据分析能力覆盖的人群进一步扩大，实现数据分析更加民主化的目标。
一个通用的 Agent 数据分析流程中，必不可少的是编排器和固定工作流。比较固定的，较短的工作流一般使用固定设计，而涉及较长的工作节点，需要应对灵活的场景的任务可以使用流程编排器。这样就可以兼顾稳定和灵活性。其次，Agent 的工具要具备多样性，这也是它的核心能力，通过多样化的工具提供丰富的能力选项。最后，针对数据分析的结果还要建立一套专属的评估标准。
我们在做数据分析 Agent 时，设计了一套完整的处理流程。在用户请求预处理阶段，我们会区分数据对象和逻辑对象，前者会区分数据的关系、描述和口径，后者则涉及对数据的合理编排。而在进行对象编排时，我们需要考虑对象之间的从属和冲突关系。接下来就要使用大模型来做 DSL 生成，这里会结合多步思考、解码策略和投票策略来提供稳定的输出。最后我们一定要有后处理阶段，包括错误修改、语义和字段的一致性检查，还有重排序等步骤。
为了降低 Agent 输出为 SQL 查询时的错误率，我们需要考虑四点：
数据模型和业务场景相关，降低大模型关联的错误性。比如针对几个表进行关联时，需要考虑明显的可关联字段以及模糊的关联关系，甚至一些隐式的关联关系。
字段冗余存储，降低选择的错误性。这里需要解决多个表合并存储时的字段冗余带来的选择错误率增加问题。
减少文本生成长度，降低时间复杂度和错误传递。大模型生成的 token 较多时，不仅速度会较慢，错误也容易积累。
查询语句提前优化，减少慢 SQL 生成的概率。如果生成了一个慢 SQL 再做优化，效果往往不尽人意。
数据分析 Agent 落地时，语义层的处理是很重要的。我们认为广义的语义层要包括对象语义、加速语义和权限语义的定义。其中，对象语义包括了数据对象和逻辑对象。加速语义是说要提前设置生成的快 SQL 语句来提升速度。权限语义则要分角色、分部门、分场景，让不同的用户能够知道他们该用到什么字段，使用什么样的数据。
具体到对象语义，例如用户输入是“帮我看一下上个月的 GMV“，这里的 GMV 就是一个数据对象的语义，可以通过大模型去做检索。而逻辑对象需要贴合用户的宽泛的表达，比如用户想要怎样展示 GMV，按照什么样的粒度去展示，还有展示的时候是什么样的排序、分组，这些都是逻辑对象的范畴。
在这一块我们分了两层来处理。除了提前做预制算子外，我们也会用到 Fix SQL 语句。比如说写面试题时我们不用写详细的代码，写一段简单的伪代码来表达逻辑即可。这里我们也通过 Fix SQL 来提取一些算子，嵌入到底层的执行引擎中，这样可以减少大量的预制算子相关的工作。
区分了语义层，我们还有语义加速的引擎。这个引擎应对的场景是不同表按照维度展开时经常出现的大查询量情况。
为了加速语义查询，首先我们做了预存储和预计算，提前初始化业务使用的场景。当遇到不同的字段，涉及到多维度展开时，我去评估去掉某个维度，可能原本 1 亿行的数据就变成了 10 万行的数据。因为我知道有些维度，比如像 SQL ID，它展开的时候行数是特别多的，全局扫描速度特别慢，所以我们要有提前拆分的逻辑，这样扫描小表的时候查询速度就会比较快。
第二点，针对用户问答，我们做了一个非常好的自适应加速场景。我们统计了用户经常问的问题，将最近不同用户常问的指标下沉到加速的逻辑里，达到用户越问越快的目的。
第三点我们做了一个记忆机制。在企业数据分析中，我们需要定义什么是 Agent 应该有的记忆。因为数据分析的用户问答的每个字可能都能影响结果，所以不能对问答随便压缩，否则可能因为你压缩掉了它的字段名称，导致你下次再去问同样的问题，Agent 给的结果会不一样。所以我们定义了三类记忆。
第一是角色的记忆，就是讲你在做什么样的运营场景，以及你个人再去使用的时候它的角色的标签。举个很简单的例子，我告诉大模型，我是银行的运营人士，我想查看今天我的业绩指标是多少，这样 Agent 就能检索某个部门的运营指标，检索的范围就会比较小。尤其在做深度搜索报告时，角色的记忆会占据很大的权重。
第二是会话的记忆。它更多针对不同会话空间的穿越记忆。Agent 需要考虑现有和之前的会话窗口的相关内容的总结，形成多会话之间的穿越记忆。
第三是轮次记忆。这其实就是我们认为的短期记忆。你在当前的会话窗口，对话的内容就是我们的上下文，每个轮次的对话的上下文的细粒度内容就是轮次记忆重点关注的。
关于记忆机制的结构设计，我们举了一个例子。结构化记忆部分，我们会提取一些常见提问内容对应的字段，比如“卖了多少”对应销售额，“上分”对应“上海分行”，等等，通过实体链接建立这些记忆关系。
非结构化记忆部分包括了会话偏好记忆，比如说用户查询销售额的时候，经常喜欢用饼状图进行对比，经常想问上海公司的销售额，那么我们会存储用户的偏好。这样当用户以后再输入类似的对话，我们会把之前的记忆通过一些权重拉过来，进行相似检索。这样用户就不需要每次都要求展示饼状图之类。
这样的机制里也有几个重点需要关注。第一，记忆的状态一定是和时间衰减相关的，什么时候增删改要做好处理。第二，用户的个人角色记忆与会话记忆在融合时一定要有加权，再通过向量化的手段做聚合。这样可以避免重复识别，提高计算效率，同时还能提高识别的效果和准确性，不至于出现用户两次问了相同的问题，模型却给出了不同的结果这样的状况。
我们发现，数据洞察 Research 是 Agent 在数据分析领域最好的落地场景。相比之下，查数据的大模型产品虽然容易被企业接受，但提效往往不明显，很容易被弃用。而深度研究就符合“慢思考”和“10 倍提效”的要求。用户让 Agent 生成深度报告，对生成时间要求是很宽容的，主要关注的还是结果质量。
这里我们也做了一个数据洞察研究报告的生成流水线，这样生成的报告的大纲和任务都是支持手动修改的。
做数据洞察研究时，我们也在思考什么时候适合用推理模型，什么时候适合非推理模型。有一些简单的内容使用快思考非推理模型，甚至小参数量的模型来处理就比较合适。而针对千人千面，思维链各不相同的情况，推理模型就比较合适。因为推理模型其实是把思维链做了内化，降低了写 COT 的成本。
行业对 Agent 的数据场景落地之前一直聚焦在上图的前半段，而我们认为 Agent 应该聚焦于后半段，也就是解决数据到洞见的问题。因为企业数据人员给业务方提供数据时，需要考虑业务方下一步要做什么。业务方一定是拿你的数据去做总结、决策、汇总，那么 Agent 真正要解决的是这里的问题，提出合理的结论和建议，这样才能做到 10 倍提效。相比之下，前半段的场景中 Agent 很难做到 10 倍提效。
关于模型基座，我们的思考是要不要只做一个模型。以国外的 Claude、Gemini、GPT 三大模型为例，Claude 的代码能力很强，GPT 偏重推理，而 Gemini 的多模态能力很强。那么我们在选择模型基座时，涉及代码生成就可以选择 Claude，涉及推理规划用 GPT，涉及多模态交互用 Gemini。整个行业的基座模型都越来越垂直化，没有哪家是全面领先的。所以我们需要灵活选择，具体到每个落地场景，我们要识别这个场景要解决什么问题，什么样的模型在什么样的阶段适合这样的场景，这是一定要去做预研分析的。
关于产品的形态，我们的思考是不要舍本逐末。不是说用户习惯了自然语言对话，我们就只能用自然对话的产品形态。“Click”是很好的形态，它并不会消失，所以 Agent 产品也不是说每个技能都全部通过对话形态来承载，很多东西直接点击是要更方便的。这里就要结合产品设计和算法 AI 以及多维的思考能力，选择最合适的逻辑。
在做企业数字化应用落地的过程中，我们的一个心得是大胆选择，匍匐前进。就是说我们要做的事情一定要大胆评估，评估好后要坚定去做。 你不去做，永远不知道里面有怎样的困难。所以我们要大胆落地，迈出第一步。所谓匍匐前进，是说你要接受你的技术和产品会被所有人吐槽的结果。我们用心感受这些吐槽，是产品迭代飞轮中非常重要的一环。我们的 Know-how 不仅包括了业务知识，也包括了对别人吐槽的 Know-how，这样才能让你快速进步
