💡 **打破分析能力边界，实现全栈式智能分析：** Data Agent for Analytics 能够无缝整合描述性、诊断性、预测性和规范性分析能力。用户无需预先指定分析技术，只需通过自然语言提出复杂需求（如“为何上季度华东区销售额下滑？预测下季度趋势并给出改善建议”），智能体即可自动判断并组合所需的分析技术，实现从数据查询、诊断到预测和行动建议的一站式闭环体验。

🧠 **降低高级分析门槛，赋能企业用户：** 通过将复杂的机器学习、优化算法等高级分析技术封装于内部，Data Agent for Analytics 使得普通用户无需具备专业的数据科学知识，即可通过自然语言调用强大的分析能力，极大地缩短了从问题提出到获得洞察的行动路径，推动企业做出更明智的商业决策。

🔎 **摆脱预定义限制，挖掘隐藏洞察：** 区别于传统BI依赖预定义指标和仪表盘的模式，Data Agent for Analytics 能够动态探索数据，发现预定义框架之外的隐藏模式、关联关系和异常点。这使得分析更加全面和深入，能够揭示传统方法难以触及的业务洞察。

🛠️ **以Code-based Reasoning为核心，抑制幻觉并增强可信度：** Data Agent 采用“Code-based Reasoning”策略，让LLM生成可执行代码（如SQL、Python），并将计算和推理责任转移给代码执行引擎。这种方式将幻觉风险从自然语言层面转化为工程化的代码正确性风险，并通过代码检查、测试、验证等手段进行系统性管理，同时结合可视化和上下文验证机制，显著提高了分析结果的可信度、可解释性和可复现性。

🚀 **具备企业级能力，赋能组织协作与数据复用：** Data Agent for Analytics 强调可靠性、可控性和可复用性，通过知识、记忆与协作空间的设计，促进不同层级用户（从数据消费者到专业分析师）之间的协作。它能够沉淀分析流程、知识和洞察，支持部署在用户私有网络环境，并能连接大数据生态，实现对海量数据的探索性分析，真正成为企业生产链路中的关键一环。

辰马 2025-10-31 08:31 浙江

“What I cannot create, I do not understand.”  --  Richard Feynman

2025年3月，笔者曾撰文探讨LLM驱动的AI Agent如何重塑人机协同模式，彼时更多聚焦于技术实验与理论推演，尚未在实际业务场景中落地。如今，随着Agentic AI技术的成熟，Data Agent for Analytics 正式从实验室走向企业生产一线——它不仅是对AI Agent潜力的验证，更是企业级数据分析范式的革新。

本篇将介绍DMS的一款数据分析智能体（Data Agent for Analytics ）产品的技术思考和实践。Data Agent for Analytics 定位为一款企业级数据分析智能体， 基于Agentic AI 技术，帮助用户查数据、做分析、生成报告、深入洞察。由于不同产品的演进路径，背景都不一样，所以只介绍最核心的部分，来深入剖析如何构建企业级数据分析助手：能力边界定义，技术内核，企业级能力。希望既能作为Data Agent for Analytics产品的技术核心介绍，也能作为读者的开发实践的参考。

很多客户会问Data Agent是不是ChatBI，是不是另一个NL2SQL产品。我一般都会明确回答不是，并补充Data Agent 使用了ChatBI和NL2SQL相关的技术。但为了更好的让用户理解本质的区别，需要先做一些概念的抽象， 聚焦在数据与分析技术领域上，以及对Agentic AI的介绍，  抽象能够更好的理解。

数据与分析主题在大语言模型起来之前已经比较热门。我们可以借助Gartner对数据与分析的定义，尝试把Data Agent的分析能力边界定义清楚。 Gartner把数据和分析定义为：管理数据以发挥数据作用，分析数据以优化决策、业务流程和成果的方法。并将核心分析技术按照目标分为四种：

