第200期 Info ServerAI 智能信息服务器

Information Server for AI

作者：郑晓军 2026-03-03 （2026-03-04 更新）

1. 概述

在 AI Agent 的时代，有不少人在惊呼：“软件已死”，“SaaS 将要衰亡”。为什么？这是因为 AI Agent 能够代替人类去运行、去操作之前由人类亲自操作的软件。因此，传统软件精美、繁复的 UI 不再具有意义，传统软件中固有的流程逻辑，会被 AI 中的逻辑来补偿。传统的应用软件会向基础的单元操作“退化”，其界面与接口会朝着更适应于 AI Agent 的高效、精准操作而发展。

这时候，我们要问自己，在市场上流行了 40 多年之久的关系数据库在 AI 的时代该往何处去？

我们把时钟拨回到 1969 年，E.F.Codd 博士在他的论文中提出了关系模型，该理论把数据管理提升到了一个基于关系代数的抽象化高度。从此，数据的存储模式独立于其访问路径，继而开拓了波澜壮阔的关系型数据库的时代。

在这个过程中，我们知道：关系数据库在一开始，其查询/操作语言并不是 SQL，而是关系代数的指令集。关系代数的指令集是与关系模型天然共生的，是最基础、最本质的操作指令。但人类用户在使用关系代数指令时，会感觉过于技术、过于专业、过于机械。因此，在 1974~1977 年间，IBM 研究员 Donald Chamberlin、Raymond Boyce 设计出 SEQUEL，这就是后来的“结构化查询语言” — SQL。SQL 的语法是更接近自然语言（英语）的一种数据库查询与操作语言。1979 年，Oracle 公司（当时还叫 Relational Software, Inc.）第一个推出了商用 SQL 数据库产品，从而大获成功。因此，SQL 后来居上，成为关系数据库语言事实上的标准，

关系型数据库在应用中的场景其实可以分为两种：一种是用户（人）直接使用数据库语言去访问数据库，此时，一种更接近自然语言语法的数据库语言就更受欢迎，例如：SQL。另一种情况是，数据库并不直接面对用户（人），而是在数据库外围包了一层应用，用户是使用应用软件来访问的数据库。那么，应用开发者一般都是专业人员，他们在应用开发过程中使用 SQL 还是使用关系代数指令，区别并不大。甚至于会认为关系代数更简洁、高效。

如今，在 AI 的时代，传统由人直接访问数据库的环节，恰恰是 AI 参与辅助甚至替代的主战场。很多人在讨论 NL2SQL，也就是自然语言到 SQL 的生成与转换。既然 AI 能够把人类的自然语言转化成 SQL，那么它就更能够把人类的自然语言转化成关系代数的指令集了！把关系代数作为 AI 的处理目标，这个过程将变得更加简洁、高效、精确且没有歧义。而且，在应用开发领域，今天 AI 的实用场景下，AI 辅助编程是发展最迅猛的一块，也是效果显著的一块。所以，无论是用户（人）直接操作数据库还是开发人员在数据库基础上写应用，由

AI 通过关系代数与数据库打交道，是未来的趋势。

这个想法，是把“关系模型”的本质，和“AI 时代的接口结合起来，它比现在所有人都在做的 NL2SQL 更优雅、更简洁、更本质。

Codd 博士当年的初心：用关系代数操作关系

我们现在的方案：自然语言 → 关系代数 → 数据库这是一条被 SQL“耽误”了 40 年的极简路径！

有了 AI 的加持，新关系型数据库可以返璞归真，放弃实现 SQL 的负担，直接提供 E.F.Codd 博士当年提出关系型数据库理论时所设计的“关系代数”操作。这样的话，关系数据库底层将更简洁、更纯粹，更容易优化。

2. 关系代数基础

首先，我们来回顾一下关系代数的基础。看看关系代数到底有哪些基本运算（规范指令集）？以及关系代数的完备性，对当今常用 SQL 功能的覆盖程度。

2.1. 关系代数的「标准指令集」（核心规范）

