先看到，再决策：企业需要怎样的 AI 数据洞察底座

根据 AskTable 创始人崔京在金山岭 CAIO 峰会的演讲《先看到，再决策：AI 数据洞察与决策底座》整理。

经分会前，团队花了一周准备报表。会上，老板看完收入曲线，问了第一个问题：

“收入涨了，为什么利润没涨？”

接着是第二个：“是投放成本变高了，还是卖出的产品变了？”

再往下问：“如果同时考虑毛利，哪些投放更值得继续？”

这时，会议往往停在一句熟悉的话上：“这个问题，我们回去拉一下数据。”

演讲配图 · 第 4 页

报表已经准备好了，决策需要的答案却还没有准备好。一次追问，又启动了一轮取数、对口径和分析。等答案回来，原本可以当场讨论的调整，可能已经推迟到下一次会议。

洞察的速度，影响决策的速度，也影响一家企业调整经营动作的速度。

这就是“先看到，再决策”想回答的问题：怎样让业务人员在需要判断的时候，持续获得可信的数据依据？

我过去先后负责过爱奇艺数据库、阿里云 PolarDB 和字节跳动火山引擎的数据库产品，2024 年创办 AskTable。过去的工作关心数据怎样存储和处理，今天更关心另一段距离：数据已经在企业里，业务做决定的时候，怎样才能真正用上。

经营决策需要连续追问

设想两家业务相近的公司，一家每月 2 号开经分会，另一家每月 12 号开。前一家能更早看清问题、更早采取行动。如果这种差距每个月都存在，它就会逐渐变成经营节奏上的差距。

这个例子并不意味着会议开得早，决策就一定正确。它说明的是：获得依据的时间，会限制企业行动的时间。

演讲配图 · 第 2 页

企业的分析需求也很少停在一个答案上。看见利润下降之后，要拆解渠道、商品和成本。决定调整投放之后，还要观察调整有没有效果，是否出现了新的变化。

看见变化、做出判断、验证效果，构成了一个持续循环。每一轮验证，又会带来下一轮问题。

演讲配图 · 第 6 页

静态报表能够回答预先设计好的问题。要支撑这个循环，还需要一种能力：业务人员可以沿着自己的判断不断追问，系统能够延续上下文，找到相关数据，并解释每一步结果。

过去两年，我们与 360 多家企业交流过。演讲中用三个比例概括了我们的观察：交流中的企业都希望借助 AI 获得洞察，约一半已经开始行动，但在我们看来，形成完整、清晰规划与布局的还不到 10%。这是团队交流经验的概括，不代表对整个行业的统计推断。

演讲配图 · 第 3 页。比例来自团队交流观察，不代表行业抽样统计。

一些企业已经让运营部门尝试 WorkBuddy 等工具，但从尝试一个工具，到让 AI 稳定参与经营，中间还有业务、组织和技术上的系统规划要完成。

一句业务问题，背后是一整套分析工作

“如果同时考虑毛利，哪些投放更值得继续？”这句话很短，但回答它并不简单。

首先，要理解这次决策。企业想优化销售规模，还是提高利润？前面的讨论已经确认了什么？还有哪些条件需要补充？

接下来，要找到可以放在一起分析的数据。广告投放、订单、商品和成本，可能分别保存在不同系统中。它们是否能关联到同一笔业务，直接决定了分析是否成立。

然后，才是计算。毛利采用什么口径？退款怎么处理？广告归因的时间窗口是什么？一份订单关联多条明细之后，会不会把收入重复计算？

最后，还要说明依据：这个人有权看哪些数据，结论来自哪里，有没有数据缺口，哪些只是需要继续验证的判断。

演讲配图 · 第 5 页

因此，让 AI 持续给出可信洞察，要过五道关。

• •数据怎么来。 美团、小红书、抖音和企业 ERP 中的数据各有格式，需要处理多源异构数据接入。
• •业务怎么描述。 “销售额”指什么，直销与经销怎样区分，都需要明确口径和业务语义。
• •计算怎么完成。 需要生成并执行 SQL、Python 等查询或分析代码，同时落实权限控制。
• •答案怎么核验。 结论要有来源、可追溯、可复核，也要符合用户权限。
• •能力怎么迭代。 使用反馈应进入知识维护与评测，让后续分析更准确。