描述性分析（Descriptive analytics）：使用BI工具、数据可视化和展示面板来回答：发生了什么？

诊断性分析（Diagnostic analytics）：需要更深入的分析和数据挖掘能力来回答：为什么会发生？

预测性分析（Predictive analytics）：通过概率预测或模拟一段时间内一系列结果来回答：可能发生什么？

规范性分析（Prescriptive analytics）：以结构化方式整合已有的知识和优化技术，在约束范围内寻找最佳结果并生成可执行的行动计划，以此来回答：应该做什么？

ChatBI或NL2SQL类的产品分析技术本质上在传统的BI分析基础上结合了LLM能力。 传统的BI分析侧重描述性分析和诊断性分析，也就是回答发生了什么，为什么会发生问题，为决策提供事实依据，典型流程是：业务系统，ETL工具，数据仓库，预定义指标最后到报表和仪表盘。

传统的BI分析技术，优势在于直观可控， 业务人员可以自主地生成报表， 工具链完整，技术成熟。 劣势主要在分析能力上，比如深度上存在局限，依赖预定义指标，需提前定义分析维度和提出假设，比较难以发现隐藏洞察。

传统的BI分析对于预测性或者规范性的分析洞察是比较困难的，所以这里提出了高级分析技术，涵盖了预测性，规范性和人工智能技术。偏向于使用数据科学和机器学习技术，主要流程包含数据处理与特征工程，模型构建，模型推理最后到行动建议。

高级分析技术的优势是可以利用不同的数据输入类型和来源，为分析者提供更多的角度洞察，推动企业作出更明智的商业决策。通过ML模型预判趋势/风险，优化算法生成行动方案，以及从非结构化数据中挖掘关联规则，比如自然语言处理，挖掘隐藏模式等。 劣势主要是门槛较高，落地周期长。 数据类型支持上，除了结构化数据， 相比传统BI分析，多了非结构化，实时数据流以及图关系数据，所以对数据治理要求也比较高。 另外涉及到机器学习，尤其是用到了深度学习模型，可解释性存在挑战。

我们现在可以更明确地定义DMS Data Agent for Analytics了。 我们希望把 Data Agent 定位为一款能够同时覆盖传统BI分析（描述性、诊断性）和高级分析（预测性、规范性）能力的智能体。也就是既可以作为自然语言到SQL查询的转换工具（NL2SQL），也可以生成预定义报表的聊天式BI（包括ChatBI），更重要的是一个具备理解分析意图、规划分析路径、执行复杂任务、并生成深度洞察的自主智能系统。

这里先尝试定义Data Agent的价值主张，技术实现也是围绕以下的价值主张：

打破分析能力边界：用户无需预先知道该用描述性统计还是构建预测模型。Data Agent 能根据用户模糊或复杂的自然语言提问（比如“为什么上季度华东区销售额下滑？预测下季度趋势并给出改善建议”），自动判断所需的分析技术组合，无缝衔接查询、诊断、预测和规划。

降低高级分析门槛：将复杂的机器学习、优化算法等高级分析能力封装在Data Agent内部，用户通过自然语言即可调用，无需具备数据科学专业知识，缩短从问题到洞察的行动路径。

摆脱预定义的限制：不再局限于预定义的指标、维度和仪表盘。Data Agent 能动态探索数据，发现预定义框架之外的隐藏模式、关联关系和异常点，提供更全面、更深入的洞察。

实现端到端分析闭环：从数据查询、可视化、根因诊断、趋势预测到行动方案建议，能够在一个连贯的交互过程中完成，过程可解释，分析过程可复用，提供闭环的分析体验。

具备企业级更大规模数据的分析能力：不限于分析数据库或者表格文件，借助于云原生计算能力，能够无缝对接大数据生态，使用分布式计算（Spark/Ray）实现海量，多模的数据实时分析。

