简介面向企业法务、合规管理及法律科技从业者这份850页的PDF文档围绕DeepSeek与知识图谱推理完整讲解企业运营全流程法律风险点识别和防控措施推荐方案。内容既涵盖法律实体识别与关系抽取、法律条文与案例结构化、知识图谱Schema设计、多源异构数据标准化、同义词库构建等基础环节也覆盖图谱存储选型、分布式查询优化、增量更新、实体链接、知识图谱补全以及DeepSeek推理引擎与规则/神经网络混合推理策略体系性很强。资源共1个PDF文件包体约15.65MB内置目录书签与快速定位支持方便按章节查阅。目前已有134人学习/浏览。文档总计850页、56个大章节前20章对上述模块的设计规范和实现方法展开细致说明既可作为法律知识图谱项目的方案参考也能帮助技术人员理解企业风险防控系统的完整技术链路。1. 企业法律风险智能诊断为什么绕不开知识图谱别被全流程三个字吓住这套方案想做的事其实可以压缩成一句话企业里每个合同、每笔交易、每场劳动争议背后都有一张关系网传统做法靠法务凭经验抽丝剥茧知识图谱把这套经验固化成可遍历的图结构再由 DeepSeek 在图上完成需要语义理解的那部分推理。于是识别风险点从关键词搜索变成多跳推理推荐防控措施从套模板变成背靠证据链生成。做过合同审查系统的人都有同感直接问大模型这份合同有没有风险得到的建议泛泛而谈很难落到诉讼或谈判里。原因是法律问题本质上是路径问题——供应商延期交货会不会触发对下游的违约责任取决于合同条款、催告记录、历史履约等多个节点必须形成一条闭合的证据链。知识图谱正是为这类多跳关系设计的载体。下面梳理的落地路径适合算法工程师、法务系统架构师与负责企业合规产品的技术负责人先按本体论构建图谱再让 DeepSeek 在图谱上做混合推理最后输出风险点、证据链和防控动作。2. 用 DeepSeek Neo4j 构建企业法律知识图谱的完整链路2.1 法律领域图谱的本体设计实体、关系与属性先立本体。企业运营法律风险的图模型并不复杂我常用的核心实体只有六类企业含子公司与关联方、自然人法人、股东、员工、合同、合同条款、法规、风险事件诉讼、保全、行政处罚。关系按业务场景设计而不是按法条设计否则图会无限膨胀查询和维护都会失控。关系方向典型属性业务含义HAS_CONTRACT企业→合同签署日期、金额、生效状态判断履约义务是否存在SIGN自然人→合同签署方式电子/纸质/代签电子签名效力审查入口APPLY_TO合同条款→合同条款类型违约/变更/解除快速定位争议条款BREACH合同→风险事件违约类型、时间、金额风险链路的起点HOLD_SHARE企业→企业持股比例、质押情况关联交易与股权穿透REFERENCE合同条款→法规引用条文编号判定条款合法性的直接跳板实体和关系定了之后属性越少越好。属性进入图谱会显著增加维护成本凡是能放进文档数据库的字段尽量不建图属性。举例合同文本全文放 Elasticsearch图谱里只存合同 ID、类型、金额、管辖地这四个用于检索和过滤的字段需要全文语义搜索时再回查 ES。关系上同理时间属性只在时间对推理有约束作用时才保留比如签署日期早于法规生效日这种场景。2.2 用 DeepSeek 从合同文本里抽取实体和关系知识图谱构建的日常工作负载在抽取环节。对于合同、判决书这类半结构化文本成熟的方案是让 DeepSeek 做零样本信息抽取输出统一 JSON再对 JSON 做校验后写库。DeepSeek 的对话接口兼容 OpenAI 的调用风格迁移成本很低。import json import re from openai import OpenAI # deepseek 提供 OpenAI 兼容的 API 端点 client OpenAI( api_keyYOUR_API_KEY, base_urlhttps://api.deepseek.com/v1 ) def extract_legal_knowledge(text: str) - tuple: schema { entities: [ {name: str, type: 企业|自然人|合同|条款|风险事件|法规} ], relations: [ { source: str, target: str, type: HAS_CONTRACT|BREACH|APPLY_TO|HOLD_SHARE, attrs: {date: YYYY-MM-DD, amount: float} } ] } # 限定输出形状避免模型自由发挥 prompt ( 你是企业法律信息抽取器。从给定文本中抽出合同当事人、合同条款、 涉及的法规、已发生或可能发生的风险事件以及彼此之间的关系。 只输出 JSONJSON 必须符合下面 schema\n f{json.dumps(schema, ensure_asciiFalse, indent2)} \n如果某条关系的时间或金额在原文里没有attrs 中可以省略该字段。\n 文本\n text[:12000] ) resp client.chat.completions.create( modeldeepseek-chat, # 或 deepseek-reasoner后者推理更强但更慢 messages[{role: user, content: prompt}], temperature0.1, # 信息抽取场景温度放低减少随机性 response_format{type: json_object} ) raw resp.choices[0].message.content # 粘贴代码可能被 markdown 包住做一次剥离 raw re.sub(r(?:json)?, , raw).strip() data json.loads(raw) return data[entities], data[relations]这段代码的关键参数temperature0.1控制随机性信息抽取宁可少答也不许编造所以只给 0.1 而非默认 1.0response_format强制返回合法 JSON避免在批量任务里反复做字符串解析deepseek-chat用于普通抽取deepseek-reasoner在面对责任划分、过错推定这类需要推导的文本时更好用代价是延迟明显上升建议只在清洗阶段用。抽取质量验证不能看单条样本。常见做法是抽 50 份合同把实体准确率、关系准确率分别统计关系准确率低于 85% 时优先修 schema 而不是改提示词。例如模型经常把甲方和公司A当两个实体本质上是缺了共指消解指令在 schema 里加一条aliases: []并要求实体去重后合并效果通常比写一大段所有角色都指向同一主体的提示词更稳定。2.3 Neo4j 写库与图查询的落库实践实体关系拿到后写库这一段没什么发挥空间但容易踩坑。我一般用 Cypher 的MERGE而不是CREATE这个关键字保证图里不产生重复节点。// 节点写入合同节点唯一的业务键用合同编号 MERGE (c:Contract {id: $contract_id}) ON CREATE SET c.type $contract_type, c.amount $amount, c.sign_date $sign_date; // 关系写入企业—签署—合同 MATCH (co:Company {id: $company_id}) MATCH (c:Contract {id: $contract_id}) MERGE (co)-[r:HAS_CONTRACT]-(c) SET r.sign_date $sign_date, r.legal_effective $legal_effective; // 批量导入建议用 UNWIND避免逐条网络往返 UNWIND $batch AS row MERGE (co:Company {id: row.company_id}) MERGE (con:Contract {id: row.contract_id}) MERGE (co)-[:HAS_CONTRACT]-(con) ON CREATE SET con.amount row.amount;涉及法规节点时我建议单独维护一份法规库。法规条文不是每次抽取都要重新入库的把它们作为静态词典预置进 Neo4j抽取只负责建立条款—引用—法规的关系这样图规模小查询也快。比如把劳动法规条文先按Article节点批量载入之后每一份劳动合同的风险判断都直接指向节点不用反复把法条全文塞给大模型。Cypher 的查询质量决定了推理的边界。一个最常用的路径查询穿透企业关联关系看连带责任风险。// 找到目标公司两跳内所有实体及其关系 MATCH p (co:Company {id: $company_id})-[:HOLD_SHARE|HAS_CONTRACT|BREACH*1..2]-(target) RETURN p LIMIT 100*1..2是可变长度路径限定最大深度为 2。企业关联、合同违约、劳动争议这类风险链路通常不超过 2 跳跳到第 3 跳之后噪音明显增加可解释性也变差。深度参数是生产环境里最值得仔细调的深度 2 是把风险画清楚深度 3 是把公司画成股东的背景板。3. 让 DeepSeek 在知识图谱上做推理从路径到风险结论3.1 为什么纯图查询跑不出风险结论先明确风险不是图里现存的边而是对多个实体和关系做综合判断后的结论。Cypher 能查出来A 公司持有 B 公司 60% 股权、B 公司有一笔逾期贷款但它不会主动告诉你A 公司存在连带清偿风险因为连带清偿是法律上的推演需要结合担保合同、贷款用途、转让记录等多个维度。这就是 DeepSeek 接入图谱的价值。业界常见的架构是 GraphRAG先在图谱上执行查询取出子图把子图序列化成上下文文本连同用户问题一起交给大模型做推理。推理任务的核心不是让模型去记法条而是让它在给定子图上做局部的、每一步都有依据的判断。模型不需要知道全世界的法律只需要知道这张图里的事实以及推理规则。所以我做这类方案时不会让模型直接访问 Neo4j。路径是业务问题 → 模板加动态参数生成 Cypher → 执行查询得到子图 JSON → 序列化为推理上下文 → DeepSeek 输出风险点、置信度和防控建议。模型接触不到数据库原始结构这是安全和准确率兼顾的做法。3.2 子图序列化的三种表示图谱数据不能直接塞进 Prompt模型对 JSON 的嵌套结构理解有限序列化成无向文本效果反而好。我对照过三种写法各有适用场景。表示方式样例优点适用场景三元组列表(企业A)-[持有]-(企业B)省 token结构干净单跳事实类问题路径形文本公司A 持有 公司B 60% 股权公司B 与 银行C 签订贷款合同金额500万状态逾期贴合模型训练语料多跳理解好多跳责任推演节点属性账本节点:合同123, 类型:采购合同, 金额:500万数值判断准确阈值类风险判断路径形文本在多数场景里效果最好因为它把图翻译成了接近自然语言的表述DeepSeek 对谁、做了什么、产生什么后果这类叙事的理解远强于对嵌套 JSON 的理解。三元组列表适合做证据回溯展示模型输出的evidence字段正好可以反向映射回三元组。def serialize_paths(records: list[dict]) - str: 把 Cypher 查询返回的路径记录转成路径形文本 lines [] for r in records: for rel in r.get(relationships, []): src rel.nodes[0][name] dst rel.nodes[1][name] typ rel.type attrs , .join(f{k}{v} for k, v in rel.properties.items()) lines.append(f{src} -[{typ}]- {dst} ({attrs})) return \n.join(lines)序列化函数里保留属性能显著提升后续推理质量。比如只写公司B 与 银行C 签订贷款合同模型不知道这笔贷款是否逾期带上状态逾期、金额500万模型才能据此推断出还款压力和潜在诉讼风险。属性是推理的事实基础宁可多带一两项也不要省略。3.3 推理任务的 Prompt 结构与关键参数Prompt 结构直接影响输出能不能进下游审批流。我常用的模板把系统指令和用户问题分开系统指令里固定输出 JSON 格式用户问题里只塞序列化后的路径事实。def build_inference_prompt(entity_context: str, question: str) - list[dict]: system ( 你是一名企业法律风险分析师。下方给定的是从企业知识图谱中抽取的路径事实 只基于这些事实做判断不得引入图谱外的企业信息。\n 输出格式固定为 JSON\n {risk_points: [{type: 风险类型, party: 主体, evidence: [依据的路径事实]}], confidence: 0.0, suggestions: [防控措施]}\n 当事实不足时confidence 必须低于 0.4并明确写 evidence 为空。 ) user f路径事实\n{entity_context}\n\n用户提问{question} return [ {role: system, content: system}, {role: user, content: user}, ]这段代码的三个要点evidence字段强制模型给出依据的路径事实后续可以回溯验证。实际落地时我会把模型输出的evidence和子图节点做一次字符串匹配如果匹配不上说明模型在编造直接拦下来进入人工复核。confidence的硬约束是防止模型不懂装懂。实践中有个很有效的技巧在提示词里告诉模型只要图谱事实中没有直接提到的内容confidence 就不要超过 0.4这比单独加温度参数有用得多。对于需要多步推导的问题可以设置deepseek-reasoner作为推理模型调用方式和deepseek-chat一样只是模型名不同。reasoner 会在内部展开思维链对担保责任是否成立这类问题输出质量明显更高代价是延迟 3 到 5 倍批量场景建议做异步任务队列。调用时我遵循temperature0.2、max_tokens2000。图谱上的推理本质上是一种受约束的生成temperature 过高会让模型想到图谱外的东西过低则可能导致重复句子、结论单一。0.2 是稳妥的默认值如果发现风险类型总是那几种可以把温度提高到 0.3同时让evidence字段承担去重判断。提示不要在同一请求里既做风险识别又做措施推荐。一次请求做完两个任务模型倾向于先凑建议再补依据证据链质量明显下降。拆成两次调用第一次只输出风险点和证据第二次把风险点和子图再传给模型生成措施。3.4 规则推理与模型推理的交接边界最后处理混合推理。我的经验是能写成规则的优先走规则规则覆盖不了再交给模型。规则引擎的优势是稳定、可解释、零延迟模型引擎的优势是能够应对未预见的表述、推断出隐含责任。具体怎么分要看场景判断类型优先规则什么时候交给 LLM过期未履行规则直接查日期条件满足即告警LLM 不参与股权质押加被执行记录规则查路径存在即标记高优先级待核查LLM 负责生成核查重点合同终止后仍然送货规则无法预判这种语义型风险LLM 根据合同条款和图谱事件推断提示生产系统中加一个规则召回率监控每周统计规则命中率。如果命中率显著上升说明数据在标准化LLM 的闸门就可以进一步收紧token 成本也随之下降。这条边界非常关键。规则过了就不需要再调用大模型能省掉大批量场景的 token规则漏掉的语义风险靠 LLM 兜底。4. 企业运营全流程风险识别的实现分阶段模板与推荐4.1 全流程阶段的划分和图谱映射企业运营的法律风险分散在采购、销售、人力资源、知识产权、投融资和数据流转六个环节。知识图谱的图结构天然适合按阶段挂载风险模板我把它组织成一张阶段到图谱子图的映射表阶段核心图谱子图典型风险信号推荐输出采购供应商—合同—订单—付款记录供应商涉诉、付款逾期、合同无违约金条款更换供应商或补充违约条款销售客户—合同—回款记录—催告记录回款周期拉长、客户股权变更频繁停止赊销或启用保理人力资源员工—劳动合同—社保记录—竞业协议竞业协议缺失、社保基数异常补签竞业协议、合规培训知识产权企业—专利/商标—申请记录—侵权线索核心专利临近到期、商标被抢注启动续展、提出异议投融资企业—股东—股权—对赌协议对赌目标无法达成、股权质押率高提前协商增信、调整估值数据合规企业—系统—数据类别—授权记录用户授权缺失、跨境传输无协议完善隐私政策、合同补授权这六个阶段不要求一次开发到位。落地时我一般先选一个数据最干净、风险暴露最明显的阶段通常是采购因为合同和付款记录都是结构化数据跑通整条链路后再复制到其他阶段。全流程的全是在架构上不是在首期上线范围上。4.2 风险识别 Pipeline 的完整代码骨架多阶段 pipeline 的实现核心是规则先扫、LLM 兜底。下面这段代码是生产可用的骨架规则命中的直接进处置队列模型命中的必须经过 evidence 校验。import json from openai import OpenAI from neo4j import GraphDatabase RULE_BASED_CHECKS { overdue_payment: ( MATCH (c:Contract)-[:HAS_ORDER]-(o:Order) WHERE o.pay_due_date date() AND o.paid false RETURN c.id AS contract_id, o.id AS order_id ), share_pledge_with_lawsuit: ( MATCH (p:Person)-[:HOLDS]-(s:Share)-[:PLEDGED_TO]-(:Bank) MATCH (p)-[:AS_PARTY]-(l:Lawsuit) RETURN p.id, s.company_id, l.case_no ), } class LegalRiskPipeline: def __init__(self, neo4j_uri, neo4j_auth, openai_api_key): self.driver GraphDatabase.driver(neo4j_uri, authneo4j_auth) self.llm OpenAI(api_keyopenai_api_key, base_urlhttps://api.deepseek.com/v1) def rule_scan(self, rule_name: str) - list: 规则层直接查询图拿到风险主体列表 query RULE_BASED_CHECKS[rule_name] with self.driver.session() as session: result session.run(query) return [record.data() for record in result] def semantic_scan(self, company_id: str, stage: str) - dict: 语义层把子图发给 DeepSeek判断规则覆盖不到的风险 subgraph self.fetch_subgraph(company_id, stage) context serialize_paths(subgraph) resp self.llm.chat.completions.create( modeldeepseek-reasoner, messagesbuild_inference_prompt(context, f请评估{stage}阶段风险), temperature0.2, max_tokens2000, ) content json.loads(resp.choices[0].message.content) return content.get(risk_points, []) def run(self, company_id: str, stages: list[str]): for stage in stages: for rule in RULE_BASED_CHECKS: hits self.rule_scan(rule) # 规则命中直接进处置队列不走 LLM节省 token self.enqueue_risk(company_id, stage, rule, hits) llm_hits self.semantic_scan(company_id, stage) # 模型输出含 evidence回溯检查 self.enqueue_risk(company_id, stage, semantic, llm_hits)RULE_BASED_CHECKS里的两类规则是生产环境最常见的带日期比较的账期规则以及带路径跨度的关系规则。rule_scan做图查询命中即为风险无需模型参与semantic_scan拿整段子图塞给大模型输出中的evidence回溯检查。两阶段衔接的关键是队列规则命中直接进处置队列模型命中必须经过evidence校验校验不过进人工复核队列而不是直接推送。4.3 防控措施推荐先查下一步再生成建议防控措施的本质不是生成一段话而是从图谱中找到可行的动作路径。例如检测到供应商涉及诉讼措施不是凭空写注意替换供应商而是查询供应商名下的未结诉讼数量、保函金额、合作合同剩余期限再结合这些数据生成建议。MATCH (co:Company {id: $supplier_id})-[:HAS_CONTRACT]-(c:Contract) WHERE c.status active OPTIONAL MATCH (co)-[:AS_PARTY]-(l:Lawsuit) WITH co, count(DISTINCT c) AS active_contracts, count(DISTINCT l) AS open_actions RETURN co.name, active_contracts, open_actions这个查询返回供应商活跃合同数和涉诉数。当涉诉数大于 2 时直接触发高风险供应商处置流程流程中再调用 DeepSeek 生成一份可审批的替换说明。值得说明的是措施推荐和风险识别必须分成两个模型调用不要放在同一次 Prompt 里。同一次调用会让模型为了凑出建议而遗漏风险判断而且措施往往基于不同子图试图覆盖所有子图的单个请求既慢又容易出错。措施推荐里要预留人工审核步骤。合规建议直接推送业务部门会造成误伤生产中一般加两档权限模型建议只读、法务确认后发布。这条规则几乎是法律科技类项目里的铁律项目经理和技术负责人最好在第一版就把它锁进权限设计中。5. 部署调优三个把 DeepSeek 推理落到生产环境的技巧5.1 用 SGLang 部署本地推理服务加速批量任务企业知识图谱有大量批量场景比如月底对整个供应商池做风险扫描。调用公网 API 在数据量大以后既是成本问题也是队列拥堵问题常见的解决方案是用 SGLang 把开源 DeepSeek 模型部署成自管推理服务。一条可行的启动命令python -m sglang.launch_server \ --model-path deepseek-ai/DeepSeek-R1-0528 \ --port 30000 \ --mem-fraction-static 0.85 \ --max-running-requests 32 \ --tp-size 2--port 30000是本地推理服务的对外开放端口--tp-size 2表示使用两张 GPU 做张量并行--mem-fraction-static控制显存占用上限防止和同一节点上的其他服务抢显存导致 OOM。启动后提供一个 OpenAI 兼容的/v1/chat/completions端点调用代码只需把base_url改为http://localhost:30000/v1其余逻辑完全不动。这个技巧的价值在于把批量扫描的成本从按 token 计费变成按 GPU 时长计费数据量越大优势越明显。5.2 混合检查把证据回溯当作幻觉过滤网大模型输出合法的 JSON 不代表结论可信尤其合理性幻觉模型会把图谱里没有的事实包装成合理的风险判断。一个实用的验证角度把模型输出中的每个evidence字段转成一条 Cypher 查询去图库里验证是否存在。查询为空即视为幻觉。# evidence: 企业与银行C签订贷款合同金额500万 MATCH (e:Enterprise)-[HAS_CONTRACT]-(c:Contract)-[LOAN_TO]-(b:Bank) WHERE b.name 银行C AND c.amount 5000000 RETURN e.id LIMIT 1这条查询可以批量替换$evidence参数。验证通过率低于 70% 时说明需要回退去改进本体设计和序列化方式而不是改提示词。这个指标比模型自评的置信度可靠得多它是一件朴素而稳定的仪器。5.3 结果展示时把推理路径可视化最后是一个容易忽略的技术点。系统上线后法务最关心的不是模型准确率而是为什么推荐这个措施。建议在返回结果的字段里保留完整的path数组前端基于path渲染成从合同到风险事件的链路图。这个可视化不需要额外的框架直接用图谱查询返回的节点关系配对即可。把链路图做到合规审批界面上比让法务看一长串 JSON 有效得多也更直接地让全流程的法律风险识别真正在业务流程中被使用起来。本文还有配套的精品资源点击获取 DeepSeek+Neo4j构建企业法律知识图谱，实现全流程风险智能诊断
简介面向企业法务、合规管理及法律科技从业者这份850页的PDF文档围绕DeepSeek与知识图谱推理完整讲解企业运营全流程法律风险点识别和防控措施推荐方案。内容既涵盖法律实体识别与关系抽取、法律条文与案例结构化、知识图谱Schema设计、多源异构数据标准化、同义词库构建等基础环节也覆盖图谱存储选型、分布式查询优化、增量更新、实体链接、知识图谱补全以及DeepSeek推理引擎与规则/神经网络混合推理策略体系性很强。资源共1个PDF文件包体约15.65MB内置目录书签与快速定位支持方便按章节查阅。目前已有134人学习/浏览。文档总计850页、56个大章节前20章对上述模块的设计规范和实现方法展开细致说明既可作为法律知识图谱项目的方案参考也能帮助技术人员理解企业风险防控系统的完整技术链路。1. 企业法律风险智能诊断为什么绕不开知识图谱别被全流程三个字吓住这套方案想做的事其实可以压缩成一句话企业里每个合同、每笔交易、每场劳动争议背后都有一张关系网传统做法靠法务凭经验抽丝剥茧知识图谱把这套经验固化成可遍历的图结构再由 DeepSeek 在图上完成需要语义理解的那部分推理。于是识别风险点从关键词搜索变成多跳推理推荐防控措施从套模板变成背靠证据链生成。做过合同审查系统的人都有同感直接问大模型这份合同有没有风险得到的建议泛泛而谈很难落到诉讼或谈判里。原因是法律问题本质上是路径问题——供应商延期交货会不会触发对下游的违约责任取决于合同条款、催告记录、历史履约等多个节点必须形成一条闭合的证据链。知识图谱正是为这类多跳关系设计的载体。下面梳理的落地路径适合算法工程师、法务系统架构师与负责企业合规产品的技术负责人先按本体论构建图谱再让 DeepSeek 在图谱上做混合推理最后输出风险点、证据链和防控动作。2. 用 DeepSeek Neo4j 构建企业法律知识图谱的完整链路2.1 法律领域图谱的本体设计实体、关系与属性先立本体。企业运营法律风险的图模型并不复杂我常用的核心实体只有六类企业含子公司与关联方、自然人法人、股东、员工、合同、合同条款、法规、风险事件诉讼、保全、行政处罚。关系按业务场景设计而不是按法条设计否则图会无限膨胀查询和维护都会失控。关系方向典型属性业务含义HAS_CONTRACT企业→合同签署日期、金额、生效状态判断履约义务是否存在SIGN自然人→合同签署方式电子/纸质/代签电子签名效力审查入口APPLY_TO合同条款→合同条款类型违约/变更/解除快速定位争议条款BREACH合同→风险事件违约类型、时间、金额风险链路的起点HOLD_SHARE企业→企业持股比例、质押情况关联交易与股权穿透REFERENCE合同条款→法规引用条文编号判定条款合法性的直接跳板实体和关系定了之后属性越少越好。属性进入图谱会显著增加维护成本凡是能放进文档数据库的字段尽量不建图属性。举例合同文本全文放 Elasticsearch图谱里只存合同 ID、类型、金额、管辖地这四个用于检索和过滤的字段需要全文语义搜索时再回查 ES。关系上同理时间属性只在时间对推理有约束作用时才保留比如签署日期早于法规生效日这种场景。2.2 用 DeepSeek 从合同文本里抽取实体和关系知识图谱构建的日常工作负载在抽取环节。对于合同、判决书这类半结构化文本成熟的方案是让 DeepSeek 做零样本信息抽取输出统一 JSON再对 JSON 做校验后写库。DeepSeek 的对话接口兼容 OpenAI 的调用风格迁移成本很低。import json import re from openai import OpenAI # deepseek 提供 OpenAI 兼容的 API 端点 client OpenAI( api_keyYOUR_API_KEY, base_urlhttps://api.deepseek.com/v1 ) def extract_legal_knowledge(text: str) - tuple: schema { entities: [ {name: str, type: 企业|自然人|合同|条款|风险事件|法规} ], relations: [ { source: str, target: str, type: HAS_CONTRACT|BREACH|APPLY_TO|HOLD_SHARE, attrs: {date: YYYY-MM-DD, amount: float} } ] } # 限定输出形状避免模型自由发挥 prompt ( 你是企业法律信息抽取器。从给定文本中抽出合同当事人、合同条款、 涉及的法规、已发生或可能发生的风险事件以及彼此之间的关系。 只输出 JSONJSON 必须符合下面 schema\n f{json.dumps(schema, ensure_asciiFalse, indent2)} \n如果某条关系的时间或金额在原文里没有attrs 中可以省略该字段。\n 文本\n text[:12000] ) resp client.chat.completions.create( modeldeepseek-chat, # 或 deepseek-reasoner后者推理更强但更慢 messages[{role: user, content: prompt}], temperature0.1, # 信息抽取场景温度放低减少随机性 response_format{type: json_object} ) raw resp.choices[0].message.content # 粘贴代码可能被 markdown 包住做一次剥离 raw re.sub(r(?:json)?, , raw).strip() data json.loads(raw) return data[entities], data[relations]这段代码的关键参数temperature0.1控制随机性信息抽取宁可少答也不许编造所以只给 0.1 而非默认 1.0response_format强制返回合法 JSON避免在批量任务里反复做字符串解析deepseek-chat用于普通抽取deepseek-reasoner在面对责任划分、过错推定这类需要推导的文本时更好用代价是延迟明显上升建议只在清洗阶段用。抽取质量验证不能看单条样本。常见做法是抽 50 份合同把实体准确率、关系准确率分别统计关系准确率低于 85% 时优先修 schema 而不是改提示词。例如模型经常把甲方和公司A当两个实体本质上是缺了共指消解指令在 schema 里加一条aliases: []并要求实体去重后合并效果通常比写一大段所有角色都指向同一主体的提示词更稳定。2.3 Neo4j 写库与图查询的落库实践实体关系拿到后写库这一段没什么发挥空间但容易踩坑。我一般用 Cypher 的MERGE而不是CREATE这个关键字保证图里不产生重复节点。// 节点写入合同节点唯一的业务键用合同编号 MERGE (c:Contract {id: $contract_id}) ON CREATE SET c.type $contract_type, c.amount $amount, c.sign_date $sign_date; // 关系写入企业—签署—合同 MATCH (co:Company {id: $company_id}) MATCH (c:Contract {id: $contract_id}) MERGE (co)-[r:HAS_CONTRACT]-(c) SET r.sign_date $sign_date, r.legal_effective $legal_effective; // 批量导入建议用 UNWIND避免逐条网络往返 UNWIND $batch AS row MERGE (co:Company {id: row.company_id}) MERGE (con:Contract {id: row.contract_id}) MERGE (co)-[:HAS_CONTRACT]-(con) ON CREATE SET con.amount row.amount;涉及法规节点时我建议单独维护一份法规库。法规条文不是每次抽取都要重新入库的把它们作为静态词典预置进 Neo4j抽取只负责建立条款—引用—法规的关系这样图规模小查询也快。比如把劳动法规条文先按Article节点批量载入之后每一份劳动合同的风险判断都直接指向节点不用反复把法条全文塞给大模型。Cypher 的查询质量决定了推理的边界。一个最常用的路径查询穿透企业关联关系看连带责任风险。// 找到目标公司两跳内所有实体及其关系 MATCH p (co:Company {id: $company_id})-[:HOLD_SHARE|HAS_CONTRACT|BREACH*1..2]-(target) RETURN p LIMIT 100*1..2是可变长度路径限定最大深度为 2。企业关联、合同违约、劳动争议这类风险链路通常不超过 2 跳跳到第 3 跳之后噪音明显增加可解释性也变差。深度参数是生产环境里最值得仔细调的深度 2 是把风险画清楚深度 3 是把公司画成股东的背景板。3. 让 DeepSeek 在知识图谱上做推理从路径到风险结论3.1 为什么纯图查询跑不出风险结论先明确风险不是图里现存的边而是对多个实体和关系做综合判断后的结论。Cypher 能查出来A 公司持有 B 公司 60% 股权、B 公司有一笔逾期贷款但它不会主动告诉你A 公司存在连带清偿风险因为连带清偿是法律上的推演需要结合担保合同、贷款用途、转让记录等多个维度。这就是 DeepSeek 接入图谱的价值。业界常见的架构是 GraphRAG先在图谱上执行查询取出子图把子图序列化成上下文文本连同用户问题一起交给大模型做推理。推理任务的核心不是让模型去记法条而是让它在给定子图上做局部的、每一步都有依据的判断。模型不需要知道全世界的法律只需要知道这张图里的事实以及推理规则。所以我做这类方案时不会让模型直接访问 Neo4j。路径是业务问题 → 模板加动态参数生成 Cypher → 执行查询得到子图 JSON → 序列化为推理上下文 → DeepSeek 输出风险点、置信度和防控建议。模型接触不到数据库原始结构这是安全和准确率兼顾的做法。3.2 子图序列化的三种表示图谱数据不能直接塞进 Prompt模型对 JSON 的嵌套结构理解有限序列化成无向文本效果反而好。我对照过三种写法各有适用场景。表示方式样例优点适用场景三元组列表(企业A)-[持有]-(企业B)省 token结构干净单跳事实类问题路径形文本公司A 持有 公司B 60% 股权公司B 与 银行C 签订贷款合同金额500万状态逾期贴合模型训练语料多跳理解好多跳责任推演节点属性账本节点:合同123, 类型:采购合同, 金额:500万数值判断准确阈值类风险判断路径形文本在多数场景里效果最好因为它把图翻译成了接近自然语言的表述DeepSeek 对谁、做了什么、产生什么后果这类叙事的理解远强于对嵌套 JSON 的理解。三元组列表适合做证据回溯展示模型输出的evidence字段正好可以反向映射回三元组。def serialize_paths(records: list[dict]) - str: 把 Cypher 查询返回的路径记录转成路径形文本 lines [] for r in records: for rel in r.get(relationships, []): src rel.nodes[0][name] dst rel.nodes[1][name] typ rel.type attrs , .join(f{k}{v} for k, v in rel.properties.items()) lines.append(f{src} -[{typ}]- {dst} ({attrs})) return \n.join(lines)序列化函数里保留属性能显著提升后续推理质量。比如只写公司B 与 银行C 签订贷款合同模型不知道这笔贷款是否逾期带上状态逾期、金额500万模型才能据此推断出还款压力和潜在诉讼风险。属性是推理的事实基础宁可多带一两项也不要省略。3.3 推理任务的 Prompt 结构与关键参数Prompt 结构直接影响输出能不能进下游审批流。我常用的模板把系统指令和用户问题分开系统指令里固定输出 JSON 格式用户问题里只塞序列化后的路径事实。def build_inference_prompt(entity_context: str, question: str) - list[dict]: system ( 你是一名企业法律风险分析师。下方给定的是从企业知识图谱中抽取的路径事实 只基于这些事实做判断不得引入图谱外的企业信息。\n 输出格式固定为 JSON\n {risk_points: [{type: 风险类型, party: 主体, evidence: [依据的路径事实]}], confidence: 0.0, suggestions: [防控措施]}\n 当事实不足时confidence 必须低于 0.4并明确写 evidence 为空。 ) user f路径事实\n{entity_context}\n\n用户提问{question} return [ {role: system, content: system}, {role: user, content: user}, ]这段代码的三个要点evidence字段强制模型给出依据的路径事实后续可以回溯验证。实际落地时我会把模型输出的evidence和子图节点做一次字符串匹配如果匹配不上说明模型在编造直接拦下来进入人工复核。confidence的硬约束是防止模型不懂装懂。实践中有个很有效的技巧在提示词里告诉模型只要图谱事实中没有直接提到的内容confidence 就不要超过 0.4这比单独加温度参数有用得多。对于需要多步推导的问题可以设置deepseek-reasoner作为推理模型调用方式和deepseek-chat一样只是模型名不同。reasoner 会在内部展开思维链对担保责任是否成立这类问题输出质量明显更高代价是延迟 3 到 5 倍批量场景建议做异步任务队列。调用时我遵循temperature0.2、max_tokens2000。图谱上的推理本质上是一种受约束的生成temperature 过高会让模型想到图谱外的东西过低则可能导致重复句子、结论单一。0.2 是稳妥的默认值如果发现风险类型总是那几种可以把温度提高到 0.3同时让evidence字段承担去重判断。提示不要在同一请求里既做风险识别又做措施推荐。一次请求做完两个任务模型倾向于先凑建议再补依据证据链质量明显下降。拆成两次调用第一次只输出风险点和证据第二次把风险点和子图再传给模型生成措施。3.4 规则推理与模型推理的交接边界最后处理混合推理。我的经验是能写成规则的优先走规则规则覆盖不了再交给模型。规则引擎的优势是稳定、可解释、零延迟模型引擎的优势是能够应对未预见的表述、推断出隐含责任。具体怎么分要看场景判断类型优先规则什么时候交给 LLM过期未履行规则直接查日期条件满足即告警LLM 不参与股权质押加被执行记录规则查路径存在即标记高优先级待核查LLM 负责生成核查重点合同终止后仍然送货规则无法预判这种语义型风险LLM 根据合同条款和图谱事件推断提示生产系统中加一个规则召回率监控每周统计规则命中率。如果命中率显著上升说明数据在标准化LLM 的闸门就可以进一步收紧token 成本也随之下降。这条边界非常关键。规则过了就不需要再调用大模型能省掉大批量场景的 token规则漏掉的语义风险靠 LLM 兜底。4. 企业运营全流程风险识别的实现分阶段模板与推荐4.1 全流程阶段的划分和图谱映射企业运营的法律风险分散在采购、销售、人力资源、知识产权、投融资和数据流转六个环节。知识图谱的图结构天然适合按阶段挂载风险模板我把它组织成一张阶段到图谱子图的映射表阶段核心图谱子图典型风险信号推荐输出采购供应商—合同—订单—付款记录供应商涉诉、付款逾期、合同无违约金条款更换供应商或补充违约条款销售客户—合同—回款记录—催告记录回款周期拉长、客户股权变更频繁停止赊销或启用保理人力资源员工—劳动合同—社保记录—竞业协议竞业协议缺失、社保基数异常补签竞业协议、合规培训知识产权企业—专利/商标—申请记录—侵权线索核心专利临近到期、商标被抢注启动续展、提出异议投融资企业—股东—股权—对赌协议对赌目标无法达成、股权质押率高提前协商增信、调整估值数据合规企业—系统—数据类别—授权记录用户授权缺失、跨境传输无协议完善隐私政策、合同补授权这六个阶段不要求一次开发到位。落地时我一般先选一个数据最干净、风险暴露最明显的阶段通常是采购因为合同和付款记录都是结构化数据跑通整条链路后再复制到其他阶段。全流程的全是在架构上不是在首期上线范围上。4.2 风险识别 Pipeline 的完整代码骨架多阶段 pipeline 的实现核心是规则先扫、LLM 兜底。下面这段代码是生产可用的骨架规则命中的直接进处置队列模型命中的必须经过 evidence 校验。import json from openai import OpenAI from neo4j import GraphDatabase RULE_BASED_CHECKS { overdue_payment: ( MATCH (c:Contract)-[:HAS_ORDER]-(o:Order) WHERE o.pay_due_date date() AND o.paid false RETURN c.id AS contract_id, o.id AS order_id ), share_pledge_with_lawsuit: ( MATCH (p:Person)-[:HOLDS]-(s:Share)-[:PLEDGED_TO]-(:Bank) MATCH (p)-[:AS_PARTY]-(l:Lawsuit) RETURN p.id, s.company_id, l.case_no ), } class LegalRiskPipeline: def __init__(self, neo4j_uri, neo4j_auth, openai_api_key): self.driver GraphDatabase.driver(neo4j_uri, authneo4j_auth) self.llm OpenAI(api_keyopenai_api_key, base_urlhttps://api.deepseek.com/v1) def rule_scan(self, rule_name: str) - list: 规则层直接查询图拿到风险主体列表 query RULE_BASED_CHECKS[rule_name] with self.driver.session() as session: result session.run(query) return [record.data() for record in result] def semantic_scan(self, company_id: str, stage: str) - dict: 语义层把子图发给 DeepSeek判断规则覆盖不到的风险 subgraph self.fetch_subgraph(company_id, stage) context serialize_paths(subgraph) resp self.llm.chat.completions.create( modeldeepseek-reasoner, messagesbuild_inference_prompt(context, f请评估{stage}阶段风险), temperature0.2, max_tokens2000, ) content json.loads(resp.choices[0].message.content) return content.get(risk_points, []) def run(self, company_id: str, stages: list[str]): for stage in stages: for rule in RULE_BASED_CHECKS: hits self.rule_scan(rule) # 规则命中直接进处置队列不走 LLM节省 token self.enqueue_risk(company_id, stage, rule, hits) llm_hits self.semantic_scan(company_id, stage) # 模型输出含 evidence回溯检查 self.enqueue_risk(company_id, stage, semantic, llm_hits)RULE_BASED_CHECKS里的两类规则是生产环境最常见的带日期比较的账期规则以及带路径跨度的关系规则。rule_scan做图查询命中即为风险无需模型参与semantic_scan拿整段子图塞给大模型输出中的evidence回溯检查。两阶段衔接的关键是队列规则命中直接进处置队列模型命中必须经过evidence校验校验不过进人工复核队列而不是直接推送。4.3 防控措施推荐先查下一步再生成建议防控措施的本质不是生成一段话而是从图谱中找到可行的动作路径。例如检测到供应商涉及诉讼措施不是凭空写注意替换供应商而是查询供应商名下的未结诉讼数量、保函金额、合作合同剩余期限再结合这些数据生成建议。MATCH (co:Company {id: $supplier_id})-[:HAS_CONTRACT]-(c:Contract) WHERE c.status active OPTIONAL MATCH (co)-[:AS_PARTY]-(l:Lawsuit) WITH co, count(DISTINCT c) AS active_contracts, count(DISTINCT l) AS open_actions RETURN co.name, active_contracts, open_actions这个查询返回供应商活跃合同数和涉诉数。当涉诉数大于 2 时直接触发高风险供应商处置流程流程中再调用 DeepSeek 生成一份可审批的替换说明。值得说明的是措施推荐和风险识别必须分成两个模型调用不要放在同一次 Prompt 里。同一次调用会让模型为了凑出建议而遗漏风险判断而且措施往往基于不同子图试图覆盖所有子图的单个请求既慢又容易出错。措施推荐里要预留人工审核步骤。合规建议直接推送业务部门会造成误伤生产中一般加两档权限模型建议只读、法务确认后发布。这条规则几乎是法律科技类项目里的铁律项目经理和技术负责人最好在第一版就把它锁进权限设计中。5. 部署调优三个把 DeepSeek 推理落到生产环境的技巧5.1 用 SGLang 部署本地推理服务加速批量任务企业知识图谱有大量批量场景比如月底对整个供应商池做风险扫描。调用公网 API 在数据量大以后既是成本问题也是队列拥堵问题常见的解决方案是用 SGLang 把开源 DeepSeek 模型部署成自管推理服务。一条可行的启动命令python -m sglang.launch_server \ --model-path deepseek-ai/DeepSeek-R1-0528 \ --port 30000 \ --mem-fraction-static 0.85 \ --max-running-requests 32 \ --tp-size 2--port 30000是本地推理服务的对外开放端口--tp-size 2表示使用两张 GPU 做张量并行--mem-fraction-static控制显存占用上限防止和同一节点上的其他服务抢显存导致 OOM。启动后提供一个 OpenAI 兼容的/v1/chat/completions端点调用代码只需把base_url改为http://localhost:30000/v1其余逻辑完全不动。这个技巧的价值在于把批量扫描的成本从按 token 计费变成按 GPU 时长计费数据量越大优势越明显。5.2 混合检查把证据回溯当作幻觉过滤网大模型输出合法的 JSON 不代表结论可信尤其合理性幻觉模型会把图谱里没有的事实包装成合理的风险判断。一个实用的验证角度把模型输出中的每个evidence字段转成一条 Cypher 查询去图库里验证是否存在。查询为空即视为幻觉。# evidence: 企业与银行C签订贷款合同金额500万 MATCH (e:Enterprise)-[HAS_CONTRACT]-(c:Contract)-[LOAN_TO]-(b:Bank) WHERE b.name 银行C AND c.amount 5000000 RETURN e.id LIMIT 1这条查询可以批量替换$evidence参数。验证通过率低于 70% 时说明需要回退去改进本体设计和序列化方式而不是改提示词。这个指标比模型自评的置信度可靠得多它是一件朴素而稳定的仪器。5.3 结果展示时把推理路径可视化最后是一个容易忽略的技术点。系统上线后法务最关心的不是模型准确率而是为什么推荐这个措施。建议在返回结果的字段里保留完整的path数组前端基于path渲染成从合同到风险事件的链路图。这个可视化不需要额外的框架直接用图谱查询返回的节点关系配对即可。把链路图做到合规审批界面上比让法务看一长串 JSON 有效得多也更直接地让全流程的法律风险识别真正在业务流程中被使用起来。本文还有配套的精品资源点击获取