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

这篇我按“先跑起来、再讲取舍”的方式写《大模型岗位变了数据分析工程师该补的还是算法吗》。概念会讲但重点放在代码怎么组织、哪里容易踩坑。摘要先把这篇文章的目标说清楚看完之后你应该能判断这件事值不值得做以及从哪里动手。摘要很多数据分析师转做大模型应用时容易陷入“Prompt 调优”的误区。本文基于近期企业级 Agent 落地经验指出从 BI 报表转向智能分析 Agent 的核心难点并非模型智商而是工程化的“脏活”——权限隔离、操作日志与可观测性。通过拆解一个自然语言查数项目的实战路径给出从 Demo 到生产的具体技术栈选型与避坑指南。---目录1. 数据分析的新机会从“解释过去”到“执行未来”2. 自然语言 BI别迷信零代码3. 指标解释 Agent让数据“开口说话”4. 数据工具调用权限是生死线5. 项目案例从 Demo 到生产的心路历程6. 总结补什么课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 statuspending 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 的爽感去看看那些在生产环境中日夜运行的日志吧那里藏着真正的答案。总结本文完成了关键概念、工程实践和落地建议的梳理。资料展示下面是我整理的AI大模型学习资料和工具包预览适合收藏后按主题逐步学习。如果你想看完整资料目录可以在评论区留言「资料」也欢迎告诉我你更关注AI大模型里的哪类内容。