题库规划 / 02-政务小灵通-业务深挖
← 上一章 下一章 →

02 - 政务小灵通：业务场景与架构深挖篇

核心定位：严肃政务场景下大模型落地实践，聚焦知识域隔离、防幻觉降级、政策时效性治理与多端协同。

Q1: 请介绍一下「政务小灵通」这个项目的业务背景、解决的核心痛点以及你们的目标用户是谁？

回答（求职者口吻）：
「政务小灵通」是我们面向政务单位工作人员和办事人员打造的智能化政策咨询与任务助手平台。

在传统政务办公中，存在三大核心业务痛点：
1. 政策法规繁多且分散：国务院、省、市各级政策文件、内部规章和红头文件分布在不同系统和内网文件夹中，业务人员查找一条办事依据往往需要跨多个库手动检索，耗时费力。
2. 专业门槛高与口径不一致：政策条文法律用语极其严谨复杂，新员工或跨部门人员难以快速理解和提炼办事要点，不同窗口对外答复的口径容易出现偏差。
3. 复杂分析任务耗时：领导或业务科室经常需要进行“多地政策对比”、“创新案例对标”或“历史政策演进汇总”，传统人工撰写简报需要数天时间整理。

针对这些痛点，我们的目标用户主要包括两类：一是基层业务与窗口办事人员，通过微信小程序进行日常多轮政策咨询和办事依据核对；二是政务知识运营与政策研究人员，通过 Web 管理端进行知识文档维护、权限审批、复杂对比任务发起与任务审计。系统通过 AI 的语义理解与精准检索，将政策查找和分析效率提升了数倍。

Q2: 为什么政务场景下大模型问答不能直接使用通用大模型（如公网版 DeepSeek/ChatGPT 直答），而必须搭建私有知识库与 RAG 架构？

回答（求职者口吻）：
政务场景的特殊性决定了通用大模型“裸奔”完全无法满足业务落地要求，核心原因有四点：

  1. 时效性与私有性截然不同：通用大模型的预训练语料存在知识截止日期，且无法涵盖各级政府内部的印发文件、科室办事指南及未公开案例。政务问答必须基于“最新、真实、特定范围”的私有文档。
  2. 严肃性与零幻觉容忍：政务问答涉及行政审批、资金发放、政策解释等严肃业务，回答必须“字字有出处，句句可溯源”。通用模型极易产生“看似合规实则捏造”的幻觉，一旦给出错误办事依据会引发严重的行政事故。
  3. 数据安全与网络合规：政务数据严禁未授权出境或泄露，很多敏感文件必须在指定安全网络或私有云环境中流转。
  4. 严格的权限隔离：不同层级、不同科室的人员能查看的文件密级与范围不同，通用大模型没有内置的租户、组织和资源级鉴权机制。

因此，必须通过 RAG（检索增强生成）架构，将大模型的能力定位为“基于受限检索事实的阅读理解与表达工具”，通过外挂严格隔离的私有知识库来确保回答的确定性与合规性。

Q3: 你们系统划分了「公开政策、客户私有、创新案例」三个知识域，这三个域的业务定位、数据来源和隔离机制具体是怎么设计的？

回答（求职者口吻）：
为了平衡“跨单位通用知识共享”与“本单位私有数据安全”，我们在业务架构上设计了三层知识域模型：

  1. 公开政策域（Public Domain）：
    - 定位：国家及地方公开发布的法律法规、国务院文件、省市规范性公文。
    - 数据来源：通过自动化采集脚本从政府官网、中国政府网定期采集清洗入库。
    - 隔离与权限：全员可读，全局共享，无需特殊审批。
  2. 客户私有域（Private Domain）：
    - 定位：各局委办、特定科室内部的办事规程、红头文件、会议纪要、未公开批复。
    - 数据来源：各单位知识管理员在 Web 端手动上传或内网 OA 系统对接同步。
    - 隔离与权限：采用“租户 ID + 组织机构 ID + 用户角色 RBAC”三重硬隔离。在向 RAGFlow 检索时，业务层会在 Filter 条件中强制注入当前用户的权限上下文，未授权的文档分块在向量检索层即被物理过滤，绝不进入大模型 Prompt。
  3. 创新案例域（Case Domain）：
    - 定位：全国其他先进地区在政务改革、营商环境优化等方面的优秀做法和创新方案。
    - 数据来源：人工精选录入与结构化加工。
    - 隔离与权限：主要供特定研究员和领导层在做“政策对比/案例对标”时定向挂载检索。

这种三域分层既保证了通用政策的复用沉淀，又彻底杜绝了私有敏感文档的跨部门越权泄露。

Q4: 政务场景对“幻觉”（凭空捏造）零容忍，你们在业务和产品机制上制定了哪些防幻觉与兜底降级规则？

