法律数据采集与预处理：从原始文书到结构化知识
大家好，我是你们这堂课的主讲人。今天咱们聊聊法律数据采集与预处理。说实话，这是整个法律知识图谱项目里最「脏」最累的活，但也是决定成败的一步。我见过太多团队，模型选得再好，算法调得再妙，最后因为数据质量太差，项目直接翻车。嗯，咱们先把这个地基打牢。
核心观点：法律知识图谱的质量，80%取决于数据预处理。别急着上模型，先把数据洗干净。
1. 法律文书的主要来源
法律数据从哪来？我个人习惯把它们分成三类：
- 公开裁判文书网：中国裁判文书网、北大法宝、无讼等。这是最主流的来源，但要注意——这些网站的反爬机制越来越严了。
- 法律法规数据库：全国人大法规库、司法部规章库。这类数据相对规整，但更新频率不一。
- 企业内部数据：律所的案件卷宗、企业的合同库。这类数据最值钱，但获取难度也最大。
我在项目中遇到过最头疼的情况：某地方法院的文书网站，每天只开放500次查询，而且每次查询后要等30秒。你想想看，要爬100万份文书，得等到猴年马月？
2. 爬虫与API获取：技术选型与避坑
获取数据，说白了就两条路：爬虫或者API。我建议优先走API，实在不行再上爬虫。
2.1 API获取
现在很多法律数据平台都开放了API接口。比如中国裁判文书网的官方API，虽然有限流，但胜在稳定。我一般这样写：
import requests
import json
def fetch_judgment(case_id, api_key):
url = f"https://api.court.gov.cn/judgment/{case_id}"
headers = {"Authorization": f"Bearer {api_key}"}
response = requests.get(url, headers=headers)
if response.status_code == 200:
return response.json()
else:
print(f"请求失败，状态码：{response.status_code}")
return None小技巧：API调用一定要加重试机制。我曾经因为网络抖动，一个批次的数据丢了30%。后来加了指数退避重试，再没出过问题。
2.2 爬虫获取
当API拿不到数据时，就得靠爬虫了。但这里有个大坑——法律网站的反爬手段五花八门。我总结了几种常见情况：
| 反爬手段 | 应对策略 | 注意事项 |
|---|---|---|
| IP封禁 | 使用代理池，轮换IP | 别用免费代理，容易被反杀 |
| 验证码 | 接入打码平台或OCR识别 | 验证码识别准确率只有80%左右 |
| 动态加载 | 使用Selenium模拟浏览器 | 速度慢，资源消耗大 |
| 请求频率限制 | 设置随机延时，模拟人类行为 | 延时建议在1-3秒之间 |
我曾经因为没处理好IP封禁，整个爬虫集群被拉黑了三天。嗯，从那以后我学乖了——每次爬取前先做个小范围的「侦察」，看看对方的反爬策略是什么。
3. 数据清洗：去重与纠错
数据拿到手了，但别高兴太早。法律文书里的「脏数据」多得超乎你想象。我见过同一份判决书在三个网站上有三个版本，也见过把「被告」写成「被吿」的奇葩错误。
3.1 去重
去重不是简单的字符串比较。法律文书有大量相似但不同的内容，比如同一案件的一审和二审判决书。我一般用两步走：
- 精确去重：基于文书ID或MD5哈希值，去掉完全重复的。
- 模糊去重：用SimHash或MinHash算法，计算文本相似度，去掉相似度超过95%的。
from simhash import Simhash
def deduplicate(documents, threshold=0.95):
unique_docs = []
seen_hashes = []
for doc in documents:
doc_hash = Simhash(doc['content'])
is_duplicate = False
for seen_hash in seen_hashes:
similarity = doc_hash.distance(seen_hash)
if similarity < threshold:
is_duplicate = True
break
if not is_duplicate:
unique_docs.append(doc)
seen_hashes.append(doc_hash)
return unique_docs注意：模糊去重的阈值要调好。设得太低，会误删重要文书；设得太高，又去不掉重复。我一般先用小样本测试，找到最佳阈值。
3.2 纠错
法律文书的错误类型很多，我归纳了一下：
- 错别字：比如「辩护人」写成「辨护人」
- 格式错误：日期格式不统一，比如「2023年1月1日」和「2023-01-01」混用
- 实体错误：当事人姓名、案号等关键信息写错
我的做法是：先建一个法律领域专用的纠错词典，然后用正则表达式做格式标准化。对于实体错误，我会用命名实体识别（NER）模型做校验。比如，如果模型识别出一个「人名」但词典里查不到，就标记为可疑。
4. 结构化与非结构化数据处理
法律数据有两种形态：结构化的（比如表格数据）和非结构化的（比如判决书全文）。处理方式完全不同。
4.1 结构化数据
这类数据相对好处理。比如法院的案件信息表，字段清晰，直接入库就行。但要注意字段映射——不同来源的字段名可能不一样。我习惯建一个映射表：
field_mapping = {
"案号": "case_id",
"当事人": "party_name",
"案由": "case_reason",
"审判日期": "judgment_date",
"审判法院": "court_name"
}4.2 非结构化数据
这才是大头。一份判决书可能包含案情描述、证据列表、法律依据、判决结果等多个部分。我的做法是：先用规则做段落分割，再用序列标注模型做信息抽取。
举个例子，提取判决结果：
import re
def extract_judgment_result(text):
# 常见的判决结果关键词
patterns = [
r"判决如下[：:](.*?)(?:本判决|如不服本判决)",
r"依照.*?判决如下[：:](.*?)(?:$|本判决)",
]
for pattern in patterns:
match = re.search(pattern, text, re.DOTALL)
if match:
return match.group(1).strip()
return None经验之谈：规则方法虽然「笨」，但在法律领域特别管用。因为法律文书的格式相对固定，规则能覆盖80%以上的情况。剩下的20%，再用模型去兜底。
5. 知识体系总览
说了这么多，咱们用一张图把整个流程串起来。这是我做项目时画的框架图，每次开工前都会看一眼：
这张图把整个流程串起来了。从数据源开始，经过获取、清洗、处理，最后到知识图谱构建。每一步都有坑，但每一步也都有解法。
好了，这一章的内容就到这儿。数据采集和预处理是基础中的基础，别嫌麻烦。下一章咱们会深入讲知识抽取，到时候这些预处理好的数据就能派上大用场了。
公众号:蓝海资料掘金营，微信deep3321