演讲配图 · 第 9 页

大模型带来了理解自然语言和业务上下文的新可能。要让这种能力进入日常经营，还需要把业务知识、数据关系、计算规则和权限组织起来。

为什么现在值得推进这件事？我们在演讲中强调了三个变化。

第一，理解和消解业务语义歧义的成本明显下降。演讲用“降了一个量级”描述我们观察到的变化：本体建设可以从人工逐条定义，转向 AI 辅助生成、再由人审核。这是对技术变化的经验判断，具体项目仍取决于数据和业务的复杂程度。

第二，权限可以进入查询规划。系统在生成查询时就知道能查什么，权限约束不再只依赖结果返回之后的过滤。

第三，需求正在从供给侧推动转向业务侧拉动。过去往往是 IT 部门采购 BI，再推动使用；现在，业务负责人亲自使用通用 AI 遇到企业数据问题后，会主动寻找能接入真实业务的解法。

演讲配图 · 第 8 页

AskTable 做的，就是为这些分析工作提供企业数据语义层与数据洞察智能体。

AskTable 在企业 AI 技术栈中处于哪一层

演讲的技术栈分为三层。

底层是企业已经拥有的系统和资料。业务记录系统包括 SAP、Salesforce、用友、金蝶，以及美团、抖音等业务平台；数据系统包括 Oracle、SQL Server、Snowflake、Databricks，以及达梦、PolarDB、OceanBase、StarRocks；知识系统包括 Confluence、Google Drive、Slack，以及飞书、钉钉文档。

中间是 AskTable 的企业数据语义与智能体能力。语义层提供业务定义、数据模型、上下文和治理，Data Agent 在这个基础上完成查询、计算、解释和报告，服务一线运营与高管分析。

上层是人和其他 Agent 使用的入口。它可以是 ChatGPT、Claude、Gemini、豆包等个人助手，也可以是 Codex、Claude Code、Dify、FastGPT、WorkBuddy、千问办公、豆包工作等工作工具或智能体平台。

这张技术栈图表达的是能力分工：AskTable 通过 API、MCP、Skill 等接口，让上层应用能够使用企业数据能力。具体系统的接入方式和范围，需要结合项目配置与验证。

演讲配图 · 第 10 页

与 Palantir 的比较，重点是职责边界

为了说明定位，我们在演讲中把 Palantir 的本体概念作为参照。本体将数据、逻辑、操作和安全统一组织起来，把静态数据映射为可供运营使用的数字孪生，也就是对业务对象及其关系的数字化表达。

这次演讲把 Palantir 概括为覆盖“看见到写回”的全链路：理解业务状态，支持决策，并进一步进入执行。AskTable 则聚焦其中与企业数据语义和洞察相关的部分，做到“看见”，不承担业务写回。

这个参照说明的是我们选择的工作范围。AskTable 提供可信的数据依据，人进行综合判断，再由相应业务系统或执行型 Agent 完成动作。例如，分析可以帮助判断哪些投放值得调整，修改预算属于后续执行环节。

演讲配图 · 第 7 页

语义层，让 AI 知道企业里的“一个数”意味着什么

很多企业已经拥有数据库、数仓和业务系统。困难在于，业务人员说的“采购额”“有效订单”“华东地区”，未必能直接对应到一张表、一个字段或一条查询。

语义层负责建立这座连接：把业务表达对应到明确的概念、数据和计算规则，再让 AI 在这个基础上理解问题、查询和分析。

用中国铝业绿星链通的采购场景，可以把它讲得更具体。演讲展示的是一家大型央企的供应链平台，涉及集团、中铝物资与中铝数为等平台公司，以及 12 家经营单元，绿星链通招标平台与采购系统之间存在业务关联。其典型难点是查询不方便、跨板块口径不一致、取数依赖 IT，以及报表准备周期长。

演讲配图 · 第 16 页

下面的语义方法，就以这个采购业务世界作为贯穿示例。

先描述业务世界，再定义怎样计算

