政务领域的咨询场景有个显著特点：问题看似简单，答案却必须严谨。一句“我这种情况能不能申请补贴”，背后涉及政策依据、申请条件、所需材料、办理渠道等多个维度，答错一个细节就可能让群众白跑一趟。传统的政务问答系统依赖关键词匹配和预设话术，命中率低且维护成本高，而大模型的出现让语义理解真正达到了可用水平。不过政务场景又对准确性有着近乎苛刻的要求，直接调用通用大模型往往会产生看似流畅实则错误的回答，因此需要一套针对性的技术方案。
一、为什么政务问答必须用RAG而不是微调
很多团队拿到政务需求后的第一反应是拿政策文件去微调模型，这个思路在多数情况下并不合适。政策文件更新频繁，一个地市的政策每年可能调整几十次，每次微调都需要重新准备数据、训练、评估，周期长、成本高，而且微调后的模型对知识边界的控制很弱，容易出现把过期政策当作现行政策输出的情况。
RAG（检索增强生成）的核心思路是把知识从模型参数中剥离出来，放到外部知识库里。用户提问时，系统先从政策库中检索出最相关的几段原文，再把原文连同问题一起交给大模型组织回答。这样做的好处很直接：回答有据可依，可以在答案中附上政策出处；政策更新只需要替换知识库文档，几分钟就能生效；模型只负责语言组织，不承担记忆知识的责任，幻觉问题大幅减少。
一个典型的政务RAG链路包括文档解析、切片、向量化、检索、重排和生成几个环节。其中文档解析是最容易被低估的一环，政策文件多为PDF格式，常常包含表格、盖章页、红头文件排版，解析质量直接决定后续效果。
from langchain.text_splitter import RecursiveCharacterTextSplitter
# 政策文档切片：保留条款完整性比追求统一长度更重要
splitter = RecursiveCharacterTextSplitter(
chunk_size=500,
chunk_overlap=80,
separators=["\n第", "\n一、", "\n二、", "。", "\n"]
)
docs = splitter.split_documents(policy_documents)
# 每个切片附加元数据，便于后续按地区、时效过滤
for doc in docs:
doc.metadata.update({
"region": "杭州市",
"publish_date": "2024-03-01",
"policy_type": "人才补贴",
"is_valid": True
})
元数据的设计在政务场景里非常关键。政策有明显的地域性和时效性，杭州市的补贴标准和宁波市不同，2023年的标准和2024年也可能不同。检索时把用户所属地区、当前日期作为过滤条件，可以有效避免检索到过期或外地的政策内容，这比单纯靠向量相似度可靠得多。
二、办事指南场景的结构化处理方案
办事指南和政策问答是两类不同性质的任务。政策问答对应的是非结构化文本，而办事指南本质上是结构化流程：事项名称、受理条件、申请材料、办理地点、法定时限、收费标准，这些字段在政务数据中都有明确规范。如果仍然把办事指南当普通文本切片检索，模型在回答“需要带什么材料”这类问题时容易遗漏条目或张冠李戴。
更稳妥的做法是为事项库单独建立结构化检索通道。全国一体化政务服务平台对事项信息有标准化的数据规范，每个事项都可以抽取成包含固定字段的对象，用户提问时先用大模型做意图识别和槽位抽取，确定用户问的是哪个事项、哪个字段，再直接查结构化数据返回，最后由模型把结果组织成自然语言。
import json
# 事项库中的单条记录示例
item = {
"item_name": "灵活就业人员社会保险参保登记",
"conditions": ["年满16周岁", "未达到法定退休年龄", "灵活就业状态"],
"materials": ["身份证原件", "居住证（非本地户籍提供）"],
"channels": ["浙里办APP", "参保地社保经办机构窗口"],
"time_limit": "即时办结",
"fee": "不收费"
}
def answer_guide_question(question, items, llm):
# 先抽取用户意图中的事项名称，再匹配结构化数据
intent = llm.extract(question, fields=["item_name", "slot"])
matched = match_item(intent["item_name"], items)
if matched:
return llm.generate(question, context=json.dumps(matched, ensure_ascii=False))
return None
这种“结构化数据加自然语言生成”的混合架构还有一个好处：同一个事项库既能服务问答机器人，也能直接驱动办事页面展示，数据只需要维护一份，避免了机器人口径和页面展示不一致的老问题。实践中建议把高频事项的指南数据做成缓存，比如社保、公积金、居住证这几十个高频事项，能覆盖绝大多数咨询流量。
三、内容安全与幻觉抑制的工程细节
政务场景对内容安全的重视程度远超一般行业，回答中不能出现敏感表述，不能给出没有依据的承诺，涉及具体金额、时限、条件的表述必须与政策原文一致。工程上需要在生成之后增加校验环节，对答案中涉及的关键数值做来源核对，如果某个数字在检索到的政策原文中找不到，就应该拦截或降级为转人工。
幻觉抑制方面，除了RAG本身的 grounding 作用，提示词层面的约束也很有效。明确要求模型只根据提供的政策原文回答，原文中没有的信息要如实告知无法回答并建议咨询窗口，禁止模型发挥常识去推测政策内容。政务场景宁可回答“该问题需向属地部门核实”，也不能编造一个看似合理的答案。
SYSTEM_PROMPT = """你是政务服务助手，回答时严格遵守以下规则： 1. 仅依据提供的政策原文回答，不得使用自身知识补充政策内容 2. 涉及金额、期限、条件、材料清单时，必须与原文完全一致 3. 原文无法回答时，明确告知并建议拨打12345热线或前往窗口咨询 4. 不对政策做任何解读、评价或预测 5. 涉及多地区政策时，仅回答用户指定地区的内容 """
兜底机制同样不可或缺。可以设置置信度阈值，当检索得分偏低、或者用户连续追问同一问题表达不满时，自动转接人工坐席。政务服务的考核指标不是回答了多少问题，而是群众的事有没有办成，转人工不应该被视为系统失败，而是服务闭环的一部分。
四、落地实施的关键步骤与常见坑
实施路径上建议分三步走。第一步做知识治理，把分散在各委办局的政策文件、办事指南集中收集，统一格式、标注时效、明确责任部门，这一步工作量通常占总项目的一半以上，但决定了后续所有环节的上限。第二步搭建问答能力，先覆盖高频的几十个事项和政策，小范围试运行收集badcase持续优化。第三步再扩展渠道，接入政务大厅的自助终端、小程序、热线系统等。
部署方式上，政务系统普遍要求数据不出域，基本只能选择私有化部署或政务云上的专属实例。模型选型不必一味追求最大参数量，在政策问答这种检索驱动的场景里，一个经过指令微调的中等规模模型配合高质量检索，效果往往好于裸用超大模型，推理成本还低一个数量级。
常见误区有几个值得提醒：一是知识库只收正式文件不收实施细则和问答口径，导致回答过于原则化，群众听了还是不知道怎么办；二是忽略多轮对话的上下文管理，用户说“那材料呢”时系统不知道指的是哪个事项；三是评估环节缺失，上线前应该准备一批标准问答对做自动化评测，用检索命中率和答案准确率两个指标量化效果，而不是靠几个人主观试用就拍板。
政务大模型的价值不在于替代人工，而在于把重复性的标准咨询消化掉，让窗口人员把精力留给真正需要人工判断的复杂事项。把RAG做扎实、把知识库运营机制建起来、把安全校验做严格，这套体系才能长期稳定地提供服务。