教程 11: Litigation Support & E-Discovery
Master AI-assisted discovery document review, deposition analysis, ESI management, cross-examination preparation, and case timeline creation for litigation
覆盖Claude: 已验证ChatGPT / Codex: 草稿Grok Bot: 草稿
本教程将带你使用 AI 助手完成 AI 辅助诉讼与电子证据开示工作流。你将学习证据开示文件审查、证言笔录分析、特权审查以及案件时间线创建——全部通过一条清晰、循序渐进的路径完成。
Claude 中的主要工作流: 在一个 matter Project(教程 04)中运行下列提示;如有可用的 Legal plugin command,则使用该命令(教程 06);并通过 MCP 连接研究连接器(教程 07)。在输出中明确保留特权与升级处理检查点。
高级级别 | 90 分钟 | 需要一定技术熟悉度
学习目标
完成本教程后,你将能够:
- 掌握 AI 辅助的证据开示文件审查与编码
- 理解电子存储信息(ESI)管理工作流
- 学会高效提取和分析证言笔录
- 根据证词模式生成有针对性的交叉询问问题
- 从文件集合中创建完整的案件时间线
- 对证人陈述进行不一致性分析
- 在诉讼过程中执行高级证据搜索与检索
- 在 AI 辅助下管理特权审查
- 构建响应性文件编码工作流
- 可视化电子邮件与通信线程
- 执行自然语言证据开示查询
- 识别有助于案件策略的文件聚类模式
第 1 部分:证据开示文件审查工作流
规模挑战
传统审查与 AI 辅助审查的速度会因案件类型、 文件质量、工作流设计和 QC 标准而有显著差异。 应将吞吐量假设视为需要在内部验证的试点指标。
AI 辅助审查的关键步骤
步骤 1:定义文件类别
在上传之前,先确定你的审查类别:
步骤 2:上传样本集
先从 100-200 份文件开始,以建立模式:
步骤 3:构建编码模板
助手会生成一致的编码判断:
务必在上传文件之前建立编码协议。中途变更标准会导致审查工作不一致,且容易受到质疑。
实操练习 1.1:建立你的审查协议
创建你的审查协议:
第 2 部分:电子存储信息(ESI)管理
ESI 基础
电子存储信息包括:
- 电子邮件及附件
- Word 文档和电子表格
- 数据库和结构化数据
- 元数据(创建日期、作者、编辑历史)
- 移动设备数据
- 备份磁带
- 云存储
批量标记工作流
阶段 1:去重
阶段 2:保管人识别
将文件映射到其来源:
阶段 3:批量标记
应用一致的元数据:
实操练习 2.1:ESI 保全方案
第 3 部分:证言笔录分析
分析证词模式
步骤 1:主题提取
步骤 2:识别不一致
步骤 3:构建叙事
构建证人的故事:
务必将证言笔录与文件及其他证人陈述交叉比对。不一致之处往往是弹劾的机会。
实操练习 3.1:完整笔录分析
第 4 部分:交叉询问问题生成
根据证词模式构建问题
步骤 1:识别脆弱点
步骤 2:起草问题
步骤 3:按主题组织
实操练习 4.1:问题生成
第 5 部分:案件时间线创建
提取事件与日期
步骤 1:识别所有日期
步骤 2:构建时间线
步骤 3:战略时间线
实操练习 5.1:基于混合来源创建时间线
第 6 部分:证人陈述分析
识别不一致与证据
步骤 1:提取证人陈述
步骤 2:与证据交叉比对
步骤 3:可信度评估
实操练习 6.1:陈述分析
第 7 部分:证据搜索与检索
快速定位证据
步骤 1:建立搜索协议
步骤 2:庭前询问过程中的快速搜索
步骤 3:听证会/审判证据
实操练习 7.1:证据搜索工作流
第 8 部分:特权审查与识别
识别受保护通信
步骤 1:特权类别
步骤 2:元数据审查
步骤 3:特权日志
应倾向于将更多项目标记给律师审查。多审查 200 份边缘文件,也比漏掉 1 份特权文件并导致特权丧失要好。
实操练习 8.1:特权审查协议
第 9 部分:响应性文件编码工作流
构建编码系统
步骤 1:定义响应性
步骤 2:构建编码表单
步骤 3:质量控制审计
实操练习 9.1:响应性编码系统
第 10 部分:电子邮件线程可视化与分析
理解电子邮件通信模式
步骤 1:提取线程
步骤 2:线程分析
步骤 3:通信模式分析
实操练习 10.1:电子邮件线程分析
第 11 部分:自然语言证据开示查询
对话式证据搜索
步骤 1:Plain English 查询
不用写:(defect OR flaw OR malfunction) AND (safety OR hazard OR risk) NOT (competitor OR comparison)
现在你可以这样提问:
步骤 2:复杂多因素查询
步骤 3:条件式证据开示查询
实操练习 11.1:自然语言查询
第 12 部分:文件聚类与模式识别
在大型文件集里发现隐藏模式
步骤 1:自动聚类
步骤 2:按主题组织
步骤 3:支持专家报告
实操练习 12.1:文件聚类分析
比较:通用助手 vs. 企业级电子证据开示工具
| Feature | General assistant + MCP | Harvey | Legora | Relativity | Everlaw |
|---|---|---|---|---|---|
| Document Review Speed | 因工作流和 QC 而异 | 因工作流和 QC 而异 | 因工作流和 QC 而异 | 因工作流和 QC 而异 | 因工作流和 QC 而异 |
| Setup Time | 可快速试点;生产环境取决于治理/集成 | 由供应商实施的时间线 | 由供应商实施的时间线 | 平台 + 工作流实施 | 平台 + 工作流实施 |
| Cost | 按报价 + 实施投入 | 按报价 | 按报价 | 按报价 | 按报价 |
| Customization | 完全 | 有限 | 有限 | 广泛 | 中等 |
| ESI Integration | 通过 MCP/connectors 和内部工具 | 供应商 connectors/workflows | 供应商 connectors/workflows | 平台 connectors/workflows | 平台 connectors/workflows |
| Timeline Creation | 手动 + AI | 自动化 | 自动化 | 手动 | 自动化 |
| Email Threading | 基础 | 高级 | 高级 | 高级 | 高级 |
| Privilege Review | AI 辅助 | AI + 手动 | AI + 手动 | 主要手动 | AI 辅助 |
| Responsive Coding | 可配置 | 预设 | 预设 | 可定制 | 预设 |
| Evidence Search | 自然语言 | 基于字段 | 基于字段 | Boolean/semantic | Semantic |
| Expert Integration | 直接 | API | API | 广泛 | 中等 |
| Learning Curve | 极低 | 陡峭 | 中等 | 陡峭 | 中等 |
AI 辅助诉讼支持的最佳实践
应该做的事
-
务必先建立协议
- 在上传文件前先定义类别与规则
- 以书面形式制定编码指南
- 先用样本文件测试
- 提前建立 QC 程序
-
务必记录你的流程
- 保留以下记录:
- 已定义的审查类别
- 使用的搜索词
- 已上传的文件
- 作出的编码决定
- 已执行的 QC 程序
- 这会为对方就证据开示流程提出异议时提供审计轨迹
- 保留以下记录:
-
务必使用多种验证方法
- 不要仅依赖 AI
- 对关键文件进行人工交叉复核
- 使用 QC 样本(5-10% 复审)
- 由律师抽查工作成果
-
务必保持特权警觉
- 倾向于为律师审查多做标记(多审 200 份边缘文件,也比漏掉 1 份特权文件要好)
- 创建清晰的特权日志
- 不要因披露而放弃特权
- 考虑设立独立的特权审查团队
-
务必善用时间线功能
- 尽早创建时间线(有助于指导证据开示策略)
- 发现新文件后更新时间线
- 用于证言准备
- 用于庭审展示
-
务必按审判需求组织材料
- 在对文件编码时同步建立证据清单
- 创建按文件组织的庭审摘要章节
- 将证词与证物关联
- 为庭审创建快速访问搜索系统
需要避免的常见错误
不要做这些事
-
不要跳过协议阶段
- 在没有明确规则的情况下开始编码
- 在审查过程中途更改规则
- 让不同法务助理采用不同标准
- 结果:编码不一致,容易受到质疑
-
不要假设准确率是 100%
- AI 可能漏掉文件中的细微差别
- 可能误分类技术性语言
- 可能误解上下文
- 解决方案:始终加入 QC 抽查
-
不要忽视元数据问题
- 元数据可能成为证据毁损的证据
- 不要修改文件日期或属性
- 保留完整审计轨迹
- 记录是谁审查/编码了每份文件
-
不要生成可被开示的律师笔记
- 不要要求 AI 分析“strategy”
- 不要与 AI 讨论“case weaknesses”
- 不要使用 AI 创建律师 work product
- 请记住:某些 AI 助手对话可能不受特权保护
-
不要忽视证言冲突
- 将最终证词与先前陈述进行比较
- 不要漏掉“我不记得”之类的回答
- 不要忽视视频中的神态表现
- 在交叉询问中检验不一致之处
-
不要忽略特权日志
- 不完整的特权日志可能导致特权丧失
- 必须描述每一份被扣留文件
- 必须说明主张特权的依据
- 应同步创建日志(而不是事后补做)
记录所有 AI 辅助审查程序。对方律师可能会质疑你的证据开示流程。清晰记录你的 QC 程序至关重要。
电子证据开示质量控制清单
审查前 QC
- 审查协议已记录并获批准
- 样本文件已编码并验证
- 所有审查人员已接受协议培训
- 搜索词已测试并验证
- 已识别 ESI 保管人和数据来源
- 已完成去重
- 元数据已保留
审查中 QC
- 每周对已编码文件进行抽查(每位审查员 5 份)
- 每月跨审查员进行一致性复核
- 所有“边缘”文件均由律师签核
- 特权标记由律师审查
- 时间线已与文件交叉核对
- 响应性编码已对照 RFPs 验证
审查后 QC
- 已复核最终 5% 的质量保证样本
- 特权日志完整且准确
- 响应性文件已按 RFP 组织
- 时间线已最终定稿并交叉核对
- 电子邮件线程已核实完整
- 专家 designation 已标记
- 庭审证物已识别并整理
- 证言片段已指定
诉讼管理 QC
- 证据开示答复符合期限要求
- 已在适当情况下提出异议
- 特权已被正确主张
- 文件出示格式正确
- Bates 标记一致
- 特权日志已随出示材料交付
- 与对方律师的沟通已记录
实务工作流:真实案件场景
场景 1:产品责任——6 个月时间线
第 1 个月:初始设置
- 定义审查类别
- 确定 20 个关键 RFPs
- 创建搜索词库
- 为 6 名保管人设置 ESI 收集
- 估算文件量(可能为 50,000-100,000)
第 2 个月:首轮审查
- 去重和 ESI 处理
- 运行第一轮搜索查询
- 批量编码响应性文件(约占全集的 80%)
- 构建初步时间线
- 识别关键参与者和主题
第 3 个月:特权与边缘文件
- 对已标记项目进行特权审查
- 律师审查边缘响应性文件
- 完成最终响应性编码
- 建立完整特权日志
- 最终确定证言安排
第 4 个月:时间线与电子邮件分析
- 完成案件时间线(所有日期、所有当事方)
- 对关键通信进行电子邮件线程分析
- 准备证言材料
- 初步证人陈述分析
- 组织专家文件
第 5 个月:证言支持
- 进行证言询问
- 在证言过程中实时搜索证据
- 分析证言笔录
- 生成交叉询问问题
- 随着新信息出现更新时间线
第 6 个月:审判准备
- 最终确定证物清单
- 创建庭审证据系统
- 准备演示用时间线
- 按主题组织证人陈述
- 准备证人提纲
现在就做
- 在上传文件前定义你的审查类别
- 为第一批文件(100–200 份)创建编码模板
- 运行一次证言笔录分析并标记不一致之处
- 根据证词模式起草 5 个交叉询问问题
- 基于至少 3 个文件来源构建案件时间线
- 对样本集完成一次特权审查并创建特权日志
- 记录你的 QC 程序以保留审计轨迹
下一教程前的作业
-
建立基础电子证据开示协议
- 为一个练习案件定义 5-8 个文件审查类别
- 为“responsive”与“non-responsive”创建判断规则
- 写一份简短的特权审查指南
-
练习创建时间线
- 选取一组样本文档
- 提取所有日期和事件
- 创建按时间顺序排列的时间线
- 识别 5 个关键转折点
-
电子邮件线程分析
- 选取 20 封样本邮件
- 识别线程及线程参与者
- 绘制通信流向
- 记录任何关键承认或矛盾
-
证言问题准备
- 找一份样本证言笔录
- 识别 3 个重大不一致点
- 为每一点起草交叉询问问题
- 创建一份有效的交叉询问提纲
-
建立你的搜索协议
- 为一种常见案件类型创建搜索词库
- 包含 20-30 个关键搜索
- 制定自然语言查询模板
- 用样本文件测试
快速参考:电子证据开示提示词
证据开示文件审查
证言笔录分析
时间线创建
电子邮件线程分析
证人陈述比较
特权审查
证据搜索
来源
- FRCP Rule 26 (Discovery Scope, ESI, Privilege Claims)
- FRCP Rule 34 (Production of ESI)
- FRCP Rule 37 (Discovery Failures and ESI Preservation Sanctions)
- EDRM Current Model (2.0)
- Relativity aiR for Review Documentation
- Everlaw Predictive Coding Guide
- ABA Model Rule 1.1 (Competence) + Comment 8 (Technology)
延伸阅读
- EDRM Frameworks and Standards
- Relativity aiR for Review Prompt Development
- Everlaw Predictive Coding Prioritization and QC