质序：完全离线的 GJB 质量体系助手技术方案

质序：完全离线的 GJB 质量体系助手技术方案

前言

军工质量体系工作经常被三个约束包围：标准条款多、材料链条长、运行环境经常断网或隔离。云端大模型在这种场景里并不总是可用，也不一定适合直接处理专业判断。

质序是我们围绕这些约束做的本地知识助手。它不调用外部模型 API，标准问答、文件检查、过程评审、答辩模拟和资格审查都运行在本机。这篇文章不展开产品推广，只记录它的技术架构、检索方案、规则边界和双端交付设计。

技术栈：Tauri 2、Rust、React 18、TypeScript、SQLite、sqlite-vec、FTS5、llama.cpp dual-sidecar、Qwen3.5-4B Q4_K_M、bge-m3。

一、总体架构

1.1 四层结构

UI 层 React 18 + TypeScript，Tauri 2 WebView macOS 使用 WKWebView，Windows 使用 WebView2 编排层 Rust 核心负责路由、检索编排、证据门禁、规则计算和 IPC 存储层 SQLite 管理条款块、元数据、关键词索引和向量索引 推理层 llama.cpp 双 sidecar：生成模型与嵌入模型独立进程

业务规则集中在 Rust 层，前端只负责交互和展示。这样做的目的很直接：关键判断不能散落在 WebView 里，也不能交给模型自由发挥。

1.2 生成与检索为什么分成两个进程

生成模型和嵌入模型分别运行在两个 llama.cpp sidecar 中，本机通信使用受限端口和 Token。

这样设计有三个原因：

1. 故障隔离：生成模型异常或卸载时，检索和规则能力仍可工作。
2. 资源控制：生成模型体量大、加载慢；嵌入模型小、响应快，生命周期可以分开管理。
3. 状态透明：生成未就绪时可以明确展示检索摘录，而不是让用户面对一个假加载状态。

macOS 通过 Metal 加速，Windows 通过 Vulkan 或 CUDA 探测加载。模型权重使用跨平台 GGUF，平台差异集中在 sidecar 二进制、打包配置和进程管理适配层。

1.3 为什么选择 4B 模型

封闭知识域里，模型首先要受控，其次才是更“聪明”。GJB 质量管理知识的范围相对有限，真正困难的是证据定位、边界判断和结果可核对。

质序的取舍是：

• 用本地知识库承担领域知识；
• 用混合检索承担条款定位；
• 用规则引擎承担计算和判定；
• 用 4B 模型承担语言组织。

因此模型参数不是唯一可靠性来源。架构把“不能出错”的部分尽量从生成模型手里拿走。

二、核心设计原则

2.1 判定归规则，语言归模型

LLM 不算分数、不判合规、不直接决定通过或不通过。需要精确结果的模块都由 Rust 规则层完成：

这个原则不是为了限制模型能力，而是为了让专业场景里的关键结论可复现、可解释。

2.2 无检索不回答

标准问答没有采用“模型先自由回答，再做一次事实校验”的路径，而是先做证据门禁：

1. 识别用户意图和知识域；
2. 在允许的 scope 内执行检索；
3. 判断证据是否充分；
4. 充分才允许模型生成；
5. 不充分则拒答、澄清，或提示用户补充标准号。

提示词约束是软约束。对质量体系问题来说，更重要的是让没有依据的回答在架构层就无法生成。

2.3 检索 Scope 隔离

知识库不是把所有文档放进同一个向量池后全库搜索，而是按知识域划分 scope：

• 主标准域；
• 支撑标准与术语域；
• 文件检查规则域；
• 资格审查知识域。

每个路由在配置中声明可用 scope。路由没有命中、scope 不存在或索引异常时，系统按失败关闭处理，不悄悄回退到全库模糊搜索。

三、知识检索方案

3.1 条款切块与元数据

标准文档解析后不会按固定长度粗暴切块，而是尽量保留条款语义边界。每个 chunk 携带标准号、条款号、章节路径、来源文件和页码信息。

