ARTICLE DETAIL

建站实战干货

来自一线的建站与推广经验沉淀,每一条都经过真实交付验证。

大模型驱动的汽车销量预测:Python与LightGBM实战指南

2026/9/8 10:29:30 拓冰建站 浏览量
大模型驱动的汽车销量预测:Python与LightGBM实战指南 简介面向新能源汽车市场分析人员与Python开发者这份代码包提供了一个从数据采集到销量预测的完整项目参考。基于requests与BeautifulSoup构建爬虫获取实时数据经Pandas清洗后存入数据库再利用Matplotlib、Seaborn及Echarts完成可视化并借助Scikit-learn、TensorFlow实现GBDT、ARIMA等模型的训练与预测。压缩包共14个文件包含8个Python脚本、1个HTML模板、1个CSV数据集及配置说明文档等整体仅27KB结构覆盖爬虫、分析、可视化、模型与数据目录便于快速定位和二次开发。目前已有79人学习使用。通过该资源可掌握网络爬虫、数据清洗、特征构建、模型评估与结果可视化的完整链路尤其适合希望结合大模型提升销量预测精度的初学者或研究者。 做汽车销量预测这几年我最大的感受是单纯靠 Excel 和传统时间序列模型已经越来越难应对真实业务里的复杂信号。政策补贴、新车发布、舆情口碑、促销活动这些信息大部分以文本形式散落在新闻和论坛里传统模型根本吃不到。所以我在新项目里直接把大模型拉进预测流程用 Python 串起“数据清洗—特征抽取—销量预测—系统对接”这条完整链路。这篇文章就把这套能跑的汽车销量预测项目代码拆开讲清楚从环境配置到模型训练再到和 SSM 项目对接全部给出可以抄作业的方案。这套思路适合三类人一是正在做汽车行业数据分析想引入 AI 能力的从业者二是后端用 Java SSM 框架、又想接 Python 预测服务的团队三是刚学大模型应用开发想找一个真实业务场景练手的朋友。整个方案我强调一个原则大模型不负责最终预测数值它负责把非结构化的文本信息变成结构化特征最终预测交给 LightGBM 这类经典模型。这样既稳又准落地成本还低。1. 项目整体设计为什么汽车销量预测要上大模型1.1 传统销量预测模型的痛点与转机以前做销量预测最常用的是 ARIMA、Prophet稍微讲究一点的上 XGBoost。它们的输入都是结构化数据历史销量、价格、库存、广告投入。听起来没毛病但实际业务里经常遇到这种情况某品牌当月突然上了热搜口碑两极分化线下门店客流爆增结果下个月销量数据非常漂亮。传统模型看到的是“上个月销量低”它无法理解“为什么低”更不会预判“接下来会反弹”。另外一个问题是政策扰动。购置税减免、以旧换新补贴这类信息刚出来时还没有形成历史数据传统模型没有依据可学。但如果能把政策文件的原文、新闻报道的标题和正文交给大模型去理解模型就能提前捕捉到“利好”信号并把它量化成特征这对销量预测的提升非常明显。所以我的结论是传统模型不是被替代而是要给它“外挂”。大模型就是这个外挂它负责把人类能读懂但机器难处理的文本信息转成模型能用的数值特征。1.2 大模型在项目里的真实角色很多朋友一听到“大模型预测销量”下意识觉得是用 ChatGPT 直接问“下个月卖多少台”然后拿它输出的数字当结果。我劝你千万别这么做。指令大模型的强项是理解和生成不是数值外推。你让它预测销量它可能给你一个看起来合理但完全没有统计依据的数字而且换一次提问换一个答案根本没法做工程化。我在这个项目里安排了两个角色环节大模型参与方式输出特征工程读取新闻标题、政策文本、用户评论按提示词抽取情绪倾向和事件类型情绪得分、事件热度、利好/利空标签预测辅助根据历史数据和外部特征生成业务解读和异常值提醒诊断文本帮助人理解预测结果最终进入 LightGBM 模型的特征既包含历史销量、价格指数、广告费用这些常规字段也包含大模型产出的文本特征。这个混合方案我实测下来最稳定MAPE平均绝对百分比误差比纯结构化特征模型低 3 到 5 个百分点比纯大模型输出不知道高到哪里去了。2. 环境准备与核心依赖2.1 基础环境Python、VSCode、本地大模型先说 Python 环境。我建议用 Python 3.10 或 3.11太老的版本对最新版 LightGBM 和 FastAPI 支持不好。编辑器直接用 VSCode配置好 Python 解释器就行。如果你对 VSCode 的 Python 环境配置还不熟记住一个关键点在命令面板里输入Python: Select Interpreter选择你创建的虚拟环境不要用全局环境否则后面装包会乱。大模型部分我用的是 Ollama 本地部署方案模型选的 Qwen2.5-7B-Instruct 的量化版。为什么不直接调云端大模型 API因为销量预测项目里经常涉及企业内部数据把数据发到外部接口会有合规风险。本地部署虽然对硬件有要求但胜在数据可控、调用免费、延迟稳定。7B 量化模型在 8GB 显存的显卡上就能跑输出质量比 3B 好很多对于抽取情绪标签这种任务已经够用。2.2 依赖安装与数据来源说明创建一个干净的虚拟环境然后按下面清单安装依赖依赖库用途安装命令pandas数据处理pip install pandasnumpy数值计算pip install numpyscikit-learn模型评估与切分pip install scikit-learnlightgbm销量预测主模型pip install lightgbmrequests调用 Ollama APIpip install requestsfastapi、uvicorn封装预测服务pip install fastapi uvicorn这些都是尽量少的花活。项目里的数据我用了两部分内部结构化数据放在data/sales.csv包含过去 36 个月的销量、广告费用、均价、同价位竞品数量外部文本数据放在data/news.csv包含当月新闻标题、政策标题和论坛帖子摘要。真实项目里这些数据通常由爬虫或内部数仓同步我这里为了演示先用脱敏后的样例数据跑通流程。注意销量预测最怕数据泄漏切分训练集和测试集时绝对不能随机打乱。时间序列数据必须按时间顺序切分用前 24 个月训练后 12 个月验证。3. 数据获取与特征工程让大模型有料可用3.1 结构化数据清洗与特征构建汽车销量数据格式还算规整但有几个坑必须处理。第一缺失值不能直接填充平均值销量序列通常有趋势用前向填充更合理。第二节假日和季度末冲量会造成明显波动需要构造“月份”和“是否季度末”两个特征。第三广告费用对销量的影响有滞后性我习惯把广告费用往前移一个月用上月的投放预测本月销量。核心处理代码大概是这样的import pandas as pd import numpy as np df pd.read_csv(data/sales.csv, parse_dates[date]) df df.sort_values(date) # 缺失值前向填充 df df.fillna(methodffill) # 构造时间特征 df[month] df[date].dt.month df[quarter_end] df[date].dt.month.isin([3, 6, 9, 12]).astype(int) # 广告费用滞后一个月 df[ad_spend_lag1] df[ad_spend].shift(1) # 目标变量下月销量 df[target] df[sales].shift(-1) df df.dropna()这里最关键的是shift(-1)这一行。它把目标变量变成“下个月的实际销量”训练的时候模型才能学会用本月已知特征预测下月结果。很多新手在这里直接拿当月销量当标签结果模型上线后预测的其实是当月数据完全错位。3.2 用大模型从文本中抽取情绪特征这是整个项目里最有技术含量的部分。我写了一个提示词模板让本地 Qwen 模型逐条分析新闻标题输出情绪分数和事件类型。提示词设计有三个要点一是输出格式必须固定为 JSON方便程序解析二是温度参数设成 0避免每次运行结果都不一样三是要求模型只输出结果不要任何解释省 token 也省时间。import requests import json OLLAMA_URL http://localhost:11434/api/generate def extract_sentiment(text): prompt f 你是一个汽车行业舆情分析助手。请阅读下面的新闻标题 判断它对某汽车品牌销量是利好、利空还是中性。 要求 1. 只输出 JSON不要其他文字。 2. 格式: {{sentiment: positive/negative/neutral, score: 0.0~1.0, event: 政策/发布/口碑/其他}} 新闻标题: {text} payload { model: qwen2.5:7b, prompt: prompt, stream: False, options: {temperature: 0} } resp requests.post(OLLAMA_URL, jsonpayload, timeout60) result json.loads(resp.json()[response]) return result跑完所有新闻数据后按月份聚合得到三个新特征positive_ratio利好新闻占比、negative_ratio利空新闻占比、policy_heat政策类新闻数量。这些特征就是大模型对销量预测的贡献它们把“这个月舆论环境好不好”这个模糊概念变成了模型能学习的数值。4. 模型训练与预测混合方案的核心代码4.1 为什么最终预测交给 LightGBM大模型抽取完特征后不要急着把数据丢给神经网络。汽车销量数据量通常不大一个月一条记录十年也就一百多条。这种小样本场景下树模型比深度学习更稳训练快、调参少、结果可解释。LightGBM 是首选它对缺失值容忍度高特征重要性可以直接输出方便业务人员理解。模型评估指标我用 MAPE它能直观反映预测偏差百分比。比如实际销量 10000 台预测 11000 台MAPE 就是 10%。车企销售部门容易理解这个数字比 RMSE 那种“误差的平方根”友好得多。4.2 大模型微调还是 API 调用有朋友问既然用了大模型为什么不直接微调一个销量预测模型我的建议是如果只是抽取情绪特征Prompt 调用完全够用没必要微调。微调需要大量已标注数据汽车销量领域公开标注集很难找自己做标注成本极高。只有当你的任务非常固定、数据量足够并且大模型默认输出格式无法满足要求时才考虑用 LoRA 做轻量微调。而且微调完的模型还得重新走评估流程大概率还不如把时间和人力花在提升文本特征质量上。4.3 训练、评估与预测代码特征列我定义为下面几个month、quarter_end、ad_spend_lag1、avg_price、competitor_count、positive_ratio、negative_ratio、policy_heat。训练部分代码如下import lightgbm as lgb from sklearn.metrics import mean_absolute_percentage_error features [month, quarter_end, ad_spend_lag1, avg_price, competitor_count, positive_ratio, negative_ratio, policy_heat] train_df df.iloc[:-12] test_df df.iloc[-12:] model lgb.LGBMRegressor( n_estimators500, learning_rate0.05, max_depth5, num_leaves31, random_state42 ) model.fit( train_df[features], train_df[target], eval_set[(test_df[features], test_df[target])], callbacks[lgb.early_stopping(50)] ) pred model.predict(test_df[features]) mape mean_absolute_percentage_error(test_df[target], pred) print(f验证集 MAPE: {mape:.4f}) # 特征重要性 importance pd.Series(model.feature_importances_, indexfeatures).sort_values(ascendingFalse) print(importance)在跑这个代码的时候如果发现大模型情绪特征的重要性排名靠后先别急着删检查一下文本数据的覆盖度。我曾经遇到过一个情况新闻数据只抓了少数几个媒体源导致情绪特征过于稀疏模型自然学不到东西。后来扩大了数据来源特征重要性立刻上来了。5. 项目集成如何与 Java SSM 项目对接5.1 用 FastAPI 封装预测接口训练好的模型要真正在业务里用起来不能只在 Jupyter Notebook 里跑。大多数车企的内部管理系统是 Java 写的特别是老一点的项目还在用 SSMSpring SpringMVC MyBatis框架。两种技术栈对接最省事的方案是用 FastAPI 把预测能力封装成 HTTP 接口。from fastapi import FastAPI from pydantic import BaseModel import pickle app FastAPI() class PredictRequest(BaseModel): features: dict with open(model/lightgbm_sales.pkl, rb) as f: model pickle.load(f) app.post(/predict) def predict(req: PredictRequest): # features 按训练时的顺序排列 input_data pd.DataFrame([req.features]) input_data input_data[features] result model.predict(input_data)[0] return {predicted_sales: round(result, 2)}启动命令就一行uvicorn main:app --host 0.0.0.0 --port 8000。然后用浏览器访问http://localhost:8000/docs就能看到 Swagger 接口文档方便联调。5.2 Java SSM 端调用 Python 服务的两种方式第一种是我最推荐的方式Java 端直接发 HTTP 请求。Spring 项目里用 RestTemplate 或者 HttpClient把预测需要的特征拼成 JSON 发给 Python 服务拿到结果后用 Gson 或 Jackson 解析。代码如下RestTemplate restTemplate new RestTemplate(); MapString, Object features new HashMap(); features.put(month, 6); features.put(quarter_end, 0); features.put(ad_spend_lag1, 320.5); // 其他特征... MapString, Object requestBody Collections.singletonMap(features, features); ResponseEntityMap response restTemplate.postForEntity( http://localhost:8000/predict, requestBody, Map.class ); double predictedSales (Double) response.getBody().get(predicted_sales);第二种方式是把训练好的 LightGBM 模型导出成 PMML 格式用 Java 的 jpmml 库直接加载。这个方案省去了 Python 服务部署更简单但模型一旦更新需要重新导出 PMML 文件并重启应用。我个人的经验是如果团队里有 Python 工程师维护模型用第一种方式更灵活如果就是纯 Java 团队第二种方式更省事。注意两个服务联调时最容易出问题的是 JSON 字段类型。Python 端的 numpy 浮点数有时候不能直接序列化我在 FastAPI 里返回前统一转成round(..., 2)就是怕 Java 这边解析报错。6. 常见问题与排查技巧实录项目在实际落地过程中我整理了几个高频问题直接列成表现象可能原因解决办法模型预测结果总是比实际低训练数据里没有包含促销活动、政策刺激等事件特征检查文本特征是否构建成功补充大模型抽取的政策热度特征Ollama 请求超时文本数据量太大逐条调用太慢用连接池并发请求或先截断前 200 字再分析中文新闻标题乱码CSV 文件编码不是 UTF-8读取时指定encodingutf-8或encodinggbk特征重要性中情绪特征全是 0大模型返回的结果没匹配上月份检查新闻日期字段按月份聚合前先做格式统一模型上线后预测有延迟每次预测都重新加载模型把模型加载放进 FastAPI 的启动事件里只加载一次还有一个特别容易踩的坑Ollama 默认会复用上下文如果你在一个会话里传入了很长的文本后面请求的响应时间会越来越慢。我处理的办法是在提示词里明确要求模型“忽略历史对话”并且在代码里每次调用都直接使用单次生成接口而不是对话接口保证上下文独立。另外如果你在 VSCode 里调试 Python 服务发现import lightgbm报错多半是解释器选错了。比如 VSCode 右下角显示的 Python 版本和你安装依赖的虚拟环境不一致。我一直习惯在项目根目录建.venv文件夹然后在.vscode/settings.json里强制指定解释器路径这样团队协作时不会出现“我本地能跑但你跑不了”的问题。最后再分享一个小技巧大模型除了帮预测还可以做预测结果解读。每个月预测完销量让 Qwen 根据预测值和特征重要性生成一段业务报告解释“这个月预测偏高主要是因为政策热度上涨和广告投放增加”。这一招在给领导汇报的时候特别好用也让项目的价值感提升不少。如果你也想把汽车销量预测做得更接地气建议从这个方向再扩展一下。本文还有配套的精品资源点击获取