采购业务中有采购计划、供应商、合同、订单，也有寻源、结算和付款。它们之间存在关系：计划产生采购需求，合同关联订单，订单继续进入验收和结算。

把这些内容描述清楚，就是业务本体。它包括四类要素：业务概念、概念分类、业务关系，以及业务事件与确定性规则。

演讲配图 · 第 18 页

“分类”具体到采购方式，可以是公开招标、邀请招标、询比价、单一来源或谈判；具体到物料，可以分大类、中类和叶类。

“关系”贯穿采购计划、寻源、招标、拟签、合同、订单、结算和付款，也连接参与报价的供应商、订单引用的物料、所属采购组织。合同签订、收货和付款完成属于事件，含税口径、退款排除和不同业务版本的数据边界属于规则。

这样，AI 才能知道当前问题涉及哪些对象，应该沿哪条业务关系继续查。

演讲配图 · 第 19 页

接下来，数据语义模型把这些概念映射到实际数据。例如，“采购金额”应该取哪个系统的哪个字段，按合同签订时间还是订单创建时间统计，使用含税还是不含税口径，退款是否排除。

数据语义模型需要明确五件事：数据映射、实体关联、指标计算、时间字段、粒度与聚合规则。

例如，演讲中的采购金额示例映射到拟签或合同的金额字段，按约定的含税口径汇总、排除退款；合同和订单通过合同标识关联，要明确一对多关系，避免重复累加；供应商数量按供应商标识去重，订单数量按订单标识去重。中标率则需要明确分子、分母分别代表哪类业务记录，物料分类可以支持逐级下钻。

系统还需要检查缺少映射、关联后可能重复计算、指标与粒度不匹配等常见问题。

这些定义如果不明确，AI 即使生成了一段能运行的查询，也可能算出业务上不成立的结果。

演讲配图 · 第 20 页

理解个人表达，同时保留统一口径

正式定义之外，AI 还需要理解用户的表达习惯。

有人说“营收”，有人说“营业收入”；某个销售团队习惯说“东区”，实际指的是“华东”。用户也可能习惯先看最近十二个月，再按区域展开分析。

这些上下文既包括别名、同义词，也包括已经确认的查询示例和历史问题、指标补充说明、Agent 行为指令，以及用户偏好和个人记忆。它们帮助 AI 选对正式定义，让回答贴近当前场景。

表达可以有习惯，区域的正式边界仍由企业的区域定义决定。

这里必须保留一个边界：个人偏好不能直接覆盖企业口径。

一个人习惯怎样看数据，与企业怎样定义一个指标，是两件不同的事。上下文与正式定义发生冲突时，应以正式定义为准。个人经验经过业务验证，才适合成为组织共同使用的知识。

演讲配图 · 第 21 页

让知识有负责人，也能修正和回滚

企业的组织、商品和流程会变化，语义定义也需要维护。

谁能修改指标？谁来审核？修改后会影响哪些报告和智能体？如果出了问题，能不能找到当时使用的版本，并恢复到此前的定义？

这些问题属于语义治理，需要同时管理负责人与权限、状态与版本、审核与发布、评测与监控，以及影响分析与回滚。

一条定义可以处于草稿、待审核、已发布或已废弃状态，保留版本历史和有效期。共享定义修改后，需要确认受影响的指标、Agent 与应用，运行回归评测，并持续观察使用情况和失败问题。

在这套方法中，AI 可以从使用反馈中发现候选关系和知识。候选内容先经过脱敏、去重和分类，再由业务人员确认定义、数据人员确认映射，绑定数据并通过评测后正式发布。正式知识应有负责人、版本和引用关系，出问题时能够找到影响范围并回滚。

使用经验可以自动收集，成为企业标准需要审核。这样积累下来的，才是一套可维护、可追溯的企业知识。

演讲配图 · 第 22 页

同一个问题，不同岗位应当看到不同范围

如果供应商、区域经理和总部负责人都问“本月采购情况怎么样”，他们有权查看的范围并不相同。

供应商只能看到自己的业务，区域经理看到所在区域，总部负责人则可能需要整体情况。即使是同一份数据，部分字段也可能只对特定岗位开放。

