转做智能分析Agent后,我花两个月才搞懂权限日志
这篇我按“先跑起来、再讲取舍”的方式写《数据分析转大模型实战,第一道门槛可能不是算法》。概念会讲,但重点放在代码怎么组织、哪里容易踩坑。
摘要
> 从报表开发到智能分析,我以为最大的门槛是模型能力,结果上线第一天就崩了——权限没兜住,日志没记全。
---
目录
- 数据分析的新机会
- 自然语言BI的幻觉
- 指标解释Agent的坑
- 数据工具调用的边界
- 项目案例:一个上线即崩的复盘
- 总结:权限日志比Prompt重要
---
数据分析的新机会
2024年开始,我明显感觉到业务方对"智能分析"的需求在涨。以前做报表,需求是"加个字段""换个维度",现在问的是"为什么Q3指标跌了""能不能预测下季度趋势"。这种问题,传统ETL+报表工具答不了,得靠Agent。
我的转型路径是从数据工程师切到Agent开发。说实话,技术栈变化不大——SQL、数据管道、指标体系这些底子还在,真正要补的是模型调用、工具编排、权限控制。
但很多人低估了后者。我见过不少团队,Prompt调优花了几周,模型选了一堆,上线第一周就出问题:数据越权查询、敏感指标泄露、调用链断了没人知道。这些不是模型能力问题,是工程化问题。
---
自然语言BI的幻觉
自然语言BI是数据分析转大模型最常见的切入点。用户问"上个月华东区的销售额",系统返回图表。听起来很美好,但实际做起来,坑比想象的多。
第一个坑是意图识别。用户说"帮我看看业绩","业绩"在你们公司是指营收还是利润?不同部门定义不一样。我最初的做法是让模型自己猜,结果同一个问题,不同人问出不同答案,报表还互相矛盾。后来改成了"先澄清再执行"——模型遇到模糊意图,先反问用户,确认了再查数据。
第二个坑是SQL生成准确率。GPT-4生成SQL,简单查询能到90%,但涉及多表关联、子查询、窗口函数,准确率骤降到60%以下。我当时的解法是:不直接让模型生成SQL,而是先生成查询计划(查哪些表、用什么字段、什么过滤条件),再让模型补全SQL。这样把复杂问题拆成两步,准确率能提到80%左右。
代码上大概是这样:
# 错误做法:直接让模型生成完整SQL prompt = f""" 用户问题:{user_question} 表结构:{schema} 请生成SQL查询。 """ # 正确做法:先生成查询计划,再补全SQL plan_prompt = f""" 用户问题:{user_question} 请分析需要查询的表、字段、过滤条件和聚合方式。 只输出计划,不要生成SQL。 """ plan = call_llm(plan_prompt) sql_prompt = f""" 查询计划:{plan} 表结构:{schema} 请根据计划生成SQL。 """ sql = call_llm(sql_prompt)---
指标解释Agent的坑
自然语言BI解决的是"查数据",指标解释解决的是"懂数据"。用户问"为什么销售额跌了",Agent要能给出原因分析。
我的第一个版本是:让模型直接读数据,自己分析。结果模型经常"幻觉"——明明数据没跌,它硬说跌了;明明原因是A,它编出个原因B。
后来我换了思路:不让模型自己算,让它解释我算好的结果。具体做法是:
1. 预计算好指标趋势、同比环比、下钻维度
2. 模型只负责"读"这些计算结果,做自然语言解释
3. 关键数字必须来自预计算,模型不能自己算
这样虽然架构复杂了,但准确性有保障。模型变成了"翻译器",把结构化数据翻译成自然语言,而不是"算数器"。
---
数据工具调用的边界
Agent要能调用工具,这是常识。但"能调用"和"安全地调用"是两回事。
我踩过的最大坑是权限越界。我的Agent可以调SQL、调API、还能写数据库。一开始没有限制,模型在测试环境跑得挺好。上线后,有个用户问了句"帮我导出所有用户数据",模型直接执行了全量导出,把生产库拖慢了30秒。
这个问题不是模型傻,是权限没兜住。后来我加了三层限制:
1. 查询权限:只能查自己部门的数据,不能跨部门
2. 操作权限:只读不写,除非明确授权
3. 结果权限:敏感字段脱敏,比如手机号中间四位打码
代码层面,我在工具调用前加了一个权限校验中间件:
def safe_tool_call(tool_name, params, user_id): # 权限校验 if not check_permission(user_id, tool_name, params): return {"error": "权限不足", "tool": tool_name} # 记录日志 log_call(user_id, tool_name, params) # 执行工具 result = call_tool(tool_name, params) # 结果脱敏 return sanitize_result(result, user_id)---
项目案例:一个上线即崩的复盘
去年我负责一个智能分析Agent项目,目标是让业务方能用自然语言查数据、看趋势、找原因。
Demo阶段一切顺利。模型能回答"上个月销售额多少""哪个渠道贡献最大""为什么华东区跌了"。业务方很满意,以为能直接上线。
结果上线第一天就崩了。
问题出在两个地方:
1. 权限失控:模型被问"帮我看看其他部门的业绩",它真的去查了,而且返回了详细数据
2. 日志缺失:出问题后,我们不知道是模型幻觉还是权限配置错误,排查花了半天
复盘后,我们做了三件事:
1. 权限最小化:每个Agent实例绑定固定数据权限,不能动态切换
2. 操作可追溯:每次工具调用记录用户、时间、输入、输出、耗时
3. 失败兜底:模型不确定时,返回"我无法回答"而不是瞎编
改完之后,系统稳定了。但说实话,这些工作比Prompt调优花的时间多三倍。
---
总结:权限日志比Prompt重要
从数据分析转大模型,我以为最大的门槛是模型能力、Prompt工程、Agent编排。做了两个项目后,我发现真正的门槛是权限控制和日志可观测。
模型能力决定了Agent能做什么,权限日志决定了Agent能做多久。
我的建议是:
- 别一上来就调Prompt,先把权限模型和日志体系搭好
- Demo和上线是两回事,Demo能跑通不代表能扛住生产环境
- 失败时谁在兜底,比"成功时多智能"更重要
这些不是理论,是我花两个月、崩了三次才搞懂的。希望你的转型路径能少踩几个坑。
资料展示
下面是我整理的AI大模型学习资料和工具包预览,适合收藏后按主题逐步学习。
如果你想看完整资料目录,可以在评论区留言「资料」;也欢迎告诉我你更关注AI大模型里的哪类内容。
