数据分析转大模型：从上线前检查开始讲

关注

原创最新推荐文章于 2026-09-02 14:19:02 发布 140 阅读 AI 写同款· GEO 优化 ›

RL调参侠之BipedalWalker BipedalWalkerHardcore SAC 前几天用PPO训练了个很一般的agent： RL调参侠之BipedalWalker PPO 我看SpinningUp上面说PPO和SAC是两个领域里各自的State_of_the_art的方法，所以就打算跑SAC试试看，之前因为Open AI Five的原因，一直感觉PPO很牛掰，实际上现在很多自动驾驶的算法也是用PPO在跑，毕竟有一个“必定能够提升期望”的理论保证在这里，我理解这对做项目很大的诱惑。不过我跑出来的结果明显是SAC更好。调参侠时间策略熵的权重alpha用的0.2，我一开始没有看SAC的阅读详情

聊《我用数据分析经验做了次 AI 项目，最先失效的是旧方法》之前，先说一句实在的：别急着背概念，先看它在真实项目里到底解决什么问题。

摘要

很多数据分析师转型做Agent时，以为学会调API、写Prompt就万事大吉。我踩过的坑告诉我：Demo跑通只是第一步，真正让项目从"能演示"变成"能上线"的，是权限控制和可观测性。这篇文章用一次智能分析Agent的实战经历，拆解从报表思维到Agent思维的转变过程，以及那些在Demo阶段被忽略、上线后却致命的问题。

数据分析的新机会

文章插图 1

做数据分析的这几年，我见过太多人转型焦虑。报表做得再好，也只是"人找数据"；大模型来了，变成了"数据找人"。这个转变看似简单，但真正做起来才发现，技术栈的迁移只是表层，思维方式的转变才是核心。

我的转型路径是从SQL报表开发，到自然语言查询，再到现在的智能分析Agent。中间踩过不少坑，但回头看，最大的收获不是学会了什么新工具，而是理解了"什么才是真正的工程化"。

很多人问我：数据分析转大模型，最难的是什么？我的答案是：不是模型调用，不是Prompt工程，而是从"单点任务"到"系统思维"的转变。报表开发是确定性的，输入固定，输出固定；Agent是概率性的，输入固定，输出不固定。这种不确定性，要求开发者具备完全不同的思维方式。

自然语言BI：从报表到对话

文章插图 2

自然语言BI（NL2SQL）是很多人转型的第一步。技术上不难，调个API，拼个Prompt，跑通一个Demo。但真正用起来，问题就来了。

我做过一个项目，把传统的销售报表升级成自然语言查询。Demo阶段，测试数据非常干净，模型回答准确率很高。但上线后，业务人员问的问题千奇百怪，模型经常"幻觉"出错误的SQL。

这里有个关键认知：NL2SQL不是简单的"翻译"，而是"理解+执行"。模型需要理解业务语境，生成正确的SQL，还要处理边界情况。我的经验是，Demo阶段要用真实数据测试，而不是清洗过的测试数据。


# 一个简单的NL2SQL示例
def generate_sql(question: str, schema: dict) -> str:
    prompt = f"""
    根据以下数据库schema，将自然语言问题转换为SQL：

    问题：{question}

    Schema：
    {json.dumps(schema, ensure_ascii=False, indent=2)}

    只返回SQL，不要解释。
    """
    response = call_llm(prompt)
    return extract_sql(response)

这个Demo能跑，但上线会崩。为什么？因为缺少权限控制和日志追踪。

优快云资料领取方式

指标解释Agent：不只是查数据

智能分析Agent的核心价值，不只是查数据，而是解释数据。从"销售额是多少"到"为什么销售额下降了"，这个转变需要模型具备推理能力。

我做的指标解释Agent，流程是这样的：
1. 用户提出问题
2. Agent理解问题，确定需要的指标
3. 调用数据工具获取数据
4. 分析数据，生成解释
5. 返回结果

Demo阶段，这个流程很顺畅。但上线后，问题出现了：

用户问"为什么销售额下降"，Agent返回了错误的数据
模型生成的解释逻辑不通
没有记录用户的问题和Agent的回答

这些问题，单靠优化Prompt解决不了。需要的是系统性的工程化方案。

数据工具调用：SQL是基础，权限是底线

数据分析师做Agent，天然优势是懂SQL、懂业务。但很多人忽略了一个问题：Agent调用数据工具时，权限怎么控制？

我见过一个项目，Agent可以直接执行任意SQL。结果有一次，模型生成了一个DROP TABLE的语句，虽然被数据库拦截了，但风险极大。

权限控制不是可选的，是必须的。我的做法是：
1. 定义白名单SQL模板，只允许SELECT
2. 限制查询时间范围，避免全表扫描
3. 记录所有SQL执行日志，便于审计


# 带权限控制的数据工具调用
class SecureSQLExecutor:
    def __init__(self, allowed_tables: list, max_rows: int = 1000):
        self.allowed_tables = allowed_tables
        self.max_rows = max_rows

    def execute(self, sql: str, user: str) -> dict:
        # 1. 解析SQL，检查表名是否在白名单
        table_names = self._extract_tables(sql)
        if not self._is_allowed(table_names):
            raise PermissionError(f"无权访问表: {table_names}")

        # 2. 限制查询行数
        if "LIMIT" not in sql.upper():
            sql += f" LIMIT {self.max_rows}"

        # 3. 执行并记录日志
        result = self._run_sql(sql)
        self._log_execution(user, sql, result)

        return result

    def _log_execution(self, user: str, sql: str, result: dict):
        # 记录到日志系统，便于追溯
        log_entry = {
            "user": user,
            "sql": sql,
            "rows": result.get("row_count", 0),
            "timestamp": datetime.now().isoformat()
        }
        logger.info(json.dumps(log_entry, ensure_ascii=False))

这个代码片段展示了基本的权限控制和日志记录。看起来简单，但很多Demo项目根本不做这些。