回答（求职者口吻）：
为了将幻觉风险降到最低，我们在“检索前-生成中-生成后”构建了全流程的防御与降级闭环：

  1. 检索相关度阈值熔断（检索前）：
    - 设定混合检索相似度综合评分阈值（例如向量相似度与 BM25 综合得分低于基准线）。如果检索返回的所有分块相关度均不达标，说明知识库无匹配依据，系统直接触发兜底，输出标准政务措辞：“很抱歉，在您权限范围内的政策知识库中暂未找到相关依据，建议您咨询对应业务科室（附联系方式）”，直接阻断调用 LLM 生成，从源头杜绝幻觉。
  2. 严苛的 System Prompt 约束（生成中）：
    - 在 Prompt 中明确约束：“你是一名严肃的政务助手，必须严格且仅根据提供的【参考文本】作答；若参考文本中没有提及，严禁根据自身常识推测或补充，必须明确回答‘依据不足’；每个论断必须在句末标注引用序号 [1]。”
  3. 引用精准溯源与强制校验（生成后）：
    - 模型生成的每一条结论，必须绑定对应参考片段的 ID。若大模型给出了引用标记但后端校验未命中任何真实 Chunk，或者生成了知识库不存在的条款，系统会对文本进行二次敏感度审核或降级提示。
  4. 人工申诉与纠错闭环：
    - 小程序端提供“回答有误反馈”按钮，一键将问题上下文、检索片段及模型输出回流至 Web 管理端审计中心，由人工专家进行知识库标注或修正。

Q5: 政务政策文件存在明显的时效性（如废止、修改、最新施行），系统在业务层如何保证检索到最新有效政策，避免引述失效法规？

回答（求职者口吻）：
政策时效性是政务问答的核心难点。我们主要通过“元数据结构化工程 + 检索期时间衰减过滤”双重机制解决：

  1. 元数据结构化治理（入库期）：
    - 每篇政策入库时，必须提取并校验以下元数据：publish_date（印发日期）、effective_date（施行日期）、expire_date（废止日期）、status（有效/已修改/已废止）、superseded_by（替代文件 ID）、issue_org（发文机关）以及 doc_level（国家级/省级/市级）。
  2. 动态过滤与时效加权（检索期）：
    - 硬过滤：检索时默认只过滤 status = 'ACTIVE' 且 effective_date <= CURRENT_DATE 的文档；已被废止的文件直接排除，除非用户明确提问“历史演变”或“某年某政策”。
    - 新旧政策关系链提示：如果命中某条已被部分修订的文件，业务层会在引用卡片中额外追加提示：“注意：该文件第 X 条已由《XXXX 号文》更新”，并将最新文件推荐给用户。
    - 时间衰减加权：在混合检索重排阶段，对相近相似度的文档，按发布时间赋予线性衰减权重，优先让最新印发的指导意见排在最前。

Q6: 用户的提问往往很口语化或含糊（如“我想办个营业执照需要带什么”），而政策法规都是极其书面化的法条，你们在业务上如何解决这种语义鸿沟？

回答（求职者口吻）：
这种口语提问与书面法条之间的语义差异，单纯靠传统关键字搜索（BM25）召回率非常低。我们采用了“Query 改写（Query Rewriting）+ 稠密向量语义检索 + 业务同义词表”的多级转化策略：

  1. 大模型 Query 改写与意图对齐：
    - 当收到口语化输入后，首先经过轻量快速模型做一步语义重构。例如将“我想办个营业执照需要带什么”改写扩充为：“个体工商户/企业 营业执照 设立登记 所需材料 申请材料清单 身份证 住所证明”，将口语转换为政务标准公文用语与核心实体词。
  2. 稠密向量（Dense Embedding）语义泛化：
    - 依赖语义向量模型（如 BAAI/bge 系列），将口语语义映射到高维语义空间，与政策中“办理设立登记应提交的文件、证件”实现跨表述的语义对齐。
  3. 政务专业同义词/实体词典（Synonym & Entity Mapping）：
    - 在预处理分词阶段维护政务专有词库，如“生娃报销”自动关联“生育保险待遇核准支付”，“公积金买房”关联“住房公积金个人住房贷款”，增强 BM25 精准召回。
  4. 多轮澄清机制：
    - 若用户输入过于泛化（如“补贴怎么领”），系统会识别为多意图，主动追问：“您是想了解高校毕业生就业补贴、企业稳岗补贴还是创业补贴？请选择或补充说明。”

Q7: 任务 Agent 模式下支持「汇总/对比/跟踪/案例对标」等目标，能举一个具体的政务业务场景案例说明 Agent 是如何工作的吗？

