LLM 语义层引擎技术白皮书

前言

当大语言模型（LLM）被用于企业业务数据分析时，一个核心问题浮现：LLM 与数据库之间需要用什么样的契约连接？

本文从技术角度探讨 LLM 语义层引擎这个命题——它需要具备哪些能力，以及它的边界在哪里。第一部分是技术探讨，第二部分介绍一个参考实现，第三部分提供有限的实证数据和待补充的评估维度。

本文以 Foggy 当前已经实现并有验证经验的能力为主线：TM/QM 语义建模、JSON Query DSL、MCP 工具协议、权限治理、查询证据，以及 Compose 组合式分析。后续演进方向会单独标注，避免与当前可用能力混淆。

第一部分：LLM 语义层引擎技术探讨

1. LLM 语义层引擎：定义与边界

1.1 定义

LLM 语义层引擎是一种位于 LLM 和数据库之间的技术层，它将物理数据库结构抽象为业务语义模型，并提供结构化查询契约，让 LLM 通过语义名称和声明式请求访问数据，而非直接编写 SQL。

这个定义包含三个核心要素：

语义建模：把物理表、字段、关系、指标收敛为业务语义描述。
结构化查询契约：LLM 提交声明式的查询请求，而非自由文本 SQL。
治理执行层：引擎负责校验、权限注入、查询编译、方言转换和执行。

1.2 它不是什么

LLM 语义层引擎不是以下几种东西：

不是 BI 工具。 它不提供仪表板、可视化或报表设计器。它是 LLM 访问数据的基础设施，可以被 BI 工具或 AI 助手调用。
不是提示词工程。 它不只是把 schema 信息塞进提示词，或用自然语言描述替代表名。它是带有编译和执行能力的引擎。
不是自治分析师。 它不宣称 LLM 通过语义层就能得到完全正确的分析结果。它的目标是减少一类可避免的问题，而不是消除所有错误。

1.3 设计目标

一个 LLM 语义层引擎通常需要满足以下目标：

LLM 不需要知道物理表名、JOIN 路径和数据库方言。
业务指标有唯一、明确的语义定义。
权限和数据隔离在引擎层执行，而非依赖提示词同步。
格式错误或未授权的请求能在引擎层被拒绝，而非进入数据库执行。
查询过程产生可审计的证据，而非只有最终答案。

2. 语义建模层

2.1 表模型

表模型（Table Model）是语义层引擎的基础数据结构。它描述一张物理表的语义信息，包括：

基本信息：模型名称、显示名称、描述、对应的物理表名。
维度：与其他表的关联关系。每个维度声明外键、主键、关联表和可查询的属性。引擎根据维度定义自动生成 JOIN，LLM 不需要手动拼装关联查询。
属性：本表上的非聚合字段，包括列名、显示名称、数据类型和可选的计算公式。
指标：可聚合的数值字段，包括列名、聚合方式（求和、平均、计数等）和数据类型。

表模型的关键设计决策是声明式关系。维度的 JOIN 路径在建模时声明，而非在查询时由 LLM 推断。这消除了 LLM 猜测 JOIN 条件的需要。

表模型还可以支持嵌套维度（雪花模型），即维度表之间存在层级关系。例如"产品 → 品类 → 品类组"这样的多级路径。引擎可以根据嵌套维度定义自动生成多级 JOIN。

2.2 查询模型

查询模型（Query Model）基于表模型定义业务查询面。它决定：

哪些字段对特定消费者（LLM、应用、角色）可见。
字段的业务标签、描述和分组。
基于已有指标的计算字段（如利润率 = 利润 / 销售额）。
预定义的查询条件和默认排序。

查询模型的核心价值是封闭契约。LLM 看到的不是开放的数据库 schema，而是一组有限的、经过业务定义的可用字段。这减少了模型在无关字段上猜测的空间。

2.3 表模型与查询模型的关系

