企业官网建设流程全解析

简介：一份面向政务平台管理人员、IT技术人员及政策制定者的AI+政务落地方案文档，系统梳理全省一体化政务平台接入AI大模型的全流程。内容覆盖项目背景与目标、需求分析、技术架构、数据治理、安全方案、性能优化及部署运维等模块，重点解决智能问答、智能审批、智能推荐、智能分析等场景落地，并兼顾数据安全与隐私合规。文档目录从AI大模型选型、平台架构与数据接口设计，到用户界面与交互体验，再到安全审计、应急恢复、负载测试等均有详细展开，适合作为政务智能化升级的工程参考蓝本。资源为单个docx文件，约415KB，共1个文件，章节完整、结构清晰。已有78人学习下载，可用性得到一定验证。

1. 全省政务平台接大模型：第一步不是选模型，而是给AI画“业务围栏”

窗口工作人员遇到群众追问“材料不全能不能先办”，传统搜索只能弹出一堆政策原文，而大模型能把几个文件拼成一段完整答复。可一旦让模型直接给出“可以办”的结论，问题就完全变了——模型没有确定性，也没有责任主体。全省一体化政务平台接入AI大模型应用方案，真正难的不是把API挂上去，而是在大模型开口之前，先把“能答什么、不能答什么、答错了怎么办”用工程手段焊死在系统里。这套方案的读者是政务信息化厂商、平台架构师和数据资源管理人员；你要解决的不仅是模型跑通，是让业务处室愿意用、敢用。

2. 接入大模型前先定业务边界：哪些场景能让AI开口，哪些只能做草稿

政务一体化平台的特点是“一个入口、多个业务系统、一套权限”。大模型接入后，业务场景边界不清，比模型效果差更危险。我一般会把场景按风险分成四档，然后再谈技术选型。

2.1 把政务场景分成四个风险等级：摘要、问答、草稿、办结

不同场景的风险等级决定大模型到底以什么身份出现。如果把它当成一个普通软件模块，不做分级，上线后大概率会在“自动审批”这类环节翻车。

这个分级背后的判断标准有三个：输出可逆吗？有权威依据吗？失败代价有多大？L1和L2可逆、有依据、失败代价小；L3虽然不可逆，但有人工兜底；L4的不可逆和依据不足同时出现，模型就不应该独立开口。

2.2 优先做“政策问答”而不是“智能审批”：一个选型判断

很多项目一上来就要做“智能审批”，但审批链路涉及逐级签批、自由裁量、行政复议，责任归属远不是模型能背的。常见做法是先把政策问答和窗口材料预审做起来。

政策问答的好处是边界清晰、可评测、可回退。群众问“失业金怎么领”，模型可以答流程，但答错后不会直接造成损失；相比之下，审批一旦全自动化，出错就得有人负责。你可以在第一版砍掉所有“自动办结”的需求，把那些需求拆成“预审建议”和“材料补正提示”，这样业务处室更容易接受。

判断一个场景适不适合给大模型做时，我会问三个问题：这个动作能不能撤回？回答有没有明确的政策依据？如果错了，是否存在补救渠道？三条全是的场景可以上；有任意一条“否”，就要降级或加入工确认环节。

2.3 接入前的四个前置条件：数据目录、权限标签、审计日志、人工回退

如果业务边界是“能不能做”，下面四个条件是“做了怎么不爆雷”。这四个条件是除模型外的硬门槛。

第一，数据目录。各厅局的政策文件、办事指南、问答库格式不一，先统一成“标题+正文+来源编号+生效日期+适用地区+公开级别”的字段结构。没有这个目录，RAG召回的就是一堆同名文件。

第二，权限标签。每个知识文件都要打上可见范围，比如“公开”“部门内部”“仅特定角色”。大模型本身不懂权限，权限必须在检索阶段过滤掉，而不是等模型生成后补救。

第三，审计日志。记录谁在什么时间问了什么，检索到哪些文档，模型输出了什么，是否被人工修改。一体化平台本来就有日志能力，这里要单独增加AI调用链路，别混在普通访问日志里。

