大模型岗位变了，数据分析工程师该补的还是算法吗？

发布时间：2026/7/19 20:06:41

这篇我按“先跑起来、再讲取舍”的方式写《大模型岗位变了，数据分析工程师该补的还是算法吗？》。概念会讲，但重点放在代码怎么组织、哪里容易踩坑。

摘要

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

摘要：很多数据分析师转做大模型应用时，容易陷入“Prompt 调优”的误区。本文基于近期企业级 Agent 落地经验，指出从 BI 报表转向智能分析 Agent 的核心难点并非模型智商，而是工程化的“脏活”——权限隔离、操作日志与可观测性。通过拆解一个自然语言查数项目的实战路径，给出从 Demo 到生产的具体技术栈选型与避坑指南。

---

1. 数据分析的新机会：从“解释过去”到“执行未来”

作为一名在数据领域摸爬滚打多年的分析师，我最近半年几乎把所有精力都投在了“自然语言转 SQL/代码”以及后续的 Agent 执行上。

很多人问我：“我都精通 SQL 和 Python 了，转大模型是不是只要学个 LangChain 或者 LlamaIndex 就行？”

我的回答通常很直接：如果你只想着怎么用 Prompt 让模型写出正确的查询，那你还在做报表；如果你想让模型真正介入业务系统去“干活”，那你得先学会怎么管住它的权限。

传统 BI（如 Tableau、PowerBI）解决的是“可视化的过去”，而智能分析 Agent 的目标是“自动化的现在”甚至“预测性的未来”。但这种转变带来了一个巨大的断层：以前的分析师对数据负责，现在的 Agent 对动作负责。一个错误的DELETE或UPDATE语句，比一个错误的图表要致命得多。

这也是为什么我在招聘 JD 里看到越来越多的要求：不仅要有模型调优能力，更要有后端工程化思维。

2. 自然语言 BI：别迷信零代码

在初期探索阶段，我们尝试过直接把 LLM 对接到数据库。结果很惨淡：模型偶尔会写出语法正确的 SQL，但在复杂的多表 Join 中容易迷失，更可怕的是，它可能会生成带有副作用的语句。

我们很快调整了策略，引入了两层架构：

1. 语义层（Semantic Layer）：不直接暴露表结构，而是暴露“指标”和“维度”。比如，不暴露orders表，而是暴露“GMV”、“客单价”等概念。这极大地降低了模型的幻觉空间。
2. 沙箱执行环境：所有生成的 SQL 或 Python 代码，必须在受限环境中预演。

这里有个具体的坑：很多人以为加了 RAG 就能解决所有问题。其实，对于结构化数据，Schema Linking（模式链接）比传统的文档 RAG 更有效。你需要告诉模型，哪个字段对应哪个业务含义，而不是让它去猜一堆文本描述。

3. 指标解释 Agent：让数据“开口说话”

单纯的 SQL 生成只是第一步，真正的价值在于对结果的解释。

我们构建了一个简单的 Agent 流程：
用户提问->意图识别->SQL 生成->数据执行->结果总结

在这个链条中，“结果总结”环节最容易翻车。如果直接让 LLM 基于冷冰冰的数字生成一段话，往往会出现“正确的废话”。

我们的做法是引入Few-Shot（少样本学习），针对不同类型的图表和异常值，预设几种专家级的解读模板。例如，当 GMV 环比下降超过 5% 时，Agent 不会只说“下降了”，而是会尝试关联同期促销活动或竞品动态（如果数据源支持）。

关键点：不要试图让一个通用的 LLM 成为全能的商业分析师。限定它的解释边界，反而能提高可信度。

4. 数据工具调用：权限是生死线

这是本文最想强调的部分，也是区分“玩具 Demo”和“生产系统”的分水岭。

在之前的项目中，我曾见过一个 Demo：用户问“帮我删除上周的测试订单”，Agent 真的生成了DELETE FROM orders WHERE date < ...并执行了。虽然测试库数据丢了可以恢复，但在生产环境中，这就是 P0 级事故。

