尧图网页设计 
简介这份PDF面向零售业数据分析师、算法工程师及希望将大模型落地到业务场景的技术人员聚焦如何用DeepSeek-R1-Distill完成低成本库存预测微调。内容从库存管理痛点切入系统讲解模型架构、数据收集与清洗、特征工程再到冻结部分模型层、小批量训练、学习率调整与数据增强等低成本微调策略并给出环境搭建、模型加载、训练循环、评估指标选择与超参数优化的完整实战步骤最后以零售企业案例串联全流程。资源包共1个PDF文件大小约1.86MB21页篇幅目录与图表显示正常结构清晰便于按章节查阅。目前已有102人学习。读者可借此掌握从数据准备到模型评估的落地方法理解低成本微调在库存预测中的适用边界并获得可复用的代码实现思路与调优经验。1. 零售库存预测为什么盯上了 DeepSeek-R1-Distill从「拍脑袋补货」到「按天算量」做零售运营的人都有一个共同的痛门店 SKU 动辄上千历史销量、促销日历、节假日、天气、竞品调价全搅在一起靠 Excel 拉个移动平均根本压不住波动。补多了压资金补少了断货丢单店长每天在「多订两箱」和「再等等看」之间反复横跳。库存预测这件事本质是把「下周这个 SKU 大概卖多少」变成一个可量化、可复现、可迭代的数值问题而不是靠老店长的直觉。大模型微调实战这两年从 NLP 圈一路烧到零售场景DeepSeek-R1-Distill 系列因为蒸馏后推理成本低、中文理解稳成了不少团队做垂直微调的首选底座。它不是一个「万能预测器」而是一个能把结构化时序特征、文本型业务规则、促销说明一起读进去的推理引擎。你给它一段「过去 28 天日销 未来 7 天促销计划 门店等级」的描述它能输出一个带解释的预测量区间这比单纯跑 ARIMA 或 Prophet 更贴近业务语言。这篇文章面向的是手里有销售流水、想用低成本方式跑通库存预测微调的工程师和数据分析师。不追求刷榜追求的是一张消费级显卡或一台带 24G 显存的机器能把 DeepSeek-R1-Distill 微调到一个「比基线模型明显好、业务方愿意看」的水平。下面从数据构造、LoRA 微调、参数设置到踩坑排查一步步拆开讲。2. 把销售流水变成微调样本DeepSeek-R1-Distill 的数据构造与格式对齐2.1 为什么库存预测不能直接拿原始流水喂模型原始 POS 流水是「一行一单」的明细字段包括时间戳、门店 ID、SKU、销量、单价、促销标记。直接把它塞进模型等于让模型在噪声里自己找规律效果极不稳定。常见做法是先做时间窗聚合把每个「门店 × SKU」按天汇总成一条时序记录再往前切一个观察窗口、往后切一个预测窗口。我一般会构造这样的样本观察窗口取过去 28 天预测窗口取未来 7 天。观察窗口里保留日销量、是否促销、是否周末、是否有缺货标记预测窗口里保留未来 7 天的促销计划、节假日标记。模型要学的不是「记住某个 SKU 卖多少」而是「给定这段历史和未来事件未来 7 天日销大概是什么形状」。这里有个关键取舍DeepSeek-R1-Distill 是语言模型不是纯时序模型。它的优势在于能读文本规则所以样本里要保留一部分自然语言描述比如「该门店位于社区周末客流集中」「该 SKU 属于低温短保补货周期 2 天」。这些文本和数值特征拼在一起才是蒸馏模型能发挥的地方。2.2 样本构造脚本从 CSV 到 JSONL 的最小可跑流程下面这段代码做三件事读销售流水、按门店和 SKU 聚合、生成带指令和回答的 JSONL 样本。依赖 pandas不需要额外框架。import pandas as pd import json from datetime import timedelta # 读取原始流水字段示例date, store_id, sku_id, qty, promo, stockout df pd.read_csv(sales_raw.csv, parse_dates[date]) # 按门店 SKU 日期聚合补全缺失日期为 0 销量 def build_series(group): group group.set_index(date).sort_index() full_idx pd.date_range(group.index.min(), group.index.max(), freqD) group group.reindex(full_idx, fill_value0) group[promo] group[promo].fillna(0).astype(int) group[stockout] group[stockout].fillna(0).astype(int) return group records [] for (store, sku), g in df.groupby([store_id, sku_id]): g build_series(g) if len(g) 35: # 历史太短跳过 continue for i in range(28, len(g) - 7): hist g.iloc[i-28:i] fut g.iloc[i:i7] prompt ( f门店 {store} 的 SKU {sku}过去28天日销为 f{hist[qty].tolist()}促销标记 {hist[promo].tolist()} f缺货标记 {hist[stockout].tolist()}。 f未来7天促销计划为 {fut[promo].tolist()}。 f请预测未来7天日销量。 ) answer json.dumps({pred: fut[qty].tolist()}, ensure_asciiFalse) records.append({instruction: prompt, output: answer}) with open(train.jsonl, w, encodingutf-8) as f: for r in records: f.write(json.dumps(r, ensure_asciiFalse) \n) print(样本数:, len(records))逻辑说明build_series负责把不连续的交易日期补成连续日序列缺货日销量记 0 但保留stockout标记避免模型把缺货误判成「卖不动」。i的循环范围保证每条样本都有完整 28 天历史和 7 天标签。prompt里把数值列表直接展开DeepSeek-R1-Distill 对数字列表的解析能力比想象中好但列表长度要固定不能今天 28 天明天 30 天。参数说明观察窗口 28 天是零售场景的常见选择覆盖四个完整周能捕捉周内周期预测窗口 7 天对应补货周期。如果 SKU 补货周期是 14 天预测窗口要相应拉长但样本数会减少需要权衡。len(g) 35这个阈值保证至少能切出一条样本历史太短的 SKU 建议单独走规则补货不要硬塞进模型。2.3 数据质量检查三个必须看的分布样本生成后别急着开训先看三个分布。第一日销量的零值比例如果超过 70% 是零说明大量 SKU 是长尾慢销模型会倾向于全预测零。第二促销标记的覆盖率如果促销样本占比低于 5%模型学不到促销对销量的拉升。第三预测窗口的销量方差方差过大的 SKU 建议做对数变换或分桶否则损失函数会被少数爆款主导。我一般会跑一段简单的统计脚本把零值比例、促销占比、销量分位数打出来。如果零值比例过高考虑把慢销 SKU 合并成「品类级」预测而不是逐个 SKU 建模。这一步不做后面微调 loss 降得再低业务指标也不会好看。3. LoRA 微调 DeepSeek-R1-Distill显存、秩和学习率的实际取值3.1 为什么选 LoRA 而不是全量微调DeepSeek-R1-Distill 即使是最小的蒸馏版本全量微调对显存的要求也不是普通团队能轻松满足的。LoRA 的思路是在注意力层的权重矩阵旁挂两个低秩矩阵训练时只更新这两个小矩阵原模型权重冻结。好处是显存占用大幅下降训练完只需要保存几十 MB 的适配器推理时合并回原模型即可。在库存预测这种垂直场景LoRA 的秩rank不需要设太大。我试过 r8 和 r16在样本量几万条的量级下r8 已经能拟合得不错r16 提升有限但显存和训练时间增加。lora_alpha一般设成 r 的两倍lora_dropout设 0.05 到 0.1防止小样本过拟合。目标模块的选择上常见做法是只挂q_proj和v_proj这两个矩阵对语义和数值模式的捕捉最直接。如果显存允许加上k_proj和o_proj会更稳但收益递减。库存预测的输入里有大量数字列表注意力模式比较固定不需要挂太多模块。3.2 训练配置一份可以直接改的 LoRA 微调脚本下面用 HuggingFace 的peft和transformers写一个最小训练循环。假设模型已经下载到本地路径数据是上一步生成的 JSONL。import torch from datasets import load_dataset from transformers import AutoTokenizer, AutoModelForCausalLM, TrainingArguments, Trainer from peft import LoraConfig, get_peft_model model_path ./DeepSeek-R1-Distill-Qwen-1.5B # 按实际路径改 tokenizer AutoTokenizer.from_pretrained(model_path, trust_remote_codeTrue) model AutoModelForCausalLM.from_pretrained( model_path, torch_dtypetorch.bfloat16, device_mapauto, trust_remote_codeTrue ) 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) model.print_trainable_parameters() dataset load_dataset(json, data_filestrain.jsonl, splittrain) def tokenize(example): text f### 指令\n{example[instruction]}\n### 回答\n{example[output]} out tokenizer(text, truncationTrue, max_length1024, paddingmax_length) out[labels] out[input_ids].copy() return out dataset dataset.map(tokenize, remove_columnsdataset.column_names) args TrainingArguments( output_dir./lora_out, per_device_train_batch_size2, gradient_accumulation_steps8, num_train_epochs3, learning_rate2e-4, bf16True, logging_steps20, save_steps200, warmup_ratio0.03, lr_scheduler_typecosine ) trainer Trainer(modelmodel, argsargs, train_datasetdataset) trainer.train() model.save_pretrained(./lora_adapter)逻辑说明tokenize把指令和回答拼成一条完整文本labels直接复制input_ids这是因果语言模型的标准做法。max_length1024要覆盖 28 天历史加 7 天预测的文本长度如果样本更长需要调大但显存也会涨。gradient_accumulation_steps8配合batch_size2等效 batch 是 16小显存机器靠这个把 batch 撑起来。参数说明learning_rate2e-4是 LoRA 微调的常见起点比全量微调大一个量级因为可训练参数少。如果 loss 震荡降到 1e-4如果 loss 几乎不降升到 3e-4 试试。num_train_epochs3在几万条样本下通常够超过 5 轮容易过拟合表现为训练 loss 降但验证集预测偏差变大。bf16比fp16更稳前提是显卡支持。3.3 显存不够时的三个降级手段如果 24G 显存跑 1.5B 模型加 LoRA 还是吃紧按顺序试这三招。第一把per_device_train_batch_size降到 1gradient_accumulation_steps翻倍等效 batch 不变但峰值显存下降。第二开启 gradient checkpointing用时间换显存训练速度会慢 20% 到 30%。第三缩短max_length把 28 天历史压缩成统计特征均值、方差、趋势斜率而不是原始列表文本长度能砍掉一半以上。这三招里第三招对预测精度影响最大因为模型丢失了日粒度的波动信息。我的建议是优先用前两招实在不行再考虑特征压缩。库存预测里「哪一天突然放量」这种信息压缩成均值就没了模型只能学到平滑趋势。4. 预测结果怎么验证别只看 loss要看补货指标4.1 离线指标MAE、WMAPE 和分位数覆盖训练 loss 降了不代表业务能用。库存预测的离线评估至少看三个指标。MAE 是平均绝对误差直观但会被大销量 SKU 主导。WMAPE 是加权平均绝对百分比误差按销量加权更贴近「整体预测准不准」。分位数覆盖看的是预测区间如果你输出的是 P50 和 P90要检查真实值落在 P90 以下的比例是不是接近 90%。我一般会在验证集上同时算这三个并且按 SKU 分层看。快销 SKU 的 WMAPE 通常能压到 20% 以内慢销 SKU 因为零值多WMAPE 会很难看这时候要看的是「是否预测为零」的分类准确率而不是回归误差。4.2 业务指标从预测值到补货量的换算预测出未来 7 天日销后补货量 预测总销量 安全库存 - 当前库存。安全库存通常按预测误差的标准差乘以服务水平系数。这一步是把模型输出翻译成业务动作也是验证模型是否可用的最后一关。常见做法是拿模型预测和现有补货规则做 A/B 对比看缺货率和库存周转天数有没有改善。如果模型预测更准但补货量没变说明安全库存系数设得太保守模型的价值被吃掉了。这时候要回头调系数而不是怀疑模型。4.3 推理部署合并 LoRA 适配器并批量预测训练完的适配器要合并回原模型才能高效推理否则每次前向都要算 LoRA 分支延迟翻倍。from peft import PeftModel from transformers import AutoModelForCausalLM, AutoTokenizer base AutoModelForCausalLM.from_pretrained( ./DeepSeek-R1-Distill-Qwen-1.5B, torch_dtypeauto, device_mapauto ) model PeftModel.from_pretrained(base, ./lora_adapter) model model.merge_and_unload() model.save_pretrained(./merged_model) tokenizer AutoTokenizer.from_pretrained(./DeepSeek-R1-Distill-Qwen-1.5B) tokenizer.save_pretrained(./merged_model)合并后模型就是一个普通因果语言模型可以用 vLLM 或 TGI 做批量推理。库存预测的请求是批量生成的建议把同一门店的多个 SKU 拼成一个 batch提高吞吐。注意生成时用do_sampleFalse预测任务要确定性输出不要采样。5. 避坑与排查DeepSeek-R1-Distill 微调库存预测的五个翻车现场5.1 现象模型对所有 SKU 都预测同一个值原因样本里数值列表没有归一化不同 SKU 销量量级差异大模型学到的是「输出一个中间值最安全」。解决按 SKU 历史均值做归一化预测时再反归一化或者在 prompt 里显式给出该 SKU 的历史均值和方差让模型有条件地输出。5.2 现象训练 loss 正常下降但验证集预测全是零原因零值样本占比过高模型发现全预测零的 loss 也不差。解决对零值样本做下采样或者在损失函数里给非零样本更高权重。更彻底的做法是把预测目标改成「是否补货」的分类加「补多少」的回归两阶段。5.3 现象显存溢出报错出现在 backward 阶段原因max_length设太大或者 batch 里混入了超长样本。解决先统计样本长度分布把超过 95 分位的截断开启 gradient checkpointing把 batch size 降到 1 并增加梯度累积。5.4 现象合并 LoRA 后推理结果和训练时不一致原因训练时用了 padding推理时没对齐或者 tokenizer 的 chat 模板不一致。解决推理时严格复用训练时的拼接格式包括### 指令和### 回答标记检查 tokenizer 是否在合并后重新加载了正确的版本。5.5 现象预测值合理但补货建议离谱原因安全库存系数没有随预测误差调整或者当前库存数据没对齐时间戳。解决把安全库存系数做成按 SKU 分层的参数快销 SKU 系数低、慢销 SKU 系数高补货计算前先校验库存快照的日期避免用上周的库存算今天的补货。6. 把预测误差变成补货缓冲一个按 SKU 分层设安全库存的小技巧微调跑通只是第一步真正让业务方觉得「这个模型有用」的是补货建议的稳定性。我踩过最大的坑是模型预测精度提升了但补货量波动反而变大店长不敢用。后来发现问题是安全库存系数一刀切快销 SKU 和慢销 SKU 用同一个系数慢销 SKU 的预测误差本来就大系数一乘补货量忽高忽低。我的做法是按 SKU 的历史 WMAPE 分三档设安全库存系数。WMAPE 低于 25% 的系数设 1.025% 到 50% 的系数设 1.3高于 50% 的系数设 1.6并且强制走人工复核。这个分层不需要复杂计算用验证集上的 WMAPE 就能分。分层WMAPE 范围安全库存系数补货动作稳定 25%1.0自动补货一般25% - 50%1.3自动补货日报监控波动 50%1.6人工复核后补货另一个技巧是给预测值加一个「趋势修正」。DeepSeek-R1-Distill 输出的日销列表有时偏平滑对突然的促销拉升反应不足。我会在推理后做一个简单后处理如果未来 7 天里有促销标记把对应天的预测值乘以一个从历史促销样本里学到的拉升系数。这个系数不用模型学直接从数据里统计「促销日均销 / 非促销日均销」得到简单但有效。验证这个方案是否值得投入就看两个数缺货率有没有下降库存周转天数有没有下降。如果两个都降说明模型加分层策略跑通了如果缺货率降但周转天数涨说明安全库存设太保守往下调系数如果两个都没变先检查预测值有没有真正进入补货计算链路很多时候是模型输出了但业务系统没用上。我自己现在跑这类项目的习惯是先跑一版最简 LoRAr8、3 轮、学习率 2e-4拿到基线 WMAPE再根据分层结果决定要不要加数据、调秩、换目标模块。不要一上来就追求最优参数库存预测的瓶颈通常在数据质量和业务对齐不在模型结构。希望帮到你。本文还有配套的精品资源点击获取 DeepSeek-R1-Distill微调实战：零售库存预测从数据构造到LoRA部署
简介这份PDF面向零售业数据分析师、算法工程师及希望将大模型落地到业务场景的技术人员聚焦如何用DeepSeek-R1-Distill完成低成本库存预测微调。内容从库存管理痛点切入系统讲解模型架构、数据收集与清洗、特征工程再到冻结部分模型层、小批量训练、学习率调整与数据增强等低成本微调策略并给出环境搭建、模型加载、训练循环、评估指标选择与超参数优化的完整实战步骤最后以零售企业案例串联全流程。资源包共1个PDF文件大小约1.86MB21页篇幅目录与图表显示正常结构清晰便于按章节查阅。目前已有102人学习。读者可借此掌握从数据准备到模型评估的落地方法理解低成本微调在库存预测中的适用边界并获得可复用的代码实现思路与调优经验。1. 零售库存预测为什么盯上了 DeepSeek-R1-Distill从「拍脑袋补货」到「按天算量」做零售运营的人都有一个共同的痛门店 SKU 动辄上千历史销量、促销日历、节假日、天气、竞品调价全搅在一起靠 Excel 拉个移动平均根本压不住波动。补多了压资金补少了断货丢单店长每天在「多订两箱」和「再等等看」之间反复横跳。库存预测这件事本质是把「下周这个 SKU 大概卖多少」变成一个可量化、可复现、可迭代的数值问题而不是靠老店长的直觉。大模型微调实战这两年从 NLP 圈一路烧到零售场景DeepSeek-R1-Distill 系列因为蒸馏后推理成本低、中文理解稳成了不少团队做垂直微调的首选底座。它不是一个「万能预测器」而是一个能把结构化时序特征、文本型业务规则、促销说明一起读进去的推理引擎。你给它一段「过去 28 天日销 未来 7 天促销计划 门店等级」的描述它能输出一个带解释的预测量区间这比单纯跑 ARIMA 或 Prophet 更贴近业务语言。这篇文章面向的是手里有销售流水、想用低成本方式跑通库存预测微调的工程师和数据分析师。不追求刷榜追求的是一张消费级显卡或一台带 24G 显存的机器能把 DeepSeek-R1-Distill 微调到一个「比基线模型明显好、业务方愿意看」的水平。下面从数据构造、LoRA 微调、参数设置到踩坑排查一步步拆开讲。2. 把销售流水变成微调样本DeepSeek-R1-Distill 的数据构造与格式对齐2.1 为什么库存预测不能直接拿原始流水喂模型原始 POS 流水是「一行一单」的明细字段包括时间戳、门店 ID、SKU、销量、单价、促销标记。直接把它塞进模型等于让模型在噪声里自己找规律效果极不稳定。常见做法是先做时间窗聚合把每个「门店 × SKU」按天汇总成一条时序记录再往前切一个观察窗口、往后切一个预测窗口。我一般会构造这样的样本观察窗口取过去 28 天预测窗口取未来 7 天。观察窗口里保留日销量、是否促销、是否周末、是否有缺货标记预测窗口里保留未来 7 天的促销计划、节假日标记。模型要学的不是「记住某个 SKU 卖多少」而是「给定这段历史和未来事件未来 7 天日销大概是什么形状」。这里有个关键取舍DeepSeek-R1-Distill 是语言模型不是纯时序模型。它的优势在于能读文本规则所以样本里要保留一部分自然语言描述比如「该门店位于社区周末客流集中」「该 SKU 属于低温短保补货周期 2 天」。这些文本和数值特征拼在一起才是蒸馏模型能发挥的地方。2.2 样本构造脚本从 CSV 到 JSONL 的最小可跑流程下面这段代码做三件事读销售流水、按门店和 SKU 聚合、生成带指令和回答的 JSONL 样本。依赖 pandas不需要额外框架。import pandas as pd import json from datetime import timedelta # 读取原始流水字段示例date, store_id, sku_id, qty, promo, stockout df pd.read_csv(sales_raw.csv, parse_dates[date]) # 按门店 SKU 日期聚合补全缺失日期为 0 销量 def build_series(group): group group.set_index(date).sort_index() full_idx pd.date_range(group.index.min(), group.index.max(), freqD) group group.reindex(full_idx, fill_value0) group[promo] group[promo].fillna(0).astype(int) group[stockout] group[stockout].fillna(0).astype(int) return group records [] for (store, sku), g in df.groupby([store_id, sku_id]): g build_series(g) if len(g) 35: # 历史太短跳过 continue for i in range(28, len(g) - 7): hist g.iloc[i-28:i] fut g.iloc[i:i7] prompt ( f门店 {store} 的 SKU {sku}过去28天日销为 f{hist[qty].tolist()}促销标记 {hist[promo].tolist()} f缺货标记 {hist[stockout].tolist()}。 f未来7天促销计划为 {fut[promo].tolist()}。 f请预测未来7天日销量。 ) answer json.dumps({pred: fut[qty].tolist()}, ensure_asciiFalse) records.append({instruction: prompt, output: answer}) with open(train.jsonl, w, encodingutf-8) as f: for r in records: f.write(json.dumps(r, ensure_asciiFalse) \n) print(样本数:, len(records))逻辑说明build_series负责把不连续的交易日期补成连续日序列缺货日销量记 0 但保留stockout标记避免模型把缺货误判成「卖不动」。i的循环范围保证每条样本都有完整 28 天历史和 7 天标签。prompt里把数值列表直接展开DeepSeek-R1-Distill 对数字列表的解析能力比想象中好但列表长度要固定不能今天 28 天明天 30 天。参数说明观察窗口 28 天是零售场景的常见选择覆盖四个完整周能捕捉周内周期预测窗口 7 天对应补货周期。如果 SKU 补货周期是 14 天预测窗口要相应拉长但样本数会减少需要权衡。len(g) 35这个阈值保证至少能切出一条样本历史太短的 SKU 建议单独走规则补货不要硬塞进模型。2.3 数据质量检查三个必须看的分布样本生成后别急着开训先看三个分布。第一日销量的零值比例如果超过 70% 是零说明大量 SKU 是长尾慢销模型会倾向于全预测零。第二促销标记的覆盖率如果促销样本占比低于 5%模型学不到促销对销量的拉升。第三预测窗口的销量方差方差过大的 SKU 建议做对数变换或分桶否则损失函数会被少数爆款主导。我一般会跑一段简单的统计脚本把零值比例、促销占比、销量分位数打出来。如果零值比例过高考虑把慢销 SKU 合并成「品类级」预测而不是逐个 SKU 建模。这一步不做后面微调 loss 降得再低业务指标也不会好看。3. LoRA 微调 DeepSeek-R1-Distill显存、秩和学习率的实际取值3.1 为什么选 LoRA 而不是全量微调DeepSeek-R1-Distill 即使是最小的蒸馏版本全量微调对显存的要求也不是普通团队能轻松满足的。LoRA 的思路是在注意力层的权重矩阵旁挂两个低秩矩阵训练时只更新这两个小矩阵原模型权重冻结。好处是显存占用大幅下降训练完只需要保存几十 MB 的适配器推理时合并回原模型即可。在库存预测这种垂直场景LoRA 的秩rank不需要设太大。我试过 r8 和 r16在样本量几万条的量级下r8 已经能拟合得不错r16 提升有限但显存和训练时间增加。lora_alpha一般设成 r 的两倍lora_dropout设 0.05 到 0.1防止小样本过拟合。目标模块的选择上常见做法是只挂q_proj和v_proj这两个矩阵对语义和数值模式的捕捉最直接。如果显存允许加上k_proj和o_proj会更稳但收益递减。库存预测的输入里有大量数字列表注意力模式比较固定不需要挂太多模块。3.2 训练配置一份可以直接改的 LoRA 微调脚本下面用 HuggingFace 的peft和transformers写一个最小训练循环。假设模型已经下载到本地路径数据是上一步生成的 JSONL。import torch from datasets import load_dataset from transformers import AutoTokenizer, AutoModelForCausalLM, TrainingArguments, Trainer from peft import LoraConfig, get_peft_model model_path ./DeepSeek-R1-Distill-Qwen-1.5B # 按实际路径改 tokenizer AutoTokenizer.from_pretrained(model_path, trust_remote_codeTrue) model AutoModelForCausalLM.from_pretrained( model_path, torch_dtypetorch.bfloat16, device_mapauto, trust_remote_codeTrue ) 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) model.print_trainable_parameters() dataset load_dataset(json, data_filestrain.jsonl, splittrain) def tokenize(example): text f### 指令\n{example[instruction]}\n### 回答\n{example[output]} out tokenizer(text, truncationTrue, max_length1024, paddingmax_length) out[labels] out[input_ids].copy() return out dataset dataset.map(tokenize, remove_columnsdataset.column_names) args TrainingArguments( output_dir./lora_out, per_device_train_batch_size2, gradient_accumulation_steps8, num_train_epochs3, learning_rate2e-4, bf16True, logging_steps20, save_steps200, warmup_ratio0.03, lr_scheduler_typecosine ) trainer Trainer(modelmodel, argsargs, train_datasetdataset) trainer.train() model.save_pretrained(./lora_adapter)逻辑说明tokenize把指令和回答拼成一条完整文本labels直接复制input_ids这是因果语言模型的标准做法。max_length1024要覆盖 28 天历史加 7 天预测的文本长度如果样本更长需要调大但显存也会涨。gradient_accumulation_steps8配合batch_size2等效 batch 是 16小显存机器靠这个把 batch 撑起来。参数说明learning_rate2e-4是 LoRA 微调的常见起点比全量微调大一个量级因为可训练参数少。如果 loss 震荡降到 1e-4如果 loss 几乎不降升到 3e-4 试试。num_train_epochs3在几万条样本下通常够超过 5 轮容易过拟合表现为训练 loss 降但验证集预测偏差变大。bf16比fp16更稳前提是显卡支持。3.3 显存不够时的三个降级手段如果 24G 显存跑 1.5B 模型加 LoRA 还是吃紧按顺序试这三招。第一把per_device_train_batch_size降到 1gradient_accumulation_steps翻倍等效 batch 不变但峰值显存下降。第二开启 gradient checkpointing用时间换显存训练速度会慢 20% 到 30%。第三缩短max_length把 28 天历史压缩成统计特征均值、方差、趋势斜率而不是原始列表文本长度能砍掉一半以上。这三招里第三招对预测精度影响最大因为模型丢失了日粒度的波动信息。我的建议是优先用前两招实在不行再考虑特征压缩。库存预测里「哪一天突然放量」这种信息压缩成均值就没了模型只能学到平滑趋势。4. 预测结果怎么验证别只看 loss要看补货指标4.1 离线指标MAE、WMAPE 和分位数覆盖训练 loss 降了不代表业务能用。库存预测的离线评估至少看三个指标。MAE 是平均绝对误差直观但会被大销量 SKU 主导。WMAPE 是加权平均绝对百分比误差按销量加权更贴近「整体预测准不准」。分位数覆盖看的是预测区间如果你输出的是 P50 和 P90要检查真实值落在 P90 以下的比例是不是接近 90%。我一般会在验证集上同时算这三个并且按 SKU 分层看。快销 SKU 的 WMAPE 通常能压到 20% 以内慢销 SKU 因为零值多WMAPE 会很难看这时候要看的是「是否预测为零」的分类准确率而不是回归误差。4.2 业务指标从预测值到补货量的换算预测出未来 7 天日销后补货量 预测总销量 安全库存 - 当前库存。安全库存通常按预测误差的标准差乘以服务水平系数。这一步是把模型输出翻译成业务动作也是验证模型是否可用的最后一关。常见做法是拿模型预测和现有补货规则做 A/B 对比看缺货率和库存周转天数有没有改善。如果模型预测更准但补货量没变说明安全库存系数设得太保守模型的价值被吃掉了。这时候要回头调系数而不是怀疑模型。4.3 推理部署合并 LoRA 适配器并批量预测训练完的适配器要合并回原模型才能高效推理否则每次前向都要算 LoRA 分支延迟翻倍。from peft import PeftModel from transformers import AutoModelForCausalLM, AutoTokenizer base AutoModelForCausalLM.from_pretrained( ./DeepSeek-R1-Distill-Qwen-1.5B, torch_dtypeauto, device_mapauto ) model PeftModel.from_pretrained(base, ./lora_adapter) model model.merge_and_unload() model.save_pretrained(./merged_model) tokenizer AutoTokenizer.from_pretrained(./DeepSeek-R1-Distill-Qwen-1.5B) tokenizer.save_pretrained(./merged_model)合并后模型就是一个普通因果语言模型可以用 vLLM 或 TGI 做批量推理。库存预测的请求是批量生成的建议把同一门店的多个 SKU 拼成一个 batch提高吞吐。注意生成时用do_sampleFalse预测任务要确定性输出不要采样。5. 避坑与排查DeepSeek-R1-Distill 微调库存预测的五个翻车现场5.1 现象模型对所有 SKU 都预测同一个值原因样本里数值列表没有归一化不同 SKU 销量量级差异大模型学到的是「输出一个中间值最安全」。解决按 SKU 历史均值做归一化预测时再反归一化或者在 prompt 里显式给出该 SKU 的历史均值和方差让模型有条件地输出。5.2 现象训练 loss 正常下降但验证集预测全是零原因零值样本占比过高模型发现全预测零的 loss 也不差。解决对零值样本做下采样或者在损失函数里给非零样本更高权重。更彻底的做法是把预测目标改成「是否补货」的分类加「补多少」的回归两阶段。5.3 现象显存溢出报错出现在 backward 阶段原因max_length设太大或者 batch 里混入了超长样本。解决先统计样本长度分布把超过 95 分位的截断开启 gradient checkpointing把 batch size 降到 1 并增加梯度累积。5.4 现象合并 LoRA 后推理结果和训练时不一致原因训练时用了 padding推理时没对齐或者 tokenizer 的 chat 模板不一致。解决推理时严格复用训练时的拼接格式包括### 指令和### 回答标记检查 tokenizer 是否在合并后重新加载了正确的版本。5.5 现象预测值合理但补货建议离谱原因安全库存系数没有随预测误差调整或者当前库存数据没对齐时间戳。解决把安全库存系数做成按 SKU 分层的参数快销 SKU 系数低、慢销 SKU 系数高补货计算前先校验库存快照的日期避免用上周的库存算今天的补货。6. 把预测误差变成补货缓冲一个按 SKU 分层设安全库存的小技巧微调跑通只是第一步真正让业务方觉得「这个模型有用」的是补货建议的稳定性。我踩过最大的坑是模型预测精度提升了但补货量波动反而变大店长不敢用。后来发现问题是安全库存系数一刀切快销 SKU 和慢销 SKU 用同一个系数慢销 SKU 的预测误差本来就大系数一乘补货量忽高忽低。我的做法是按 SKU 的历史 WMAPE 分三档设安全库存系数。WMAPE 低于 25% 的系数设 1.025% 到 50% 的系数设 1.3高于 50% 的系数设 1.6并且强制走人工复核。这个分层不需要复杂计算用验证集上的 WMAPE 就能分。分层WMAPE 范围安全库存系数补货动作稳定 25%1.0自动补货一般25% - 50%1.3自动补货日报监控波动 50%1.6人工复核后补货另一个技巧是给预测值加一个「趋势修正」。DeepSeek-R1-Distill 输出的日销列表有时偏平滑对突然的促销拉升反应不足。我会在推理后做一个简单后处理如果未来 7 天里有促销标记把对应天的预测值乘以一个从历史促销样本里学到的拉升系数。这个系数不用模型学直接从数据里统计「促销日均销 / 非促销日均销」得到简单但有效。验证这个方案是否值得投入就看两个数缺货率有没有下降库存周转天数有没有下降。如果两个都降说明模型加分层策略跑通了如果缺货率降但周转天数涨说明安全库存设太保守往下调系数如果两个都没变先检查预测值有没有真正进入补货计算链路很多时候是模型输出了但业务系统没用上。我自己现在跑这类项目的习惯是先跑一版最简 LoRAr8、3 轮、学习率 2e-4拿到基线 WMAPE再根据分层结果决定要不要加数据、调秩、换目标模块。不要一上来就追求最优参数库存预测的瓶颈通常在数据质量和业务对齐不在模型结构。希望帮到你。本文还有配套的精品资源点击获取