聊《做过数据分析的人学大模型哪些经验可以直接迁移》之前先说一句实在的别急着背概念先看它在真实项目里到底解决什么问题。摘要很多做数据分析的同学转大模型第一个项目往往是智能分析 Agent——用自然语言查数据、出报表。Demo 跑通很容易但交给团队用就出问题。这篇文章不聊 Prompt 怎么写聊一个更实际的门槛权限控制、操作日志、可观测性。这些不是锦上添花而是 Demo 变产品的分水岭。目录数据分析的新机会自然语言 BI 为什么容易做却难用好指标解释 Agent不只是翻译 SQL数据工具调用从单点到工作流项目案例从 Demo 到可维护项目总结---数据分析的新机会我在带团队做 AI 数据产品时见过一个现象数据分析背景的同学转大模型开发反而比纯后端快。原因很实际。数据分析的人懂指标、懂数据口径、懂业务逻辑这些在写 Prompt 和定义 Agent 行为时比写代码本身更重要。但问题也在这里。很多做数据分析的同学习惯的是出结果。报表跑通、数据准确任务就结束了。但 Agent 不一样它要面对的是真实用户、真实权限、真实数据泄露风险。我见过一个案例一个分析师用 LangChain 写了个智能分析 Agent本地跑通能回答上月销售额为什么下降团队很兴奋。结果上线第一天有用户通过对话拿到了公司级敏感指标权限没控制日志没记录事后追查不到是谁问的、问了什么。这不是技术能力问题是工程化思维缺失。自然语言 BI 为什么容易做却难用好自然语言转 SQL现在随便一个模型都能做。Demo 阶段你输入上个月华东区的销售额Agent 生成 SQL查库返回结果看起来很完美。但真实环境里你会遇到这些问题权限问题不同部门的人问同样的问题应该看到不同的数据。销售只能看自己区域财务可以看全公司高管可以看明细。这个权限控制不是在 Prompt 里加一句只返回用户有权限的数据就能解决的需要在 SQL 生成阶段就注入用户权限过滤条件。口径问题销售额是含税还是不含税是下单时间还是发货时间分析师知道但模型不知道。你需要把口径定义成可查询的知识库而不是每次让模型自己猜。结果验证模型生成的 SQL 能不能跑有没有语法错误返回结果是否合理这些都需要在 Agent 流程里加校验环节。我最近在做的一个项目就是在自然语言 BI 上加了权限注入层。核心思路是在 SQL 生成之前先把用户身份对应的数据权限条件拼进 WHERE 子句而不是让模型自己去判断。# 权限注入示例在 SQL 生成前注入数据权限条件 def inject_permissions(user_id, base_query): # 从权限服务获取用户可见的数据范围 allowed_regions get_user_regions(user_id) allowed_departments get_user_departments(user_id) # 注入权限条件 if allowed_regions: base_query f AND region IN ({format_values(allowed_regions)}) if allowed_departments: base_query f AND department IN ({format_values(allowed_departments)}) return base_query这个改动看起来简单但它是 Demo 和产品的关键区别。指标解释 Agent不只是翻译 SQL数据分析转大模型一个很自然的延伸是做指标解释 Agent——用户问为什么销售额下降Agent 不仅返回数据还能解释原因。这个场景比单纯的自然语言 BI 更复杂因为涉及多步推理。我见过一个实现方案第一步Agent 生成 SQL 拿到数据第二步对比历史数据找出异常点第三步关联维度分析定位下钻方向第四步生成自然语言解释。问题出在第三步和第四步。关联维度分析需要模型自己决定查哪些维度这个过程不可控。模型可能查了无关维度浪费调用次数也可能漏掉关键维度给出错误结论。自然语言解释需要模型编故事但编得对不对没人能实时验证。我的解决方案是把可解释的部分固化把不可控的部分暴露出来让用户确认。具体来说维度分析用预定义的规则引擎而不是让模型自由发挥。规则引擎根据业务逻辑决定在什么情况下应该下钻到哪个维度。模型只负责生成解释文本不负责决定分析路径。同时所有生成的解释都会记录操作日志包括用户问了什么、模型做了什么分析、最终给出的结论是什么。这样事后可以追溯也可以用来优化模型。数据工具调用从单点到工作流数据分析的人做 Agent最容易犯的错误是把所有工具调用写在一起。比如一个销售分析 Agent用户问一个问题Agent 要查数据、做对比、生成图表、写解释。这四个步骤如果写成一个函数代码会很长而且一旦某个环节出错整个流程就崩了。更好的做法是把每个工具调用拆成独立步骤用工作流管理。我最近在用的方案是 LangGraph它允许你把 Agent 流程定义成有向图每个节点是一个工具调用边是流转逻辑。这样做的好处是每个节点可观测你可以看到每一步花了多少时间、调用了什么模型、返回了什么结果。每个节点可重试如果某个工具调用失败可以单独重试不影响其他步骤。每个节点可替换如果某个步骤的模型效果不好可以单独替换不需要重写整个流程。from langgraph.graph import StateGraph, END # 定义状态 class AnalysisState(TypedDict): question: str sql: str data: pd.DataFrame insight: str chart_url: str # 定义节点 def generate_sql(state: AnalysisState) - AnalysisState: # 调用模型生成 SQL state[sql] llm.generate_sql(state[question]) return state def execute_query(state: AnalysisState) - AnalysisState: # 执行 SQL注入权限条件 state[data] db.execute(inject_permissions(state[sql])) return state def generate_insight(state: AnalysisState) - AnalysisState: # 基于数据生成洞察 state[insight] llm.generate_insight(state[data]) return state # 构建工作流 workflow StateGraph(AnalysisState) workflow.add_node(generate_sql, generate_sql) workflow.add_node(execute_query, execute_query) workflow.add_node(generate_insight, generate_insight) workflow.add_edge(generate_sql, execute_query) workflow.add_edge(execute_query, generate_insight) workflow.add_edge(generate_insight, END) app workflow.compile()这个结构看起来比单函数复杂但它给你的是可维护性。权限控制、日志记录、错误处理都可以加在对应的节点里而不是整个流程里打补丁。项目案例从 Demo 到可维护项目去年我带团队做了一个智能分析 Agent最初版本就是一个 Demo用户问问题Agent 生成 SQL查库返回结果。内部测试没问题就准备上线。上线前做了一次代码审查发现了三个问题第一没有权限控制。所有用户都能查到所有数据包括敏感指标。这个问题如果不在上线前解决风险很大。第二没有操作日志。用户问了什么、模型返回了什么、数据从哪张表查的全部没有记录。出了问题没法追查。第三没有结果校验。模型生成的 SQL 没有经过验证就直接执行有注入风险也有性能风险。我们花了两周时间做了以下改造权限控制方面我们在 SQL 生成前注入用户权限条件并在数据返回后二次校验确保没有越权数据泄露。操作日志方面我们在每个节点加了日志记录包括输入、输出、耗时、模型调用次数。日志集中存储支持按用户、按时间、按问题类型查询。结果校验方面我们加了一个 SQL 解析器在生成 SQL 后检查是否有危险操作如 DROP、DELETE以及查询复杂度是否超出阈值。改造后的 Agent上线后运行了三个月处理了上万次查询没有出现权限泄露或数据错误。团队反馈是可观测性提升后排查问题从几小时缩短到几分钟。这个案例的核心结论是Demo 和产品的差距不在模型能力在工程化细节。总结数据分析转大模型优势在业务理解短板在工程化思维。很多分析师做 Agent习惯的是出结果但 Agent 面对的是真实用户和真实风险权限、日志、可观测性不是可选项是必选项。我的建议是先做一个能跑通的 Demo验证你的场景是否可行。然后停下来不要急着加功能先把权限控制、操作日志、结果校验这三件事做好。这三件事做好了你的 Agent 才是一个可以交给团队用的产品而不只是一个演示。技术能力决定你能走多快工程化能力决定你能走多远。数据分析转大模型这是一次机会也是一次升级。资料展示下面是我整理的AI大模型学习资料和工具包预览适合收藏后按主题逐步学习。如果你想看完整资料目录可以在评论区留言「资料」也欢迎告诉我你更关注AI大模型里的哪类内容。