我问 AI ，企业数字化差什么？

他说最难的是数据清洗，库太多，数据录入不规范，字段命名乱。ai 要靠猜。

所以花了两周写了个中间层，想解决"企业多个数据库接 LLM 时字段乱、权限乱、口径乱"的问题。写了 7000 行 Python 、134 个测试、3 份架构 spec 。然后意识到：我没有用户，没有真实场景验证，可能从头到尾在解决一个我想象出来的问题。

发出来给大家看看，也许有人真遇到过这个痛点，也许大家帮我确认这就是个锤子找钉子。

---

想解决什么问题

企业内部通常有好几个数据库：销售用 MySQL 、财务用 PostgreSQL 、HR 用 SQL Server 。现在老板说要接 LLM 让业务人员自然语言查数据。

直接接会遇到这些问题：

问题	举例
字段名无意义	aa字段是单价，hj是合计，LLM 猜不出来
同名不同义	销售库的"金额"是回款，财务库的"金额"是开票
权限失控	销售员能查到成本和利润率
没有 SQL 审查	LLM 生成的 SQL 可能 DROP TABLE
敏感数据裸奔	手机号身份证明文返回

我的想法是在数据库和 LLM 之间加一层，把这些脏活自动化：

企业数据库群（ MySQL/PG/SQLite/Oracle/达梦）
        ↓
┌─────────────────────────────────┐
│         KaiwuBridge             │
│  自动理解字段含义（不用人工标注）  │
│  权限控制 + SQL 审查 + 数据脱敏   │
│  跨库字段自动对齐               │
└─────────────────────────────────┘
        ↓
任意 LLM （本地 Ollama / DeepSeek / GPT ）

核心卖点是不用人工洗库——传统做法是 DBA 花几周给每个字段写注释、建数据字典，我想用 LLM+统计方法自动搞定。

---

实现了什么

1. 自动理解字段含义（图传播方案）

不是简单让 LLM 看字段名猜含义，而是：

1. 数据画像：统计每个字段的分布、空值率、唯一值比例
2. 代数关系检测：自动发现 单价 × 数量 ≈ 合计 这种关系
3. 建图：把字段、外键、代数关系建成一张依赖图
4. 图传播：LLM 在图上迭代 3-5 轮，每轮看邻居字段的描述来修正自己的理解

这样即使字段名是aa，系统也能通过"aa × 整数字段 ≈ hj"推断出 aa 是单价。

灵感来自 2026 年 3 月的 DBAutoDoc 论文，核心思想是 schema 理解本质上是图结构问题。

2. 七层安全防线

物理层（只读账号）→ SQL 白名单（只允许 SELECT ）→ 注释绕过防护 →
字段级权限（ LLM 看不到=查不到）→ 行级过滤 RLAC （华东员工只看华东数据）→
数据脱敏（手机号自动打码）→ 动态脱敏（按角色返回不同精度）

3. 解耦架构（三个接口）

GET  /v1/context  — Agent 获取 schema+权限+映射+歧义信号
POST /v1/execute  — Agent 提交 SQL ，中间层负责安全检查+执行+脱敏
POST /v1/chat/completions — OpenAI 兼容接口（兼容层）

Agent 层和数据层彻底分离。Agent 只管生成 SQL ，中间层只管安全执行。

4. 跨库字段自动对齐

• bge-m3 embedding + Wasserstein 分布距离
• 主动学习：优先推送置信度 0.6-0.8 的模糊案例给人审核（信息价值最高）
• 用户确认/拒绝后自动提取规则，不是调阈值

5. 告警过滤

同一个错误短时间内反复出现且从未成功 → 自动压制，不打扰用户。管理员可以看到"僵尸规则"列表。

6. Schema Linking （ LLM 路由）

企业可能有几十张表、几百个字段，不可能全塞给 LLM 。需要根据用户问题精准定位到相关的 2-3 张表。

做法参考了 SchemaGraphSQL （ ACL ARR 2025 ）：

1. 建图：把所有表作为节点，外键关系+跨库映射作为边
2. LLM 实体提取：一次调用从问题中提取关键实体，映射到相关表
3. BFS 扩展：在图上从相关表出发走 2 跳，把 JOIN 需要的关联表也带上
4. 精选子集：最多给 LLM 看 5 张表的 schema ，而不是全量几十张