第四，人工回退。任何面向公众的模型输出，都要给“转人工”留一个入口。更重要的是，模型服务本身也要有熔断：AI网关连续超时或返回异常时，业务系统直接跳过AI，进入原有流程。这个回退开关不是给群众用的，是给运维应急用的。

这四条准备好，再谈架构和技术选型。否则先选模型再补边界，最后一定会返工。

3. 一体化平台的接入架构：模型网关、私有化部署与RAG知识库

一体化平台接入大模型，不是在一个业务系统里装一个SDK那么简单。全省的平台往往有一个统一用户中心、统一事项库和统一消息中心，AI最好作为一项公共能力接入，而不是每个局点各搞一套。

3.1 三种接入方式：旁路网关、平台内嵌SDK、统一模型服务中台

接大模型的常见做法有三种：在原有平台外面加一个AI网关、在业务代码里内嵌SDK、或者在全省建一个统一模型服务中台。它们不冲突，但选择的侧重点不同。

一体化平台通常已经有统一API网关，我一般会优先选“旁路网关+逐步沉淀为中台”的路线。第一版做独立AI网关，把模型调用、知识检索、审计日志放在同一处；等场景多了，再把网关管理面收拢成中台。这样做的好处是，业务系统不需要关心模型供应商切换，只用调一个内部API。

3.2 模型选型与算力规划：从7B到70B，量化不是免费午餐

模型选型受三个因素制约：可投入的算力、需要的并发量、以及对事实准确性的要求。政务场景不是对话聊天，不需要模型多聪明，但需要它稳定、快、可控。参数规模越大，回答质量通常越高，但推理成本和显存压力也越大。

以常见开源模型为例，粗略估算如下（具体还要看量化方式和KV Cache策略，只做规划参考）：

量化（比如INT8、AWQ）能把显存砍到三分之一甚至更低，但输出质量的损失在敏感场景会被放大。我的习惯是，面向公众的问答优先FP16或INT8，不要一上来就做4bit量化；内部辅助场景再用更高压缩比。另外，别忽略上下文长度带来的显存增长——窗口越长，KV Cache占用越高，并发能力下降得很快。

3.3 RAG知识库设计：chunk、overlap、topK与时效性

政务知识库不能只靠模型记住，原因很简单：政策更新太快，模型权重跟不上。RAG是目前最可靠的办法，把知识外置，每次回答问题前先检索，再把相关片段喂给模型生成答案。

切块是第一个坑。常见做法是按字符数切，但在政务场景，最好先按“条”“款”“附件”来切。比如一个政策文件里第3条讲对象、第4条讲材料，强行按每512字符硬切，会把两条内容混在一起，检索结果七零八落。如果原文有明确条号，优先按条切；没有条号的，再用chunk_size=512、overlap=64~128。

检索参数也需要设好。top_k建议先给5，相似度阈值设置在0.5到0.7之间。政务问答宁可少答，也不要把低相关片段当作依据；阈值太低，模型会把“近似内容”说成肯定结论。Embedding模型选中文能力强的开源模型，并在自己的语料上做小规模评测，不要只听指标。

还有一个容易被忽略的点：时效性。政策文件有生效日期、废止状态，知识库每条都要带“有效开始时间”和“有效结束时间”，检索时按当前日期过滤。否则上个月的旧政策会和新政策一起被检索到，模型只能靠Prompt排序，结果很随机。

3.4 最小可跑通接入流程：带RAG和回退的网关代码

第一版接入直接调裸模型是不行的，至少要有个网关代代码，把检索、Prompt组装、调用、审计串起来。下面是一段示意代码，生产环境建议用服务端SDK和连接池，但逻辑可以直接照搬。

