政务知识库是典型的强合规导向场景，架构选型的第一原则是「合规一票否决」：安全优先级高于效果，可控性优先级高于体验，所有技术决策必须先通过等保、密评、信创、数据不出域四大硬性红线校验，再在此基础上优化检索准确率与用户体验。这是政务场景与普通企业知识库最本质的区别。
一、选型前置：政务场景的四大硬性红线
架构师启动选型前，必须先明确以下不可突破的约束，所有组件与方案都需先满足底线要求：
- 等保2.0三级强制要求
政务核心系统原则上需达到网络安全等级保护第三级，采用「一个中心、三重防护」的纵深防御架构，强制要求集中安全管理中心、双因素身份认证、全量日志留存不少于6个月、重要数据异地备份、每年一次正式等级测评。权限体系必须满足三权分立（系统管理员、安全管理员、审计管理员权限互相独立制衡）。
- 全栈信创适配要求
从算力芯片、服务器、操作系统、数据库、中间件到大模型、推理引擎，均需纳入信创体系兼容范围，优先选用国家信创目录内产品，规避境外技术供应链风险。涉密场景要求更严苛，核心软硬件必须完全国产化、自主可控。
- 数据分级与域隔离
依据政务数据分类分级标准，数据分为公开、内部、秘密、机密、绝密五级；对应部署在互联网政务服务域、政务外网办公域、涉密内网核心域，三域物理隔离，数据仅能通过审批流程单向摆渡，禁止跨网调用模型与流转数据。
- 全链路可审计可溯源
所有用户访问、文档操作、模型调用、问答内容全程留痕，日志不可篡改；模型输出必须挂载原文依据，支持精准溯源到具体文件、具体条款，无依据内容禁止输出，从机制上遏制幻觉风险。
二、整体架构设计：三域分层，安全贯穿
政务知识库采用「三域独立部署、安全能力贯穿」的分层架构，三个网络域物理隔离，各自部署完整技术栈；安全网关、权限管控、审计溯源作为公共基础能力，嵌入每一层的必经链路。
分层逻辑（从外到内）：
接入层 → 安全网关层 → 业务编排与权限层 → RAG核心处理层 → 模型服务层 → 数据存储层 → 国产化基础设施层
其中安全网关层是所有请求的唯一入口，所有访问必须先完成身份鉴权、权限校验、Prompt安全检测、频次限流，再进入业务逻辑，从边界处守住安全底线。
三、核心模块选型决策与架构思考
- 底座模型选型：国产化私有化是唯一合规解
真实困境
• 闭源大模型API上线快、通用能力强，但政务内部数据出域直接触碰合规红线，完全不可行。
• 境外开源模型（如Llama系列）存在知识产权与数据安全风险，无法通过涉密场景测评；移植到国产算力平台适配成本高、性能损耗大。
• 国产模型能力参差不齐，部分模型仅支持x86+英伟达架构，在昇腾、海光等国产算力环境下兼容性差。
架构师选型逻辑
-
合规优先，一票否决：涉密与内部政务场景，直接排除境外模型与公有云API，仅选用已完成网信部门备案、进入信创目录的国产大模型私有化版本。
-
算力原生适配优先：优先选择官方原生支持国产算力芯片（昇腾、海光DCU、寒武纪）的模型，避免后续移植踩坑；采购阶段明确要求提供目标软硬件环境下的实测性能报告。
-
分级部署，按需匹配：不盲目追求大参数，互联网服务域用7B-14B模型兼顾并发与成本，政务外网用14B-32B提升推理深度，涉密域按密级要求单独部署。
-
三类模型解耦选型：生成、Embedding、重排模型分开选型，各自匹配最优国产方案，不强求同一厂商体系。
推荐选型方案
模型类型 私有化推荐选型 适配算力 适用场景
生成模型 Qwen2.5、通义千问、文心一言 私有化版 昇腾910/310、海光DCU 通用问答、政策解读、公文辅助
Embedding模型 bge-large-zh-v1.5、m3e-large 国产推理卡、CPU 文本向量化、语义检索
重排模型 bge-reranker-large 国产推理卡、CPU 大规模知识库精排
- RAG全链路：政务公文特性的定制化改造
政务文档有极强的格式规范性与结构逻辑性，通用RAG方案直接套用会出现严重的效果折扣，必须针对公文特性做全链路定制。
（1）文档解析：结构化提取元数据，解决「垃圾进垃圾出」
真实问题：政务公文遵循GB/T 9704-2012格式标准，包含文号、密级、发文机关、生效日期、主题词等关键元数据，通用解析工具会丢失这些信息；大量红头扫描件、带公章文件、复杂表格无法精准识别，直接导致检索准确率低下。
架构思考与选型：
• 放弃通用文档加载器，基于公文格式标准开发定制化结构化解析器，自动提取文号、标题、发文机关、成文日期、生效日期、密级、主题词等元数据，与分片内容绑定入库。
• 扫描件采用版面级国产OCR引擎，支持红头、公章、表格、标题层级识别，还原文档完整结构，而非纯文本提取。
• 表格、附件单独处理：表格保留结构化格式，附件建立关联索引，避免碎片化丢失上下文。
（2）分片策略：结构优先的条款级分片
真实问题：固定长度分片极易切断政策条款、办事流程，导致回答断章取义；政务文件天然具备「章-节-条-款」层级结构，通用分片完全浪费了这一结构优势。
架构思考与选型：
• 核心采用元数据驱动的结构化分片：法律法规按条款拆分、政策文件按章节段落拆分、办事指南按事项步骤拆分，以天然语义边界为分片单位，每个分片携带完整的标题层级路径。
• 对超长段落做固定长度兜底，设置10%-15%的重叠窗口，覆盖衔接处语义。
• 所有分片强制绑定所属文件的元数据（文号、效力状态、密级、发文机关），作为后续检索过滤与排序的基础。
该方案既保留了语义完整性，又契合政务文档的查询习惯，是政务RAG的工业界标准做法。
（3）检索架构：混合召回+政务规则重排
真实问题：纯向量检索对文号、事项编码、专有名词等精准查询效果远差于关键词检索；政务查询有强时效性与效力层级要求，已废止、失效的政策若被召回并生成回答，会引发严重的办事误导与合规风险。
架构思考与选型：
-
混合召回为基础：BM25关键词检索负责文号、标题、主题词的精准匹配，向量检索负责语义模糊查询，两路召回结果做归一化融合。
-
政务专属排序因子：在融合打分中叠加规则权重：
◦ 时效性权重：现行有效 > 征求意见 > 已废止，默认过滤废止文件
◦ 效力层级权重：上位法 > 下位法，上级文件 > 下级文件
◦ 匹配度权重：文号精确匹配 > 标题匹配 > 正文匹配
- 前置过滤能力：支持按发文机关、年份、文件类型、密级做条件过滤，适配政务查文的使用习惯。
选型结论：十万至百万级文档规模，混合检索+政务规则重排即可满足要求，无需额外引入重排模型；超大规模省级知识库再引入国产重排模型做精排。
- 权限架构：分级分类+前置过滤+域隔离
这是政务知识库区别于普通企业系统的核心差异化设计，也是最容易上线后被迫重构的环节。
典型架构坑
很多方案采用「检索出结果后再做权限过滤」的后置模式，会导致严重的召回不足：比如普通工作人员仅有权查看内部公开文档，向量库召回Top10结果中可能8条为涉密文件，过滤后仅剩2条有效内容，回答质量大幅下降。
架构级解决方案
-
物理域隔离：互联网、政务外网、涉密内网三域物理断开，数据仅能通过合规摆渡工具单向流转，模型服务互不调用，从物理层面杜绝跨域泄密。
-
权限前置注入：文档分片入库时标注密级、部门可见范围、岗位权限标签；检索时将用户身份、密级、部门作为过滤条件直接传入存储层，仅在用户权限范围内执行相似度计算，从根源上解决无权限结果召回的问题。
-
三权分立设计：系统管理员、安全管理员、审计管理员三个角色权限互相独立、互相制衡，满足等保三级测评要求。
-
统一身份对接：对接政务统一身份认证平台、公务员实名制系统，不独立建设账号体系，默认遵循最小权限原则。
-
安全合规架构：全链路满足等保与密评要求
安全不是单一模块，而是贯穿全链路的体系化设计，对应等保三级的技术与管理要求：
• 输入侧安全：安全网关集成Prompt注入检测、敏感词检测、身份鉴权、频次限流，禁止恶意诱导提问与越权访问。
• 数据侧安全：存储与传输采用国密SM2/SM4算法加密；文档添加隐水印支持泄露溯源；敏感字段自动脱敏，不落盘明文。
• 输出侧安全：
-
强制溯源机制：所有回答必须标注引用文件的文号、发文机关、原文片段，无有效引用时直接告知「无法解答」，从机制上压制幻觉。
-
内容安全审核：输出内容先经过政务合规审核模型校验，过滤违规表述、错误结论，禁止生成超出知识库范围的政策解读与办事承诺。
• 审计与管理中心：搭建统一安全管理中心，汇聚全链路操作日志、访问日志、模型调用日志，日志不可篡改且留存不少于6个月，支持合规审计与故障溯源。
四、不同层级政务场景的部署方案
- 区县级/单一局办：轻量私有化方案
• 适用场景：区县政务服务、单个部门内部知识库，文档量十万级以内
• 核心配置：国产化单节点服务器（鲲鹏/飞腾+国产推理卡），7B参数生成模型，PgVector（适配国产数据库）承载向量存储，对接部门统一身份
• 部署域：政务外网部署内部办公知识库，互联网域单独部署公开办事知识库，两域隔离
- 地市级：标准生产级方案
• 适用场景：市级政务服务平台、多部门共享知识库，文档量十万至百万级
• 核心配置：三节点高可用集群，模型服务独立部署，14B参数生成模型，Milvus国产化版本+Elasticsearch国产化版本做混合检索，前置安全网关，对接市级统一身份认证
• 核心能力：多部门租户隔离，统一算力资源池，集中审计与安全管控，满足等保三级要求
- 省级/跨厅局：分布式知识中台方案
• 适用场景：省级政务知识中台，跨厅局、跨地市共享，文档量百万级以上
• 核心配置：分布式算力集群，多LoRA领域适配器共享基础模型（人社、税务、市场监管等领域分别适配），「混合检索+重排模型」三级召回架构，多租户权限体系
• 核心能力：统一知识标准、统一算力调度、统一安全管控，支持联邦检索实现各部门数据不出域、逻辑共享
五、政务场景典型工程坑与规避思路
- 信创适配坑：不同国产芯片、操作系统、数据库的组合兼容性问题多，模型移植后推理性能损耗大。
◦ 规避：选型前必须做目标环境POC验证，优先选用官方原生支持信创生态的组件；保留x86过渡方案，逐步完成全栈替换。
- 政策时效性坑：政策修订、废止后未及时更新知识库，系统仍返回旧政策，引发办事误导。
◦ 规避：建立文档全生命周期管理机制，入库强制标注生效/废止日期，检索默认过滤已废止文件；对接官方政策文件库，实现增量自动同步更新。
- 幻觉合规风险：模型生成无依据政策解读、错误办事指引，引发政务舆情与行政纠纷。
◦ 规避：严格执行强制溯源机制，无原文依据不生成回答；划定明确的回答边界，超出范围直接告知无法解答；高频问题建立人工审核闭环。
- 跨部门共享难：各部门数据格式、密级标准不统一，权限壁垒高，难以共建共享。
◦ 规避：先行制定统一的政务知识入库规范（元数据标准、分片标准、密级标注标准）；采用「物理分布、逻辑统一」的联邦检索架构，各部门数据不出域，统一检索入口。
六、架构演进路线
-
基础阶段（1-3个月）：单域部署，跑通文档入库、检索问答核心流程，完成等保与信创基础适配，验证业务价值。
-
提升阶段（3-6个月）：扩展多部门共享，完善权限、审计、安全体系，增加政策解读、办事指引、公文辅助生成能力，正式上线运行。
-
深化阶段（6个月以上）：构建政务知识中台，引入知识图谱关联政策、事项、部门，支持复杂逻辑推理；对接政务服务系统，实现「问答-办事」联动。