尧图网站建设 
简介这份PDF面向零售从业者、数据分析师以及希望将DeepSeek应用于实际业务的读者聚焦零售库存管理中的真实难点提供一套可参考的智能预测模型搭建指南。内容从零售业库存管理现状与挑战讲起逐一分析需求预测不准确、供应链不确定性和库存成本控制等问题并完整演示数据收集整理、特征选择、数据标准化、模型架构设计、损失函数与优化器确定、模型训练与评估、超参数调优、交叉验证以及防止过拟合等关键步骤。后半部分结合零售企业案例展示从数据准备到模型应用再到库存水平、缺货情况与成本效益改善的全过程便于读者对照自身场景迁移使用。资源为单份PDF文件共20页大小1.62MB目录结构完整章节划分清晰可快速定位到具体方法。目前已有66人浏览/学习适合需要提升库存预测精度、降低缺货与积压风险的数据分析、运营管理及技术学习人群。1. 零售业库存为什么需要DeepSeek这是一条能落地的预测路线如果你是零售计划员、供应链数据岗或者正在做门店运营系统的开发肯定对下面这个场景不陌生每周要做下一周期的补货建议手头是Excel表格加一套看天吃饭的统计模型平时还凑合促销一来就崩仓库里一边缺货一边积压。库存预测这件事传统做法是移动平均、指数平滑或者ARIMA这些方法对平稳序列还行但一碰到促销爆发、缺货回补、新品上架这种真实零售噪音基本就失灵了。把DeepSeek这类大语言模型拉进来做智能预测模型是最近零售数据方案里讨论较多的一条新路线。LLM能直接吃下你不规整的销售历史、促销日历和商品属性按要求输出未来需求还能给出依据而不是丢给你一个黑匣子数字。这篇指南给正在评估这套方案、准备动手搭预测流程的从业者从模型选型、数据清洗、API调用到参数调优和踩坑点照着走完能跑通一条最小可用的预测链路。至于它到底靠不靠谱、值不值得投入看完你自己就有判断了。2. 先想清楚再动手DeepSeek做库存预测的原理与选型理由2.1 LLM做时序预测的逻辑把数字序列翻译成文本任务很多人第一次听说用LLM做时序预测第一反应是“这东西不是用来聊天的吗”。其实换个角度就通了库存预测本质上是“根据过去N天的销量规律推断未来M天的需求”。这个任务在数学上叫时序外推在文本上叫“根据前文续写后文”。大语言模型在预训练阶段读过海量带数字的文本对数值序列的形态、周期性、突刺都有感知能力你只要把数字序列按照固定格式写进提示词它就能把预测当成文本补全来做。我最早尝试时也怀疑过这是不是玄学后来跑通一轮才明白关键在于任务塑形。不要让它自由发挥而是给一段结构化的输入比如“以下是从1月1日到1月28日SKU A001 的每日销量单位件120, 135, 142, 128, 90, 88, ...请预测未来7天销量”。模型会基于上下文里的数字量级、波动幅度、近期趋势做外推。它跟统计模型最大的区别是注意力机制能同时看到全窗口的数据不会像RNN那样把早期信息忘掉也不需要你手工指定“这个序列是不是有季节项”。还有一点值得说这里不需要微调至少起步阶段不需要。模型本身已经具备数值推理能力拿三五个示例喂在提示词里就够了这大大降低了落地门槛。你要做的不是重新训练而是把数据整理成模型能消化的文本格式然后设计好让它“闭嘴输出数字”的方式。这一点在第4章会详细展开。2.2 选DeepSeek而不是传统模型或别的LLM的三个理由先回答一个绕不开的问题既然XGBoost、Prophet都能做预测为什么还要用DeepSeek我的答案有三个都是从实际项目里总结出来的。第一中文零售语义理解能力强。库存预测的上游是业务动作比如“满300减50”“第二件半价”“春节前一周清仓”。这些事件在历史数据里留下的模式统计模型只能看到“销量异常高”解释不了为什么高而DeepSeek能直接读懂中文活动描述你可以在提示词里把促销信息、节假日名称写进去它就能把“去年春节前一周销量翻倍”这个规律纳入预测。这在品类多、促销频繁的零售场景里非常实用。第二上下文窗口足够大能塞下完整的历史周期。做零售预测最怕的就是只看近一个月季节性、去年同期的参照全丢。DeepSeek的上下文能容纳90天甚至更长的日度数据你可以把完整的历史序列放进去让模型自己找周期。传统ARIMA在长序列上要反复做差分和定阶工程上繁琐得多。第三接口标准、成本可控。DeepSeek开放平台提供跟主流LLM兼容的API格式你不需要为它单独写一套调用框架单次预测的token消耗也很小即使每天跑几千个SKU成本也在可接受范围内。对比自己部署同等规模模型API方案在起步阶段省掉了显卡和运维投入。当然如果数据敏感、调用量大本地部署是另一条路下面单独说。2.3 先定场景再选路径API调用还是本地部署聊完选型理由实际操作前还要先定一件事走API调用还是本地部署。我见过不少团队一上来就想私有化部署结果卡在显卡配置和性能调优上一个月没跑通。这里给个决策参考如果数据不能出内网、SKU数量大且调用频繁、或者你所在企业对供应链数据管控严格那只能走本地部署常见做法是用vllm拉起DeepSeek之后再逐层对接业务系统如果只是先验证效果、数据量中等API调用是最快的路径。本地部署这件事本身也有隐藏成本。你以为买块卡装上就能跑实际上vllm的启动参数、模型量化方式、并发配置都会影响响应速度调不好就是车拉不动货。我的建议很直接先花两周用API把预测流程跑通、验证精度再决定要不要搬回本地。技术方案的价值在于先证明预测结果能改善库存周转而不是先折腾一套基础设施。方向验证了部署形式随时可以换方向错了部署再漂亮也是白搭。3. 数据是预测的底线库存预测需要的数据清洗与特征工程3.1 最小可用数据集销售、库存、促销、日历四张表网上很多预测教程一上来就丢给你一个温州/深圳的公开数据集但零售业库存优化这件事落地时永远要用自己的数据。我建议先凑齐四张表缺了后面预测精度必然打折。第一张是销售明细至少要有日期、SKU编码、门店编码、销售数量、销售金额。第二张是库存快照记录每个SKU在每个门店的每日库存量注意很多系统里的库存是时点数要跟你预测的需求口径对齐。第三张是促销日历记录活动起始日期、参与SKU或品类、活动类型比如满减、直降、捆绑最好带上折扣力度。第四张是日历表包含日期、是否工作日、是否周末、是否法定节假日。这四张表凑齐了就具备了搭建预测模型的最小数据基础。数据质量是第一步要处理的问题也是最容易被忽视的。实际从ERP和POS系统导出来的数据什么妖魔鬼怪都有同一个订单记了两遍、退货单混在销售里、SKU编码大小写不一致、负数销量。我一般会先做一轮全表扫描检查重复记录和异常值而不是直接拿去算特征。另外有个零售特有的坑就是缺货期间的销量是0但这个0不代表需求为0而是被库存憋住了这种数据如果原样喂给模型模型会低估真实需求后面避坑章里再细说。3.2 用Pandas把历史销售整理成逐日序列四张表对齐后第一步是把销售明细整理成“SKU × 日期 × 门店”粒度的每日销量序列。这里用Python的pandas就能搞定不需要引入重型计算引擎。下面这段代码做了三件事加载销售明细、剔除异常记录、按天聚合出每个SKU的销量序列。import pandas as pd # 读取销售明细注意日期列要提前转成datetime类型 sales pd.read_csv(sales_detail.csv, parse_dates[order_date]) # 剔除销量为负或为零的异常记录常见的退款单、测试单 sales sales[sales[qty] 0] sales sales.drop_duplicates(subset[order_id, sku_code, store_code]) # 按SKU和日期聚合得到逐日销量 daily sales.groupby([sku_code, order_date], as_indexFalse)[qty].sum() daily daily.rename(columns{order_date: date, qty: daily_qty}) # 把缺失日期补零避免时间轴上有空洞 all_dates pd.date_range(startdaily[date].min(), enddaily[date].max(), freqD) daily_full ( daily.set_index([sku_code, date]) .reindex(pd.MultiIndex.from_product([daily[sku_code].unique(), all_dates])) .fillna(0) .reset_index() )这段代码的逻辑是从明细到序列的标准化过程。第一行用parse_dates确保日期列被解析成时间类型这是后面所有时间操作的前提第二步同时做了值域过滤和去重退货单和重复记录必须在这一步清掉否则聚合出来的销量会被虚高。补零这一步是零售预测里容易被忽略的细节如果某天没有销售记录既可能是真没卖出去也可能是门店盘点或系统漏单。我先用0填充保证时间轴连续但会额外记录一个“是否缺货导致的0”标记这个标记在第3.3节会变成特征。3.3 构建特征矩阵滞后项、滚动均值与促销编码序列整理好之后接下来是特征工程也就是把“过去长什么样”转成模型能直接感知的数值信号。这里不打算用复杂特征四个常用组合就够滞后项、滚动统计量、周期性编码、事件标记。下面这段代码以单个SKU为例展示特征构造过程多SKU场景用groupby包一层即可。import numpy as np # 构造滞后特征过去第7天、第14天、第28天的销量 daily[lag_7] daily.groupby(sku_code)[daily_qty].shift(7) daily[lag_14] daily.groupby(sku_code)[daily_qty].shift(14) daily[lag_28] daily.groupby(sku_code)[daily_qty].shift(28) # 滚动统计量近7天的均值与标准差捕捉近期波动 daily[roll_mean_7] daily.groupby(sku_code)[daily_qty].transform( lambda x: x.rolling(7, min_periods1).mean() ) daily[roll_std_7] daily.groupby(sku_code)[daily_qty].transform( lambda x: x.rolling(7, min_periods1).std().fillna(0) ) # 周期性编码星期几和是否周末 daily[weekday] daily[date].dt.weekday daily[is_weekend] (daily[weekday] 5).astype(int)特征里最核心的是滞后项和滚动均值。lag_7和lag_14能帮模型识别周度周期零售数据通常有很强的“工作日低、周末高”规律lag_28则是用来对月度的活动周期做参照。滚动均值表示近期整体水平模型靠它来校准量级避免被一两天的极端值带偏。这里有一个参数选择上的注意点滞后期选了7、14、28而不是1到28天全部铺满是考虑到DeepSeek的提示词长度有限特征越精简模型越容易聚焦等后续效果验证不够再逐渐加特征不迟。促销和节假日编码我习惯在前一步就做成交替的0/1标记列这样提示词里可以直接引用“feature_promo: 1”这样的格式。促销标记必须带活动类型比如大促和小促分别编码因为它们的销售拉升系数完全不同。拼到提示词里时特征列顺序要固定今天周一还是周六、近7天平均销量多少、是否在促销期这些信息要跟销量序列错开编排否则模型会把特征数值也当成销量来解读这个坑在第5章会展开。4. 搭建基于DeepSeek的预测模型Prompt设计与API调用全流程4.1 设计输出JSON的Prompt让模型别废话如果说数据是预测的底线Prompt就是预测的上限。同一个模型提示词写得好不好预测结果能差出一个量级。我踩过的第一个坑就是让模型“自由表达”结果它回了三段分析加一个模糊结论根本没法接进业务流程。后来统一做法强制输出JSON把预测值、置信区间、业务解释放在固定字段里。下面是一段在我这边跑过很多轮的基础Prompt模板你先感受一下结构。你是零售库存预测助手。根据给定的历史销售数据和特征预测未来7天的每日销量。 输入格式 history: [120, 135, 142, 138, 90, 85, 88, 130, 142, 155, 150, 102, 95, ...] features: {is_weekend: 0, promo_type: none, roll_mean_7: 128.5, lag_7: 120} 去年同日销量: [150, 162, 158, 99, 92, ...] 要求 1. 只输出JSON不要多余解释。 2. 预测值必须是非负整数单位是件。 3. 参考近期趋势不要简单取平均值。 4. 如果存在促销或节假日请单独加大预测幅度。 输出格式 {predicted_daily: [null, null, null, null, null, null, null], confidence: 0.0, reason: }这个Prompt的设计关键有三个。第一是“历史销量 结构化特征 去年同期参照”三段式排列给模型足够的信息落点第二是明确告诉它“参考趋势不要取平均”这是抑制模型偷懒的关键约束第三是输出模板里置信度字段和reason字段用来后续判断哪些SKU的预测结果需要人工复核。你可能会问去年同期要不要给我的经验是要零售数据年周期性强去年的参照能显著提升节日和换季场景的表现。4.2 最小可用的DeepSeek API调用脚本Prompt设计好之后就该把它接进代码了。以DeepSeek开放平台的接口为例它兼容OpenAI的SDK格式所以直接用openai库就能跑起来不用额外引依赖。下面这段脚本是完整的预测函数包含了请求构造、超时设置和返回解析。import os import json import openai client openai.OpenAI( api_keyos.getenv(DEEPSEEK_API_KEY), base_urlhttps://api.deepseek.com/v1 ) def predict_sku_demand(history, features, last_year_sales): # 构造输入文本 prompt f 你是零售库存预测助手。根据给定的历史销售数据和特征预测未来7天的每日销量。 输入格式 history: {history} features: {json.dumps(features, ensure_asciiFalse)} 去年同日销量: {last_year_sales} 要求 1. 只输出JSON不要多余解释。 2. 预测值必须是非负整数单位是件。 3. 参考近期趋势不要简单取平均值。 4. 如果存在促销或节假日请单独加大预测幅度。 输出格式 {{predicted_daily: [null, null, null, null, null, null, null], confidence: 0.0, reason: }} resp client.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: 你是零售库存预测助手。}, {role: user, content: prompt} ], temperature0.1, max_tokens512, timeout60 ) # 解析模型返回的JSON内容 content resp.choices[0].message.content result json.loads(content) return result这段代码的逻辑分三步构造client、填充Prompt并发请求、解析JSON结果。api_key从环境变量读取不建议硬编码在脚本里否则代码一泄露密钥就全完了。base_url指向DeepSeek开放平台兼容接口的地址如果你是本地部署这里换成你vllm服务自己的地址即可其余代码不用动。参数设置方面temperature设了0.1这个值很关键。预测任务要的是低随机性、可复现如果设到0.7同一份数据跑两次结果能差出20%。max_tokens设512别贪大模型输出越长越容易在中间夹带废话或在JSON里混入注释。timeout设60秒下面是血泪教训有些库存预测场景需要批量跑几百上千个SKU不控制超时一个卡住的请求能把整个批次拖死。4.3 必调的三个参数temperature、max_tokens与请求超时刚接触LLM预测的人最容易把聊天时的习惯带过来乱调参数。这里给一张我调过很多轮的参数表你可以直接照抄初始值再按自己数据的情况微调。参数推荐值作用与调整方向temperature0.1控制输出随机性。预测任务往低调0.1到0.2之间即可超过0.3后结果波动明显增大top_p0.9配合temperature控制采样范围一般保持默认不建议与temperature同时大幅调整max_tokens512限制输出长度。7天预测结果加解释512足够设太大浪费token设太小JSON易被截断timeout60秒单次请求超时。批量跑数据时建议结合重试机制50个并发里难免有慢请求frequency_penalty0别开开了会让模型刻意改变输出风格影响数值稳定性参数调优的核心原则是“先固定再单变量调”。不要一上来同时改五个参数改完都不知道是谁起的作用。我一般先把temperature和max_tokens固定用20个覆盖不同场景的SKU做样例集比如正常品、促销品、新品各几个跑一遍看哪些输出格式错误或明显偏离量级再针对性调Prompt而不是调模型参数。另外OpenAI兼容SDK里还有个容易忽略的点response_format。如果接入的接口支持json_object模式就在请求参数里显式声明这能大幅降低模型输出碎文本的概率。我这边实测不申明时大概5%的请求返回格式不干净申明后降到接近0。这个比例在单次调用上无所谓在每天几千次调用的批处理流程里就是实打实的收益。5. 避坑指南库存预测模型最常翻车的五个场景5.1 现象模型每天输出同一个数字完全没变化跑完第一批预测结果你可能会发现某些SKU未来7天的预测值几乎一模一样比如全是130件上下。这个“偷懒”行为在LLM里很常见它倾向于用序列的均值或众数填满输出而不去识别波动规律。原因主要有两个一是提示词里没有强调“如果要预测的日期包含周末需考虑周期性”模型把任务简化成了求期望二是历史序列里噪音太大模型选择保守策略用均值糊弄过去。解决方法是双管齐下。Prompt里明确加上“预测值应体现星期周期性工作日与周末可以不同”同时在few-shot示例里故意放一个工作周末差异明显的样本比如周一80件、周六200件让模型模仿。再有把temperature适当调到0.2给它一点波动空间不要追求绝对稳定而丢失变化。最后还要检查是不是历史数据本身有问题比如某SKU近一个月每天都卖130件上下那它输出130反而是对的。5.2 现象双11和春节的预测偏差超过40%这是零售预测里最扎心的场景。平时模型表现挺好一到双11、年货节这种大型促销预测值比实际销量低三四成补货计划直接被打乱。原因也不难找大促期间销量曲线是完全不同于平日的形态促销前两三天开始爬坡、活动爆发成尖峰、结束后急速下滑这种形态在平日的训练样本里几乎没有。更深一层促销还分平台大促和店铺自促折扣深度不同拉升系数完全不同一个笼统的“promo_type: 1”根本没法区分。解决的核心是把“去年同期同类促销”和“促销库存深度”装进Prompt。我一般在特征里加两个字段activity_ratio去年同期促销期间销量是平日均值的倍数和promo_depth折扣力度比如0.8代表八折。这两个字段有很强的业务含义模型能直接利用它们做量级缩放。再配合few-shot示例给两个不同类型促销的历史序列模型在大促上的表现会有肉眼可见的提升。5.3 现象API偶尔超时预测流程直接中断接进生产流程后你会发现API调用不是每次都顺滑的。某个请求卡了90秒报了个超时异常整批几百个SKU的预测全部停在原地这就是典型的“一个老鼠坏一锅汤”。原因多数在于批量请求没有做并发控制和异常隔离。调用几十个SKU时看不出问题一旦到几千个网络抖动、服务端限流、单请求返回变长都会让任务把自己卡死。解决方案是加三层保险。第一层把超时时间设为30到60秒设置短一点宁可失败重试也不要无限等待第二层用tenacity或手写重试装饰器对超时和限流异常做最多2次重试重试间隔递增第三层也是最重要的兜底异常时降级用最近7天均值作为预测结果并标记该SKU为“低置信度”。这样即使API全挂了库存计划也不会空等系统依然能给出一个可用的参考值。不要追求每次调用都成功要保证流程不会断。5.4 现象新品SKU没有历史数据模型无从下手新品预测是库存计划里最头疼的问题之一。没有历史序列你的Prompt再怎么精心设计模型也只能干瞪眼。有的同学会硬造一段历史填进去结果模型顺着造出来的数据预测出来的结果跟抽签没区别。解决思路是冷启动方案老零售人应该都熟悉。新品虽然自己没数据但同品类、同价格带、同定位的老品有一堆。常见做法是找到同一二级品类下10个销量中位数接近的老品把它们的近期销量序列按比例缩放后拼合成一段“合成历史”作为新品的参照输入。Prompt里也要明确告诉模型这是新品并降低置信度预期。在输出JSON的confidence字段上可以设定新品的置信度上限为0.5。这样做不是为了为难模型而是让下游的补货计划知道这个数字参考价值有限下单时要更保守或者人工介入。5.5 现象本地部署后响应慢到没法用接进内网、用vllm部署了DeepSeek之后你可能会遇到一个尴尬的情况跑是能跑但一个请求要等几秒甚至十几秒批量跑几百个SKU根本等不起。原因基本集中在三处。一是模型精度太高权重占据大量显存推理时吞吐上不去这时候量化是首选方案常见做法是用AWQ或者GPTQ做4bit量化精度损失在可接受范围速度能提升好几倍二是vllm的max_model_len设得太大每个请求都要预分配大量显存实际用不到那么多上下文白白浪费三是并发参数设置不合理开的并发太高导致GPU显存溢出或争抢触发重新排队。另外本地部署的模型版本不同性能差异也很大不要盲目选最大最全的版本要看你的实际输入长度和调用量。建议先用小模型跑通流程再从响应速度、显存占用、预测精度三个指标做一次基准测试用数据决定要不要上更大参数的版本。6. 让预测真正被库存计划用起来回测与多层级预测技巧模型跑通、能出数只是第一步。库存计划真正需要的是一个可验证、可上线的预测机制。我最后讲两个让我少走很多弯路的做法回测框架和多层级预测。回测是预测模型的生命线。不要等模型上线后才看效果要在历史数据上模拟“过去的未来”从一年前开始用截至每个时点的数据预测未来7天然后跟实际对比滚动推进。我第一次做这件事时才发现模型的平均误差看着还行但分品类拆开后零食类偏差只有15%换季服装类偏差接近60%。不拆开看这个60%就被平均数字掩盖了。这类问题要用WAPE加权绝对百分比误差来评估单看MAPE会被某些低销量SKU的极端值带偏。回测跑完再把Top偏差大的SKU导出来人工看一眼就能发现是特征缺失还是促销漏标。多层级预测是另一个值得投入的方向。直接预测SKU级需求噪音大、误差也大直接预测门店总需求又会丢失单个商品的补货信息。我现在的做法是分三层先在品类或中类层级做一次总量预测再把SKU预测结果按比例缩放对齐到总量上最后在门店层级做分配。# 以品类总量的预测值为基准对SKU预测做比例修正 category_total_pred 3200 # 品类层预测结果 sku_pred_raw [420, 1550, 760, 470] # SKU层原始预测 sku_pred_scaled [int(x * category_total_pred / sum(sku_pred_raw)) for x in sku_pred_raw]这段代码的逻辑是一个简单的比例对齐。SKU层预测求和后与品类层预测往往不一致这种不一致在供应链里会传导成库存偏差。按比例缩放后SKU层合计数与品类层对齐既保留了单品差异信息又不会在汇总时出现结构性失真。这是从“能用”到“好用”的关键一步。最后说一点个人教训。我做促销预测时有一版模型线上表现不错但第二个月开始持续低估补货需求。排查下来问题不在模型而在于没有把缺货回补效应考虑进去上一周缺货的SKU这周会有补偿性需求增长。后来在特征里加了“缺货天数”这个标记模型才真正把这段需求接住了。这件事让我养成了一个习惯每次预测结果出来先对比“预测值 vs 上次预测值”的差异方向再去看业务侧最近发生了什么而不是直接丢给模型背锅。这方案跑了一年多回过头看最大的价值不是预测精度提升了多少而是让补货计划从拍脑袋变成了有依据的讨论。希望帮到你。本文还有配套的精品资源点击获取 用DeepSeek搞定零售库存预测：从Prompt设计到落地避坑指南
简介这份PDF面向零售从业者、数据分析师以及希望将DeepSeek应用于实际业务的读者聚焦零售库存管理中的真实难点提供一套可参考的智能预测模型搭建指南。内容从零售业库存管理现状与挑战讲起逐一分析需求预测不准确、供应链不确定性和库存成本控制等问题并完整演示数据收集整理、特征选择、数据标准化、模型架构设计、损失函数与优化器确定、模型训练与评估、超参数调优、交叉验证以及防止过拟合等关键步骤。后半部分结合零售企业案例展示从数据准备到模型应用再到库存水平、缺货情况与成本效益改善的全过程便于读者对照自身场景迁移使用。资源为单份PDF文件共20页大小1.62MB目录结构完整章节划分清晰可快速定位到具体方法。目前已有66人浏览/学习适合需要提升库存预测精度、降低缺货与积压风险的数据分析、运营管理及技术学习人群。1. 零售业库存为什么需要DeepSeek这是一条能落地的预测路线如果你是零售计划员、供应链数据岗或者正在做门店运营系统的开发肯定对下面这个场景不陌生每周要做下一周期的补货建议手头是Excel表格加一套看天吃饭的统计模型平时还凑合促销一来就崩仓库里一边缺货一边积压。库存预测这件事传统做法是移动平均、指数平滑或者ARIMA这些方法对平稳序列还行但一碰到促销爆发、缺货回补、新品上架这种真实零售噪音基本就失灵了。把DeepSeek这类大语言模型拉进来做智能预测模型是最近零售数据方案里讨论较多的一条新路线。LLM能直接吃下你不规整的销售历史、促销日历和商品属性按要求输出未来需求还能给出依据而不是丢给你一个黑匣子数字。这篇指南给正在评估这套方案、准备动手搭预测流程的从业者从模型选型、数据清洗、API调用到参数调优和踩坑点照着走完能跑通一条最小可用的预测链路。至于它到底靠不靠谱、值不值得投入看完你自己就有判断了。2. 先想清楚再动手DeepSeek做库存预测的原理与选型理由2.1 LLM做时序预测的逻辑把数字序列翻译成文本任务很多人第一次听说用LLM做时序预测第一反应是“这东西不是用来聊天的吗”。其实换个角度就通了库存预测本质上是“根据过去N天的销量规律推断未来M天的需求”。这个任务在数学上叫时序外推在文本上叫“根据前文续写后文”。大语言模型在预训练阶段读过海量带数字的文本对数值序列的形态、周期性、突刺都有感知能力你只要把数字序列按照固定格式写进提示词它就能把预测当成文本补全来做。我最早尝试时也怀疑过这是不是玄学后来跑通一轮才明白关键在于任务塑形。不要让它自由发挥而是给一段结构化的输入比如“以下是从1月1日到1月28日SKU A001 的每日销量单位件120, 135, 142, 128, 90, 88, ...请预测未来7天销量”。模型会基于上下文里的数字量级、波动幅度、近期趋势做外推。它跟统计模型最大的区别是注意力机制能同时看到全窗口的数据不会像RNN那样把早期信息忘掉也不需要你手工指定“这个序列是不是有季节项”。还有一点值得说这里不需要微调至少起步阶段不需要。模型本身已经具备数值推理能力拿三五个示例喂在提示词里就够了这大大降低了落地门槛。你要做的不是重新训练而是把数据整理成模型能消化的文本格式然后设计好让它“闭嘴输出数字”的方式。这一点在第4章会详细展开。2.2 选DeepSeek而不是传统模型或别的LLM的三个理由先回答一个绕不开的问题既然XGBoost、Prophet都能做预测为什么还要用DeepSeek我的答案有三个都是从实际项目里总结出来的。第一中文零售语义理解能力强。库存预测的上游是业务动作比如“满300减50”“第二件半价”“春节前一周清仓”。这些事件在历史数据里留下的模式统计模型只能看到“销量异常高”解释不了为什么高而DeepSeek能直接读懂中文活动描述你可以在提示词里把促销信息、节假日名称写进去它就能把“去年春节前一周销量翻倍”这个规律纳入预测。这在品类多、促销频繁的零售场景里非常实用。第二上下文窗口足够大能塞下完整的历史周期。做零售预测最怕的就是只看近一个月季节性、去年同期的参照全丢。DeepSeek的上下文能容纳90天甚至更长的日度数据你可以把完整的历史序列放进去让模型自己找周期。传统ARIMA在长序列上要反复做差分和定阶工程上繁琐得多。第三接口标准、成本可控。DeepSeek开放平台提供跟主流LLM兼容的API格式你不需要为它单独写一套调用框架单次预测的token消耗也很小即使每天跑几千个SKU成本也在可接受范围内。对比自己部署同等规模模型API方案在起步阶段省掉了显卡和运维投入。当然如果数据敏感、调用量大本地部署是另一条路下面单独说。2.3 先定场景再选路径API调用还是本地部署聊完选型理由实际操作前还要先定一件事走API调用还是本地部署。我见过不少团队一上来就想私有化部署结果卡在显卡配置和性能调优上一个月没跑通。这里给个决策参考如果数据不能出内网、SKU数量大且调用频繁、或者你所在企业对供应链数据管控严格那只能走本地部署常见做法是用vllm拉起DeepSeek之后再逐层对接业务系统如果只是先验证效果、数据量中等API调用是最快的路径。本地部署这件事本身也有隐藏成本。你以为买块卡装上就能跑实际上vllm的启动参数、模型量化方式、并发配置都会影响响应速度调不好就是车拉不动货。我的建议很直接先花两周用API把预测流程跑通、验证精度再决定要不要搬回本地。技术方案的价值在于先证明预测结果能改善库存周转而不是先折腾一套基础设施。方向验证了部署形式随时可以换方向错了部署再漂亮也是白搭。3. 数据是预测的底线库存预测需要的数据清洗与特征工程3.1 最小可用数据集销售、库存、促销、日历四张表网上很多预测教程一上来就丢给你一个温州/深圳的公开数据集但零售业库存优化这件事落地时永远要用自己的数据。我建议先凑齐四张表缺了后面预测精度必然打折。第一张是销售明细至少要有日期、SKU编码、门店编码、销售数量、销售金额。第二张是库存快照记录每个SKU在每个门店的每日库存量注意很多系统里的库存是时点数要跟你预测的需求口径对齐。第三张是促销日历记录活动起始日期、参与SKU或品类、活动类型比如满减、直降、捆绑最好带上折扣力度。第四张是日历表包含日期、是否工作日、是否周末、是否法定节假日。这四张表凑齐了就具备了搭建预测模型的最小数据基础。数据质量是第一步要处理的问题也是最容易被忽视的。实际从ERP和POS系统导出来的数据什么妖魔鬼怪都有同一个订单记了两遍、退货单混在销售里、SKU编码大小写不一致、负数销量。我一般会先做一轮全表扫描检查重复记录和异常值而不是直接拿去算特征。另外有个零售特有的坑就是缺货期间的销量是0但这个0不代表需求为0而是被库存憋住了这种数据如果原样喂给模型模型会低估真实需求后面避坑章里再细说。3.2 用Pandas把历史销售整理成逐日序列四张表对齐后第一步是把销售明细整理成“SKU × 日期 × 门店”粒度的每日销量序列。这里用Python的pandas就能搞定不需要引入重型计算引擎。下面这段代码做了三件事加载销售明细、剔除异常记录、按天聚合出每个SKU的销量序列。import pandas as pd # 读取销售明细注意日期列要提前转成datetime类型 sales pd.read_csv(sales_detail.csv, parse_dates[order_date]) # 剔除销量为负或为零的异常记录常见的退款单、测试单 sales sales[sales[qty] 0] sales sales.drop_duplicates(subset[order_id, sku_code, store_code]) # 按SKU和日期聚合得到逐日销量 daily sales.groupby([sku_code, order_date], as_indexFalse)[qty].sum() daily daily.rename(columns{order_date: date, qty: daily_qty}) # 把缺失日期补零避免时间轴上有空洞 all_dates pd.date_range(startdaily[date].min(), enddaily[date].max(), freqD) daily_full ( daily.set_index([sku_code, date]) .reindex(pd.MultiIndex.from_product([daily[sku_code].unique(), all_dates])) .fillna(0) .reset_index() )这段代码的逻辑是从明细到序列的标准化过程。第一行用parse_dates确保日期列被解析成时间类型这是后面所有时间操作的前提第二步同时做了值域过滤和去重退货单和重复记录必须在这一步清掉否则聚合出来的销量会被虚高。补零这一步是零售预测里容易被忽略的细节如果某天没有销售记录既可能是真没卖出去也可能是门店盘点或系统漏单。我先用0填充保证时间轴连续但会额外记录一个“是否缺货导致的0”标记这个标记在第3.3节会变成特征。3.3 构建特征矩阵滞后项、滚动均值与促销编码序列整理好之后接下来是特征工程也就是把“过去长什么样”转成模型能直接感知的数值信号。这里不打算用复杂特征四个常用组合就够滞后项、滚动统计量、周期性编码、事件标记。下面这段代码以单个SKU为例展示特征构造过程多SKU场景用groupby包一层即可。import numpy as np # 构造滞后特征过去第7天、第14天、第28天的销量 daily[lag_7] daily.groupby(sku_code)[daily_qty].shift(7) daily[lag_14] daily.groupby(sku_code)[daily_qty].shift(14) daily[lag_28] daily.groupby(sku_code)[daily_qty].shift(28) # 滚动统计量近7天的均值与标准差捕捉近期波动 daily[roll_mean_7] daily.groupby(sku_code)[daily_qty].transform( lambda x: x.rolling(7, min_periods1).mean() ) daily[roll_std_7] daily.groupby(sku_code)[daily_qty].transform( lambda x: x.rolling(7, min_periods1).std().fillna(0) ) # 周期性编码星期几和是否周末 daily[weekday] daily[date].dt.weekday daily[is_weekend] (daily[weekday] 5).astype(int)特征里最核心的是滞后项和滚动均值。lag_7和lag_14能帮模型识别周度周期零售数据通常有很强的“工作日低、周末高”规律lag_28则是用来对月度的活动周期做参照。滚动均值表示近期整体水平模型靠它来校准量级避免被一两天的极端值带偏。这里有一个参数选择上的注意点滞后期选了7、14、28而不是1到28天全部铺满是考虑到DeepSeek的提示词长度有限特征越精简模型越容易聚焦等后续效果验证不够再逐渐加特征不迟。促销和节假日编码我习惯在前一步就做成交替的0/1标记列这样提示词里可以直接引用“feature_promo: 1”这样的格式。促销标记必须带活动类型比如大促和小促分别编码因为它们的销售拉升系数完全不同。拼到提示词里时特征列顺序要固定今天周一还是周六、近7天平均销量多少、是否在促销期这些信息要跟销量序列错开编排否则模型会把特征数值也当成销量来解读这个坑在第5章会展开。4. 搭建基于DeepSeek的预测模型Prompt设计与API调用全流程4.1 设计输出JSON的Prompt让模型别废话如果说数据是预测的底线Prompt就是预测的上限。同一个模型提示词写得好不好预测结果能差出一个量级。我踩过的第一个坑就是让模型“自由表达”结果它回了三段分析加一个模糊结论根本没法接进业务流程。后来统一做法强制输出JSON把预测值、置信区间、业务解释放在固定字段里。下面是一段在我这边跑过很多轮的基础Prompt模板你先感受一下结构。你是零售库存预测助手。根据给定的历史销售数据和特征预测未来7天的每日销量。 输入格式 history: [120, 135, 142, 138, 90, 85, 88, 130, 142, 155, 150, 102, 95, ...] features: {is_weekend: 0, promo_type: none, roll_mean_7: 128.5, lag_7: 120} 去年同日销量: [150, 162, 158, 99, 92, ...] 要求 1. 只输出JSON不要多余解释。 2. 预测值必须是非负整数单位是件。 3. 参考近期趋势不要简单取平均值。 4. 如果存在促销或节假日请单独加大预测幅度。 输出格式 {predicted_daily: [null, null, null, null, null, null, null], confidence: 0.0, reason: }这个Prompt的设计关键有三个。第一是“历史销量 结构化特征 去年同期参照”三段式排列给模型足够的信息落点第二是明确告诉它“参考趋势不要取平均”这是抑制模型偷懒的关键约束第三是输出模板里置信度字段和reason字段用来后续判断哪些SKU的预测结果需要人工复核。你可能会问去年同期要不要给我的经验是要零售数据年周期性强去年的参照能显著提升节日和换季场景的表现。4.2 最小可用的DeepSeek API调用脚本Prompt设计好之后就该把它接进代码了。以DeepSeek开放平台的接口为例它兼容OpenAI的SDK格式所以直接用openai库就能跑起来不用额外引依赖。下面这段脚本是完整的预测函数包含了请求构造、超时设置和返回解析。import os import json import openai client openai.OpenAI( api_keyos.getenv(DEEPSEEK_API_KEY), base_urlhttps://api.deepseek.com/v1 ) def predict_sku_demand(history, features, last_year_sales): # 构造输入文本 prompt f 你是零售库存预测助手。根据给定的历史销售数据和特征预测未来7天的每日销量。 输入格式 history: {history} features: {json.dumps(features, ensure_asciiFalse)} 去年同日销量: {last_year_sales} 要求 1. 只输出JSON不要多余解释。 2. 预测值必须是非负整数单位是件。 3. 参考近期趋势不要简单取平均值。 4. 如果存在促销或节假日请单独加大预测幅度。 输出格式 {{predicted_daily: [null, null, null, null, null, null, null], confidence: 0.0, reason: }} resp client.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: 你是零售库存预测助手。}, {role: user, content: prompt} ], temperature0.1, max_tokens512, timeout60 ) # 解析模型返回的JSON内容 content resp.choices[0].message.content result json.loads(content) return result这段代码的逻辑分三步构造client、填充Prompt并发请求、解析JSON结果。api_key从环境变量读取不建议硬编码在脚本里否则代码一泄露密钥就全完了。base_url指向DeepSeek开放平台兼容接口的地址如果你是本地部署这里换成你vllm服务自己的地址即可其余代码不用动。参数设置方面temperature设了0.1这个值很关键。预测任务要的是低随机性、可复现如果设到0.7同一份数据跑两次结果能差出20%。max_tokens设512别贪大模型输出越长越容易在中间夹带废话或在JSON里混入注释。timeout设60秒下面是血泪教训有些库存预测场景需要批量跑几百上千个SKU不控制超时一个卡住的请求能把整个批次拖死。4.3 必调的三个参数temperature、max_tokens与请求超时刚接触LLM预测的人最容易把聊天时的习惯带过来乱调参数。这里给一张我调过很多轮的参数表你可以直接照抄初始值再按自己数据的情况微调。参数推荐值作用与调整方向temperature0.1控制输出随机性。预测任务往低调0.1到0.2之间即可超过0.3后结果波动明显增大top_p0.9配合temperature控制采样范围一般保持默认不建议与temperature同时大幅调整max_tokens512限制输出长度。7天预测结果加解释512足够设太大浪费token设太小JSON易被截断timeout60秒单次请求超时。批量跑数据时建议结合重试机制50个并发里难免有慢请求frequency_penalty0别开开了会让模型刻意改变输出风格影响数值稳定性参数调优的核心原则是“先固定再单变量调”。不要一上来同时改五个参数改完都不知道是谁起的作用。我一般先把temperature和max_tokens固定用20个覆盖不同场景的SKU做样例集比如正常品、促销品、新品各几个跑一遍看哪些输出格式错误或明显偏离量级再针对性调Prompt而不是调模型参数。另外OpenAI兼容SDK里还有个容易忽略的点response_format。如果接入的接口支持json_object模式就在请求参数里显式声明这能大幅降低模型输出碎文本的概率。我这边实测不申明时大概5%的请求返回格式不干净申明后降到接近0。这个比例在单次调用上无所谓在每天几千次调用的批处理流程里就是实打实的收益。5. 避坑指南库存预测模型最常翻车的五个场景5.1 现象模型每天输出同一个数字完全没变化跑完第一批预测结果你可能会发现某些SKU未来7天的预测值几乎一模一样比如全是130件上下。这个“偷懒”行为在LLM里很常见它倾向于用序列的均值或众数填满输出而不去识别波动规律。原因主要有两个一是提示词里没有强调“如果要预测的日期包含周末需考虑周期性”模型把任务简化成了求期望二是历史序列里噪音太大模型选择保守策略用均值糊弄过去。解决方法是双管齐下。Prompt里明确加上“预测值应体现星期周期性工作日与周末可以不同”同时在few-shot示例里故意放一个工作周末差异明显的样本比如周一80件、周六200件让模型模仿。再有把temperature适当调到0.2给它一点波动空间不要追求绝对稳定而丢失变化。最后还要检查是不是历史数据本身有问题比如某SKU近一个月每天都卖130件上下那它输出130反而是对的。5.2 现象双11和春节的预测偏差超过40%这是零售预测里最扎心的场景。平时模型表现挺好一到双11、年货节这种大型促销预测值比实际销量低三四成补货计划直接被打乱。原因也不难找大促期间销量曲线是完全不同于平日的形态促销前两三天开始爬坡、活动爆发成尖峰、结束后急速下滑这种形态在平日的训练样本里几乎没有。更深一层促销还分平台大促和店铺自促折扣深度不同拉升系数完全不同一个笼统的“promo_type: 1”根本没法区分。解决的核心是把“去年同期同类促销”和“促销库存深度”装进Prompt。我一般在特征里加两个字段activity_ratio去年同期促销期间销量是平日均值的倍数和promo_depth折扣力度比如0.8代表八折。这两个字段有很强的业务含义模型能直接利用它们做量级缩放。再配合few-shot示例给两个不同类型促销的历史序列模型在大促上的表现会有肉眼可见的提升。5.3 现象API偶尔超时预测流程直接中断接进生产流程后你会发现API调用不是每次都顺滑的。某个请求卡了90秒报了个超时异常整批几百个SKU的预测全部停在原地这就是典型的“一个老鼠坏一锅汤”。原因多数在于批量请求没有做并发控制和异常隔离。调用几十个SKU时看不出问题一旦到几千个网络抖动、服务端限流、单请求返回变长都会让任务把自己卡死。解决方案是加三层保险。第一层把超时时间设为30到60秒设置短一点宁可失败重试也不要无限等待第二层用tenacity或手写重试装饰器对超时和限流异常做最多2次重试重试间隔递增第三层也是最重要的兜底异常时降级用最近7天均值作为预测结果并标记该SKU为“低置信度”。这样即使API全挂了库存计划也不会空等系统依然能给出一个可用的参考值。不要追求每次调用都成功要保证流程不会断。5.4 现象新品SKU没有历史数据模型无从下手新品预测是库存计划里最头疼的问题之一。没有历史序列你的Prompt再怎么精心设计模型也只能干瞪眼。有的同学会硬造一段历史填进去结果模型顺着造出来的数据预测出来的结果跟抽签没区别。解决思路是冷启动方案老零售人应该都熟悉。新品虽然自己没数据但同品类、同价格带、同定位的老品有一堆。常见做法是找到同一二级品类下10个销量中位数接近的老品把它们的近期销量序列按比例缩放后拼合成一段“合成历史”作为新品的参照输入。Prompt里也要明确告诉模型这是新品并降低置信度预期。在输出JSON的confidence字段上可以设定新品的置信度上限为0.5。这样做不是为了为难模型而是让下游的补货计划知道这个数字参考价值有限下单时要更保守或者人工介入。5.5 现象本地部署后响应慢到没法用接进内网、用vllm部署了DeepSeek之后你可能会遇到一个尴尬的情况跑是能跑但一个请求要等几秒甚至十几秒批量跑几百个SKU根本等不起。原因基本集中在三处。一是模型精度太高权重占据大量显存推理时吞吐上不去这时候量化是首选方案常见做法是用AWQ或者GPTQ做4bit量化精度损失在可接受范围速度能提升好几倍二是vllm的max_model_len设得太大每个请求都要预分配大量显存实际用不到那么多上下文白白浪费三是并发参数设置不合理开的并发太高导致GPU显存溢出或争抢触发重新排队。另外本地部署的模型版本不同性能差异也很大不要盲目选最大最全的版本要看你的实际输入长度和调用量。建议先用小模型跑通流程再从响应速度、显存占用、预测精度三个指标做一次基准测试用数据决定要不要上更大参数的版本。6. 让预测真正被库存计划用起来回测与多层级预测技巧模型跑通、能出数只是第一步。库存计划真正需要的是一个可验证、可上线的预测机制。我最后讲两个让我少走很多弯路的做法回测框架和多层级预测。回测是预测模型的生命线。不要等模型上线后才看效果要在历史数据上模拟“过去的未来”从一年前开始用截至每个时点的数据预测未来7天然后跟实际对比滚动推进。我第一次做这件事时才发现模型的平均误差看着还行但分品类拆开后零食类偏差只有15%换季服装类偏差接近60%。不拆开看这个60%就被平均数字掩盖了。这类问题要用WAPE加权绝对百分比误差来评估单看MAPE会被某些低销量SKU的极端值带偏。回测跑完再把Top偏差大的SKU导出来人工看一眼就能发现是特征缺失还是促销漏标。多层级预测是另一个值得投入的方向。直接预测SKU级需求噪音大、误差也大直接预测门店总需求又会丢失单个商品的补货信息。我现在的做法是分三层先在品类或中类层级做一次总量预测再把SKU预测结果按比例缩放对齐到总量上最后在门店层级做分配。# 以品类总量的预测值为基准对SKU预测做比例修正 category_total_pred 3200 # 品类层预测结果 sku_pred_raw [420, 1550, 760, 470] # SKU层原始预测 sku_pred_scaled [int(x * category_total_pred / sum(sku_pred_raw)) for x in sku_pred_raw]这段代码的逻辑是一个简单的比例对齐。SKU层预测求和后与品类层预测往往不一致这种不一致在供应链里会传导成库存偏差。按比例缩放后SKU层合计数与品类层对齐既保留了单品差异信息又不会在汇总时出现结构性失真。这是从“能用”到“好用”的关键一步。最后说一点个人教训。我做促销预测时有一版模型线上表现不错但第二个月开始持续低估补货需求。排查下来问题不在模型而在于没有把缺货回补效应考虑进去上一周缺货的SKU这周会有补偿性需求增长。后来在特征里加了“缺货天数”这个标记模型才真正把这段需求接住了。这件事让我养成了一个习惯每次预测结果出来先对比“预测值 vs 上次预测值”的差异方向再去看业务侧最近发生了什么而不是直接丢给模型背锅。这方案跑了一年多回过头看最大的价值不是预测精度提升了多少而是让补货计划从拍脑袋变成了有依据的讨论。希望帮到你。本文还有配套的精品资源点击获取