Data Agent与ChatBI等市面上其他的问数的产品区别是什么呢？毕竟都在强调具备Agentic AI的能力。 Agentic AI（智能体驱动的人工智能）的概念在LLM出现之前就存在（例如在强化学习、传统AI中）， 但随着LLM能力的突破性进展，Agentic AI作为新一代AI范式被广泛认可。其核心可定义为：以大型语言模型为认知引擎，具备自主决策、目标导向和环境交互能力的智能体系统。

我们可以从利用模型推理的程度来进行分别，也就是Test-Time Scalling。 是模型推理阶段的Scaling Law。

随着OpenAI o1和DeepSeek R1等模型展示了强大的CoT推理能力，业界认识到增加推理计算量能显著提升复杂任务的准确性。这催生了TTS（Test-Time Scaling）这一新兴的研究领域。TTS模仿了人类在处理困难问题时的倾向，也就是投入更长的时间和更多的思考资源来提高决策的可靠性， 对于AI Agent来说， 通过增加LLM的测试时间， 可以增强其自我改进，减少人工监督。 接下来我们结合TTS从架构差异，性能和适用场景进行简单对比。

架构的差异：

ChatBI（问数）优势：架构简洁，基于NL2SQL技术，易于集成现有BI平台，支持快速意图识别和可视化输出，适合对话式交互。局限：TTS应用有限（简单的CoT），被动响应模式，缺乏上下文记忆和多步推理，难以处理复杂查询和根因分析。前期配置工作较多，比如需要对接入的数据源进行清洗，质量优化。同时为了提高自然语言查询的准确度，需要预定义好数据模型（维度，独立，层次关系等）

Data Agent优势：多代理架构，集成知识库和长期记忆，深度应用TTS（多路径探索、迭代采样），支持主动监控和个性化洞察。局限：架构复杂，实施门槛高，对于简单的问题容易陷入复杂的逻辑陷阱中，导致取数效率不高。

性能：

ChatBI（问数）响应速度快，低延迟（单轮100-5000 Token），适合即时洞察（如销售汇总、图表生成），推理深度有限，缺乏主动性。

Data Agent：深度分析（异常检测、预测建模、行动建议），支持多源数据处理，延迟较高，Token消耗大，但可以基于问题的难易程度实现推理时间的最优分配。

适用场景：

ChatBI（问数）：适合标准化、高频的简单查询场景，但对数据质量要求极高，需要提前做数据建模。

Data Agent：适合复杂、个性化的分析场景，对数据质量要求不高，提供主动式、智能化的数据洞察体验。

最后，我们可以用表格对传统BI/ChatBI，高级分析和Data Agent差异化进行总结：

通过前面的介绍，Data Agent将LLM作为认知引擎。 LLM基于语言模式的统计学习，缺乏对事实世界的真实理解。生成的内容是对训练数据中模式的重组，而非基于逻辑推理的事实表述，这就会导致数据分析过程中，有可能出现幻觉。  其次是上下文学习能力（ICL）的局限性，比如差的Few-shot会误导后续推理，泛化能力问题，难以理解复杂场景下的深度语义和意图等。 另外是工具使用上，一方面LLM对于太多工具难以适应，一方面工具调用也存在安全的风险。

接下来重点介绍Data Agent 针对以上的问题是如何优化的，以及如何让LLM像分析师一样思考与行动，包含以下几个方面：

深度语义理解

上下文管理

幻觉抑制

工具的使用

首先需要理解用户想要什么，当用户说"分析一下销售表现"时，作为数据分析的智能助手， Data Agent需要考虑提问者的角色背景、所处的业务场景、以及历史对话记录中学习的用户偏好，计算口径等，需要记忆沉淀能力。

其次是语义理解，语义理解的复杂性体现在同一个词在不同行业、不同公司甚至不同部门都有不同含义。"活跃用户"在电商场景下可能指30天内有购买行为的用户，在社交产品中可能指7天内有登录行为的用户，在SaaS产品中可能指当月有核心功能使用的付费用户。Data Agent必须维护这些领域特定的语义映射，并在对话中动态选择正确的解释。