关系代数真正原始、最基础的操作只有这几类，我们可以把它们理解成关系数据库的“机器码”。

1、基础集合运算（两个关系结构必须相同：属性名、类型一致）并 ∪ 差 −

交 ∩（有些定义里不算原始，可由差表示）

2、专为关系设计的核心原始运算（这是关系代数的灵魂）选择 σ (sigma)

按条件筛选行：σ 条件 (关系)

投影 π (pi)

选列，去掉重复行：π 属性列表 (关系)

笛卡尔积 ×

把两个关系拼起来：R × S

重命名 ρ (rho)

给关系/属性改名：ρ 新名 (关系)

在这 7 个操作里面，真正最小原始集是：

σ、π、×、∪、−、ρ

交 ∩ 可以不用，因为 R∩S = R−(R−S)。

3、常用“导出运算”（实际用得更多，但不是原始）这些都能由上面组合出来：

自然连接 ⋈ （最常用，相当于等值条件 + 投影去重） θ连接/等值连接左/右/外连接（也能表示，但稍复杂）

除法 ÷（典型用于“找全匹配”，SQL 里要写 EXISTS）

2.2. 关系代数的否完备性问题，对 SQL 查询功能的覆盖度

1、结论：关系代数是「关系完备」的，并且：在允许使用临时关系、多步表达式、子表达式的前提下，关系代数 ≡ 一阶谓词逻辑（关系完备）

它能表达 所有标准 SQL 中“关系完备”的查询。

2、什么叫「关系完备」？

Codd 博士给出的定义非常清晰：

凡是能用一阶谓词逻辑（只用到 AND、OR、NOT、∃、∀）描述的查询，都能用关系代数表达。

而几乎所有日常 SQL 查询都属于这一类：

- 多表连接 JOIN - 过滤 WHERE - 选列 SELECT - 子查询 IN / EXISTS / NOT IN

- 分组前筛选 HAVING 之前的逻辑（HAVING 之后的部分可以通过临时关系加多步表达式实现）

所有可以用多层嵌套表达的查询，只要不超出一阶逻辑，关系代数全能写。

3、关系代数与 SQL 的对比关系代数 能做到：

-所有查询逻辑

-所有连接、筛选、投影

-所有存在性判断（EXISTS）

-所有集合运算

关系代数原本不负责（不是查询能力）：

-INSERT / UPDATE / DELETE（这是关系演算扩展，或 SQL 扩展）

-视图、授权

- 聚合函数：COUNT、SUM、AVG、MAX、MIN - GROUP BY、ORDER BY

- 外连接在原始代数里不是基础操作，但可以表达

4、关键语法：「允许临时关系 + 多指令流程」

在这种条件下，我们可以把复杂查询拆成多步，每一步用关系代数生成临时关系，再对临时关系继续运算；这就构成了完整的查询能力，与现代 SQL 查询部分的表达能力完全等价。可以非常确定地说：任何一个标准 SQL 查询（不涉及聚合与排序），都能翻译成关系代数。加上聚合与排序，只是扩展，不破坏完备性。

5、总结

关系代数原始指令集：σ 选择、π 投影、× 笛卡尔积、∪ 并、− 差、ρ 重命名；这 6 个就是最小完备集。它是关系完备的。

在允许临时关系 + 多步表达式时：能表达所有一阶逻辑查询，能覆盖 SQL 里几乎所有普通查询；不能直接表达的只是聚合、排序、更新这类附加功能，不是查询逻辑本身。

3. 关系代数的语法设计与扩展

在此，我们针对专业人员/AI 生成场景设计一套“公式化的、贴近关系代数数学符号的语法 — 放弃自然语言的易用性（包括了不确定性），回归关系代数的数学本源，更适合自动化生成和专业场景使用。

3.1. 核心设计思路

1.符号优先：直接复用关系代数的希腊字母/数学符号作为核心操作符，抛弃自然语言关键词，极致贴合理论公式；

2.变量极简：临时表变量用简洁标识符（如：R、S、T1），赋值符简化为数学常用的 ←；

