4. 法律关系抽取：从模板到大模型，一场技术演进之旅
法律关系抽取，说白了就是让机器看懂法律文本里谁和谁有什么关系。比如“张三起诉李四”，机器得知道“张三”是原告，“李四”是被告，关系是“诉讼”。
我做了这么多年法律知识图谱，最深的感触是：关系抽取是整个图谱的骨架。实体是节点，关系才是真正的灵魂。没有准确的关系，图谱就是一堆散落的珠子。
4.1 基于模板的关系抽取：老手艺人的看家本领
模板匹配，是最朴素的方法。你定义好一些固定的句式，让程序去文本里找。
举个例子，法律文书里经常出现：
“原告XXX诉被告XXX”
“XXX与XXX签订《合同》”
“XXX向XXX借款XXX元”
我们可以写成正则表达式：
原告(.*?)诉被告(.*?) → 关系：诉讼
(.*?)与(.*?)签订 → 关系：合同关系
(.*?)向(.*?)借款 → 关系：借贷关系
优点：准确率高，几乎没有误报。适合结构化强的法律文书。
缺点：覆盖范围有限。法律文本千变万化，模板写不完。
我曾经在一个项目中，光“合同纠纷”相关的模板就写了200多个。你以为够全了？结果新来一批判决书，又冒出十几种新写法。嗯，这就是模板方法的宿命。
我的经验：模板方法适合做“种子数据”。先用模板抽出一批高置信度的关系，作为后续模型的训练数据。别指望它覆盖所有场景。
4.2 基于远程监督的关系抽取：用知识库给数据打标签
远程监督的思路很巧妙：假设你有一个知识库，里面存着已知的实体对和关系。比如知识库里说“张三”和“李四”是“借贷关系”。那么，任何同时包含“张三”和“李四”的句子，都自动标记为“借贷关系”。
这样做的好处是——不用人工标注，成本极低。但问题也很明显：
- 噪声大：句子可能说的是“张三和李四一起吃饭”，跟借贷没关系，但也被强行打上标签。
- 多义性：同一对实体在不同句子中关系可能不同。
我见过一个项目，用远程监督抽了100万条关系，结果人工抽检发现准确率不到40%。为什么？因为知识库里的“张三”和“李四”是借贷关系，但文本里他们可能在聊天气。
避坑指南：远程监督必须配合去噪策略。我常用的方法有：
- 多实例学习：一个实体对取多个句子，用注意力机制选出最相关的那个
- 置信度阈值：只保留模型预测概率高于0.8的结果
- 人工抽检闭环：定期抽检，把错误样本反馈回去重新训练
4.3 基于大模型的关系抽取：Few-shot / Zero-shot 的降维打击
大模型来了之后，关系抽取这件事变得简单了很多。你想想看，以前我们要为每种关系类型准备几千条标注数据，现在呢？
Zero-shot：直接告诉模型“帮我找出句子里的法律关系，类型包括：诉讼、借贷、担保、合同...”，模型就能干活。不需要任何训练数据。
Few-shot：给模型看3-5个例子，它就能举一反三。
我最近在做一个项目，需要抽取“股权质押”关系。传统方法至少要标注2000条数据，训练一个BERT模型。用大模型呢？我写了5个示例，调了一下prompt，半小时就搞定了。
来看看prompt怎么写：
你是一个法律关系抽取专家。
请从以下句子中抽取法律关系。
关系类型包括：[诉讼、借贷、担保、合同、股权质押]
示例1：
句子：张三向李四借款100万元。
输出：{"subject": "张三", "object": "李四", "relation": "借贷"}
示例2：
句子：王五将其持有的甲公司10%股权质押给银行。
输出：{"subject": "王五", "object": "银行", "relation": "股权质押"}
现在请抽取：
句子：赵六为钱七的借款提供连带责任保证。
输出：
大模型输出：
{"subject": "赵六", "object": "钱七", "relation": "担保"}
你看，一次就对了。这就是大模型的魅力。
但要注意：大模型不是万能的。我测试过，在非常冷门的法律领域（比如海事海商），大模型的Zero-shot效果会明显下降。这时候Few-shot就派上用场了，给几个高质量示例，效果立竿见影。
4.4 关系融合与冲突解决：多源数据怎么拧成一股绳
实际项目中，我们往往同时使用多种方法：模板抽一批、远程监督抽一批、大模型再抽一批。问题来了——同一个实体对，不同方法抽出的关系可能不一样。
比如：
| 方法 | 抽取结果 |
|---|---|
| 模板 | 张三 → 李四：借贷 |
| 远程监督 | 张三 → 李四：担保 |
| 大模型 | 张三 → 李四：借贷 |
怎么解决？我一般用三层策略：
- 置信度优先：给每种方法设定置信度权重。模板方法准确率高，权重给0.8；远程监督噪声大，权重给0.4；大模型看情况，一般给0.6。投票时加权求和。
- 时间维度：同一个实体对在不同时间点可能有不同关系。比如张三先向李四借款，后来李四又为张三担保。这时候要保留多条关系，而不是合并。
- 人工兜底：对于置信度接近、无法自动判断的冲突，我会设计一个“争议池”，定期人工审核。
我个人的习惯：关系融合不是简单的“谁对谁错”，而是要考虑业务场景。如果是做司法大数据分析，宁可多保留几条关系，也别漏掉。如果是做智能问答，那就要严格去重，保证答案唯一。
知识体系总览
下面这张图，是我梳理的法律关系抽取整体架构。你可以看到，从底层数据到上层应用，每一层都有对应的技术选型。
这张图里，我特意把“业务场景适配”放在了融合层。为什么？因为很多团队只关注技术，忽略了业务需求。你想想看，做司法统计和做智能问答，对关系质量的要求能一样吗？前者可以容忍一些噪声，后者必须精确到每个实体对。
好了，这一章的内容就到这里。关系抽取是个系统工程，没有银弹。模板、远程监督、大模型，各有各的用武之地。关键是要根据你的数据特点、业务需求、成本预算，找到最适合的组合方案。
公众号:蓝海资料掘金营，微信deep3321