利用 Function Calling 构建自动化数据分析 Pipeline 的实战经验分享

很多开发者在尝试用 LLM 做数据分析时，最头疼的不是模型写不出 Python 代码，而是如何让模型在“分析-执行-修正”这个闭环里稳定运行。单纯靠 Prompt 让 AI 输出代码块再手动运行，根本无法规模化。真正的突破点在于将 LLM 视为一个“调度大脑”，通过 Function Calling（函数调用）把数据分析的原子能力（如 SQL 查询、Pandas 处理、绘图）封装成工具。

核心逻辑是构建一个「意图解析 → 工具调用 → 结果反馈 → 结论生成」的 Pipeline。

在实战中，最有效的做法是不要给模型一个万能的 execute_python 接口，因为那样太容易崩溃。建议将能力拆解为具体的函数。例如，定义一个 get_dataset_schema 用来获取表结构，一个 run_sql_query 用来提取数据，以及一个 generate_visual_chart 用来绘图。这样模型在调用时有明确的约束，幻觉率会大幅降低。

一个典型的函数定义结构如下（以 JSON Schema 为例）：

{
  "name": "query_sales_data",
  "description": "查询指定时间段内的销售额和订单量",
  "parameters": {
    "type": "object",
    "properties": {
      "start_date": {"type": "string", "description": "开始日期, 格式 YYYY-MM-DD"},
      "end_date": {"type": "string", "description": "结束日期, 格式 YYYY-MM-DD"},
      "product_category": {"type": "string", "description": "产品类目"}
    },
    "required": ["start_date", "end_date"]
  }
}

这意味着 AI 不再是简单的“写代码”，而是在“操作软件”。对开发者来说，这种模式最大的影响是解耦了模型能力与业务逻辑。你不需要为了适配新数据集而疯狂修改 Prompt，只需要更新 Function 的定义和底层的 API 实现。

但这里有个坑：当分析链路过长时，模型容易在第三四次函数调用后丢失上下文，导致得出错误的结论。解决办法是在每次函数返回结果给模型时，对结果进行精简（Summarization），只保留关键指标，而不是把几千行的 CSV 结果直接塞回 Context。

这种 Pipeline 的成熟意味着 AI 正在从「聊天机器人」转向「智能 Agent」。它把数据分析的门槛从“会写 SQL/Python”降低到了“会描述问题”，但对开发者的要求则从“写好 Prompt”变成了“设计合理的工具集和状态机”。