数据分析转大模型：把落地步骤拆成清单

Agent智能体

361人浏览 · 2026-07-10 00:09:30

Agent智能体 · 2026-07-10 00:09:30 发布

聊《数据分析转大模型：一次新的项目切入》之前，先说一句实在的：别急着背概念，先看它在真实项目里到底解决什么问题。

摘要

先把这篇文章的目标说清楚：看完之后，你应该能判断这件事值不值得做，以及从哪里动手。

最近圈子里有个挺明显的趋势：大家不再满足于让 LLM 跑个 Demo 或者做个简单的 QA 问答了。真正的痛点转移到了权限控制、操作日志和可观测性上。对于做了几年报表、SQL 写得飞起的数据分析师来说，这其实是个巨大的机会，也是个巨大的坑。

我前阵子帮一个朋友梳理他的简历和转型路径，他最大的误区就是觉得“我会 SQL + 我会 Python = 我能做 Agent”。错得离谱。在工业界，能调通 langchain 的例子是基础，能把 Agent 塞进生产环境且不出安全事故，才是护城河。

今天不聊虚的概念，直接从我最近做的一个“智能分析 Agent”项目复盘入手，讲讲从传统 BI 到 Agentic Data Analysis 的路上，到底该先补什么，暂时放什么。

数据分析的新机会

文章插图 1

传统的数据分析工作流是线性的：提需求 -> 写 SQL -> 跑数据 -> 画图表 -> 汇报。
现在的智能分析工作流是交互式的：提意图 -> Agent 拆解 -> 工具调用（SQL/API） -> 结果校验 -> 生成洞察。

这里的区别不在于“智能”，而在于“权限”和“边界”。

以前你跑 SQL，顶多是查多了点历史数据，或者慢了一点。现在 Agent 拿着你的自然语言指令去查库，如果权限没控好，它可能顺手把你的生产配置表也 SELECT * 了一遍。所以，转型的第一步，不是学 Prompt Engineering，而是学如何设计安全的工具调用层。

我在项目中做的第一个决策是：放弃全能的通用 Agent 设计，采用“受限工具集”策略。 我们不提供直接的数据库连接对象给 LLM，而是封装成几个只读、参数固定的 SQL 生成函数，并且加上严格的白名单限制。

自然语言 BI 的陷阱

文章插图 2

很多教程教你写一个 NL2SQL 的 Demo，输入“上个月销售额最高的产品”，输出一段 SQL。这在本地运行没问题，但一上生产就崩。

为什么？因为语义歧义。

“上个月”是指自然月还是滚动 30 天？“销售额”是指含税还是不含税？“最高”是按总金额还是平均单价？

在真实项目中，我见过最坑的案例是：分析师定义了一个“活跃用户”，业务方定义的“活跃”是登录，而数据仓库定义的“活跃”是有下单行为。Agent 如果直接根据元数据猜，出来的结果完全是两回事。

我的建议：
不要在 Prompt 里硬猜业务口径。要把这些“隐性知识”显性化。我构建了一个简单的 Schema 映射层，把业务术语和数据库字段通过 JSON 配置绑定起来。

{
  "business_term": "active_user_30d",
  "description": "过去30天内至少登录或下单一次的用户",
  "sql_fragment": "COUNT(DISTINCT user_id) FROM users WHERE last_login > NOW() - INTERVAL '30 days' OR has_order = true",
  "risk_level": "high"
}

这样 Agent 就不需要去理解复杂的 SQL 逻辑，只需要做术语匹配。这就是从“写 SQL”到“管理数据资产”的思维转变。

CSDN资料领取方式

指标解释 Agent

光查出数字没用，业务方问的是：“为什么跌了？”

这时候需要一个专门的“解释 Agent”。它不直接查库，而是负责分析上游 Agent 查出来的结果。

这里有一个重要的取舍：不要试图让一个大模型同时干两件事——既做精确的数字查询，又做复杂的因果推断。大模型在概率上擅长推断，但在精确计算上是灾难。

我的做法是将流程拆分：
1. Query Agent：负责将自然语言转为 SQL，执行查询，返回原始数据集（DataFrame）。
2. Insight Agent：接收原始数据集和业务背景，进行趋势分析和异常检测。

为了控制成本和安全，Insight Agent 只能看到聚合后的统计特征（如均值、方差、同比环比），绝对不能看到原始明细数据。这也符合数据脱敏的要求。

数据工具调用与可观测性

回到开头提到的热点：权限、日志、可观测。

在 Agent 架构中，每一个 Step 都是一个潜在的风险点。我们需要记录：

User Input：用户问了什么。
Plan：Agent 计划怎么解决（比如先查 A 表，再关联 B 表）。
Tool Calls：具体调用了哪个函数，传了什么参数。
Output：工具返回的结果摘要。

我在项目里集成了一套简单的日志链路追踪。当结果出现偏差时，我们可以回溯是哪个环节的 Prompt 出了问题，或者是哪个工具返回的数据有误。

如果没有这套可观测性，一旦 Agent 胡言乱语，你根本不知道是模型幻觉，还是 SQL 写错了。对于企业级应用，“知道为什么错了”比“偶尔猜对”重要一万倍。

项目案例：从报表到智能助手

我们重构了一个内部的销售看板。以前销售总监每天早上要看 5 张 Excel 报表，现在他可以在对话框里问：“华东区上周表现最差的三个品类是什么？主要原因是什么？”

背后的工作流：
1. 解析意图：定位到“华东区”、“上周”、“品类销量”。
2. 工具调用：查询 SalesDim 和 FactSales 表。
3. 结果校验：检查返回行数是否合理，金额总和是否与总账对齐。
4. 自然语言生成：将差异数据转化为文字报告。

在这个过程中，最关键的不是大模型有多强，而是数据清洗的中间层。我们加了一个“数据健康度检查”步骤，如果 SQL 返回的数据量超过阈值（比如一次性返回 10 万行），Agent 会主动拒绝并提示用户缩小查询范围，防止 OOM 或超时。

总结

从数据分析转到大模型应用开发，本质上是从“执行者”转变为“架构师”。

你需要考虑的不只是“怎么算出来”，更是“怎么安全地算出来”以及“怎么让人相信算得对”。

给你的转型建议：
1. 先补工程化能力：学会写单元测试，学会加日志，学会做权限控制。不要只会在 Jupyter Notebook 里跑代码。
2. 放下对模型的迷信：LLM 是概率机，数据准确性靠的是严格的 Schema 和校验规则，而不是 Prompt 的技巧。
3. 关注可观测性：在项目复盘中，能够展示你是如何监控和调试 Agent 行为的，这比展示你能写出多复杂的 Prompt 要有说服力得多。

这条路不好走，因为你要懂数据，又要懂 AI，还要懂运维。但一旦打通，你就不再是那个只会写 SQL 的工具人，而是真正的设计者。