演讲配图 · 第 23 页

因此，权限需要参与整个分析过程。系统应先了解用户的身份、岗位、角色、数据范围和字段权限，在查询规划时就明确可以访问什么。

“同一个问题，不同人问，答案应不同”，说的是权限范围不同。大家仍应遵循共同的指标定义，在各自有权查看的数据上得到答案。

演讲配图 · 第 24 页

对于有内网要求的企业，AskTable 支持完全本地私有部署。当数据、分析组件和模型推理都部署在企业内部时，可以让相关数据流转在内网完成。具体部署方式，需要结合企业已有环境确定。

模型与算力供给可以结合项目选择模型服务或本地 GPU。采用外部模型服务时，要另外确认数据流转范围，不能把这种配置与完全本地推理混为一谈。轻量部署可以用于快速验证，正式环境的资源则随场景确定。

演讲配图 · 第 36 页。仅在相关数据、组件和推理均位于企业内部时，适用图中的内网数据流转说明。

可信洞察既要求算得对，也要求依据可查、权限清楚。

同一套数据能力，服务两种工作节奏

管理者与一线团队的分析方式不一样。

管理者问“利润率为什么下降”，希望看到的是一份展开分析的报告：变化集中在哪里，有哪些可能原因，还应该验证什么。这对应 AskTable 的高管决策分析模式，侧重深度洞察。

演讲配图 · 第 13 页

一线团队的问题通常更具体。店长想知道昨天的外卖销售额，电商运营关心某个渠道的 GMV 和 ROI，区域销售需要查看本周成交情况。这对应即时问数模式，侧重快速获得指标、明细和解释，再继续追问。

渠道经理还可能追问某个经销商本月的线索转化率，产品经理则关心智能录音卡最常使用的功能。即时问数不仅提供一个指标，还包括同比环比、明细拆解、简单原因解释和继续追问。

演讲配图 · 第 14 页

演讲给出的响应量级是：深度分析约 1—2 分钟，即时问数约 5—10 秒。前者产出图文报告、异常归因与经营建议，后者服务高频的具体问题。实际响应会随查询复杂度、数据规模和部署条件变化。

演讲配图 · 第 12 页。响应时间为场景参考，实际取决于问题、数据与部署环境。

两种模式共用企业的业务定义和数据基础，区别在于问题的深度与工作节奏。

这些能力也可以供其他 Agent 调用。AskTable 位于业务系统、数据库、知识资料与上层应用之间，通过 API、MCP、Skill 等接口，把数据分析能力接入已有工具和业务入口。

客户案例：已有平台和新型团队，走出了不同路径

零售、广告投放与芯片制造：从具体业务问题进入

演讲先展示了三个真实场景：美团的即时零售日常经营查询、海信的海外电商广告投放分析，以及合肥芯片制造企业的生产与供应链数据分析。

它们各自面对不同的业务对象。零售关心日常经营变化，电商投放需要把渠道表现与业务结果一起看，制造场景需要理解生产和供应链的关系。共同的入口，是让业务人员直接围绕自己的问题查询数据，并继续分析。

演讲配图 · 第 11 页

中国铝业：把采购问数嵌入已有平台

中国铝业绿星链通案例展示的业务规模，包括每年数十万份合同、近万个招投标项目，以及约 500 亿元的交易额。这些是演讲对客户平台规模的介绍，用于说明其业务复杂度，并非 AI 带来的新增交易成效。

业务数据覆盖采购计划、寻源、供应商、合同订单、结算和付款。业务人员的追问，经常需要跨越其中多个环节。

AskTable 的应用方式，是在已有采购平台中嵌入自然语言问数。演讲展示的“绿星智集”AI 问数系统，让业务人员通过对话获取采购流程中的数据洞察。

它既支持按不同维度统计需求量、采购量等指标，也支持输入业务标识，检索业务数据的流转过程和分析结果，形成覆盖核心采购流程的业务搜索能力。

演讲展示的项目覆盖 16 类数据表、170 个高频场景，涉及采购计划、合同执行、供应商履约、结算付款等问题。专项治理还围绕计划优化、高价值设备采购、供应商履约、物料采购量同比环比、采购总额和单价趋势等具体任务展开。