回答（求职者口吻）：
我以政务研究中非常高频的「跨地区营商环境政策对比」为例：

  • 用户下达目标：“请对比武汉市与杭州市在 2024 年针对专精特新中小企业扶持政策的异同，重点对比资金奖补、用地支持和人才落户三个维度。”
  • Agent 执行流程：
    1. 计划拆解（Plan）：Agent 规划出 4 个子任务：① 检索武汉市 2024 年专精特新政策文件并提取三要素；② 检索杭州市 2024 年对应政策并提取三要素；③ 交叉比对两地政策的共性与差异；④ 生成结构化对比表格与总结简报。
    2. 工具调用（Act）：
    • Step 1 调用 rag_search_tool，传入参数 { city: "武汉", year: 2024, keyword: "专精特新 中小企业 扶持 补贴", domain: "public" }；
    • Step 2 再次调用 rag_search_tool，传入杭州市参数检索；
    • Step 3 调用 data_compare_tool 对两组结构化数据进行维度矩阵对齐。
      3. 状态机与进度同步：后端状态机实时推进，通过 SSE 向小程序端实时推送步骤卡片：“[1/3 正在检索武汉政策…] -> [2/3 正在检索杭州政策…] -> [3/3 正在对比差异…]”。
      4. 最终交付：输出一份包含两地政策名称、发文字号、资金梯度对比表、用地政策差异点及精准引用来源的完整政务简报，并支持 Web 端一键导出为 Word/PDF。

Q8: 政务系统对数据安全和合规性要求极高，如果客户提出“文档绝对不能出内网”或“科室间物理隔离”，系统在架构上如何满足？

回答（求职者口吻）：
我们在架构设计之初就充分考虑了政务信创与内网私有化部署要求：

  1. 纯内网全栈私有化部署：
    - RAGFlow 底座、Embedding 模型服务、开源大模型（如 Qwen-72B/DeepSeek 私有化量化版）、MySQL、Redis、MinIO 对象存储全部容器化部署在政务内网物理机或政务云私有 VPC 中，全程不依赖任何公网外网 API，实现数据不出局。
  2. 多租户与组织科室物理/逻辑隔离：
    - 租户隔离：不同局委办分配独立的 Tenant ID，底层 MinIO 存储桶物理隔离，MySQL 按租户分表或租户字段硬过滤。
    - 知识库物理分库：在 RAGFlow 中，为保密级别高的科室创建独立的知识库实体（Dataset），不与其他部门共享向量索引文件。
  3. 脱敏与全链路审计：
    - 文档入库时自动对身份证号、手机号、涉密人名做正则脱敏；所有问答、检索、Agent 调用均完整记录操作人 IP、时间、Query、命中 Chunk ID 及完整响应，保留 180 天以上供网信与合规部门审计溯源。

Q9: 微信小程序端与 Web 管理端各自承载的业务生命周期是怎样的？两者如何协同？

回答（求职者口吻）：
微信小程序和 Web 管理端在业务上形成了“运营生产端”与“消费应用端”的完整闭环：

  • Web 管理端（知识与安全运营中心）：
  • 知识入库与生命周期管理：文档上传、OCR 识别确认、分块微调预览、元数据打标（发文日期/时效/密级）、知识库发布与下架。
  • Agent 工具与权限配置：配置可用工具白名单、为不同部门分配知识域权限、查看任务状态机运行明细。
  • 运营大屏与审计：监控高频热搜政策词、问答不满意率、失败降级日志、用户敏感词拦截记录。
  • 微信小程序端（高效触达与交互端）：
  • 日常政策问答：多轮对话、流式输出、引用卡片点击展开原文、会话历史管理。
  • 任务 Agent 发起与跟踪：发起政策对比与汇总长任务，实时查看步骤进度条，获取结构化简报并分享。
  • 协同机制：
  • 两端共享同一套 Go 后端 RESTful/SSE API 与统一认证鉴权中心；Web 端更新或发布的知识库，通过 Redis 缓存失效机制秒级同步至小程序检索端。

Q10: 整个项目推进过程中，你遇到了哪些非纯技术的挑战？是如何跨团队协同解决的？

回答（求职者口吻）：
在政务 AI 项目中，最大的非技术挑战通常来自“业务方对大模型能力的预期偏差”与“政务知识源数据的混乱非标”：

  1. 管理客户预期，明确 AI 边界：
    - 业务方初期往往认为大模型是“无所不能的超级大脑”，遇到模型回答与某位领导口头指示不一致时就质疑系统。我主动与业务负责人沟通，明确“RAG 系统是严格基于已发布公文的忠实索引者”，并在产品界面上强化“引用来源与依据原文展示”，让客户直观看到“每一句话背后都有红头文件支撑”，把预期从“自由创作”引导到“严肃依据核验”。
  2. 制定知识文档入库规范：
    - 客户提供的原始文档存在大量扫描件倾斜、Word 格式错乱、废止政策未标明等问题。我推动制定了《政务知识库文档入库标准白皮书》，明确了文档命名规范、版本号与时效标注要求，并协同客户方的业务骨干分批次对历史文档进行梳理与清洗，确保“入库数据本身的高质量”，从而奠定了模型高准确率的基石。