前言
“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产品的技术核心介绍，也能作为读者的开发实践的参考。
能力边界定义
与ChatBI/NL2SQL的区别
很多客户会问Data Agent是不是ChatBI，是不是另一个NL2SQL产品。我一般都会明确回答不是，并补充Data Agent 使用了ChatBI和NL2SQL相关的技术。但为了更好的让用户理解本质的区别，需要先做一些概念的抽象， 聚焦在数据与分析技术领域上，以及对Agentic AI的介绍， 抽象能够更好的理解。
定义分析技术
数据与分析主题在大语言模型起来之前已经比较热门。我们可以借助Gartner对数据与分析的定义，尝试把Data Agent的分析能力边界定义清楚。 Gartner把数据和分析定义为：管理数据以发挥数据作用，分析数据以优化决策、业务流程和成果的方法。并将核心分析技术按照目标分为四种：
描述性分析（Descriptive analytics）：使用BI工具、数据可视化和展示面板来回答：发生了什么？
诊断性分析（Diagnostic analytics）：需要更深入的分析和数据挖掘能力来回答：为什么会发生？
预测性分析（Predictive analytics）：通过概率预测或模拟一段时间内一系列结果来回答：可能发生什么？
规范性分析（Prescriptive analytics）：以结构化方式整合已有的知识和优化技术，在约束范围内寻找最佳结果并生成可执行的行动计划，以此来回答：应该做什么？
传统的BI分析
ChatBI或NL2SQL类的产品分析技术本质上在传统的BI分析基础上结合了LLM能力。 传统的BI分析侧重描述性分析和诊断性分析，也就是回答发生了什么，为什么会发生问题，为决策提供事实依据，典型流程是：业务系统，ETL工具，数据仓库，预定义指标最后到报表和仪表盘。
传统的BI分析技术，优势在于直观可控， 业务人员可以自主地生成报表， 工具链完整，技术成熟。 劣势主要在分析能力上，比如深度上存在局限，依赖预定义指标，需提前定义分析维度和提出假设，比较难以发现隐藏洞察。
高级分析技术
传统的BI分析对于预测性或者规范性的分析洞察是比较困难的，所以这里提出了高级分析技术，涵盖了预测性，规范性和人工智能技术。偏向于使用数据科学和机器学习技术，主要流程包含数据处理与特征工程，模型构建，模型推理最后到行动建议。
高级分析技术的优势是可以利用不同的数据输入类型和来源，为分析者提供更多的角度洞察，推动企业作出更明智的商业决策。通过ML模型预判趋势/风险，优化算法生成行动方案，以及从非结构化数据中挖掘关联规则，比如自然语言处理，挖掘隐藏模式等。 劣势主要是门槛较高，落地周期长。 数据类型支持上，除了结构化数据， 相比传统BI分析，多了非结构化，实时数据流以及图关系数据，所以对数据治理要求也比较高。 另外涉及到机器学习，尤其是用到了深度学习模型，可解释性存在挑战。
Data Agent的价值主张
我们现在可以更明确地定义DMS Data Agent for Analytics了。 我们希望把 Data Agent 定位为一款能够同时覆盖传统BI分析（描述性、诊断性）和高级分析（预测性、规范性）能力的智能体。也就是既可以作为自然语言到SQL查询的转换工具（NL2SQL），也可以生成预定义报表的聊天式BI（包括ChatBI），更重要的是一个具备理解分析意图、规划分析路径、执行复杂任务、并生成深度洞察的自主智能系统。
这里先尝试定义Data Agent的价值主张，技术实现也是围绕以下的价值主张：
打破分析能力边界：用户无需预先知道该用描述性统计还是构建预测模型。Data Agent 能根据用户模糊或复杂的自然语言提问（比如“为什么上季度华东区销售额下滑？预测下季度趋势并给出改善建议”），自动判断所需的分析技术组合，无缝衔接查询、诊断、预测和规划。
降低高级分析门槛：将复杂的机器学习、优化算法等高级分析能力封装在Data Agent内部，用户通过自然语言即可调用，无需具备数据科学专业知识，缩短从问题到洞察的行动路径。
摆脱预定义的限制：不再局限于预定义的指标、维度和仪表盘。Data Agent 能动态探索数据，发现预定义框架之外的隐藏模式、关联关系和异常点，提供更全面、更深入的洞察。
实现端到端分析闭环：从数据查询、可视化、根因诊断、趋势预测到行动方案建议，能够在一个连贯的交互过程中完成，过程可解释，分析过程可复用，提供闭环的分析体验。
具备企业级更大规模数据的分析能力：不限于分析数据库或者表格文件，借助于云原生计算能力，能够无缝对接大数据生态，使用分布式计算（Spark/Ray）实现海量，多模的数据实时分析。
Agentic AI 能力对比
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差异化进行总结：
维度 | 传统BI 分析/ChatBI | 高级分析（数据科学/ ML） | Data Agent for Analytics（Agentic AI） |
典型技术栈 | SQL、ETL、可视化报表、OLAP、多维分析 | 机器学习、预测模型、优化算法、NLP、深度学习 | 融合了BI分析和高级分析技术 |
分析方式 | 预定义指标、固定维度的报表分析 | 需要专家设计算法与特征工程 | 自然语言驱动、自主任务规划与工具调用 |
使用门槛 | 低，业务人员可用 | 高，需数据科学家介入 | 低，用户自然语言交互 高，AI 自动调用高级分析 |
核心能力 | 描述性、诊断性分析 | 预测性、规范性分析 | 自主推理，智能工具协作 |
可解释性 | 传统BI：强，逻辑固定，可视化清晰 ChatBI/NL2SQL：弱，一次性产生结果，SQL生成不可追溯。 | 弱，模型黑箱，结果难解释 | 强，同时具备高级分析的智能深度与BI系统的透明度，生成可执行中间逻辑，分析路径与计算过程可验证、可复盘 |
扩展与集成 | 内部系统集成有限 | 需定制开发与模型部署 | 原生支持云原生计算、API、企业生态融合 |
技术内核
通过前面的介绍，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分析《2017年Kaggle 机器学习和数据科学调查》 公开数据集，Data Agent 可以利用BERTopic，将基于Transformer 的嵌入模型，聚类以及自定义 TF-IDF 策略相结合，创建可解释且语义上有意义的主题，再结合LLM的语言理解能力，可以给出人能看得懂的分析报告。
企业级能力
Data Agent 经过小半年的建设，其分析能力已经得到客户的认可，并在云栖大会上，备受关注。 三天的云栖大会，团队的同学在展台边上与来自各行各业的300+客户交流，深刻认识到，成为企业生产链路的一环是多么的重要，技术先进性需与企业价值对齐，缺乏业务增长支撑的能力将难以落地。那我们常说的企业级能力是什么呢， 或者说用云企业客户关注企业级能力什么特征？我理解核心有三点：
首先是可靠性，系统持续在线；
其次是可控性，数据，安全，责任边界等可控；
最后是可复用性，知识，流程，洞察能被沉淀和扩展。
从这三个特征出发，结合客户交流反馈，可以定义出Data Agent应当有哪些企业级核心能力。
核心能力 | 说明和实现机制 | 企业价值 |
可验证的智能 | Code-based Reasonning ， Verify机制 | 过程可复现，结果可解释，可复用 |
数据资产化管理 | DMS OneMeta 统一基础元数据和业务知识层 | 提高数据价值变现速度 |
协作与分工 | 企业内部员工，部门之间业务领域的划分和协作，企业内部不同角色如何分工协作 | 提升组织效率 |
安全合规 | 私有计算沙箱环境，VPC网络环境，细粒度数据权限管理 | 数据不出域，合规透明 |
企业内生态集成与扩展 | 连接内部知识体系与复用已有的数据架构和系统 | 降低集成成本 |
持续学习与适应 | 融合语义，数据，知识与反馈，形成长期记忆 | 越用越智能，长期回报 |
Data Agent 知识，记忆与协作
空间内部成员，一个企业或者组织中，围绕数据可以分为四层结构，通常每一层对数据的认知需求也不太一样，可以面前的与DIKW模型对应起来，但这也不是绝对的。 但我们可以明确的是， 对数据洞察的需求以及数据分析技能的掌握是不匹配的， 大多数最有能力的人距离真实业务场景相对而言更远。所以Data Agent需要考虑他们之间的协作关系，帮助有数据专业分析技能的人更加高效，使得他们的价值通过Data Agent 放大数倍，实现对企业数据更加深刻的洞察，同时可以减少数据消费者洞察数据价值的等待时间，另外借助Data Agent赋予数据消费者更多的自主能力。
企业数据分析需求分布
最后
以上是我们这半年做Data Agent 一些想法和实践经验，希望使得您对Data Agent有更全面的认识， 同时在构建类似的产品功能时有些参考价值， LLM能力的快速发展，使人有一种AGI很快就会到来的错觉， 但实践下来其实还有很长的路要走， 或许不久将来会出现比基于Transformer或者RL更先进的训练方法，不管怎么样，人工智能始终是一门应用学科，只有不断地实践，才能突破认知瓶颈，更好的拥抱时代的变化。
云栖大会Data Agent 架构介绍
| 欢迎光临 链载Ai (http://www.lianzai.com/) | Powered by Discuz! X3.5 |