受控 SQL、奖牌语义层以及三款查询引擎如何让企业数据真正可查询——不会出现幻觉的列名。

大多数 Text-to-SQL 演示在真实企业数据面前都会失效。你问“上季度收入排名前十的物料有哪些？”模型会自信地返回一个把 ORDERS 与 PRODUCTS 联接的查询——但这些表在你的 SAP 系统中并不存在。它甚至会凭空造出一个叫 revenue 的列，而实际的列被埋在 VBAK.NETWR 里——只有做过多年 SAP 顾问的人才知道这个字段的含义。

这就是我们用 Onibex ASK（Agentic Semantic Knowledge）要解决的问题：ASK 是一个把自然语言转换为受控 SQL 的开放平台，面向 SAP 数据。“受控”一词在这里承担了大量职责，值得仔细拆解其含义以及它为何能改变一切。

LLM 应该是编译器，而不是发明家

大多数 Text-to-SQL 系统会把数据库 Schema 交给 LLM，让它“自己想办法”。对于简单的 Schema（少量表，表名直观），这效果出奇地好。但 SAP HANA 的 Schema 并不简单。一个真实的 S/4HANA 系统可能有成千上万张表、四字母的加密字段名，以及为了性能而非可读性设计的联接条件。

我们的方法不同：LLM 从不发明结构。它只把业务术语映射到精选的语义层。

语义层——我们称为 Data Products 的一组 YAML 文件——是唯一的真实来源。每个查询里的每个字段都必须追溯到真实表里的真实列，以及连接它们的精确联接谓词。LLM 是一个编译器：它接收自然语言问题，在语义层中查找匹配的业务术语，并仅根据已解析的映射生成 SQL。如果某个术语不在层中，代理会请求澄清，而不是猜测。

当用户问“按物料统计的收入是多少？”时，ASK 通过 synonyms 字段把“revenue”映射到 VBAK.NETWR。它知道 VBAK 到 VBAP 的联接，因为 Data Product 已经定义好了。它不会触碰任何其他表。SQL 是可复现、可审计且确定性的——不是因为 LLM 格外聪明，而是因为它在严格的防护栏内运行。

奖牌模型应用于 SAP

让一切顺利运行的结构化决策之一，是对语义层采用 Bronze / Silver / Gold 奖牌模型。

Bronze 是原始 SAP 表——仅包含列和主键，没有联接逻辑。VBAK（销售订单抬头）、VBAP（销售订单行项目）、MARA（物料主数据）。这些表让 ASK 理解物理 Schema。

Silver 是业务逻辑所在的位置。Silver 实体把多个 Bronze 表联接成一个连贯的业务概念，拥有该概念的完整联接拓扑，并定义字段角色：度量、维度、标识符、时间戳。Silver 平面是代理的回退——如果没有 Gold 实体覆盖某个问题，ASK 会从 Silver 解析并计算联接。

Gold 是反规范化的分析层——一个已预联接、预聚合的实体，代理只需一次扫描即可查询。当 Gold 实体恰好覆盖问题所需的指标和维度时，ASK 仅从 Gold 回答。没有联接、没有规划开销、延迟极低。

问题：“Q1 按净值排名的前 10 个物料” │ ▼ 是否有 Gold 实体覆盖？ ├─ 是 → 单次查询 Gold 表 └─ 否 → 通过 Silver 实体解析（VBAK + VBAP 联接）

这种 Gold-first 解析方式让查询在规模化时仍能保持合理延迟。建模良好的 Gold 实体覆盖了业务用户实际提问的 80%。Silver 处理长尾问题。

三种引擎应对不同权衡

我们纠结最久的问题之一是：代理每次查询应该做多少规划？规划越多，SQL 越好——但也意味着更多 LLM 调用、更高延迟和更高成本。我们最终发布了三种引擎，让用户和管理员可以显式地做出权衡。

Flash
1 次 LLM 调用 · ~15 秒 · 低成本

将 Schema 视为自由文本块进行搜索，一次性生成 SQL。没有语义计划、没有联接验证、没有范围检查。快速且廉价——适合探索性问题。可复现性最低：同一问题问两次可能产生略有不同的 SQL。

Precise
3 次 LLM 调用 · ~60 秒 · 高置信度