数据的元数据（Catalog）决定Data Agent的数据理解， 比如多表关联查询，或者某个字段的分布特征，如果一开始 Data Agent不理解或者未完全理解，直接导致后续分析逻辑错误，我们把数据理解作为独立模块，便于在用户录入和分析过程中可以复用。

计算口径的澄清是语义理解的另一个关键维度。企业数据分析中最常见的问题之一就是：同样的指标名称，不同团队计算出的结果不一样，这往往源于对计算口径的理解差异。是否包含退货、是否剔除测试订单、是用下单时间还是支付时间、汇率是用实时还是月末等等。

我们把以上的内容抽象为知识和记忆。

知识与记忆形成了人对事物的认知，AI Agent中的知识和记忆是什么呢？在AI  Agent 系统中，“知识”通常指Agent可获取的领域事实、规则或静态信息，如预先收集的文档、知识库或训练数据中的隐式知识；而“记忆”指Agent在交互过程中动态记录的上下文信息和经验，如用户历史对话、偏好或之前决策。知识和记忆如同光谱的两端，二者在某种程度上可以相互转化。

左侧是具体，个性化的记忆，偏向具体的事实记录，有情景性和特殊性。

右侧是抽象，通用的知识，原理和规则，具有逻辑性强，通常是经过整理和归纳的通用信息。

中间存在过渡状态，如同光谱的颜色渐变一样，当记忆被多次验证、结构化、抽象化后，它可以上升为知识；反之，当知识被个性化使用时，也会沉淀为新的记忆。

哲学家对知识的定义始终未达成一致，不过我们可以尝试定义Data Agent的知识，可以按照不同的抽象层次进行划分：

底层是基础数据知识，关于数据本身的详细信息，包括数据的Catalog（通常包含库表列，名称含义、数据类型，存储方式，采集来源，数据血缘等），是 Data Agent理解和获取原始数据的基础。

中间为分析方法知识，包含各种用于处理和分析数据的算法，模型，统计方法或口径，以及自定义的分析流程，决定Data Agent如何从原始数据中提取有价值的信息和规律。

最高层为行业通用知识，包含通用的业务逻辑，行业术语（黑话），概念以及行业的一般性规则和理念等，用于指导Data Agent的分析方向，如何解读分析结果，并使得 Data Agent以符合行业或公司习惯的方法进行交流和应用分析结果。

知识和记忆的难点在于如何召回，二者的召回目的，流程和策略都有较大的差别，知识的目的是保证分析的正确性与通用性，提供确定性，逻辑规则，而记忆是为了连续性和情景化。策略上，知识可以使用RAG，层级（上文的三个抽象层级）分类召回。 而记忆需要根据时间和热度召回，记忆需要具备遗忘机制。

最后，人与人之间沟通需求时，也不是一次问答就能够清晰明了的，所以多轮对话也是必要的，这就要求Data Agent 需求分析模块具备“反向提问”的能力，当模型检测到语义置信度不足，通过Human-in-the-Loop 意图澄清机制，使得Data Agent能够在前期确保问题被正确定义。

在语义结构明确后，Data Agent 会自动生成意图执行计划，以结构化方式给用户展示分析思路，用户也可以根据需要进行调整。

如何处理开放式探索性类型的问题，很多时候用户可能也不知道怎么提问，就像老板给你分配一个模糊的任务一样，老板内心里面可能希望你发现一些洞察，但是不知道具体是什么。这类问题对人来说简直是天灾，没有目的地分析，对于认真工作的你来说，往往需要耗费更多的精力。但是对于Data Agent来说，这反而是其最擅长的点。 Data Agent可以结合业务语义，数据语义从不同的角度进行分析。在这个过程中，可能会给你更多的启发，帮助你进一步下钻分析。

