为什么没有 Semantic Layer 您的 AI 项目会失败
Source: Dev.to
请提供您希望翻译的正文内容，我将为您翻译成简体中文。
自然语言分析
业务用户希望使用简洁的英文提问并获得准确答案——无需 SQL、无需工单、无需等待。大型语言模型能够从自然语言生成 SQL，且在语法上表现出色，但 语法 ≠ 语义。LLM 可能写出语法正确的 SQL，却因不了解业务定义而返回错误答案。
语义层提供这些定义。没有语义层，AI 分析只是一场在会议中有效的演示，无法在生产环境中可靠运行。
常见失败模式及语义层修复
| 失败模式 | 语义层修复 |
|---|---|
| 指标幻觉 | 使用带有规范公式的虚拟数据集 |
| 关联混淆 | 预定义的关联关系 |
| 列误解 | 为每个字段提供 Wiki 描述 |
| 安全绕过 | 在视图层强制执行访问策略 |
| 结果不一致 | 确定性定义（相同问题 → 相同 SQL） |
示例
-
指标幻觉 – LLM 认为 Revenue =
SUM(amount)来自transactions表，但真实定义是SUM(order_total) WHERE status = 'completed' AND refunded = FALSE来自orders表。AI 给出的数字看起来合理，却偏差了 15 %。
修复：在虚拟数据集中存储规范的指标定义；AI 直接引用该视图，而不是自行编造公式。 -
关联混淆 – 从
orders到customers有三条路径：customer_id、billing_address_id和shipping_address_id。进行收入分析时需要使用customer_id路径，但 LLM 选用了billing_address_id。结果数值足够接近，容易逃过审查。
修复：在语义模型中定义批准的关联关系；AI 按照这些关系执行。 -
列误解 –
orders表中有一列名为date。它是订单日期、发货日期还是发票日期？LLM 默认它是订单日期，但实际是发货日期，导致所有基于时间的查询都偏移了 2–5 天。
修复：为每列添加 Wiki 风格的描述；语义层告诉 AIdate实际指ShipDate，而用于收入分析的应是OrderDate。 -
安全绕过 – 你的 BI 仪表盘对行级安全做了限制，使地区经理只能看到所在地区的数据。AI 代理直接查询原始表，绕过了 BI 层，导致某位经理看到全公司的数据。
修复：在语义层实施细粒度访问控制；AI 只能查询视图而非原始表，安全策略随数据一起传递。 -
结果不一致 – 同一个问题被提两次会生成不同的 SQL，因为 LLM 的输出具有概率性（例如，周一的答案是 $4.2 M；周三的答案是 $4.5 M）。两者都与财务部门的数字不符。
修复：在语义层使用确定性定义，使相同的问题始终解析到相同的视图、公式和结果。
为什么认真对待 AI 分析的平台会嵌入语义层
Dremio 的方法将 virtual datasets、wikis、labels 和 fine‑grained access control 合并为一个层，供人类和 AI 代理共同使用。AI 不仅仅生成 SQL；它会查询语义层以了解：
- 数据的含义
- 应用哪些公式
- 查询用户被允许看到的内容
构建 AI‑ready 数据平台
- 语义层 – 定义度量、记录列信息并强制执行安全策略。
- AI 代理 – 读取语义层以理解业务上下文。
- 查询引擎 – 使用完整的优化（缓存、反射、下推）执行 AI 生成的 SQL。
- 结果交付 – 通过人与使用的相同界面，以业务术语返回答案。
如果没有第 1 步，AI 只是一种没有业务理解的 SQL 自动补全工具。它会生成语法正确但语义错误的查询。语义层是玩具演示与生产级 AI 分析系统之间的区别。
要点
如果您的 AI 分析项目产生不可靠的结果，请不要升级模型。审计模型可访问的上下文：
- 它能读取您的指标定义吗？
- 它了解列描述吗？
- 安全策略是否得到执行？
如果答案是否定的，解决方案不是更好的大语言模型，而是一个 语义层。
免费试用 Dremio Cloud 30 天。