表模型是物理层的语义化描述，面向引擎内部。查询模型是业务层的公开契约，面向消费者（LLM 或应用）。同一个表模型可以派生出多个查询模型，面向不同的业务场景或权限角色。

这种分离让物理数据库变更（如表名修改、字段重构）只需要更新表模型，而不需要修改所有消费端的查询逻辑。

3. 结构化查询契约

3.1 为什么需要 DSL

让 LLM 通过自然语言直接查询数据库是另一种思路。但直通式自然语言查询面临两个问题：

第一，自然语言的歧义性使得权限注入和字段校验变得困难。当查询以结构化载荷表达时，引擎可以逐字段校验权限；当查询以自然语言表达时，权限检查只能在生成 SQL 之后进行，此时已经跳过了语义层的治理。

第二，结构化载荷更容易审计和复用。一个 JSON 查询请求可以被记录、比较、回放和调试。自然语言查询的审计需要额外的解析步骤。

因此，LLM 语义层引擎通常需要提供一种结构化的查询 DSL（Domain Specific Language），LLM 通过工具调用提交声明式请求。

3.2 查询 DSL 的核心要素

一个面向 LLM 的查询 DSL 通常包含以下要素：

字段引用：使用语义名称而非物理列名。维度属性通过路径语法引用，如 customer$caption、customer$customerType。
过滤条件（Slice）：声明字段、操作符和值。支持比较、集合、范围、模糊匹配和逻辑组合。
分组与聚合：声明分组字段和可选的聚合覆盖。
排序与分页：声明排序字段、方向和页码。
计算字段：在查询时定义基于已有字段的计算表达式。

3.3 DSL 编译

引擎接收 DSL 请求后，执行以下编译步骤：

字段解析：将语义字段名解析为物理表和列。
字段校验：验证请求的字段是否在当前查询模型的可见范围内。
权限注入：根据当前用户或上下文注入行级过滤条件。
关系推导：根据表模型中的维度定义，自动生成必要的 JOIN。
方言转换：根据目标数据库生成对应方言的底层查询。
执行与证据：执行查询并收集执行证据。

这个过程中，LLM 提交的是语义层面的请求，引擎负责将其转换为具体数据库可执行的查询。

4. 工具协议层

4.1 四步契约

LLM 语义层引擎通常通过工具调用协议暴露能力。一个合理的工具契约遵循四步模式：

发现：LLM 获取当前用户可见的查询模型列表。
描述：LLM 获取选定模型的详细字段定义，包括维度、属性、指标和计算字段。
查询：LLM 提交结构化 DSL 请求，引擎编译执行并返回结果。
组合（可选）：LLM 通过 dataset.compose_script 提交多步骤查询计划，引擎按步骤执行并返回组合结果。

4.2 工具调用 vs 数据库直通

工具调用模式的关键边界是：LLM 调用的是引擎暴露的有限工具集，而不是获得任意数据库访问能力。每个工具调用都经过语义模型和权限上下文校验。

这不同于给 LLM 一个数据库连接字符串和 SQL 执行权限。后者的安全和治理边界完全依赖提示词约束，而提示词约束是软性的。

4.3 错误处理与关闭式失败

当请求引用了不可见字段、违反权限规则或包含不支持的操作时，更稳妥的做法是关闭式失败（fail-closed）：明确拒绝请求并返回结构化错误信息，而不是尝试降级执行或猜测替代方案。

关闭式失败比静默降级更安全。LLM 可以根据错误信息调整请求，而不是在不完整或不正确的结果上继续推理。

5. 治理与权限

5.1 模型可见性

不同用户或端点可以看到不同的查询模型集合。管理员可能看到全部模型，业务用户可能只看到与其职能相关的模型。模型可见性控制发生在工具协议层。

5.2 字段可见性

同一个查询模型中，不同角色可能看到不同的字段。例如，财务人员可以看到成本字段，而销售人员只能看到收入字段。字段可见性控制发生在查询模型层。

5.3 行级切片与上下文注入

