👨🏻💻 作者：云器Lakehouse 产品负责人郭天琪
“上个月各区域的收入是多少？”对接企业数据库后，AI Agent 很快就能生成 SQL、返回数字，甚至附上一段分析。但对数据负责人来说，还需要追问：它用的是下单金额、实收金额，还是财务确认收入？按下单时间还是支付时间统计？退款算在哪个月？
这些问题，单靠表名、字段名和数据类型回答不了。SQL 能执行，说明语法和对象引用通过了检查；业务口径是否正确，需要另行验证。Agent 如果自行补全这些缺失信息，就可能把一份看起来合理的结果交给业务，而错误并不会触发数据库报错。
我们将这类风险归结为指标含义不清、跨团队定义不一致，以及缺少治理的数据访问。语义层的作用，是把业务定义和使用约束放到统一入口，让 AI 有可依据的分析上下文。对云器而言，Semantic View 将这一思路落在可查询的语义模型上：团队先确认口径，Agent 再发现和使用这些定义。
分析中的 AI 幻觉，往往始于业务定义缺失
第一类缺口是指标含义不清。字段叫 revenue，并没有说明它是否扣除了优惠和退款；字段叫 active，也没有说明“活跃”是登录过还是完成过交易。模型可以生成一种解释，但数据库结构本身没有提供选择依据。
跨团队的口径差异会让问题更难发现。销售按下单金额看业绩，财务按实收金额看回款，这两种定义各有用途。如果 Agent 将它们都理解成“收入”，查询不同数据源时就可能混用口径，最后给出无法对账的结论。
另一类风险来自数据访问范围。Agent 能读到的表，未必都适合用于正式分析。临时中间表、旧版本模型或未经验证的数据，也可能有完整的字段和可执行的查询。缺少明确入口时，Agent 只能从可见对象中选择，并自行判断业务逻辑。建模前收集口径、时间粒度和排除条件，正是为了减少这些猜测。
统一语义层，把业务定义变成查询依据
云器 Semantic View 是 Lakehouse 中的逻辑模型对象。模型通过 TABLES 映射业务实体和物理表，声明主外键关系；通过 DIMENSIONS 定义分析维度；通过 METRICS 集中表达指标公式、退款、测试订单等排除条件，可以在适用的指标中用条件聚合表达；名称和注释则解释这些规则的业务含义。
Agent 查询时，选择模型中已有的指标和维度，通过 semantic_view() 获取结果，由引擎依据声明的关系处理关联与聚合。这样，业务口径不必在每次提问时重新生成，也不用只留在一份提示词中。
如果用户问的指标不存在，或者能匹配到多个口径，接入流程应要求 Agent 说明缺口、请求确认，不能默默编出一个公式继续执行。Semantic View 提供可发现的模型信息；“何时澄清、何时停止”仍要写入 Agent 的工具使用规则。数据团队也要限制绕过模型直接查询原始表的路径。
这形成了集中定义、多端消费的方式。BI 报表、分析应用和 AI Agent 在实际接入同一语义模型后，可以复用同一份业务逻辑，不必各自维护一套计算公式。
口径一致，才能比较不同入口的分析结果
统一语义并不要求所有部门只保留一个“收入”。真正需要避免的是同名不同义。下单金额、实收金额和确认收入，应在业务对齐后分别定义，写清适用范围；Agent 再根据问题选择，而不是把部门间的合理差异抹平。
当财务和运营问的是同一个指标，并使用相同的数据范围、时间条件和权限时，无论从报表还是 Agent 入口查询，都应沿用相同的计算定义。这样，出现差异时，团队可以核查具体条件，而不必先翻找两套 SQL，确认是否有人漏掉了退款。
一致性还包括聚合方式和维度粒度。同一个数能否按客户、区域或产品拆分，取决于模型关系及指标所在粒度。把这些内容纳入模型，可以减少 Agent 在跨表分析时临时推断关联路径和统计方式的空间。
治理决定 Agent 能使用哪些数据，以及定义如何变更
模型入口需要与权限一起设计。云器支持对 Semantic View 授予和撤销 SELECT 权限，并查看授权情况。企业可以按用途组织不同视图，再为 Agent 使用的角色开放必要对象。涉及敏感数据时，还要核查底层数据和其他查询工具的授权，不能只建一个语义视图，就认为所有访问都受到了限制。
这里需要区分对象访问权限与数据范围控制：视图对象的 SELECT 授权，不等于自动完成行级、列级隔离。客户端 Agent 能看到什么，应按实际接入方式验证，不能依赖模型名称或可见性标记来判断安全边界。
口径变更也需要治理。例如新增一种折扣后，可以取回现有视图定义，修改相关指标，再通过 CREATE OR REPLACE 替换模型。实际查询该模型的下游会使用更新后的定义；复制到其他工具里的公式、旧快照和已有缓存，仍需另行处理。
为便于追溯，团队应将定义脚本纳入代码审查和版本管理，记录变更原因，发布前验证受影响的查询。这是围绕模型建立的工程流程，不能与产品内置的完整版本审计能力混为一谈。
可信上下文，要能说明指标怎样用
表结构告诉 Agent “有哪些数据”，业务上下文还要回答“这些数据代表什么、应该怎样计算”。客户与订单如何关联、金额是在订单还是明细粒度、所谓“本月”按哪个时间字段统计，这些信息都会影响结果。
云器提供的发现命令，让 Agent 可以先读取语义模型，再构造查询。SHOW SEMANTIC METRICS 用于查看已有指标及其元数据，DESC EXTENDED 可以检查公式和完整模型结构；SHOW SEMANTIC DIMENSIONS 配合 FOR METRIC，可查看某个指标能够合法分组的维度。关系也可以通过专门的内省命令检查。
名称、同义词和注释在这里有具体用途。例如，将指标命名为“在职员工数”，注明明确排除离职员工，就比一个含义模糊的 headcount 字段更容易匹配业务问题。公式、关系和维度信息则让 Agent 有依据判断查询能否成立。
这些元数据的质量仍由团队负责。错误的主键声明、遗漏的过滤规则或与公式不一致的注释，都可能让模型“创建成功，但结果不对”。上线前必须核对业务口径，并用基础查询和报表查询验证结果。
一个零售分析问题：先确认口径，再计算
以下是用于说明流程的示例，并非客户实测案例。
业务用户问：“商品 X 上季度的调整后收入是多少？”“调整后”可能指扣除折扣和退货，也可能指按固定汇率折算。若 Agent 直接从金额、退款和汇率字段中挑选公式，两种结果都可能看起来合理，却只有一种符合这次提问的意图。
假设数据团队已分别建立这两种指标，写明计算方式和使用范围，Agent 就可以先读取指标元数据，再询问用户：“你要看扣除折扣与退货后的收入，还是汇率调整后的收入？”确认口径和时间范围后，再查询对应指标。
如果模型只提供其中一种，Agent 应说明当前可用口径；如果两种都没有，就应将需求交回建模流程。这样的交互需要 Agent 策略与语义模型共同配合，不能将澄清行为当作 Semantic View 自动完成的功能。
回答时同时交代采用的指标和统计范围，业务方才能判断数字是否回答了原问题。计算结果可复核，AI 对结果的解释仍需要谨慎：收入下降本身，并不足以证明是某次活动或某个渠道造成的。
查询性能与指标复用，影响 AI 能否持续使用
一次演示能返回答案，与持续承接业务查询，是不同的要求。随着问题和使用人数增加，团队既要关注响应时间，也要避免每个新 Agent 项目重复建设指标逻辑。
语义模型让已确认的指标能够被后续应用复用。性能则要结合执行平台评估：云器 Lakehouse 提供结果缓存、计算集群缓存和慢查询分析等配套能力，但它们不是 Semantic View 自带的独立缓存层。指标定义相同，也不意味着不同 SQL 一定能命中同一缓存。
对于高频、耗时的聚合，预计算可以作为另一种优化方式评估，需要同时确定数据更新频率和可接受的时效。语义视图负责业务定义，性能优化应结合实际查询、数据量和执行计划展开，不能只凭“接入了语义层”就承诺查询会更快。
从一组可验证的业务问题开始
对数据总监和数据工程负责人来说，接入 Agent 前可以先检查：高频指标的口径是否已经确认，访问权限是否收敛到必要范围，业务逻辑是否有可审查、可维护的定义。对这些问题没有答案时，增加提示词通常不足以解决口径冲突。
云器 Semantic View 提供的是一套可执行、可发现的业务模型。它能够减少指标计算中的语义歧义，但不会自动修复源数据质量，也不能保证模型对结果的每一段解释都正确。计算与解释应分开看待：前者按模型执行，后者仍需要证据和校验。
落地不必从覆盖所有业务开始。可以选择一个已有标准报表的分析主题，将口径和关系建成 Semantic View，让 Agent 按“发现指标、确认歧义、查询模型”的流程回答同一组问题，再与报表核对。先验证它在缺少指标或问题含糊时是否会停止猜测，再扩展到其他场景。
如果你的团队正在评估企业数据分析 Agent，可以从一组收入或订单问题开始，与云器团队一起梳理指标口径、搭建语义模型并验证查询结果。讨论的重点应是：每个答案用了什么定义，业务方能否复核。
常见问题
Q1：语义层能消除分析中的所有 AI 幻觉吗？
不能。它通过明确指标公式、实体关系和适用维度，减少业务定义缺失带来的错误。源数据质量、用户意图识别和结果解释仍可能出错，需要结合验证流程与 Agent 使用规则处理。
Q2：云器 Semantic View 为 Agent 提供哪些治理支持？
它支持视图对象的查询授权、模型定义的查看与集中维护。行列范围控制、Agent 的其他数据访问路径，以及定义脚本的审查和版本管理，需要结合企业实际权限与工程流程配置。
Q3：为什么语义层有助于 AI 项目规模化？
多个应用可以复用已确认的业务定义，减少重复建模和口径漂移。查询性能还需依靠平台缓存、执行优化或另行设计的预计算方案，并以实际测试结果为准。
参考资料
云器官方文档：语义视图设计方法，从业务问题到视图
https://www.yunqi.tech/documents/semantic-view-design
云器官方文档：管理语义视图，结构发现与权限管理
https://www.yunqi.tech/documents/semantic-view-manage
云器官方文档：用 AI Agent 生成和维护语义视图
https://www.yunqi.tech/documents/semantic-view-agent-guide
云器官方文档：语义视图与 AI 功能集成
https://www.yunqi.tech/documents/semantic-view-ai
🎁 新用户专享福利
✅ 1 TB 存储 · 1 CRU时/天计算 · 1 年全托管体验
➤ 即刻访问云器官网领取：https://www.yunqi.tech/product/one-year-package
