Large Language Models for Predictive Analysis: How Far Are They?¶
会议: ACL 2025
作者: Qin Chen, Yuanyi Ren, Xiaojun Ma, Yuyang Shi (Peking University, Harvard University)
arXiv: 2505.17149
代码: GitHub
领域: LLM/NLP, 基准评测
关键词: predictive analysis, benchmark, code generation, text analysis, text-code alignment, LLM evaluation
一句话总结¶
提出 PredictiQ 基准——首个系统评估 LLM 预测分析能力的综合框架，整合 8 个领域 44 个真实数据集和 1130 条专家设计的查询，从文本分析、代码生成、文本-代码对齐三个维度七个方面评估 12 个主流 LLM，揭示即使最强的 GPT4O3Mini 在深度分析（2.91/4）和数据预处理（51%缺失）上仍存在显著不足。
研究背景与动机¶
- 核心问题： 预测分析（利用统计建模和机器学习从历史数据预测未来趋势）是现代决策的基石，LLM 有潜力成为非专业用户进行预测分析的即开即用工具，但学界缺乏系统评估 LLM 在预测分析中实际能力的基准和方法论。
- 现有评测的不足： 已有评测方法存在两个根本缺陷——(1) 仅评估模型输出结果（如数据库查询的总销售额），受限于 LLM 上下文长度，无法处理完整的大规模数据集，可扩展性差；(2) 仅评估生成代码的执行结果，忽略了文本解释（如算法选择理由、数据特征分析），导致可用性和用户信任度下降。两种方式均无法胜任预测分析这种高度复杂的任务。
- 本文动机： LLM 驱动的预测分析涉及数据预处理、算法选择、结果解读等多环节，这些环节既需要清晰的文本解释来保障可靠性，又需要可执行的代码来实现分析逻辑，且文本与代码之间需保持一致性以帮助用户理解。因此，迫切需要一个能同时评估文本分析质量、代码生成质量和文本-代码对齐程度的综合评估框架。
- 关键差异： 与 Text2Analysis 等仅关注代码生成的先前工作不同，PredictiQ 是首个覆盖预测分析全流程（输入→分析→代码→解释→对齐）的端到端评估基准。
方法详解¶
数据收集与查询构造¶
PredictiQ 从 Kaggle、TCPD 时间序列基准和 Econometric Analysis 教材等公开平台收集 44 个真实世界数据集，覆盖 8 个常见预测分析应用领域。数据科学专家基于每个数据集的特点，按照严格约束制定预测性查询：(a) 使用无歧义语言明确预测目标；(b) 仅依赖数据集内部信息，不依赖外部知识；(c) 每条查询限定为单一问题。查询类型涵盖分类（285条）、回归（324条）、预测（220条）、聚类（137条）、异常检测（126条）等多种任务，共计 1130 条查询。
| 领域 | 数据集数 | 查询数 |
|---|---|---|
| 经济学 | 12 | 270 |
| 市场与销售 | 6 | 200 |
| 行业分析 | 7 | 180 |
| 交通 | 5 | 130 |
| 医疗 | 4 | 130 |
| 社会学 | 4 | 110 |
| 人力资源 | 3 | 80 |
| 教育 | 3 | 70 |
| 合计 | 44 | 1130 |
Prompt 构造策略¶
每条 Prompt 由三部分组成：(1) 查询与指令——指示 LLM 扮演专业数据科学家进行预测分析；(2) 数据摘要——列出所有列名、数据类型、数值列的最大/最小值、分类列的类别数等统计信息；(3) 数据详情——以 CSV 格式提供完整数据集。数据摘要帮助 LLM 更好地理解数据结构，CSV 格式则提供分析所需的具体信息。
三域七方面评估协议¶
评估协议设计是本文核心贡献之一，覆盖预测分析全流程的三个域：
- 文本分析（2个方面）：相关性——文本分析与数据和查询的匹配程度；深度——对算法选择的论证是否全面深入。
- 代码生成（2个方面）：有用性——代码是否有效解决给定问题；功能正确性——代码执行是否无错误（通过人工执行验证，计算可执行比率后映射到 0-4 分）。
- 文本-代码对齐（3个方面）：描述准确性——文本是否精确反映代码功能；覆盖度——文本是否涵盖代码的所有相关方面；清晰度——文本与代码的对应关系是否清晰易懂。
各方面均采用 0-4 分制，满分 28 分。评估器选择方面，对比 GPT4Turbo、GPT4O 和 Phi3Medium 与 5 位人类数据分析专家的评分一致性，GPT4Turbo 以 90.5% 的对齐率胜出，被选为主评估器。
实验结果¶
12 个 LLM 在 PredictiQ 上的整体表现¶
| 模型 | 相关性 | 深度 | 有用性 | 功能正确率 | 描述准确性 | 覆盖度 | 清晰度 | 总分 |
|---|---|---|---|---|---|---|---|---|
| GPT4O3Mini | 3.63 | 2.91 | 3.53 | 87% | 3.52 | 3.52 | 3.52 | 24.11 |
| GPT4O1 | 3.61 | 2.80 | 3.45 | 85% | 3.47 | 3.48 | 3.48 | 23.70 |
| GPT4O | 3.60 | 2.39 | 3.12 | 81% | 3.36 | 3.31 | 3.41 | 22.43 |
| GPT4Turbo | 3.39 | 2.18 | 2.78 | 78% | 3.09 | 2.95 | 3.18 | 20.68 |
| Phi4 | 2.94 | 2.55 | 2.87 | 54% | 2.84 | 2.82 | 2.88 | 19.06 |
| GPT3.5Turbo | 3.00 | 1.76 | 2.40 | 53% | 2.66 | 2.47 | 2.80 | 17.21 |
| CohereRPlus | 2.89 | 1.70 | 2.38 | 42% | 2.50 | 2.42 | 2.62 | 16.20 |
| Phi3Medium | 2.90 | 1.74 | 2.33 | 41% | 2.45 | 2.33 | 2.58 | 15.97 |
| ChatLlama2-70B | 2.32 | 1.51 | 1.78 | 21% | 1.25 | 1.27 | 1.60 | 10.57 |
| CodeLlama2-7B | 2.04 | 1.34 | 1.64 | 15% | 0.99 | 1.00 | 1.22 | 8.83 |
| ChatLlama2-13B | 1.97 | 1.24 | 1.53 | 18% | 1.02 | 1.03 | 1.24 | 8.75 |
| ChatLlama2-7B | 2.01 | 1.31 | 1.49 | 18% | 0.83 | 0.85 | 1.14 | 8.34 |
代码质量深度分析¶
LLM 生成的代码普遍存在缺失数据预处理的问题，且错误类型随模型规模变化呈现不同模式：
| 模型 | 无预处理占比 | Import错误 | 语法错误 | 运行时错误 | 库错误 | 数据流错误 |
|---|---|---|---|---|---|---|
| GPT4O3Mini | 51% | 0.3% | 3.1% | 2.3% | 2.9% | 4.4% |
| GPT4O | 66% | 0.4% | 5.1% | 3.9% | 3.8% | 5.8% |
| GPT4Turbo | 66% | 1.3% | 7.8% | 3.8% | 3.4% | 5.7% |
| GPT3.5Turbo | 71% | 3.8% | 15.3% | 7.6% | 7.8% | 12.5% |
| Phi4 | 58% | 3.8% | 12.3% | 10.3% | 9.5% | 10.2% |
| ChatLlama2-70B | 87% | 15.0% | 12.5% | 22.7% | 16.3% | 12.5% |
| CodeLlama2-7B | 89% | 38.2% | 17.4% | 11.3% | 8.8% | 9.3% |
关键发现¶
- 代码微调的双刃剑效应：CodeLlama2-7B 在文本分析和文本-代码对齐方面超越同规模 ChatLlama2-7B 甚至 13B 的 Chat 模型（总分 8.83 vs 8.75），但代码可执行率反而更低（15% vs 18%），表明过度特化的代码微调可能损害实际代码执行质量。
- 模型规模与性能的非线性关系：增大 Llama 家族的参数规模（7B→13B→70B）能提升总分（8.34→8.75→10.57），但代码可执行率提升有限（18%→18%→21%），逻辑错误占比甚至上升。
- LLM 普遍忽视数据预处理：即使表现最优的 GPT4O3Mini 仍有 51% 的生成代码缺乏数据预处理（如缺失值处理、异常值过滤），小模型更为严重（ChatLlama2-7B 达 92%）。
- 领域间能力差异显著：ChatLlama2-70B 在教育领域的表现超出其平均分 31.4%，但在其他领域大幅下滑。GPT4O3Mini 和 GPT4O 表现最均衡，领域间分差分别仅为 1.67 和 1.82 分。
- 推理模型需要大上下文：GPT4O1 和 GPT4O3Mini 在 4K token 限制下表现远不如 GPT4O，需将上下文扩展到 32K token 才能释放推理能力，但 GPT4O3Mini 用更少的 token 即可达到 GPT4O1 的水平。
亮点与创新¶
- 首个针对 LLM 预测分析能力的综合基准，从文本、代码、对齐三个维度全面覆盖分析全流程，填补了领域空白
- 评估协议设计严谨——投入 300 人时构造查询、900 人时评估响应，并通过实验验证 GPT4Turbo 作为评估器与人类专家的 90.5% 对齐率
- 实验规模大且发现深刻：12 个模型 × 1130 条查询的全量评测，揭示了代码微调的双刃剑效应、推理模型的上下文依赖等非直觉发现
- 评估器偏差分析揭示了 LLM-as-judge 的"圆数偏差"问题，Phi3Medium 对所有目标模型给出几乎不可区分的高分，削弱了评估的区分度
局限性¶
- 仅评估预测分析任务，未涵盖处方分析（prescriptive）和诊断分析（diagnostic）等其他高级数据分析类型
- 数据集局限于 8 个常见应用领域的结构化表格数据，未包含图像、图数据等非结构化形式
- 查询限定为单问题形式，未涉及多步骤复合查询或交互式分析场景
- Llama 系列仅测试 Llama-2 版本，未纳入 Llama-3 等更新模型
- 评估使用 GPT4Turbo 而非全人工评审，尽管对齐率达 90.5%，仍有约 10% 的评分偏差
相关工作¶
- LLM 评估基准： 通用 LLM 能力评估（如 MMLU、SuperGLUE）侧重于语言理解/推理，本文聚焦于预测分析这一特定应用场景
- LLM 数据分析： Text2Analysis (He et al., 2023) 引入四类数据分析查询但仅评估代码生成；Data Interpreter (Hong et al., 2024) 关注 LLM Agent 的数据科学能力但缺乏标准化评估协议
- LLM 代码生成评估： HumanEval、MBPP 等关注通用代码生成，不涉及数据分析特有的文本解释和对齐需求
- 时序预测与 LLM： Time-LLM (Jin et al., 2023) 等关注特定领域时序预测，但局限于单一任务类型，缺乏多领域多任务的综合评估
评分¶
| 维度 | 分数 |
|---|---|
| 新颖性 | ⭐⭐⭐⭐ |
| 技术深度 | ⭐⭐⭐ |
| 实验完整度 | ⭐⭐⭐⭐⭐ |
| 写作质量 | ⭐⭐⭐⭐ |
| 实用性 | ⭐⭐⭐⭐ |