简介这份《零售库存优化中小连锁超市的DeepSeek需求预测模型搭建》PDF面向具备数据分析和深度学习基础、从事中小连锁超市运营管理的专业人士可系统应对需求预测不准、库存积压与缺货并存等核心库存管理痛点。资源共1个PDF文件压缩包约1.61MB全文30页目录、文字与图表信息完整可正常阅读。内容从中小连锁超市库存管理现状与传统方法局限切入依次讲解DeepSeek模型原理、数据收集与清洗、特征提取与归一化、模型搭建及参数选择、损失函数监控、过拟合与欠拟合处理并通过库存补货决策、商品陈列优化、促销活动规划等实际案例展示从环境准备、模型训练到评估验证的完整落地路径。目前已有98人学习下载适合用于指导中小超市科学制定补货与促销策略提升运营效率和整体盈利能力。1. 库存优化先把预测做对DeepSeek需求预测的切入路径库存优化最直接的杠杆不是采购谈判而是把“未来两周每种货能卖多少”这个信号算准。中小连锁超市一个典型的盘面是6000到15000个SKU、3到30家门店日销量序列里混着周末脉冲、生鲜折扣、天气突变和本地学校考试传统时间序列模型在这种多源噪声下很容易失真于是业务总是退回“店长拍脑袋”。DeepSeek参与需求预测的价值在于能把非结构化外生信息直接接进预测流程——促销海报文案、区域天气、节假日安排这些原本需要人工编码成特征的东西现在用自然语言告诉模型即可。但这不意味着让大模型凭空生成数字更可靠的做法是把控制数据窗口、预测粒度和输出格式让DeepSeek在“历史证据加外部事件”的约束下做推断。这篇文章按一条可复现的落地路径展开先定预测粒度与数据口径再讲DeepSeek API的接入与提示词参数然后把预测结果换算成安全库存和采购单最后一节处理重试、成本与回测验证。适合已经在跑进销存系统、想给库存模块加一个AI预测层的中小零售团队。2. 需求预测模型的建模边界数据粒度、上下文构造与DeepSeek部署选型采购、运营、店长对“预测模型”的理解经常打架做分析和做业务的人各说各话。跑通之前得先把建模边界、数据口径和部署形态三件事定死否则后面所有代码都是空中楼阁。2.1 需求预测选型对比ARIMA、XGBoost与DeepSeek的边界传统做法不是不能用而是维护成本高。ARIMA要求序列平稳超市日销量受促销冲击能瞬间放大十几倍差分和季节调整追不上这种非平稳变化XGBoost能建模非线性但每个SKU、每家门店都要构造滞后特征、促销虚拟变量、天气平滑项中小团队几千个SKU做下来特征口径每天都在变模型上线一个月就没人敢信了。DeepSeek在这条链路里的定位不是替代所有时序算法而是解决“外生因素难进模型”的问题。促销文案、本地事件、天气描述这些非结构化信号在传统模型里要靠人工打标在DeepSeek这里直接作为自然语言输入。但它的边界也很明确LLM不是靠序列内部自相关做数值递推的机器更擅长的是把外部信息翻译成先验判断。所以适合日粒度、周粒度的需求推断不适合分钟级实时补货。对比项ARIMAXGBoostDeepSeek数据需求仅历史销量销量加大量特征销量加自然语言背景外生因素接入难需人工编码中等特征工程量大直接描述即可特征工程低高低可解释性差分项难解释特征重要性可看给出理由文本上线成本低高中取决于调用量选型结论很直接如果只有销量一条序列用ARIMA或指数平滑就够了有稳定特征体系就上XGBoost想让促销、天气、本地事件以最低成本进模型才轮到DeepSeek。多数中小连锁的实际情况是三者并行DeepSeek负责把外生因素量化XGBoost负责稳定输出后面章节会讲这个混合用法。2.2 预测粒度与数据口径SKU乘门店的日销量才够用先踩一个最常见的坑销量不等于需求。货架空了之后的销售记录是0但真实需求还在拿缺货期的销量喂模型会系统性低估热销品的需求。处理办法是在清洗时保留门店报缺标记把断货日的记录单独打标模型可以学到“这天卖没了”和“这天没人买”的区别。粒度选择上SKU乘门店逐格预测在统计上不成立。一个300平米的社区店大量SKU一周只卖出个位数逐格预测的误差会吞掉信号。我一般会做两层先按“品类乘门店”做日粒度预测再把预测总量按该SKU在品类里的历史销售份额分摊下去。这样既保留了门店差异又避开稀疏矩阵。2.2.1 预测窗口历史给多少、未来预测多远历史窗口太短学不到季节性太长塞不进上下文。我的通用做法是历史取120天其中最近14天给日粒度明细之前的按周聚合未来预测14天。生鲜类预测3到5天就够因为日配把风险窗口压短了常温商品预测14天对齐补货周期。窗口参数在提示词里写清楚模型才知道往哪个尺度上判断。2.3 清洗历史数据用SQL把销量、促销、天气拼成一张宽表数据准备阶段不要用Python来回倒腾直接在数仓或业务库里拼宽表。下面这段SQL是我在中小连锁项目里的标准模板把POS流水、促销计划、天气、节假日、商品主数据join成一张表后续喂给DeepSeek或特征工程都用它。WITH daily_sales AS ( SELECT store_id, sku_id, sale_date, SUM(CASE WHEN is_return 0 THEN qty ELSE 0 END) AS qty, MAX(CASE WHEN stockout_flag 1 THEN 1 ELSE 0 END) AS stockout FROM pos_detail WHERE sale_date DATE_SUB(CURDATE(), INTERVAL 120 DAY) GROUP BY store_id, sku_id, sale_date ) SELECT s.store_id, s.sku_id, s.sale_date, s.qty, s.stockout, p.promo_type, p.promo_discount, w.temperature, w.weather_code, CASE WHEN h.holiday_name IS NOT NULL THEN 1 ELSE 0 END AS is_holiday, m.first_category, m.shelf_life_days, m.price_tier FROM daily_sales s LEFT JOIN promo_plan p ON p.store_id s.store_id AND p.sku_id s.sku_id AND p.sale_date s.sale_date LEFT JOIN weather_daily w ON w.store_id s.store_id AND w.sale_date s.sale_date LEFT JOIN holiday_calendar h ON h.sale_date s.sale_date LEFT JOIN sku_master m ON m.sku_id s.sku_id;这段SQL有三个关键点。第一促销必须join计划表而不是实际发生表否则预测时拿不到未来促销训练时却用了促销结果造成数据泄漏第二退货用is_return排除掉残次损耗不走销量字段单独记录第三stockout_flag来自门店报缺单缺货日的销量要在提示词里单独标注让模型知道这天数据是截断的。2.4 DeepSeek部署方式选型本地部署与API调用的取舍部署形态决定整个项目的节奏和预算。API方式接入最快因为DeepSeek的接口兼容OpenAI格式用OpenAI SDK改一下base_url和api_key就能调通VSCode里常见的AI插件、Codex这类CLI工具也都是这么接DeepSeek的。数据敏感度不高、SKU数量在几千级别的场景API足够。本地部署适合两种团队一种是销售数据完全不能出内网财务和供应商协议数据敏感另一种是预测频次极高每天跑全量SKUAPI费用失控。硬件上7B和14B参数量级的量化模型用消费级显卡能跑但要支撑几十家门店的全量预测需要的不是单卡推理而是稳定的批处理吞吐所以先算清并发再决定要不要自建。我的建议是分阶段先用API把预测流程和提示词效果跑通确认业务指标确实改善再考虑把高频链路迁到本地推理保留API作为重点SKU的reasoner通道。部署不是目的预测质量和成本可控才是。3. 用DeepSeek API搭建需求预测提示词设计、参数调节与批量解析这一章是核心实现。数据清洗好了部署形态定了接下来就是让DeepSeek产出可用的预测结果。重点是三个API参数怎么配、提示词怎么构造、批量调用时怎么解析和容错。3.1 DeepSeek API的调用方式与预测参数配置DeepSeek API的调用方式和OpenAI基本一致base_url指向https://api.deepseek.com模型名用deepseek-chat或deepseek-reasoner。需求预测这个场景deepseek-chat足够它响应快、支持结构化输出适合批量任务deepseek-reasoner擅长复杂推断但输出慢、当前不开放temperature控制项适合用来处理重点SKU或异常品类的周度复盘。参数配置上预测任务和聊天任务差别很大。temperature建议压在0.2以下预测要的是稳定可复现不是发散创意max_tokens给1200保证JSON能完整输出不截断开启response_format为json_object强迫模型返回结构化结果而不是散文。下面这张表是我在预测场景下的默认参数。参数推荐值说明modeldeepseek-chat速度快支持JSON输出temperature0.1-0.2降低输出随机性max_tokens1200容纳14天预测数组加理由文本response_formatjson_object结构化输出便于程序解析timeout60秒批量任务预留更长超时3.2 提示词模板把历史窗口和促销计划结构化提示词不是把历史数据全塞进去让模型自己悟而是要把上下文组织成“数据加规则”的结构。系统提示词定义角色和输出格式用户提示词放历史窗口和外部事件。下面是我用的模板框架。SYSTEM_PROMPT 你是连锁超市的需求预测分析师。 你将收到一个SKU在某门店的历史销量、促销、天气和节假日信息。 请预测未来14天的每日销量输出严格JSON不要输出其它内容。 格式 { sku_id: 1000231, store_id: S045, forecast_daily: [12, 15, 14, 20, 18, 16, 22], reasons: [周五促销预计带来约30%增量, 下周一开始连续降雨客流下降] } 要求 1. 所有预测值必须是正整数 2. reasons最多写3条每一条都要有可核对的依据 3. 如果提供了缺货标记该日真实需求应高于记录值 def build_user_prompt(row): return f SKU: {row[sku_id]} 门店: {row[store_id]} 品类: {row[first_category]} 保质期: {row[shelf_life_days]}天 价格带: {row[price_tier]} 最近8周周销量(聚合值): {row[weekly_series]} 最近14天日销量: {row[daily_series]} 缺货标记(1为当日缺货): {row[stockout_series]} 未来14天促销与天气事件: {row[future_events]} 请基于以上信息输出未来14天日销量预测。提示词里最容易被忽略的是缺货标记。如果历史里有一天销量是0但实际是卖空了模型会把这个0当成正常需求后续预测就偏低。把缺货标记单独给出来等于告诉模型“这里的数据被截断了你推断真实需求时要修正”。future_events这一项必须包含促销计划、节假日和天气预报这是DeepSeek相对传统模型的核心增量。3.3 批量预测与JSON解析的完整Python实现真实场景不会一次只调一个SKU而是每天跑几百上千个。批量调用的代码需要注意三点并发控制、JSON容错、失败重试。下面这段代码演示了完整的调用加解析流程。import json import os import time from concurrent.futures import ThreadPoolExecutor, as_completed from openai import OpenAI client OpenAI( api_keyos.getenv(DEEPSEEK_API_KEY), base_urlhttps://api.deepseek.com ) def parse_forecast_response(text, sku_id, store_id): 解析模型返回的JSON处理常见的截断和格式问题。 text text.strip() if text.startswith(): text text.split(\n, 1)[1].rsplit(, 1)[0] try: data json.loads(text) except json.JSONDecodeError: # 尝试补齐截断的JSON比如缺右括号 fixed text.rstrip(,. \n) ] try: data json.loads(fixed) except json.JSONDecodeError: return None forecast data.get(forecast_daily) if not forecast or len(forecast) ! 14: return None return { sku_id: sku_id, store_id: store_id, forecast: [int(x) for x in forecast], reasons: data.get(reasons, []) } def predict_single(store_id, sku_id, row): try: resp client.chat.completions.create( modeldeepseek-chat, temperature0.2, max_tokens1200, response_format{type: json_object}, messages[ {role: system, content: SYSTEM_PROMPT}, {role: user, content: build_user_prompt(row)}, ], timeout60 ) content resp.choices[0].message.content result parse_forecast_response(content, sku_id, store_id) return result except Exception as exc: print(fSKU {sku_id} 预测失败: {exc}) return None # 按门店分组同一门店顺序提交避免触发限流 all_results [] with ThreadPoolExecutor(max_workers8) as executor: future_map { executor.submit(predict_single, store_id, sku_id, row): (store_id, sku_id) for store_id, sku_id, row in task_list } for future in as_completed(future_map): result future.result() if result: all_results.append(result)这段代码里的并发数max_workers8不是拍脑袋定的。DeepSeek API的限流策略按账号并发数计算8个并发是大部分中小账号能稳定跑的水平想更高并发得在控制台申请扩容。JSON解析做了两层兜底第一层处理markdown代码块包裹的情况第二层处理截断后缺右括号的情况。如果解析完不是合法的14天数组直接丢弃而不是硬塞进补货计算坏数据比没数据更危险。3.4 混合方案DeepSeek量化外生因素XGBoost出数值直接让LLM输出销量数字在工程上有一个隐患可复现性不稳定。同一个SKU同一批上下文两次预测可能差10%上下这个波动在补货计算里会被放大。更稳的做法是让DeepSeek只做它擅长的事——量化外生因素数值预测仍交给统计模型。做法是对每个预测区间让DeepSeek输出一组影响系数比如“双十一促销对饮料品类的影响系数是1.4雨天客流减少导致销量系数0.85”然后把这组系数作为特征喂给XGBoost或者直接乘到基准预测上。这样即便DeepSeek输出的系数波动一点基准模型还在兜底不会出现预测值大幅跳变。混合模式适合对稳定性要求高的核心SKU纯DeepSeek模式适合新品的冷启动预测因为新品没有历史销量只能靠商品属性和外部事件推。4. 把预测需求变成库存补货参数安全库存与订货量计算预测本身不产生价值预测转化为采购单才产生价值。从DeepSeek拿到的14天预测序列要换算成日均需求、需求波动、安全库存和订货量这一步的工程精度直接决定库存周转率和缺货率。4.1 把预测序列转成补货参数拿到14天预测后第一件事不是直接求和而是拆出两个统计量日均需求d_avg和日需求标准差sigma。d_avg用于计算补货的基准量sigma用于计算安全库存。预测序列如果本身带了置信区间直接用区间宽度估算sigma比用历史波动更贴近未来。补货计算要考虑两个时间窗口供应商前置期lead_time和补货周期review_period。生鲜类的lead_time往往是1天日化类可能是7天如果把这两类商品混在一起批量计算安全库存会系统性失真。覆盖周期coverage等于两者之和目标库存等于覆盖周期内的期望需求加上安全库存。4.2 安全库存公式服务水平Z值与门店分级安全库存的经典公式是Z * sigma * sqrt(coverage)其中Z值是服务水平对应的标准正态分位数。95%服务水平意味着补货周期内缺货概率不超过5%Z值取1.6599%服务水平Z值取2.33。提高服务水平的代价是指数级上升的安全库存不是线性增长。服务水平Z值适用场景90%1.28低值耐用品、可接受缺货95%1.65常规日用品、标准品97.5%1.96高毛利核心SKU99%2.33处方药、急缺类商品门店和品类要分开定Z值。社区店的A类生鲜我会定95%到97.5%远郊店的B类日化90%就够。维度不要一刀切否则要么库存高企要么缺货投诉不断。生鲜类特别注意安全库存过高会直接变成损耗服务水平不是越高越好要平衡缺货损失和过期损耗两个方向。4.3 从建议订货量到采购单MOQ、配送周期与合并规则有了目标库存订货量就是目标库存减掉在库和在途。这里的工程细节在于MOQ最小起订量和配送周期。中小连锁的供应商往往要求整箱起订计算出的订货量要向上取整到MOQ的倍数否则买手手工改单会绕过整个模型。import math def calc_reorder_qty(d_avg, sigma_d, z_value, lead_time, review_period, on_hand, in_transit, moq): 计算建议订货量 coverage lead_time review_period # 目标库存 覆盖期期望需求 安全库存 target_stock coverage * d_avg z_value * sigma_d * math.sqrt(coverage) # 订货量 目标库存 - 在库 - 在途最低为0 order_qty max(target_stock - on_hand - in_transit, 0) # 向上取整到MOQ倍数 if moq 0: order_qty math.ceil(order_qty / moq) * moq return order_qty # 示例某饮料SKU日均需求30瓶日波动5瓶95%服务水平 qty calc_reorder_qty( d_avg30, sigma_d5, z_value1.65, lead_time3, review_period7, on_hand80, in_transit50, moq12 ) print(f建议订货量: {qty})参数说明on_hand是当前可售库存不包括在途in_transit是已经下单未到货的量漏掉它会导致重复订货。lead_time和review_period的单位必须一致都用天。最后按供应商分组、按配送周期合并成采购单生鲜按日配合并常温商品按周配合并不要每个SKU单独下单否则物流成本会吃掉库存优化省下的钱。5. 预测模型上线排错重试策略、token成本与滚动回测上线阶段的问题集中在三块接口不稳定、费用失控、模型效果无法证明。每块都有对应的处理手段处理完这三件事预测模型才算真正接进采购流程。5.1 应对“服务器繁忙”指数退避与熔断DeepSeek在高峰期经常返回繁忙提示批量任务如果不去处理几百个SKU的预测会连环失败。处理办法是重试加熔断重试时用指数退避第一次等1秒第二次2秒第三次4秒最多重试4次连续失败超过阈值就整个任务暂停15分钟避免在服务不可用期间空耗配额。重试代码挂在调用函数外层不污染正常流程。5.2 控制token成本聚合预测、缓存与重点SKU分层成本控制的第一个手段是减少调用次数。SKU乘门店的矩阵逐格调用token开销几个月就能超过模型本身的价值。我的做法是把预测分层C类长尾SKU不做逐格预测直接按品类历史占比分摊总量B类SKU走deepseek-chat批量预测A类核心SKU可以单独用deepseek-reasoner做周度复盘。第二个手段是缓存促销计划不变的SKU预测结果直接复用不需要每天重算。第三个手段是压缩历史窗口120天历史在prompt里全部展开token用得非常快周聚合数据保留日明细只留最近14天能省掉一半输入token。5.3 滚动回测验证用历史窗口证明预测有效模型效果要用滚动回测说话。方法很简单取过去120天数据用前106天预测后14天然后把预测窗口往后滚动重复多次。代码上控制好训练窗口和预测窗口不相交避免数据泄漏。回测指标重点看两个WAPE评估整体偏差MAPE评估单SKU表现。生鲜品类的MAPE高于30%是常态不用惊慌看趋势是不是稳定下降。每个回测周期的失败案例要单独存档把当时的上下文和实际销量存成回归测试集下次改提示词前先跑一遍回归集防止修好一个SKU弄坏一片。本文还有配套的精品资源点击获取
DeepSeek需求预测实战：从API调用到安全库存与补货计算
简介这份《零售库存优化中小连锁超市的DeepSeek需求预测模型搭建》PDF面向具备数据分析和深度学习基础、从事中小连锁超市运营管理的专业人士可系统应对需求预测不准、库存积压与缺货并存等核心库存管理痛点。资源共1个PDF文件压缩包约1.61MB全文30页目录、文字与图表信息完整可正常阅读。内容从中小连锁超市库存管理现状与传统方法局限切入依次讲解DeepSeek模型原理、数据收集与清洗、特征提取与归一化、模型搭建及参数选择、损失函数监控、过拟合与欠拟合处理并通过库存补货决策、商品陈列优化、促销活动规划等实际案例展示从环境准备、模型训练到评估验证的完整落地路径。目前已有98人学习下载适合用于指导中小超市科学制定补货与促销策略提升运营效率和整体盈利能力。1. 库存优化先把预测做对DeepSeek需求预测的切入路径库存优化最直接的杠杆不是采购谈判而是把“未来两周每种货能卖多少”这个信号算准。中小连锁超市一个典型的盘面是6000到15000个SKU、3到30家门店日销量序列里混着周末脉冲、生鲜折扣、天气突变和本地学校考试传统时间序列模型在这种多源噪声下很容易失真于是业务总是退回“店长拍脑袋”。DeepSeek参与需求预测的价值在于能把非结构化外生信息直接接进预测流程——促销海报文案、区域天气、节假日安排这些原本需要人工编码成特征的东西现在用自然语言告诉模型即可。但这不意味着让大模型凭空生成数字更可靠的做法是把控制数据窗口、预测粒度和输出格式让DeepSeek在“历史证据加外部事件”的约束下做推断。这篇文章按一条可复现的落地路径展开先定预测粒度与数据口径再讲DeepSeek API的接入与提示词参数然后把预测结果换算成安全库存和采购单最后一节处理重试、成本与回测验证。适合已经在跑进销存系统、想给库存模块加一个AI预测层的中小零售团队。2. 需求预测模型的建模边界数据粒度、上下文构造与DeepSeek部署选型采购、运营、店长对“预测模型”的理解经常打架做分析和做业务的人各说各话。跑通之前得先把建模边界、数据口径和部署形态三件事定死否则后面所有代码都是空中楼阁。2.1 需求预测选型对比ARIMA、XGBoost与DeepSeek的边界传统做法不是不能用而是维护成本高。ARIMA要求序列平稳超市日销量受促销冲击能瞬间放大十几倍差分和季节调整追不上这种非平稳变化XGBoost能建模非线性但每个SKU、每家门店都要构造滞后特征、促销虚拟变量、天气平滑项中小团队几千个SKU做下来特征口径每天都在变模型上线一个月就没人敢信了。DeepSeek在这条链路里的定位不是替代所有时序算法而是解决“外生因素难进模型”的问题。促销文案、本地事件、天气描述这些非结构化信号在传统模型里要靠人工打标在DeepSeek这里直接作为自然语言输入。但它的边界也很明确LLM不是靠序列内部自相关做数值递推的机器更擅长的是把外部信息翻译成先验判断。所以适合日粒度、周粒度的需求推断不适合分钟级实时补货。对比项ARIMAXGBoostDeepSeek数据需求仅历史销量销量加大量特征销量加自然语言背景外生因素接入难需人工编码中等特征工程量大直接描述即可特征工程低高低可解释性差分项难解释特征重要性可看给出理由文本上线成本低高中取决于调用量选型结论很直接如果只有销量一条序列用ARIMA或指数平滑就够了有稳定特征体系就上XGBoost想让促销、天气、本地事件以最低成本进模型才轮到DeepSeek。多数中小连锁的实际情况是三者并行DeepSeek负责把外生因素量化XGBoost负责稳定输出后面章节会讲这个混合用法。2.2 预测粒度与数据口径SKU乘门店的日销量才够用先踩一个最常见的坑销量不等于需求。货架空了之后的销售记录是0但真实需求还在拿缺货期的销量喂模型会系统性低估热销品的需求。处理办法是在清洗时保留门店报缺标记把断货日的记录单独打标模型可以学到“这天卖没了”和“这天没人买”的区别。粒度选择上SKU乘门店逐格预测在统计上不成立。一个300平米的社区店大量SKU一周只卖出个位数逐格预测的误差会吞掉信号。我一般会做两层先按“品类乘门店”做日粒度预测再把预测总量按该SKU在品类里的历史销售份额分摊下去。这样既保留了门店差异又避开稀疏矩阵。2.2.1 预测窗口历史给多少、未来预测多远历史窗口太短学不到季节性太长塞不进上下文。我的通用做法是历史取120天其中最近14天给日粒度明细之前的按周聚合未来预测14天。生鲜类预测3到5天就够因为日配把风险窗口压短了常温商品预测14天对齐补货周期。窗口参数在提示词里写清楚模型才知道往哪个尺度上判断。2.3 清洗历史数据用SQL把销量、促销、天气拼成一张宽表数据准备阶段不要用Python来回倒腾直接在数仓或业务库里拼宽表。下面这段SQL是我在中小连锁项目里的标准模板把POS流水、促销计划、天气、节假日、商品主数据join成一张表后续喂给DeepSeek或特征工程都用它。WITH daily_sales AS ( SELECT store_id, sku_id, sale_date, SUM(CASE WHEN is_return 0 THEN qty ELSE 0 END) AS qty, MAX(CASE WHEN stockout_flag 1 THEN 1 ELSE 0 END) AS stockout FROM pos_detail WHERE sale_date DATE_SUB(CURDATE(), INTERVAL 120 DAY) GROUP BY store_id, sku_id, sale_date ) SELECT s.store_id, s.sku_id, s.sale_date, s.qty, s.stockout, p.promo_type, p.promo_discount, w.temperature, w.weather_code, CASE WHEN h.holiday_name IS NOT NULL THEN 1 ELSE 0 END AS is_holiday, m.first_category, m.shelf_life_days, m.price_tier FROM daily_sales s LEFT JOIN promo_plan p ON p.store_id s.store_id AND p.sku_id s.sku_id AND p.sale_date s.sale_date LEFT JOIN weather_daily w ON w.store_id s.store_id AND w.sale_date s.sale_date LEFT JOIN holiday_calendar h ON h.sale_date s.sale_date LEFT JOIN sku_master m ON m.sku_id s.sku_id;这段SQL有三个关键点。第一促销必须join计划表而不是实际发生表否则预测时拿不到未来促销训练时却用了促销结果造成数据泄漏第二退货用is_return排除掉残次损耗不走销量字段单独记录第三stockout_flag来自门店报缺单缺货日的销量要在提示词里单独标注让模型知道这天数据是截断的。2.4 DeepSeek部署方式选型本地部署与API调用的取舍部署形态决定整个项目的节奏和预算。API方式接入最快因为DeepSeek的接口兼容OpenAI格式用OpenAI SDK改一下base_url和api_key就能调通VSCode里常见的AI插件、Codex这类CLI工具也都是这么接DeepSeek的。数据敏感度不高、SKU数量在几千级别的场景API足够。本地部署适合两种团队一种是销售数据完全不能出内网财务和供应商协议数据敏感另一种是预测频次极高每天跑全量SKUAPI费用失控。硬件上7B和14B参数量级的量化模型用消费级显卡能跑但要支撑几十家门店的全量预测需要的不是单卡推理而是稳定的批处理吞吐所以先算清并发再决定要不要自建。我的建议是分阶段先用API把预测流程和提示词效果跑通确认业务指标确实改善再考虑把高频链路迁到本地推理保留API作为重点SKU的reasoner通道。部署不是目的预测质量和成本可控才是。3. 用DeepSeek API搭建需求预测提示词设计、参数调节与批量解析这一章是核心实现。数据清洗好了部署形态定了接下来就是让DeepSeek产出可用的预测结果。重点是三个API参数怎么配、提示词怎么构造、批量调用时怎么解析和容错。3.1 DeepSeek API的调用方式与预测参数配置DeepSeek API的调用方式和OpenAI基本一致base_url指向https://api.deepseek.com模型名用deepseek-chat或deepseek-reasoner。需求预测这个场景deepseek-chat足够它响应快、支持结构化输出适合批量任务deepseek-reasoner擅长复杂推断但输出慢、当前不开放temperature控制项适合用来处理重点SKU或异常品类的周度复盘。参数配置上预测任务和聊天任务差别很大。temperature建议压在0.2以下预测要的是稳定可复现不是发散创意max_tokens给1200保证JSON能完整输出不截断开启response_format为json_object强迫模型返回结构化结果而不是散文。下面这张表是我在预测场景下的默认参数。参数推荐值说明modeldeepseek-chat速度快支持JSON输出temperature0.1-0.2降低输出随机性max_tokens1200容纳14天预测数组加理由文本response_formatjson_object结构化输出便于程序解析timeout60秒批量任务预留更长超时3.2 提示词模板把历史窗口和促销计划结构化提示词不是把历史数据全塞进去让模型自己悟而是要把上下文组织成“数据加规则”的结构。系统提示词定义角色和输出格式用户提示词放历史窗口和外部事件。下面是我用的模板框架。SYSTEM_PROMPT 你是连锁超市的需求预测分析师。 你将收到一个SKU在某门店的历史销量、促销、天气和节假日信息。 请预测未来14天的每日销量输出严格JSON不要输出其它内容。 格式 { sku_id: 1000231, store_id: S045, forecast_daily: [12, 15, 14, 20, 18, 16, 22], reasons: [周五促销预计带来约30%增量, 下周一开始连续降雨客流下降] } 要求 1. 所有预测值必须是正整数 2. reasons最多写3条每一条都要有可核对的依据 3. 如果提供了缺货标记该日真实需求应高于记录值 def build_user_prompt(row): return f SKU: {row[sku_id]} 门店: {row[store_id]} 品类: {row[first_category]} 保质期: {row[shelf_life_days]}天 价格带: {row[price_tier]} 最近8周周销量(聚合值): {row[weekly_series]} 最近14天日销量: {row[daily_series]} 缺货标记(1为当日缺货): {row[stockout_series]} 未来14天促销与天气事件: {row[future_events]} 请基于以上信息输出未来14天日销量预测。提示词里最容易被忽略的是缺货标记。如果历史里有一天销量是0但实际是卖空了模型会把这个0当成正常需求后续预测就偏低。把缺货标记单独给出来等于告诉模型“这里的数据被截断了你推断真实需求时要修正”。future_events这一项必须包含促销计划、节假日和天气预报这是DeepSeek相对传统模型的核心增量。3.3 批量预测与JSON解析的完整Python实现真实场景不会一次只调一个SKU而是每天跑几百上千个。批量调用的代码需要注意三点并发控制、JSON容错、失败重试。下面这段代码演示了完整的调用加解析流程。import json import os import time from concurrent.futures import ThreadPoolExecutor, as_completed from openai import OpenAI client OpenAI( api_keyos.getenv(DEEPSEEK_API_KEY), base_urlhttps://api.deepseek.com ) def parse_forecast_response(text, sku_id, store_id): 解析模型返回的JSON处理常见的截断和格式问题。 text text.strip() if text.startswith(): text text.split(\n, 1)[1].rsplit(, 1)[0] try: data json.loads(text) except json.JSONDecodeError: # 尝试补齐截断的JSON比如缺右括号 fixed text.rstrip(,. \n) ] try: data json.loads(fixed) except json.JSONDecodeError: return None forecast data.get(forecast_daily) if not forecast or len(forecast) ! 14: return None return { sku_id: sku_id, store_id: store_id, forecast: [int(x) for x in forecast], reasons: data.get(reasons, []) } def predict_single(store_id, sku_id, row): try: resp client.chat.completions.create( modeldeepseek-chat, temperature0.2, max_tokens1200, response_format{type: json_object}, messages[ {role: system, content: SYSTEM_PROMPT}, {role: user, content: build_user_prompt(row)}, ], timeout60 ) content resp.choices[0].message.content result parse_forecast_response(content, sku_id, store_id) return result except Exception as exc: print(fSKU {sku_id} 预测失败: {exc}) return None # 按门店分组同一门店顺序提交避免触发限流 all_results [] with ThreadPoolExecutor(max_workers8) as executor: future_map { executor.submit(predict_single, store_id, sku_id, row): (store_id, sku_id) for store_id, sku_id, row in task_list } for future in as_completed(future_map): result future.result() if result: all_results.append(result)这段代码里的并发数max_workers8不是拍脑袋定的。DeepSeek API的限流策略按账号并发数计算8个并发是大部分中小账号能稳定跑的水平想更高并发得在控制台申请扩容。JSON解析做了两层兜底第一层处理markdown代码块包裹的情况第二层处理截断后缺右括号的情况。如果解析完不是合法的14天数组直接丢弃而不是硬塞进补货计算坏数据比没数据更危险。3.4 混合方案DeepSeek量化外生因素XGBoost出数值直接让LLM输出销量数字在工程上有一个隐患可复现性不稳定。同一个SKU同一批上下文两次预测可能差10%上下这个波动在补货计算里会被放大。更稳的做法是让DeepSeek只做它擅长的事——量化外生因素数值预测仍交给统计模型。做法是对每个预测区间让DeepSeek输出一组影响系数比如“双十一促销对饮料品类的影响系数是1.4雨天客流减少导致销量系数0.85”然后把这组系数作为特征喂给XGBoost或者直接乘到基准预测上。这样即便DeepSeek输出的系数波动一点基准模型还在兜底不会出现预测值大幅跳变。混合模式适合对稳定性要求高的核心SKU纯DeepSeek模式适合新品的冷启动预测因为新品没有历史销量只能靠商品属性和外部事件推。4. 把预测需求变成库存补货参数安全库存与订货量计算预测本身不产生价值预测转化为采购单才产生价值。从DeepSeek拿到的14天预测序列要换算成日均需求、需求波动、安全库存和订货量这一步的工程精度直接决定库存周转率和缺货率。4.1 把预测序列转成补货参数拿到14天预测后第一件事不是直接求和而是拆出两个统计量日均需求d_avg和日需求标准差sigma。d_avg用于计算补货的基准量sigma用于计算安全库存。预测序列如果本身带了置信区间直接用区间宽度估算sigma比用历史波动更贴近未来。补货计算要考虑两个时间窗口供应商前置期lead_time和补货周期review_period。生鲜类的lead_time往往是1天日化类可能是7天如果把这两类商品混在一起批量计算安全库存会系统性失真。覆盖周期coverage等于两者之和目标库存等于覆盖周期内的期望需求加上安全库存。4.2 安全库存公式服务水平Z值与门店分级安全库存的经典公式是Z * sigma * sqrt(coverage)其中Z值是服务水平对应的标准正态分位数。95%服务水平意味着补货周期内缺货概率不超过5%Z值取1.6599%服务水平Z值取2.33。提高服务水平的代价是指数级上升的安全库存不是线性增长。服务水平Z值适用场景90%1.28低值耐用品、可接受缺货95%1.65常规日用品、标准品97.5%1.96高毛利核心SKU99%2.33处方药、急缺类商品门店和品类要分开定Z值。社区店的A类生鲜我会定95%到97.5%远郊店的B类日化90%就够。维度不要一刀切否则要么库存高企要么缺货投诉不断。生鲜类特别注意安全库存过高会直接变成损耗服务水平不是越高越好要平衡缺货损失和过期损耗两个方向。4.3 从建议订货量到采购单MOQ、配送周期与合并规则有了目标库存订货量就是目标库存减掉在库和在途。这里的工程细节在于MOQ最小起订量和配送周期。中小连锁的供应商往往要求整箱起订计算出的订货量要向上取整到MOQ的倍数否则买手手工改单会绕过整个模型。import math def calc_reorder_qty(d_avg, sigma_d, z_value, lead_time, review_period, on_hand, in_transit, moq): 计算建议订货量 coverage lead_time review_period # 目标库存 覆盖期期望需求 安全库存 target_stock coverage * d_avg z_value * sigma_d * math.sqrt(coverage) # 订货量 目标库存 - 在库 - 在途最低为0 order_qty max(target_stock - on_hand - in_transit, 0) # 向上取整到MOQ倍数 if moq 0: order_qty math.ceil(order_qty / moq) * moq return order_qty # 示例某饮料SKU日均需求30瓶日波动5瓶95%服务水平 qty calc_reorder_qty( d_avg30, sigma_d5, z_value1.65, lead_time3, review_period7, on_hand80, in_transit50, moq12 ) print(f建议订货量: {qty})参数说明on_hand是当前可售库存不包括在途in_transit是已经下单未到货的量漏掉它会导致重复订货。lead_time和review_period的单位必须一致都用天。最后按供应商分组、按配送周期合并成采购单生鲜按日配合并常温商品按周配合并不要每个SKU单独下单否则物流成本会吃掉库存优化省下的钱。5. 预测模型上线排错重试策略、token成本与滚动回测上线阶段的问题集中在三块接口不稳定、费用失控、模型效果无法证明。每块都有对应的处理手段处理完这三件事预测模型才算真正接进采购流程。5.1 应对“服务器繁忙”指数退避与熔断DeepSeek在高峰期经常返回繁忙提示批量任务如果不去处理几百个SKU的预测会连环失败。处理办法是重试加熔断重试时用指数退避第一次等1秒第二次2秒第三次4秒最多重试4次连续失败超过阈值就整个任务暂停15分钟避免在服务不可用期间空耗配额。重试代码挂在调用函数外层不污染正常流程。5.2 控制token成本聚合预测、缓存与重点SKU分层成本控制的第一个手段是减少调用次数。SKU乘门店的矩阵逐格调用token开销几个月就能超过模型本身的价值。我的做法是把预测分层C类长尾SKU不做逐格预测直接按品类历史占比分摊总量B类SKU走deepseek-chat批量预测A类核心SKU可以单独用deepseek-reasoner做周度复盘。第二个手段是缓存促销计划不变的SKU预测结果直接复用不需要每天重算。第三个手段是压缩历史窗口120天历史在prompt里全部展开token用得非常快周聚合数据保留日明细只留最近14天能省掉一半输入token。5.3 滚动回测验证用历史窗口证明预测有效模型效果要用滚动回测说话。方法很简单取过去120天数据用前106天预测后14天然后把预测窗口往后滚动重复多次。代码上控制好训练窗口和预测窗口不相交避免数据泄漏。回测指标重点看两个WAPE评估整体偏差MAPE评估单SKU表现。生鲜品类的MAPE高于30%是常态不用惊慌看趋势是不是稳定下降。每个回测周期的失败案例要单独存档把当时的上下文和实际销量存成回归测试集下次改提示词前先跑一遍回归集防止修好一个SKU弄坏一片。本文还有配套的精品资源点击获取