Data Agent一轮分析完后给出问题建议，帮助用户进一步洞察

Context Engineering 是当下比较流行的AI Agent开发的工程实践， 针对每一次给到LLM的上下文进行动态的设计，构建，和优化，上下文内容除了系统提示词、角色和目标描述、用户需求外，还有对话历史，外部知识，工具调用等。 简单来说，上下文工程决定了模型知道什么，何时知道以及何种方式知道， 最终目的是LLM在约束的搜索空间下， 可以更好的理解、推理和决策。

如下图，Data Agent 的上下文管理实际上是一个完整的智能认知系统的构建，核心流程如下：从规划，分析，反思到学习，构建一个完整的智能认知系统。

 Agent Core Loop

进一步展开，如下图，从右往左看：

Data Agent上下文管理

Data Agent通过Multi-Agents协作，每个Agent具备独立的上下文管理能力，有助于进一步缩小模型的搜索空间， 通过协作完成复杂的任务。

Context Windows内容是动态的，也就是大家常看到的上下文管理能力， 比如长度控制，KVCache优化， 按需从长期记忆层寻找相关规则和知识内容。

我们称为Cognition，有点拟人化意思。包含前文描述的三层知识（基础数据知识，分析方法支持和行业通用知识），同时包含Agent的长期记忆，  作为 Data Agent的认知基座，为每次分析提供认知支撑。

最左边是外部输入层，具备多源知识融合能力，主要负责将文档、数据库、实时搜索等异构数据源统一处理，通过知识图谱和向量化技术实现语义级的知识存储和检索。

用户经常会问使用Data Agent做数据分析，模型有上下文窗口限制，是怎么放得下的， 我们通常回答放不下，因为Data Agent并不会把用户的原始数据给到模型上下文， 根本原因不是上下文窗口问题，而是模型推理的本质， 虽然今天像Qwen，DeepSeek这类模型具备Thinking模式，模型进行依然是语义空间的模式匹配和概率推理，对于精确的数值计算，逻辑推导，模型本质是在模拟计算过程，而非真正执行计算。 比如下面的例子， 模型会根据问题进行下一个Token预测， 如果使用Greedy Decoding方式，每次取概率最大的Logis或token，很有可能计算错误，设置不同的tok_k或者temperature会产生不一样的结论。

来自：Chain-of-Thought Reasoning without Prompting

如果结合LLM的预训练机制，我们可以进一步分析LLM数字幻觉的原理，尽管今天的LLM在数学能力上显著提升，在一些竞赛上已经超过了大部分人，  但在处理需要精确数值理解的任务时，仍易产生数字幻觉。具体体现在以下几个方面。

分词问题，LLM在推理之前，会把输入进行分词，也就是我们常说的Token化，然后再进行Embedding向量化。 有时LLM对数字的分词是非原子化的，比如“489,012” 可能被分解为：489、 ， 、012 三个独立的Token，这不仅割裂了数字的整体性，使模型难以将其作为一个单一数值实体处理，分隔符Token（如逗号）还可能引入干扰或歧义。

位置编码干扰，主流的序列位置编码方法（比如RoPE）主要解决文本的相对位置依赖性，但对数值的绝对精度需求支持不足。位置编码的量化特性也可能对邻近小数字的表征造成不利影响。

预训练知识中数据分布的长尾效应，数据中某些模式的普遍性会导致模型产生系统性偏差。例如我们之前遇到的一个真实案例：训练语料中“第X个”的表达常以“第0个”或“第一个”对应索引0开始，导致模型在明确要求“从1开始计数”时，仍顽固地输出从0开始的索引（BadCase）。相反，要求“从100开始计数”则可能正确，因为该模式在数据中相对少见。

数字模式的过拟合，比如LLM学到了“销售增长通常在20-30%” 这样的模式， 当实际需要计算时，如果PE没有做好，模型很可能会输出这个“经验值”。

