用自然语言做数据分析，到底能走到哪一步？

不是写几个SQL的事，而是一整个分析工作流能不能交给AI

---

问题不是写不出SQL

会写SQL的人，其实也不太想写SQL。

这不是矫情。当你需要对一份数据做探索性分析的时候，通常的流程是这样的，先想一个问题，然后写SQL，跑出来看看，发现维度不对，改一下group by，再跑，发现要关联另一张表，再改，然后觉得这个结果应该画个图，于是导出数据拖进Excel或者BI工具。

一个本来五分钟的思考过程，手上可能要折腾半小时。

更麻烦的是复杂的多步骤分析。比如，先查上季度的销售数据，然后跟去年同期做对比，再按城市和品类拆解，最后用Python跑一下相关性分析。这种活交给SQL，得写好几段，中间结果还得临时存着。

所以这两年Text-to-SQL特别火，逻辑很直接，你说人话，它给你转成SQL，省事了。

但实际跑下来会发现一个问题，大多数Text-to-SQL工具停在"生成一条SQL"这一步。而真实的数据分析从来不是一条SQL能搞定的事。

那如果一个AI数据分析助手，不止能写SQL呢？

---

让AI自己探索数据

先说最基础的对话能力。

你问一句"上个月华东地区销售额最高的前三个品类是什么"，它生成SQL，执行，给你答案。这个现在不少工具都能做到。

但真正的考验在下一句。

你接着问"那跟去年同期比呢"，它需要记住上一轮查了什么，知道你说的"比"是指同比，然后自己去找去年同期对应的数据。再问一句"按城市拆一下看看分布"，它得在上一个结果的基础上追加维度。

这听起来像正常人类分析师的工作方式。但实际上大多数AI对话工具做不到的原因是，它不知道自己"能查什么"。

关键在一步叫schema linking的东西。数据库里的表名和字段名往往是技术命名，比如 t_ord_dtl_2024，而你说的是"订单详情"。中间这层翻译，靠的是对数据源的语义理解。

AskTable 的做法是让AI Agent自主探索元数据。它不是拿用户的提问直接去撞SQL，而是先用工具去看，当前项目里有哪些表、每个表的结构是什么、字段之间的关联关系是什么。有点像你接手一个陌生数据库时，先 SHOW TABLES、DESCRIBE 一圈，摸清了再动手。

不同的是，这个过程是全自动的，而且多轮对话中持续可见。

---

画布：把分析流程拼起来

如果说对话是"一问一答"的交互方式，那有些分析场景需要的是把多个步骤编排在一起，这就是画布（Canvas）要解决的问题。

画布的底层思路很直白，把一个数据分析任务拆成若干个节点，节点之间连起来就是数据流向。

节点类型有几种：

• Data节点：自然语言描述你想查什么，它生成SQL跑数据
• Chart节点：基于上游结果自动生成可视化图表
• Python节点：写Python代码做数据处理或统计分析
• Web Search节点：AI联网搜索，补充外部信息
• Excel节点：导入外部Excel文件作为数据源

举个例子。你想分析最近用户增长的情况，可以这样搭：

第一个Data节点，拉近30天每日新增用户数。第二个Data节点，拉去年同期数据做对比。一个Chart节点把两条线画在一张图上。再接一个Python节点，跑一下新增用户的留存曲线。最后再加个Web Search节点，让AI帮你搜一下这段时间行业内有没有什么大事件可以解释数据波动。

节点之间的依赖关系会自动解析成DAG（有向无环图），按序执行。上游刷新了，下游跟着自动更新。

---

Autopilot：让AI自己操作画布

画布已经能解决大部分问题，但还有一个更激进的尝试。

叫Autopilot。简单来说，你用自然语言告诉AI"帮我分析一下最近的用户增长"，AI会自己创建节点、配置查询、连接节点、跑数据、出图表。

你看着它一步步把画布搭出来，中间可以随时打断、修改、调整。

这个功能的实现方式是在画布之上加了一层规划Agent。它理解你的意图后，把任务拆解成具体的节点操作，然后逐一执行。每次操作的结果实时同步到画布上，你能看到整个过程。

说实在的，这个功能我一开始用的时候觉得"有点东西"。因为你能看到AI的思考链路，它选择了哪些表，怎么关联的，出了什么结果，中间结果都是透明的。不是说它给你一个黑盒输出，你只能信或者不信。

---

实时协作：不只是一个玩具

上面说的很多功能，如果只是自己一个人用，那跟一个做得比较好的Jupyter Notebook差别不算巨大。

但Canvas加了一个东西，让它从"个人工具"变成了"团队协作工具"。

实时协作。基于Replicache的CRDT同步方案，多人同时在一个画布上操作，数据、节点、连线都能实时看到对方的修改。

