从StarRocks到MIP：数据平台的下一步是“理解”

“企业级AI的长期壁垒不是Prompt，而是业务语义。

当Agent开始参与企业分析，数据平台需要面对更具体的问题：一次查询用了哪套业务定义，是否选对了数据，结果能否支持后续判断？查询性能依然重要，指标口径、业务规则和结果核验也需要进入分析过程。

在这篇署名文章中，镜舟CEO回顾了从StarRocks到MIP的产品思考，并以跨仓备料等业务问题说明，为什么企业需要让AI在明确的业务上下文中使用数据。文章也解释了镜舟如何从实时分析与湖仓底座出发，进一步构建面向企业AI的数据平台。

本文转载自镜舟科技，作者为镜舟CEO。以下为原文。

2026年5月，黄仁勋在一场专访里说出了一个耐人寻味的数字：英伟达在中国AI芯片市场的份额，已经降到了零。

回看StarRocks最初面对的客户问题，最直接的感受是：企业产生的数据越来越多，理解和使用数据的速度却没有同步提高。报表要等，复杂查询要等，业务人员提出一个问题后，还要经过数据加工、查询和分析，才能拿到结果。

当时，一个突出的瓶颈是性能。我们首先投入实时分析，希望让数据在业务需要的时候用得上。BI、用户画像和应用内分析，都是这种需求的具体体现。查询快一些，业务就有机会多问一个问题、多做一次验证。

后来，越来越多的数据进入对象存储和开放数据湖，分析需要覆盖湖与仓。企业既要使用近期更新的数据，也要分析长期积累的历史记录。我们继续投入湖仓建设，把分析引擎、湖和对象存储纳入完整的数据基础设施，减少数据使用过程中的割裂。

我们一直用一个标准看待这些投入：它们有没有缩短企业从数据到业务价值的距离。查询速度是其中的重要一环，最终还要看数据能否帮助业务形成判断。

性能是我们最早解决的问题，但不是我们最终想解决的问题。我们真正关心的是，如何缩短企业从数据到业务价值的距离。

今天，AI和Agent开始直接使用企业数据。模型可以生成SQL，Agent可以拆解问题、连续查询，再把结果交给其他应用。与此同时，数据平台还要回答：它采用了哪套业务定义，是否用对了数据，结果能否找到依据？

StarRocks重点解决的是数据如何被更快地查询，MIP要进一步解决企业数据如何被AI正确地理解和使用。对我而言，这是沿着数据价值链继续向上生长。StarRocks的分析能力，以及围绕它建设的统一数据底座，是这项工作的出发点。

客户的问题

逐渐超出了查询性能

从2024、2025年开始，我在客户交流中越来越多地听到一些新的问题。大家关心已有的数据平台怎样服务AI，也在追问落地后的具体要求：

·数据访问：AI怎样使用已有数据，文档和结构化数据能否一起分析？

·业务口径：同一个指标，怎样让AI采用适合当前任务的定义？

·权限与核验：不同角色能看哪些数据，答案出现偏差后能否找到原因？

这类问题在不同客户的讨论中反复出现。我们也去了解较早开展实践的团队怎样处理，MIP的方向是在这个过程中逐渐形成的。

金融客户就和我们讨论过一种困扰：AI能为指标变化生成分析，但业务解释会出现偏差。用于经营讨论时，管理者需要知道变化来自哪里，团队却还要重新查数据、找口径，核对AI给出的理由。

以这类任务为例，某项利润指标上升，分析需要先确认采用哪个利润口径、比较哪个期间、两期是否覆盖相同机构，再拆解收入与成本。如果当前查询包含了新增机构，而比较期没有纳入同样范围，把增长直接解释为经营效率改善，就可能产生误导。SQL可以执行成功，两个数也都算对了，但比较的业务对象并不一致。

归因还要再向前一步。哪项收入增加、哪项成本下降，可以用数据核对；为什么变化，则需要业务记录或其他证据。模型生成一段读起来顺畅的解释，和获得足以支持判断的依据，是两项不同的工作。

SQL正确，不代表业务理解正确。这是我们在早期问数实践中持续关注的问题，也改变了我对数据平台下一阶段价值的判断。