行级安全是数据治理的基本要求。语义层引擎需要支持根据当前用户或应用上下文自动注入行级过滤条件，例如公司边界、部门范围或数据所有权。

这些切片更适合在引擎编译 DSL 时注入，LLM 不需要知道这些规则的存在，也不能通过结构化查询契约绕过它们。

5.4 权限的执行边界

权限规则的关键在于：执行边界在引擎内部，而不在提示词中。把权限规则写在提示词里，依赖 LLM 遵守，是不可靠的。引擎层的权限执行是确定性的——不在可见列表中的字段无法通过该查询契约引用，不满足行级条件的数据不会通过该查询契约返回。

6. 查询证据与可审计性

6.1 为什么需要证据

LLM 生成的分析结果可能看起来合理但实际错误。仅提供最终答案而不展示推理过程，用户无法判断结果是否可信。查询证据让用户能够追溯从问题到答案的完整路径。

6.2 有效证据的组成

有效的查询证据通常包括：

选定的查询模型和可见字段。
结构化查询载荷（原始 DSL 请求）。
引擎生成的底层查询（在适当场景下）。
执行状态、返回行数和结果样本。
错误信息和拒绝原因（如有）。

6.3 目标：可复核而非无条件信任

查询证据的目标不是证明结果正确，而是让结果可复核。对于重要决策，用户应能基于证据验证数据来源、查询逻辑和结果范围。

系统的设计目标是提升治理和可追踪性，而不是取消人工复核。

7. 数据库方言抽象

SQL 方言差异是一个工程事实。日期函数、字符串处理、窗口函数、分页语法、NULL 处理和类型转换在不同数据库中的行为各不相同。

如果让 LLM 处理方言差异，模型需要知道目标数据库类型，并在每次查询中正确适配语法。这增加了提示词复杂度，也增加了出错概率。

语义层引擎更适合在编译阶段处理方言转换。LLM 提交的 DSL 是方言无关的，引擎根据目标数据库生成对应方言的底层查询。这样，同一个语义模型和查询契约可以运行在不同数据库上，而 LLM 不需要知道底层差异。

8. 复杂分析工作流

8.1 单查询能力边界

结构化 DSL 可以表达筛选、分组、排序、聚合、计算字段，以及在底层数据库支持时的窗口函数。这覆盖了大部分标准业务查询。

8.2 多步骤组合式分析

业务分析通常不止一个扁平查询。例如：

先按产品聚合销售额，再计算每个产品的销售占比。
先计算应收账款的逾期天数，再按客户分群。
先从两个不同模型获取数据，再连接中间结果进行对比分析。

语义层引擎可以支持组合式分析：允许 LLM 提交多步骤查询计划，引擎按步骤执行并管理中间结果。这适用于需要派生计算、多模型连接或分阶段聚合的分析场景。

8.3 实际边界与关闭式失败

复杂分析的效果仍然依赖语义模型的质量、字段命名的清晰度和工具描述的准确性。当字段不可用、权限规则拒绝访问、公式不受支持或数据库方言无法执行请求时，相关工作流更适合关闭式失败。

语义层引擎不应被理解为无需复核的自治分析师。更准确的理解是：它提供可治理的执行层和结构化工作流，让 AI 辅助分析更可检查、更可复用。

8.4 v1.0 能力边界与下一版本方向

本节区分 Foggy 当前可用的核心能力，以及正在评估的后续演进方向。这样读者可以清楚判断哪些能力已经适合用于当前集成，哪些能力仍属于下一阶段设计与验证范围。

当前 v1.0 能力边界：

能力	作用	能力边界
TM/QM 语义建模	把物理表、字段、关系、指标和查询面抽象为业务语义契约	基础语义建模能力
JSON Query DSL	让 LLM 通过结构化载荷提交筛选、分组、聚合和计算字段请求	当前主查询契约，不要求 LLM 直接写物理 SQL
MCP 工具协议	为 AI 客户端提供模型发现、模型描述、查询、图表和导出入口	AI 客户端接入协议；语义层引擎能力不限于 MCP
权限治理与查询证据	在引擎层执行字段校验、权限注入、查询编译和证据输出	用于提升治理和可复核性，不代表结果无条件正确
Compose 组合式分析	支持多步骤查询计划、中间结果连接和派生计算	适合多步骤和跨结果集分析；复杂场景仍需结合模型质量、权限边界和执行证据评估

