锤子找钉子的项目分享：假想企业本地部署后不用人工洗库接入 LLM 的中间层

我问 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 看字段名猜含义，而是：

数据画像：统计每个字段的分布、空值率、唯一值比例
代数关系检测：自动发现 单价 × 数量 ≈ 合计 这种关系
建图：把字段、外键、代数关系建成一张依赖图
图传播：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 ）：

建图：把所有表作为节点，外键关系+跨库映射作为边
LLM 实体提取：一次调用从问题中提取关键实体，映射到相关表
BFS 扩展：在图上从相关表出发走 2 跳，把 JOIN 需要的关联表也带上
精选子集：最多给 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%的代码都是提前优化。

如果你遇到过这个问题

想听听大家的看法：

是我想的这么简单么数字化落地?LLM + 优化层计入数据库，就 AI 落地么？
真实企业数字化落地最难攻克什么？
这个方向值得继续做吗？还是应该 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

[Local LLM] 锤子找钉子的项目分享：假想企业本地部署后不用人工洗库接入 llm 的中间层。