演讲配图 · 第 25 页。图中业务规模为客户平台规模，不是 AI 新增业绩。

这个案例也解释了为什么语义体系重要。同样问“采购金额”，如果合同、订单和结算采用不同口径，简单地把数据连接起来，仍然难以形成一致的回答。

成熟组织已经积累了平台和流程，可以沿用这些入口，逐步补充数据能力。演讲中的中国交建、国元证券，也分别展示了在已有知识库体系或内部业务系统中接入数据查询与分析的路径。

演讲配图 · 第 27 页

某省公安厅：沿着线索进行探索式分析

还有一类工作没有预先设定好的分析路径。审计中查异常交易，办案中分析资金流水与关系网络，或在边关场景中核查出入境及相关活动记录，都需要根据已有线索继续提出新问题。

演讲以某省公安厅的边关智能盘查为例：在授权范围内，工作人员可以用自然语言查询相关人员去过哪里、乘坐过什么交通工具、出入境多少次，再根据结果继续追问。

其中一个具体能力是模糊人名查找。口头表达与数据库记录可能不完全一致，系统先查找相近的人名，再由工作人员结合身份证号核对身份。相似名称只是检索线索，不能直接等同于身份确认。

这个案例表达了与固定经营报表不同的价值：当问题会随着线索变化，AI 可以协助跨数据检索和连续探索，为工作人员提供可核验的依据。

演讲配图 · 第 26 页。客户名称按新版匿名口径处理。

瀚思：用少量工程人员支撑日常经营分析

瀚思展示了另一种组织方式：由两名 FDE，也就是深入业务现场的工程人员，配置工具、治理数据模型，让业务人员在日常工作中使用 AI。

演讲中的业务模型治理涉及不到十张表。业务人员可以在协作工具中呼叫智能体问数据，可以通过自动化任务取得经营指标，也可以直接查看 Dashboard 和分析报告，再与 AI 对话打磨结果。

工程人员则借助 Codex 等工具管理配置 AskTable、维护数据库表结构。

这个案例的启发在于分工。业务人员围绕经营问题使用数据，工程人员维护连接、模型与配置。要让 AI 持续工作，背后仍需要有人把企业的数据和业务规则组织好。

演讲配图 · 第 28 页

不同行业，常常卡在相似的问题上

演讲中一家日活约 5000 万的国民级应用，面对的是流量端与变现端数据各自运行的问题。CEO 追问“日活下降，营收有没有跟着下降”，分析人员需要拉取两套数据、核对两个时间窗口、运行不同脚本，回答可能要等一周。它需要先把用户流量与营收放到可共同分析的基础上。

一家跨境家居企业，则希望建立接驳 SAP 的统一数据入口，让毛利、订单和销售费用在同一套明细、同一口径、同一时间窗口下对应起来，再沿着问题继续追问。

金山云在 2025 年上半年就已使用 AskTable。这个案例体现了另一类需求：已有较好的数据治理基础，仍需要让业务部门更方便地随时问数据，减少寻找数据的时间。

这些企业的系统和业务不同，共同要求却很明确：先让相关数据能够一起解释同一个业务问题，再谈更深入的分析。

演讲配图 · 第 29 页。客户名称按新版匿名口径处理。

专注企业数据洞察，也能跨行业复用

AskTable 的“垂类”体现在能力范围：专注企业数据语义、查询与洞察。它同时是一套能够跨行业复用的标准平台，各行业在共同能力之上配置自己的数据、业务概念、权限和入口。

演讲列出的行业包括工业制造、家电消费、零售电商、建筑工程、金融证券、公安政法、海事交通、海关贸易、装备制造和政府采购。

相应场景也超出了经营报表：收入、利润和渠道分析，广告渠道与关键词的 ROI 分析，用户留存、转化和行为路径分析，公安线索检索，海关贸易数据交叉核验与异常发现，以及船舶和港口数据查询与趋势分析。

共用的是数据洞察能力，需要因行业适配的是业务定义、数据关系与责任边界。

演讲配图 · 第 30 页

与上下游合作，形成完整的数据解决方案