后续演进方向：

方向	作用	能力边界
Virtual Semantic SQL	让 LLM 面向语义表或临时结果集编写受限 SQL，由前置解析器校验并翻译为引擎可执行计划	下一版本主要方向，不是物理数据库直通，不替代当前 DSL 主契约
Skill / Playbook	沉淀可复用的高阶分析流程和错误处理策略	后续版本方向，可作为提升复杂分析稳定性的辅助机制

下一版本的主要引擎方向之一是 Virtual Semantic SQL。它不是要证明 SQL 可以解决所有问题，也不是要替代语义层、DSL、权限治理或查询证据。它的目标是在特定环节利用 LLM 对 SQL 语法的熟悉度，同时仍然把执行边界放在 Foggy 语义层引擎内。

Virtual Semantic SQL 计划覆盖两类用法：

作为 DSL 的上层表达。 LLM 面向由 QM 暴露的逻辑宽表编写受限 SQL；引擎将 SQL 解析为 AST，校验 FROM、SELECT、WHERE、GROUP BY 等节点是否只引用可见语义字段，再翻译为内部 DSL 执行。这个路径可以理解为 SQL -> AST -> DSL。
用于内存结果集的二次分析。 组合式分析或多模型查询先把中间结果写入内存数据库；引擎可以把这些临时表自动映射为临时 TM/QM，让 LLM 继续使用 DSL 查询，也可以允许 LLM 对临时语义表使用受限 SQL 做二次过滤、连接、聚合和派生计算。

DSL、Compose 组合式分析、底层 CTE 实现与 Virtual Semantic SQL 的适用边界不会固定不变。这个边界需要根据任务类型、模型能力、错误率、可解释性、权限边界和执行证据持续评估。随着 LLM 模型能力变化，最佳交互契约也可能调整。

9. 安全边界原则

语义层引擎的安全模型需要用事实描述，而非用过度的安全承诺。

受中介的执行。 LLM 通过工具协议提交请求，引擎在语义模型和权限上下文约束下编译和执行查询。这是受中介的执行，不是完全隔离。具体安全边界取决于部署方式、启用的工具集、引擎版本和运维控制。

脚本执行的边界。 如果引擎支持组合式分析或脚本执行，更适合描述为"受约束的脚本执行"，而不是"沙箱隔离"。实际安全性取决于脚本能力的范围和引擎的执行约束。

用户复核的必要性。 对于重要决策，用户应复核生成答案、查询载荷、可用的执行证据和源数据。系统的目标是提升治理和可追踪性，而不是让用户无条件信任生成结果。

第二部分：Foggy 参考实现

10. Foggy 概述与架构

Foggy 是上述技术探讨的一个参考实现。它的产品定位是"面向 LLM 的语义层引擎"。

Foggy 的架构由五个层次组成：

┌──────────────────────────────────────────────────────────────┐
│                      AI 客户端层                              │
│  Claude Desktop / Cursor / 自定义 Agent / 产品 UI            │
└──────────────────────┬───────────────────────────────────────┘
                       │ MCP / REST API
┌──────────────────────▼───────────────────────────────────────┐
│                    工具协议层（MCP）                           │
│  list_model · describe_model_internal · query_model           │
│  compose_script                                               │
└──────────────────────┬───────────────────────────────────────┘
                       │ 结构化 DSL 请求
┌──────────────────────▼───────────────────────────────────────┐
│                    语义层引擎（核心）                          │
│  DSL 解析 → 字段校验 → 权限注入 → 查询编译 → 方言转换          │
│  查询证据（Evidence）输出                                     │
└──────┬───────────────────────────────────┬───────────────────┘
       │ 模型加载                           │ 生成 SQL