这样 LLM 生成 SQL 时只看到精选的、和问题相关的表，不会被无关表干扰，生成准确率显著提升。

零样本、不需要 embedding 模型、不需要训练。一次 LLM 调用搞定路由。

---

功能全景（经过几次迭代后的当前状态）

从最初只有"连数据库+调 LLM"，到现在塞了一堆功能。用一张表说清楚每个模块干什么：

功能模块	解决什么问题	什么场景用	原理/技术
数据画像 (profiler.py)	字段名无意义时无法理解数据	scan 时自动运行，给每个字段建统计档案	空值率/唯一值比例/数值分布/高频值采样
代数关系检测 (profiler.py)	aa×bb≈cc这种隐含业务关系人看不出来	同表内数值字段三元组枚举	numpy 向量化计算，5%误差容忍度
图传播引擎 (graph_propagation.py)	单看一个字段猜不出含义，需要上下文	scan --semantic 时替代逐字段 LLM 生成	建依赖图→LLM 迭代 3-5 轮→邻居描述作为 context 精化
Schema Linking 路由 (schema_graph.py)	几十张表不能全塞给 LLM	每次用户提问时自动触发	外键图+LLM 实体提取+BFS 2 跳扩展，精选≤5 张表
跨库语义匹配 (matching.py)	不同库的"金额"可能是不同概念	scan 后自动两两匹配，生成 pending 映射	bge-m3 embedding + Wasserstein 分布距离
主动学习 (matching.py RuleExtractor)	人工审核效率低，不知道先审哪个	管理界面展示待审核映射时排序	优先推送置信度 0.6-0.8 的案例（信息价值最高）
SQL 白名单审查 (security.py)	LLM 可能生成 DROP TABLE	每次执行 SQL 前强制检查	sqlparse 语法树分析，只放行 SELECT/WITH
字段级权限 (permissions.py)	销售员不该看到成本字段	schema 发给 LLM 前过滤	配置 denied_columns ，物理移除字段
行级过滤 RLAC (executor.py)	华东员工只能看华东数据	SQL 执行时 CTE 子查询包装注入 WHERE	不依赖 LLM"自觉"，执行层强制注入
数据脱敏 (security.py + executor.py)	手机号身份证不能明文返回	结果返回前自动处理	正则打码 + 按角色动态精度（ full/partial/round ）
告警过滤 (alert_filter.py)	同一个错误反复弹出烦死人	兼容层执行失败时判断	滑动窗口频率统计，≥5 次且 0 成功→压制
歧义检测 (server.py)	"销售额"在两个库都有，用哪个？	/v1/context 接口返回歧义信号	语义名片匹配+多库来源检测，含 confidence
数据新鲜度 (executor.py)	查到的数据可能是上周的	执行成功后附加提示	查 MAX(updated_at)，超 24 小时警告
映射导入导出 (admin.py)	DBA 想在 Excel 里批量维护映射关系	管理后台 CSV 上传下载	CSV 解析 + LLM 验证层（检查明显错误）
持续学习 (admin.py + matching.py)	用户反馈应该让系统越来越准	confirm/reject 映射时自动触发	贝叶斯更新阈值 + 规则提取（不只是调参）
解耦接口 (server.py)	Agent 层和数据层耦合在一起不好扩展	Agent 自己生成 SQL 时用 context+execute	REST 分离：context 只给数据，execute 只管执行

一共 22 个 Python 模块，7015 行代码。说实话写到后面自己都觉得功能堆太多了。

---

测试和结果

代数关系检测

用 100 行模拟订单数据测试：

• 召回率：100%（ 2/2 个标注关系全部检测到）
• 误报率：0%（编码字段没有被误判为代数关系）

语义匹配基线（诚实报告）

用 10 对手工标注的跨库字段对测试：

• **负例拒绝率：100%**（不相关字段不会被误匹配）
• **正例召回率：0%**（裸英文字段名在 bge-m3 上语义分全部低于阈值）

这个 0%是预期的——证明了图传播层的必要性。裸字段名sales_amount和revenue的 embedding 相似度只有 0.67 ，低于 0.85 阈值。需要图传播先生成中文描述（"每笔订单的含税销售金额"），再做匹配才有意义。