另一个信号来自较早探索企业Agent的团队。有先行客户尝试过较广的应用范围，后来选择在BI分析、广告投放等业务领域分别沉淀知识，增加语义约束，在关键环节保留人工确认，并把验证过的分析过程整理成可复用的方法。

这让我们更重视应用范围和业务定义的关系。同样叫“效果”，经营分析与广告投放关注的指标、目标和时间窗口可能不同。先把一个业务域做清楚，才容易判断答案是否可用，经验是否值得复用。

我对数据平台的判断也由此多了一层：除了把SQL跑得更快，还要帮助AI在正确的业务上下文里使用数据。客户最终要用这些结果讨论经营、安排生产，甚至推动后续流程。

当数据的使用者扩展到Agent

过去，人通常通过BI、SQL或业务应用使用数据。现在，企业多了一条新的使用路径：人→Agent→企业数据→后续分析或业务流程。

使用者的变化，增加了数据平台需要承担的工作。人看到异常结果时，可以停下来追问口径、核对来源；Agent则可能连续发起查询，组合不同结果，再把结论交给另一个Agent。如果没有安排核验环节，前一步的理解偏差就可能进入后续任务。

Agent可能把一次错误查询的风险，放大为后续自动化分析与决策的风险。

因此，我们希望把一部分工作提前到分析开始之前：明确业务定义，确认数据范围，让当前身份和权限进入数据使用过程。同时保留查询与执行记录，便于核验；涉及采购提交、库存调整等业务操作时，还要另行检查操作权限和审批要求。

这些安排各有作用。语义定义帮助Agent选择口径，上下文补充任务所需的业务信息，权限约束数据和操作范围，执行记录帮助查明过程。定义工作不能代替过程治理，事后追踪也无法替企业决定“可用库存”应该怎样计算。

过去数据库解决的是“能不能查”；Agent时代还要解决“AI有没有理解对”。

AI也扩大了值得分析的数据范围。调研中，我们谈到过金融机构保存的音视频、扫描文档等材料，它们过去主要用于存证。要把这些材料用于分析，往往需要先完成识别、信息提取和数据整理。多模态能力为缩短这段准备工作提供了新的可能。

可以设想一个服务复盘任务：业务团队想知道，某类申请为什么反复退回补充材料。结构化记录能告诉我们退回次数和处理时间，具体缺少什么、沟通中哪里产生歧义，则可能留在扫描材料、录音或处理备注里。分析需要按申请编号、材料版本和时间把它们对应起来，再区分系统记录、工作人员说明和模型推测，并保留原文或录音位置供复核。

这类任务让我们看到，企业过去保存的数据有机会参与更多业务。但能够读取材料之后，仍要处理业务含义、访问权限和证据核验。模型能力越丰富，数据基础设施越需要把这些使用条件准备好。

数据统一之后

更难的是统一理解

以一个产品生产的例子展开。如果把“还有多少库存”放回生产现场，问题可能是：“A工厂明早8点要生产80台设备，能不能按时齐套开工？”业务要知道的是指定任务在指定时间能否获得所需物料。

下面用一组假设数据展开这个场景。按已确认的物料清单，每台设备需要2个同规格控制模块，因此这张生产订单需要160个。其他物料已经齐套，当前只需核对这个模块；各系统的数据时点已对齐，也没有需要扣除的其他限制。

这类约束在业务系统中有具体含义。例如，库存预留规则区分为特定订单保留的数量；其库存状态规则也明确，冻结库存仍属于实物库存，但不能用于生产订单等业务。

如果Agent只汇总三个在库批次，会得到240个，再与需求的160个比较，得出“库存充足”。即使排除了冻结和其他订单占用，算出两地合计可分配的140个，也仍然没有回答能否在A工厂明早8点开工。

在库、可分配、能按时到达产线，是不同的业务状态。在这个场景里，当前能确认支持目标时点的只有A工厂的70个，距需求还差90个。供应商预计到货的60个，可以作为待确认的补充来源，但不能直接当作已经放行、可投入生产的库存。

Agent要回答这个问题，需要先把生产订单、物料清单、仓库批次、订单预留、质量状态和到货计划对应起来。预留给本订单的数量应算入本订单供给，预留给其他订单的数量则要扣除；异地有货，还要检查运输、收货和送达产线的时间。只看字段名或做一次数量汇总，无法代替这些判断。

一个有用的答案，需要同时交代确定的部分和仍待确认的条件：

