从 ChatBI 到知数 DataAgent：网易智企，让 AI 从“能演示”到“真上岗”

2.1 知数 DataAgent 的产品架构

数据层

支持企业级数据源的统一接入与治理，支持对接第三方 BI 和指标平台。

语义层

统一指标语义定义，支持血缘、图谱分析、文档解析，把数据变成 AI 读得懂的资产。

Agent 层

通过业务助手圈定场景，自然语言发起任务，Core Agent 自主规划和调度工具、执行分析。

产出层

图表、报告、文件等分析结果沉淀到工作台，支持分享、导出、推送。

开放层

自定义入口、业务助手、MCP 和 IM 集成、外部工具接入。

最终数帆的目标是让每个业务团队都拥有一个真正可用、可信、可持续进化的 知数 DataAgent 数字员工。

2.2 让数据从被看见走到被交付

为了帮助大家更清晰地了解知数 DataAgent 能解决哪些具体问题，下面通过一条日常典型的数据工作链路来展示：

这一圈走完，可以看到，知数 DataAgent 的终点不是问答，是一条从问数、归因、交付、沉淀到自动推送的完整数据工作链路。

2.3 知数 DataAgent 的技术架构设计

通过上述整体技术设计，最终确保知数 DataAgent 运行在语义可信、权限受控、计算可靠的架构之上。后续几章将对这张架构图进行逐一拆解。

这一章要解决的问题就是如何让 AI 从查数据到懂业务。

3.1 为什么 AI 总是答不对

先看一组数字，在数十家真实客户场景做过 POC 实测：数据初始化完成、还没做任何语义建设时，问答准确率不到 50%；经过指标构建、业务术语定义、提示词调优这些环节之后，准确率能到 90% 以上，甚至更高。这个过程，大模型没有变，数据也没有变，为什么差距这么大呢？核心在于有没有把企业的语义准确传达给模型。

下面来看看四类最典型的“答不对”。它们看似简单，但都潜藏着多种“正确答案”：

这四类问题，换成更强的模型，都不会少。因为答案不取决于模型，取决于公司怎么定义。所以知数 DataAgent 要真正用起来，必须建设语义，这个是没有捷径的。

3.2 语义平台六层技术架构

这个是网易智企·数帆语义平台的六层架构，从上到下分别是：

3.3 三大数据语义资产

数帆一共有三类结构化的数据语义资产，分别是数据集、指标、BI 看板。这三类语义资产存在依赖关系，数据集是地基，定义表和表之间的关联关系；指标建在数据集之上，定义的是指标口径、计算逻辑；BI 看板在最上面，既可以依赖数据集也可以依赖指标来完成对应的固化看板。

三类资产的适用场景差别很大：

所以没有哪一类最优，要看自己的业务场景和人力来判断。

3.4 数据语义计算引擎

如果让模型直接生成表计算、LOD 这类复杂逻辑，非常不稳定，而且容易出错。数帆推荐的做法是把复杂计算的定义沉淀到语义层，对模型透明。模型只负责说清楚“要什么”，怎么算由引擎决定。

数据语义计算引擎完全自研，总结为下面三个维度：

有了数据计算引擎以后，可以在知数 DataAgent 里把复杂计算逻辑定义在计算语义层，对数据模型透明，大模型专注做自己擅长推理的事情。

3.5 数据语义加速引擎

对于知数 DataAgent 这种对话式的场景，用户对延迟的容忍度很低。而且问答的查询非常灵活，传统的缓存基本不起作用，再加上多表关联、全表扫描，性能压力会比普通的 BI 报表要大很多。为此数帆自研了一套物化加速引擎，把复杂的计算逻辑提前抽取到 MPP 里，来解决数据语义计算性能问题：

通过物化视图，数帆把关联、筛选等复杂计算提前 T+1 给算好了，基本能实现秒级的响应，很好的保障了问答时的交互体验。

3.6 业务知识建设

前面讲的三类资产和计算、加速，处理的都是结构化表数据，企业里还有一类知识不在表里，散落在每个员工的大脑和各个文档里，这叫业务知识。对知数 DataAgent 来说，它和数据一样重要。业务知识主要可分为以下五大类：

数帆产品上提供统一的功能来定义这些知识，可以通过手动配置、批量导入、文档自动解析、问答结果沉淀等方式把这些知识沉淀到系统里：