历史解析结果中存在两类问题：

• 超短块，缺少上下文；
• PDF 锚点错位，导致引用无法准确定位。

这些问题已经通过块治理脚本合并或修复。否则混合检索会把坏块放大到前排，直接影响回答质量。

3.2 混合检索与 RRF 融合

单个语义向量检索对标准号、缩略语和精确条款名并不稳定，因此质序使用双路混合检索：

用户问题 → 标准号与术语归一化 → FTS5 / BM25 关键词检索 → sqlite-vec 语义向量检索 → RRF 排名融合 → scope 过滤 → 充分性判定 → 证据组装

BM25 分数和余弦相似度量纲不同，直接加权会引入很多调参成本。RRF 使用排名融合，可以避免把两类分数粗暴折算成一个假分数。

更重要的是，充分性判定不能只看稠密检索 top1。当前判据会同时考虑融合排序结果和某一路强命中。也就是说，精确标准号、关键词强命中或语义强命中，只要能通过证据充分性规则，都可以进入后续回答流程。

3.3 精确素材化，而不是“直答”

早期方案里存在一个“直取通道”：短标准号精确命中后直接返回结果。这个设计看起来快，但会带来两个问题：

1. 为了绕过阈值给精确命中人为抬分，形成“分数伪造”；
2. 用户想问解释、适用条件或操作方法时，直答只能返回原文片段，体验反而不完整。

现在这条通道被改造成高质量素材通道。精确命中的证据会被标记为material类型，单独参与充分性判定，不抬分，也不绕过模型回答。最终回答仍然基于证据组织，并在证据面板中说明哪些素材来自精确定位。

3.4 标准号泛化

用户经常不会输入完整标准号。系统在进入语义检索前先做编号归一化：

GJB438 → GJB 438B-2009 9001 → GJB 9001C-2017 150.1A → GJB/Z 150.1A 150 → 给出系列候选，提示用户确认

唯一命中可以提升为高质量素材；多个命中进入澄清流程；无法确认时不猜标准。这类匹配由规则完成，不消耗 LLM 推理，也避免模型自行补全标准号。

3.5 资产分层与完整性

遵循“代码入仓、模型留本地”的原则：

• 仓库保存源码、契约、提示词、配置和资产清单；
• 模型权重、sidecar 二进制、索引产物、安装包不进 Git；
• 每个资产登记文件名、大小、sha256 和获取方式；
• 构建或启动前校验资产，不匹配则拒绝运行。

仓库同时设置单文件体积门禁，避免模型、索引或二进制被误提交。

四、功能域与工作流

质序包含五个主要能力域。它们不是五个孤立入口，而是围绕“查依据、查材料、备评审、练答辩、预审查”的工作流组织。

4.1 标准问答

标准问答负责解释条款、术语、阶段要求和常见质量体系问题。

一次典型请求会经过意图识别、标准号归一化、混合检索、证据充分性判断、回答生成和后置校验。回答中保留标准号与条款号，右栏展示证据摘录。

如果证据不足，系统不会编造标准条款，而是返回明确的未命中或澄清提示。

4.2 文件检查

文件检查面向方案设计报告等材料。系统解析 Word 或 PDF 的章节结构、标题层级、表格和文字内容，再按规则包检查必选项、常见缺口和结构性问题。

结果分为三类：

1. 硬伤：缺少必选章节或关键记录；
2. 建议：内容存在但表达或完整性可加强；
3. 通过：满足当前规则包要求。

每个发现都带依据，便于作者在提交前逐条确认。检查结果是辅助意见，不替代人工签批。

4.3 研制过程评审

过程评审模块按研制阶段整理评审关注点、材料准备项和容易遗漏的问题。阶段与评审项的映射由配置和规则维护，模型负责解释这些要点。

它的价值不在于替项目组决定能否转阶段，而在于转阶段前减少漏项。

4.4 评审模拟与答辩准备