这个技术选型本身有点意思。Replicache走的是offline-first路线，本地先做操作（乐观更新），然后通过SSE poke通知触发增量pull。好处是延迟感知极低，断网也能继续操作，网络恢复后自动同步。

实现上比较核心的是一个 useNodesStateSynced hook，它是Replicache KV store和ReactFlow之间的唯一同步层。diff引擎会保留用户的选择状态，不会因为远端更新就把你当前选中的节点切掉。

这意味着一个场景，你跟同事开会对数据，一个人改查询条件，另一个人在旁边看结果实时变化。不需要"你先改完发我再打开"。

---

图表生成：为什么不用LLM直接画

说到图表生成，有个技术选型上值得聊的点。

最早一批AI图表工具的做法是让LLM输出前端代码（比如ECharts的option配置或者JSX），然后用 eval 渲染。这种方式的问题在于，LLM输出的代码不可控，格式稍有偏差就崩，而且很难做类型检查和测试。

AskTable走了一条更稳的路，自己做了一套叫ChartSpec的声明式图表规范。

逻辑是这样的：

LLM只需要输出结构化的JSON，描述图表类型、数据映射、坐标轴、颜色这些。然后一个纯函数Resolver接收这个JSON，把它转成具体的Recharts组件配置。最后由五个专用渲染器处理输出，笛卡尔坐标系、散点图、饼图、热力图、组合图。

这套方案的好处是确定性的。JSON格式有Zod校验，Resolver是纯函数可以单测，渲染器只管展示。出了问题可以精确定位是LLM理解错了意图，还是Resolver转译有问题，还是渲染器本身有bug。

而且支持多层图表。比如帕累托图，柱状图加折线图加双Y轴，一个ChartSpec就能描述。

---

准确率怎么保证

聊到Text-to-SQL，绕不开的问题是准确率。

LLM生成SQL不是100%可靠的。特别是在复杂的业务场景下，字段命名不规范、表关系复杂、业务逻辑模糊的时候，生成一条错误的SQL比生成一条正确的SQL容易得多。

除了模型本身的能力，还有几个层面的工程手段可以提升准确率。

术语库（Glossary）。让业务人员自己定义业务术语和映射关系。比如你们公司内部说的"有效订单"对应的是哪些状态组合，直接录进术语库，Agent生成SQL时会用到这些知识。

训练集。把历史上"问得好的问题"和对应的正确SQL收集起来，形成问答对。后续生成时可以做few-shot提示，让模型参考已有的高质量样例。训练集可以手动录入，也可以从历史对话中自动积累。

SDI脱敏系统。自动识别敏感字段，姓名、邮箱、手机号、身份证号这些。生成SQL时可以做列级权限控制，敏感字段自动脱敏或者过滤。

这套组合拳打下来，准确率会比裸用一个LLM高不少。更重要的是，它是一个可以持续积累的系统。用得越多，术语库越丰富，训练集越大，效果越好。

---

部署：数据能不能留在自己手里

最后说一个实际落地时最常被问的问题。

上面的功能再好，如果数据不能留在自己手里，对很多团队来说就没法用。

AskTable提供了两种部署模式。

Cloud SaaS模式，注册就能用，数据存在云端。适合个人或者对数据隐私要求不高的场景。

私有化部署模式，Docker一键拉起，PostgreSQL、Redis、Qdrant、FastAPI全部跑在自己服务器上。连的也是自己的数据库，数据不需要迁移。

私有化部署的架构是Docker All-in-One，一个容器里跑齐所有组件。后端用ARQ Worker处理异步任务，Redis Streams做事件总线，支持断点续跑。SSE连接断了你带上 Last-Event-ID 重连，之前的执行结果都能回放。

模型配置也是灵活的。可以接Claude、GPT，也可以配置本地LLM。模型组在数据库里管理，运行时可以随时切换。

---

回到最开始的问题

“用自然语言做数据分析，到底能走到哪一步？”

答案大概是，已经远远不止是"帮你写条SQL"了。

从对话式查询到多步骤画布编排，从Autopilot自动驾驶到实时协作，从图表自动生成到Python数据处理。整个流程中AI能做的环节越来越多，而且关键的是，每一步都是透明的，你能看到AI做了什么、为什么这么做、结果对不对。

当然，它不完美。复杂的业务逻辑还是需要人去理解，AI目前更适合做探索性的、中低复杂度的分析。但方向已经很清晰了。

数据分析的门槛在持续降低。不是说"人人都要学SQL"了，而是人人都可以直接跟数据对话。

---

文中提到的工具是 AskTable，一个AI驱动的自然语言数据分析平台，支持20+数据库类型，提供Cloud SaaS和私有化部署两种模式。