3.语法无冗余：去掉语句结束符、冗余关键字，仅保留核心运算逻辑，适配 AI 生成的简洁性需求；

4.兼容脚本流：支持多行顺序执行，变量可复用，满足脚本化执行的基础要求。

3.2. 公式化极简语法设计

3.2.1. 基础约定

l变量/表标识符：字母（大小写敏感）+ 数字 + 下划线，如：R、S1、T_sc（建议专业场景用单字母+数字，更简洁）；

l属性标识符：用 ‘.’ 区分表和属性（避免冲突），如 R.Sno、S.Cno；无冲突时可省略表名，如：Sno；

l 常量：字符串 'xxx'、数值 20、布尔 TRUE/FALSE；

l注释：仅保留单行注释 //（AI 生成脚本极少用多行注释）；

l执行逻辑：按行顺序执行，换行即表示语句结束，无需分号。

3.2.2. 核心操作语法（完全公式化）

直接对应关系代数的数学符号，语法格式与数学公式几乎一致：

关系代数操作

3.2.3. 条件表达式规则（公式化）

完全复用数理逻辑符号，无自然语言关键词： l 比较运算符：=（等于）、≠（不等于）、<、>、≤、≥；

l逻辑运算符：∧（与）、∨（或）、¬（非）；

l优先级：括号 () 提升优先级，与数学运算一致；

示例：σ((R.Sage>20 ∨ R.Sage<30) ∧ ¬(R.Ssex='female'))(R)。

3.2.4. 有关输入和输出的扩展语法

首先，加入“加载-输出”核心扩展，符号化设计：

3.2.5. 完整公式化脚本示例

以“查询 20 岁以上男生的姓名和选修课程号”为例，根据我们定义的规范，公式化的

脚本如下：

// 加载原始数据（⊕=加载）

R← ⊕('./student.csv', (Sno,Sname,Ssex,Sage)) // 学生表

S← ⊕('./sc.csv', (Sno,Cno,Score)) // 成绩表// 加载原始数据（⊕=加载）

R← ⊕('./student.csv', (Sno,Sname,Ssex,Sage)) // 学生表

S← ⊕('./sc.csv', (Sno,Cno,Score)) // 成绩表

// 1. 选择 20 岁以上的男生（σ=选择）

T1 ← σ(Sage>20 ∧ Ssex='male')(R)

// 2. 投影学生表的学号、姓名（π=投影）

T2 ← π(Sno,Sname)(T1)

// 3. 投影成绩表的学号、课程号

T3 ← π(Sno,Cno)(S)

// 4. 自然连接（⋈ =自然连接）

Result ← T2 ⋈ T3

// 输出结果（⊙=输出）

⊙(Result, './result.csv') // 输出到文件

⊙(Result) // 同时输出到终端

3.3. 关系代数的扩展

为了提升关系代数指令集的完备性，我们决定首先在基础的关系代数指令集中中加入聚合、分组、排序。

我们设计一个将聚合、分组、排序这类实用操作“优雅融入”极简公式化关系代数语法中，核心要兼顾「理论一致性」和「使用简洁性」——既不破坏关系代数的公式化风格，又能自然扩展核心操作，而非生硬叠加。这里根据该设计理念的扩展语法方案：

3.3.1. 核心设计原则：

l符号化优先：延续希腊字母/数学符号体系，不引入自然语言关键词；

l极简扩展：将聚合/分组/排序作为「衍生操作」，而非新增核心操作，保持原语法的简洁性；

l层级清晰：分组是「聚合的前置条件」，排序是「最终结果的修饰」，逻辑上贴合关系代数的集合操作逻辑；

l兼容变量：所有扩展操作结果均可赋值给临时表变量，适配脚本化执行。

3.3.2. 公式化扩展语法设计

1、聚合操作（Aggregation）

设计思路：聚合本质是「对关系的属性列做数值计算」，用希腊字母 `γ`（Gamma，对应 Group/Aggregate）作为聚合运算符，格式上贴合投影（π）的写法，保持语法一致性。

示例：

// 计算学生表中年龄的平均值和总人数，结果赋值给 T1