答辩准备模块围绕标准条款和评审要点生成练习问题，帮助用户检查自己的表达是否覆盖关键条件、证据和边界。

关键结论仍由规则或库内知识比对，不依赖模型临时“感觉”回答是否正确。

4.5 资格审查

资格审查使用证据状态模型和打分表进行预演。用户录入满足、部分满足、缺失或未验证等状态后，规则层计算预估分数、扣分项和风险清单。

模型只负责把这些结果组织成可读说明。这样同一种证据状态反复计算时，不会出现多个不同总分。

五、双平台交付

5.1 macOS

macOS 使用 Tauri 2 打包为.app，再生成.dmg。模型和 sidecar 依赖放入应用资源目录，运行时从 bundle 内解析路径，GPU 加速使用 Metal。

5.2 Windows

Windows 使用 Tauri 2 打包为 NSIS 安装器。受安装器单文件限制，大体量模型通过离线压缩包分发，安装或首次构建时解压到规范数据目录。GPU 后端按 Vulkan、CUDA 和 CPU 可用性探测。

Windows 侧还处理了几个细节：

• sidecar 子进程避免弹出控制台窗口；
• 中文路径和 UTF-8 输出统一处理；
• PowerShell 脚本使用带 BOM 的 UTF-8；
• .gitattributes固定换行策略，防止 CRLF 破坏哈希校验。

5.3 平台差异边界

双端共用同一套核心契约和资产清单。平台差异集中在适配层：

业务代码不根据平台散写分支，路径也不硬编码用户目录或盘符。

六、踩坑与修正

6.1 模型编造标准号

早期只靠提示词要求“不知道就说不知道”，模型仍可能生成看似合理的标准号。后来改为检索门禁优先：没有充分证据，就不进入生成阶段。

6.2 模型判分不稳定

让模型直接理解打分表并给分，会出现同一次输入多次结果不一致的问题。现在打分表计算完全放在规则层，模型只做语言组织。

6.3 精确直答损失上下文

精确命中标准号后直接返回原文，看起来最快，但用户追问含义、适用范围和做法时没有形成完整回答。改为素材化后，精确命中仍然享受检索优先级，但不会绕过回答组织流程。

6.4 Windows 哈希校验失败

Git 在 Windows 上检出时可能把文本换成 CRLF，导致按内容计算的 sha256 全部变化。项目通过固定换行策略和资产校验规则解决。

6.5 PowerShell 中文脚本异常

没有 BOM 的 UTF-8 中文脚本在 Windows PowerShell 5.1 中可能被按 ANSI 解析。统一改成 UTF-8 with BOM 后，避免中文注释和字符串引发解析错误。

七、后续优化方向

1. 检索证据质量：继续治理低相关引用、超短块和锚点异常。
2. 对象卡素材化：围绕高频对象和岗位场景补齐解释型素材，但不做固定标准答案。
3. 性能指标：持续跟踪意图识别、检索、首 token、生成和后置检查耗时。
4. 资源调度：继续完善模型空闲卸载和按需加载，平衡冷启动与内存占用。
5. 发布工程：macOS 公证、Windows 代码签名和真机回归仍按双端发布门禁推进。

结语

质序的设计核心不是“用一个更大的模型解决所有问题”，而是在封闭知识、断网环境和准确性优先的约束下重新划分职责：

• 知识放本地库；
• 定位放混合检索；
• 判定放规则层；
• 表达放小模型；
• 证据交给用户核对。

对类似的专业场景 AI 应用来说，这个思路可能比单纯追求模型参数更有参考价值。

通过网盘分享的文件：质序安装包
链接: https://pan.baidu.com/s/1AEaYHEL-LmjmNYc70ZZP7A?pwd=udiq 提取码: udiq
–来自百度网盘超级会员v8的分享

如果有想要下载使用，或者想要获取源码自己再开发的同学，可以直接私信我。

文中截图均来自通用演示界面和公开标准示例，不包含具体单位、项目或人员信息。