┌──────▼──────────────────┐  ┌─────────────▼───────────────────┐
│   TM/QM 语义模型层       │  │         数据库层                 │
│  TM: 表结构·维度·指标     │  │  PostgreSQL / MySQL / SQLite    │
│  QM: 查询面·权限·公式     │  │  SQL Server / MongoDB          │
└─────────────────────────┘  └─────────────────────────────────┘

Foggy 提供 Java 和 Python 双引擎实现，同一语义模型可用于多种部署形态。主要开源仓库包括：

Java 引擎与 MCP Bridge：https://github.com/foggy-projects/foggy-data-mcp-bridge
Python 引擎与 MCP Bridge：https://github.com/foggy-projects/foggy-data-mcp-bridge-python

11. TM/QM 实现

11.1 TM 语法

Foggy 的 TM 文件使用 JavaScript 模块语法。以下是一个简化的销售事实表示例：

javascript

export const model = {
    name: 'FactSalesModel',
    caption: '销售事实表',
    tableName: 'fact_sales',

    dimensions: [
        {
            name: 'customer',
            tableName: 'dim_customer',
            foreignKey: 'customer_key',
            primaryKey: 'customer_key',
            captionColumn: 'customer_name',
            caption: '客户',
            properties: [
                { column: 'customer_type', caption: '客户类型' },
                { column: 'province', caption: '省份' }
            ]
        }
    ],

    properties: [
        { column: 'order_id', caption: '订单ID', type: 'STRING' },
        { column: 'order_status', caption: '订单状态', type: 'STRING' }
    ],

    measures: [
        { column: 'sales_amount', name: 'salesAmount',
          caption: '销售金额', type: 'MONEY', aggregation: 'sum' },
        { column: 'profit_amount', name: 'profitAmount',
          caption: '利润金额', type: 'MONEY', aggregation: 'sum' }
    ]
};

dimensions 声明 JOIN 关系，properties 定义非聚合字段，measures 定义可聚合指标。引擎根据维度定义自动生成 LEFT JOIN dim_customer ON fact_sales.customer_key = dim_customer.customer_key。

TM 还支持 AI 增强配置（ai.prompt / ai.levels），为 LLM 提供字段级的语义提示。

11.2 QM 语法

Foggy 的 QM 通过 loadTableModel 加载 TM，使用 ref 引用字段：

javascript

const fs = loadTableModel('FactSalesModel');

export const queryModel = {
    name: 'SalesAnalysisQueryModel',
    caption: '销售分析',
    model: fs,

    columnGroups: [
        {
            caption: '维度',
            items: [
                { ref: fs.customer },
                { ref: fs.customer$customerType }
            ]
        },
        {
            caption: '指标',
            items: [
                { ref: fs.salesAmount },
                { ref: fs.profitAmount },
                {
                    name: 'profitRate',
                    caption: '利润率(%)',
                    formula: 'profitAmount / salesAmount * 100',
                    type: 'NUMBER'
                }
            ]
        }
    ]
};

QM 通过 columnGroups 组织展示结构，通过 formula 定义计算字段。LLM 看到的是 salesAmount、customer$caption 这样的语义名称。

12. JSON Query DSL

Foggy 的查询 DSL 使用 JSON 格式。以下是一个请求示例——"按客户类型查看已完成订单的销售金额"：

json

{
    "page": 1,
    "pageSize": 20,
    "param": {
        "columns": ["customer$customerType", "salesAmount"],
        "slice": [
            { "field": "orderStatus", "op": "=", "value": "COMPLETED" }
        ],
        "groupBy": ["customer$customerType"],
        "orderBy": ["-salesAmount"]
    }
}

引擎将其编译为：

sql

SELECT c.customer_type, SUM(f.sales_amount) AS salesAmount
FROM fact_sales f
LEFT JOIN dim_customer c ON f.customer_key = c.customer_key
WHERE f.order_status = 'COMPLETED'
GROUP BY c.customer_type
ORDER BY salesAmount DESC
LIMIT 20

