当前位置：首页 > news >正文

企业想用AI做数据分析，但数据不能出内网，怎么办

news 2026/7/5 1:49:22

企业想用AI做数据分析，但数据不能出内网，怎么办

私有化部署不只是装个Docker的事

一个很现实的困境

很多技术负责人找到我说同样的话。

“我们想用AI做数据分析，但数据不能出内网。你有没有合适的方案？”

这不是小问题。金融、医疗、政企、制造业，这些行业的数据是核心资产，监管要求、合规审查、商业机密，每一条都在说同一件事，数据不能离开你控制的服务器。

但市面上大部分AI数据工具都是SaaS。你把数据传上去，它帮你分析。逻辑没问题，只是数据出了你的边界。又或者也有人问我们和豆包有啥区别，其实差别很大。我们的功能远不是通用大模型可以比较的。

有人试过自己搭。用开源的Text-to-SQL模型，自己接个LLM API。跑起来后发现几个问题，模型不知道你的表结构，生成一堆报错，权限控制自己从头写，响应速度慢到没人用，最后变成技术团队自嗨，业务部门根本不碰。

这条路能走通，但坑不少。

私有化部署的底线要求

先把问题拆开看，一个能真正在企业里用的AI数据分析工具，至少要解决这几件事。

数据不出内网。这是前提，不是可选项。所有数据查询、元数据采集、AI推理，都应该在企业的网络边界内完成。

能连现有的数据库。不是让用户把数据导来导去，而是直接连接已经在跑的数据库。而且数据库类型可能五花八门，MySQL、PostgreSQL、Oracle、ClickHouse，甚至还有信创数据库比如达梦、人大金仓。

权限不能丢。企业里已经有的行级、列级权限控制，上了AI工具之后不能失效。一个销售看自己的区域数据，一个运营看全量数据，这个规则在自然语言查询时同样要生效。

响应速度要能接受。用户问一个问题，等一分钟才出结果，这个工具就不会有人用第二次。

可维护、可排查。出了问题得知道是哪一环的问题，是LLM理解错了，是SQL写错了，还是数据库本身慢。

AskTable的私有化方案

AskTable 在这块做得比较扎实，所以我直接拿它来聊。

它的私有化部署方式是Docker All-in-One。一个docker-compose up把所有组件跑起来，包括：

PostgreSQL（系统元数据存储）
Redis（缓存和任务队列）
Qdrant（向量检索，用于语义搜索字段）
FastAPI后端（核心服务）
Nginx（反向代理）

这些全部跑在你自己的服务器上。容器内不存储任何业务数据，只存系统配置和元数据。

连数据库的方式是直连。配置好目标数据库的连接字符串，AskTable直接去读表结构，提取schema。数据本身不迁移，留在原处。

模型配置支持多种方案。可以接Claude API或GPT API（走公网），也可以配置本地LLM。模型组在系统里管理，运行时可以随时切换。对于数据完全不出网的要求，本地LLM是唯一选项。

安全隧道：连防火墙后面的数据库

有一种场景比较麻烦。

企业的数据库在内网防火墙后面，没有公网IP，外部服务根本访问不到。但你想用的AI工具可能部署在云服务器上。

AskTable的解法是一个叫Secure Tunnel的组件。

基于frp做动态端口分配。隧道服务跑在内网，主动向云服务器建立连接，建立一条加密通道。云端的AskTable通过这条隧道访问内网数据库，不需要开放任何入站端口。

这个方案的安全逻辑是，内网主动出站建立连接，不需要开放入站端口。攻击面比直接暴露数据库端口小得多。

具体实现上，隧道服务是一个独立部署的Go程序，不跟主服务耦合。配置好服务器地址和API Key，启动就自动建连。断线自动重连。

权限体系：RBAC + 行级/列级控制

上了AI工具之后，原有的权限体系不能废掉。

AskTable的权限框架是RBAC（基于角色的访问控制）加上数据访问策略。

角色权限比较好理解，管理员、分析师、访客，不同角色看到的功能不同。管理员可以配置数据源、管理用户，分析师可以创建Bot和画布，访客只能通过public link查看。

真正有技术含量的是数据访问策略。

行级过滤。通过SQL解析器实现。在LLM生成的SQL外层包一层过滤条件。比如一个销售只能看region = '华东'的数据，这个条件会被自动注入到每一条查询中，用Jinja模板写动态条件。

列级权限。某些字段对某些角色不可见。比如手机号、身份证号这些敏感字段，普通角色查询时会被自动脱敏或隐藏。系统有一个SDI（Sensitive Data Identification）模块，自动识别这些字段类型。

关键是，这些权限控制发生在SQL执行之前，不是执行之后的结果过滤。也就是说，权限之外的数据根本不会被查询到，不存在"查出来再过滤"的性能浪费和安全漏洞。

准确率：不是靠一个模型

在企业场景下，SQL生成准确率直接决定这个工具能不能用。

一个很现实的问题是，企业的数据库表结构和命名方式往往很不规范。t_ord_dtl_2024这种表名，直接问AI"订单详情"，它根本对不上。

AskTable的方案不是"换一个更强的模型"就完事了，而是几层工程手段叠加。

元数据标注。让业务人员自己给表和字段标注业务含义。t_ord_dtl_2024标注为"订单明细表"，字段ord_sts标注为"订单状态"。AI在生成SQL时用的是这些业务语义，不是技术命名。

术语库（Glossary）。管理业务术语和同义词。比如公司里说的"有效订单"，对应的状态组合是什么，录进术语库。用户提问时，AI会先做术语匹配，再去做schema linking。

训练集。收集"好的问题-正确的SQL"问答对。支持手动录入和从历史对话自动积累。生成SQL时做few-shot提示，让模型参考已有的高质量样例。还有一个测试集功能，批量跑测试用例，看生成质量。

向量索引。元数据建立向量索引后，用户提问时先做语义搜索，找到相关的表和字段，再让LLM生成SQL。这比让LLM从几百张表里直接猜靠谱得多。

这几层叠加下来的效果，明显比裸用一个LLM好。而且是一个正循环，用得越多，标注越完善，训练集越大，效果越好。

实际部署架构

落地部署时的典型架构是这样：

用户浏览器 ↓ Nginx（HTTPS，反向代理） ↓ FastAPI（Gunicorn + Uvicorn Worker） ↓ ├── PostgreSQL（系统配置、用户、Bot配置） ├── Redis（缓存 + ARQ任务队列 + Redis Streams事件总线） ├── Qdrant（向量索引，元数据语义搜索） └── 目标数据库（MySQL/Oracle/ClickHouse/...）

后端异步任务用ARQ + Redis Streams。ARQ把耗时任务（比如SQL生成、数据查询）从API进程里移出来，放在独立的Worker进程跑。Redis Streams做事件总线，支持SSE流式推送和断点续跑。

具体来说，Agent执行SQL查询时，中间结果通过Redis Streams写入。前端通过SSE连接读取流，实时展示进度。如果SSE连接断了，前端带上Last-Event-ID重连，Redis Stream里的事件会自动回放，不需要重跑。

多实例部署时，任何一台API实例都可以服务SSE请求，因为事件数据在Redis里，不在进程内存里。这使得水平扩展变得简单。