# rag_gateway_demo.py from typing import List, Dict import requests, json # 1. 先走知识库检索，拿到命中文档 def retrieve(query: str, top_k: int = 5, min_score: float = 0.6) -> List[Dict]: # 这里替换成你的向量检索服务，例如Milvus、Elasticsearch resp = requests.post( "http://rag-service/search", json={"query": query, "top_k": top_k, "min_score": min_score}, timeout=3, ) resp.raise_for_status() return resp.json()["hits"] # 每项包含 doc_id, text, score # 2. 组装系统消息和用户消息，约束回答边界 def build_messages(query: str, hits: List[Dict]) -> List[Dict]: context = "\n".join( f"[{h['doc_id']}] {h['text']}" for h in hits ) system = ( "你是政务助手，只能依据给出的资料回答。" "不要编造条款，不要补充资料之外的办事承诺。" "资料不足时，回答：我查到的公开资料不足，建议您转人工坐席。" ) return [ {"role": "system", "content": system}, {"role": "user", "content": f"资料：\n{context}\n\n问题：{query}"}, ] # 3. 调用本地大模型接口，失败时返回兜底话术 def ask_llm(messages: List[Dict]) -> str: payload = { "model": "local-qwen-14b", "messages": messages, "temperature": 0.2, "max_tokens": 512, "top_p": 0.9, "stream": False, } try: resp = requests.post( "http://llm-gateway:8000/v1/chat/completions", json=payload, timeout=30, ) resp.raise_for_status() return resp.json()["choices"][0]["message"]["content"] except Exception: return "AI服务暂时不可用，您可以先通过原有渠道咨询。" # 4. 统一入口，记录审计日志 def handle(query: str, user_id: str) -> str: hits = retrieve(query) messages = build_messages(query, hits) answer = ask_llm(messages) # 生产这里写结构化日志，而不是 print print(json.dumps({ "user_id": user_id, "query": query, "retrieved_docs": [h["doc_id"] for h in hits], "answer": answer, }, ensure_ascii=False)) return answer

这段代码的逻辑是“检索先行、模型限定”。参数方面，temperature设为0.2是为了降低随机性；max_tokens设为512，避免回答过长；top_p 0.9在政务场景不算激进。timeout强制30秒，超过就返回兜底，而不是让群众一直转圈。

生产环境还要在这段代码前加一层认证鉴权：把平台登录态映射到用户在知识库的可见范围，按权限过滤检索结果。这个动作必须放在服务端，不能在浏览器里做。

4. 让大模型按政务口径说话：Prompt、微调与多Agent协作

模型接入只是第一步。很多项目回调通API后又发现，输出是“通用大模型腔调”，不像政务答复。这章说清楚三种调教手段的边界。

4.1 政务Prompt模板：系统指令、Few-shot与输出约束

政务Prompt不能一句话“你是客服”了事。系统指令里要写清楚权限范围，避免模型越权承诺。我常用的模板包含五个元素：角色、知识边界、行为许可、禁止事项、输出格式。

{ "messages": [ { "role": "system", "content": "你是XX省一体化政务平台的智能问答助手。\n" "你只能依据给定的政策资料回答群众问题。\n" "禁止编造法条、禁止承诺办理时限、禁止询问无关个人信息。\n" "回答时先给结论，再给依据，最后补充办理入口。\n" "资料不足时，回答：我查到的公开资料不足，建议您拨打12345或前往办事窗口咨询。" }, { "role": "user", "content": "资料：\n[根据《XX条例》第8条]……\n问题：办事材料不齐全怎么办？" }, { "role": "assistant", "content": "根据《XX条例》第8条，材料不齐全的，应当一次性告知需要补正的全部内容。您可以先到窗口提交现有材料，工作人员会出具补正告知单。" } ] }

这段Prompt的关键是“禁止承诺办理时限”。政务事项的时限经常有条件，模型很容易在省略条件后只输出一个数字，业务方最怕这种回答。Few-shot样本放一条或两条就够了，放多了模型会被样本语气带偏。

你也可以在输出格式里要求JSON结构，例如{"answer": "...", "sources": ["xxx"]}，方便前端展示引用来源。相比让模型用自然语言夹带来源，结构化输出更容易做校验。

4.2 什么时候才需要微调：数据标注、LoRA与评测闭环

先说结论：能靠Prompt和RAG解决的，不要微调。微调的启动成本不只是训练机器，而是需要一份高质量、可审计的领域数据。尤其在政务场景，训练数据必须经过业务处室审定，否则就是灾难。