语义空间和数值空间是不对等的，我们知道LLM基于自然语言模式匹配，其数值推理缺乏数学严谨性，在Embedding空间中，两组数字语义距离可能离得很近，但实际上对数值分析来说，毫无意义，甚至产生误导。

那如何解决这个问题呢，一种方式是通过提示词工程（PE）手段进行优化，比如COT，Step by Step等，这些PE优化手段的主要作用是：提升推理过程的透明度、引导LLM结构化思考、暴露潜在错误，它们本身不能直接大幅降低前面描述的LLM固有幻觉。在Agent应用场景中，这些方法的作用是让错误更容易被发现，并为后续的验证或工具调用创造条件。另外也可以使用Self-Consistency 方式，采样多个推理路径并投票，能在一定程度上减少随机错误的发生。Self-Consistency 假设正确的答案往往对应多条合理的推理路径，从统计上是优于单一路径上的结果。

另外就是借助工具，比如计算器。2023年6月GPT-4首次引入Function Calling，而Calculator是最早的示例之一。

观察今天的大语言模型，主要在内容创作，Math和Coding能力方面，这很大原因是这些知识都是人类对世界的抽象语言，并且已经数字化，这正是LLM的学习来源。 对于Agent来说，使用LLM 来Coding，实际在创造工具，感知真实世界，解决更复杂的问题，可能是通往AGI的必经之路。各大厂商都在不断增强LLM的Codding能力。

Data Agent 综合了以上的优化思路，尤其是以 Code-based Reasoning 为核心策略， LLM负责理解问题并生成可执行代码，比如SQL，Python 以及其他的DSL，作为中间的逻辑表示， 将最终答案生成的责任转移给代码执行引擎，使输出可执行、可解释、可复现。将产生幻觉的风险从“自然语言层面的直接幻觉”转化为“逻辑层面的代码正确性风险”，后者可通过工程化手段（代码检查、测试、验证）进行更有效的系统性管理，从而从大幅减少LLM 在最终数值和事实断言上的编造问题。

其次Data Agent使得LLM像一个数据分析师那样思考：理解问题，数据获取，数据验证，逻辑建模，可视化，结论生成等。除了通过编写SQL或者借助Pandas，Numpy这类数据分析常用的库以外，Data Agent也会和数据分析一样，通过数据可视化进行直觉验证，毕竟一图胜千言，借助VL模型可以比较容易地洞察数据趋势和异常点。 Verify机制也是Data Agent最重要的部分，不仅可以对可视化效果进行审查，最重要的是对最终的分析结果进行上下文验证，进一步降低幻觉。另外在数据分析层次上，比如DIKW模型的内化，有助于 Data Agent更加的专业化的分析。

LLM因为有了工具，不再局限于文本生成。 MCP掀起一波AI Ready 热潮，可能MCP的构建者比MCP用户还要多。 实际上模型能够准确地用好几个工具已经是非常大的进步了。实际经验来看，超过10个以上，主流的LLM很难得心应手。总结下来有几个方面。

当系统中工具数量增多时，系统注册了大量工具（例如：查询数据库、绘图、报表生成、外部API 调用等）， 模型需要根据自然语言描述在这些工具之间进行匹配，面临工具选择的语义模糊性，导致工具误选，漏选。

其次是工具多，增加了组合复杂性，尤其是参数复杂或中间状态不透明时，很容易导致调用链断裂，结果不一致和死循环。

上下文容量与记忆碎片化问题，工具说明会占用大量上下文，工具调用之间的状态和结果难以长期保留，导致记忆碎片化，信息丢失。

工具接口不统一，往往由不同团队或系统提供，接口规范、输入输出格式、错误机制各不相同，无形地增加了LLM推理时的搜索空间。

最后是安全问题，工具调用往往意味着执行外部代码或访问敏感数据，外部工具恶意Prompt 注入可能诱导模型越权执行。