DSL 支持的操作符包括比较（=、>、>=）、集合（in、not in）、范围（[]、[)）、模糊匹配（like）、空值检查、逻辑组合（$or、$and）、字段间比较（$field、$expr）以及父子维度层级查询。

13. MCP 工具集成

Foggy 通过 Model Context Protocol（MCP）暴露以下工具：

工具	说明
`dataset.list_model`	获取可访问的模型列表
`dataset.describe_model_internal`	获取模型详细字段信息
`dataset.query_model`	执行结构化 DSL 查询
`dataset.compose_script`	执行多步骤组合式分析

不同部署可以暴露不同工具集。例如，分析师端点可以提供结构化工具，业务用户端点可以只开放自然语言查询或受限查询入口。

典型查询流程：

dataset.list_model → dataset.describe_model_internal → dataset.query_model

多步骤分析流程：

dataset.list_model → dataset.describe_model_internal → dataset.compose_script

14. Odoo 社区版与 Bridge Pro 产品集成

Odoo 集成是 Foggy 将语义层引擎应用到 ERP 数据的产品案例。它包含面向基础验证和开发者集成的社区版路径，也包含面向企业场景的 Foggy Odoo Bridge Pro。

社区版侧重提供可复用的基础集成路径：

将典型 Odoo 数据模型映射为 TM/QM。
通过 Foggy 工具协议提供模型发现、字段描述和结构化查询能力。
帮助开发者验证语义建模、DSL 查询和 AI 辅助分析工作流。
开源仓库：https://github.com/foggy-projects/foggy-odoo-bridge

Foggy Odoo Bridge Pro 在此基础上面向更完整的产品集成。它将 Odoo 的业务模型和权限规则映射到 Foggy 查询工作流中：

Odoo 数据模型映射为 TM/QM。
Odoo 的用户权限和公司边界注入为行级切片。
AI 辅助分析通过 MCP 工具经由受治理的模型契约运行。

社区版和 Pro 版共同构成了语义层引擎进入 ERP 集成场景的实际案例：前者用于降低集成和验证门槛，后者用于承载更完整的产品化能力。

第三部分：实证数据

15. Benchmark 方法论

评估 LLM 语义层引擎的有效性需要多维度的 Benchmark。一个严谨的评估框架可以覆盖以下维度：

场景覆盖：单表查询、多维度分组、计算字段、多步骤组合分析、权限拒绝、空结果处理。
LLM 模型对比：不同模型版本在相同题目上的表现差异。
Schema 复杂度：从简单星型模型到复杂雪花模型的覆盖。
数据快照：固定数据集，确保结果可复现。
评分标准：查询是否成功执行、结果是否业务正确、是否使用了正确的字段和聚合方式。

任何 Benchmark 结果都应附带场景定义、模型版本、数据快照和评分方法，否则数字本身没有意义。

16. 当前实证结果

Odoo 社区版与 Foggy Odoo Bridge Pro 提供了将语义层引擎应用到 ERP 数据中的真实产品经验。以下是当前已有的定性发现：

元数据质量比提示词长度更重要。 字段的 caption、description 和 ai.prompt 的准确性直接影响 LLM 选择字段的正确率。
工具契约的稳定路径很重要。 从发现到描述到查询的四步流程为 LLM 提供了可预测的行为模式。
空结果需要明确处理。 当查询返回空结果时，如果引擎不明确标注，AI 助手可能编造记录或给出误导性回答。
更强的 LLM 通常表现更好，但引擎和工具契约仍然会影响结果。 语义层引擎不能替代模型能力，但可以减少模型犯错的机会。
Benchmark 通过不证明普遍正确。 在特定 schema、特定用户、特定权限和特定业务问题上通过的测试，不能推广到所有场景。

17. 待补充维度

