简介一份面向司法领域技术人员与AI研究者的DeepSeek证据链智能分析完整方案手册。PDF共364页、52个大章节系统覆盖证据自动归类、语义特征提取、多标签分类模型、注意力机制、实体关系抽取、知识图谱构建、关联权重计算及证据链漏洞识别等核心环节章节兼顾算法原理与工程实现细节。文档为1个PDF文件压缩包共12.76MB支持目录章节跳转与左侧书签大纲快速定位内容完整、表格与图示显示正常。已有90人学习下载。从证据数据采集预处理、非结构化文本向量化到命名实体识别微调、知识图谱存储与时序建模再到置信度评估与阈值判定逻辑整份方案可帮助读者系统搭建司法证据智能处理流程也可作为大模型逻辑推理应用落地的技术参考。1. 证据链这项工作卡在「读完到用上」之间的那一公里拿到 364 页证据材料传统做法是团队坐在一起分卷、贴标签、画时间轴动辄一周。真正让证据梳理变慢的往往不是「读不完」而是「读完了却对不上」——同一笔转账在第三卷出现过银行流水和合同日期相差两天证人说的时间点和聊天记录对不上。DeepSeek 做证据材料智能梳理与证据链漏洞识别这件事核心不是靠全文检索而是靠逻辑推理把几百页零散材料重组成一条可被质证的时间线。这篇笔记写给做诉讼准备、企业合规调查、证据目录管理的从业者把环境搭建、归类关联、漏洞识别和补全建议这几步拆开讲清楚每步给出能复现的参数和代码。2. DeepSeek 落地选型本地部署还是 API两条路各自卡在哪2.1 两条运行路径的取舍本地部署与 API 调用证据材料通常涉密或敏感不能直接往外送。所以第一步不是调参是先定运行路径。常见做法是两条路二选一内网环境用 vLLM 本地部署 DeepSeek机器性能不足或项目周期紧就走 API 调用。本地部署的好处是数据不出域Prompt 里可以放心塞证据正文坏处是显存和并发要自己扛。一个三百多页 PDF 切出来大概是百万级 token 规模逐章推理时并发不高但上下文很长我一般至少准备两块 24G 显存跑量化版边缘设备例如 Jetson Orin 这类也能跑小尺寸模型做初步抽提效果会比x86 服务器差一些。API 调用则省去硬件但要自己做请求管理和成本控制。DeepSeek 的价格按 token 计费证据梳理涉及大量重复归类与关联判断每一页都会被多次送入模型跑完全量材料再乘上调用次数账单才会体现出差距。我的建议是能确定运行环境之前先在 API 上用小样本跑通 prompt确认输出格式稳定再决定要不要迁移到本地。方向没问题但成本失控的项目多半是死在「所有证据反复全量送入模型」这一步后面会讲怎么用归类和抽提减少无效调用。2.2 推理参数与输出约束把「脑洞」关进证据的笼子不论本地还是 API证据类任务对生成参数的要求都比通用对话严。核心是温度自动归类任务我固定在 0.1~0.2保证相同语义的证据每次归类结果一致漏洞识别任务可以放宽到 0.3~0.5因为需要模型适当发散找矛盾点但不能超过 0.5否则模型会把「可能有关」写成「一定有关」。Max tokens 要按输出结构设定归类结果输出 JSON 时我限制在 1024 以内识别漏洞并附理由时会放到 2048。输出约束比温度更关键。证据场景最怕模型自由发挥所以我在所有请求里强制 JSON Object 输出并固定字段名。一个标准的归类请求长这样import requests payload { model: deepseek-chat, messages: [ { role: system, content: 你是证据管理助手。只输出 JSON不要输出任何解释。, }, { role: user, content: 证据内容李四于2024年3月14日向王五转账人民币5万元整附言项目预付款。, }, ], response_format: {type: json_object}, temperature: 0.1, max_tokens: 1024, top_p: 0.7, } resp requests.post( https://api.deepseek.com/chat/completions, headers{Authorization: Bearer YOUR_API_KEY}, jsonpayload, ) print(resp.json()[choices][0][message][content])关键在response_format和temperature两个参数。response_format锁死输出为结构化 JSON后续代码才能稳定解析temperature压到 0.1 是为了归类可复现——同样的证据第二次跑不能变类别。top_p配合 temperature 使用0.7 是一个兼顾稳定性和少量多样性的常用值。如果你走本地 vLLM 部署OpenAI 兼容接口参数相同只需把 URL 换成内网服务地址。3. 证据自动归类与关联分析把散落证据拼成关系网3.1 预处理的切分与标注先给证据上「户口」再聪明的模型也架不住一页 PDF 里挤十种内容。做归类之前先把 364 页拆成最小证据单元。常见做法是按证据编号切每份证据从「证据一、」到「证据二、」之间划一刀切出来的段落保留页号、编号和标题。切分代码不复杂但边界条件很折磨人——有的材料没有编号只有扫描件的页眉这时候就只能按页码切再让模型给每页打标签。这里我一般用两步先按规则切再用模型兜底修正。import re import json text open(evidence.txt, encodingutf-8).read() # 按常见证据编号格式切分 parts re.split(r(?证据[一二三四五六七八九十][、.]), text) chunks [] for i, part in enumerate(parts): part part.strip() if len(part) 20: continue # 提取开头的证据编号作为 id first_line part.split(\n, 1)[0] chunk { id: fev_{i:03d}, header: first_line.strip(), page_range: fp{max(i - 1, 0)}-p{i 1}, content: part, } chunks.append(chunk) with open(chunks.jsonl, w, encodingutf-8) as f: for c in chunks: f.write(json.dumps(c, ensure_asciiFalse) \n) print(f切分出 {len(chunks)} 个证据片段)这段代码把一整块文本按「证据N、」这个标记切分并把每个片段记录为独立的 JSON 行。(?...)是正则的前瞻匹配切分时保留证据编号本身不被吞掉。page_range是按片段索引估算的页码真正做文书校验时还要和原始 PDF 的页码对齐。切分粒度决定了后续所有步骤的上限宁可多切一刀也不要把两份证据粘在一起送进模型。3.2 自动归类语义相似度 层次聚类的组合切分完就该归类了。一开始我以为让 DeepSeek 直接输出类别就行实际跑下来发现不稳定同一份转账记录上一轮归到「资金往来」下一轮变成「合同履行」。所以要分两层先用文本向量做粗聚类再用 DeepSeek 给每个簇打业务标签。向量聚类抓的是文本相似DeepSeek 抓的是语义类别两相结合归类才稳定。向量化可以选择本地 embedding 模型也可以直接调 DeepSeek 的 embedding 接口。拿到向量之后算两两相似度这步用 sklearn 就能做import numpy as np from sklearn.cluster import AgglomerativeClustering from sklearn.metrics.pairwise import cosine_similarity # vectors 是每个证据片段的 embeddingshape (n_chunks, dim) sim cosine_similarity(vectors) # 相似度高于 0.85 视为强关联用于聚类 cluster AgglomerativeClustering( n_clustersNone, distance_threshold0.35, metriceuclidean, linkageaverage, ) labels cluster.fit_predict(1 - sim) for idx, label in enumerate(labels): print(f{chunks[idx][id]} - cluster {label})距离阈值 0.35 对应余弦相似度约 0.75 的归并线。这个数值不是玄学是多次跑出来的经验值低于 0.75 聚进来的大多是泛泛相关高于 0.85 则同一事件的不同侧面会被拆成一堆碎片。跑完聚类后把每个簇的文本并到一起发给 DeepSeek 一句话总结类别名称比如「施工合同付款记录」「2023年6月微信聊天记录」。这样类目名称是模型给的但归类边界是向量定的后者比前者可靠得多。3.3 关联分析共同要素匹配与证据-待证事实映射归好类之后要做的是关联分析。证据链不是「所有证据列表」而是「谁和谁共同支持哪个待证事实」。常规做法是从证据文本里抽结构化字段再按字段做匹配同一转账金额在不同证据中重复出现、同一人物身份证号横跨多份材料、同一时间点出现在银行流水和聊天记录中这些都是强关联信号。我一般会在归类基础上再用 DeepSeek 做一轮「关联对」抽取。输出用固定的 JSON Schema每条记录包含两个证据 ID 和关联类型prompt 请分析下面两份证据之间的关系。 输出 JSON格式为 { rel_type: 补强|矛盾|时间衔接|无关联|待核验, reason: 说明判断依据不超过50字, confidence: 0.0-1.0 } 证据A{chunk_a} 证据B{chunk_b} # 对同一个簇内或跨簇候选对批量调用 # 候选对生成规则同人物、同金额、同时间字段的优先 candidates generate_candidate_pairs(chunks) results [] for a, b in candidates[:200]: # 控制调用量 out call_deepseek(prompt.format(chunk_aa, chunk_bb)) results.append(json.loads(out))generate_candidate_pairs的规则决定了关联的召回率。我的候选生成策略是先从抽出的字段里找「同名、同号、同金额、同日期」的硬匹配再辅以向量相似度 0.75 以上的软匹配。硬匹配基本不遗漏资金类关联软匹配负责抓「同一个地点、同一种说辞」这类语义关联。confidence 低于 0.6 的关联对通常会进「待核验」池留给法律专业人员二次确认模型如果给不出确证就别让它在最终报告里出现。4. 证据链漏洞识别让逻辑推理找到断裂点4.1 漏洞类型先定义清楚模型才不会乱找「漏洞」这个词太抽象模型不知道你在找什么。做识别前先把证据链漏洞拆成可枚举的类型。按我的经验诉讼和合规场景里最常见的五类就是时间断裂关键行为没有对应的时间凭证、来源单一关键事实只有孤证没有旁证、逻辑跳跃从现有证据推不出结论中间缺一环、数量不一致合同金额、付款金额、发票金额对不上、形式瑕疵复印件替代原件、缺少签章、电子数据没有提取记录。定义越细识别准度越高。我通常把这些定义直接写进 System Prompt让 DeepSeek 按类型框定搜索范围避免它把「法律风险评估」也当成漏洞输出。另外一个关键习惯让模型每条漏洞结论都引用证据原文编号没有编号的结论一律丢弃。这一步能过滤掉相当多幻觉输出。4.2 推理提示词的结构任务、口径、输出 schema证据链漏洞识别最考验的是提示词结构。我的结构固定为三段任务限定、类型定义、输出格式约束。任务限定告诉模型它只做证据链漏洞分析类型定义把五类漏洞逐条解释并给出正反例输出格式给一个严格的 JSON Schema 模板。system_content 你是证据链审查助手。只做一件事从给定证据段落中识别证据链漏洞。 可识别的漏洞类型仅限time_gap, single_source, logic_jump, amount_mismatch, form_defect。 每一条漏洞结论必须包含 evidence_id 列表和原文摘录。 禁止输出不属于上述五类的结论。 user_content 证据目录及内容如下 {evidence_context} 请查找证据链漏洞输出 JSON { gaps: [ { gap_type: time_gap, evidence_ids: [ev_012], quoted_text: 原文摘录, reason: 这个时间点缺少对应凭证无法确认行为发生时间, suggestion: 补充2024年3月银行流水或行程记录 } ] } 注意suggestion是可选但必须合理的字段模型给出的补全建议越具体后续人工核验的效率越高。reason 字段要写「缺什么、为什么缺」不能写「不确定」。实际跑下来限定五类漏洞之后误报率显著下降——模型在开放式任务里什么都能给你挑出「问题」锁死类型口径后反而收敛多了。4.3 输出校验与漏洞定位让每个结论都能回溯模型输出的 JSON 不能直接用先要过一道校验脚本。校验两件事引用的 evidence_id 是否真实存在quoted_text 是否能在对应证据原文里找到。找不到就丢弃或降级为「待核验」。# 校验输出中的 evidence_id 与原文摘录 import json result json.loads(model_output) valid_gaps [] for gap in result[gaps]: ids_ok all(eid in chunk_id_set for eid in gap[evidence_ids]) # 简化校验摘录内容必须包含在对应证据原文中 text_ok all( gap[quoted_text][:20] in chunks[eid][content] for eid in gap[evidence_ids] ) if ids_ok and text_ok: valid_gaps.append(gap) else: print(f丢弃无效结论: {gap.get(gap_type)} fids_ok{ids_ok} text_ok{text_ok})证据 ID 不是模型自己想出来的编号而是第 3 章切分时落在chunks.jsonl里的ev_xxx。校验脚本把模型输出的 ID 和原文 ID 双向核对原文摘录也按前 20 个字符做包含匹配。这个 20 字规则够用因为 evidence chunk 最短也有几十字太短的摘录说明模型没在「读」证据只是在编。5. 避坑证据项目最容易翻车的 5 个环节5.1 模型「一本正经」地编造证据编号现象模型输出的evidence_ids指向一份完全不存在于证据目录的材料引用的「原文」在全部 364 页里找不到。原因上下文过长导致模型丢失了前文证据编号的映射关系也可能源于训练数据里相似案例的「记忆」。推理模型在长上下文中特别容易串号。解决给每个证据片段一个极简且唯一的编号体系如ev_045并在每次送入模型前把编号和证据抬头列成索引表让模型「看着索引回答问题」。同时跑完一轮后用 4.3 的校验脚本强制过滤拿不到 ID 匹配的结论直接丢弃不进入正式报告。5.2 归类结果互相打架同一证据被拆进三个类别现象同一份银行流水在「资金往来」「合同履行」「借贷关系」三个类别里各出现一次导致后续关联分析翻倍膨胀。原因向量聚类的边界是浮动的0.75 阈值的簇边缘发生交叉覆盖DeepSeek 语义打标阶段又把「同一份文本在不同上下文中的侧重」当成了「不同类别」的证据。解决归类阶段切断上下文影响——每个证据片段只送一次模型禁止让模型同时参考其他证据来给当前证据定类。聚类阶段全局只跑一次不允许用「再聚一轮」来修正第一轮的结果。跑完两轮后人工抽查 20 条归类边界样本用 20 条的准确率决定是否调整相似度阈值而不是凭感觉改。5.3 长文档截断导致关键时间点丢失现象识别出的漏洞里反复出现「时间缺失」但人工核查发现时间记录明明在后半段材料里。原因PDF 切出来的文本超过模型的上下文窗口被静默截断了。尤其是最后几节和附录里的补充协议经常被截得七零八落。解决切分前先做全文档字符数统计超过模型单次窗口的按卷分拆而不是硬塞。给每份长证据做卷内摘要把摘要和全文分开送——摘要用来建立时间线全文用来做深度推理两者用卷号关联。跑完漏洞识别后单独做一轮「时间要素回查」把模型报出的时间断裂点和全文索引一一比对。5.4 输出 JSON 结构漂移现象response_format明明设了json_object模型偶尔还是返回夹杂解释性文字的 JSON甚至字段名从gap_type变成gapType。原因模型在极端长输出或超长上下文的末端格式保持能力下降。解决两次而不是一次机会。第一次解析失败时把原始输出原样送回给模型附一句「严格按这个 JSON Schema 重写不要加解释」。实测一次纠错能救回约 70% 的漂移输出第二次再失败就丢弃因为就算解析成功内容可信度也存疑。解析代码用json.loads包一层 try-except并在异常时自动触发重试逻辑不要在人工环节处理可自动恢复的异常。5.5 漏洞「漏报」比「误报」更致命现象识别结果里没有报出金额矛盾但人工核对时发现合同金额和付款金额差了两千块。原因单轮推理的覆盖是有限的模型倾向于报它「看得顺眼」的漏洞比如时间断裂这种一眼能看出来的金额不一致这类需要跨三份材料对齐比对的单轮调用常常漏。解决把漏洞识别拆成两轮第一轮做全局扫描第二轮做专项比对。专项比对的输入不是全部证据而是已经归入「合同」「付款」「发票」三个类别的材料让模型专门找金额、日期、主体不一致。专项比对的漏报率比全局扫描低很多代价是多一次调用。两条输出合并去重后再进入人工复核环节。6. 用反向核对给补全建议上保险再落回证据目录6.1 补全建议的置信度分级补全建议不能全量推给业务人员。按置信度分级处理高置信度的直接列表低置信度的归入待议项。判定标准我一般看三个建议引用的证据数量是否大于等于 2是否指明具体材料类型而不是写「补充相关材料」建议所依托的证据与建议之间的逻辑距离是否超过一步。置信度判定条件处理方式强建议引用 ≥2 份证据给出具体补充材料类型逻辑距离 ≤1直接写入补全清单标注优先级中等建议引用 ≥1 份证据或材料类型明确作为备选项附人工复核备注弱建议引用 0 份证据仅属推理方向单独留档不进正式清单这个表是从几十个证据项目里沉淀出来的。强建议类的典型例子是「2024年3月14日付款记录缺失可调取对应用款审批单或银行流水」它引用付款凭证和审批单两份现有证据逻辑距离只有一步。弱建议典型的则是「建议查一下相关人员的关系」没有落地材料指向的东西只能作为线索留着。6.2 用反向核对脚本做最终检验并在结论质量上收口补全清单出来之后我习惯加一道反向核对把建议清单打回给模型让它判断「如果这些材料全部补齐证据链是否能闭合」。这一步很便宜却能拦截不少自相矛盾的建议。# 反向核对补全后证据链是否闭合 validation_prompt 以下是一份证据链漏洞清单及其补全建议。 请逐条判断 1. 补全建议是否覆盖了漏洞指向的材料缺失 2. 建议补入的材料类型是否现实可获取 3. 补全后原先断裂的逻辑是否能形成闭环 输出 JSON { validation: [ { gap_id: 1, is_closed: true, note: 补入银行流水后付款时间可确认 } ] } 反向核对的意义在于防止「为补而补」——有些缺失材料根本不存在或者获取成本远高于证明价值这类建议就不该给。我做过的项目里大约有三成补全建议会在反向核对阶段被降级或撤销理由集中在「现有证据已足够推导」和「所建议材料现实中无法取得」。这轮验证做完再把清单按优先级写回证据目录表格里标注哪些是模型建议、哪些待人工确认。做这类项目久了我养成了一个习惯永远把模型输出的最终稿当草稿先问一句「如果我是对方律师我会从哪条断裂点攻击这条证据链」然后顺着这个角度再查一遍。漏洞识别工具解决的是「有没有漏看」而反向核对解决的是「建议完不完得成闭环」。两者的关系像是先放大镜再查一遍底稿缺哪个环节都会在后面翻车。希望这套方案能帮你在下一份证据材料上少照几次灯、多省几宿——至少能让你把时间花在真正需要经验判断的地方而不是重复翻卷。本文还有配套的精品资源点击获取 基于DeepSeek的证据链智能梳理与漏洞识别实战指南
简介一份面向司法领域技术人员与AI研究者的DeepSeek证据链智能分析完整方案手册。PDF共364页、52个大章节系统覆盖证据自动归类、语义特征提取、多标签分类模型、注意力机制、实体关系抽取、知识图谱构建、关联权重计算及证据链漏洞识别等核心环节章节兼顾算法原理与工程实现细节。文档为1个PDF文件压缩包共12.76MB支持目录章节跳转与左侧书签大纲快速定位内容完整、表格与图示显示正常。已有90人学习下载。从证据数据采集预处理、非结构化文本向量化到命名实体识别微调、知识图谱存储与时序建模再到置信度评估与阈值判定逻辑整份方案可帮助读者系统搭建司法证据智能处理流程也可作为大模型逻辑推理应用落地的技术参考。1. 证据链这项工作卡在「读完到用上」之间的那一公里拿到 364 页证据材料传统做法是团队坐在一起分卷、贴标签、画时间轴动辄一周。真正让证据梳理变慢的往往不是「读不完」而是「读完了却对不上」——同一笔转账在第三卷出现过银行流水和合同日期相差两天证人说的时间点和聊天记录对不上。DeepSeek 做证据材料智能梳理与证据链漏洞识别这件事核心不是靠全文检索而是靠逻辑推理把几百页零散材料重组成一条可被质证的时间线。这篇笔记写给做诉讼准备、企业合规调查、证据目录管理的从业者把环境搭建、归类关联、漏洞识别和补全建议这几步拆开讲清楚每步给出能复现的参数和代码。2. DeepSeek 落地选型本地部署还是 API两条路各自卡在哪2.1 两条运行路径的取舍本地部署与 API 调用证据材料通常涉密或敏感不能直接往外送。所以第一步不是调参是先定运行路径。常见做法是两条路二选一内网环境用 vLLM 本地部署 DeepSeek机器性能不足或项目周期紧就走 API 调用。本地部署的好处是数据不出域Prompt 里可以放心塞证据正文坏处是显存和并发要自己扛。一个三百多页 PDF 切出来大概是百万级 token 规模逐章推理时并发不高但上下文很长我一般至少准备两块 24G 显存跑量化版边缘设备例如 Jetson Orin 这类也能跑小尺寸模型做初步抽提效果会比x86 服务器差一些。API 调用则省去硬件但要自己做请求管理和成本控制。DeepSeek 的价格按 token 计费证据梳理涉及大量重复归类与关联判断每一页都会被多次送入模型跑完全量材料再乘上调用次数账单才会体现出差距。我的建议是能确定运行环境之前先在 API 上用小样本跑通 prompt确认输出格式稳定再决定要不要迁移到本地。方向没问题但成本失控的项目多半是死在「所有证据反复全量送入模型」这一步后面会讲怎么用归类和抽提减少无效调用。2.2 推理参数与输出约束把「脑洞」关进证据的笼子不论本地还是 API证据类任务对生成参数的要求都比通用对话严。核心是温度自动归类任务我固定在 0.1~0.2保证相同语义的证据每次归类结果一致漏洞识别任务可以放宽到 0.3~0.5因为需要模型适当发散找矛盾点但不能超过 0.5否则模型会把「可能有关」写成「一定有关」。Max tokens 要按输出结构设定归类结果输出 JSON 时我限制在 1024 以内识别漏洞并附理由时会放到 2048。输出约束比温度更关键。证据场景最怕模型自由发挥所以我在所有请求里强制 JSON Object 输出并固定字段名。一个标准的归类请求长这样import requests payload { model: deepseek-chat, messages: [ { role: system, content: 你是证据管理助手。只输出 JSON不要输出任何解释。, }, { role: user, content: 证据内容李四于2024年3月14日向王五转账人民币5万元整附言项目预付款。, }, ], response_format: {type: json_object}, temperature: 0.1, max_tokens: 1024, top_p: 0.7, } resp requests.post( https://api.deepseek.com/chat/completions, headers{Authorization: Bearer YOUR_API_KEY}, jsonpayload, ) print(resp.json()[choices][0][message][content])关键在response_format和temperature两个参数。response_format锁死输出为结构化 JSON后续代码才能稳定解析temperature压到 0.1 是为了归类可复现——同样的证据第二次跑不能变类别。top_p配合 temperature 使用0.7 是一个兼顾稳定性和少量多样性的常用值。如果你走本地 vLLM 部署OpenAI 兼容接口参数相同只需把 URL 换成内网服务地址。3. 证据自动归类与关联分析把散落证据拼成关系网3.1 预处理的切分与标注先给证据上「户口」再聪明的模型也架不住一页 PDF 里挤十种内容。做归类之前先把 364 页拆成最小证据单元。常见做法是按证据编号切每份证据从「证据一、」到「证据二、」之间划一刀切出来的段落保留页号、编号和标题。切分代码不复杂但边界条件很折磨人——有的材料没有编号只有扫描件的页眉这时候就只能按页码切再让模型给每页打标签。这里我一般用两步先按规则切再用模型兜底修正。import re import json text open(evidence.txt, encodingutf-8).read() # 按常见证据编号格式切分 parts re.split(r(?证据[一二三四五六七八九十][、.]), text) chunks [] for i, part in enumerate(parts): part part.strip() if len(part) 20: continue # 提取开头的证据编号作为 id first_line part.split(\n, 1)[0] chunk { id: fev_{i:03d}, header: first_line.strip(), page_range: fp{max(i - 1, 0)}-p{i 1}, content: part, } chunks.append(chunk) with open(chunks.jsonl, w, encodingutf-8) as f: for c in chunks: f.write(json.dumps(c, ensure_asciiFalse) \n) print(f切分出 {len(chunks)} 个证据片段)这段代码把一整块文本按「证据N、」这个标记切分并把每个片段记录为独立的 JSON 行。(?...)是正则的前瞻匹配切分时保留证据编号本身不被吞掉。page_range是按片段索引估算的页码真正做文书校验时还要和原始 PDF 的页码对齐。切分粒度决定了后续所有步骤的上限宁可多切一刀也不要把两份证据粘在一起送进模型。3.2 自动归类语义相似度 层次聚类的组合切分完就该归类了。一开始我以为让 DeepSeek 直接输出类别就行实际跑下来发现不稳定同一份转账记录上一轮归到「资金往来」下一轮变成「合同履行」。所以要分两层先用文本向量做粗聚类再用 DeepSeek 给每个簇打业务标签。向量聚类抓的是文本相似DeepSeek 抓的是语义类别两相结合归类才稳定。向量化可以选择本地 embedding 模型也可以直接调 DeepSeek 的 embedding 接口。拿到向量之后算两两相似度这步用 sklearn 就能做import numpy as np from sklearn.cluster import AgglomerativeClustering from sklearn.metrics.pairwise import cosine_similarity # vectors 是每个证据片段的 embeddingshape (n_chunks, dim) sim cosine_similarity(vectors) # 相似度高于 0.85 视为强关联用于聚类 cluster AgglomerativeClustering( n_clustersNone, distance_threshold0.35, metriceuclidean, linkageaverage, ) labels cluster.fit_predict(1 - sim) for idx, label in enumerate(labels): print(f{chunks[idx][id]} - cluster {label})距离阈值 0.35 对应余弦相似度约 0.75 的归并线。这个数值不是玄学是多次跑出来的经验值低于 0.75 聚进来的大多是泛泛相关高于 0.85 则同一事件的不同侧面会被拆成一堆碎片。跑完聚类后把每个簇的文本并到一起发给 DeepSeek 一句话总结类别名称比如「施工合同付款记录」「2023年6月微信聊天记录」。这样类目名称是模型给的但归类边界是向量定的后者比前者可靠得多。3.3 关联分析共同要素匹配与证据-待证事实映射归好类之后要做的是关联分析。证据链不是「所有证据列表」而是「谁和谁共同支持哪个待证事实」。常规做法是从证据文本里抽结构化字段再按字段做匹配同一转账金额在不同证据中重复出现、同一人物身份证号横跨多份材料、同一时间点出现在银行流水和聊天记录中这些都是强关联信号。我一般会在归类基础上再用 DeepSeek 做一轮「关联对」抽取。输出用固定的 JSON Schema每条记录包含两个证据 ID 和关联类型prompt 请分析下面两份证据之间的关系。 输出 JSON格式为 { rel_type: 补强|矛盾|时间衔接|无关联|待核验, reason: 说明判断依据不超过50字, confidence: 0.0-1.0 } 证据A{chunk_a} 证据B{chunk_b} # 对同一个簇内或跨簇候选对批量调用 # 候选对生成规则同人物、同金额、同时间字段的优先 candidates generate_candidate_pairs(chunks) results [] for a, b in candidates[:200]: # 控制调用量 out call_deepseek(prompt.format(chunk_aa, chunk_bb)) results.append(json.loads(out))generate_candidate_pairs的规则决定了关联的召回率。我的候选生成策略是先从抽出的字段里找「同名、同号、同金额、同日期」的硬匹配再辅以向量相似度 0.75 以上的软匹配。硬匹配基本不遗漏资金类关联软匹配负责抓「同一个地点、同一种说辞」这类语义关联。confidence 低于 0.6 的关联对通常会进「待核验」池留给法律专业人员二次确认模型如果给不出确证就别让它在最终报告里出现。4. 证据链漏洞识别让逻辑推理找到断裂点4.1 漏洞类型先定义清楚模型才不会乱找「漏洞」这个词太抽象模型不知道你在找什么。做识别前先把证据链漏洞拆成可枚举的类型。按我的经验诉讼和合规场景里最常见的五类就是时间断裂关键行为没有对应的时间凭证、来源单一关键事实只有孤证没有旁证、逻辑跳跃从现有证据推不出结论中间缺一环、数量不一致合同金额、付款金额、发票金额对不上、形式瑕疵复印件替代原件、缺少签章、电子数据没有提取记录。定义越细识别准度越高。我通常把这些定义直接写进 System Prompt让 DeepSeek 按类型框定搜索范围避免它把「法律风险评估」也当成漏洞输出。另外一个关键习惯让模型每条漏洞结论都引用证据原文编号没有编号的结论一律丢弃。这一步能过滤掉相当多幻觉输出。4.2 推理提示词的结构任务、口径、输出 schema证据链漏洞识别最考验的是提示词结构。我的结构固定为三段任务限定、类型定义、输出格式约束。任务限定告诉模型它只做证据链漏洞分析类型定义把五类漏洞逐条解释并给出正反例输出格式给一个严格的 JSON Schema 模板。system_content 你是证据链审查助手。只做一件事从给定证据段落中识别证据链漏洞。 可识别的漏洞类型仅限time_gap, single_source, logic_jump, amount_mismatch, form_defect。 每一条漏洞结论必须包含 evidence_id 列表和原文摘录。 禁止输出不属于上述五类的结论。 user_content 证据目录及内容如下 {evidence_context} 请查找证据链漏洞输出 JSON { gaps: [ { gap_type: time_gap, evidence_ids: [ev_012], quoted_text: 原文摘录, reason: 这个时间点缺少对应凭证无法确认行为发生时间, suggestion: 补充2024年3月银行流水或行程记录 } ] } 注意suggestion是可选但必须合理的字段模型给出的补全建议越具体后续人工核验的效率越高。reason 字段要写「缺什么、为什么缺」不能写「不确定」。实际跑下来限定五类漏洞之后误报率显著下降——模型在开放式任务里什么都能给你挑出「问题」锁死类型口径后反而收敛多了。4.3 输出校验与漏洞定位让每个结论都能回溯模型输出的 JSON 不能直接用先要过一道校验脚本。校验两件事引用的 evidence_id 是否真实存在quoted_text 是否能在对应证据原文里找到。找不到就丢弃或降级为「待核验」。# 校验输出中的 evidence_id 与原文摘录 import json result json.loads(model_output) valid_gaps [] for gap in result[gaps]: ids_ok all(eid in chunk_id_set for eid in gap[evidence_ids]) # 简化校验摘录内容必须包含在对应证据原文中 text_ok all( gap[quoted_text][:20] in chunks[eid][content] for eid in gap[evidence_ids] ) if ids_ok and text_ok: valid_gaps.append(gap) else: print(f丢弃无效结论: {gap.get(gap_type)} fids_ok{ids_ok} text_ok{text_ok})证据 ID 不是模型自己想出来的编号而是第 3 章切分时落在chunks.jsonl里的ev_xxx。校验脚本把模型输出的 ID 和原文 ID 双向核对原文摘录也按前 20 个字符做包含匹配。这个 20 字规则够用因为 evidence chunk 最短也有几十字太短的摘录说明模型没在「读」证据只是在编。5. 避坑证据项目最容易翻车的 5 个环节5.1 模型「一本正经」地编造证据编号现象模型输出的evidence_ids指向一份完全不存在于证据目录的材料引用的「原文」在全部 364 页里找不到。原因上下文过长导致模型丢失了前文证据编号的映射关系也可能源于训练数据里相似案例的「记忆」。推理模型在长上下文中特别容易串号。解决给每个证据片段一个极简且唯一的编号体系如ev_045并在每次送入模型前把编号和证据抬头列成索引表让模型「看着索引回答问题」。同时跑完一轮后用 4.3 的校验脚本强制过滤拿不到 ID 匹配的结论直接丢弃不进入正式报告。5.2 归类结果互相打架同一证据被拆进三个类别现象同一份银行流水在「资金往来」「合同履行」「借贷关系」三个类别里各出现一次导致后续关联分析翻倍膨胀。原因向量聚类的边界是浮动的0.75 阈值的簇边缘发生交叉覆盖DeepSeek 语义打标阶段又把「同一份文本在不同上下文中的侧重」当成了「不同类别」的证据。解决归类阶段切断上下文影响——每个证据片段只送一次模型禁止让模型同时参考其他证据来给当前证据定类。聚类阶段全局只跑一次不允许用「再聚一轮」来修正第一轮的结果。跑完两轮后人工抽查 20 条归类边界样本用 20 条的准确率决定是否调整相似度阈值而不是凭感觉改。5.3 长文档截断导致关键时间点丢失现象识别出的漏洞里反复出现「时间缺失」但人工核查发现时间记录明明在后半段材料里。原因PDF 切出来的文本超过模型的上下文窗口被静默截断了。尤其是最后几节和附录里的补充协议经常被截得七零八落。解决切分前先做全文档字符数统计超过模型单次窗口的按卷分拆而不是硬塞。给每份长证据做卷内摘要把摘要和全文分开送——摘要用来建立时间线全文用来做深度推理两者用卷号关联。跑完漏洞识别后单独做一轮「时间要素回查」把模型报出的时间断裂点和全文索引一一比对。5.4 输出 JSON 结构漂移现象response_format明明设了json_object模型偶尔还是返回夹杂解释性文字的 JSON甚至字段名从gap_type变成gapType。原因模型在极端长输出或超长上下文的末端格式保持能力下降。解决两次而不是一次机会。第一次解析失败时把原始输出原样送回给模型附一句「严格按这个 JSON Schema 重写不要加解释」。实测一次纠错能救回约 70% 的漂移输出第二次再失败就丢弃因为就算解析成功内容可信度也存疑。解析代码用json.loads包一层 try-except并在异常时自动触发重试逻辑不要在人工环节处理可自动恢复的异常。5.5 漏洞「漏报」比「误报」更致命现象识别结果里没有报出金额矛盾但人工核对时发现合同金额和付款金额差了两千块。原因单轮推理的覆盖是有限的模型倾向于报它「看得顺眼」的漏洞比如时间断裂这种一眼能看出来的金额不一致这类需要跨三份材料对齐比对的单轮调用常常漏。解决把漏洞识别拆成两轮第一轮做全局扫描第二轮做专项比对。专项比对的输入不是全部证据而是已经归入「合同」「付款」「发票」三个类别的材料让模型专门找金额、日期、主体不一致。专项比对的漏报率比全局扫描低很多代价是多一次调用。两条输出合并去重后再进入人工复核环节。6. 用反向核对给补全建议上保险再落回证据目录6.1 补全建议的置信度分级补全建议不能全量推给业务人员。按置信度分级处理高置信度的直接列表低置信度的归入待议项。判定标准我一般看三个建议引用的证据数量是否大于等于 2是否指明具体材料类型而不是写「补充相关材料」建议所依托的证据与建议之间的逻辑距离是否超过一步。置信度判定条件处理方式强建议引用 ≥2 份证据给出具体补充材料类型逻辑距离 ≤1直接写入补全清单标注优先级中等建议引用 ≥1 份证据或材料类型明确作为备选项附人工复核备注弱建议引用 0 份证据仅属推理方向单独留档不进正式清单这个表是从几十个证据项目里沉淀出来的。强建议类的典型例子是「2024年3月14日付款记录缺失可调取对应用款审批单或银行流水」它引用付款凭证和审批单两份现有证据逻辑距离只有一步。弱建议典型的则是「建议查一下相关人员的关系」没有落地材料指向的东西只能作为线索留着。6.2 用反向核对脚本做最终检验并在结论质量上收口补全清单出来之后我习惯加一道反向核对把建议清单打回给模型让它判断「如果这些材料全部补齐证据链是否能闭合」。这一步很便宜却能拦截不少自相矛盾的建议。# 反向核对补全后证据链是否闭合 validation_prompt 以下是一份证据链漏洞清单及其补全建议。 请逐条判断 1. 补全建议是否覆盖了漏洞指向的材料缺失 2. 建议补入的材料类型是否现实可获取 3. 补全后原先断裂的逻辑是否能形成闭环 输出 JSON { validation: [ { gap_id: 1, is_closed: true, note: 补入银行流水后付款时间可确认 } ] } 反向核对的意义在于防止「为补而补」——有些缺失材料根本不存在或者获取成本远高于证明价值这类建议就不该给。我做过的项目里大约有三成补全建议会在反向核对阶段被降级或撤销理由集中在「现有证据已足够推导」和「所建议材料现实中无法取得」。这轮验证做完再把清单按优先级写回证据目录表格里标注哪些是模型建议、哪些待人工确认。做这类项目久了我养成了一个习惯永远把模型输出的最终稿当草稿先问一句「如果我是对方律师我会从哪条断裂点攻击这条证据链」然后顺着这个角度再查一遍。漏洞识别工具解决的是「有没有漏看」而反向核对解决的是「建议完不完得成闭环」。两者的关系像是先放大镜再查一遍底稿缺哪个环节都会在后面翻车。希望这套方案能帮你在下一份证据材料上少照几次灯、多省几宿——至少能让你把时间花在真正需要经验判断的地方而不是重复翻卷。本文还有配套的精品资源点击获取