简介这份PDF面向零售行业数据分析师、算法工程师及希望将大模型落地业务的技术人员聚焦库存预测这一核心场景讲解如何以低成本方式微调DeepSeek-R1-Distill模型。资源包仅含1个PDF文件大小约1.86MB内容完整、图表与目录显示正常便于直接查阅。文档共21页从零售库存管理的痛点切入依次覆盖模型架构原理、数据收集与清洗、特征工程、冻结部分模型层、小批量训练与学习率调整、数据增强与采样策略并给出环境搭建、模型加载、训练循环、评估指标选择与超参数优化的完整实战路径最后以零售企业案例串联全流程。已有102人学习适合想用有限算力完成垂直领域微调、提升库存预测精度的读者参考。1. 零售库存预测为什么盯上了 DeepSeek-R1-Distill 微调零售库存预测这件事说到底是把「下周这家店这款 SKU 能卖多少」算准。传统做法是时序模型加人工规则遇到促销、换季、上新就集体翻车运营只能靠经验拍脑袋补货结果一边压货一边缺货。DeepSeek-R1-Distill 这类蒸馏推理模型出现后思路变了把历史销量、价格、促销、天气、节假日这些结构化字段拼成一段文本让模型直接输出预测值和补货建议再用门店真实数据做一次低成本微调让它学会自家商品体系的说话方式。这篇讲的就是这条路径怎么落地为什么选蒸馏版而不是满血版LoRA 微调怎么配数据怎么造显存怎么省推理怎么接进补货流程。适合手里有几千到几万条门店销量记录、想用大模型微调实战替代规则引擎的算法和供应链工程师。不追求刷榜追求的是能跑起来、能复现、能进生产。2. 选型DeepSeek-R1-Distill 与 LoRA 微调实战的匹配逻辑2.1 为什么蒸馏版比满血版更适合库存场景库存预测的输入是结构化数字加少量文本描述输出是数值加简短理由任务本身不需要模型有极强的开放推理能力。满血版参数大、显存吃紧、推理延迟高放进每天要跑几千次的门店补货流程里成本直接失控。DeepSeek-R1-Distill 把推理链蒸馏进小参数模型保留了「先想再答」的结构同时把显存和延迟压到单卡可承受的范围。我一般会先确认三件事单店 SKU 数量、预测频率、可接受的单次推理延迟。如果 SKU 在几百以内、每天跑一次蒸馏版加 LoRA 完全够用如果 SKU 上万、要实时算就得考虑批量推理和缓存。选型不是看模型多大而是看任务需不需要那么大的脑子。另一个理由是微调成本。全量微调要更新所有参数显存和训练时间都翻倍LoRA 只训练低秩矩阵显存占用能降一个量级几百条到几千条样本就能看到效果。库存数据本身噪声大全量微调容易过拟合到某几个促销日LoRA 的低秩约束反而更稳。2.2 LoRA 微调的关键参数怎么定LoRA 的核心参数是秩 r、alpha、dropout 和目标模块。库存预测任务里我一般从 r8 或 r16 起步alpha 取 r 的两倍dropout 0.05 到 0.1。目标模块优先选 q_proj 和 v_proj这两个注意力投影对数值模式的捕捉最敏感如果数据里文本描述多再加 k_proj 和 o_proj。下面是一段用 transformers peft 配置 LoRA 的代码直接可抄from transformers import AutoModelForCausalLM, AutoTokenizer from peft import LoraConfig, get_peft_model, TaskType model_name deepseek-ai/DeepSeek-R1-Distill-Qwen-1.5B tokenizer AutoTokenizer.from_pretrained(model_name, trust_remote_codeTrue) model AutoModelForCausalLM.from_pretrained( model_name, torch_dtypeauto, device_mapauto, trust_remote_codeTrue ) lora_config LoraConfig( task_typeTaskType.CAUSAL_LM, r16, # 秩库存任务 8~16 足够 lora_alpha32, # 一般取 r 的 2 倍 lora_dropout0.05, # 防过拟合数据少时调到 0.1 target_modules[q_proj, v_proj], # 先只调注意力投影 biasnone ) model get_peft_model(model, lora_config) model.print_trainable_parameters()逻辑说明r决定低秩矩阵的容量库存数据模式相对固定r 太大反而学进噪声lora_alpha控制更新幅度和 r 配合使用target_modules决定挂载位置先小范围试效果不够再扩。跑完print_trainable_parameters()你会看到可训练参数只占总参数的百分之几这就是低成本微调的来源。参数不是拍死的。如果验证集 loss 震荡先把 dropout 提到 0.1如果欠拟合把 r 提到 32 并同步把 alpha 提到 64。每次只动一个变量记录验证集表现别一次改一堆。2.3 训练超参学习率、批次与梯度累积学习率我一般用 1e-4 到 2e-4配合 cosine 调度和 warmup。批次大小受显存限制单卡 24G 跑 1.5B 模型per_device_train_batch_size 设 2 到 4再用 gradient_accumulation_steps 累积到等效批次 16 或 32。这样既稳住梯度又不爆显存。from transformers import TrainingArguments, Trainer training_args TrainingArguments( output_dir./inventory_lora_out, per_device_train_batch_size2, gradient_accumulation_steps8, # 等效批次 16 learning_rate1.5e-4, num_train_epochs3, lr_scheduler_typecosine, warmup_ratio0.03, logging_steps10, save_strategyepoch, fp16True, # 有 bf16 优先用 bf16 report_tonone )gradient_accumulation_steps是显存不够时的后悔药等效批次上去了显存占用没上去。fp16在支持 bf16 的卡上换成bf16True更稳数值范围大不容易溢出。epoch 不要多库存数据重复训练三轮以上就开始背答案验证集 loss 会先降后升看到回升就停。3. 数据把门店销量表变成模型能吃的指令样本3.1 库存预测样本的字段设计与构造模型不会自己读数据库得把每条销量记录转成「指令 输入 输出」的文本。输入侧我一般保留门店 ID、SKU ID、品类、过去 N 天销量、当前库存、在途库存、价格、是否促销、节假日标记、天气。输出侧是未来 7 天预测销量和补货建议。N 取 14 或 28太短抓不到周期太长噪声多。构造脚本核心是把宽表拍成 JSONLimport pandas as pd, json def build_sample(row): prompt ( f门店{row[store_id]}的SKU {row[sku_id]}{row[category]} f过去14天销量{row[sales_14d]}当前库存{row[stock]} f在途{row[in_transit]}售价{row[price]}元 f促销{row[promo]}节假日{row[holiday]}天气{row[weather]}。 f请预测未来7天销量并给出补货建议。 ) answer ( f未来7天预测销量{row[sales_next7]} f建议补货{row[replenish]}件理由{row[reason]}。 ) return {instruction: prompt, output: answer} df pd.read_csv(store_sales.csv) with open(inventory_train.jsonl, w, encodingutf-8) as f: for _, row in df.iterrows(): f.write(json.dumps(build_sample(row), ensure_asciiFalse) \n)逻辑说明instruction是模型看到的全部上下文字段顺序固定训练和推理必须一致否则线上效果会掉。output里把预测值、补货量、理由都写进去让模型学会「给数也给解释」。reason字段可以来自运营标注也可以由规则生成早期没有标注就用「库存低于预测销量」这类模板先跑通。参数上sales_14d建议存成逗号分隔的序列而不是单个汇总值模型对序列模式的捕捉比汇总值强。promo、holiday用 0/1weather用枚举字符串。字段名不要用中文避免 tokenizer 切分不稳定。3.2 数据清洗与类别不平衡的处理零售数据最大的坑是长尾少数爆款占大部分销量大量 SKU 一周卖不出几件。直接训练模型会偏向预测热门品冷门品全预测成零。处理办法有三步一是对销量做分层采样保证冷门 SKU 在训练集里有足够样本二是对预测目标做对数变换再还原压住极端值三是把「零销量」样本单独抽一部分让模型学会识别真正的滞销。清洗时重点看三类异常促销日销量突增、缺货日销量被截断、退货导致的负值。促销日样本要保留但打上标记缺货日样本要么剔除要么把销量补成预估需求负值直接清零。这些处理不写进代码块但每一步都要在数据管道里留日志否则出了问题查不到源头。样本量方面我一般建议每个品类至少 500 条有效样本再开训总量几千条就能看到 LoRA 的效果。数据太少时先把 r 降到 8、dropout 提到 0.1别急着加 epoch。4. 训练与推理从单卡跑通到接进补货流程4.1 单卡训练的最小命令与显存观察数据准备好后用 Trainer 或 trl 的 SFTTrainer 都能跑。我习惯先用小样本比如 200 条跑 10 步确认 loss 在降、显存没爆再上全量。启动命令python train_lora.py \ --model_name deepseek-ai/DeepSeek-R1-Distill-Qwen-1.5B \ --data_path inventory_train.jsonl \ --output_dir ./inventory_lora_out \ --per_device_train_batch_size 2 \ --gradient_accumulation_steps 8 \ --learning_rate 1.5e-4 \ --num_train_epochs 3 \ --fp16跑起来后用nvidia-smi -l 2盯显存正常情况 1.5B 模型加 LoRA 在 24G 卡上占用 10G 到 14G。如果 OOM先降 batch size再开 gradient checkpointing最后才考虑换更小的模型。训练日志里重点看 loss 曲线和 grad_normgrad_norm 突然飙高说明学习率太大或数据里有异常样本。4.2 推理接入批量预测与结果校验训练完把 LoRA 权重合并或直接加载适配器做推理。库存场景是批量任务不要一条条调要拼 batch。下面是最小推理代码from peft import PeftModel from transformers import AutoModelForCausalLM, AutoTokenizer import torch base AutoModelForCausalLM.from_pretrained( deepseek-ai/DeepSeek-R1-Distill-Qwen-1.5B, torch_dtypetorch.float16, device_mapauto ) model PeftModel.from_pretrained(base, ./inventory_lora_out) tokenizer AutoTokenizer.from_pretrained(deepseek-ai/DeepSeek-R1-Distill-Qwen-1.5B) prompts [门店S001的SKU A123饮料过去14天销量...] inputs tokenizer(prompts, return_tensorspt, paddingTrue).to(model.device) with torch.no_grad(): outputs model.generate(**inputs, max_new_tokens128, do_sampleFalse) print(tokenizer.batch_decode(outputs, skip_special_tokensTrue))do_sampleFalse保证输出稳定库存预测不需要多样性。max_new_tokens控制输出长度128 够放预测值和理由。推理结果不能直接进补货系统要加一层校验预测值是否在合理区间、补货量是否超过仓容、是否和人工规则冲突。校验不过的样本回流到训练集形成闭环。批量推理时注意 padding 侧和 attention mask左侧 padding 对生成任务更友好。如果延迟要求高可以把模型转成量化版本但量化后要重新验证预测偏差别直接上线。5. 避坑库存微调里最容易翻车的五件事现象训练 loss 一直降验证集预测全是同一个值。原因数据里某个字段比如门店 ID被模型当成了捷径或者输出格式太单一。解决检查输入字段是否泄露了答案打乱样本顺序输出里增加理由的多样性必要时对字段做随机遮蔽增强。现象线上预测比线下差一大截。原因训练样本的字段顺序、单位、缺失值处理和线上不一致。解决把数据构造逻辑封装成同一个函数训练和推理共用上线前用同一批样本对比线下线上输出。现象显存够但训练极慢。原因没开 fp16/bf16或者 dataloader 的 num_workers 设成 0。解决开启混合精度num_workers 设 2 到 4把数据预处理提前做好别在训练循环里读 CSV。现象模型把促销日销量预测得离谱。原因促销样本占比低模型没学到促销和销量的关系。解决对促销样本过采样或在输入里显式加入促销力度字段训练时给促销样本更高的 loss 权重。现象换了一个品类效果崩了。原因LoRA 只学了原品类的模式泛化不足。解决要么按品类分别微调要么在训练集里混入多品类样本并在输入里保留品类字段让模型区分。6. 进阶用验证集回测和滚动微调把预测稳住微调不是一锤子买卖。库存数据有时效性上个月的促销模式这个月可能就变了。我一般会留最近 4 周做滚动验证每周用历史数据重新跑一次 LoRA对比上周模型的预测误差误差上升就触发重训。验证指标不只看 MAE还要看缺货率和压货率这两个才是业务真正关心的。回测脚本的核心是把验证集按时间切分模拟真实预测节奏import numpy as np def backtest(model, val_df, tokenizer): errors [] for week in val_df[week].unique(): subset val_df[val_df[week] week] preds batch_predict(model, tokenizer, subset) true subset[sales_next7].values errors.append(np.mean(np.abs(preds - true))) return errorsweek字段保证按时间顺序回测不能随机切分否则会高估效果。batch_predict复用线上推理函数保证一致。误差序列如果连续两周上升就说明数据分布漂移了该重新构造训练集。另一个技巧是滚动微调不从头训而是在上一版 LoRA 权重基础上用新数据继续训学习率调低到 5e-5epoch 减到 1。这样既跟得上变化又不会把之前学到的通用模式冲掉。我自己的习惯是每次重训前先备份当前权重回测不过就回滚别等上线出问题再找后悔药。这套方案值不值得做取决于你的 SKU 规模和补货频率。SKU 几百、每天跑一次单卡加 LoRA 完全撑得住SKU 上万、要实时算就得先做批量推理和缓存层。别一上来就追求大模型先把数据管道和回测跑通模型小一点反而更容易调稳。希望帮到你。本文还有配套的精品资源点击获取 DeepSeek-R1-Distill 微调实战：零售库存预测的 LoRA 低成本方案
简介这份PDF面向零售行业数据分析师、算法工程师及希望将大模型落地业务的技术人员聚焦库存预测这一核心场景讲解如何以低成本方式微调DeepSeek-R1-Distill模型。资源包仅含1个PDF文件大小约1.86MB内容完整、图表与目录显示正常便于直接查阅。文档共21页从零售库存管理的痛点切入依次覆盖模型架构原理、数据收集与清洗、特征工程、冻结部分模型层、小批量训练与学习率调整、数据增强与采样策略并给出环境搭建、模型加载、训练循环、评估指标选择与超参数优化的完整实战路径最后以零售企业案例串联全流程。已有102人学习适合想用有限算力完成垂直领域微调、提升库存预测精度的读者参考。1. 零售库存预测为什么盯上了 DeepSeek-R1-Distill 微调零售库存预测这件事说到底是把「下周这家店这款 SKU 能卖多少」算准。传统做法是时序模型加人工规则遇到促销、换季、上新就集体翻车运营只能靠经验拍脑袋补货结果一边压货一边缺货。DeepSeek-R1-Distill 这类蒸馏推理模型出现后思路变了把历史销量、价格、促销、天气、节假日这些结构化字段拼成一段文本让模型直接输出预测值和补货建议再用门店真实数据做一次低成本微调让它学会自家商品体系的说话方式。这篇讲的就是这条路径怎么落地为什么选蒸馏版而不是满血版LoRA 微调怎么配数据怎么造显存怎么省推理怎么接进补货流程。适合手里有几千到几万条门店销量记录、想用大模型微调实战替代规则引擎的算法和供应链工程师。不追求刷榜追求的是能跑起来、能复现、能进生产。2. 选型DeepSeek-R1-Distill 与 LoRA 微调实战的匹配逻辑2.1 为什么蒸馏版比满血版更适合库存场景库存预测的输入是结构化数字加少量文本描述输出是数值加简短理由任务本身不需要模型有极强的开放推理能力。满血版参数大、显存吃紧、推理延迟高放进每天要跑几千次的门店补货流程里成本直接失控。DeepSeek-R1-Distill 把推理链蒸馏进小参数模型保留了「先想再答」的结构同时把显存和延迟压到单卡可承受的范围。我一般会先确认三件事单店 SKU 数量、预测频率、可接受的单次推理延迟。如果 SKU 在几百以内、每天跑一次蒸馏版加 LoRA 完全够用如果 SKU 上万、要实时算就得考虑批量推理和缓存。选型不是看模型多大而是看任务需不需要那么大的脑子。另一个理由是微调成本。全量微调要更新所有参数显存和训练时间都翻倍LoRA 只训练低秩矩阵显存占用能降一个量级几百条到几千条样本就能看到效果。库存数据本身噪声大全量微调容易过拟合到某几个促销日LoRA 的低秩约束反而更稳。2.2 LoRA 微调的关键参数怎么定LoRA 的核心参数是秩 r、alpha、dropout 和目标模块。库存预测任务里我一般从 r8 或 r16 起步alpha 取 r 的两倍dropout 0.05 到 0.1。目标模块优先选 q_proj 和 v_proj这两个注意力投影对数值模式的捕捉最敏感如果数据里文本描述多再加 k_proj 和 o_proj。下面是一段用 transformers peft 配置 LoRA 的代码直接可抄from transformers import AutoModelForCausalLM, AutoTokenizer from peft import LoraConfig, get_peft_model, TaskType model_name deepseek-ai/DeepSeek-R1-Distill-Qwen-1.5B tokenizer AutoTokenizer.from_pretrained(model_name, trust_remote_codeTrue) model AutoModelForCausalLM.from_pretrained( model_name, torch_dtypeauto, device_mapauto, trust_remote_codeTrue ) lora_config LoraConfig( task_typeTaskType.CAUSAL_LM, r16, # 秩库存任务 8~16 足够 lora_alpha32, # 一般取 r 的 2 倍 lora_dropout0.05, # 防过拟合数据少时调到 0.1 target_modules[q_proj, v_proj], # 先只调注意力投影 biasnone ) model get_peft_model(model, lora_config) model.print_trainable_parameters()逻辑说明r决定低秩矩阵的容量库存数据模式相对固定r 太大反而学进噪声lora_alpha控制更新幅度和 r 配合使用target_modules决定挂载位置先小范围试效果不够再扩。跑完print_trainable_parameters()你会看到可训练参数只占总参数的百分之几这就是低成本微调的来源。参数不是拍死的。如果验证集 loss 震荡先把 dropout 提到 0.1如果欠拟合把 r 提到 32 并同步把 alpha 提到 64。每次只动一个变量记录验证集表现别一次改一堆。2.3 训练超参学习率、批次与梯度累积学习率我一般用 1e-4 到 2e-4配合 cosine 调度和 warmup。批次大小受显存限制单卡 24G 跑 1.5B 模型per_device_train_batch_size 设 2 到 4再用 gradient_accumulation_steps 累积到等效批次 16 或 32。这样既稳住梯度又不爆显存。from transformers import TrainingArguments, Trainer training_args TrainingArguments( output_dir./inventory_lora_out, per_device_train_batch_size2, gradient_accumulation_steps8, # 等效批次 16 learning_rate1.5e-4, num_train_epochs3, lr_scheduler_typecosine, warmup_ratio0.03, logging_steps10, save_strategyepoch, fp16True, # 有 bf16 优先用 bf16 report_tonone )gradient_accumulation_steps是显存不够时的后悔药等效批次上去了显存占用没上去。fp16在支持 bf16 的卡上换成bf16True更稳数值范围大不容易溢出。epoch 不要多库存数据重复训练三轮以上就开始背答案验证集 loss 会先降后升看到回升就停。3. 数据把门店销量表变成模型能吃的指令样本3.1 库存预测样本的字段设计与构造模型不会自己读数据库得把每条销量记录转成「指令 输入 输出」的文本。输入侧我一般保留门店 ID、SKU ID、品类、过去 N 天销量、当前库存、在途库存、价格、是否促销、节假日标记、天气。输出侧是未来 7 天预测销量和补货建议。N 取 14 或 28太短抓不到周期太长噪声多。构造脚本核心是把宽表拍成 JSONLimport pandas as pd, json def build_sample(row): prompt ( f门店{row[store_id]}的SKU {row[sku_id]}{row[category]} f过去14天销量{row[sales_14d]}当前库存{row[stock]} f在途{row[in_transit]}售价{row[price]}元 f促销{row[promo]}节假日{row[holiday]}天气{row[weather]}。 f请预测未来7天销量并给出补货建议。 ) answer ( f未来7天预测销量{row[sales_next7]} f建议补货{row[replenish]}件理由{row[reason]}。 ) return {instruction: prompt, output: answer} df pd.read_csv(store_sales.csv) with open(inventory_train.jsonl, w, encodingutf-8) as f: for _, row in df.iterrows(): f.write(json.dumps(build_sample(row), ensure_asciiFalse) \n)逻辑说明instruction是模型看到的全部上下文字段顺序固定训练和推理必须一致否则线上效果会掉。output里把预测值、补货量、理由都写进去让模型学会「给数也给解释」。reason字段可以来自运营标注也可以由规则生成早期没有标注就用「库存低于预测销量」这类模板先跑通。参数上sales_14d建议存成逗号分隔的序列而不是单个汇总值模型对序列模式的捕捉比汇总值强。promo、holiday用 0/1weather用枚举字符串。字段名不要用中文避免 tokenizer 切分不稳定。3.2 数据清洗与类别不平衡的处理零售数据最大的坑是长尾少数爆款占大部分销量大量 SKU 一周卖不出几件。直接训练模型会偏向预测热门品冷门品全预测成零。处理办法有三步一是对销量做分层采样保证冷门 SKU 在训练集里有足够样本二是对预测目标做对数变换再还原压住极端值三是把「零销量」样本单独抽一部分让模型学会识别真正的滞销。清洗时重点看三类异常促销日销量突增、缺货日销量被截断、退货导致的负值。促销日样本要保留但打上标记缺货日样本要么剔除要么把销量补成预估需求负值直接清零。这些处理不写进代码块但每一步都要在数据管道里留日志否则出了问题查不到源头。样本量方面我一般建议每个品类至少 500 条有效样本再开训总量几千条就能看到 LoRA 的效果。数据太少时先把 r 降到 8、dropout 提到 0.1别急着加 epoch。4. 训练与推理从单卡跑通到接进补货流程4.1 单卡训练的最小命令与显存观察数据准备好后用 Trainer 或 trl 的 SFTTrainer 都能跑。我习惯先用小样本比如 200 条跑 10 步确认 loss 在降、显存没爆再上全量。启动命令python train_lora.py \ --model_name deepseek-ai/DeepSeek-R1-Distill-Qwen-1.5B \ --data_path inventory_train.jsonl \ --output_dir ./inventory_lora_out \ --per_device_train_batch_size 2 \ --gradient_accumulation_steps 8 \ --learning_rate 1.5e-4 \ --num_train_epochs 3 \ --fp16跑起来后用nvidia-smi -l 2盯显存正常情况 1.5B 模型加 LoRA 在 24G 卡上占用 10G 到 14G。如果 OOM先降 batch size再开 gradient checkpointing最后才考虑换更小的模型。训练日志里重点看 loss 曲线和 grad_normgrad_norm 突然飙高说明学习率太大或数据里有异常样本。4.2 推理接入批量预测与结果校验训练完把 LoRA 权重合并或直接加载适配器做推理。库存场景是批量任务不要一条条调要拼 batch。下面是最小推理代码from peft import PeftModel from transformers import AutoModelForCausalLM, AutoTokenizer import torch base AutoModelForCausalLM.from_pretrained( deepseek-ai/DeepSeek-R1-Distill-Qwen-1.5B, torch_dtypetorch.float16, device_mapauto ) model PeftModel.from_pretrained(base, ./inventory_lora_out) tokenizer AutoTokenizer.from_pretrained(deepseek-ai/DeepSeek-R1-Distill-Qwen-1.5B) prompts [门店S001的SKU A123饮料过去14天销量...] inputs tokenizer(prompts, return_tensorspt, paddingTrue).to(model.device) with torch.no_grad(): outputs model.generate(**inputs, max_new_tokens128, do_sampleFalse) print(tokenizer.batch_decode(outputs, skip_special_tokensTrue))do_sampleFalse保证输出稳定库存预测不需要多样性。max_new_tokens控制输出长度128 够放预测值和理由。推理结果不能直接进补货系统要加一层校验预测值是否在合理区间、补货量是否超过仓容、是否和人工规则冲突。校验不过的样本回流到训练集形成闭环。批量推理时注意 padding 侧和 attention mask左侧 padding 对生成任务更友好。如果延迟要求高可以把模型转成量化版本但量化后要重新验证预测偏差别直接上线。5. 避坑库存微调里最容易翻车的五件事现象训练 loss 一直降验证集预测全是同一个值。原因数据里某个字段比如门店 ID被模型当成了捷径或者输出格式太单一。解决检查输入字段是否泄露了答案打乱样本顺序输出里增加理由的多样性必要时对字段做随机遮蔽增强。现象线上预测比线下差一大截。原因训练样本的字段顺序、单位、缺失值处理和线上不一致。解决把数据构造逻辑封装成同一个函数训练和推理共用上线前用同一批样本对比线下线上输出。现象显存够但训练极慢。原因没开 fp16/bf16或者 dataloader 的 num_workers 设成 0。解决开启混合精度num_workers 设 2 到 4把数据预处理提前做好别在训练循环里读 CSV。现象模型把促销日销量预测得离谱。原因促销样本占比低模型没学到促销和销量的关系。解决对促销样本过采样或在输入里显式加入促销力度字段训练时给促销样本更高的 loss 权重。现象换了一个品类效果崩了。原因LoRA 只学了原品类的模式泛化不足。解决要么按品类分别微调要么在训练集里混入多品类样本并在输入里保留品类字段让模型区分。6. 进阶用验证集回测和滚动微调把预测稳住微调不是一锤子买卖。库存数据有时效性上个月的促销模式这个月可能就变了。我一般会留最近 4 周做滚动验证每周用历史数据重新跑一次 LoRA对比上周模型的预测误差误差上升就触发重训。验证指标不只看 MAE还要看缺货率和压货率这两个才是业务真正关心的。回测脚本的核心是把验证集按时间切分模拟真实预测节奏import numpy as np def backtest(model, val_df, tokenizer): errors [] for week in val_df[week].unique(): subset val_df[val_df[week] week] preds batch_predict(model, tokenizer, subset) true subset[sales_next7].values errors.append(np.mean(np.abs(preds - true))) return errorsweek字段保证按时间顺序回测不能随机切分否则会高估效果。batch_predict复用线上推理函数保证一致。误差序列如果连续两周上升就说明数据分布漂移了该重新构造训练集。另一个技巧是滚动微调不从头训而是在上一版 LoRA 权重基础上用新数据继续训学习率调低到 5e-5epoch 减到 1。这样既跟得上变化又不会把之前学到的通用模式冲掉。我自己的习惯是每次重训前先备份当前权重回测不过就回滚别等上线出问题再找后悔药。这套方案值不值得做取决于你的 SKU 规模和补货频率。SKU 几百、每天跑一次单卡加 LoRA 完全撑得住SKU 上万、要实时算就得先做批量推理和缓存层。别一上来就追求大模型先把数据管道和回测跑通模型小一点反而更容易调稳。希望帮到你。本文还有配套的精品资源点击获取