基于 Function Calling 实现自动化报表生成的落地实践与坑点分析

这次在项目里尝试用 Function Calling 实现自动化报表，核心链路是：用户自然语言 → LLM 识别意图并调用查询函数 → 结构化数据返回 → LLM 汇总生成分析报表。看似闭环，但实际跑起来后，有几个深坑必须得避开。

最核心的痛点在于 Prompt 的“语义漂移”和参数幻觉。
当你的函数定义（Schema）过于庞大时，LLM 很容易在参数传递上出错，比如把 date_range 的格式写错，或者在面对相似字段（如 created_at 和 updated_at）时产生混淆。

几个实操层面的优化点：

1. 拒绝把所有字段塞进 Schema
千万不要直接把数据库表结构 dump 给模型。建议采用“两级分发”机制：先通过一个轻量级的 get_relevant_fields 函数，让模型在所有字段中筛选出本次查询相关的 5-10 个字段，然后再进入正式的查询函数。这样能显著降低 Token 消耗，提高参数命中率。

2. 强约束参数格式
在函数描述中，不要只写 date: 字符串，要明确写死格式要求。例如：

{
  "name": "query_sales_data",
  "description": "查询销售数据，日期必须采用 YYYY-MM-DD 格式",
  "parameters": {
    "type": "object",
    "properties": {
      "start_date": { "type": "string", "description": "开始日期，格式：2023-01-01" }
    }
  }
}

3. 结果回传的截断处理
Function Calling 返回的结果如果太大（比如查出了 1000 行数据），直接喂回给 LLM 会导致上下文溢出或推理速度骤降。正确的做法是在函数内部完成初步的聚合（Aggregation），只把汇总后的统计结果交给 LLM 做解读，而不是把原始数据集传回去。

对开发者的启示：
Function Calling 的本质不是让 AI 替代编程，而是把 AI 当作一个“动态路由”。在做自动化报表时，要把复杂的逻辑留在代码侧（函数内部），把意图识别留在 AI 侧。如果你试图通过复杂的 Prompt 让 AI 直接写出完美的 SQL 且一次性运行成功，那大概率会在生产环境被各种 Edge Case 搞崩溃。

建议的验证链路：
定义精简函数 → 强制格式约束 → 内部数据聚合 → 最终自然语言润色。这套组合拳比单纯依赖模型能力要稳得多。