报表转 Agent 很香，但权限日志没兜底，上线就是灾难

原创于 2026-08-08 14:01:48 发布 · 103 阅读

3 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

聊《数据分析转大模型，真正值钱的为什么不是会调 API？》之前，先说一句实在的：别急着背概念，先看它在真实项目里到底解决什么问题。

摘要

很多人问我，做传统数据分析的，现在转大模型是不是降维打击？

我看过不少简历，SQL 写得溜，Tableau、PowerBI 玩得熟，转型期一上来就狂练 LangChain、RAG，最后做出来的 Demo 在本地跑得飞起，一交生产环境，第二天就被运维投诉炸了。

问题出在哪？出在大家太迷恋“智能”，却忽略了“工程”。

大模型应用从 Demo 走向生产，真正的分水岭不是模型有多聪明，而是权限控制、日志追踪和可观测性。今天不聊怎么调 API，聊聊作为数据分析师，想真正上手大模型 Agent，哪些课必须补，哪些可以先放放。

数据分析的新机会，别只盯着“提效”

文章插图 1

传统数据分析的价值，过去主要在于“描述”和“诊断”：发生了什么，为什么发生。

大模型带来的变化，是把“执行”也接进来了。你不再只是给业务方看一张图表，而是直接给出一个可执行的结论，甚至直接触发下游动作。

但这里有个巨大的陷阱。

很多同行觉得，学会了 Prompt 工程，能写几个 Chain，就能做智能分析。其实这只是第一步。在真实项目里，模型能生成代码，能查数据库，但如果它查错了表，或者把敏感数据暴露给了不该看的人，这个 Agent 就是“定时炸弹”。

我见过一个案例，一个销售分析 Agent，能自动查 CRM 数据并生成周报。Demo 阶段很棒，老板很兴奋。结果上线第一周，它把某条竞对的高敏感报价数据，通过邮件摘要的形式发给了全公司。

这不是模型笨，这是权限体系没建好。

所以，转型的第一步，心态要变：从“让模型更聪明”变成“让模型更安全、更可追溯”。

自然语言 BI：别让模型“自由发挥”

文章插图 2

自然语言查数据（Text-to-SQL）是数据分析转大模型最自然的切入点。

但这里有个取舍问题。

你是希望模型完全自由地生成 SQL，还是希望它在一个受控的范围内生成？

在 Demo 里，你可以直接让模型连数据库，因为它不知道风险。但在生产环境，你必须做一层“网关”。

我的建议是，先别急着搞复杂的 RAG，先把“查询边界”钉死。

比如，你可以限制模型只能查询经过脱敏的数据视图，而不是直接查原始表。你可以限制查询时间范围，比如只能查最近 30 天的数据。你可以限制返回行数，比如最多返回 100 条。

这些规则，不应该写在 Prompt 里，因为 Prompt 是不稳定的。它们应该写在代码层。


# 伪代码示例：在生成 SQL 后的安全检查层
def validate_sql(sql: str, user_context: UserContext) -> bool:
    # 1. 检查是否包含敏感字段
    if any(field in sql for field in SENSITIVE_FIELDS):
        raise SecurityError("Attempted to access sensitive data")

    # 2. 强制追加时间过滤条件
    if "WHERE" not in sql.upper():
        sql += f" WHERE create_time > '{user_context.date_range.start}'"

    # 3. 限制最大行数
    if "LIMIT" not in sql.upper():
        sql += f" LIMIT {MAX_ROWS}"

    return sql

你看，真正的工程价值，不是让模型生成更复杂的 SQL，而是确保它生成的 SQL 在安全边界内。

CSDN资料领取方式