因此，我们在 Agent 架构中强制加入了权限中间件。

实战代码示例：基于角色的查询拦截器

我们使用 Python 编写了一个简单的中间件，在 SQL 生成后、执行前进行校验。这不仅是为了安全，更是为了建立信任。

import sqlparse from sqlparse.sql import IdentifierList, Identifier from sqlparse.tokens import Keyword, DML class SecurityMiddleware: def __init__(self): # 定义允许的操作类型，严格限制为只读 self.allowed_operations = {'SELECT'} def check_sql(self, sql: str, user_role: str) -> dict: """ 检查 SQL 语句的安全性和权限 """ parsed = sqlparse.parse(sql)[0] # 1. 检查是否为 SELECT 语句 if parsed.get_type() != 'SELECT': return {"safe": False, "error": "只允许查询操作"} # 2. 检查是否涉及敏感表或字段 sensitive_tables = ['passwords', 'credit_cards', 'internal_employees'] tokens = list(parsed.flatten()) for token in tokens: if token.ttype is Keyword and token.value.lower() in [t.lower() for t in sensitive_tables]: return {"safe": False, "error": "无权访问敏感数据表"} # 3. 添加自动的限制条件（防止全表扫描） # 简单起见，这里假设所有表都有 tenant_id 字段 if "WHERE" not in sql.upper(): # 实际生产中建议使用 AST 解析后插入 WHERE 条件，而非字符串拼接 pass return {"safe": True, "message": "权限校验通过"} # 使用示例 middleware = SecurityMiddleware() sql_query = "SELECT count(*) FROM orders WHERE status='pending'" result = middleware.check_sql(sql_query, "analyst") print(result) # Output: {'safe': True, 'message': '权限校验通过'}

这段代码虽然简单，但它揭示了工程化的本质：永远不要相信模型的原生输出。你必须通过代码层面对其行为进行约束。

5. 项目案例：从 Demo 到生产的心路历程

去年我们主导了一个内部“智能运营助手”项目。

初期阶段：团队花了两周时间用 LangChain 搭出了一个能查日报的系统。演示效果惊艳，老板很满意。
中期阶段：接入真实数据后，发现模型经常“幻觉”出根本不存在的指标，且响应速度慢得让人无法接受。
后期阶段（重构）：
1. 移除端到端的 LLM 直接调用，改为 LLM 生成 JSON 结构的查询指令，再由后端强类型代码执行。
2. 增加全链路日志：记录每一次用户的提问、模型的思考过程（Chain of Thought）、生成的 SQL、执行的耗时以及最终结果。
3. 建立反馈闭环：允许用户对结果点赞/踩，这些数据被用来微调后续的 Prompt 模板。

最终效果：虽然开发周期延长了 50%，但系统的可用性提升了 300%。用户不再担心“乱删数据”，因为所有的操作都有迹可循，且有严格的权限控制。

6. 总结：补什么课？

回到最初的问题：数据分析工程师转大模型，该补算法吗？

不需要。你不需要去推导 Transformer 的内部原理，也不需要去训练一个基座模型。

你需要补的是工程化思维：
1. 可观测性：当 Agent 出错时，你能通过日志迅速定位是 Prompt 问题、数据问题还是模型幻觉吗？
2. 权限与安全：你能设计出怎样的护栏，防止 Agent 做出破坏性操作？
3. 成本控制：你懂得如何压缩 Context Window，如何在缓存和实时推理之间做权衡吗？

大模型应用的深水区，不在模型本身，而在那些不起眼的“脏活”里。对于习惯了与确定性数据打交道的分析师来说，拥抱这种不确定性背后的确定性工程规范，才是转型成功的关键。

别只盯着 Demo 的爽感，去看看那些在生产环境中日夜运行的日志吧，那里藏着真正的答案。