1. 项目概述与需求拆解1.1 战储稳备场景的特殊性在哪这些年我一直在做应急保障类的信息化项目经手的系统从早期的单机物资台账到后来的B/S架构管理平台再到现在的“战储稳备大模型人工智能动态管控系统平台软件”说实话这个项目名的每一个词都不是白给的。“战储”对应战略储备“稳备”对应稳定保障合在一起就是一套面向战略储备物资的全生命周期动态管控体系。为什么叫“动态管控”而不叫“管理”一字之差背后是需求层次的完全不同。传统管理系统的核心是“记账”物资入库、出库、盘点、报废流程走完数据更新就算完事。但真正的战储场景里物资放在仓库里是会“变质”的环境温湿度会波动库存数量会因紧急调拨而变动设备状态会随使用年限而劣化这些问题如果等人工巡检发现往往已经造成了损失。大模型在这一场景里解决的不是“记账”问题而是“理解”和“预判”问题。比如系统读取温湿度传感器数据后结合历史维护记录、物资特性说明和外部环境数据自动判断当前存储条件是否处于安全区间并生成处置建议——这种能力靠传统规则引擎很难实现因为规则是死的而现实场景的组合是无穷的。这个项目适合谁来参考一是做物资储备管理、应急保障、仓储物流信息化的产品经理和技术负责人二是准备把大模型落地到具体行业场景的算法工程师三是对“AI传统行业”融合感兴趣、想找一个完整落地案例的学习者。1.2 用户真正想要什么从“看得见”到“管得住”我在前期需求调研时跟一线仓管人员聊过很多次他们的痛点非常一致系统里什么数据都有但关键信息要靠人翻报表才能发现。比如某个批次物资临近保质期Excel表格里明明标着日期但没人每天去翻一遍几千行数据结果就是过期了才发现。所以这个平台软件的核心目标可以拆成三层看得见所有储备物资、设施设备、人员作业的实时状态一屏统览不靠翻表管得住异常情况能自动识别、自动预警、自动生成处置建议不再依赖老师傅的经验留得下每一次预警、处置、复盘都形成知识沉淀让系统的判断能力随使用时间越来越强这三层目标前两层是传统信息化系统加一点智能化就能实现的第三层才是大模型真正发挥价值的地方。我见过太多项目做完前两层就验收了但真正让客户觉得“值回票价”的恰恰是第三层——知识沉淀和自主决策辅助。2. 总体架构设计与关键技术选型2.1 整体架构不是所有模块都需要大模型先给结论这套系统绝不是“什么都往大模型里塞”的堆砌式设计。我的架构原则是——传统逻辑能解决的问题用传统逻辑规则能覆盖的用规则大模型只负责那些“需要理解力”的部分。系统整体分五层感知层对接温湿度传感器、烟感、门禁、定位标签、视频监控等物联网设备统一接入物联网关数据层数据分类存储关系型数据进PostgreSQL时序数据进TDengine向量数据进Milvus文件数据进MinIO智能层这是大模型的核心层负责自然语言交互、知识问答、报告生成、辅助决策、异常研判业务层物资管理、设备管理、人员管理、预警管理、调度管理、值班管理六大模块展示层Web管理端、大屏可视化端、移动端为什么数据层要拆三个数据库因为数据类型差异太大。温湿度传感器每分钟产生一条数据一张表一年就是几十万行用关系型数据库存查询性能很难保证而物资文本描述、规章制度、历史处置案例这种非结构化内容又需要向量化之后才能被大模型高效检索。把数据按特性分库是架构设计的第一个关键决策。智能层的设计我多说几句。这里我用了“模型网关”的思路大模型本身不直接暴露给业务层而是通过统一的模型服务接口向外提供“对话”“摘要”“分类”“抽取”四类原子能力。业务层需要什么功能就组合调用这四类能力。好处显而易见将来换模型也好、升级模型也好业务层完全不用动。2.2 大模型选型为什么我选择了7B级本地部署选型阶段我对比了三条路线一是调用云端大模型API二是本地部署7B级开源模型三是本地部署70B级大模型。综合评估下来选了第二条——本地部署7B级开源模型具体用的是Qwen2.5-7B-Instruct。先看云端API路线为什么被否掉。战储场景很多数据涉及敏感信息物资清单、调度计划、人员配置这些数据一旦出网合规风险很大。而且储备库的网络环境并不稳定很多库区在偏远地区信号条件差完全依赖公网接口的可用性没法保证。70B级大模型为什么也没选硬件成本是一方面更核心的问题是推理延迟。7B量化模型在单张消费级显卡上生成速度能达到40-60 token/s而70B模型即使量化后也要双卡甚至四卡才能跑起来生成速度还掉到20 token/s以下。对于系统里频繁的短文本处理需求这种延迟差异是灾难性的。实测下来7B模型配合“系统提示词检索增强”做得好的话在领域任务上的表现完全够用。2.3 全套技术栈一览直接照着选型就行层级技术选型选择理由前端Vue3 Element Plus组件生态成熟社区案例多自定义表格和表单开发效率高后端Spring Cloud Python FastAPI 混合Java负责业务逻辑Python负责AI推理各取所长主库PostgreSQL 15支持JSONB和全文检索物资台账的复杂查询需求都能满足时序库TDengine 3.x写入性能强悍单机每秒几十万点写入无压力部署运维简单向量库Milvus 2.4开源向量检索方案里性能与易用性的平衡点推理框架Ollama vLLM 双轨Ollama快速验证vLLM生产部署兼顾开发效率与吞吐物联网接入EMQX 5.x单节点支持百万级连接协议适配插件丰富大屏可视化DataV内置大量行业模板应急场景的图表组件开箱即用我特别想说明一下为什么后端要搞成“Java Python”混合。纯Java团队写AI推理代码太痛苦纯Python团队写高并发业务服务也不靠谱。我的做法是Spring Cloud负责用户、权限、流程、报表这些稳定业务FastAPI独立部署一套AI服务专门承接“对话、摘要、向量化、模型推理”这四类任务。两边通过HTTP接口通信职责清晰团队协作起来也舒服。3. 大模型本地部署、行业化改造与微调复盘3.1 基于Ollama的本地部署实操Ollama是目前本地跑大模型最省心的方案没有之一。它把模型下载、量化转换、API服务、GPU调度全封装好了一条命令就能把模型跑起来。我在Ubuntu 22.04服务器上的部署过程如下# 安装Ollama curl -fsSL https://ollama.com/install.sh | sh # 拉取Qwen2.5-7B-Instruct模型4bit量化版 ollama pull qwen2.5:7b-instruct-q4_K_M # 启动服务默认监听11434端口 ollama serve模型跑起来之后通过Ollama的REST API直接可以调用。这里有个小坑Ollama默认只监听127.0.0.1如果推理服务跟业务服务不在同一台机器需要改一下systemd配置在服务文件里加上环境变量。注意修改Ollama监听地址时要先确认服务器防火墙只放行内网IP严禁暴露到公网。这是安全红线我见过有团队把Ollama直接暴露公网被薅算力的案例。模型跑起来只是第一步。Ollama适合开发验证和低并发场景真要上生产、扛并发还是得用vLLM做推理服务化。我用vLLM做了同样的模型部署吞吐量比Ollama高好几倍而且vLLM支持连续的请求批处理多用户同时提问时不会互相阻塞。3.2 行业知识注入用RAG让模型“懂行”本地部署的7B模型有一个明显短板通用知识还行但涉及行业规章制度、具体设备手册、历史处置案例这些“私域知识”模型基本一无所知。解决这个问题的主流方案是RAG检索增强生成。我实现的RAG流程如下把《战略储备物资管理规定》《设备维护保养规程》等文档按章节切片每片500-800字相邻切片保留100字重叠避免关键信息正好被切断用嵌入模型把切片向量化存入Milvus向量库用户提问时先把问题向量化在向量库中检索最相关的3-5个片段将检索到的片段拼接到系统提示词里让大模型基于这些材料回答这套流程跑通之后效果提升非常明显。之前直接问模型“乙类物资的存储温度要求上限是多少”模型会一本正经地编一个答案接入RAG后它会先从知识库检索到“乙类物资存储温度不得超过25摄氏度”的规定原文再组织语言返回准确率从不到40%提升到85%以上。RAG还有一个容易被忽略的细节嵌入模型的选择。我用的是开源嵌入模型bge-large-zh中文场景效果不错而且它输出768维向量跟Milvus默认配置匹配得很好。别小看这个选择嵌入模型的效果直接决定了检索的召回率检索召回率又决定了RAG的最终效果。3.3 大模型微调方案LoRA让模型学会“格式严谨”RAG解决的是“知识”问题但模型生成的格式和语气还是很“通用”。战储场景对输出格式要求极高预警通知单必须是固定模板物资调拨建议必须列出风险等级、调拨数量、替代方案这些结构化字段。为了让模型输出规范化我对Qwen2.5-7B做了LoRA微调。微调用的是开源框架LLaMA-Factory数据准备阶段我整理了一千多条历史处置记录和业务问答对人工改写成规定格式。训练参数如下model_name_or_path: Qwen/Qwen2.5-7B-Instruct stage: sft finetuning_type: lora lora_rank: 32 lora_alpha: 64 learning_rate: 2e-4 num_train_epochs: 3 max_seq_length: 4096 batch_size: 4 gradient_accumulation_steps: 8训练在一张NVIDIA RTX 4090上跑了约8个小时显存占用稳定在18GB左右。这里有个参数理解的要点lora_rank决定了低秩矩阵的维度越大则适应能力越强但过大容易过拟合。数据量只有一千多条rank取32是安全的“learning_rate设成2e-4比全量微调常用的1e-5要高一个量级因为LoRA只更新极少量参数需要更大的步长才能有效收敛”。微调后的模型效果很明显格式遵从率从不到60%提升到97%以上字段缺失、格式错乱的问题基本消失。而且因为只训练了LoRA适配器基础能力没有丢掉通用对话能力几乎不受影响。实操心得LoRA微调有一个关键技巧——训练数据里要留出10%左右的样本来做验证不要全量丢进去训练。我第一版没留验证集训练完才发现模型在训练集上表现好但一碰新问题就乱套返回去加了验证集重训才解决。3.4 模型路由轻任务走小模型重任务走大模型部署上线后遇到一个实际问题系统里有大量短文本分类、命名实体识别这类轻量任务用7B模型去做杀鸡用牛刀不说GPU资源也被白白消耗。比如“判断某条预警记录的紧急程度”这种任务用一个300M的BERT类模型就能做到95%的准确率而且推理延迟只有几十毫秒。所以我在智能层加了一个模型路由模块逻辑很简单文本分类、要素抽取类任务 → 走轻量级模型开放问答、报告生成、决策建议类任务 → 走Qwen2.5-7B涉及长文档理解和多步推理的任务 → 走Qwen2.5-7B加长上下文模式或结合RAG多轮检索这个路由规则上线后GPU平均利用率从70%降到40%左右但整体响应速度反而快了关键是省钱——同样的资源可以支撑更大的业务量。4. 核心功能模块与实现细节4.1 动态台账与智能编码识别物资台账是这套系统的地基。传统台账是一张静态表记录物资编码、名称、批次、数量、有效期、存放位置。动态管控要求台账随实物的每一次变化而自动更新。我做了两个智能化增强。第一个是智能编码识别新增物资时系统自动识别物资名称、规格型号、生产日期等关键字段再结合内部编码规则自动生成物资编码。这里面用到大模型的文本抽取能力把非结构化的送货单、验收单内容转成结构化数据。实测下来对格式规范的单据识别准确率能做到95%以上。第二个是有效期智能提醒。传统实现是写一个定时任务每天扫描数据库里有效期字段快到期就发提醒。我的改进是让系统根据物资特性和历史损耗数据动态生成“提前预警天数”普通物资提前30天预警对温度敏感、容易变质的物资提前60天预警对有特殊储存要求的物资则结合实时环境监测数据推算更精准的剩余可用时长。4.2 全要素感知与异常识别这一块是把物联网数据和大模型判断结合起来。库区内布置的温湿度、烟感、水浸、门磁、人体红外传感器每10秒回传一条数据。平台实时监测这些数据一旦发现异常触发联动处置流程。举例来说某冷库的设定温度是-18℃实际温度传感器回传-16℃超过了允许偏差。传统系统只会发一条“温度偏高”的告警但我们这套系统的大模型会进一步分析该冷库存放的物资是什么、该物资在-16℃下的变质风险有多大、历史同期是否有类似波动、预案中规定的处置措施是什么最终生成一条包含风险等级、原因分析、处置建议的完整预警工单。这个过程听起来复杂实现起来其实就是调用一次大模型接口输入是传感器数据、物资基本信息、历史温度趋势、预案文本输出是一份结构化分析报告。关键在于提示词的工程化设计我在提示词里把“输出格式限制为JSON”写死了这样后续系统可以直接解析模型输出自动创建工单。4.3 智能辅助决策与应急调度当突发事件发生时系统的价值体现在“把应对时间从小时级压缩到分钟级”。我设计了一个应急调度智能体模拟值班主任的分析思路第一步接收事件描述如“XX库区发现火灾报警”大模型自动解析出事件类型、涉及区域、影响范围。第二步系统自动从数据库中检索该区域存放了哪些物资、这些物资的易燃易爆等级、最近的消防器材位置、周边值班人员名单、应急预案库中的对应处置方案。第三步大模型综合这些信息生成调度建议建议调配哪些救援力量、优先转移哪些物资、是否需要外部支援、按照什么顺序执行处置。调度建议直接生成标准的调度令文本经值班员确认后一键下发。这一步是整个系统里最复杂的模块也是客户觉得最“惊艳”的模块。它把原本需要老师傅多年经验才能完成的判断变成了一个可复制、可追溯的自动化流程。4.4 数据安全与权限管控体系战储系统对数据安全的重视程度怎么强调都不过分。这个平台软件从设计之初就把安全作为一等公民来对待而不是事后打补丁。先说权限模型。我采用了“堡垒机分权分域”的模式。堡垒机负责所有运维操作的审计留痕防止运维人员越权访问业务数据分权分域是三层控制功能权限能看哪些菜单、数据权限能看哪些库区的数据、操作权限能执行哪些操作。比如一个负责A库区的保管员登录系统只能看到A库区的数据和对应的物资操作菜单B库区的数据他在界面上根本看不到接口层面也做了同样的数据过滤。大模型服务的安全更需要注意。模型本身不能直接访问数据库所有查询请求都通过业务后端的中转由业务后端根据用户身份做一次数据范围校验再把过滤后的数据拼进提示词。这样从机制上保证了大模型“知道得少、泄露不了”。5. 关键技术环节落地实录5.1 智能问答/值班助手模块的实现这个模块本质上是一个“7×24小时在线的AI值班员”让仓管员可以通过自然语言直接查询系统数据、获取操作指引。它实现起来不复杂但细节非常考验功夫。核心流程是用户输入问题系统先通过意图识别确定用户想干什么再调用对应的数据查询接口获取数据最后让大模型根据数据生成答复。这里最关键的一步是数据查询我采用了“Query改写参数抽取”的方式用户问“A区还有多少乙类物资”系统先用大模型把这句话改写为SQL查询意图并抽取“A区”“乙类物资”两个参数然后通过业务后端查库再把查询结果回传给模型生成自然语言答复。实际部署时发现完全靠大模型生成SQL去查库风险太大一个语法错误就会导致接口报错。我的方案是让大模型只生成“查询意图代码”比如GET_MATERIAL_STOCK具体的SQL查询语句由后台的规则引擎编写。这样生成结果可控准确率和安全系数都大幅提升。5.2 预测性维护的关键参数设置设备预测性维护是这个平台的一大亮点。体现在两个方面一是基于时间序列分析的设备状态趋势预测二是基于大模型文本理解的故障根因分析。时间序列预测这块我选用了轻量级的Prophet库对每台设备的关键运行指标如制冷机组的主机电流、排气温度、油压差分别建模。模型输入过去30天的数据预测未来7天的变化趋势。当预测值即将超出设备正常阈值时提前触发维护工单。大模型在故障根因分析中扮演的角色是这样的设备报警时系统自动把设备历史运行数据、维修记录、报警代码、操作手册文本打包让大模型给出可能的故障原因排序和对应的检修建议。传统运维模式下一次故障平均需要工程师现场查看后翻阅资料才能确定检修方向有了大模型辅助检修方向可以在报警后5分钟内生成大幅缩短了停机排查时间。5.3 大模型推理性能调优记录大模型服务上线初期响应延迟一度达到8秒以上完全不可接受。我记录了完整的调优过程供大家参考第一步确认瓶颈。用监控工具看到GPU利用率只有50%左右但请求排队时间很长。这说明瓶颈不在GPU算力而在Ollama的并发处理机制——Ollama默认只能同时处理一个请求其他请求排队等待。第二步换推理框架。把生产环境的Ollama替换为vLLMvLLM我配置了连续批处理可以让多个请求同时运行在GPU上显存够用的情况下并发能力成倍提升。第三步优化模型量化。从Q4量化切换到Q8量化试了一下生成质量略有提升但显存占用上升了约25%。考虑到当前业务场景对质量要求足够而且服务器显存有余量最终保留了Q8量化。第四步加提示词缓存。对于固定前缀的系统提示词几千字的管理规定开启prompt caching后这部分重复计算直接省掉。这四步做完单请求响应时间从8秒降到2秒以内并发能力从1提升到8。下面是优化前后的对比数据指标Ollama优化前vLLM优化后单请求平均响应8.2秒1.8秒最大并发数18GPU利用率45%-60%85%-95%长文本生成速度42 token/s55 token/s注意如果模型推理要对接的业务有严格的响应时间要求建议在模型网关层加超时控制和降级逻辑。我设置了“重任务走大模型、轻任务走规则引擎”的降级策略大模型超时3秒就自动切换到规则引擎兜底保证用户的请求永远有响应。6. 常见问题与排查技巧实录6.1 部署与运维高频问题速查现象原因解决办法Ollama模型拉到98%就卡住网络不稳定断点续传有问题换国内镜像源或手动下载GGUF文件后用Modelfile导入大模型回答内容偏离主题提示词中缺少角色限定和范围限定给提示词加“你是战储管理系统的值班助手”角色前缀并明确不在知识库范围内的问题拒答vLLM启动报显存不足模型大小与GPU显存不匹配估算公式模型权重GB×1.2上下文长度×0.002超过显存85%就需换小量化模型向量检索结果不相关文档切片粒度不合适或重叠区太小调低切片字数到300-500重叠区增加到150字效果通常能明显改善前端页面等接口等到超时大模型生成时间过长网关层加异步化接口先返回“生成中”状态模型生成完成后通过WebSocket推送结果6.2 三个让人印象深刻的坑第一个坑是RAG检索效果看起来很好但大模型就是不用检索到的资料。排查后发现是提示词里检索内容的位置放得太靠后了模型在生成时根本“注意”不到。解决方法很简单把检索到的文本片段放在用户问题前面并用明确的标识符区分比如“【参考资料】”和“【用户问题】”。第二个坑是LoRA微调后模型“失忆”。微调后的模型在领域任务上表现优秀但问它“你好”这种基础对话回复却变得语无伦次。原因是训练时把所有数据都格式化成了一种模板模型把“看见模板就输出固定格式”学得太狠。解决方法是训练数据里混入5%-10%的通用对话数据保住基础能力。第三个坑是生产环境推理服务偶发OOM。排查发现是vLLM的KV Cache设置过大跟模型权重一起把显存挤爆了。解决方法是显存管理策略调成自动模式并限制最大并发数。这个问题在长文本处理场景下尤其容易出现建议上线前用实际业务数据做一次压力测试。6.3 战储场景的独有经验总结从项目立项到上线运维这个系统前前后后做了一年多有些经验和教训值得分享给大家。第一大模型项目不要从“最炫的功能”开始做。这个项目最初客户想先做智能调度但我的建议是先做“智能问答”和“预警分析”——前一个用RAG就能实现后一个用规则加重模型就能跑通。这两个模块能让客户快速看到价值建立起信任后面的高级功能推进才会顺利。第二模型能力边界要在需求评审时就讲清楚。很多客户以为大模型是万能的问它什么都能答。实际上7B模型在垂直领域的能力上限就摆在那里不配合RAG和微调根本没法用。一定要在项目初期就建立“模型知识库规则引擎”三位一体的意识客户对这个架构理解到位了后续的配合也会顺畅很多。第三数据的质量直接决定大模型应用的天花板。梳理了客户的历史数据后发现大量表格存在数据缺失、格式不统一、口径不一致的问题这些数据不治理模型训练和RAG检索的效果都无从谈起。项目排期里一定要留出专门的数据治理阶段这个钱和精力不能省。第四系统的可观测性设计要前置。大模型应用调试起来比传统软件困难得多因为模型的输出有一定随机性。我的做法是所有模型请求统一记录日志包括输入提示词、输出结果、响应耗时、模型参数设置。遇到反馈说“系统回答不对”直接查日志就能还原现场排查效率提升巨大。7. 写在最后这套系统的边界与可能性项目上线半年多我个人的体会是所谓“人工智能动态管控系统”本质上不是让AI替代人而是让AI把人在海量信息里“大海捞针”的时间和精力节省下来让人更专注于真正需要经验判断的决策。这套系统目前能做的事情已经很具体自动监控储备物资状态、智能预警异常风险、辅助生成处置方案、沉淀行业知识、7×24小时回答一线人员的业务问题。而它的边界也同样明显大模型不产生“未知的知识”它的所有判断都基于喂给它的数据和前提遇到从未见过的新情况它依然会给出可能不准确的答案。最后分享一个很实用的小技巧大模型系统的提示词要当代码来维护。我在项目里专门建了一个Git仓库所有提示词都放在里面每次修改都要走代码审查流程。这样做的原因很简单——提示词就是逻辑逻辑变了要有记录记录乱了系统就失控了。这个习惯帮我避免了好几次“不知道哪个环节改了配置导致输出结果大变”的现场事故。