关于在内网环境下本地部署人工智能模型辅助装备维修文书工作的可行性研究
关于在内网环境下本地部署人工智能模型辅助装备维修文书工作的可行性研究
摘要
随着人工智能技术的快速发展，大语言模型在文本生成、知识检索和智能问答等领域展现出巨大潜力。然而，在军事等涉密环境中，数据安全和保密要求使得依赖互联网的商用AI服务无法使用。本文提出了一种基于国产硬件平台（飞腾D2000处理器+银河麒麟V10操作系统）的完全离线大语言模型部署方案，采用Ollama推理引擎结合MaxKB知识库平台，实现了在纯内网环境下的本地AI辅助系统。本文详细阐述了系统架构设计、模型量化与适配、离线部署流程、知识库构建方法，并在实际装备维修文书工作场景中进行了验证。实验结果表明，该系统在完全断网条件下可稳定运行，轻量模型（15亿参数）推理速度达每秒10-14个汉字，标准模型（40亿参数）达每秒6-10个汉字，能够有效辅助修理日志撰写、技术档案整理、故障知识检索等文书工作，将重复性文书耗时压缩至原来的三分之一以下。同时，本文客观分析了飞腾桌面级平台在推理速度和模型容量方面的局限性，并探讨了未来配备国产AI加速芯片后的性能提升空间。本研究为涉密环境下的人工智能应用提供了一条可复制、可推广的技术路径。
关键词： 大语言模型；离线部署；飞腾处理器；银河麒麟；装备维修；知识库；检索增强生成；信息安全
一、问题的提出与研究背景
（一）研究背景
近年来，以GPT、LLaMA、Qwen、DeepSeek为代表的大语言模型技术取得了突破性进展。这类模型通过在海量文本数据上进行预训练，习得了丰富的语言知识和世界知识，能够执行文本生成、问答对话、信息抽取、逻辑推理等多种自然语言处理任务。在民用领域，AI辅助写作、智能客服、知识管理等应用已广泛落地，显著提升了工作效率。据中国信息通信研究院2025年发布的报告，国内已有超过60%的大型企业在办公场景中引入了AI辅助工具，平均文书处理效率提升40%以上。
在军事装备保障领域，维修文书工作是保障链条中不可或缺的重要环节。装备维修过程中产生的方案计划、修理日志、故障分析报告、器材消耗统计、技术总结等材料，不仅数量庞大，而且格式要求严格、用语规范明确。以我单位为例，一台装备的一次二级保养即需填写保养记录表、器材消耗登记表、工时统计表等5-7份表格，撰写修理日志1篇；一次中修则涉及维修方案、故障分析报告、质量检验记录、试车报告等10余份文书。基层维修人员往往需要将大量时间精力投入到文书材料的撰写和整理中，据统计约占工作总时间的25%-35%，严重影响了实际维修保障工作的效率。
（二）当前文书工作面临的具体困难
一是方案计划类材料繁多。维修方案、保障计划、应急预案等各类文书格式各异，每次撰写均需查阅模板、核对要素，耗时耗力。仅维修方案一项，即包含任务来源、装备现状分析、维修内容确定、器材保障计划、质量控制措施、安全注意事项等十余个必填要素，任何一项遗漏均需返工。
二是表格填写重复性高。装备履历卡、维修记录表、器材消耗登记表等表格字段固定，但需逐条手工录入，数据散落在纸质台账中，汇总统计困难。同一数据（如装备编号、维修日期）往往需要在多份表格中重复填写，既浪费时间又容易出错。
三是文字材料记录要求严格。修理日志、故障分析报告、技术总结等材料对用语规范、逻辑结构有明确要求，撰写门槛较高，反复修改占用大量精力。部分年轻同志因文字功底不足，一篇800字的修理日志需反复修改3-4遍方能通过审核。
四是历史资料检索不便。历年维修档案以纸质为主，查阅特定型号、特定故障的历史记录需逐本翻阅，效率低下。我单位现存纸质维修档案逾200册，查找某一条具体记录平均耗时15-30分钟。
（三）保密约束下的技术困境
当前，人工智能技术已在文字生成、知识检索、数据整理等方面展现出显著的效率提升能力。但商用AI服务必须联网使用，数据需上传至外部服务器，不符合部队保密规定。根据《涉密信息系统安全保密管理规定》，涉密计算机和信息系统不得连接互联网，涉密数据不得在非涉密设备上处理和存储。这意味着市面上主流的在线AI服务在军事环境中完全不可用——任何需要将数据上传至外部服务器的方案都违反保密规定。
由此产生了一个核心矛盾：一方面，AI技术确实能够显著提升文书工作效率；另一方面，保密要求使得常规AI应用路径被完全封堵。能否在完全断网的条件下，在本地计算机上运行AI模型，使其在不产生任何外发数据的前提下提供智能辅助服务？
（四）面临的技术挑战
这一问题的解决面临多重技术挑战：第一，主流AI推理框架和模型发布通常面向x86架构和NVIDIA GPU环境，而军事单位配备的国产计算机多采用飞腾、鲲鹏等ARM架构处理器，且通常不配备独立显卡，需要解决架构适配和纯CPU推理的问题；第二，离线环境无法在线下载模型和依赖包，所有资源必须预先准备并通过物理介质传入，对部署流程的完整性提出了更高要求；第三，国产操作系统（银河麒麟、统信UOS等）的软件生态与主流Linux发行版存在差异，部分依赖可能无法直接安装，需要针对性的解决方案。
二、相关技术综述
（一）大语言模型技术发展
大语言模型的发展经历了从统计语言模型到神经网络语言模型、再到Transformer架构预训练模型的演进过程。2017年，Vaswani等人提出Transformer架构，其自注意力机制有效解决了长距离依赖建模问题，成为后续所有主流大模型的基础架构。2018年，OpenAI发布GPT系列模型，验证了"大规模预训练+下游任务微调"范式的有效性。此后，模型参数规模从数亿快速增长至数千亿，能力边界不断拓展。
2023年以来，开源大语言模型生态蓬勃发展。Meta发布的LLaMA系列、阿里巴巴发布的Qwen（通义千问）系列、深度求索发布的DeepSeek系列等开源模型，在多项基准测试中接近甚至超越同期闭源模型水平。特别是2025年发布的DeepSeek-R1系列，通过强化学习训练获得了较强的推理能力，其蒸馏版本（1.5B、7B参数）在保持较好能力的同时大幅降低了硬件需求，为本地化部署提供了现实条件。
（二）模型量化与CPU推理技术
大语言模型的参数量通常在数十亿至数千亿级别，直接以浮点精度存储和运算需要大量内存和算力。以Qwen3-4B模型为例，其FP16精度权重文件约8GB，加上推理时的中间状态，至少需要12GB以上内存才能运行，且计算速度极慢。
模型量化技术通过降低权重和激活值的数值精度来解决这一问题。GGUF格式是当前CPU推理场景下最主流的量化模型格式，由llama.cpp项目定义。其Q4_K_M量化方案采用混合精度策略：使用4位量化存储大部分权重，对注意力层等关键组件保持6位精度，同时使用K-quant分组量化减少精度损失。经Q4_K_M量化后，Qwen3-4B模型体积从8GB压缩至2.4GB，压缩比约3.3:1，而在标准基准测试上的精度损失通常不超过2-3个百分点。
llama.cpp项目针对ARM架构（包括ARMv8.0至ARMv9.2的多种指令集扩展）进行了深度优化，利用NEON/SVE向量指令加速矩阵运算，使得纯CPU推理在ARM平台上成为可能。Ollama是基于llama.cpp构建的高层推理引擎，提供了模型管理、REST API服务、systemd系统服务集成等生产级功能，支持Linux ARM64平台，是目前离线部署大模型最成熟的开源方案之一。
（三）检索增强生成技术
大语言模型虽然具备广泛的世界知识，但其训练数据存在时效性限制，且无法获取特定组织的内部文档和专有知识。检索增强生成（Retrieval-Augmented Generation, RAG）技术通过在推理前先从外部知识库中检索相关文档片段，将其作为上下文注入模型输入，使模型能够基于真实、最新的资料生成回答，有效解决了模型"幻觉"（编造不存在的信息）问题。
RAG系统的核心组件包括：文档解析与分段模块（将上传文档切分为适当长度的文本块）、向量化模块（使用Embedding模型将文本块转换为高维向量）、向量数据库（存储和检索向量）、以及生成模块（将检索结果与用户问题组合后送入LLM生成回答）。在中文场景下，bge-m3（由智源研究院发布）是当前效果最优的开源中文Embedding模型之一，在C-MTEB等多个中文检索基准上表现优异。其Q4_K_M量化版本体积仅约400MB，可在CPU环境下高效运行，每段文本的向量化耗时约0.1-0.3秒。
（四）军事信息化与国产化替代
军事信息化建设对自主可控提出了刚性要求。在硬件层面，飞腾、鲲鹏等国产ARM架构处理器已广泛应用于军事办公系统；在操作系统层面，银河麒麟、统信UOS等国产Linux发行版已成为标配。这些国产平台在通用办公场景下已趋成熟，但在AI推理等新兴应用场景下的适配和优化仍处于探索阶段。
现有文献中，关于军事领域AI应用的研究多集中于目标识别、态势感知、辅助决策等方向，而面向日常文书工作的AI辅助系统研究较少。在部署环境方面，已有研究多基于x86+NVIDIA GPU平台，针对国产ARM平台纯CPU环境的离线部署实践报道不多。本文的工作填补了这一空白，为同类条件下的方案实施提供了可参考的工程实践。
三、系统总体设计
（一）设计原则
本系统的设计遵循以下五项原则：
1.安全优先原则。系统全链路不产生任何外发网络流量，所有数据存储和处理均在本机完成，满足涉密信息系统"不上网、不外传"的基本要求。
2.自主可控原则。硬件采用国产飞腾处理器，操作系统采用银河麒麟，软件组件全部为开源可审计项目，不依赖任何境外商业服务或闭源组件。
3.实用优先原则。不追求模型能力的极致，而是在现有硬件条件下选择"够用"的模型规模，确保系统响应速度在可接受范围内，优先保障日常高频任务的流畅体验。
4.易部署原则。将复杂的安装配置过程封装为自动化脚本，降低对操作人员技术水平的要求，使方案具备可复制、可推广的条件。
5.易使用原则。最终用户通过浏览器即可访问系统，无需安装客户端软件，无需掌握命令行操作，学习成本趋近于零。
（二）系统架构
本系统采用三层架构设计：
1.推理层（Ollama推理引擎）。负责加载和运行大语言模型，提供标准的REST API接口（兼容OpenAI API格式）。该层运行于宿主机操作系统上，以systemd服务形式常驻后台，监听本地网络端口（11434）。支持同时加载多个模型（对话模型和向量模型），根据请求动态调度。
2.应用层（MaxKB知识库平台）。负责知识库管理、文档解析、向量检索、对话管理和用户界面。该层以Docker容器形式运行，内部集成了PostgreSQL数据库（存储知识库元数据和对话记录）、Redis缓存（加速检索）和Web服务（提供浏览器访问界面）。应用层通过HTTP协议调用推理层的API完成模型推理。
3.数据层。包括模型文件（GGUF格式的量化权重，存储于宿主机文件系统）和知识库数据（上传的文档、分段后的文本块、向量化后的Embedding，存储于PostgreSQL和向量索引中）。
三层之间的数据流向为：用户通过浏览器向应用层发送问题；应用层对问题进行向量化（调用推理层的Embedding模型）；在向量数据库中检索相关文档片段（默认返回最相似的5段）；将检索结果与问题组合为提示词；调用推理层的对话模型生成回答；将回答返回用户浏览器展示。整个流程在本机内部完成，不产生任何外部网络通信。
（三）网络安全设计
在网络安全层面，本系统采取以下措施：
1.物理隔离。系统运行于不连接互联网的涉密计算机上，从物理层面杜绝数据外泄通道。
2.最小化网络暴露。Ollama服务虽监听0.0.0.0:11434（因Docker容器需通过宿主机IP访问），但该端口仅在局域网内可达。在单机使用场景下，可进一步配置为仅监听127.0.0.1，完全关闭外部访问。
3.防火墙策略。通过系统防火墙（firewalld）精确控制端口开放范围，仅放行必要的服务端口（8080用于Web访问，11434用于容器间通信），其余端口全部关闭。
4.无外发流量。系统运行期间不产生任何DNS查询、HTTP外联、遥测上报等外发网络行为。所有开源组件的遥测功能在离线环境下自动失效。
（四）软件组件选型
| 组件 | 选型 | 版本 | 选型理由 |
|---|---|---|---|
| 推理引擎 | Ollama | v0.32.3 | 原生ARM64支持，生产级服务管理，API兼容性好 |
| 对话模型（轻量） | DeepSeek-R1-Distill-1.5B | Q4_K_M | 轻量快速，适合日常问答，内存占用小 |
| 对话模型（标准） | Qwen3-4B | Q4_K_M | 综合能力更强，适合复杂文书撰写 |
| 向量模型 | bge-m3 | Q4_K_M | 中文检索效果最优，体积小（418MB） |
| 知识库平台 | MaxKB专业版 | v2.10.4-lts | 自包含离线安装器，ARM64原生支持，多用户 |
| 容器引擎 | Docker（MaxKB自带） | — | 应用层隔离运行，简化依赖管理 |
| 操作系统 | 银河麒麟V10 | arm64 | 国产操作系统，安全可控 |
四、关键技术与实现
（一）ARM64架构适配
飞腾D2000采用ARMv8架构（aarch64），与主流的x86_64（Intel/AMD）在指令集层面完全不同。这意味着所有二进制可执行文件必须针对aarch64重新编译，x86版本无法运行（会报"exec format error"错误）。
Ollama官方发布包提供了linux-arm64版本，但其打包格式为.tar.zst（zstd压缩的tar归档）。在离线环境下，目标机器可能未安装zstd解压工具且无法在线安装。本方案的解决策略是：在联网准备阶段即完成解压，将解压后的完整目录（包含二进制文件和共享库）作为离线介质的一部分传入目标机器，从根本上规避了对zstd工具的依赖。
Ollama v0.32及以后版本的发布包结构发生了变化，从单一二进制文件演变为包含bin/和lib/两个子目录的结构。bin/目录包含ollama主程序（约34MB），lib/ollama/目录包含运行时共享库（libggml系列、libllama系列、libomp等十余个.so文件，以及针对不同ARM指令集变体armv8.0至armv9.2的CPU优化库）。部署时必须同时安装二进制和共享库，并通过ldconfig注册动态库搜索路径，否则运行时会因找不到.so文件而失败。本方案的一键安装脚本已完整处理上述所有步骤。
（二）模型量化与多档配置策略
本方案选用的Q4_K_M量化方案是一种平衡型策略，在体积压缩和精度保持之间取得了良好平衡。各模型的量化前后对比如下：
| 模型 | 原始体积（FP16） | 量化后体积（Q4_K_M） | 压缩比 | 精度损失 |
|---|---|---|---|---|
| DeepSeek-R1-1.5B | 约3.0GB | 1.1GB | 2.7:1 | 约1-2% |
| Qwen3-4B | 约8.0GB | 2.4GB | 3.3:1 | 约2-3% |
| Qwen2.5-7B | 约14.0GB | 4.4GB | 3.2:1 | 约2-3% |
| bge-m3 | 约1.1GB | 418MB | 2.7:1 | 约1% |
在模型规模选择上，本方案采用"多档配置"策略：1.5B参数模型作为日常快速问答的主力（速度快，等待时间短）；4B参数模型作为需要更强推理能力时的备选（质量更好，速度适中）；7B参数模型作为能力上限的储备（质量最好，但速度较慢）。这种策略使用户可根据任务复杂度和时间要求灵活切换，而非一刀切地使用单一模型。
（三）离线部署流程设计
离线部署的核心挑战在于：目标机器无法访问互联网，所有依赖必须预先准备。本方案将部署流程设计为五个阶段：
1.联网准备阶段（在可上网的计算机上完成）。下载Ollama ARM64发布包并解压；下载MaxKB离线安装器；从ModelScope等国内模型仓库下载GGUF格式模型文件；编写自动化安装脚本；生成文件完整性校验清单（MD5摘要值）。
2.介质传输阶段。将上述文件通过U盘或光盘（刻录时启用数据校验）传入涉密环境。传输前后均进行MD5校验，确保文件完整性。建议优先使用U盘（可靠性高于光盘），若使用光盘则必须勾选"刻录后校验数据"选项。
3.目标机安装阶段（在飞腾机上完成）。运行一键安装脚本，自动完成架构校验、二进制安装、共享库部署、用户创建、systemd服务配置、服务启动和验证。整个过程无需人工干预，无需联网，耗时约5分钟。
4.模型导入阶段。运行模型导入脚本，自动扫描模型目录、校验GGUF文件完整性（检查文件头魔数）、生成Modelfile、调用Ollama API创建模型。5个模型全部导入约需20分钟。
5.知识库平台安装阶段。解压MaxKB离线安装器（1.26GB），运行其内置的install.sh脚本。该安装器自包含Docker引擎和所有容器镜像，安装过程不产生任何网络请求，耗时约15分钟。
（四）知识库构建方法
知识库的构建遵循RAG技术的标准流程，具体步骤如下：
1.文档上传与解析。支持PDF、Word、PPT、TXT、Markdown等常见格式。系统自动提取文本内容，处理表格、标题层级等结构信息。对于扫描件PDF，需先通过OCR工具转换为可编辑文本后再上传。
2.文本分段。将长文档切分为适当长度的文本块（chunk）。分段策略采用"按段落+滑动窗口"方式，每个chunk约300-500字，相邻chunk之间有50-100字的重叠，以确保语义完整性。分段过大会导致检索精度下降，过小则会丢失上下文信息。
3.向量化。使用bge-m3模型将每个文本块转换为1024维的浮点向量。该过程在本地CPU上完成，每个chunk的向量化耗时约0.1-0.3秒。一份100页的文档（约5万字）完成全部向量化约需3-5分钟。
4.索引存储。向量数据存入内置的向量数据库，建立近似最近邻（ANN）索引，支持高效的相似度检索。检索时通过余弦相似度计算问题向量与文档向量的匹配程度。
5.检索与生成。用户提问时，系统先将问题向量化，然后在向量索引中检索Top-K个最相似的文本块（默认K=5），将这些文本块作为上下文与问题一起送入对话模型，生成基于文档内容的回答。回答中会标注引用来源，便于用户核实。
（五）数据完整性保障与安全审计
在离线介质传输过程中，数据完整性是必须严格保障的环节。本方案采用MD5校验机制：在联网准备阶段，对所有模型文件和安装包逐一计算MD5摘要值，生成校验清单文件随介质一同传入。在目标机上，运行校验脚本逐文件比对MD5值，任何不一致均标记为"损坏"并提示重新拷贝。
实际部署中验证了该校验机制的必要性：首次使用光盘刻录传输时，因刻录软件未启用"刻录后校验"选项，导致部分大文件（4GB以上）出现静默数据损坏——文件大小完全正确，但内部字节存在错误。这类损坏无法通过简单的"看文件大小"来发现，只有MD5校验才能检出。损坏的模型文件在导入Ollama时报"supplied file was not in GGUF format"错误，经校验定位后重新拷贝即恢复正常。
在安全审计方面，本方案所用全部软件组件均为开源项目，源代码公开可查。Ollama以MIT许可证发布，其网络通信模块仅包含本地HTTP服务器实现，不存在任何外联逻辑；MaxKB以GPLv3许可证发布，其网络请求仅指向用户配置的模型服务地址，不包含遥测或数据上报功能。在离线环境下，即使代码中存在外联逻辑，也因无网络可达而自动失效，形成双重保障。
五、实验环境与部署实施
（一）硬件环境
| 项目 | 规格 |
|---|---|
| 处理器 | 飞腾D2000/8（8核ARM Cortex-A72，主频2.3GHz） |
| 架构 | ARM64/aarch64（ARMv8-A） |
| 内存 | 16GB DDR4 |
| 存储 | 512GB SATA SSD |
| 显卡 | 无独立显卡（集成显示控制器，不参与计算） |
| 网络 | 千兆以太网（实验中断开外网连接） |
飞腾D2000是面向桌面办公市场的国产处理器，其单核性能约为同期Intel Core i5的40%-50%，多核性能约为60%。该处理器不具备NVIDIA CUDA或AMD ROCm等GPU计算能力，AI推理完全依赖CPU的整数和浮点运算单元。选择该平台的原因是其为部队现有配备的办公电脑标准配置，本方案的目标即是在不新增硬件采购的前提下挖掘现有设备的AI应用潜力。
（二）软件环境
| 项目 | 版本/详情 |
|---|---|
| 操作系统 | 银河麒麟V10 SP1（arm64） |
| 内核版本 | Linux 4.19.x（kylin定制） |
| 包管理器 | yum/dnf |
| Ollama | v0.32.3（linux-arm64） |
| MaxKB | 专业版v2.10.4-lts（aarch64离线安装器） |
| Docker | MaxKB安装器自带（containerd+runc） |
（三）模型文件清单
| 模型 | 参数量 | 量化 | 文件大小 | 用途 |
|---|---|---|---|---|
| DeepSeek-R1-Distill-Qwen-1.5B | 15亿 | Q4_K_M | 1.1GB | 日常对话、快速问答 |
| Qwen3-4B | 40亿 | Q4_K_M | 2.4GB | 复杂推理、文书撰写 |
| Qwen2.5-7B-Instruct | 70亿 | Q4_K_M | 4.4GB | 能力储备（速度较慢） |
| DeepSeek-R1-Distill-Qwen-7B | 70亿 | Q4_K_M | 4.4GB | 能力储备（速度较慢） |
| bge-m3 | 5.68亿 | Q4_K_M | 418MB | 文本向量化（Embedding） |
（四）部署实施过程
实际部署于2026年7月完成，由一名具备基本Linux操作能力的技术人员执行，总耗时约3小时（含问题排查时间）。主要步骤及耗时如下：
1.介质准备与校验（约30分钟）。将U盘中的文件拷入/data/ollma目录，运行MD5校验脚本验证文件完整性。首次部署时因光盘刻录未启用校验，导致部分模型文件损坏，重新拷贝后通过。
2.Ollama安装（约5分钟）。运行install_ollama.sh一键脚本，自动完成全部安装步骤。脚本输出显示架构校验通过（aarch64）、二进制和共享库安装成功、systemd服务启动正常、11434端口监听确认。
3.模型导入（约20分钟）。运行import_models.sh，依次导入5个模型。每个模型的导入过程包括：GGUF魔数校验（确认文件头为"GGUF"标识）、生成Modelfile配置文件、调用ollama create构建模型。1.5B模型导入约2分钟，7B模型约8分钟。
4.MaxKB安装（约15分钟）。解压离线安装器（1.26GB），运行install.sh。安装过程自动加载Docker镜像、启动PostgreSQL和Redis容器、初始化数据库、启动Web服务。
5.配置与验证（约20分钟）。在MaxKB Web界面中添加Ollama模型（填写宿主机IP:11434）、配置Embedding模型（bge-m3）、上传测试文档、验证问答功能正常。
六、实验结果与性能评估
（一）推理速度测试
在飞腾D2000平台上，对不同规模模型进行了推理速度测试。测试方法为：向模型发送固定长度的提示（约100字），记录生成256个token所需时间，计算平均生成速度。每个模型重复测试5次取平均值。
| 模型 | 参数量 | 平均速度 | 首字延迟 | 生成200字耗时 |
|---|---|---|---|---|
| DeepSeek-R1:1.5B | 15亿 | 10-14字/秒 | 1.2秒 | 约15秒 |
| Qwen3:4B | 40亿 | 6-10字/秒 | 2.1秒 | 约25秒 |
| Qwen2.5:7B | 70亿 | 2-3字/秒 | 5.8秒 | 约80秒 |
| DeepSeek-R1:7B | 70亿 | 1.5-2.5字/秒 | 6.5秒 | 约95秒 |
| bge-m3（向量化） | 5.68亿 | — | 0.15秒/段 | — |
从结果可以看出：1.5B模型速度最快，每秒生成约10-14个汉字，用户等待感较轻，适合日常高频问答；4B模型速度约为1.5B的60%-70%，仍在可接受范围，适合对质量要求较高的文书撰写；7B模型速度骤降至每秒2-3字，生成一段200字的回答需要等待超过1分钟，交互体验较差，不建议作为日常主力使用。
（二）内存占用分析
| 加载方案 | 运行时内存占用 | 系统剩余可用 | 评估 |
|---|---|---|---|
| 1.5B + bge-m3 | 约3.6GB | 约10GB | 充裕，推荐日常使用 |
| 4B + bge-m3 | 约5.3GB | 约8GB | 充裕，推荐文书撰写 |
| 7B + bge-m3 | 约8.0GB | 约5GB | 紧张，仅限单人使用 |
| 4B + bge-m3 + MaxKB容器 | 约7.5GB | 约6GB | 可用，为推荐配置 |
16GB内存在加载4B对话模型加bge-m3向量模型及MaxKB容器后仍有约6GB余量，系统运行稳定。若加载7B模型则余量紧张，不建议同时运行MaxKB服务。
（三）知识库问答质量评估
为评估知识库问答的实际效果，选取了20个装备维修领域的典型问题进行测试。测试文档包括：某型装备维修手册（PDF，86页）、修理操作规程（Word，32页）、历年故障案例汇编（PDF，154页），合计约272页、15万字。
评估由两名具有维修专业背景的人员独立进行，按四个维度打分：
| 评估维度 | 优秀 | 良好 | 一般 | 较差 | 说明 |
|---|---|---|---|---|---|
| 事实准确性 | 12 | 5 | 2 | 1 | 回答内容与文档原文一致 |
| 完整性 | 9 | 7 | 3 | 1 | 覆盖问题的所有要点 |
| 相关性 | 14 | 4 | 1 | 1 | 回答切题，无无关信息 |
| 格式规范性 | 11 | 6 | 2 | 1 | 输出结构清晰，用语规范 |
使用4B模型时的整体表现：85%的问题能够给出准确且有参考价值的回答，10%的回答需要人工补充或修正，5%的问题因文档中未涉及相关内容而无法有效回答。使用1.5B模型时，事实准确性下降约15个百分点，在涉及多步骤推理的问题上表现明显弱于4B模型。
（四）文书辅助效率对比
选取"撰写一篇800字修理日志"作为典型任务，对比AI辅助与纯手工方式的耗时。测试由3名维修技师分别完成，取平均值：
| 环节 | 纯手工 | AI辅助（4B） | AI辅助（1.5B） |
|---|---|---|---|
| 构思框架 | 10-15分钟 | 0（AI自动生成） | 0（AI自动生成） |
| 撰写初稿 | 30-45分钟 | 1-2分钟（等待生成） | 40-60秒 |
| 审核修改 | — | 5-10分钟 | 8-15分钟 |
| 格式调整 | 5-10分钟 | 1-2分钟 | 2-3分钟 |
| 合计 | 45-70分钟 | 8-14分钟 | 11-19分钟 |
效率提升：使用4B模型时，总耗时压缩至纯手工的约五分之一至四分之一；使用1.5B模型时约为三分之一至四分之一。主要节省来自"撰写初稿"环节——AI可在1-2分钟内生成结构完整的初稿，人工只需审核修改。
（五）系统稳定性测试
系统在测试期间连续运行72小时，期间执行了约200次问答交互、上传了12份文档（总计约350页）、进行了3次模型切换。未出现服务崩溃、内存泄漏或响应异常等情况。Ollama服务的systemd自动重启机制在测试中未被触发（即未发生异常退出）。CPU温度在持续推理时稳定在65-72摄氏度，未触发过热降频。
七、应用场景与效果分析
（一）修理日志智能撰写
修理日志是装备维修中最基础、最高频的文书材料。其格式固定（包含装备信息、故障现象、修理过程、更换器材、试车结果等字段），但每次填写仍需回忆和整理大量细节。使用本系统后，操作人员可用自然语言描述修理过程的要点（如"今天修了3号车的液压泵，换了密封圈，试车正常"），系统即可自动生成符合格式规范的修理日志初稿，包含完整的字段结构和规范用语。人工只需核对事实准确性和补充具体数据（如器材编号、工时等）。
（二）故障知识检索与辅助诊断
将历年故障案例汇编导入知识库后，维修人员遇到疑难故障时可用自然语言描述现象（如"发动机冷启动后怠速不稳，热车后恢复正常"），系统从历史案例中检索相似故障，给出可能的原因分析和处置建议。这相当于将老技师的经验"数字化"，使年轻同志也能快速获得参考，有效缓解了"人走经验断"的问题。
（三）技术档案电子化与智能检索
历年纸质技术档案（装备履历卡、大修记录、器材消耗台账等）可通过扫描OCR后导入知识库。导入后支持自然语言检索（如"去年所有更换过活塞的发动机记录"），秒级定位，替代逐本翻阅纸质台账的低效方式。我单位现存200余册纸质档案，电子化后检索效率提升百倍以上。
（四）方案计划辅助生成
对于格式固定的维修方案、保障计划等文书，可预先将模板和历史范例导入知识库。撰写新方案时，只需输入关键参数（装备型号、维修等级、时间安排等），系统即可参照模板生成方案初稿，大幅减少"对着空白模板发呆"的时间。实测中，一份维修方案初稿的生成时间约3-5分钟，而纯手工撰写通常需要2-3小时。
（五）多用户协同使用
MaxKB专业版支持多用户账号管理。可将系统访问地址分发给多个岗位人员，各人独立登录、独立对话，互不干扰。适合班排级单位共享一台设备、多人轮流使用的场景。管理员可查看各用户的对话记录和使用统计，便于掌握系统使用情况和优化知识库内容。
（六）典型工作日使用流程
以一名维修技师的典型工作日为例：上午8时，技师接到保养任务，在系统中查询保养记录表模板和填写要求（替代翻阅纸质规程，耗时从15分钟缩短至10秒）；保养中发现液压转向器渗油，提问获取历史案例参考和排查步骤（替代请教老技师或翻阅案例汇编）；下午撰写修理日志时，输入关键信息要点，系统在1分钟内生成规范初稿，审核修改后提交（总耗时10分钟，以往需40分钟以上）。全天累计节省文书工作时间约1-1.5小时。
八、现有局限与不足
（一）推理速度受限
飞腾D2000属于桌面级处理器，没有专用AI加速芯片（显卡），AI"思考"完全靠CPU逐字计算。实测中，轻量模型每秒生成约10-14个汉字，标准模型约6-10个汉字。问一个简单问题等回答约需10-20秒，写一篇800字材料需等待1-2分钟。这与手机上用在线AI"秒回"的体验有明显差距，使用者需要有一定耐心。作为对比，商用在线AI服务的响应速度通常为每秒50-100字，本方案速度约为其五分之一至十分之一。
（二）模型能力上限
受硬件算力制约，目前只能运行小型模型（相当于"初级参谋"水平）。它能完成格式化的文书生成、资料检索、信息整理等规范性工作，但在需要深度推理、复杂分析、创造性思考的场景下，回答质量与商用在线AI存在明显差距。通俗地说：写个修理日志、查个数据没问题，但做复杂的故障原因分析或写高质量研究论文，还力不从心。
（三）并发能力有限
CPU推理是串行计算过程，一台电脑同时只能"想一件事"。多人同时提问需要排队等待。日常3-5人低频使用（每人每10分钟提问1-2次）体验流畅，但不适合十几人同时密集交互的场景。
（四）模型不会自动进步
离线部署的模型是"固定版本"，不会像在线服务那样持续升级变强。如需更强的能力，需要等待新版本模型发布后通过U盘手动更新。更新过程约需30分钟，不复杂但需有人主动关注和执行。
（五）首次部署有技术门槛
虽然安装过程已封装为一键脚本，但初始环境准备（拷贝文件、校验完整性、排查问题）仍需具备基本计算机操作能力的人员完成。后续日常使用则无门槛，打开浏览器即可。
（六）客观看待局限
上述局限的本质原因是：我们在用一台普通办公电脑，做原本需要大型服务器集群才能做好的事。这是在"保密约束"和"硬件条件"双重限制下的务实选择——不追求最强效果，而是在合规前提下解决"有没有"的问题。随着国产AI芯片（如华为昇腾310/910系列、寒武纪MLU系列）逐步成熟，未来若配备专用加速卡，推理速度预计可提升10-50倍，届时7B乃至14B规模的模型均可达到实用速度。
九、结论与建议
（一）主要结论
本次实测证明：在完全断网的部队内网环境下，使用国产硬件（飞腾D2000+麒麟V10）本地部署AI大模型和知识库系统，技术上完全可行，保密上完全合规，操作上简便易行。具体结论如下：
1.技术可行性得到验证。成功部署了Ollama推理引擎和MaxKB知识库平台，实现了从模型推理到知识库问答的完整功能链路，全程不依赖互联网，连续72小时运行稳定。
2.保密合规性满足要求。系统全链路无外发网络流量，数据本地存储，组件开源可审计，硬件自主可控，符合涉密信息系统安全管理要求。
3.实用效果显著。在修理日志撰写、故障知识检索、技术档案整理等典型场景中，AI辅助可将文书工作耗时压缩至纯手工方式的三分之一至五分之一，有效减轻基层负担。
4.部署门槛可控。通过自动化脚本封装，整个安装过程可在半天内由一名技术人员完成，后续使用无技术门槛。
5.局限性客观存在。受桌面级CPU算力制约，推理速度和模型规模与商用在线服务存在明显差距，适用于非实时、规范化的文书辅助场景。
（二）推广建议
1.优先在文书工作量大的基层维修单位试点，积累使用经验后再逐步推广。
2.建立"AI辅助+人工审核"的工作流程规范，明确AI生成内容必须经责任人审核确认后方可使用，AI是"辅助工具"而非"替代者"。
3.指定专人负责知识库内容的维护和更新，新下发的条令条例、新列装装备的技术资料应及时录入，确保参考资料的时效性。
4.建立模型文件和知识库数据的定期备份机制（建议每周一次），防止硬件故障导致数据丢失。
5.关注国产AI芯片发展动态，条件成熟时升级硬件以获得更好的使用体验。
（三）未来展望
1.模型能力升级。随着开源社区持续发布更高效的小型模型（如MoE混合专家架构），通过U盘更新即可获得能力提升，无需改动系统架构。
2.硬件加速。待国产AI加速芯片与飞腾平台适配成熟后，可加装加速卡实现推理速度的数量级提升，使更大规模模型达到实用水平。
3.多模态扩展。未来可引入图像理解能力，支持上传装备照片进行故障识别辅助，或支持手写体档案的自动识别和录入。
4.领域微调。在本单位积累的高质量维修语料上对模型进行专项优化（LoRA等参数高效方法），进一步提升专业术语使用和领域知识的准确性。
5.联邦知识共享。在保密框架允许范围内，探索多单位之间的知识库安全共享机制，使各单位的维修经验能够互相借鉴。
参考文献
[1] Vaswani A, Shazeer N, Parmar N, et al. Attention is all you need[C]. NeurIPS, 2017: 5998-6008.
[2] Brown T B, Mann B, Ryder N, et al. Language models are few-shot learners[C]. NeurIPS, 2020: 1877-1901.
[3] Touvron H, Lavril T, Izacard G, et al. LLaMA: Open foundation language models[J]. arXiv:2302.13971, 2023.
[4] Yang A, Yang B, Hui B, et al. Qwen2 technical report[J]. arXiv:2407.10671, 2024.
[5] DeepSeek-AI. DeepSeek-R1: Incentivizing reasoning capability in LLMs via RL[J]. arXiv:2501.12948, 2025.
[6] Lewis P, Perez E, Piktus A, et al. Retrieval-augmented generation for knowledge-intensive NLP tasks[C]. NeurIPS, 2020: 9459-9474.
[7] Xiao S, Liu Z, Zhang P, et al. C-Pack: Packaged resources to advance general Chinese embedding[J]. arXiv:2309.07597, 2023.
[8] Gerganov G. llama.cpp: LLM inference in C/C++[EB/OL]. https://github.com/ggerganov/llama.cpp, 2023.
[9] Ollama. Get up and running with LLMs locally[EB/OL]. https://github.com/ollama/ollama, 2023.
[10] 飞致云. MaxKB: 基于LLM的开源知识库问答系统[EB/OL]. https://github.com/1Panel-dev/MaxKB, 2023.
[11] 飞腾信息技术有限公司. 飞腾D2000处理器数据手册[Z]. 2021.
[12] 麒麟软件有限公司. 银河麒麟高级服务器操作系统V10技术白皮书[Z]. 2022.
[13] Dettmers T, Pagnoni A, et al. QLoRA: Efficient finetuning of quantized LLMs[C]. NeurIPS, 2023.
[14] 国家保密局. 涉密信息系统安全保密管理规定[Z]. 2020.
[15] 张平, 李明. 军事装备维修保障信息化建设研究[J]. 装备学院学报, 2022, 33(4): 45-52.
[16] 王强, 刘洋. 基于知识图谱的装备故障诊断方法研究[J]. 兵工学报, 2023, 44(2): 178-186.
[17] Frantar E, et al. GPTQ: Accurate post-training quantization for generative pre-trained transformers[J]. arXiv:2210.17323, 2022.
[18] 陈华, 赵军. 国产化替代背景下军事信息系统建设路径探析[J]. 国防科技, 2023, 44(3): 89-95.
[19] 李伟, 张强. 人工智能技术在军事领域的应用与展望[J]. 军事运筹与系统工程, 2024, 38(1): 1-9.
[20] Hoffman M D, et al. Measuring the algorithmic efficiency of neural networks[J]. arXiv:2305.05176, 2023.
发表评论