按当前已确认条件，明早8点可供本订单使用的控制模块为70个，需求为160个，尚有90个缺口。B工厂可申请调拨70个，但当前到线时间晚于开工时间；供应商在途的60个尚未确认质量放行时间，因此暂不能确认按时齐套。

若B工厂的70个能获批调拨并提前送达，仍有20个缺口，需要进一步确认在途批次能否在开工前完成收货、检验与入库。

这里的条件也决定了下一步该找谁确认：物流团队确认调拨到线时间，质量团队确认检验与放行安排，计划人员决定是否调整生产任务。Agent可以整理依据、提示缺口和比较方案；释放其他订单的预留、解除质量冻结或修改排产，仍要经过相应授权和审批。

这是我们所说的“理解”：把“够不够”还原为对哪张订单、在哪个地点、什么时间、满足哪些条件的可用性判断。它需要企业明确的业务定义，也需要及时、完整的数据；语义层不会让延迟的物流提前到达，也不能代替质量人员作出放行决定。

同一批物料，在财务盘点中仍然是在库资产，在仓库视角下可能可以分配，在生产计划视角下却未必赶得上开工。统一语义需要保留这些合理差异，并让人和Agent知道每种定义适用于什么任务。问题没有给出订单、工厂或时间时，就需要补充确认。

统一语义，是让不同的人、不同应用和不同Agent，对同一个业务概念有共同的定义可以依据。

Semantic View的价值在于让指标、维度和对象关系进入可计算的定义。订单占用怎样区分、冻结状态怎样处理，可以成为查询依据；检验安排、调拨说明等信息，则需要相关业务知识与上下文补充。结果应能够回溯到所用的物料清单版本、库存时点、预留明细和计划记录，使用者才有条件核对结论。

我们为什么从企业数据往上构建理解

对话入口可以让使用更方便，模型和Agent框架也会继续发展，但一家企业怎样定义客户、库存、收入和履约，需要从自己的业务中整理出来。

我们的判断是：Chat容易复制，企业自己的Context需要长期积累。以“可使用库存”为例，通用模型能够解释库存管理的概念，但哪些预订有效、何时释放、谁能批准调拨，要依据这家企业的流程。

模型会变，Agent会变，但企业自己的数据、语义和规则不会由模型替你定义。

将规则写进某个应用的Prompt，可以帮助解决眼前的问题。随着应用增多，同一条规则可能出现在不同位置，调整后需要逐一检查。更值得长期建设的，是由企业维护业务定义、适用范围和版本，再让不同应用使用这些经过确认的知识。

企业AI真正长期的资产不是Prompt，而是数据和业务语义。

这里的积累还包括分析经验。检查生产任务能否按期备料，需要确认物料需求和使用时间，再看库存、预订及到货计划；发现缺口后，要区分缺货、到货偏晚和状态待确认。这套经过业务人员验证的步骤，可以连同适用条件一起沉淀为 Skill，供后续Agent使用。

我希望这类知识能持续留在企业手里。更换模型或应用时，团队可以在已有定义和分析方法上验证新系统，而不必重新解释一遍业务。能否正确调用、是否遵守权限，仍然需要检验。

我们不是从聊天框往下找数据，而是从企业数据往上构建理解。

基于这些调研和判断，我们选择建设MIP。它是镜舟面向企业AI的数据平台，从StarRocks的分析能力出发，向业务语义、企业上下文和Agent使用延展。

AI要使用更多类型的数据、连续发起分析，对数据时效、执行效率和资源管理的要求也会继续存在。MIP的三层关系，沿着数据被使用的过程展开：

·统一数据底座：提供任务所需的数据和分析执行能力。

·业务语义与上下文：明确数据在这家企业、这个任务中的含义，并提供相关业务依据。

·Agent使用：依据前两层开展分析，让结果采用的口径和数据能够核对。

One Engine.Unified Semantics.Every Agent.这句话概括了我们希望建立的关系：用统一引擎和业务语义，为不同Agent使用企业数据提供基础。

对于应用范围，我们的态度同样明确。现阶段，把企业全部数据交给一个缺少边界的Agent，再期待它自动成为熟悉业务的分析师太过于理想化。先在口径清楚的数据域里验证，保留必要的人工确认，依据实际效果扩大范围，是我们更愿意和客户一起推进的方式。

