智叟云集政策监测技术方案——原文解析、证据提取与可核验摘要

智叟云集政策监测技术方案------原文解析、证据提取与可核验摘要

一、政策监测不只是收集文章

智叟云集系统政策监测模块可以在现有来源、任务和报告能力上扩展，用于持续发现与客户地区、行业和业务有关的信息。

政策信息对准确性的要求较高。系统需要明确区分：

正式政策；
申报通知；
政策解读；
征求意见稿；
补充通知；
废止或调整公告。

标题相似不代表效力或适用范围相同。政策解读也不能自动代替正式文件。

因此，模块应把原文、结构化信息、摘要和核验状态分别保存。

试用地址

二、整体处理框架

复制代码

政策来源配置
      ↓
发现新文件与更新
      ↓
正文和附件解析
      ↓
文件类型识别
      ↓
机构 文号 时间 条件提取
      ↓
原文证据关联
      ↓
客户订阅匹配
      ↓
摘要与简报
      ↓
人工复核和通知

建议目录：

复制代码

src/modules/policies/
  collectors/        来源适配
  extractors/        HTML PDF 附件内容提取
  classifiers/       文件类型识别
  evidence/          字段证据
  summaries/         摘要生成
  reviews/           人工复核
  repositories/      数据访问

数据采集和摘要生成分开运行。一旦模型服务暂时不可用，原文仍然能够保存，后续可以继续处理，不必重新抓取。

三、第一步：保存原文与来源信息

每条政策记录需要保存：

信息	作用
原文标题	保持与来源一致
发布机构	判断信息来源
文号	辅助识别同一文件
原文地址	支持回溯
发布日期	反映文件发布时间
生效日期	与发布日期分开
申报时间	与政策生效时间分开
附件	保存申报表、细则等材料
内容版本	识别后续变化

同一政策被多个网站转载时，可以建立来源关联，但不能只凭相同标题就删除全部转载记录。原发布页面与转载页面的证据价值不同，应保留来源类型。

四、第二步：按文件类型解析内容

常见输入包括 HTML、文本 PDF、扫描 PDF 和 Word 附件。

处理方式应分别选择：

HTML：提取正文，去除导航和广告；
文本 PDF：提取文本及页码；
扫描文件：OCR 后保留识别质量信息；
表格附件：保留行列关系，不要只拼成连续文字。

页面或附件解析失败时，应标记为"解析失败"或"待处理"，不能生成一份内容不完整却看似确定的摘要。

对于金额、日期和条件表格，OCR 的识别误差尤其需要复核。

五、第三步：让每个关键字段带有原文依据

建议结构：

复制代码

{
  "field": "applicationDeadline",
  "value": null,
  "verificationStatus": "pending",
  "evidence": {
    "documentVersion": 1,
    "page": 3,
    "quote": "申报截止时间另行通知",
    "start": 128,
    "end": 139
  }
}

这里的字段值为空，是因为原文并没有给出明确日期。

偏移位置应对应一个固定版本的规范化文本，不能在原文变化后继续沿用旧坐标。

证据核验函数可以先确认引用是否真实存在：

复制代码

// evidence/verified-quote.mjs
export function verifiedQuote(text, evidence) {
  return (
    typeof evidence?.quote === "string" &&
    evidence.quote.length > 0 &&
    Number.isInteger(evidence.start) &&
    Number.isInteger(evidence.end) &&
    evidence.start >= 0 &&
    evidence.end <= text.length &&
    evidence.end > evidence.start &&
    text.slice(evidence.start, evidence.end) === evidence.quote
  );
}

需要强调：文本匹配只能确认引用位置，不能证明字段解释正确。

例如，原文同时包含"提交截止"和"评审日期"，即使引用都真实存在，也可能选错字段。因此还需要语义检查和人工复核。

六、第四步：约束摘要生成

摘要建议围绕固定栏目输出：

复制代码

政策主要内容
适用地区
适用对象
申报条件
所需材料
关键时间
原文依据
待核验事项

摘要生成时应遵循：

没有证据的金额、日期和条件不补写。
对"拟""原则上""另行通知"等限定词保留原意。
区分征求意见稿和正式发布文件。
不把关键词命中直接解释为客户符合条件。
对缺失字段显示"原文未明确"或"待核验"。

外部正文是待分析数据，不应被当作模型执行指令。如果文档中夹带"忽略此前要求"等文字，分析程序不应因此改变流程或调用内部工具。

建议模型只返回受限 JSON，并由后端校验字段、枚举值和证据。

七、第五步：实现复核与版本管理

可以使用以下处理状态：

复制代码

已发现
  ↓
已获取原文
  ↓
已解析
  ↓
待复核 / 已整理
  ↓
已加入简报

同时保存：

使用的模型版本；
提示词版本；
原文版本；
自动提取结果；
人工修改记录；
修改原因和处理人。

人工修改不应直接抹掉自动结果。保留两者，才能分析错误来源，并逐步改进规则。

政策原文更新后，需要检查旧摘要是否仍适用。涉及申报时间或条件变化时，旧摘要应标记为待重新核验。

八、前端页面怎么组织

政策监测页面建议包含：

区域	展示内容
筛选区	地区、政策领域、时间范围、文件类型
列表区	标题、机构、发布日期、核验状态
要点区	条件、材料、时间、匹配原因
证据区	原文片段、页码、附件
操作区	查看原文、提交复核、加入简报

一个合理的交互是：用户点击"申报截止时间"，能够看到对应原文，而不只是看到模型给出的日期。

这也方便客户发现问题后进行反馈。

九、如何验证政策摘要质量

建议建立人工标注的小型样本集，覆盖：

没有文号的通知；
多个日期并存；
扫描附件；
征求意见稿；
正式文件与转载；
条件分散在正文和附件；
原文后续更新。

逐项比较：

验证内容	方法
字段提取是否正确	与人工标注比较
摘要是否有依据	检查证据片段
缺失字段是否被编造	检查应为空的值
文档类型是否正确	检查正式文件与征求意见等分类
原文更新后是否重算	修改样本版本再执行
租户数据是否隔离	使用不同租户访问相同记录编号

本次验证代码已经检查"证据片段必须与原文一致"，但尚未验证真实政策文件的模型提取准确率。

政策监测的目标是帮助客户及时发现相关信息、理解原文要点和定位依据，而不是未经核验就替客户作出申报资格判断。