T1 ← γ(avg(Sage)→avg_age, count(Sno)→total_student)(R)

// 计算成绩表中总分、最高分、最低分

T2 ← γ(sum(Score)→total_score, max(Score)→max_score, min(Score)→min_score)(S)

特殊说明：

l无分组时，聚合会将整个表视为一个组，返回单行结果（符合关系代数的「关系」特性，结果仍为表，而非单个值）；

lcount(*)用 count(ALL)替代，保持公式化：γ(count(ALL)→total_rows)(R)。

2、分组聚合（Group By + Aggregation）

设计思路：分组是「先按属性分组，再在组内聚合」，因此在聚合运算符 `γ` 中增加「分组属性」，格式为 `γ(分组属性; 聚合表达式)(表/变量)`，用分号分隔「分组条件」和「聚合表达式」，层级清晰。

示例：

// 按性别分组，计算每组的平均年龄、人数

T3 ← γ(Ssex; avg(Sage)→avg_age, count(Sno)→gender_count)(R)

// 按课程号+性别分组，计算每组的成绩平均分

T4 ← γ(Cno,Ssex; avg(Score)→avg_score)(JOIN R,S) // 先连接再分组聚合

3、排序操作（Sorting）

设计思路：排序是「对关系的行进行有序排列」，属于「结果修饰」，而非核心集合操作，因此用前缀符号 `τ`（Tau，对应 Total Order），格式为 `τ(排序规则)(表/变量)`。

示例：

// 按年龄升序排序（省略↑）

T5 ← τ(Sage)(R)

// 按课程号升序、成绩降序排序

T6 ← τ(Cno↑,Score↓)(S)

// 分组聚合后再排序（链式操作）

T7 ← τ(avg_score↓)(γ(Cno; avg(Score)→avg_score)(S))

4、组合用法（完整脚本示例）以「按课程号分组计算平均分，筛选平均分≥80 的课程，再按平均分降序排序」为例，

展示完整的公式化脚本：

// 加载原始数据

R ← ⊕('./sc.csv', (Sno,Cno,Score)) // 成绩表

// 1. 分组聚合：按课程号计算平均分

T1 ← γ(Cno; avg(Score)→avg_score)(R)

// 2. 选择：筛选平均分≥80 的课程（复用核心选择操作σ）

T2 ← σ(avg_score≥80)(T1)

// 3. 排序：按平均分降序

Result ← τ(avg_score↓)(T2)

// 输出结果

⊙(Result)

3.3.3. 进阶扩展

为了满足更精细的控制，我们在不破坏核心语法的基础上继续补充了以下极简扩展：

1、去重操作（Distinct）

复用投影运算符 `π`，增加后缀 `!` 表示去重（默认投影已去重，此处为显式声明）：

// 显式去重：获取所有不重复的课程号

T8 ← π!(Cno)(S)

2、限制结果行数（Limit）作为排序的补充，用后缀符号 `#` 表示行数限制，格式为 `τ(规则)#N(表)`：

// 取成绩最高的前 10 条记录

T9 ← τ(Score↓)#10(S)

3、空值处理聚合函数中用 `[ignore_null]` 作为可选后缀，默认忽略空值，保持语法简洁：

// 计算平均分（忽略空值，默认）

T10 ← γ(avg(Score)[ignore_null]→avg_score)(S)

注意：关于「窗口函数」「Top-N」等更进阶的操作，我们将在后续的版本中设计。基于上述语法的 BNF 范式（用于解析器的实现），可以借助 AI 的能力生成。

3.4. 本系统关系代数语法设计的技术特点

在关系代数的语法设计中，我们关注了：

1.核心语法完全复用关系代数数学符号（σ/π/×/∪/−/ρ/⋈ ），替换自然语言关键词，极致公式化；

2.赋值用 `←`、加载用 `⊕`、输出用 `⊙`，保持符号化统一，适配专业 AI 生成场景；

3.条件表达式使用数理逻辑符号（∧/∨/¬），无自然语言冗余，语法规则与数学公式完全对齐。