常见做法是在三类情况下考虑微调：一是模型总是把特定专业名词理解错；二是输出格式始终无法固定；三是RAG检索到了正确内容，但模型不会按标准口径组织语言。这些都说明Prompt已经压不住问题，才轮到微调。

微调的数据集不用贪大。先整理50到100条“问题+资料+标准答复”作为评测集，再用300到1000条做LoRA训练。政务场景优先用LoRA这类参数高效微调，冻结底座，只训练适配层。每次微调完，必须在固定评测集上跑一遍，对比微调前哪些样本变好、哪些样本变差。这里有一个容易被忽略的点：微调是黑匣子，不跑回归就别上生产。

数据标注时，我一般会把样本分成三类：正常问答、拒答样本、纠偏样本。纠偏样本专门用来覆盖“群众问A，但实际需要告知B”的场景。每一条标注都要写明“为什么这么答”，标注完成后由业务处室复核，算法团队不能自己说自己标注得对。

4.3 多Agent协作拆解：意图分类、检索、审查各司其职

热词里的“多AI协作”“AI Agent”在政务场景不是让一群模型互相聊天，而是把业务流程拆成多个可编排的模型调用。一个典型的问答链路会包含以下角色：

多Agent协作的收益是职责分离：回答Agent不需要关心权限，审查Agent不需要懂业务。代价是时延变长、成本变高。所以别一上来就上Agent，先跑通单Agent，把失败日志收集起来，确认单个模型实在扛不住，再拆。

每个Agent的调用都要产生审计日志，这点在一体化平台里尤其重要。哪怕最终回答是从Agent链路拼出来的，也要能定位到是哪一步产生了有争议的句子。

5. 避坑清单：政务大模型接入最容易翻车的6个问题

没有哪个模型接入项目不踩坑，政务项目尤甚。下面这些是我在类似方案里反复看到的坑，按频率排序。

5.1 模型一本正经编造“第十条”，如何用溯源和兜底堵住

现象：群众问“落户需要哪些材料”，模型引用了根本不存在的《XX办法》第十条，群众照办后跑空窗口，投诉直接到市政府热线。

原因：大模型生成时靠概率拼装内容，没有“权威源”概念。RAG即使带回了正确片段，模型也可能自己补充一段“合理但不真实”的条款。

解决：每个回答的末端必须带上“依据来源”列表，来源为空时不允许发送。另外可以写一个小服务，把模型输出里的“第X条”抽取出来，与RAG命中文档做比对，匹配不到就丢弃该片段。对引用失败的情况，宁可回答“资料不足”，也不要强行补全。

5.2 拿历史办件数据直接微调，模型反而学会了“酌情处理”

现象：某项目用近三年的办件记录微调模型后，模型在回答“材料缺失”时总是说“可以酌情容缺受理”。业务处室看了头皮发麻。

原因：历史办件数据包含大量人工特例、自由裁量和个案协商结果，不是标准答案；而且办件数据里往往有公民姓名、证件号，直接训练有隐私合规风险。

解决：微调只使用已审定的办事指南、政策问答和公开规范性文件。如果非要学历史办件的“答法”，必须由业务处室把个案清洗成标准问答对，并隐去所有个人信息。数据质量把关人必须来自业务方，不是算法团队拍板。

5.3 上下文窗口拉满，召回率和费用同时失控

现象：有人觉得“模型上下文支持128K，干脆把政策全文都塞进去”，结果文档一长，模型答非所问，而且每次会话都消耗大量token，服务商账单翻了几倍。

原因：长上下文的注意力会集中在开头和结尾，中间关键条款容易被忽略；大模型按token计费，全文灌入的成本线性上涨，但效果没有同步上涨。

解决：把RAG当作默认方案，控制进入模型的片段总量。例如系统指令加检索片段合计不超过3000 token；对超长文档做“先粗检索，再对命中的章节做细读”，不要一次性读全文。上线后用包含长政策的评测集定期抽测，发现特定文件总答错，就单独优化它的切片。

5.4 权限没打通，AI成了越权查询入口

