做了个中间层，想帮企业不用洗库就能接 LLM，但担心自己是不是在锤子找钉子

小袁同学 · 2026-05-16T06:52:05.210Z

最近被一个问题卡住：企业想上 LLM 查数据，但库太多、字段乱、权限散，直接接根本没法用。我问了一圈，发现最头疼的是数据清洗——DBA 得花几周给每个字段写注释、建字典，LLM 全靠猜。于是花了两周写了套中间层，叫 KaiwuBridge，想试试能不能自动化搞定这些脏活。目前写了 7000 行 Python、134 个测试、3 份架构文档，但越做越虚：没有真实用户，也没实际场景验证，可能从头到尾都在解决一个我自己脑补的问题。发出来看看有没有人真遇到过类似痛点，或者直接告诉我这就是个锤子找钉子也行。主要想解决几个问题： - 字段名无意义（比如 `aa` 是单价，`hj` 是合计） - 同名不同义（销售和财务的“金额”含义不同） - 权限失控（不该看的能查到） - SQL 审查缺失（LLM 可能生成 DROP TABLE） - 敏感数据裸奔（手机号、身份证明文返回）做法是在数据库和 LLM 之间加一层，自动理解字段、控制权限、对齐跨库数据。核心卖点是某词不用人工洗库某词，用 LLM + 统计方法自动推断字段含义。实现上用了图传播方案：先做数据画像，检测代数关系（比如 `单价 × 数量 ≈ 合计`），建依赖图，再让 LLM 在图上迭代修正理解。还加了七层安全防线，从只读账号到动态脱敏。架构也尽量解耦，三个接口： - GET /v1/context：Agent 获取 schema、权限、映射 - POST /v1/execute：提交 SQL，中间层做安全检查+执行+脱敏 - POST /v1/chat/completions：兼容 OpenAI 接口跨库对齐用了 bge-m3 embedding + Wasserstein 距离，主动学习优先推模糊案例给人审核。Schema Linking 参考了 SchemaGraphSQL，用 BFS 扩展精准路由到相关表，避免 LLM 被无关表干扰。现在功能堆了不少，从连库调 LLM 一路迭代到现在的样子，但越堆越怕方向偏了。