4.聚合/分组复用运算符 `γ`，格式为 `γ(分组属性; 聚合表达式)(表)`，聚合函数用小写缩写（sum/avg 等），保持公式化；

5.排序用运算符 `τ`，格式为 `τ(属性[↑/↓])(表)`，可叠加行数限制 `#N`；

6.所有扩展操作均可与原核心关系代数操作链式执行，结果赋值给临时表变量，适配脚本化执行，且完全贴合专业/AI 生成的场景需求。

在技术上体现了：

1.AI 友好：公式化语法结构固定、无歧义，AI 生成时无需处理自然语言的模糊性，只需按“符号+变量+表达式”的固定模板生成；

2.专业适配：完全贴合关系代数理论公式，专业人员无需记忆自然语言关键词，直接用数学思维编写脚本；

3.极简高效：无冗余语法元素，脚本行数少、逻辑紧凑，适合自动化执行和批量生成；

4.易解析实现：语法规则高度结构化，解析器只需处理“符号+括号+变量+属性”四类核心元素，无需复杂的自然语言分词/解析。

5.风格统一：所有扩展操作均使用希腊字母/数学符号，延续原公式化语法，无自然语言冗余，AI 生成时模板化程度高；

6.在扩展方面：

1)逻辑优雅：

n分组聚合是「聚合的增强版」，复用 `γ` 运算符，无需新增核心操作；

n排序是「结果修饰」，用前缀 `τ` 标识，不影响关系代数的核心集合操作逻辑；

2)极简边界：仅扩展最常用的聚合（sum/avg/count/min/max）、分组、排序，无多余功能，符合“返璞归真”的设计理念；

3)兼容原有操作：扩展操作可与核心操作（σ/π/⋈ 等）无缝链式执行，变量赋值逻辑完全一致。

4. 数据集成服务器

今天，我们要开发一款提供关系代数接口的数据库时，我们需要考虑什么？我们要考虑的不仅仅是这款数据库如何实现，还要考虑什么样的用户会来使用这款数据库。

关系型数据库市场发展到今天已有 40 多年了，这已经是一个非常成熟的市场。因此，世界上大大小小的数据库不计其数，用户的数据也都基本存放于现有的数据库中。对于市场上的一个用户来说，很少有成规模的数据还没有数据库产品来管理的。

从另一方面看，今天的市场，经过几十年的积累，已经存在大量的数据库以及数据仓库。对于信息使用者来说，打破信息孤岛，充分有效地访问数据、使用信息，是一件具有强需求的事情。所以，我们不仅要构建一个提供关系代数的数据库，而且要构建一款提供关系代数接口的数据集成服务器。

也就是说，我们在开发关系代数接口的数据库时，不仅仅要做自己的存储引擎，还要能够把当前市场上其它各种关系型数据库作为数据源集成到我们的数据库中有能把现有其它数据库接进来的能力。甚至于后者更加重要。

4.1. 历史上的数据集成技术与产品

在数据库技术发展的历史上，有不少公司在跨平台数据访问上做了工作、推出了产品，接触得比较多的有：

lIntersolv - 在 1995 年左右，美国 Intersolv 公司开发了针对各种关系数据库和其它数据源的 ODBC 接口。试图用标准的 ODBC 在一个平台上访问各类数据源，打破企业信息孤岛的情况。不过，这样的解决方案属于纯客户端的，难以在一个查询中整合多源的数据

（如：跨节点异构连接）。

lSybase Omni SQL Server - Sybase 在 1994 年底推出一款 Omni SQL Server 的产品。该产品对外提供 SQL 访问的接口，给用户的感觉是一个 Sybase 的数据库服务器，而不同的地方在于 Omni SQL Server 自身并不存储和管理数据，它背后连接其它各种异构的数据库，把它们当成真正的数据源。当时的 Omni SQL Server 可以提供跨节点的表连接，但不支持跨节点的更新和事务，以及分布式的两阶段提交。

lOracle DB-Link - 在 Oracle 中，有 DB-Link 模块可以访问其它的数据库服务器，也包括异构的产品。

