简介这份PDF文档面向零售行业的技术开发人员与数据分析从业者聚焦如何将DeepSeek模型与ERP系统对接并基于对接后的数据完成零售库存预测的时序模型训练。内容从库存预测的重要性与常见方法讲起逐步深入到DeepSeek架构原理、ERP系统数据特点、两者对接流程以及时序模型构建基础涵盖AR、MA、ARMA、ARIMA等经典模型与训练步骤。文档还专门设置模型评估与优化章节讲解MSE、RMSE、MAE、MAPE等指标及交叉验证、特征工程、模型融合等策略并通过实际案例展示从数据准备到预测结果评估的完整链路。资源包为1个PDF文件大小约1.96MB共26页目录完整、图表清晰已有112人学习。读者可借此掌握DeepSeek与ERP对接的接口开发、数据预处理、模型调优与监控方法获得可直接参考的库存预测项目实践思路。1. 零售库存预测把 DeepSeek 和 ERP 的时序模型接起来到底难在哪做过零售库存的人都知道最怕的不是没数据而是数据躺在 ERP 里睡大觉。SKU 维度、门店维度、日销、退货、在途、促销标记这些字段在 ERP 系统里都有但要让 DeepSeek 这类大模型真正吃进去做时序预测中间隔着一整套工程链路。这个标题讲的就是这条链路从 ERP 取数、清洗成时序样本、用 DeepSeek 做推理或微调、再把预测结果写回业务系统。它适合两类人一类是手里有 ERP 但不知道怎么把数据喂给模型的工程师另一类是想用 DeepSeek 做时序预测但被数据格式卡住的算法同学。核心难点不在模型本身而在 ERP 的业务语义和时序模型需要的数值语义之间的翻译。2. 先搞清楚 ERP 里哪些字段能当时序特征用2.1 ERP 库存表的字段语义和时序建模的映射关系ERP 系统里跟库存相关的表通常分三类主数据表物料、门店、供应商、事务表采购入库、销售出库、调拨、退货、快照表每日库存余额。做时序预测时真正有用的是事务表加快照表的组合。常见做法是先把每日每个 SKU 在每个门店的净销量算出来再跟当日库存余额对齐形成「日期 SKU 门店 销量 库存 促销标记」的宽表。这里有个容易翻车的地方ERP 里的销售出库不一定等于真实销量。退货、换货、内部领用都会影响净销量。我一般会写一个 SQL 把正向出库和逆向退货做聚合再按日期和 SKU 分组。下面这段 SQL 是常见的净销量计算逻辑字段名按实际 ERP 改。-- 计算每日每 SKU 每门店的净销量 SELECT t.txn_date AS sale_date, t.sku_id, t.store_id, SUM(CASE WHEN t.txn_type SALE_OUT THEN t.qty ELSE 0 END) - SUM(CASE WHEN t.txn_type SALE_RETURN THEN t.qty ELSE 0 END) AS net_sales, SUM(CASE WHEN t.txn_type PURCHASE_IN THEN t.qty ELSE 0 END) AS purchase_in, SUM(CASE WHEN t.txn_type TRANSFER_IN THEN t.qty ELSE 0 END) - SUM(CASE WHEN t.txn_type TRANSFER_OUT THEN t.qty ELSE 0 END) AS transfer_net FROM erp_inventory_txn t WHERE t.txn_date BETWEEN 2024-01-01 AND 2024-12-31 AND t.status CONFIRMED GROUP BY t.txn_date, t.sku_id, t.store_id;这段 SQL 的逻辑是按事务类型分别聚合再算净销量。参数上要注意status字段很多 ERP 里未审核的单据也会留在表里不过滤会把脏数据带进模型。txn_date用业务日期而不是创建日期否则跨月补录的单据会打乱时序。2.2 把 ERP 快照表对齐成连续日期序列ERP 的库存快照表通常只在有变动的日期有记录但时序模型需要连续日期。常见做法是用日期维度表左连接快照表缺失日期用前一天的库存余额填充。这一步在 Python 里用 pandas 的reindex加ffill就能做但要注意门店开业前的日期不应该填充否则会造出虚假的零库存记录。import pandas as pd # df_snapshot 来自 ERP 快照表df_calendar 是日期维度表 df df_calendar.merge(df_snapshot, on[date, sku_id, store_id], howleft) df df.sort_values([sku_id, store_id, date]) # 只对门店营业日期之后的数据做前向填充 df[inventory_balance] df.groupby([sku_id, store_id])[inventory_balance].ffill() # 开业前保持 NaN后续训练时 mask 掉 df[is_open] df[inventory_balance].notna().astype(int)参数说明ffill只填充缺失值不会覆盖已有值。is_open标记用来在训练时排除未开业日期的样本。如果 ERP 里有门店开业日期字段优先用它做过滤比事后 mask 更干净。3. DeepSeek 接入时序预测的两种落地路径3.1 用 DeepSeek API 做零样本推理的调用方式如果只是想做快速验证不打算微调可以直接调 DeepSeek API 做零样本时序推理。思路是把最近 N 天的销量和库存拼成一段文本让模型输出未来 M 天的预测值。这种方式适合 SKU 数量不多、预测精度要求不极端的场景。下面是一个 Python 调用示例用requests直接发请求。import requests import json def predict_with_deepseek(history_sales, history_inventory, horizon7): prompt f你是一个零售库存预测助手。以下是某 SKU 过去 14 天的日销量和库存余额 销量{history_sales} 库存{history_inventory} 请预测未来 {horizon} 天的日销量只输出 JSON 数组不要解释。 resp requests.post( https://api.deepseek.com/v1/chat/completions, headers{Authorization: Bearer YOUR_API_KEY, Content-Type: application/json}, json{ model: deepseek-chat, messages: [{role: user, content: prompt}], temperature: 0.1, max_tokens: 256 }, timeout30 ) return json.loads(resp.json()[choices][0][message][content])逻辑说明temperature设 0.1 是为了让输出稳定时序预测不需要创造性。max_tokens按预测天数乘每条记录长度估算。注意 API 返回的文本可能带 markdown 代码块标记实际用的时候要加一层清洗。这种方式单次调用成本低但 SKU 多了以后延迟和费用都会上去适合做冷启动或长尾 SKU 的兜底。3.2 用 LoRA 微调 DeepSeek 做领域适配的步骤当 SKU 数量上千、促销模式复杂时零样本推理的精度不够。常见做法是用 LoRA 在自有零售数据上做轻量微调。DeepSeek 系列模型支持 LoRA 训练显存需求比全量微调低很多。下面是一个基于 Hugging Face 生态的训练脚本骨架。from transformers import AutoModelForCausalLM, AutoTokenizer, TrainingArguments from peft import LoraConfig, get_peft_model from datasets import load_dataset model_name deepseek-ai/deepseek-llm-7b-chat tokenizer AutoTokenizer.from_pretrained(model_name) model AutoModelForCausalLM.from_pretrained(model_name, device_mapauto) lora_config LoraConfig( r8, lora_alpha16, target_modules[q_proj, v_proj], lora_dropout0.05, biasnone, task_typeCAUSAL_LM ) model get_peft_model(model, lora_config) dataset load_dataset(json, data_filesretail_timeseries_train.json) training_args TrainingArguments( output_dir./deepseek-lora-retail, per_device_train_batch_size4, gradient_accumulation_steps8, num_train_epochs3, learning_rate2e-4, fp16True, logging_steps50, save_strategyepoch )参数说明r8是 LoRA 秩零售时序数据模式相对固定8 到 16 之间够用。target_modules选q_proj和v_proj是常见做法显存紧张时只调这两个。learning_rate用 2e-4 比全量微调的 1e-5 高一个量级因为 LoRA 只更新低秩矩阵。训练数据格式建议是「历史序列 → 未来序列」的 JSON 对每条样本控制在 512 token 以内。3.3 把预测结果写回 ERP 的接口设计模型输出预测值只是第一步业务要用起来必须写回 ERP。常见做法是走 ERP 的开放接口把预测销量和建议补货量写入自定义表或计划表。下面是一个写回接口的伪代码示例。def push_forecast_to_erp(forecast_df, erp_endpoint, api_key): payload { batch_id: generate_batch_id(), records: forecast_df[[sku_id, store_id, forecast_date, forecast_qty]].to_dict(records) } resp requests.post( f{erp_endpoint}/api/inventory/forecast, headers{X-API-Key: api_key}, jsonpayload, timeout60 ) if resp.status_code ! 200: raise RuntimeError(fERP writeback failed: {resp.text}) return resp.json()[accepted_count]逻辑说明批量写入比逐条写入效率高batch_id用于幂等控制避免重复推送。参数上注意 ERP 接口的字段名可能跟模型输出不一致中间要加一层字段映射。写回前建议先在测试环境验证生产环境加审批流避免错误预测直接触发采购。4. 避坑与排查ERP 对接时序模型最常见的 5 个翻车点4.1 现象模型预测值全是零或常数原因通常是训练数据里缺失值被填成了零或者归一化时把有效范围压没了。ERP 导出的数据里未开业日期、停售 SKU、盘点冻结期都会产生大量空值。如果直接用fillna(0)模型会学到「大部分时候销量是零」的错误模式。解决用is_open或is_active标记区分「真实零销量」和「无数据」。训练时对无数据样本做 mask损失函数里排除。归一化按 SKU 维度单独做不要全局归一化。4.2 现象促销期间的预测误差突然变大原因是 ERP 里的促销标记没有跟销量数据对齐。很多 ERP 的促销单是提前录入的但实际执行日期可能调整导致模型看到的促销标记和真实销量峰值错位。解决用实际销售日期反查促销活动而不是用促销单的计划日期。如果 ERP 有促销执行确认表优先用确认日期。没有的话用销量突变点做后验对齐再人工抽检。4.3 现象DeepSeek API 返回格式不稳定JSON 解析失败原因是模型输出可能带 markdown 代码块、多余解释文字或截断。零样本推理时 prompt 里虽然写了「只输出 JSON」但模型不保证 100% 遵守。解决在代码里加清洗层用正则提取第一个[到最后一个]之间的内容。同时设max_tokens留足余量避免截断。生产环境建议加重试机制连续失败三次降级到统计方法兜底。4.4 现象LoRA 微调后模型在验证集上 loss 下降但业务指标变差原因是训练目标跟业务目标不一致。语言模型的 loss 是 token 级交叉熵但业务关心的是 MAPE 或补货准确率。模型可能学会了输出「看起来像」的序列但数值精度不够。解决在验证阶段加业务指标评估不要只看 loss。可以把预测值离散化成区间用分类准确率辅助判断。另外检查训练数据里是否有未来信息泄漏比如用了预测日之后的库存数据。4.5 现象写回 ERP 后数据对不上部分记录丢失原因是 ERP 接口有字段长度限制或枚举值校验。比如sku_id在模型里是字符串ERP 里是数字转换时前导零丢失。或者forecast_date格式不匹配ERP 期望YYYYMMDD而模型输出YYYY-MM-DD。解决写回前做字段级校验用 ERP 的元数据接口拉取字段定义。批量写入时记录每条的返回状态失败的单独重试。建议在中间加一张暂存表确认全部写入成功后再触发业务逻辑。5. 用回测框架验证预测效果一个可复用的评估脚本模型训完不是终点能不能用要看回测。我一般会写一个按时间滑窗的回测脚本模拟「用过去 90 天预测未来 7 天」的真实场景逐周滚动统计每个 SKU 的 MAPE 和补货偏差。下面是一个简化版实现。import numpy as np import pandas as pd def backtest_forecast(df, model_fn, history_days90, horizon7, step7): results [] dates sorted(df[date].unique()) for i in range(history_days, len(dates) - horizon, step): train_end dates[i] test_start dates[i] test_end dates[min(i horizon, len(dates) - 1)] train_df df[df[date] train_end] test_df df[(df[date] train_end) (df[date] test_end)] preds model_fn(train_df, horizon) merged test_df.merge(preds, on[sku_id, store_id, date], howinner) mape np.mean(np.abs(merged[actual] - merged[pred]) / np.maximum(merged[actual], 1)) results.append({train_end: train_end, mape: mape, samples: len(merged)}) return pd.DataFrame(results)逻辑说明history_days是训练窗口horizon是预测窗口step是滚动步长。np.maximum(actual, 1)避免除零。这个脚本可以同时跑 DeepSeek API 和 LoRA 模型对比不同方案的 MAPE。参数上建议至少跑 8 到 12 个滚动窗口否则单次结果波动太大。回测之外我还会做一件事把预测值和实际值按 SKU 分层看。快消品和长尾品的误差分布完全不同混在一起看平均值会掩盖问题。通常快消品 MAPE 能压到 15% 以内长尾品 30% 到 50% 都算正常。如果某个 SKU 的误差突然翻倍优先查 ERP 里那段时间有没有盘点调整或供应商换货。最后说个血泪经验别一上来就全量铺开。先选 20 个 SKU 跑通全链路从 ERP 取数到写回验证确认每个环节都稳了再扩。我见过太多项目卡在字段映射和接口权限上模型本身反而没出过什么大问题。希望帮到你。本文还有配套的精品资源点击获取
简介这份PDF文档面向零售行业的技术开发人员与数据分析从业者聚焦如何将DeepSeek模型与ERP系统对接并基于对接后的数据完成零售库存预测的时序模型训练。内容从库存预测的重要性与常见方法讲起逐步深入到DeepSeek架构原理、ERP系统数据特点、两者对接流程以及时序模型构建基础涵盖AR、MA、ARMA、ARIMA等经典模型与训练步骤。文档还专门设置模型评估与优化章节讲解MSE、RMSE、MAE、MAPE等指标及交叉验证、特征工程、模型融合等策略并通过实际案例展示从数据准备到预测结果评估的完整链路。资源包为1个PDF文件大小约1.96MB共26页目录完整、图表清晰已有112人学习。读者可借此掌握DeepSeek与ERP对接的接口开发、数据预处理、模型调优与监控方法获得可直接参考的库存预测项目实践思路。1. 零售库存预测把 DeepSeek 和 ERP 的时序模型接起来到底难在哪做过零售库存的人都知道最怕的不是没数据而是数据躺在 ERP 里睡大觉。SKU 维度、门店维度、日销、退货、在途、促销标记这些字段在 ERP 系统里都有但要让 DeepSeek 这类大模型真正吃进去做时序预测中间隔着一整套工程链路。这个标题讲的就是这条链路从 ERP 取数、清洗成时序样本、用 DeepSeek 做推理或微调、再把预测结果写回业务系统。它适合两类人一类是手里有 ERP 但不知道怎么把数据喂给模型的工程师另一类是想用 DeepSeek 做时序预测但被数据格式卡住的算法同学。核心难点不在模型本身而在 ERP 的业务语义和时序模型需要的数值语义之间的翻译。2. 先搞清楚 ERP 里哪些字段能当时序特征用2.1 ERP 库存表的字段语义和时序建模的映射关系ERP 系统里跟库存相关的表通常分三类主数据表物料、门店、供应商、事务表采购入库、销售出库、调拨、退货、快照表每日库存余额。做时序预测时真正有用的是事务表加快照表的组合。常见做法是先把每日每个 SKU 在每个门店的净销量算出来再跟当日库存余额对齐形成「日期 SKU 门店 销量 库存 促销标记」的宽表。这里有个容易翻车的地方ERP 里的销售出库不一定等于真实销量。退货、换货、内部领用都会影响净销量。我一般会写一个 SQL 把正向出库和逆向退货做聚合再按日期和 SKU 分组。下面这段 SQL 是常见的净销量计算逻辑字段名按实际 ERP 改。-- 计算每日每 SKU 每门店的净销量 SELECT t.txn_date AS sale_date, t.sku_id, t.store_id, SUM(CASE WHEN t.txn_type SALE_OUT THEN t.qty ELSE 0 END) - SUM(CASE WHEN t.txn_type SALE_RETURN THEN t.qty ELSE 0 END) AS net_sales, SUM(CASE WHEN t.txn_type PURCHASE_IN THEN t.qty ELSE 0 END) AS purchase_in, SUM(CASE WHEN t.txn_type TRANSFER_IN THEN t.qty ELSE 0 END) - SUM(CASE WHEN t.txn_type TRANSFER_OUT THEN t.qty ELSE 0 END) AS transfer_net FROM erp_inventory_txn t WHERE t.txn_date BETWEEN 2024-01-01 AND 2024-12-31 AND t.status CONFIRMED GROUP BY t.txn_date, t.sku_id, t.store_id;这段 SQL 的逻辑是按事务类型分别聚合再算净销量。参数上要注意status字段很多 ERP 里未审核的单据也会留在表里不过滤会把脏数据带进模型。txn_date用业务日期而不是创建日期否则跨月补录的单据会打乱时序。2.2 把 ERP 快照表对齐成连续日期序列ERP 的库存快照表通常只在有变动的日期有记录但时序模型需要连续日期。常见做法是用日期维度表左连接快照表缺失日期用前一天的库存余额填充。这一步在 Python 里用 pandas 的reindex加ffill就能做但要注意门店开业前的日期不应该填充否则会造出虚假的零库存记录。import pandas as pd # df_snapshot 来自 ERP 快照表df_calendar 是日期维度表 df df_calendar.merge(df_snapshot, on[date, sku_id, store_id], howleft) df df.sort_values([sku_id, store_id, date]) # 只对门店营业日期之后的数据做前向填充 df[inventory_balance] df.groupby([sku_id, store_id])[inventory_balance].ffill() # 开业前保持 NaN后续训练时 mask 掉 df[is_open] df[inventory_balance].notna().astype(int)参数说明ffill只填充缺失值不会覆盖已有值。is_open标记用来在训练时排除未开业日期的样本。如果 ERP 里有门店开业日期字段优先用它做过滤比事后 mask 更干净。3. DeepSeek 接入时序预测的两种落地路径3.1 用 DeepSeek API 做零样本推理的调用方式如果只是想做快速验证不打算微调可以直接调 DeepSeek API 做零样本时序推理。思路是把最近 N 天的销量和库存拼成一段文本让模型输出未来 M 天的预测值。这种方式适合 SKU 数量不多、预测精度要求不极端的场景。下面是一个 Python 调用示例用requests直接发请求。import requests import json def predict_with_deepseek(history_sales, history_inventory, horizon7): prompt f你是一个零售库存预测助手。以下是某 SKU 过去 14 天的日销量和库存余额 销量{history_sales} 库存{history_inventory} 请预测未来 {horizon} 天的日销量只输出 JSON 数组不要解释。 resp requests.post( https://api.deepseek.com/v1/chat/completions, headers{Authorization: Bearer YOUR_API_KEY, Content-Type: application/json}, json{ model: deepseek-chat, messages: [{role: user, content: prompt}], temperature: 0.1, max_tokens: 256 }, timeout30 ) return json.loads(resp.json()[choices][0][message][content])逻辑说明temperature设 0.1 是为了让输出稳定时序预测不需要创造性。max_tokens按预测天数乘每条记录长度估算。注意 API 返回的文本可能带 markdown 代码块标记实际用的时候要加一层清洗。这种方式单次调用成本低但 SKU 多了以后延迟和费用都会上去适合做冷启动或长尾 SKU 的兜底。3.2 用 LoRA 微调 DeepSeek 做领域适配的步骤当 SKU 数量上千、促销模式复杂时零样本推理的精度不够。常见做法是用 LoRA 在自有零售数据上做轻量微调。DeepSeek 系列模型支持 LoRA 训练显存需求比全量微调低很多。下面是一个基于 Hugging Face 生态的训练脚本骨架。from transformers import AutoModelForCausalLM, AutoTokenizer, TrainingArguments from peft import LoraConfig, get_peft_model from datasets import load_dataset model_name deepseek-ai/deepseek-llm-7b-chat tokenizer AutoTokenizer.from_pretrained(model_name) model AutoModelForCausalLM.from_pretrained(model_name, device_mapauto) lora_config LoraConfig( r8, lora_alpha16, target_modules[q_proj, v_proj], lora_dropout0.05, biasnone, task_typeCAUSAL_LM ) model get_peft_model(model, lora_config) dataset load_dataset(json, data_filesretail_timeseries_train.json) training_args TrainingArguments( output_dir./deepseek-lora-retail, per_device_train_batch_size4, gradient_accumulation_steps8, num_train_epochs3, learning_rate2e-4, fp16True, logging_steps50, save_strategyepoch )参数说明r8是 LoRA 秩零售时序数据模式相对固定8 到 16 之间够用。target_modules选q_proj和v_proj是常见做法显存紧张时只调这两个。learning_rate用 2e-4 比全量微调的 1e-5 高一个量级因为 LoRA 只更新低秩矩阵。训练数据格式建议是「历史序列 → 未来序列」的 JSON 对每条样本控制在 512 token 以内。3.3 把预测结果写回 ERP 的接口设计模型输出预测值只是第一步业务要用起来必须写回 ERP。常见做法是走 ERP 的开放接口把预测销量和建议补货量写入自定义表或计划表。下面是一个写回接口的伪代码示例。def push_forecast_to_erp(forecast_df, erp_endpoint, api_key): payload { batch_id: generate_batch_id(), records: forecast_df[[sku_id, store_id, forecast_date, forecast_qty]].to_dict(records) } resp requests.post( f{erp_endpoint}/api/inventory/forecast, headers{X-API-Key: api_key}, jsonpayload, timeout60 ) if resp.status_code ! 200: raise RuntimeError(fERP writeback failed: {resp.text}) return resp.json()[accepted_count]逻辑说明批量写入比逐条写入效率高batch_id用于幂等控制避免重复推送。参数上注意 ERP 接口的字段名可能跟模型输出不一致中间要加一层字段映射。写回前建议先在测试环境验证生产环境加审批流避免错误预测直接触发采购。4. 避坑与排查ERP 对接时序模型最常见的 5 个翻车点4.1 现象模型预测值全是零或常数原因通常是训练数据里缺失值被填成了零或者归一化时把有效范围压没了。ERP 导出的数据里未开业日期、停售 SKU、盘点冻结期都会产生大量空值。如果直接用fillna(0)模型会学到「大部分时候销量是零」的错误模式。解决用is_open或is_active标记区分「真实零销量」和「无数据」。训练时对无数据样本做 mask损失函数里排除。归一化按 SKU 维度单独做不要全局归一化。4.2 现象促销期间的预测误差突然变大原因是 ERP 里的促销标记没有跟销量数据对齐。很多 ERP 的促销单是提前录入的但实际执行日期可能调整导致模型看到的促销标记和真实销量峰值错位。解决用实际销售日期反查促销活动而不是用促销单的计划日期。如果 ERP 有促销执行确认表优先用确认日期。没有的话用销量突变点做后验对齐再人工抽检。4.3 现象DeepSeek API 返回格式不稳定JSON 解析失败原因是模型输出可能带 markdown 代码块、多余解释文字或截断。零样本推理时 prompt 里虽然写了「只输出 JSON」但模型不保证 100% 遵守。解决在代码里加清洗层用正则提取第一个[到最后一个]之间的内容。同时设max_tokens留足余量避免截断。生产环境建议加重试机制连续失败三次降级到统计方法兜底。4.4 现象LoRA 微调后模型在验证集上 loss 下降但业务指标变差原因是训练目标跟业务目标不一致。语言模型的 loss 是 token 级交叉熵但业务关心的是 MAPE 或补货准确率。模型可能学会了输出「看起来像」的序列但数值精度不够。解决在验证阶段加业务指标评估不要只看 loss。可以把预测值离散化成区间用分类准确率辅助判断。另外检查训练数据里是否有未来信息泄漏比如用了预测日之后的库存数据。4.5 现象写回 ERP 后数据对不上部分记录丢失原因是 ERP 接口有字段长度限制或枚举值校验。比如sku_id在模型里是字符串ERP 里是数字转换时前导零丢失。或者forecast_date格式不匹配ERP 期望YYYYMMDD而模型输出YYYY-MM-DD。解决写回前做字段级校验用 ERP 的元数据接口拉取字段定义。批量写入时记录每条的返回状态失败的单独重试。建议在中间加一张暂存表确认全部写入成功后再触发业务逻辑。5. 用回测框架验证预测效果一个可复用的评估脚本模型训完不是终点能不能用要看回测。我一般会写一个按时间滑窗的回测脚本模拟「用过去 90 天预测未来 7 天」的真实场景逐周滚动统计每个 SKU 的 MAPE 和补货偏差。下面是一个简化版实现。import numpy as np import pandas as pd def backtest_forecast(df, model_fn, history_days90, horizon7, step7): results [] dates sorted(df[date].unique()) for i in range(history_days, len(dates) - horizon, step): train_end dates[i] test_start dates[i] test_end dates[min(i horizon, len(dates) - 1)] train_df df[df[date] train_end] test_df df[(df[date] train_end) (df[date] test_end)] preds model_fn(train_df, horizon) merged test_df.merge(preds, on[sku_id, store_id, date], howinner) mape np.mean(np.abs(merged[actual] - merged[pred]) / np.maximum(merged[actual], 1)) results.append({train_end: train_end, mape: mape, samples: len(merged)}) return pd.DataFrame(results)逻辑说明history_days是训练窗口horizon是预测窗口step是滚动步长。np.maximum(actual, 1)避免除零。这个脚本可以同时跑 DeepSeek API 和 LoRA 模型对比不同方案的 MAPE。参数上建议至少跑 8 到 12 个滚动窗口否则单次结果波动太大。回测之外我还会做一件事把预测值和实际值按 SKU 分层看。快消品和长尾品的误差分布完全不同混在一起看平均值会掩盖问题。通常快消品 MAPE 能压到 15% 以内长尾品 30% 到 50% 都算正常。如果某个 SKU 的误差突然翻倍优先查 ERP 里那段时间有没有盘点调整或供应商换货。最后说个血泪经验别一上来就全量铺开。先选 20 个 SKU 跑通全链路从 ERP 取数到写回验证确认每个环节都稳了再扩。我见过太多项目卡在字段映射和接口权限上模型本身反而没出过什么大问题。希望帮到你。本文还有配套的精品资源点击获取
