1. 项目最初的定位先想清楚政策支撑支撑的到底是什么1.1 需求从一次窗口接待开始大概三个月前我们单位接了一个内部项目编号就叫生成式人工智能赋能政务服务的政策支撑——系列记录的第一篇。名字听起来挺大但需求其实是从很具体的一次窗口接待来的业务科同事每天要面对几十个咨询问题翻来覆去就那几类但他们每次都得翻文件夹、找依据、核对口径再组织语言答复。一个简单问题从翻文件到确认时效性至少几分钟。赶上咨询高峰后面排队的人急窗口的人也急。我们当时调研了一圈发现所谓的政策支撑落到实际业务上其实就三个诉求第一窗口人员需要一个能在几秒钟内查到底层条款的工具而不是一检索就弹出一堆PDF让自己慢慢翻第二不同的人回答同一个问题口径要一致不能这次说需要原件下次说复印件也行第三也是最关键的答错了不行——政务咨询一旦给错信息群众多跑一趟都是事故。所以项目的本质不是做一个聪明的聊天机器人而是做一个知轻重的辅助检索与拟答复工具。这个定位上的差别直接决定了后面几乎所有技术选型。如果我们一开始就冲着AI什么都答去后面大概率会死在幻觉治理和口径审核上。如果把它当作一个带生成能力的知识检索系统每个答案都强制有依据、有出处、可回溯事情就清楚多了。我给这类项目的总结就一句话生成式AI在政务场景里价值不在于创造而在于把已有的、分散的信息用最准确的方式组织和表达出来。1.2 三条边界不做开放问答、不直接面对群众、不确定就不答需求梳理到一半业务方一度提出很多美好想象能不能让AI直接回答群众的问题能不能把几十年的文件全部学进去当百科用我们一样样往下砍最后立了三条规定写进了需求文档里。第一不做开放问答。系统的服务范围只锁定在政策文件库里已有的内容。问库外的事不问领域的事直接走拒答流程。这一点看起来浪费了生成式AI的能力但实际上保住了口碑。用户对大模型容忍胡编但对政务咨询零容忍。与其答错不如答这个问题我暂时无法确认请转人工。第二不直接面向群众。系统输出的答案是给内部业务人员看的草稿不是最终答复。任何对外发布的内容必须由人工确认以后才能出去。这条边界既是技术上的安全垫也是责任上的防火墙。AI可以帮你把草稿写到八分熟剩下两分必须人来把关。第三不确定就不答。写进验收标准的第一条要求宁可拒答不可编造。所谓不确定包括检索得分不高、依据片段存在歧义、材料里没有直接答案等情况。后续我们在工程上做了三层拦截来实现这条原则下面专门有一节讲。这三条边界定下来以后项目的MVP范围也清晰了。我们选了三个高频业务方向做试点每类几十份核心文件先把质量和流程打磨通再谈扩量。做这类项目最怕贪大求全——一上来想把全领域都覆盖结果评测集做不出、口径对不上、效果说不清楚最后只能变成演示很惊艳、上线没人用的展厅系统。2. 技术选型里的取舍为什么是私有化部署加RAG而不是直接调大模型API2.1 第一轮淘汰数据合规决定了不能走API路线方案评审第一轮大家争论最激烈的是要不要接外部大模型API。坦白说如果只看成本和效果通用大模型API是性价比最高的选择——不需要买GPU不需要管运维效果还比小模型好一个档次。但项目一过数据合规评估这个方案当场就被毙了。原因是政策文件、咨询记录这些东西属于内部敏感数据不能出内网。把用户问题和文件内容发到外部API哪怕协议里写得再好从安全角度也不能接受。这一点不仅是政务场景很多国企、金融、医疗项目都是同样的逻辑。那段时间我接触了几个同行大家遇到的情况几乎一模一样先进的技术方案统统被数据不能出域一条卡住最后老老实实走私有化部署路线。所以我建议所有做这类项目的团队第一件事不是选模型而是先和合规同事确认清楚数据边界。边界一确定选项就少一半。我们最终的环境是单位内网的一台GPU服务器操作系统和软件栈全部适配国产化要求。这基本封死了直接调云端API和用最新最大模型两条路倒逼我们在本地化方案里把效果挖到极致。2.2 底座模型为什么选了14B这一档本地部署最大的限制是显存和推理速度。当时我们比较了三档开源底座模型大概是7B、14B、30B这种量级。直接说结论最终选了14B这一档原因有三个。第一7B模型在指令跟随和长文档推理上明显偏弱。政策问答有一种典型场景用户问我这种情况能不能申请补贴答案在文件里分散在不同的条款——资格条件在第几条、例外情形在第几条、提交材料又在附件里。7B模型经常只看到资格条件就下结论忽略了例外条款这是政务场景不能接受的遗漏。第二30B模型效果确实更好但需要更大的显存和更高的算力推理速度也慢。我们的场景是窗口人员即时使用一个答案等十几秒体验就很难受了。第三14B刚好在效果和成本之间取了平衡单卡能跑推理速度在可接受范围内配合RAG做得好的话效果并不输给更大的模型。这里多说一句模型不是越大越好关键看有没有把知识放到该放的位置。我们在后面的实践里发现底座模型只负责根据材料总结答案这个推理任务而具体的政策知识全部通过检索环节喂进去。这样一来模型本身不需要记住任何文件细节14B的参数量完全够用。2.3 检索、重排与生成的流水线设计架构上我们采用了标准的RAG模式但做了很多政务场景特有的改造。先说主干流程用户输入问题后系统先做查询改写把口语化表达转成更贴近政策术语的查询语句接着做混合检索同时跑关键词检索和向量检索各取一批候选段落然后重排从候选里挑出最相关的五到八段最后把这些段落和原始问题一起交给底座模型生成带引用的答案。为什么要用混合检索而不是纯向量检索这个后面踩坑部分会细讲这里先说结论政务文件里的术语和口语之间差异很大用户说这个钱什么时候到账文件里写的是补贴发放时限纯向量检索不一定能对上。关键词检索虽然土但对这类精准词匹配很有效。两者结合召回率才稳定。重排这一步也容易被忽略。向量检索一次性召回二十个段落如果全部塞给LLM模型容易被无关内容干扰答案质量反而下降。重排模型的作用是先按相关度排出顺序只把最相关的几段送进生成阶段。这样既保证上下文精炼又能过滤掉大部分噪音。整套流水线的设计原则就一条每一个环节都为了减少模型自由发挥的空间而不是增加它的发挥空间。第3个关键取舍是向量库的选择。当时市面上可选的开源方案不少我们最后选了一个内网部署成熟、中文分词和索引效率都不错的产品。这里不推荐具体品牌因为几个月后我们可能还会换但选型标准可以分享一是必须支持纯内网离线部署二是索引更新要够快我们每周要增量导入新文件三是查询延迟要低四是社区活跃度要好——因为内网环境没法搜到太多第三方资料踩坑时主要靠社区Issue撑腰。3. 政策知识库的构建切分方式、元数据和时效性数据这一关怎么过3.1 语料清洗扫描件、表格和附件是最大的坑知识库是整个项目的真正瓶颈。说过很多次RAG的效果上限由数据质量决定模型只是把数据的价值释放出来。我们在数据准备上花的时间超过整个项目的三分之一而且这个比例我认为非常合理。政策文件语料的形态五花八门大致分四类扫描版的红头文件、Word版定稿、网站发布的通知页面、以及作为附件附在正文后面的实施细则和表格。每一类都有各自的坑。扫描件得先过OCR识别出来的文字经常带页眉页脚、水印噪声有些文件还被印章压住了关键文字Word版格式不统一有的用多级列表有的用纯文本敲空格对齐网页通知更麻烦正文旁边全是导航栏、相关链接、版权信息这些都要清掉附件则经常被漏掉——很多政策正文只有两页真正的操作细则全在附件里不处理附件就等于丢了半个知识库。清洗流程我们做了标准化先统一转成文本格式再按规则清除页眉页脚和水印特征第三步做版面分析把标题、正文、表格结构识别出来最后对OCR结果做人工抽检。抽检比例不用很高但重点文件必须逐字核对尤其涉及金额、期限、材料清单这类关键信息。OCR识别错一个字补贴金额3000元变30000元系统的所有努力都会毁在一处文字错误上。3.2 按文件逻辑结构切分而不是固定窗口早期做的原型里我们把文件按每500个字符硬切成一段结果惨不忍睹一条规定被拦腰截断上下句残缺附件标题和正文内容被切到不同的向量里检索时经常召回一些半句话。后来我们把切分策略彻底改成按政策文件的逻辑结构切分。政务文件有非常清晰的层级文件头 - 章 - 条 - 款 - 项很多还有附件。我们就按照这个结构来切每一条作为基本切片超过一定长度的条款再按款细拆但子切片必须带上父条款的上下文摘要避免模型只看到后半句却丢了前面的限定条件。每个切片保存三部分元数据来源文件唯一编号、条款路径比如某管理办法-第三章-第十条-第二款、以及文件当前的效力状态现行有效、已修订、废止。还有一个细节政务文件里经常出现附件一、附件二而且附件正文才是真正能回答问题的内容。我们最开始没有单独提取附件导致很多问题的依据缺失。后来清洗流程里加了一步附件识别与关联把附件作为独立的文档处理同时在元数据里维护与正文的父子关系。这一步很琐碎但对召回效果的提升立竿见影。3.3 元数据和时效性让系统知道哪份文件说了算政策知识库和普通技术文档库最大的区别在于同一个问题新旧文件给出的答案可能是互相矛盾的。用户问申请这个补贴需要什么材料如果系统同时召回了一份2019年的旧办法和一份今年的新细则语言模型很可能把两者混在一起生成一段四不像回答。这个问题必须靠元数据层面的时效性机制来解决。我们的做法是给每份文件标记层级和状态新文件导入时如果标题与现有文件相同或者发文内容明显覆盖旧文件就把旧文件标记为被修订状态检索排序时默认排除只有用户明确问以前的规定是什么新旧政策有什么区别时才把已失效文件拉出来作为对比参考。另外我们给每条切片都打了生效日期标签排序时按现行有效 当年修订 已废止的优先级处理。这一步是政务类RAG和普通RAG最不一样的地方也是最容易被技术团队忽略的地方。通用场景里知识过时问题不大但政策场景里拿废止文件答题后果非常严重。我们做了很多次回归测试专门构造新旧规定冲突的问题确保系统永远优先采用最新有效文件。曾经有一轮测试发现系统在回答某问题时引用了一个旧条款排查原因是检索阶段把旧文件和新文件同时召回而重排模型没法判断时效优先级。后来我们直接在检索前就做了按效力状态过滤用规则手段把这个问题彻底解决——这种问题靠模型自觉是不靠谱的要放到管线上用规则硬约束。4. 幻觉治理三板斧引用溯源、兜底拒答和模板化输出4.1 强制引用让每句话都有出处政务场景对幻觉的容忍度极低所以我们的防幻觉设计不是堆一两个技巧而是做成了一整套路管线我用三板斧来概括。第一板斧是强制引用。系统提示词里写得非常死只准基于检索提供的材料作答必须引用具体的条款编号任何材料中没有的信息一律不允许补充。但这里要说句实话——提示词约束并不是100%有效的模型偶尔还是会自由发挥或者编一个不存在的条款号。所以我们加了程序层面的校验生成结束后解析结果里每个引用的ID检查它是否真的存在于本次检索返回的片段集合里不存在就直接拦截这条答案走拒答流程。这一步等于把生成环节可能出错的风险在输出端又封了一道。实际操作中我们让输出走一个结构化格式方便程序校验。比如模型返回的是一个固定结构的JSON包含回答正文、引用清单、置信度三个字段。引用清单里的每一条都要能对应到知识库里一个真实的条款路径。这样做的额外好处是前端展示时可以直接把依据渲染成可点击的原文片段窗口人员一点就能核对原文信任感一下子就上来了。很多同行觉得引用溯源是给用户看的装饰我的体会是它同时是内部质检的抓手——没有引用结构你连AI有没有乱答都很难自动检查。4.2 兜底拒答阈值怎么设才合理第二板斧是兜底拒答。无论检索和生成做得再好总有知识库覆盖不到的问题和模型拿不准的情况。我们设计了两道阈值来触发拒绝回答。第一道是检索置信度阈值如果检索阶段所有候选片段的相似度最高分都低于0.55这个值是我们在内部小测试集上反复调出来的系统认为知识库里没有可支撑答案的内容直接返回预设的拒答话术。第二道是生成忠实度阈值生成结束后用程序计算答案和检索片段之间的语义相似度低于0.6就认为模型超纲发挥了同样拦截。两道阈值的共同效果是让系统在答不出来和答错了之间选择前者。关于阈值设置我要特别提醒别想偷懒直接套网上的参数。不同业务领域、不同底座的模型、不同的向量模型得分分布完全不一样。政务场景里我们宁可把阈值调高一些换取更低的错误率——因为一次错误答复的代价远超几十次拒答带来的不便。而且拒答话术也要有人情味我们写了三档完全无相关材料时回复根据现有材料暂无法直接回答有材料但不足以得出明确结论时回复材料不完整建议转人工核实涉及内部审批细节时回复该问题涉及内部流程请联系对应业务科室。这样用户不会一头撞在冷冰冰的无法回答上引导也更顺畅。4.3 模板化输出限制生成自由度提高可读性第三板斧是模板化输出。很多AI产品追求让模型自由发挥、写小作文政务场景恰恰相反——答案的自由度越低可用性越高。我们最后把答案强制成一个固定的四段式结构结论、依据、条件、例外。结论部分先给简明的判定结果比如符合条件可以申请依据部分列出引用的条款原文关键句条件部分把需要满足的资格条件逐条列出例外部分写明材料中提到的例外情形没有就写材料中未提到例外情形。这样做有三层好处第一窗口人员可以直接照框架答复不需要再自己组织语言第二模板让评测变得容易对齐了几个固定维度打分就行第三模板天然抑制了模型编造——它必须在每个槽位里填内容没法漫无边际地发挥。另外我们配合了一个可配置的敏感词拦截列表。涉及个人隐私、具体审批进度、内部意见等业务方明确不能由AI回答的词汇一旦命中就直接转到人工通道不进生成流程。这个列表由业务方持续补充我们做成后台可编辑的配置项。整套在生成流程之前拦截属于成本和效果比很高的投入。5. 效果评测怎么做先定义答得好再谈指标提升5.1 评测集来自真实咨询问题而不是自己拍脑袋项目做到第三周我们发现最大的难点不是调模型而是说不清到底什么样算答得好。技术团队觉得答案流畅就行业务方觉得必须依据齐全两边标准不一样就很容易陷入无休止的扯皮。解决办法是先建评测体系把答得好拆成可打分的维度形成一套固定的评测集。评测集的问题全部来自真实咨询记录抽样不是我们自己编的。我从业务科要了过去半年的咨询台账筛掉那些用搜索引擎就能精确匹配的简单问题留下真正需要理解归纳判断的问题一共整理出一千条左右覆盖四类典型场景流程类办理XX业务需要几步、条件类申请XX补贴需要满足哪些条件、材料类需提交哪些材料复印件是否可以、比较类新旧规定有什么不同。每一类都要求答案必须能追溯到具体条款否则就算内容看着合理也是失败答案。评测集建好以后整个迭代过程就变得非常高效。每次改完提示词或者调整检索策略先在这个固定集合上跑一遍自动评测看总体趋势有没有变坏再抽样走人工评审。没有这个基准你根本说不清改动是变好了还是变差了到最后就拼感觉这是做技术的大忌。5.2 人工评分表里最重的一项依据可溯性人工评审是我们每周的核心工作。我们请业务科的业务骨干和技术团队一起对抽样答案按四个维度打分每个维度零到五分。四个维度分别是内容准确性、依据完整性、依据可溯性、表述清晰性。内容准确性是硬指标出现与材料冲突的事实错误直接判零分不接受大体正确但金额差一位这种说法。依据完整性看关键条件有没有漏项政务回答最怕漏例外情形漏了就会导致用户误判。依据可溯性要求答案里的每一条结论都能对应到具体条款路径这条我给的权重是最高的因为一旦可溯源前面两个维度就算偶尔有瑕疵也能被发现和纠正反之听起来再正确的答案找不到出处等于没依据。表述清晰性是给窗口人员看的看的是能不能直接照着念。评分结果每周汇总一次形成准确率、完整率、可溯率三个百分数。第一轮评测的准确率只有六成出头重灾区是答案归纳不完整和引用串位引用了文件A的内容却标成文件B。第二轮我们加强了检索重排和引用校验可溯率涨上去了但完整性掉下来了——很多答案只回答了问题的一半因为召回片段里少了后半段。第三轮调整了切分策略和重排候选数量才把这根曲线拉平。整体跑完准确率从六成提高到八到九成区间到后面每次改动带来的波动已经很小我们就知道这个系统进入可上线状态了。5.3 对抗性测试专门看它不该答的时候答不答常规评测能看出答得好不好但政务场景还得回答另一个问题不该答的时候它会不会乱答。所以我们专门设计了一组对抗性测试包括完全无关的问题今天天气怎么样、涉敏问题、诱导性问题既然文件没说不行是不是可以、以及跨领域问题。这些问题的预期结果统一是拒答或转人工一项没做到就要修正。对抗性测试跑下来暴露了一个很有意思的问题模型特别喜欢在政策边界上顺着用户说。比如用户问材料里没有明确禁止是不是就代表允许模型有时会生成根据现有材料推断应视为允许。这在业务上完全不能接受——政务逻辑里未提及不等于默许很多审批事项实行的是正面清单管理没写就是不行。我们最后的处理方式是在系统提示词里明确加了一句不得基于材料未提及推断为允许或禁止材料未提及的事项一律回答无法确认。评测集里也专门加了一批这类问题做回归确保以后不会复发。坦白说自动评测指标能覆盖的部分有限成本也高但它绝对不能省。它至少能保证每次改动后的趋势是收敛的再通过人工评审守住最终质量线。对这个项目来说评测体系推动的迭代比模型效果本身更关键——因为模型能力摆在那里真正拉开差距的是你有没有一套机制能持续发现它在哪里犯错然后针对性地把漏洞堵上。6. 踩过的四个坑从OCR乱码到多轮对话漂移6.1 坑一OCR把文件结构弄乱了第一个坑出现在知识库建设早期。一批扫描版文件过了OCR之后我们直接把结果送去切分结果引用路径全乱了文件的章和条标题全部变成普通段落切分程序认不出哪些是标题、哪些是正文。用户问一条细则系统引用的依据路径指向了完全错误的条款位置等于引文出处张冠李戴。排查半天根因是OCR输出的纯文本丢了版面结构信息。我们后来做了两件事修正一是对关键文件改用带版面分析的OCR流程并在导入前做人工抽检尤其是文件目录页和条款标题二是写了一个条款编号的正则锚点识别逻辑切分时如果识别不到合理的第X条编号就把这一段丢弃而不是将就着挂到前一条下面。宁可少一条材料也不能把错误的结构塞进知识库。这个坑给我的教训是语料管道的错误会一路放大到最终答案OCR这一步的投入永远值得。6.2 坑二纯向量检索召回失败混合检索救回来了第二个坑是召回问题。我们用纯向量检索做了两周发现用户口语化提问时经常召回不中。典型的例子用户问这个钱什么时候能到账文件里的写法是补贴发放时限两个说法在语义上高度相关但向量相似度打分就是不给力导致最相关的那段文件根本没进候选集。没有正确的材料再好的生成模型也答不对。我们当时的解决思路是上混合检索把BM25关键词检索和向量检索各自的top结果合并再做重排。同时建了一个小型的政务术语同义词词典把高频口语说法映射到标准术语上查询改写阶段先做一步转换。这两个改动加在一起相关片段召回率有了非常明显的提升。后来测试发现一些用纯向量检索根本召不回的问题混合检索可以直接命中。如果你也在做类似项目我建议从一开始就把混合检索作为标配不要等到踩坑了才补。6.3 坑三多轮对话漂移最后我干脆限制了对话第三个坑出现在上线前的模拟测试。有测试人员连续问了三五个问题第一个问我想办XX业务第二个问需要什么材料第三个问一般多久能批下来。看起来是一段正常的多轮对话但模型在第二轮和第三轮开始把一些混淆信息带进来——比如把没讨论过的业务也假设成了前缀生成了牛头不对马嘴的回答。我们自己内部叫它多轮漂移。政务咨询的实际情况和通用聊天不太一样绝大多数用户问问题就是一问一答很少有连续追问十个回合的场景。与其花大力气做复杂的多轮状态管理不如干脆把系统的对话能力降级成有界多轮每一轮只保留上一轮的简短主题摘要不把完整历史塞给模型一旦检测到用户当前问题涉及的主题和上一轮不一致立即清空上下文。这里我还想加一句设计产品时别掉进越智能越好的陷阱满足真实使用模式才是正道。6.4 坑四权限和审计拖到上线前才补第四个坑纯属进度管理失误。我们一直在忙效果调优把权限控制这事排到了后面结果等系统准备接入内网办公平台时才发现不同科室能看到的文件范围不同。如果不在检索阶段做数据过滤A科室用户的答案引用里可能带出B科室的内部文件这个在政务环境里是没法过审的。于是我们赶在最后阶段给知识库加了文件级权限标签每个文件标记可见科室范围检索前先按账号权限过滤同时记录每一次问答的操作日志用于审计。这个工作其实并不复杂但因为它涉及的不是效果而是合规很容易在项目推进过程中被忽略。提醒所有做类似项目的朋友权限和审计从第一天就要设计进架构不要留着当上线前的彩蛋。到目前为止系统已经内测了三个月每天有几十个真实咨询在跑。我的一个体会是这类项目最值钱的部分反而不是大模型本身而是围绕如何把生成能力关进笼子里做的整套工程——引用校验、阈值拦截、模板约束、权限过滤、评测机制每一个单独拿出来都不算新技术串起来才构成政务场景能用的AI系统。以后如果有机会我再单独写一期知识库增量更新和上线后的问题复盘。 
长河君 · 2026/10/18 22:47:44 · 阅读 1.2k 政务场景下RAG落地实践：从政策知识库到幻觉治理
1. 项目最初的定位先想清楚政策支撑支撑的到底是什么1.1 需求从一次窗口接待开始大概三个月前我们单位接了一个内部项目编号就叫生成式人工智能赋能政务服务的政策支撑——系列记录的第一篇。名字听起来挺大但需求其实是从很具体的一次窗口接待来的业务科同事每天要面对几十个咨询问题翻来覆去就那几类但他们每次都得翻文件夹、找依据、核对口径再组织语言答复。一个简单问题从翻文件到确认时效性至少几分钟。赶上咨询高峰后面排队的人急窗口的人也急。我们当时调研了一圈发现所谓的政策支撑落到实际业务上其实就三个诉求第一窗口人员需要一个能在几秒钟内查到底层条款的工具而不是一检索就弹出一堆PDF让自己慢慢翻第二不同的人回答同一个问题口径要一致不能这次说需要原件下次说复印件也行第三也是最关键的答错了不行——政务咨询一旦给错信息群众多跑一趟都是事故。所以项目的本质不是做一个聪明的聊天机器人而是做一个知轻重的辅助检索与拟答复工具。这个定位上的差别直接决定了后面几乎所有技术选型。如果我们一开始就冲着AI什么都答去后面大概率会死在幻觉治理和口径审核上。如果把它当作一个带生成能力的知识检索系统每个答案都强制有依据、有出处、可回溯事情就清楚多了。我给这类项目的总结就一句话生成式AI在政务场景里价值不在于创造而在于把已有的、分散的信息用最准确的方式组织和表达出来。1.2 三条边界不做开放问答、不直接面对群众、不确定就不答需求梳理到一半业务方一度提出很多美好想象能不能让AI直接回答群众的问题能不能把几十年的文件全部学进去当百科用我们一样样往下砍最后立了三条规定写进了需求文档里。第一不做开放问答。系统的服务范围只锁定在政策文件库里已有的内容。问库外的事不问领域的事直接走拒答流程。这一点看起来浪费了生成式AI的能力但实际上保住了口碑。用户对大模型容忍胡编但对政务咨询零容忍。与其答错不如答这个问题我暂时无法确认请转人工。第二不直接面向群众。系统输出的答案是给内部业务人员看的草稿不是最终答复。任何对外发布的内容必须由人工确认以后才能出去。这条边界既是技术上的安全垫也是责任上的防火墙。AI可以帮你把草稿写到八分熟剩下两分必须人来把关。第三不确定就不答。写进验收标准的第一条要求宁可拒答不可编造。所谓不确定包括检索得分不高、依据片段存在歧义、材料里没有直接答案等情况。后续我们在工程上做了三层拦截来实现这条原则下面专门有一节讲。这三条边界定下来以后项目的MVP范围也清晰了。我们选了三个高频业务方向做试点每类几十份核心文件先把质量和流程打磨通再谈扩量。做这类项目最怕贪大求全——一上来想把全领域都覆盖结果评测集做不出、口径对不上、效果说不清楚最后只能变成演示很惊艳、上线没人用的展厅系统。2. 技术选型里的取舍为什么是私有化部署加RAG而不是直接调大模型API2.1 第一轮淘汰数据合规决定了不能走API路线方案评审第一轮大家争论最激烈的是要不要接外部大模型API。坦白说如果只看成本和效果通用大模型API是性价比最高的选择——不需要买GPU不需要管运维效果还比小模型好一个档次。但项目一过数据合规评估这个方案当场就被毙了。原因是政策文件、咨询记录这些东西属于内部敏感数据不能出内网。把用户问题和文件内容发到外部API哪怕协议里写得再好从安全角度也不能接受。这一点不仅是政务场景很多国企、金融、医疗项目都是同样的逻辑。那段时间我接触了几个同行大家遇到的情况几乎一模一样先进的技术方案统统被数据不能出域一条卡住最后老老实实走私有化部署路线。所以我建议所有做这类项目的团队第一件事不是选模型而是先和合规同事确认清楚数据边界。边界一确定选项就少一半。我们最终的环境是单位内网的一台GPU服务器操作系统和软件栈全部适配国产化要求。这基本封死了直接调云端API和用最新最大模型两条路倒逼我们在本地化方案里把效果挖到极致。2.2 底座模型为什么选了14B这一档本地部署最大的限制是显存和推理速度。当时我们比较了三档开源底座模型大概是7B、14B、30B这种量级。直接说结论最终选了14B这一档原因有三个。第一7B模型在指令跟随和长文档推理上明显偏弱。政策问答有一种典型场景用户问我这种情况能不能申请补贴答案在文件里分散在不同的条款——资格条件在第几条、例外情形在第几条、提交材料又在附件里。7B模型经常只看到资格条件就下结论忽略了例外条款这是政务场景不能接受的遗漏。第二30B模型效果确实更好但需要更大的显存和更高的算力推理速度也慢。我们的场景是窗口人员即时使用一个答案等十几秒体验就很难受了。第三14B刚好在效果和成本之间取了平衡单卡能跑推理速度在可接受范围内配合RAG做得好的话效果并不输给更大的模型。这里多说一句模型不是越大越好关键看有没有把知识放到该放的位置。我们在后面的实践里发现底座模型只负责根据材料总结答案这个推理任务而具体的政策知识全部通过检索环节喂进去。这样一来模型本身不需要记住任何文件细节14B的参数量完全够用。2.3 检索、重排与生成的流水线设计架构上我们采用了标准的RAG模式但做了很多政务场景特有的改造。先说主干流程用户输入问题后系统先做查询改写把口语化表达转成更贴近政策术语的查询语句接着做混合检索同时跑关键词检索和向量检索各取一批候选段落然后重排从候选里挑出最相关的五到八段最后把这些段落和原始问题一起交给底座模型生成带引用的答案。为什么要用混合检索而不是纯向量检索这个后面踩坑部分会细讲这里先说结论政务文件里的术语和口语之间差异很大用户说这个钱什么时候到账文件里写的是补贴发放时限纯向量检索不一定能对上。关键词检索虽然土但对这类精准词匹配很有效。两者结合召回率才稳定。重排这一步也容易被忽略。向量检索一次性召回二十个段落如果全部塞给LLM模型容易被无关内容干扰答案质量反而下降。重排模型的作用是先按相关度排出顺序只把最相关的几段送进生成阶段。这样既保证上下文精炼又能过滤掉大部分噪音。整套流水线的设计原则就一条每一个环节都为了减少模型自由发挥的空间而不是增加它的发挥空间。第3个关键取舍是向量库的选择。当时市面上可选的开源方案不少我们最后选了一个内网部署成熟、中文分词和索引效率都不错的产品。这里不推荐具体品牌因为几个月后我们可能还会换但选型标准可以分享一是必须支持纯内网离线部署二是索引更新要够快我们每周要增量导入新文件三是查询延迟要低四是社区活跃度要好——因为内网环境没法搜到太多第三方资料踩坑时主要靠社区Issue撑腰。3. 政策知识库的构建切分方式、元数据和时效性数据这一关怎么过3.1 语料清洗扫描件、表格和附件是最大的坑知识库是整个项目的真正瓶颈。说过很多次RAG的效果上限由数据质量决定模型只是把数据的价值释放出来。我们在数据准备上花的时间超过整个项目的三分之一而且这个比例我认为非常合理。政策文件语料的形态五花八门大致分四类扫描版的红头文件、Word版定稿、网站发布的通知页面、以及作为附件附在正文后面的实施细则和表格。每一类都有各自的坑。扫描件得先过OCR识别出来的文字经常带页眉页脚、水印噪声有些文件还被印章压住了关键文字Word版格式不统一有的用多级列表有的用纯文本敲空格对齐网页通知更麻烦正文旁边全是导航栏、相关链接、版权信息这些都要清掉附件则经常被漏掉——很多政策正文只有两页真正的操作细则全在附件里不处理附件就等于丢了半个知识库。清洗流程我们做了标准化先统一转成文本格式再按规则清除页眉页脚和水印特征第三步做版面分析把标题、正文、表格结构识别出来最后对OCR结果做人工抽检。抽检比例不用很高但重点文件必须逐字核对尤其涉及金额、期限、材料清单这类关键信息。OCR识别错一个字补贴金额3000元变30000元系统的所有努力都会毁在一处文字错误上。3.2 按文件逻辑结构切分而不是固定窗口早期做的原型里我们把文件按每500个字符硬切成一段结果惨不忍睹一条规定被拦腰截断上下句残缺附件标题和正文内容被切到不同的向量里检索时经常召回一些半句话。后来我们把切分策略彻底改成按政策文件的逻辑结构切分。政务文件有非常清晰的层级文件头 - 章 - 条 - 款 - 项很多还有附件。我们就按照这个结构来切每一条作为基本切片超过一定长度的条款再按款细拆但子切片必须带上父条款的上下文摘要避免模型只看到后半句却丢了前面的限定条件。每个切片保存三部分元数据来源文件唯一编号、条款路径比如某管理办法-第三章-第十条-第二款、以及文件当前的效力状态现行有效、已修订、废止。还有一个细节政务文件里经常出现附件一、附件二而且附件正文才是真正能回答问题的内容。我们最开始没有单独提取附件导致很多问题的依据缺失。后来清洗流程里加了一步附件识别与关联把附件作为独立的文档处理同时在元数据里维护与正文的父子关系。这一步很琐碎但对召回效果的提升立竿见影。3.3 元数据和时效性让系统知道哪份文件说了算政策知识库和普通技术文档库最大的区别在于同一个问题新旧文件给出的答案可能是互相矛盾的。用户问申请这个补贴需要什么材料如果系统同时召回了一份2019年的旧办法和一份今年的新细则语言模型很可能把两者混在一起生成一段四不像回答。这个问题必须靠元数据层面的时效性机制来解决。我们的做法是给每份文件标记层级和状态新文件导入时如果标题与现有文件相同或者发文内容明显覆盖旧文件就把旧文件标记为被修订状态检索排序时默认排除只有用户明确问以前的规定是什么新旧政策有什么区别时才把已失效文件拉出来作为对比参考。另外我们给每条切片都打了生效日期标签排序时按现行有效 当年修订 已废止的优先级处理。这一步是政务类RAG和普通RAG最不一样的地方也是最容易被技术团队忽略的地方。通用场景里知识过时问题不大但政策场景里拿废止文件答题后果非常严重。我们做了很多次回归测试专门构造新旧规定冲突的问题确保系统永远优先采用最新有效文件。曾经有一轮测试发现系统在回答某问题时引用了一个旧条款排查原因是检索阶段把旧文件和新文件同时召回而重排模型没法判断时效优先级。后来我们直接在检索前就做了按效力状态过滤用规则手段把这个问题彻底解决——这种问题靠模型自觉是不靠谱的要放到管线上用规则硬约束。4. 幻觉治理三板斧引用溯源、兜底拒答和模板化输出4.1 强制引用让每句话都有出处政务场景对幻觉的容忍度极低所以我们的防幻觉设计不是堆一两个技巧而是做成了一整套路管线我用三板斧来概括。第一板斧是强制引用。系统提示词里写得非常死只准基于检索提供的材料作答必须引用具体的条款编号任何材料中没有的信息一律不允许补充。但这里要说句实话——提示词约束并不是100%有效的模型偶尔还是会自由发挥或者编一个不存在的条款号。所以我们加了程序层面的校验生成结束后解析结果里每个引用的ID检查它是否真的存在于本次检索返回的片段集合里不存在就直接拦截这条答案走拒答流程。这一步等于把生成环节可能出错的风险在输出端又封了一道。实际操作中我们让输出走一个结构化格式方便程序校验。比如模型返回的是一个固定结构的JSON包含回答正文、引用清单、置信度三个字段。引用清单里的每一条都要能对应到知识库里一个真实的条款路径。这样做的额外好处是前端展示时可以直接把依据渲染成可点击的原文片段窗口人员一点就能核对原文信任感一下子就上来了。很多同行觉得引用溯源是给用户看的装饰我的体会是它同时是内部质检的抓手——没有引用结构你连AI有没有乱答都很难自动检查。4.2 兜底拒答阈值怎么设才合理第二板斧是兜底拒答。无论检索和生成做得再好总有知识库覆盖不到的问题和模型拿不准的情况。我们设计了两道阈值来触发拒绝回答。第一道是检索置信度阈值如果检索阶段所有候选片段的相似度最高分都低于0.55这个值是我们在内部小测试集上反复调出来的系统认为知识库里没有可支撑答案的内容直接返回预设的拒答话术。第二道是生成忠实度阈值生成结束后用程序计算答案和检索片段之间的语义相似度低于0.6就认为模型超纲发挥了同样拦截。两道阈值的共同效果是让系统在答不出来和答错了之间选择前者。关于阈值设置我要特别提醒别想偷懒直接套网上的参数。不同业务领域、不同底座的模型、不同的向量模型得分分布完全不一样。政务场景里我们宁可把阈值调高一些换取更低的错误率——因为一次错误答复的代价远超几十次拒答带来的不便。而且拒答话术也要有人情味我们写了三档完全无相关材料时回复根据现有材料暂无法直接回答有材料但不足以得出明确结论时回复材料不完整建议转人工核实涉及内部审批细节时回复该问题涉及内部流程请联系对应业务科室。这样用户不会一头撞在冷冰冰的无法回答上引导也更顺畅。4.3 模板化输出限制生成自由度提高可读性第三板斧是模板化输出。很多AI产品追求让模型自由发挥、写小作文政务场景恰恰相反——答案的自由度越低可用性越高。我们最后把答案强制成一个固定的四段式结构结论、依据、条件、例外。结论部分先给简明的判定结果比如符合条件可以申请依据部分列出引用的条款原文关键句条件部分把需要满足的资格条件逐条列出例外部分写明材料中提到的例外情形没有就写材料中未提到例外情形。这样做有三层好处第一窗口人员可以直接照框架答复不需要再自己组织语言第二模板让评测变得容易对齐了几个固定维度打分就行第三模板天然抑制了模型编造——它必须在每个槽位里填内容没法漫无边际地发挥。另外我们配合了一个可配置的敏感词拦截列表。涉及个人隐私、具体审批进度、内部意见等业务方明确不能由AI回答的词汇一旦命中就直接转到人工通道不进生成流程。这个列表由业务方持续补充我们做成后台可编辑的配置项。整套在生成流程之前拦截属于成本和效果比很高的投入。5. 效果评测怎么做先定义答得好再谈指标提升5.1 评测集来自真实咨询问题而不是自己拍脑袋项目做到第三周我们发现最大的难点不是调模型而是说不清到底什么样算答得好。技术团队觉得答案流畅就行业务方觉得必须依据齐全两边标准不一样就很容易陷入无休止的扯皮。解决办法是先建评测体系把答得好拆成可打分的维度形成一套固定的评测集。评测集的问题全部来自真实咨询记录抽样不是我们自己编的。我从业务科要了过去半年的咨询台账筛掉那些用搜索引擎就能精确匹配的简单问题留下真正需要理解归纳判断的问题一共整理出一千条左右覆盖四类典型场景流程类办理XX业务需要几步、条件类申请XX补贴需要满足哪些条件、材料类需提交哪些材料复印件是否可以、比较类新旧规定有什么不同。每一类都要求答案必须能追溯到具体条款否则就算内容看着合理也是失败答案。评测集建好以后整个迭代过程就变得非常高效。每次改完提示词或者调整检索策略先在这个固定集合上跑一遍自动评测看总体趋势有没有变坏再抽样走人工评审。没有这个基准你根本说不清改动是变好了还是变差了到最后就拼感觉这是做技术的大忌。5.2 人工评分表里最重的一项依据可溯性人工评审是我们每周的核心工作。我们请业务科的业务骨干和技术团队一起对抽样答案按四个维度打分每个维度零到五分。四个维度分别是内容准确性、依据完整性、依据可溯性、表述清晰性。内容准确性是硬指标出现与材料冲突的事实错误直接判零分不接受大体正确但金额差一位这种说法。依据完整性看关键条件有没有漏项政务回答最怕漏例外情形漏了就会导致用户误判。依据可溯性要求答案里的每一条结论都能对应到具体条款路径这条我给的权重是最高的因为一旦可溯源前面两个维度就算偶尔有瑕疵也能被发现和纠正反之听起来再正确的答案找不到出处等于没依据。表述清晰性是给窗口人员看的看的是能不能直接照着念。评分结果每周汇总一次形成准确率、完整率、可溯率三个百分数。第一轮评测的准确率只有六成出头重灾区是答案归纳不完整和引用串位引用了文件A的内容却标成文件B。第二轮我们加强了检索重排和引用校验可溯率涨上去了但完整性掉下来了——很多答案只回答了问题的一半因为召回片段里少了后半段。第三轮调整了切分策略和重排候选数量才把这根曲线拉平。整体跑完准确率从六成提高到八到九成区间到后面每次改动带来的波动已经很小我们就知道这个系统进入可上线状态了。5.3 对抗性测试专门看它不该答的时候答不答常规评测能看出答得好不好但政务场景还得回答另一个问题不该答的时候它会不会乱答。所以我们专门设计了一组对抗性测试包括完全无关的问题今天天气怎么样、涉敏问题、诱导性问题既然文件没说不行是不是可以、以及跨领域问题。这些问题的预期结果统一是拒答或转人工一项没做到就要修正。对抗性测试跑下来暴露了一个很有意思的问题模型特别喜欢在政策边界上顺着用户说。比如用户问材料里没有明确禁止是不是就代表允许模型有时会生成根据现有材料推断应视为允许。这在业务上完全不能接受——政务逻辑里未提及不等于默许很多审批事项实行的是正面清单管理没写就是不行。我们最后的处理方式是在系统提示词里明确加了一句不得基于材料未提及推断为允许或禁止材料未提及的事项一律回答无法确认。评测集里也专门加了一批这类问题做回归确保以后不会复发。坦白说自动评测指标能覆盖的部分有限成本也高但它绝对不能省。它至少能保证每次改动后的趋势是收敛的再通过人工评审守住最终质量线。对这个项目来说评测体系推动的迭代比模型效果本身更关键——因为模型能力摆在那里真正拉开差距的是你有没有一套机制能持续发现它在哪里犯错然后针对性地把漏洞堵上。6. 踩过的四个坑从OCR乱码到多轮对话漂移6.1 坑一OCR把文件结构弄乱了第一个坑出现在知识库建设早期。一批扫描版文件过了OCR之后我们直接把结果送去切分结果引用路径全乱了文件的章和条标题全部变成普通段落切分程序认不出哪些是标题、哪些是正文。用户问一条细则系统引用的依据路径指向了完全错误的条款位置等于引文出处张冠李戴。排查半天根因是OCR输出的纯文本丢了版面结构信息。我们后来做了两件事修正一是对关键文件改用带版面分析的OCR流程并在导入前做人工抽检尤其是文件目录页和条款标题二是写了一个条款编号的正则锚点识别逻辑切分时如果识别不到合理的第X条编号就把这一段丢弃而不是将就着挂到前一条下面。宁可少一条材料也不能把错误的结构塞进知识库。这个坑给我的教训是语料管道的错误会一路放大到最终答案OCR这一步的投入永远值得。6.2 坑二纯向量检索召回失败混合检索救回来了第二个坑是召回问题。我们用纯向量检索做了两周发现用户口语化提问时经常召回不中。典型的例子用户问这个钱什么时候能到账文件里的写法是补贴发放时限两个说法在语义上高度相关但向量相似度打分就是不给力导致最相关的那段文件根本没进候选集。没有正确的材料再好的生成模型也答不对。我们当时的解决思路是上混合检索把BM25关键词检索和向量检索各自的top结果合并再做重排。同时建了一个小型的政务术语同义词词典把高频口语说法映射到标准术语上查询改写阶段先做一步转换。这两个改动加在一起相关片段召回率有了非常明显的提升。后来测试发现一些用纯向量检索根本召不回的问题混合检索可以直接命中。如果你也在做类似项目我建议从一开始就把混合检索作为标配不要等到踩坑了才补。6.3 坑三多轮对话漂移最后我干脆限制了对话第三个坑出现在上线前的模拟测试。有测试人员连续问了三五个问题第一个问我想办XX业务第二个问需要什么材料第三个问一般多久能批下来。看起来是一段正常的多轮对话但模型在第二轮和第三轮开始把一些混淆信息带进来——比如把没讨论过的业务也假设成了前缀生成了牛头不对马嘴的回答。我们自己内部叫它多轮漂移。政务咨询的实际情况和通用聊天不太一样绝大多数用户问问题就是一问一答很少有连续追问十个回合的场景。与其花大力气做复杂的多轮状态管理不如干脆把系统的对话能力降级成有界多轮每一轮只保留上一轮的简短主题摘要不把完整历史塞给模型一旦检测到用户当前问题涉及的主题和上一轮不一致立即清空上下文。这里我还想加一句设计产品时别掉进越智能越好的陷阱满足真实使用模式才是正道。6.4 坑四权限和审计拖到上线前才补第四个坑纯属进度管理失误。我们一直在忙效果调优把权限控制这事排到了后面结果等系统准备接入内网办公平台时才发现不同科室能看到的文件范围不同。如果不在检索阶段做数据过滤A科室用户的答案引用里可能带出B科室的内部文件这个在政务环境里是没法过审的。于是我们赶在最后阶段给知识库加了文件级权限标签每个文件标记可见科室范围检索前先按账号权限过滤同时记录每一次问答的操作日志用于审计。这个工作其实并不复杂但因为它涉及的不是效果而是合规很容易在项目推进过程中被忽略。提醒所有做类似项目的朋友权限和审计从第一天就要设计进架构不要留着当上线前的彩蛋。到目前为止系统已经内测了三个月每天有几十个真实咨询在跑。我的一个体会是这类项目最值钱的部分反而不是大模型本身而是围绕如何把生成能力关进笼子里做的整套工程——引用校验、阈值拦截、模板约束、权限过滤、评测机制每一个单独拿出来都不算新技术串起来才构成政务场景能用的AI系统。以后如果有机会我再单独写一期知识库增量更新和上线后的问题复盘。