提取语义计划 IR，使用 Medallion 重排的混合 kNN+BM25 搜索，通过 Dijkstra 算法规划联接，生成 SQL，然后针对允许的表集合进行审计——如果超出范围则重试一次。完全确定性的 Data Product 选择。适用于合规、审计追踪，或 Flash 失败时使用。

Smart
2 次 LLM 调用 · ~40 秒 · 默认

向 LLM 展示紧凑目录，让它挑选相关 Data Products——选择是模型驱动的。但选择之后的联接规划使用与 Precise 相同的 Dijkstra 图。平衡日常生产使用的速度与准确性。

这个设计背后的洞见是：确定性放在哪里很重要。Precise 让 Data Product 的选择确定化。Smart 让联接规划确定化。Flash 把两者都留给模型。需要可审计性的用户使用 Precise；需要吞吐量的用户使用 Smart；需要速度的用户使用 Flash。

问题模糊时会发生什么？

真实的企业数据存在词汇问题。“Sales”可能指 SD 模块的 VBAK，也可能指 MM 模块的 EKKO（从采购视角看）。“Revenue”可能指毛收入或净收入，取决于用户是财务还是销售。

ASK 通过 OpenSearch 中的语义词典索引支持三级消歧系统。

第 1 级：如果一个术语正好映射到一个实体，代理自动解析。不中断。

第 2 级：如果一个术语映射到跨不同 SAP 模块的多个实体，代理会弹出消歧消息——“你是指 SD 销售订单还是 MM 采购订单？”——并等待。它不会猜测。

第 3 级：如果该术语完全没有映射，代理返回明确消息，指引用户联系 Agentic Trainer。它从不幻觉一个解析。

语义词典由管理员通过 ASK Configuration App 管理——这是一个 React SPA，允许注册规范字段标签、SAP 列映射、同义词、上下文线索以及每个模块的消歧提示，所有内容均在 OpenSearch 中进行混合检索索引。

工件

工件是一份完整的业务文档——销售报告、高管简报、数据表包——完全由自然语言生成。用户在四步对话向导中描述需求（名称、受众与目的、包含的数据、格式）。代理规划并执行多条 SQL 查询，根据结果撰写结构化叙述，并返回带有嵌入数据表的格式化文档。

输出可下载为 Excel 文件——包含叙述性 Report 工作表、每个查询结果一张 Data 工作表，以及一张 SQL 工作表——全部在浏览器中组装，无需服务器端 Excel 依赖。

这与“只是生成报告”不同之处在于：文档中的数据受与所有其他查询相同的语义层管控。高管简报中的“按物料统计的收入”表使用的 VBAK.NETWR 列与聊天答案相同。没有单独的报告层需要同步。

我们学到的

01. Schema 质量就是产品

ASK 的好坏完全取决于描述数据的 Data Products。你添加的每个同义词、词典中的每条消歧提示、每个联接条件的业务语言描述——所有这些都直接提升答案质量。工程是基础设施；语义层才是产品。

02. 确定性是特性，而非约束

我们选择让联接规划确定化——使用图上的 Dijkstra，而不是让 LLM 选择联接——因为用户需要向审计员解释答案。“代理选择此联接是因为它是关系图中这两个实体之间的最短路径”是一个比“模型选择了它”更站得住脚的答案。

03. 三种引擎不是过度工程

Flash 和 Precise 服务于截然不同的用例——没有单一引擎能同时很好地覆盖两者。Smart 成为 80% 场景的默认选择。显式模式也为用户提供了调试工具：如果 Smart 失败，试试 Precise；如果 Precise 太慢，试试 Flash。模式选择器既是配置选项，也是诊断便利。

04. 治理需要仪式

开发到生产的晋升流程在设计时感觉像是开销。实际上，用户告诉我们这是最有价值的特性之一。糟糕的字段描述可能会破坏开发环境的查询，但绝不会悄无声息地破坏 CEO 周一早上查询的生产数据。

试用 Agentic Semantic Knowledge

语义层规范、平台代码和完整手册已在 GitHub 上发布。如果你正在处理 SAP 数据——或任何具有复杂 Schema 的企业数据——无论是否使用本平台，Bronze/Silver/Gold 模型和受控 SQL 方法都值得了解。View on github.