企业落地这套能力，需要产业链各环节一起工作。

上游提供数据基础设施和治理。演讲展示的数据库与数仓生态包括达梦、金仓、OceanBase、PolarDB、openGauss、StarRocks、Databend、云器，数据治理相关企业包括枢衍、派可、数治云。

中游由 AskTable 提供企业数据语义层与数据洞察智能体，并与 Dify、FastGPT、HiAgent 等知识库或智能体平台衔接。

下游把数据依据用于业务应用与决策。演讲以乘势科技的数字员工和全景效应的决策智能为例：前者执行业务策略时需要实时数据，后者进行决策分析时需要持续的数据输入。AskTable 在其中提供可信依据，执行仍由相应应用承担。

演讲的生态页还列出了雪搭闪策、杉树科技等企业，具体协作范围根据项目需求确定。

API、MCP、Skill 是这些能力连接起来的接口方式。企业可以保留已经建设好的系统，在需要的环节补充数据语义、分析或执行能力。

演讲配图 · 第 32 页

从一个值得解决的问题开始，按数据基础推进

企业开始尝试 AI 数据洞察时，可以先选一个反复出现、会影响决策的问题。

例如，每次经营会都要重新拆解的利润变化，每周都要等待 IT 取数的供应商履约分析，或运营每天都会问的渠道表现。

随后，再看支持这个问题的数据在哪里，口径是否明确，谁负责确认答案。

演讲中的现场演示环节以制造、零售场景为例，让大家直观理解问数与分析的使用方式。企业也可以从自己的具体问题出发，先体验，再验证。

演讲给出的起步路径，是先做一次短诊断，了解业务场景与数据现状；再用示例数据或脱敏数据做快速演示，体验连续追问；条件具备后，接入真实业务数据开展 PoC，也就是概念验证，检查实际价值。

快速验证与正式落地需要区分。演讲提出的“20 分钟诊断、1 天内 Demo、1 周内 PoC”，描述的是起步与验证节奏，不能替代企业的数据建设和正式交付计划。

演讲配图 · 第 34 页。演示与概念验证节奏不等同于正式交付周期。

如果企业已有数仓、宽表和主数据，可以在现有资产上补充语义定义、权限和使用入口。演讲以约两周作为这类条件下的落地参考。

如果企业只有分别运行的 ERP、MES 等业务系统，尚未形成可用的统一数据层，就需要先梳理业务和数据关系。准备过程可能从半个月延伸到一年以上，取决于范围和基础。

实际项目应先评估数据成熟度，再确定时间表。

演讲配图 · 第 35 页。落地周期为条件化参考，实际项目需先评估范围和数据成熟度。

AskTable 在这条路径中承担企业数据语义与洞察能力。上游的数据基础设施和治理、下游的业务应用与执行系统，需要相互配合。

AI 怎样成为组织每天可用的能力

演讲最后，我们把落地问题收束到四个具体问题：

• •AI 从哪里学习公司的业务？这需要知识体系。
• •AI 从哪里了解当前发生了什么？这需要数据体系。
• •AI 通过什么工具参与工作？这需要 API 体系。
• •AI 遇到解决不了的问题，该找谁确认？这需要 Agent 与人的协作体系。

演讲配图 · 第 38 页

企业把这些条件逐步建立起来，AI 才有机会在真实流程里发挥作用。

我们始终想传达的一点是：问题本身比概念重要，落地需要因地制宜、实事求是。

演讲配图 · 第 39 页

回到最初那场经分会。如果业务负责人追问利润、渠道和成本时，团队能够在权限范围内继续分析，看到数据依据，辨认缺口，再决定下一步动作，经营讨论就有了继续向前的条件。

先看到，再决策。让业务持续获得可信的数据依据，是 AskTable 希望帮助企业建立的基础能力。

在这个基础上，企业才能进一步讨论，哪些经过确认的判断适合交给 Agent 执行，以及怎样把效果带回下一轮分析。

演讲配图 · 第 41 页

如果想进一步了解自己的企业适合从哪里开始，可以通过 AskTable.com 与我们交流业务问题、查看案例，再确定诊断和验证的范围。