📚 课程目录第4章金融法规数据获取

4. 金融法规数据获取

在金融法规RAG系统中，数据获取不是“把网页抓下来”这么简单。法规文本具有强时效性、多版本并存、发布主体分散、格式高度不统一等特点。如果数据层没有做好来源管理、采集控制、清洗规范与版本追踪，后续的向量化、检索和合规问答都会建立在不可靠的基础上。本节围绕“从哪里来、怎么采、怎么洗、怎么管版本”四个环节展开。

一、核心原理：法规数据的四个特殊属性

金融法规数据与普通网页语料最大的区别在于：权威性、时效性、版本性、结构性。权威性要求来源必须是官方发布渠道；时效性要求能识别“现行有效、已修订、已废止”等状态；版本性要求同一法规的多个修订版本可追溯、可对比；结构性要求把标题、章节、条款、附件、发文号等字段拆解出来，而不是整篇纯文本。

关键判断：RAG检索的答案质量，上限由数据层决定。法规数据如果混入失效版本或非官方解读，模型会“自信地引用错误依据”，这比检索不到更危险。

二、法规数据来源：分层采集策略

建议将来源分为三层，按权威性和采集难度分别处理：

第一层：官方权威源。如中国人民银行、国家金融监督管理总局、证监会、外汇局、沪深交易所、中国证券业协会等官网的“法律法规/规章/规范性文件”栏目。这是合规问答的最终依据。
第二层：聚合与标准源。如国家法律法规数据库、地方政府数据开放平台、北大法宝/威科先行等商业数据库（需授权）。适合做交叉校验和补全。
第三层：辅助解释源。官方答记者问、政策解读、监管处罚案例。可用于增强问答上下文，但必须与法规正文严格区分标签，避免模型混淆“法条”与“解读”。

三、爬虫与API采集：可控、可审计、可重放

采集层要解决三个问题：发现新法规、抓取正文与附件、记录采集元数据。对无API的官网，使用爬虫；对有开放接口或RSS的站点，优先走API。无论哪种方式，都要保留source_url、fetch_time、http_status、content_hash等字段，保证可审计与可重放。

# 采集任务配置示例（YAML）
source:
  name: "监管总局-规章"
  base_url: "https://www.example.gov.cn"
  list_selector: "ul.rule-list li a"
  detail_selector: "div.article-content"
  encoding: "utf-8"
  rate_limit: 1.5          # 每秒请求数
  retry: 3
  headers:
    User-Agent: "ComplianceRAG-Bot/1.0"
    Accept-Language: "zh-CN,zh;q=0.9"
storage:
  raw_dir: "data/raw/regulator"
  meta_file: "data/meta/fetch_log.jsonl"

采集时需注意：遵守robots协议与网站条款，控制频率，避免对目标站点造成压力；对PDF附件单独走解析管道；对分页列表做增量判断，优先按“发布日期+发文号”去重，而不是仅按URL。

四、数据清洗：从网页噪声到结构化条款

清洗的目标是产出可检索、可引用、可定位的条款级数据。典型流程如下：

正文抽取：去除导航、页脚、广告、相关推荐等噪声，保留标题、发文号、发布日期、正文、附件。
格式归一：统一全角/半角、去除多余空白与软换行、修复PDF断行导致的词语断裂。
条款切分：按“第X条”“第X章”“（一）（二）”等层级切分为条款块，并保留父级路径。
字段补全：抽取发文机关、文号、效力状态、生效日期、失效日期、修订记录。
质量校验：检查条款是否为空、标题是否缺失、日期是否合法、正文长度是否异常。

实践建议：条款切分不要只按正则“第.*条”。金融法规中常出现“第X条之一”“第X条第二款”“附则”等变体，建议用“层级解析器+人工抽检”结合，先保证切分边界正确，再谈向量化。

五、去重与版本管理：同一法规的多版本共存

去重要区分两类：完全重复（同一页面被多次抓取）和版本重复（同一法规的修订版）。前者用内容哈希即可；后者必须保留，因为合规问答可能需要回答“修订前后差异”。

维度	完全重复	版本重复
识别方式	content_hash 相同	法规ID相同，版本号/发布日期不同
处理策略	保留最新抓取记录，旧记录归档	全部保留，标记效力状态与生效区间
检索影响	避免同一内容多次召回	默认只召回“现行有效”版本，历史版本按需召回
元数据重点	fetch_time、source_url	version、effective_date、status、supersedes

版本管理建议采用“法规主表+版本子表”的结构：主表存法规唯一标识与当前状态，子表存每个版本的正文、发布日期、生效日期、修订说明。检索时通过status=effective过滤，必要时再开放历史版本。

# 版本记录示例（JSONL）
{"law_id":"LAW-2024-001","version":"2024-06","status":"effective",
 "publish_date":"2024-06-01","effective_date":"2024-07-01",
 "supersedes":"2023-12","content_hash":"a1b2c3..."}
{"law_id":"LAW-2024-001","version":"2023-12","status":"superseded",
 "publish_date":"2023-12-15","effective_date":"2024-01-01",
 "supersedes":null,"content_hash":"d4e5f6..."}

六、案例场景：一次“失效法规误召回”的复盘

某合规问答系统上线后，用户询问“某业务是否需要事前审批”，模型引用了一条已被修订的旧条款，给出了过时结论。复盘发现：采集时旧版本和新版本都被抓取，但清洗阶段未标记效力状态，向量库中两个版本同时参与检索，且旧版本语义更接近问题，导致误召回。

修复方案包括：在元数据中强制增加status与effective_date字段；检索前按当前日期过滤失效版本；对“修订前后差异”类问题单独走版本对比检索通道；在答案中附带法规版本与生效日期，提示用户核对。

常见误区：只做文本去重，不做版本治理；只存正文，不存发文号与生效日期；把政策解读当法条入库；采集不做增量，重复抓取导致元数据混乱。这些问题在RAG中会直接表现为“答非所问”或“引用失效依据”。

综上，金融法规数据获取的核心不是“抓得多”，而是“抓得准、洗得净、管得住版本”。只有把来源分层、采集留痕、清洗结构化、去重与版本治理做到位，RAG系统才能在合规问答中给出可追溯、可验证、可更新的答案。