lIBM DB2 Information Integrator/IBM InfoSphere Information Server - IBM 在数据管理类产品中，数据集成服务器做的工作是比较多的。在 2001 年左右，推出了 Information Integrator，后来该产品整合到 InfoSphere 系列，核心产品是 InfoSphere Information。该产品就是我们所说的典型的数据集成服务器。它背后可以连接各种关系型数据库，而在前端提供统一的数据库视图，给用户的感觉就是一个标准的 DB2 数据库服务器。

数据集成服务器，这个概念在历史上也有人称它为“数据联邦”或者数据库网关（Database Gateway）。功能比较全面，技术投入、市场宣传做得比较多的是 IBM InfoSphere Information Server。如今，这项技术与 Data Fabric 和“数据编织”的概念由联系到了一起。

4.2. Information Server 的实现

我们现在要实现的，就是一款对外提供关系代数(Relational Algebra)接口的数据库服务器。

该服务器既可以访问自有的数据引擎，也可以访问其它异构的关系型数据库，从而成为数据集成服务器（Data Integration Server）。而有了 Data Integration Server，我们就能把客户的各种数据库整合到一起，提供统一的查询视图，打破信息孤岛的困扰。

实现思路：

1、建立一个服务器守护进程，在接到用户连接请求时 Fork 一个子进程负责该用户的会话。目前，实现一个多进程的服务器结构就可以。

用户的认证与访问控制，暂时可以沿用 Linux 操作系统的用户管理与访问控制体系。这样可以节省研发资源，在功能上也不弱，未来还可以适应定制化的操作系统。

服务器的对外服务，可以考虑传统的 Client/Server 架构，保持连接与会话。也可以考虑提供无长连接的 Web Services/Restful API 的形式，通过 token 来连接上下文。

服务器端将考虑客户端非正常消失时释放资源的问题。

2、数据集成服务器有自己的数据字典管理，该数据字典可以采用文件，或者嵌入式的数据库来承载。该数据字典记载数据的来源、权限、结构。

3、该服务器有一个能够解析关系代数指令所组成的脚本的解释器，并可以对解析后的关系代数指令脚本做一定程度的优化。例如，把单一关系的条件过滤放到连接之前。

该解释器可以基于关系代数脚本的 BNF，由 lex 和 yacc 生成器实现代码的生成。BNF 可以通过语法规范的描述，借助 AI 来提升设计效率。

4、该服务器中有一个关系代数脚本的执行器。服务器的一个会话服务，返回给客户端的是一个关系数据集：R。

服务器端与客户端的通信协议需满足一个关系数据集的高效传输。

关系代数的脚本，支持关系变量 T，也就是一个临时关系；而这个临时关系（或者叫关系变量）它的作用域是当前会话。

可以支持多个关系代数指令的流程（脚本），可以暂不支持指令的嵌套（所谓嵌套，可以通过临时关系迭代完成）。

不支持其它过程性语言的结构，数据库端的存储过程都交给中间件层去做。

暂时不支持在脚本中嵌入函数，未来是否支持，看用户实际应用的情况。

执行器的开发可借助 AI 的辅助。

5、数据集成的访问，暂仅实现只读的查询访问。在第一步，先实现 MySQL 和 PostgreSQL 的集成。其它数据库随后照猫画虎。

6、有关更新操作，OLTP 场景，都将以本地数据管理引擎为支撑。在本地存储引擎构建 OLTP 功能的时候，还需要引入插入（从另一个关系插入）、更新（“选择”操作的语法与“更名” 组合？）、删除（可沿用“选择”操作语法）；在 OLTP 场景中，考虑引入显式的封锁指令，可以指明封锁的范围。这里，还需要设计一个有效的语法。这里，我们想到的问题是：在现有的关系数据库事务处理过程中，数据可见性和事务管理实际上受到 SQL 语言的限制。在 SQL 中并没有规定各个更新语句对于数据封锁的范围。例如：在 select for update 语句中，一般默认是被 select 子句选中的数据行才会被封锁。但实际上，那些没有被选中的数据行，很可能在此期间被其它会话更新，使得它们有一部分符合了 select for update 的条件。这样就引发了不确定性，它取决于数据库彼时的执行状态。

