让大模型直接读你的 CSV 然后给结论，是把最容易出错的一步交给了它：在脑子里做 GROUP BY 。正确架构是模型负责理解问题与生成代码，确定性的计算交给 pandas 或 SQL 执行，模型只读结构化结果再写结论。
为什么不能把表格塞进上下文
上下文窗口装不下真实业务数据，即使装得下，让模型心算聚合值也必然产生幻觉。 Hugging Face 的实战经验同样指向一个结论：数据分析代理要能跑代码，用 pandas 之类的库真正执行计算，而不是靠语言模型”想出”数字。
最小可用架构：
CodeAgent + additional_authorized_imports=["numpy","pandas","matplotlib.pyplot"]。给模型授权这些库，它就能自己写代码、执行、看图、修正，人只提供数据和问题。四层架构：把不确定性关进笼子
- 意图层：用小模型做分类与参数抽取，把”上个月华东的客单价”解析成结构化查询参数。
- 计算层：纯 Python 或 SQL 执行查询，返回结构化 JSON 。这一步不允许模型参与估算。
- 合成层：模型基于 JSON 写结论，并在提示词里加硬约束——不得引用数据中不存在的时间范围与指标。
- 展示层：图表由代码生成，模型不”画”图，只决定画什么。
提示词里的三条硬规则
- 用”禁止”而不是”尽量”：例如”绝不引用数据中未出现的年份”，比”请尽量不要编造”可靠得多。
- 要求先列出三个值得回答的问题，再逐个回答：能显著降低跑题率。
- 要求每个数字后跟一句业务解读：避免输出一堆无意义的相关系数。
一张表的正确提问方式
不要问”这份数据有什么洞察”。要先给出字段含义与业务口径，再指定指标、维度、时间范围，并要求它先跑出汇总表再解读。口径不定义，模型就会用默认理解替代你的业务定义。
工程化落地要点
| 要点 | 做法 |
|---|---|
| 数据预聚合 | 把原始大表预先聚合成小文件，查询从秒级降到毫秒级 |
| 沙箱执行 | 代码必须在隔离环境运行，限制资源与网络 |
| 结果可追溯 | 保留每次运行的代码与数据快照，结论可被复核 |
| 成本控制 | 意图分类用小模型，只有合成结论用大模型 |
若你的分析需要访问外部系统，可以把取数能力封装成工具，参考 常用 MCP 服务端清单；需要结合文档检索时见 RAG 与智能体结合实战。日常办公场景的替代方案可参考 AI 会议纪要工具对比。
模型算出的数字能直接用于汇报吗？
不能直接使用。必须让代码真实执行计算，模型只做解读，并保留执行代码与结果快照以便复核。
数据量很大时怎么办？
先按维度与时间预聚合成小文件，查询时只读聚合结果；不要让模型接触原始明细。
图表需要模型生成吗？
不需要，也不应该。让代码用 matplotlib 或 seaborn 出图，模型只决定画哪张图、怎么看。
为什么结论里会出现数据里没有的年份？
因为提示词用了软约束。改成硬约束：”绝不引用数据中未出现的时间范围”，并让合成层只接收结构化 JSON 。
评论 (0)