但我还没有在真实数据库上跑过完整流水线。

安全测试

65 个安全测试覆盖：SQL 注入（含注释绕过）、JWT 伪造、越权访问、频率限制、数据脱敏。全部通过。

总计

134 passed, 0 failed, 21 warnings

---

技术栈

• Python 3.12 + FastAPI + SQLAlchemy 2.0
• sentence-transformers (bge-m3) 做 embedding
• numpy/scipy 做统计验证
• SQLite 存元数据（零部署）
• 支持 MySQL / PostgreSQL / SQLite / SQL Server / Oracle / 达梦 / 人大金仓

全部依赖 Apache 2.0 / MIT / BSD ，可商用。

---

为什么说是锤子找钉子

写完之后冷静下来想了几个问题：

1. 谁是用户？

我假想的场景是"中型企业，有 3-5 个业务数据库，想让业务人员自然语言查数据"。但我没有找到一个具体的企业说"我需要这个"。

2. 真实场景下这个问题存在吗？

也许存在，但解决方案可能不是我想的这样：

• 大企业有数据中台团队，人工建数据字典不是问题
• 小企业可能就一个 MySQL ，不需要跨库对齐
• 中型企业可能更需要的是 BI 工具而不是自然语言查询

3. "不用人工洗库"这个卖点成立吗？

图传播方案理论上能自动理解字段含义，但：

• 需要 LLM （本地 7B 模型够不够？需要 API 调用？）
• 准确率未在真实脏数据上验证
• 企业可能宁愿花一周人工标注也不愿意信任自动化结果

4. 过度工程了吗？

7000 行代码、图传播、主动学习、告警过滤、动态脱敏……如果第一个用户只需要"连 MySQL + 权限控制 + 调 DeepSeek"，那 90%的代码都是提前优化。

---

如果你遇到过这个问题

想听听大家的看法：

1. 是我想的这么简单么数字化落地?LLM + 优化层 计入数据库，就 AI 落地么？
2. 真实企业数字化落地最难攻克什么？
3. 这个方向值得继续做吗？还是应该 pivot 成更具体的东西（比如只做 SQL 安全审查层）？

代码在本地，如果有人感兴趣可以开源。也欢迎直接告诉我这是个伪需求，省得我继续往里面投时间。

---

参考的论文和开源项目

来源	用在哪	怎么用的
SchemaGraphSQL (ACL ARR 2025)	Schema Linking 路由	核心思想：用外键关系图+LLM 实体提取+BFS 路径搜索做 schema linking ，零样本不需要训练。我直接实现了这个方案
DBAutoDoc (2026.03)	图传播引擎	核心思想：schema 理解是图结构问题，通过依赖图迭代传播语义修正直到收敛。我简化了实现，没用原文的 GNN ，直接 LLM 迭代
LLM-FK (2025)	外键发现思路	三 agent 协作（ Interpreter/Refiner/Verifier ）的思路启发了我的约束发现设计，但我没实现多 agent ，只用了统计方法
Valentine	跨库匹配 baseline	schema matching 的开源 benchmark ，参考了它的评估方法论（ precision/recall on labeled pairs ）
ALITE	约束发现	用数据分析发现函数依赖和包含依赖的思路，我简化成了代数关系检测（ A×B≈C ）
sentence-transformers	embedding 计算	直接用的 bge-m3 模型做字段语义向量化
FastAPI	Web 框架	OpenAI 兼容接口
SQLAlchemy	数据库连接	多数据库统一适配层
sqlparse	SQL 安全审查	语法树分析，白名单验证，表名提取

部分论文 ai 搜的，，，， 说实话，论文读了不少，但真正落地时大幅简化了。DBAutoDoc 原文用的是 GNN 做图传播，我直接用 LLM 迭代替代了（因为目标场景是企业内部几十张表，不是几千张表的学术 benchmark ，LLM 迭代 3-5 轮完全够用）。

---

技术细节：Python 3.12 / FastAPI / SQLAlchemy / bge-m3 / 图传播架构 / 134 测试全绿

附仓库（为了避免说推广仓库的，所以放最后）： https://github.com/val1813/kwb