7、远端数据库的访问

关系代数的脚本，能够解析成最原始的关系，R。而这个 R 就对应了源数据库的某张表。该表的数据可以通过传统的 SQL 语句：select * from t; 从远程获得。在脚本优化的情况下，从远程获得表数据的过程中，可以附带查询条件。

跨节点的表连接基本在本地做。同时，也先不考虑 pass through，因为我们本服务器已经抛弃了 SQL。

数据集成服务器在本地管理巨大的临时表空间。该表空间由内存、文件组合来提供。在硬件上会引入 NVRAM 进行性能优化。

8、对于后台的数据库，最好有连接的能力（在权限对应的情况下）。我们的 Information Server 平时保留尽可能少的数据库连接。可以考虑管理一个本地的连接池。

9、本地的存储引擎开发，考虑与市场上较强的存储引擎开发团队合作。包括有创新概念的实验性探索。

4.3. Information Server 的架构图

5. AI 赋能的自然语言访问

我们的 Information Server 提供关系代数的接口，这个接口可以直接使用。但在 AI 时代，普通用户使用我们的 Information Server，可以通过自然语言发出查询请求。系统将通过如下的处理流程：

用户自然语言 → LLM → 关系代数表达式 → Information Server → 结果

最终给到用户想要的查询结果。

LLM 为什么能读懂用户的自然语言？这就涉及到关于 LLM 上下文，有关 Skill 的提示。

5.1. 关于 AI 提示的设计

我们设计了一套「关系代数生成 Skill 提示词」模板。它严格分成两部分：

1、固定不变的系统技能（Skill 本体）

2、可替换的数据库结构（Schema 部分）

用户只需要替换第 2 部分，就能适配任意数据库。

5.1.1. 固定部分：关系代数生成 Skill（永久不变）

- 严格使用下面提供的表结构

5.1.2. 动态部分：数据库表结构 Schema（每次换库只改这里）示例（用户可以替换成自己的表）：

5.1.3. 完整组合示例（直接可复制给 LLM）将上述两个文本文件组合起来复制给 LLM 即可。

5.1.4. 用户输入示例 & 输出效果

用户输入：

查询计算机系成绩大于 90 分的学生姓名

我们将得到 LLM 的输出：

π (sname) (σ (dept='CS' ∧ score>90) (Student ⋈ SC))

5.2. 这套提示词的特点（为什么叫 Skill）

固定部分（Skill 部分）不动：语法、格式、约束永久不变

Schema 部分可插拔：换数据库只换中间一段

LLM 输出极稳定：只给代数表达式，不废话

5.3. 接下来的工作

1、试验上述提示词组合的效果；

2、引入扩展指令后的效果；

3、如果允许关系变量（临时变量），如何使用多语句实现嵌套。同时，如何限制单语句内的嵌套。

4、做更多复杂的实验；调整、改进 Skill 内容。

6. AI 赋能的智能分析

Information Server 的功能并不止步于仅仅提供自然语言的查询。我们试图在这个基础上加入各个行业数据分析的知识，使得用户可以向该系统提问关于某个行业的，抽象化的业务问题。例如：用户可以问：“我们银行本季度的业绩表现如何？”

为此，我们将整理我们几十年来的各行业数据分析的经验，把各个行业从业务的角度，最重要、最全面的分析角度，最有效的分析过程，作为 Skill 存放在我们 Information Server 的元数据中，它将被提供给 LLM 生成自然语言描述的各类查询。然后再进入自然语言到查询的过程。最后，Information Server 会解读查询结果，给到用户业务分析的答案。

这里是关于金融行业数据分析的一个模板，示例：

这与自然语言查询在入口处有区别，自然语言查询是直接查询，系统仅仅给出查询结果，不做分析。智能分析不需要给出具体的查询需求，而且系统会根据结果给出自然语言的分析表述。