让客户已有的投入继续服务AI

从数据与语义出发，也与我们服务的客户有关。他们已经建设了StarRocks集群、数据湖、表结构、SQL、物化视图和权限体系。数据团队还在长期工作中确认了指标、分析方法与运维方式，这些都应该成为AI应用的起点。

MIP的目标，不是让客户为了AI再建设一套数据平台，而是让过去的数据投入开始服务AI。

我们希望尽可能在已有基础设施上增加语义、上下文和Agent能力。具体到项目中，需要先梳理现有资产：哪些SQL已经包含确认过的指标口径，哪些物化视图服务于日常分析，哪些权限规则需要传递到新的使用入口。能够复用的部分继续使用，需要调整的部分明确范围。

以库存分析为例，可以先选择一个仓库或一类物料，沿用库存、出入库和预订数据，把“可使用库存”的定义整理出来。验证时，既看正常问题，也看容易出错的情况：在库充足但已被占用、出库尚未同步、预计到货晚于使用时间、当前角色无权查看某个仓库。

业务人员核对结果，数据团队检查口径与查询，AI团队验证任务执行和异常处理。除了答案是否正确，还应记录团队为纠正答案付出了多少额外工作。对客户来说，少花多少时间查表、找人确认和反复解释，是判断这项投入的具体依据。

这也要求镜舟进一步积累业务能力。过去服务BI和分析应用时，我们接触过客户的数据模型、指标和分析方法。接下来，需要与客户一起整理其中可复用的经验，将它们转化为经过确认的定义、分析方法与核验样例，让一次实施留下后续还可以使用的成果。

企业各自的规则仍然需要由企业确认。镜舟和伙伴提供的工具、方法与行业经验，应该帮助客户更好地完成这项工作，并让积累能够持续维护。

把企业实践带回开放生态

从StarRocks向上生长，也意味着继续承担对社区和生态的责任。StarRocks 社区解决通用的数据基础设施问题，镜舟则有机会把企业使用中遇到的新需求带回产品和社区。

Agent连续发起分析时，怎样与日常报表合理分配资源；一个任务同时需要结构化查询和文档检索时，底层怎样提供适用的数据访问能力；湖仓中的数据怎样更方便地用于分析，这些都是值得共同推进的工程问题。通用能力在开放生态中得到完善，会让更多开发者和应用受益。

企业AI的使用过程也需要不同伙伴参与。仓储系统维护物料状态，BI工具承载既有报表，行业应用处理领用和审批，Agent框架负责组织任务。MIP提供数据与业务语义基础，希望通过清晰的接口，让这些工具在各自职责范围内协作。

这种开放还应保留企业的选择空间。客户可以继续使用熟悉的分析工具，也可以由伙伴开发生产计划等领域的Agent。不同应用如果能依据经过确认的业务定义工作，就可以减少各自重新整理一套口径的工作。

商业投入则需要把企业落地做深：组织权限如何适配，业务规则如何维护，行业经验如何沉淀为Skill，以及实施完成后怎样持续提供服务。这些需要长期的产品与工程投入。

开源决定技术能走多远，商业化决定企业级能力能做多深。

对我而言，这两项工作需要相互支撑。社区、客户、伙伴和商业公司在各自擅长的部分持续投入，企业才有条件在已有生态中逐步用好AI。

结语

如果三年后回看今天的选择，我希望客户能感受到一项具体变化：过去回答一个业务问题，需要分别找数据、确认口径、组织查询和分析；现在可以用业务语言提出问题，更快得到基于真实数据、采用明确业务定义、能够追溯依据的结果。

从“查得快”走向“理解得快”，是我对MIP的期待，也是The Fastest Path from Data to Understanding所要表达的方向。数据平台帮助企业更快形成有依据的业务判断，决策仍然由企业自己作出。

MIP没有替企业做决定，但它应该让企业更快、更有依据地理解业务。

MIP产品发布会，10月20日线上见

从实时分析走向业务理解，数据平台需要增加哪些能力？10月20日，镜舟科技将举办MIP产品发布会，介绍产品架构与核心能力，并通过演示展示数据、业务语义与企业Context如何共同支持Agent分析任务。

时间：2026年10月20日14点，北京时间

形式：线上发布会

文：梦芸数据猿

责编：凝视深空数据猿