3.7 语义关系建设

单个指标只能回答值是多少，但是回答不了为什么，只有把这些语义定义通过一定的方式关联起来，才能真正解决因果推理分析。

下面以净利润这个指标为例，来看下四类语义关系是怎么构建的：

指标就不再是孤立定义，而是有计算逻辑、有上下游、有底层数据、有业务知识的业务实体。

3.8 语义的召回和消费

语义一定会越建越厚，但模型上下文是有限的。指标、术语、规则加起来上万条，不可能全塞进去，所以语义的消费和召回非常重要，具体设计架构图如下所示：

前述定义好的语义，会通过异步构建、定时同步等方式，分别存储至 ES 文本索引与向量化数据库中，而语义间的关联关系则存入图数据库。整个检索过程主要分为以下五步：

最后是编排，召回决定上限，上下文编排决定效果。如何把召回的内容组织成大模型能看得懂的语义也非常重要。这一层的原则是保障高召回率和冗余，决策交给大模型。

3.9 语义 AI ready 检查和反哺

语义建设不是一次性工程，而是要持续迭代优化的，那么数帆如何让语义越用越准，主要做了两件事情：

第一件事： AI ready 检查

语义定义得好不好、能不能用，必须有个评估标准。系统会对每个数据集和指标进行语义完整度打分，通过工程化打分和大模型打分两套规则来判断语义的完整度，如果发现语义问题，会给出提醒及优化建议，可以及时让用户感知到并进行优化。

第二件事：反哺

问答过程中产生的优质知识将被沉淀下来。例如，当用户提问“客户收入是多少”时，系统若识别到歧义，会引导用户澄清口径，澄清后的结果可一键沉淀为团队知识。此外，系统还支持通过点赞点踩、Badcase 回流等方式进行反哺纠正。值得注意的是，无论采用哪种方式，在沉淀为组织知识前，均需经过人工二次审核，以确保语义定义的准确性。

最终定义、检查、消费、反哺这四段是首尾相接形成环，每转一圈，语义就厚一层。最终让语义越用越准确。

当 AI 具备了业务理解能力后，如何保障其在生产环境中持续、稳定地运行。

4.1 为什么稳定性和准确性必须当成工程来做

为什么说稳定性和准确性必须当成工程来做？从真实业务场景的实践中，主要暴露出以下四个核心痛点。

数据场景的失败都是静默的，这就是为什么模型能力再涨，也替代不了工程。因此，要让 AI 真正迈入生产环境，必须将 Harness 工程建设扎实。

4.2 Harness 总体架构，跑得稳，更要跑得对

以下为 Harness 工程的整体技术架构：

ReAct 自主循环，也就是模型的推理部分，决定下一步做什么，调什么工具，Agent 每思考转动一圈，都会经过一次工程的兜底校验，保证错误不会静默的走出去。

数据轨，也是重点构建的 harness 五大工程关卡，包括语义关、选数关、计算关、权限关和验证关，其中，语义关已在第三章详细阐述，接下来将重点解析其余四大关卡。

4.3 选数关，召得全，更要选得准

因为大模型的上下文有限，怎么从上千个指标圈出和用户意图相符合的指标。

通过这么一套机制，很好地解决了选指标的难题。模型不是在“猜”哪个字段对，而是在已经被缩小过的候选集里做选择。

4.4 计算关，模型做好推理，把计算交给工程

在计算这一层数帆的核心处理原则就是，让模型做好推理，把计算交给工程，总结下来可以分为下面的五点

4.5 计算关，NL2SQL 还是 NL2DSL？

到底是让模型直接写 SQL，还是写 DSL？这两条路线各有优缺点：

这里采用了一条不同的链路：NL2SQL → SQL2DSL → 物理 SQL。先让模型在自己最擅长的语言里自由表达，再把 SQL 解析成语法树、翻译成 DSL，最后由 DSL 生成物理 SQL。这样既保住了生成 SQL 的灵活性，又拿到了可解析、可干预、可注入权限的中间层。

这条路的代价是翻译工作量，子查询、CTE、窗口函数，都要进行处理，历经两年多的持续优化，目前解析成功率在 99% 以上，保障了计算的稳定性。

4.6 权限关，数据权限不经过模型，换什么问法都绕不过

数据权限的处理一样不经过模型，所以换什么问法都绕不过去。