现象：普通来访用户问“这个事项内部审核意见是什么”，模型竟然根据内部材料生成了一段答复。幸好在测试阶段发现，否则就是重大事故。

原因：很多实施方把知识库当成一个公共向量库，没有在检索阶段根据用户身份做权限过滤。模型只能看到你给它的内容，它不会主动“不知道”，只会把检索到的东西讲出来。

解决：把平台登录用户的角色、部门编码转换成检索参数，给每个知识文档打上可见范围。例如工作流的“审核意见”仅对特定工单成员可见；检索接口必须接收user_id和dept_code，并且在向量查询时加上权限过滤条件。测试时要专门准备“低权限用户问高权限内容”的用例，输出必须是“无权访问”。

5.5 只测“答得对”，不测“拒绝得对”

现象：模型对“能不能绕过线上排队直接插队”“哪个窗口的工作人员经常迟到”这类问题，也一板一眼回答，虽然内容不违法，但明显越界。

原因：评测集里全是正常业务问题，没有设计边界问题、诱导问题和恶意问题。模型天然倾向迎合用户，缺少拒绝指令时就会“有求必应”。

解决：在测试集里加入30%以上的拒答样本，包括“诱导”“非业务”“敏感咨询”三类。同时给模型一个固定的拒绝话术模板：“这个问题超出我的公开资料范围，建议您通过XX渠道咨询。”注意“拒绝”不是不回复，而是引导到正规渠道。这样才能让业务方放心面向公众开放。

5.6 私有化部署的模型版本更新滞后，安全补丁没人管

现象：大模型一体机部署后，模型框架被扫描出高危漏洞，供应商说要升级，但业务方不敢动，因为没人知道升级后同一个Prompt的输出会不会变。

原因：部署时缺少版本管理和回归机制，模型升级被当成“换程序”，而没有当成“发版”。

解决：把模型包、Prompt配置、知识库快照、评测集结果一起纳入版本管理。每次升级先在新环境跑一遍黄金数据集，通过后再灰度10%流量，观察几天再全量。同时保留上一版权重和配置，以便出了问题随时回滚。这条会帮你在后续运维中省下大量精力。

6. 验证与进阶：从“模型能答”到“平台敢用”的最后一公里

6.1 黄金数据集回归：一段极简脚本

要让模型升级不再靠“感觉”，我一般会建一个黄金数据集。里面三类用例：标准问答、拒答问题、边界问题。每次改Prompt、换模型、调检索参数，都跑一遍这个脚本：

# golden_regression.py import json from rag_gateway_demo import handle cases = json.load(open("golden_qa.json")) # [{q, must_have: [], must_not_have: []}] passed = 0 for c in cases: ans = handle(c["q"], user_id="tester") ok = all(k in ans for k in c["must_have"]) and \ not any(k in ans for k in c["must_not_have"]) passed += ok print(f"regression pass rate: {passed / len(cases):.2%}")

这段脚本把“模型变好变坏”量化成通过率。注意不要只关注总通过率，还要对比每个用例的通过状态，原来对的不能改错。如果通过率微升，但某几个高频问题反而变差了，不能上线。

6.2 可观测性：人工复核率比单次回答更说明问题

我会在接入平台后持续跟踪几个指标：模型调用量、平均时延、检索无命中率、人工复核率。其中人工复核率最关键，它是“业务方实际不信任AI”的直接信号，超过20%就要回头查是知识库旧了，还是Prompt出了问题。

6.3 从问答到流程：把AI放进审批链

下一步可以把AI输出做成“预审意见”，接到低风险事项的审批流里，例如材料补正告知。建议试点选择“输出可修改、不直接发证”的事项，让AI先提意见、主办人确认后发送。我的教训是，不要急着把AI从“参谋”升成“决策”；只有经过一个季度的复核率验证，才敢把部分事项设为默认预审。

希望你在做类似方案时，把这些边界和验证手段前置到立项阶段。一个能拒绝、能溯源、能回滚的大模型应用，比一个只会对答如流的模型有价值得多。希望帮到你。

本文还有配套的精品资源，点击获取