Data Agent 对于工具的选择始终保持克制，前文提到 Data Agent 使用 “Code-based Reasoning” 的策略，专注于数据分析， 除了给到LLM的上下文是连贯的， 我们希望代码逻辑也是连贯的，也就是LLM的输出是可执行、可解释、可复现的。

结合DMS的DataOps的能力积累，我们为客户提供一个安全的，云原生的沙箱环境，Agent通过统一的交互协议与之通信。 这种模式有以下几个关键优势，也是 Data Agent服务于企业客户数据分析场景的关键。

模型只需要知道一个工具，可以执行SQL，Python代码，画图，编写文档，并且是交互式的，可验证计算，有助于LLM自动修正与逐步推理。

具备持久执行上下文，代码执行器可以在多轮推理中保留变量、函数、数据表和中间结果，变量与函数在多轮推理间复用。这种模式与模型上下文的目的是一致的，能让LLM 以更自然、更一致的方式进行多步推理与探索。同时可以固化为分析文档，使得分析流程可追踪和可解释。

与数据分析生态融合，兼容主流Python 数据分析与机器学习库，在分析过程中动态构建、训练模型，利用算法结果辅助推理，传统的算法提供确定性，LLM 提供语义解释。

大小模型协同，尤其是自然语言处理领域除了LLM，还有许多专有的语言模型，在情感分析，文本聚类等场景下，尤其是数据规模比较大的情况下，性能效率更出色。

支持部署在用户VPC网络环境，计算沙箱环境与VPC内存储与计算资源打通，构建私有网络分析环境，数据不出域。

支持更大规模数据的分析，计算沙箱环境可以作为数据库，分布式计算引擎或框架（比如Spark，Ray， Dask等）的Driver端，进而连接更大规模的数据。对海量的数据进行探索性分析。

举一个例子，

Data  Agent 经过小半年的建设，其分析能力已经得到客户的认可，并在云栖大会上，备受关注。 三天的云栖大会，团队的同学在展台边上与来自各行各业的300+客户交流，深刻认识到，成为企业生产链路的一环是多么的重要，技术先进性需与企业价值对齐，缺乏业务增长支撑的能力将难以落地。那我们常说的企业级能力是什么呢， 或者说用云企业客户关注企业级能力什么特征？我理解核心有三点：

首先是可靠性，系统持续在线；

其次是可控性，数据，安全，责任边界等可控；

最后是可复用性，知识，流程，洞察能被沉淀和扩展。

从这三个特征出发，结合客户交流反馈，可以定义出Data Agent应当有哪些企业级核心能力。

Data Agent 知识，记忆与协作

空间内部成员，一个企业或者组织中，围绕数据可以分为四层结构，通常每一层对数据的认知需求也不太一样，可以面前的与DIKW模型对应起来，但这也不是绝对的。  但我们可以明确的是， 对数据洞察的需求以及数据分析技能的掌握是不匹配的， 大多数最有能力的人距离真实业务场景相对而言更远。所以Data Agent需要考虑他们之间的协作关系，帮助有数据专业分析技能的人更加高效，使得他们的价值通过Data Agent 放大数倍，实现对企业数据更加深刻的洞察，同时可以减少数据消费者洞察数据价值的等待时间，另外借助Data Agent赋予数据消费者更多的自主能力。

企业数据分析需求分布

以上是我们这半年做Data Agent 一些想法和实践经验，希望使得您对Data Agent有更全面的认识， 同时在构建类似的产品功能时有些参考价值，  LLM能力的快速发展，使人有一种AGI很快就会到来的错觉， 但实践下来其实还有很长的路要走， 或许不久将来会出现比基于Transformer或者RL更先进的训练方法，不管怎么样，人工智能始终是一门应用学科，只有不断地实践，才能突破认知瓶颈，更好的拥抱时代的变化。

云栖大会Data Agent 架构介绍

最后放一段激动人心的宣传视频

阅读原文

跳转微信打开