下图展示了企业级的权限体系的定义，支持行权限、列权限、表权限等数据权限配置，定义好权限以后，可将权限分配给组织架构、用户组或者用户，从而满足企业级复杂的权限配置能力：

有了计算关从 SQL 解析成 DSL 这一步以后，系统可在每次 SQL 执行前进行拦截，把用户行权限和列权限的配置注入到 DSL ，整个过程模型完全不参与权限判断，从而一定能保障模型无法越权。

权限还有一个细节，也是用户反复提到的，如果结果受权限影响的时候，系统会明确提示「数据展示不全」，避免用户会以为是查错了，提高对产品的信任度：

4.7 权限关，构建 Agent 全链路安全防护体系

它直接运行在服务器上，可以执行任意脚本，所以系统要构建全链路的安全防护体系保障 Agent 的执行安全。

1. 输入安全：用户问题进来先过敏感词校验、内容安全检查，两道都过才进下一步。

2. 模型交互安全：Agent 不直连大模型，统一走安全代理。代理里做路由白名单、凭据隔离、传输加密、输出安全检查。

3. 工具执行安全：每个任务独立的进程级沙箱，做工作区隔离、执行文件权限控制、网络访问白名单。

4. 安全底座：访问控制、审计日志、多租户隔离、安全策略。

通过数据权限的安全以及这一套全链路的安全的防护体系的建设，才能保障 Agent 才敢真正上生产。

4.8 验证关，可澄清、可干预、可解释、可追溯

最后一道关卡是“验证关”。前文提及，数据场景的失败往往是静默的。该关卡旨在将“看不见”的推理过程，转化为“可检查”的证据链，主要分为以下四个部分：

1. 可澄清：置信度低的时候不硬答，而是触发澄清，而且澄清是可以暂停、可以恢复的，用户补充完信息，会接着原来的流程往下跑。

2. 可干预：_{支持灵活配置异常重试策略：执行失败或结果偏离预期时，系统将自动重试。同时，允许用户在问答结果的基础上直接修改查询条件，实现结果的动态调整与二次纠偏。}

3. 可解释：_{将底层 SQL 执行、权限控制与业务口径等黑盒流程，转化为用户可理解的信息呈现于结果页；核心结论同步附上推导依据，让整个数据查询链路清晰可解释。}

4. 可追溯：_{针对知数 DataAgent 场景定制专属思维链。从模型思考、工具调用到中间结果，全过程具备高度的可追溯性，让异常排查有迹可循。}

4.9 Harness 优化，从细节中不断提升

前述的五道关卡仅为设计原则，Harness 工程的优化实则是持续打磨的过程。下图展示了近半年来完成的100多项优化细节，且大部分直接源于客户真实环境中的业务反馈。归根结底，Harness 的优化必须以客户真实问题为锚点，持续迭代、精益求精，死磕细节。

经过半年多的优化，系统真实场景的问答准确率从 66% 提高到了 95%。

本章将聚焦系统的持续进化机制，即如何构建“数据飞轮”。这一目标的实现，主要依赖于自动化评测体系、自动化排查工具与自动化交付体系的建设。

5.1 自动化评测体系

没有评测，准确性就是一个黑盒，每次迭代究竟影响多少准确率？更换模型后效果如何？这些问题既无法内部复盘，也难以向客户交代。为此，系统构建了自动化评测体系，整体架构如下图所示：

1. 用例层：_{基于线上真实用户问题与持续沉淀的 Badcase，系统目前已累积1000+条评测用例。}

2. 执行层&收集层：执行层通过模拟真实用户的问答交互，调用知数 DataAgent 能力执行任务。执行完毕后，系统会自动回收回答内容、完整调用链路、耗时及 Token 消耗等数据，以供收集层进行后续处理。

3. 评分层：_{评分逻辑与语义打分类似，采用“工程化代码评分”与“大模型语义评分”相结合的机制。例如，针对 SQL、结果数据等客观指标，优先交由代码进行精准判定；代码无法覆盖的部分，则交由大模型评估其语义等价性。}

4. 指标层 & 报告层：基于评分结果，系统会自动生成多维度的评估指标（涵盖准确率、模型差异对比、成本消耗等），并最终输出完整的评测报告。

通过这套评测机制，可持续驱动系统准确性的迭代优化，构建起稳固的正向循环。

5.2 全链路日志排查助手

