简介这份资源面向法律科技方向的学习者与开发者提供一套以知识图谱为核心的法务智能问答完整方案适合具备一定自然语言处理与机器学习基础、希望切入法律垂直领域的中高级读者。包内围绕案由知识库、法务资讯对话知识库与基础法律知识图谱展开覆盖案由预测模型、法务问题类型分类、法务问题自动问答服务以及基于图谱的知识查询四大任务模块并附有可运行的源码实现便于读者对照复现与二次开发。压缩包整体约33.88MB文件总数与类型明细上游暂未提供但内容以代码与数据资源为主结构围绕数据构建、模型训练与问答服务分层组织。目前已有675人学习下载可作为法律智能问答方向的入门到进阶参考帮助读者理解从数据采集、图谱构建到问答落地的完整链路并掌握案由预测与问题分类等典型任务的实现思路。1. 法务智能知识图谱20W问答数据落地的真实门槛在哪很多团队第一次做法务问答直觉是“拿个大模型套个法律语料微调一下就行”。真跑起来才发现用户问“公司拖欠工资三个月我能不能直接解除合同并要赔偿”模型要么答得笼统要么把劳动法和合同法条款串在一起引用条文编号还是错的。问题不在模型大小在于法务领域对“依据可追溯”的要求远高于通用问答——答案必须能落到具体法条、司法解释或裁判观点上否则没人敢用。法务智能知识图谱要解决的就是这件事把 20W 量级的法务问答对和法律资讯组织成“问题—法条—概念—裁判要点”互相咬合的图结构让检索和生成都有据可依。它适合两类人一是想给现有问答系统加一层可解释依据的工程团队二是手里有法务语料、想验证知识图谱到底值不值得投入的从业者。下面按“图怎么建、问答怎么接、坑在哪”的顺序拆开讲。2. 从 20W 问答到知识图谱实体抽取与关系设计的落地路径2.1 为什么不能直接把问答对塞进向量库向量检索能解决“语义相似”但解决不了“依据链”。用户问“试用期被辞退有没有补偿”向量库可能召回一堆语义相近但结论相反的问答——有的说“试用期辞退无补偿”有的说“违法辞退要赔”。这两条在向量空间里距离很近但适用条件完全不同。知识图谱的价值在于把“适用条件”显式建模成节点和边试用期、辞退理由、是否违法、补偿标准每个维度都是图上的一个约束。常见做法是三层结构最底层是法条和司法解释原文节点中间层是法律概念如“违法解除”“经济补偿金”最上层是问答对和资讯。问答对不直接连法条而是通过概念节点中转。这样一条问答可以挂多个概念一个概念可以关联多条法条检索时先定位概念再拉法条依据链就出来了。2.2 实体抽取用规则兜底用模型提召回法务文本的实体类型比通用领域窄主要是法条引用《劳动合同法》第 39 条、法律概念竞业限制、不可抗力、主体用人单位、劳动者、金额与期限。纯靠模型抽法条编号这种强格式实体反而容易错纯靠正则概念类实体召回不够。我一般用“正则 词典 模型”三路合并import re from typing import List, Dict # 第一路法条引用正则覆盖《XX法》第X条、第X款 LAW_PATTERN re.compile( r《([^》])》第([一二三四五六七八九十百零\d])条 r(?:第([一二三四五六七八九十\d])款)? ) def extract_law_refs(text: str) - List[Dict]: 抽取法条引用返回结构化结果 results [] for m in LAW_PATTERN.finditer(text): results.append({ law_name: m.group(1), # 法律名称 article: m.group(2), # 条号 paragraph: m.group(3), # 款号可能为空 span: m.span() # 原文位置用于回溯 }) return results # 第二路概念词典匹配词典从法条标题和司法解释小标题里抽 CONCEPT_DICT [竞业限制, 经济补偿金, 违法解除, 不可抗力, 诉讼时效] def extract_concepts(text: str) - List[str]: return [c for c in CONCEPT_DICT if c in text]这段代码的关键在span字段——法务场景必须保留原文位置后面做依据展示时要高亮回原文。LAW_PATTERN里条号用了中文数字和阿拉伯数字两套因为实际语料里两种写法混用。概念词典不建议手工维护从法条标题和司法解释小标题里批量抽更稳。第三路模型抽取用轻量 NER 即可不需要大模型。把正则和词典的结果作为特征拼进去模型只负责补漏。三路合并时按span去重重叠的以正则结果优先因为法条编号正则的准确率远高于模型。2.3 关系设计别把图建成一棵树新手容易把知识图谱建成树法条是父节点概念是子节点问答是叶子。这样查询“同时涉及竞业限制和经济补偿金的问题”就要跨树遍历效率低且容易漏。正确做法是概念之间也建边比如“竞业限制”和“经济补偿金”在劳动合同解除场景下经常共现就加一条co_occur边权重用共现频次归一化。关系类型控制在 6 到 8 种就够references问答引用法条、defines法条定义概念、co_occur概念共现、supersedes新法条替代旧法条、related资讯关联问答。supersedes这条边很多人会漏但法务领域时效性极强旧法条没标记替代关系检索时会把已废止的条文推给用户这是血泪教训。2.4 入库与索引Neo4j 的写入参数怎么调图数据库选 Neo4j 是常见方案20W 问答加关联法条节点量大概在百万级。批量写入时UNWIND比逐条CREATE快一个数量级但要注意事务大小// 批量写入问答节点每批 5000 条 UNWIND $batch AS row MERGE (q:Question {qid: row.qid}) SET q.text row.text, q.category row.category WITH q, row UNWIND row.law_refs AS ref MERGE (l:Law {law_name: ref.law_name, article: ref.article}) MERGE (q)-[:REFERENCES {paragraph: ref.paragraph}]-(l)MERGE而不是CREATE是为了幂等重跑不会产生重复节点。每批 5000 条是实测比较稳的值再大事务日志压力明显再小写入次数太多。REFERENCES边上带paragraph属性因为同一条问答可能引用同一条法的不同款边上不带属性会丢信息。提示Neo4j 社区版对节点数没硬限制但内存配置要跟上。百万级节点建议堆内存不低于 8G页缓存不低于 4G否则查询会频繁走磁盘。3. 法律资讯问答怎么接检索增强与图谱查询的配合3.1 资讯和问答的区别时效性权重不一样法务问答对相对稳定一条“试用期辞退补偿”的问答可能几年不变。法律资讯时效性强新司法解释出台后旧资讯的参考价值骤降。所以资讯节点要带publish_date和effective_date两个时间属性检索时按时间衰减加权。常见做法是资讯得分乘以一个衰减因子半衰期设 180 天左右具体看领域更新频率。图谱查询和向量检索要配合用不能只靠一个。用户问“最新竞业限制补偿标准”图谱先定位“竞业限制”概念节点拉出关联法条和近期资讯向量检索再在候选集里做语义精排。反过来用户问一个模糊问题向量检索先召回一批问答再从问答节点沿REFERENCES边拉法条做依据展示。两条路径的入口不同但最终都落到图上。3.2 图谱查询从问题到法条的完整链路一条典型的图谱查询链路是这样的用户输入问题 → 实体识别抽出概念和法条引用 → 图谱查询拉出关联法条和问答 → 按权重排序 → 生成答案时把法条原文作为依据附上。def query_knowledge_graph(driver, question: str, top_k: int 5): 从问题出发查询图谱返回问答和法条依据 concepts extract_concepts(question) law_refs extract_law_refs(question) # 概念节点匹配同时拉出关联问答和法条 cypher MATCH (c:Concept) WHERE c.name IN $concepts OPTIONAL MATCH (c)-[:DEFINES]-(l:Law) OPTIONAL MATCH (q:Question)-[:REFERENCES]-(l) RETURN c.name AS concept, collect(DISTINCT l) AS laws, collect(DISTINCT q) AS questions with driver.session() as session: result session.run(cypher, conceptsconcepts) return result.data()OPTIONAL MATCH是必须的因为有些概念节点可能还没关联法条用MATCH会直接过滤掉。collect(DISTINCT ...)去重是因为一个概念可能被多条法条定义一条法条可能被多条问答引用不去重结果会膨胀。返回的laws和questions在应用层再做排序和截断。3.3 检索增强生成法条原文怎么拼进 prompt图谱查出来的法条原文不能直接丢给大模型要先做截断和格式化。法条动辄几百字全拼进去 token 消耗大且容易稀释重点。我一般只拼与问题最相关的条款每条法条截取前 200 字并标注来源。def build_prompt(question: str, laws: list, qa_pairs: list) - str: 拼装 RAG prompt法条和问答分开标注 law_text \n.join( f[{l[law_name]}第{l[article]}条] {l[content][:200]} for l in laws[:3] ) qa_text \n.join( f问{q[text]}\n答{q[answer][:150]} for q in qa_pairs[:3] ) return f基于以下法条和参考问答回答问题。 法条依据 {law_text} 参考问答 {qa_text} 问题{question} 回答时请注明引用的法条编号。法条截断到 200 字、问答截断到 150 字是经验值再长对生成质量提升有限反而增加幻觉风险。prompt 里明确要求“注明引用的法条编号”这样生成结果可以回溯校验发现编号对不上就能拦截。3.4 效果验证怎么判断图谱有没有起作用验证分两层检索层看召回率和依据准确率生成层看答案是否引用了正确法条。检索层可以人工标注 200 条测试问题看图谱路径召回的问答里有多少是真正相关的。生成层更直接把生成答案里的法条编号抽出来和图谱里实际关联的法条比对编号对不上的比例超过 10% 就要查原因。常见原因是概念节点没对齐——用户问“辞退补偿”图谱里概念叫“经济补偿金”实体识别没匹配上。解决办法是给概念节点加同义词属性查询时同义词一起匹配。这个坑很隐蔽因为向量检索能兜住一部分但图谱路径就断了。4. 避坑与排查法务知识图谱落地时最容易翻车的 5 个点4.1 法条更新后图谱没同步检索出已废止条文现象用户问“民法典实施后合同法还有效吗”系统推了《合同法》第 X 条作为依据。原因图谱里旧法条节点没标记supersedes关系检索时按权重排序旧法条反而靠前。解决建图谱时就加supersedes边新法条指向被替代的旧法条检索时过滤掉有入边supersedes的节点或者给旧法条降权。4.2 概念节点粒度太粗一条问答挂了几十个概念现象图谱查询返回的问答列表里很多问答只沾一点边相关性差。原因实体抽取时概念词典太宽泛比如“合同”这种词到处出现导致一条问答挂了几十个概念节点。解决概念词典只保留有区分度的法律术语通用词合同、责任、义务不进图谱或者进图谱但设更高的匹配阈值。4.3 批量写入时事务太大Neo4j 直接 OOM现象20W 问答一次性UNWIND写入跑到一半 Neo4j 报内存不足。原因单事务节点和边太多事务状态全在内存里。解决分批写入每批 3000 到 5000 条批间加短暂 sleep 让事务日志落盘。同时调大堆内存和页缓存但根本办法还是分批。4.4 问答对里的答案本身有错图谱把错误放大了现象图谱检索出的问答答案引用了错误法条生成结果跟着错。原因原始 20W 问答对里混入了低质量数据没做清洗直接入库。解决入库前跑一遍法条引用校验答案里提到的法条编号和实际关联的法条对不上就标记待审核。宁可少入库不要脏入库。4.5 图谱查询和向量检索权重没调好两边打架现象图谱查出的高相关问答被向量检索的低相关结果挤掉。原因两路结果合并时权重是拍脑袋定的没做归一化。解决图谱得分和向量得分各自归一化到 0 到 1再按业务调权重。法务场景建议图谱权重不低于 0.6因为依据准确性比语义相似更重要。5. 进阶技巧用图谱做答案依据校验与增量更新图谱建好之后最大的价值其实不是检索而是校验。生成模型给出的答案把里面的法条编号抽出来去图谱里查这条法条是否真的关联了当前问题涉及的概念。如果没关联说明模型在编造依据直接拦截。这个校验逻辑比人工审核快得多也比纯规则校验准。def validate_answer(answer: str, question: str, driver) - bool: 校验生成答案里的法条引用是否在图谱中有依据 refs extract_law_refs(answer) if not refs: return False # 没引用法条法务场景直接不通过 concepts extract_concepts(question) with driver.session() as session: for ref in refs: cypher MATCH (l:Law {law_name: $law, article: $article}) MATCH (c:Concept)-[:DEFINES]-(l) WHERE c.name IN $concepts RETURN count(c) AS cnt result session.run( cypher, lawref[law_name], articleref[article], conceptsconcepts ) if result.single()[cnt] 0: return False # 法条和问题概念无关联判定为幻觉 return True这个校验函数的关键在DEFINES边——法条定义概念概念关联问题。如果答案引用的法条没有定义问题涉及的概念说明引用是硬凑的。实际跑下来能拦掉大部分法条编号编造的情况。增量更新是另一个进阶点。新法条出台后不需要重建整个图谱只需要插入新法条节点、建supersedes边、更新概念关联。增量更新的难点在概念对齐——新法条可能引入新概念需要判断是新建概念节点还是挂到已有概念上。我一般先跑一遍新法条的概念抽取和已有概念做字符串相似度匹配相似度高于 0.85 的挂到已有节点低于的建新节点并标记待人工确认。最后说个习惯每次图谱更新后我会抽 50 条测试问题跑一遍回归看检索结果里旧法条的比例有没有上升。这个习惯帮我拦过好几次更新引入的回归问题。法务知识图谱不是建完就完事它更像一个需要持续维护的索引更新和校验的功夫花得值。希望帮到你。本文还有配套的精品资源点击获取