本文当前不包含精确的 Benchmark 数字。以下维度的实证数据需要在后续工作中补充：

维度	当前状态	计划
题目数量	有限样本	扩展到更大题库
LLM 模型版本	未系统对比	对比主流模型在相同题目上的表现
Schema 复杂度	单一 Odoo schema	测试不同复杂度的数据模型
评分方法	人工判断	建立标准化评分规则
数据快照	未公开	准备可公开的测试数据集
权限场景	基础验证	系统测试不同权限组合
空结果/错误处理	定性观察	量化统计

只有在上述维度的数据准备完成后，才应在本文中补充具体数字。

附录

术语表

术语	全称	说明
TM	Table Model（表模型）	描述物理表结构、字段、维度关系、指标定义和数据类型的语义模型文件。
QM	Query Model（查询模型）	基于 TM 定义的业务查询视图，决定暴露给 AI 和应用的字段、标签、公式和权限。
DSL	Domain Specific Language	JSON 格式的结构化查询语言，LLM 通过 DSL 向引擎提交查询请求。
Slice	—	DSL 中的过滤条件，包含字段、操作符和值。
Evidence	查询证据	引擎在查询执行过程中产生的可审计信息。
Compose	组合式分析	多步骤查询计划，支持中间结果连接和派生计算。
Virtual Semantic SQL	虚拟语义 SQL	面向语义表或临时结果集的受限 SQL 交互契约。它需要先经过语义字段校验和权限约束，再翻译为内部 DSL 或内存执行计划，不是物理数据库直通。
MCP	Model Context Protocol	AI 工具调用协议，Foggy 通过 MCP 向 AI 客户端暴露能力。

后续补充计划

补充公开 Benchmark 数据（需场景定义、模型版本、数据快照和评分规则）。
补充 Odoo 集成的公开发布说明和演示材料。
补充组合工作流、权限拒绝和空结果处理的可复用示例。
补充数据库方言支持矩阵。
补充部署架构说明（嵌入式 / 网关 / 独立服务）。
补充二次结果集成与 Virtual Semantic SQL 的设计说明、原型边界和失败模式。

LLM 语义层引擎技术白皮书 ​

前言 ​

第一部分：LLM 语义层引擎技术探讨 ​

1. LLM 语义层引擎：定义与边界 ​

1.1 定义 ​

1.2 它不是什么 ​

1.3 设计目标 ​

2. 语义建模层 ​

2.1 表模型 ​

2.2 查询模型 ​

2.3 表模型与查询模型的关系 ​

3. 结构化查询契约 ​

3.1 为什么需要 DSL ​

3.2 查询 DSL 的核心要素 ​

3.3 DSL 编译 ​

4. 工具协议层 ​

4.1 四步契约 ​

4.2 工具调用 vs 数据库直通 ​

4.3 错误处理与关闭式失败 ​

5. 治理与权限 ​

5.1 模型可见性 ​

5.2 字段可见性 ​

5.3 行级切片与上下文注入 ​

5.4 权限的执行边界 ​

6. 查询证据与可审计性 ​

6.1 为什么需要证据 ​

6.2 有效证据的组成 ​

6.3 目标：可复核而非无条件信任 ​

7. 数据库方言抽象 ​

8. 复杂分析工作流 ​

8.1 单查询能力边界 ​

8.2 多步骤组合式分析 ​

8.3 实际边界与关闭式失败 ​

8.4 v1.0 能力边界与下一版本方向 ​

9. 安全边界原则 ​

第二部分：Foggy 参考实现 ​

10. Foggy 概述与架构 ​

11. TM/QM 实现 ​

11.1 TM 语法 ​

11.2 QM 语法 ​

12. JSON Query DSL ​

13. MCP 工具集成 ​

14. Odoo 社区版与 Bridge Pro 产品集成 ​

第三部分：实证数据 ​

15. Benchmark 方法论 ​

16. 当前实证结果 ​

17. 待补充维度 ​

附录 ​

术语表 ​

后续补充计划 ​