锤子找钉子的项目分享：假想企业本地部署后不用人工洗库接入 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 调用？）
- 准确率未在真实脏数据上验证
- 企业可能宁愿花一周人工标注也不愿意信任自动化结果
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
