能跑Demo就能上线？数据分析转大模型的权限与日志课

关注

原创最新推荐文章于 2026-08-22 03:25:39 发布 192 阅读 AI 写同款· GEO 优化 ›

详解STM32F407双重ADC同步采集与DMA传输的配置技巧及实战应用本文详细解析了STM32F407双重ADC同步采集与DMA传输的配置技巧及实战应用。通过CubeMX配置、代码实现和常见问题解决方案，帮助开发者高效实现多通道数据同步采集，提升工业自动化和嵌入式系统的数据采集效率与精度。阅读详情

聊《做过数据分析的人学大模型，哪些经验可以直接迁移？》之前，先说一句实在的：别急着背概念，先看它在真实项目里到底解决什么问题。

摘要

很多做数据分析的同学转大模型，第一个项目往往是智能分析 Agent——用自然语言查数据、出报表。Demo 跑通很容易，但交给团队用就出问题。这篇文章不聊 Prompt 怎么写，聊一个更实际的门槛：权限控制、操作日志、可观测性。这些不是"锦上添花"，而是 Demo 变产品的分水岭。

数据分析的新机会

文章插图 1

我在带团队做 AI 数据产品时，见过一个现象：数据分析背景的同学，转大模型开发反而比纯后端快。

原因很实际。数据分析的人懂指标、懂数据口径、懂业务逻辑，这些在写 Prompt 和定义 Agent 行为时，比写代码本身更重要。

但问题也在这里。

很多做数据分析的同学，习惯的是"出结果"。报表跑通、数据准确，任务就结束了。但 Agent 不一样，它要面对的是真实用户、真实权限、真实数据泄露风险。

我见过一个案例：一个分析师用 LangChain 写了个智能分析 Agent，本地跑通，能回答"上月销售额为什么下降"，团队很兴奋。结果上线第一天，有用户通过对话拿到了公司级敏感指标，权限没控制，日志没记录，事后追查不到是谁问的、问了什么。

这不是技术能力问题，是工程化思维缺失。

自然语言 BI 为什么容易做，却难用好

文章插图 2

自然语言转 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()

这个结构看起来比单函数复杂，但它给你的是可维护性。权限控制、日志记录、错误处理，都可以加在对应的节点里，而不是整个流程里打补丁。