简介：这是一份基于DeepSeek的法律舆情智能分析技术方案文档，面向法律科技产品经理、NLP算法工程师与舆情分析从业者，旨在解决法律热点事件脉络梳理与公关应对策略自动生成难题。文档以事件抽取技术为主线，完整呈现法律文本预处理、专业语料库与标注体系设计、命名实体识别、触发词识别、事件要素抽取、时序关系抽取、因果关系识别、事件共指消解等核心环节；同时包含舆情数据采集、多源异构处理、实时抓取与文本清洗去重工程实践，并覆盖注意力机制适配、多标签分类、事件脉络节点权重计算与可视化数据结构设计等进阶主题。资源完整包含56个大章节、709页，为单个PDF文件，大小14.3MB，支持目录跳转与书签大纲，排版清晰完整。目前已有82人学习，适合需要快速了解法律NLP落地方案、借鉴完整技术框架与实现细节的读者。
1. 法律舆情为什么必须走事件抽取，而不是让 DeepSeek 直接写结论
打开一个涉法热点事件的舆情报告，真正值钱的不是模型复述了多少条微博，而是它能不能把“谁在哪一天起诉了谁、法院怎么认定、律师怎么回应、舆论为什么发酵”理成一条能查证的线。DeepSeek 这类大模型直接问“你怎么看这个案子”，能给出流畅但无法追溯的结论；一旦进入法律舆情场景，结论必须挂在证据上，事件抽取就是那个挂钩。它的工作方式不是写作文，而是从非结构化的判决书、公告、新闻和社交媒体文本里，把事件触发词、参与者、时间点、法律依据抽成结构化字段，再按时间线拼装。这套方案的价值在于：不靠模型记忆法律知识，而是靠抽取结果还原事件本身，让公关应对方案有据可依。
适合谁做？律所品牌团队、企业法务与舆情监测服务商，以及做法律 NLP 的开发者。前提是你手里有真实的文本数据源，模型负责把文本变成结构，而不是替你拍板。
2. 用 DeepSeek 搭事件抽取管线：两种接入方式与结构化输出设计
2.1 先想清楚：为什么事件抽取比直接摘要更适合法律舆情
法律舆情文本有一个区别于通用新闻的显著特点：事实陈述与观点评论混杂。一篇报道里既有法院公告的原文引用，又有律师的主观解读，还有评论区里情绪化的猜测。摘要模型会把这三层内容揉在一起输出，而事件抽取强制模型逐句判断“这句话描述了哪个事件、涉及谁、发生在什么时间、和哪条法律条文相关”。
另一个原因是可复核性。你拿抽取出的“2024-05-12，某某法院，立案”去原始文本里检索，一定能找到对应句子；但摘要输出“该案引发广泛关注”这种话，无法定位到具体证据。法律舆情的应对方案一旦对外发布，每一个事实点都要能回查原文，事件抽取提供的正是这种可追溯的结构。
我在实际项目里的做法是两级管线：先用事件抽取把原始文本切成最小事件单元，再用事件脉络模块把这些单元串成时间线。DeepSeek 在这一步替代了传统的序列标注模型，不需要再为每一个事件类型训练一个 BERT 分类器，而是用指令跟随能力直接输出 JSON 结构，这让冷启动新事件类型的成本从几天降到几小时。
2.2 本地部署还是 API：两条接入路径的取舍
DeepSeek 接入方式无非两条路，本地部署和官方 API。本地部署适合对数据出境敏感的法律场景，毕竟判决书和公关材料属于敏感信息。常见做法是部署蒸馏版模型，比如 14B 到 32B 的量化版本，配合 vLLM 做推理加速。API 调用则胜在省事，不需要维护推理服务器，适合快速验证抽取效果。我之前在一个涉密项目里被客户明确要求“数据不出内网”，最后走了本地部署；另一个纯公开数据的项目直接用了 API，开发周期压缩了一半。
下面这段代码演示的是通过 API 方式调用 DeepSeek 做事件抽取的最小链路。实际项目中一般会封装成独立的服务，避免在业务代码里散落 prompt 模板。
import json import requests # 请替换为真实的 API Key 和接口地址 API_URL = "https://api.deepseek.com/chat/completions" API_KEY = "sk-xxxxxxxx" def extract_events(text: str, api_key: str = API_KEY, model: str = "deepseek-chat") -> list: """ 从单条法律舆情文本中抽取事件列表。 返回的每个事件都是结构化字典，对应一个最小事件单元。 """ prompt = f"""你是法律舆情事件抽取引擎。 请从下面的文本中抽取所有法律事件。 判断标准：有触发词（立案/起诉/判决/上诉/逮捕/约谈等）， 有明确参与者或机构，且描述的是一个事实动作。 观点、情绪、预测不算事件。 文本： {text} 输出 JSON 数组，每个元素包含字段： event_type, trigger_word, subject, object, time, location, case_no, summary 只输出 JSON，不要额外说明。""" resp = requests.post( API_URL, headers={"Authorization": f"Bearer {api_key}"}, json={ "model": model, "messages": [{"role": "user", "content": prompt}], "temperature": 0.1, # 抽取任务用低温，减少创造性输出 "response_format": {"type": "json_object"}, # 强制 JSON 输出 }, timeout=60, ) resp.raise_for_status() content = resp.json()["choices"][0]["message"]["content"] # 模型可能返回 {"events": [...]} 或直接返回数组，这里做兼容 data = json.loads(content) if isinstance(data, dict): data = data.get("events", []) return data if __name__ == "__main__": sample = ( "2024年5月12日，北京市朝阳区人民法院就王某某诉某科技公司" "劳动争议一案立案。原告代理律师李某某称，公司未足额支付加班费，" "已提交相关证据。被告方暂未公开回应。" ) events = extract_events(sample) for event in events: print(json.dumps(event, ensure_ascii=False, indent=2))temperature 参数在事件抽取里是关键，我一般固定 0.1 到 0.2。温度拉高会让模型输出的事件类型漂移，同一个 trigger word 这次叫“立案”，下次叫“受理”，后续聚合阶段会很难做。response_format 强制 JSON 输出能省掉大量解析容错代码，但要注意 DeepSeek 在超长上下文下偶尔还是会漏掉这个约束，所以代码里留了兼容分支。
2.3 schema 设计决定下游所有工作
事件抽取的输出 schema 是整条管线的地基。设计得过粗，下游时间线合并时缺乏分组依据；设计得过细，模型容易抽错或漏抽。我常用的字段如下：
| 字段 | 说明 | 示例 |
|---|---|---|
| event_type | 事件类型，枚举值 | 立案、开庭、判决、上诉、执行 |
| trigger_word | 触发词，原文中的原词 | 立案 |
| subject | 主动方 | 王某某 |
| object | 被动方 | 某科技公司 |
| time | 事件时间，ISO 格式 | 2024-05-12 |
| location | 法院/机构 | 北京市朝阳区人民法院 |
| case_no | 案号，没有则填空字符串 | （2024）京0105民初123号 |
| summary | 一句话描述 | 王某某诉科技公司劳动争议案在朝阳法院立案 |
event_type 必须做成枚举而不是自由文本。如果你让模型自由发挥，它会输出“起诉”“状告”“递交诉状”等几十种同义说法，后续统计时你会后悔没做枚举约束。在 prompt 里显式给出候选列表是最简单的约束方案。
另一个坑是 time 字段的归一化。新闻文本里经常出现“上周五”“近日”“昨天”这类相对时间，模型无法准确换算成绝对日期。我的处理办法是：在调用事件抽取之前，先用一个独立的日期归一化步骤把相对时间转成绝对时间；如果模型实在无法判断，time 字段给空字符串，不要编造时间。
3. 热点事件脉络梳理：从事件分帧到时间线合并的落地实现
3.1 为什么单条抽取不够，必须做事件分帧
抽取完成只是第一步。一篇万字报道能抽出三十多个事件，但里面有一大半是重复的——不同媒体对同一次庭审的报道，写出来是不同句子，抽出来是相似事件。如果不做去重和合并，最终的时间线会膨胀成流水账，公关团队根本没法看。
事件分帧在这里承担两个职责：第一，识别事件之间的重叠与包含关系，把同一事件的多篇报道合并成一个事件帧；第二，识别事件之间的时序和因果连接，确定“立案”在“判决”之前。我一般把事件帧定义为“同一主体、同一事件类型、同一案号，时间相差不超过 30 天”的抽取结果聚合。
3.2 用 embedding 相似度做事件去重
去重最直接的办法是计算事件 summary 的 embedding 相似度。同一事件的不同报道，summary 语义高度相近，法律术语重合度高。对相似度超过阈值的两两事件，保留信息更全的一条，把另一条的来源链接挂到它下面。
阈值的选择有一点玄学成分。我测试下来，0.86 到 0.90 之间比较稳，低于 0.86 会把“一审判决”和“二审裁决”合并掉——这俩在法律上是完全不同的事件——高于 0.90 又会留下大量重复。下面这段代码实现了去重合并的核心逻辑：
import json import numpy as np from openai import OpenAI client = OpenAI( api_key="sk-xxxx", base_url="https://api.deepseek.com/v1" ) def dedup_events(events: list, threshold: float = 0.88) -> list: """ 基于 embedding 相似度对事件去重。 events: extract_events() 的输出，每个事件是一个字典。 返回去重后的事件列表。 """ if not events: return [] # 生成每个事件的 embedding 向量 vectors = [] for event in events: text = f"{event['event_type']} {event['subject']} {event['object']} {event['summary']}" resp = client.embeddings.create( model="embedding-2", input=text ) vectors.append(resp.data[0].embedding) matrix = np.array(vectors) norm_matrix = matrix / np.linalg.norm(matrix, axis=1, keepdims=True) # 计算余弦相似度矩阵 sim_matrix = norm_matrix @ norm_matrix.T keep = [] dropped = set() for i in range(len(events)): if i in dropped: continue keep.append(events[i]) for j in range(i + 1, len(events)): if sim_matrix[i][j] >= threshold: dropped.add(j) return keep这段代码的关键是把事件按“事件类型 + 主体 + 客体 + 一句话描述”拼成向量化文本。只用 summary 不够，因为法律事件里类型信息权重极高，“判决”和“上诉”的 summary 再像也不能合并。拼上 event_type 之后，相似度计算就有了硬约束。
需要注意 embedding 是异步批量生成的，上面的写法是同步逐条处理，适合事件量小于几百条的场景。如果每天要处理上万条舆情，要用批量接口或向量数据库预处理，否则 API 调用延迟会成为瓶颈。
3.3 时间线合并：把离散事件帧串成叙事线
去重之后的事件仍然是无序的，时间线合并要解决两个问题：排序和分组。排序按 time 字段升序，这个简单；分组则要按“案号 + 主体”把关联事件聚合到同一个案件下，再为每个案件生成一条时间线。同一个热点事件往往包含多个关联案件，比如某某公司被罚、涉及的高管被刑拘、股民发起索赔，这是三条并行时间线但彼此因果相关。
我用的做法是两阶段：先用 case_no 和 subject/object 做一次硬分组，再用 DeepSeek 对每个案件下的事件序列做一次软梳理，补上隐含的因果关系。硬分组保证准确，软梳理保证完整。
这里给一个梳理 prompt 模板，作用是让模型基于抽取出的结构化事件生成脉络摘要：
timeline_prompt = f""" 以下是关于案件“{case_no}”的事件序列，已按时间排序： {json.dumps(events_in_case, ensure_ascii=False, indent=2)} 请做三件事： 1. 检查事件时间顺序是否有明显矛盾，如果有，指出矛盾点； 2. 用 200 字以内概括案件的完整发展脉络，要包含关键转折点； 3. 标出舆论关注度最高的三个事件，用一句话说明原因。 输出格式： {{ "conflicts": [...], "overview": "...", "key_events": ["事件id1", "事件id2", "事件id3"] }} """事件 id 是给每个事件帧分配的稳定编号。分配策略是哈希 case_no 加时间加触发词，保证同一事件在不同批次的处理中得到相同 id，这样后续增量更新时可以合并同一条事件的新报道，而不是重复插入。很多人在这一步用自增 id，增量数据一来就全乱了，回头看会很想给自己一个后悔药。
3.4 舆论关注度：别只看转发量，要看情绪曲线
时间线里要同时接入舆情热度数据。关注度不能只看某一天的转发峰值，那是时点指标。更稳的做法是拉取舆情系统里每个事件的声量序列，计算 24 小时环比增速、负面情感占比、以及意见领袖（大 V、官媒、当事人双方）的参与度。
把这三个指标归一化到 0-100，加权求和得到舆论关注度。我常用的权重是增速 0.4、负面占比 0.35、KOL 参与 0.25。这个权重不是固定的，纯法律垂直类事件和泛社会类事件差别很大，后者 KOL 参与权重应该提到 0.4 以上。这套方案里，事件抽取只负责事实层，舆情热度数据从外部舆情监测系统对接，两者在时间线合并时做关联。
4. 舆情研判与应对方案生成：把抽取结果变成可执行的公关策略
4.1 舆情等级评估：四个维度的综合判定
事件脉络理清之后，下一步是评估风险等级。舆情等级决定了应对的优先级和资源投入。我用四个维度综合判定，而不是只看法庭程序走到哪一步：
| 维度 | 低风险 | 中风险 | 高风险 | 权重 |
|---|---|---|---|---|
| 程序阶段 | 尚未立案 | 已开庭未判决 | 一审败诉/被强制执行 | 0.25 |
| 传播热度 | 日声量 < 1k | 1k–50k | > 50k 或登上热搜 | 0.25 |
| 负面倾向 | 负面占比 < 30% | 30%–60% | > 60% | 0.2 |
| 次生风险 | 无涉刑可能 | 涉及行政处罚 | 涉及刑责/群体事件 | 0.3 |
分数超过 70 分就需要在 4 小时内启动应对；40-70 分是 24 小时内；低于 40 分可以按常规监测走。这个分值和阈值是我自己用的，不是某种行业标准，但它好在完全可解释——你可以在应对方案里写明“因为一审败诉且负面占比 72%，所以判定高风险”，而不是笼统地说“舆情形势严峻”。
每个维度的判分都应该是规则化的，可以从事件抽取结果和舆情数据源自动计算完成，不需要人工介入。我坚持把自动判分和人工复核分开：机器给建议等级，法务人员在系统里确认或修改，这个操作记录要留痕。
4.2 应对方案生成：让 DeepSeek 按 PR 框架输出，而不是自由发挥
很多团队直接用 DeepSeek 写公关回应，效果经常翻车——模型会写出“我们高度重视”开头的官腔，或者引用不存在的法律条款。问题出在 prompt 里没有给足上下文和输出约束。
我把应对方案生成拆成三个模块：事实基线、法律风险点、沟通策略。事实基线来自事件抽取，法律风险点来自对判决结果和相关法条的分析，沟通策略则由模型基于前两者生成。
def generate_response_plan(case_profile: dict) -> str: """ 生成公关应对方案。 case_profile 应包含： - overview: 案件脉络概述 - legal_risks: 法律风险点列表 - public_concerns: 舆论最关注的问题 - confirmed_facts: 已确认的事实，只允许引用这些 """ prompt = f""" 你是企业法律舆情的公关策略顾问。 基于以下案件画像，输出一份应对方案。 【已确认事实】（只能引用这些，不得自行补充） {json.dumps(case_profile['confirmed_facts'], ensure_ascii=False)} 【法律风险点】 {json.dumps(case_profile['legal_risks'], ensure_ascii=False)} 【舆论关切】 {json.dumps(case_profile['public_concerns'], ensure_ascii=False)} 请输出 JSON： {{ "response_statement": "对外回应声明草稿，≤300字，客观陈述事实并说明后续动作", "faq_list": [ {{"question": "舆论可能追问的问题", "answer": "标准回答，必须基于已确认事实"}} ], "action_items": [ {{"priority": "high/medium/low", "action": "具体动作", "owner": "负责角色", "deadline": "时限"}} ], "forbidden_statements": ["绝对不能说的表述及其原因"] }} """ # 调用 DeepSeek 的代码省略，与 extract_events 的调用方式一致 return prompt # 实际返回的是模型生成结果这里的动作项是应对方案自动生成的核心价值点。模型输出的 action_items 不只是停留在“关注舆情动态”这种空话，而是能基于风险点和时间线自动推导出“调取一审判决书全文”“确认是否存在上诉迹象”“提前准备好劳动合同样本供媒体查阅”这类具体任务。owner 字段不一定能直接映射到真实的人名，但可以根据部门映射规则把“负责角色”翻译成“法务部/品牌部/外聘律师”。
4.3 避免生成内容与事实脱节的最后一道闸门
模型生成的方案不能直接发布。我在管线末端加了一道“事实一致性校验”：把生成文本里出现的所有案件事实，与 confirmed_facts 做语义比对，凡是 confirmed_facts 里没有对应描述的内容都标记为“待人工核实”。这个校验可以用 DeepSeek 自己完成，也可以做一个朴素的关键词回溯，做法就是让模型在生成文本时附上每个事实点对应的来源事件 id，再由程序回查该事件 id 是否存在。
比起信任模型的自我校验，我更推荐在生成时直接限制上下文。confirmed_facts 之外的信息不要放进 prompt，这样模型根本没有机会引用未知细节。这也是为什么前面要花那么大力气做事件抽取——结构化的事实基线是整个应对方案生成环节的事实隔离墙。
5. 从 709 页材料到可用结论：五个真实场景下的翻车点与排查办法
5.1 长文档切片导致事件断裂
现象：输入的原始材料有几百页，按固定长度切成多个 chunk 后，同一个案件的事件被切散在不同段落里，抽取结果出现“判决已下达，但没有立案记录”的逻辑断裂。
原因：固定长度切片不感知语义边界。法律文书里一个案件的完整描述可能跨越多个章节，切在案件描述中间就会破坏事件单元的完整性。
解决：先按文档结构切分，用章节标题、案号、当事人名称作为切分边界；没有明确结构的文本，使用基于嵌入向量的语义切分，而不是硬按 token 数切分。切分后对每个 chunk 做事件抽取，再用 embedding 相似度跨 chunk 合并。多花一次语义切分的成本，能换来事件完整性的大幅提升。
5.2 模型把媒体报道当事实
现象：抽取结果中出现“该公司涉嫌诈骗”这类事件，但实际上原文是“有网友称该公司涉嫌诈骗”。模型把转述的质疑和已确认的司法动作混为一谈。
原因：模型不理解来源者立场和事实确认度的区别。新闻报道里有“警方通报”“官方回应”“网友爆料”，事实层级完全不同，但抽取 prompt 没有让模型区分。
解决：在抽取 schema 里增加 evidence_level 字段，枚举值为 confirmed（官方确认）、reported（媒体报道）、rumor（未证实）。prompt 中显式要求：如果文本是转述或引述，标签降级为 reported 或 rumor。后续在时间线梳理时只把 confirmed 作为事实基线，rumor 单独列入“待核实清单”。
5.3 法律条文引用幻觉
现象：应对方案生成时，模型引用了不存在的《公司法》第几条，或把已废止的司法解释当作现行有效依据。这种错误在外行看来无感，但法务一眼就能发现，直接导致方案不可用。
原因：大模型存在幻觉，法律条文的精确编号不在可靠记忆范围内。让模型凭记忆引用具体法条是必然翻车的做法。
解决：建立一个法条知识库，通过检索增强生成在 prompt 里注入相关条文。每次生成前先用关键词从法条库检索候选条文，把条文全文放进上下文，模型只能引用上下文里出现的条文，不能凭记忆生成。为保险起见，还要对模型输出的每个法律引用做一次规则校验，编号如果不在法条库索引中就标记为“引用无效”。
5.4 应对方案请示流程缺失导致信息倒灌
现象：模型生成的应对方案直接对外发布，但方案内容由某个早期事件版本生成，而当时案件已有新进展未被纳入，发布后舆情二次爆发。
原因：没有版本管理意识。事件抽取和时间线梳理是增量更新的，但应对方案是一次性生成的，两者脱节。
解决：给每个案件建立事件时间线版本号，任何应对方案都必须关联版本号。时间线更新时，所有已生成的相关方案进入“已过期”状态，不允许直接发布或复用。这就跟代码发布要锁版本一样，防止新旧混用。
5.5 解析失败与错误数据
现象：DeepSeek 偶发输出非 JSON 格式或字段缺失，导致后续处理代码直接崩溃，某个案件的数据流中断。
原因：深层次原因是推理服务在高并发下输出不稳定，或上下文过长导致指令跟随衰减。表层原因是解析代码没有容错。
解决：所有模型输出走一次“修复-重试”流程。第一步尝试 json.loads 解析；失败后用一个修复 prompt 让模型对输出做二次格式化；二次仍然失败则丢弃该事件但保留原始文本，在日志里记录待人工复核。绝不能因为没有解析结果就把整条数据吞掉，原始文本是最可靠的后悔药，你敢丢数据，后续想重建就得重新花一遍 API 时间。
6. 把单轮生成改成多轮推演：给应对方案做压力测试
最后一层进阶做法，是把“生成一次方案”改成“方案-预演-修正”的多轮推演。方法是在 DeepSeek 中模拟两个角色：公关团队和模拟质疑方，让后者针对方案文本连续追问，前者在追问下修正输出。我的实现是构造一段多轮对话，每一轮把上一轮的回答拼接进上下文。
def stress_test_plan(plan: dict) -> dict: """ 以红队对抗方式对应对方案做多轮压力测试。 每轮由质疑方提问，公关方回答，共 3 轮。 """ red_team_prompt = """ 你是资深财经媒体记者，擅长质疑企业回应。 下面是一份法律舆情的公关应对方案，请你连续追问， 找出声明中的模糊表述、回避事实、前后矛盾之处。 """ blue_team_prompt = """ 你是企业公关负责人，你需要在保持事实一致的前提下， 回应记者的每一次追问。不要编造事实，无法回答就承认“信息待核实”。 """ current_plan = json.dumps(plan, ensure_ascii=False) for round_idx in range(1, 4): question = call_model(f"{red_team_prompt}\n\n方案如下：{current_plan}\n第{round_idx}轮提问：") answer = call_model(f"{blue_team_prompt}\n\n追问：{question}\n你的回应：") current_plan += f"\n{round_idx}轮修正：" + answer return json.loads(current_plan)三轮推演之后得到的方案，基本能把“舆论最尖锐的问题”和“无法回答的部分”暴露干净。前者直接充实到 FAQ 库，后者标注为“待进一步取证”，提前暴露风险比发布之后再补救要好得多。
用这套思路做下来，我自己的习惯是：每个案件从事件抽取到应对方案定稿，一定留一份“数据来源清单”，里面记录每条关键事实来自哪份材料哪一页。这个习惯救过我很多次——客户拿着舆情报告反问“这句话依据是什么”时，三分钟内拿出出处，比解释一万句模型原理都管用。希望这片子能帮你把自己的舆情分析链路真正搭起来。
本文还有配套的精品资源，点击获取