数帆多数客户为私有化部署，网络环境错综复杂，远程排障面临极大挑战。同时，单次 Agent 问答动辄涉及数十次模型、工具调用及数据查询，人工排查效率极低。为此，系统专门打造了全链路日志排查助手：

1. 全链路日志树状记录：通过 Trans ID 将单次问答的完整调用链路组织为树状结构，涵盖工具调用、大模型调用及业务查询调用等节点。从执行时序、耗时瓶颈、空跑情况到异常报错，各环节状态均可清晰呈现。

2. 问答完即可实现问题排查：产品端的“分析过程”面板直接提供了日志查看与分析入口。业务人员或一线支持团队无需向研发团队索要日志，即可在问答结束后第一时间完成自助排查。

3. 智能排查 Agent：_{将日常排障中积累的经验沉淀为技能（Skill）与排查预案。结合日志查询 MCP 获取日志总览与阶段详情，系统可自动锁定可疑环节，并最终输出归因报告与行动建议。}

5.3 自动化交付体系建设

结果

目前，已成功构建起从“语义构建、用例构建、自动化评测”到“自动化排查”的完整闭环。实施团队每日凌晨自动跑测，发现问题并持续迭代，让整个系统真正转动成“数据飞轮”。当前，部分交付体系已落地，正逐步摆脱对实施人员经验的过度依赖。随着项目基数越大，这套飞轮释放的效能将越明显。

在问答交互的过程中，如何将个人经验转化为组织能力，从而实现组织的持续成长。

6.1 问答的终点，不该是聊天记录

核心判断：问答不应该是终点，更不该仅仅是聊天记录。它适合解决临时的单点问题，却无法沉淀为组织资产。唯有把个人分析经验沉淀并复用，组织才能真正实现持续成长。

在资产沉淀方面，主要涵盖三个部分：分析经验的沉淀，产出结果的沉淀、办公协同；

6.2 分析经验沉淀：技能和流程

6.3 报告资产沉淀

同一份分析结果，在不同场景下需具备不同的呈现形态。系统为此沉淀了三类报告资产，三者均复用统一的分析工具与语义底座：

1. AI报告：_{图文结合的在线文档形态，支持流式编辑与数据动态刷新，适用于周报、月报等周期性汇报场景。}

2. BI看板：_{具备高度交互与联动能力，适用于深度数据探索，对存量 BI 用户极其友好。}

3. HTML报告：支持一次性生成，视觉表现出色且风格多样，适用于各类汇报演示场景。

关键机制：AI 生成的内容必须具备可编辑性，支持二次加工。

AI 生成的图表可无缝切入编辑模式，支持修改配色、调整坐标轴或替换维度；编辑完成后，可一键沉淀至工作台或公共资产库，实现分析成果的固化与复用。

6.4 数据分发与办公协同

真正的数字员工，必须无缝接入办公工作流，才能真正释放价值。核心涵盖以下四大能力：

1. 结果分发：_{支持在分析过程中，通过自然语言将该段分析直接封装为定时任务。结果可定向推送至企业 IM（钉钉、企微、飞书）、邮件、短信或 Webhook 等多种渠道。}

2. IM 接入：_{业务助手支持无缝对接各类 IM 机器人，用户可在移动端直接完成数据查询与交互。}

3. 开放接入：_{产品能力已全面封装为标准 API 与 CLI，支持第三方 Agent 灵活调用。}

4. 办公协同：_{分析结果可一键写入办公文档，同时系统也支持读取各类办公文档内容进行深度分析，实现双向协同，彻底打破知识壁垒。}

借助强大的数据分发与办公协同能力，数帆打通了落地闭环的最后一公里。

对业务人员而言，这些能力最终体现在一条完整的数据工作链路中：用自然语言取数，围绕指标变化继续追问原因，生成可编辑的分析报告，再将分析方法沉淀为技能、将结果设置为定时推送。一次问答由此可以转化为后续可复用的组织资产。

知数 DataAgent 的业务需求已经得到验证，产品成熟度仍需在真实场景中持续打磨，而语义建设、工程保障和评测体系，是其中的重要基础。从 ChatBI 到 DataAgent，知数 DataAgent 的三年演进，也体现了这些能力如何随着真实业务问题持续积累。未来，数帆将持续深耕数据智能领域，以可靠的 AI 技术，释放企业生产力，共创美好世界。