设计法律文档 RAG 系统，第一句话应该怎么说
一句话总结
在法律文档检索‑增强生成（RAG）系统里，第一句话必须先点出“文档目标与适用范围”，而不是直接抛出技术实现或数据来源。如果把系统的技术细节或模型性能放在开头，读者会立刻失去对系统合法性和业务边界的信任；
相反，先声明系统的治理目标、受众以及合规边界，才能在后续任何技术细节出现时拥有合法性的“护盾”。这是一条判决式的结论：正确的首句是对业务与合规的承诺，而不是对技术的炫耀。
适合谁看
- 企业法务负责人：需要评估是否可以把 RAG 方案投入生产，关注合规、保密与责任划分。
- AI 产品经理（PM）：负责需求拆解、里程碑规划，需要明确系统定位以制定功能路线图。
- 机器学习工程师：实现检索‑增强生成的底层技术实现者，必须在业务约束下选型与调参。
- 合规与风险团队：审查系统输出的法律风险，确保首句的合规声明能够在监管审计中站得住脚。
核心内容
1. 为什么“技术先行”会让系统失信？
在一次跨部门的 Hiring Committee 讨论中，PM 把 PPT 的第一张直接写成“基于最新的 LLM，我们的系统可以在 0.8 秒内返回完整法律条文”。HR 立刻打断：“这不是技术卖点，而是合规风险点。
”随后，法务同事举了一个真实案例：某金融公司在内部系统页面开头写了“本系统使用 GPT‑4”，结果在一次监管审计中被指责未在用户界面明确告知“生成内容非官方法律意见”，导致 300 万美元的罚款。
这说明，不是先说技术，而是先说合规。第一句话如果是“本系统仅提供参考，非正式法律意见”，即使后面技术再强，也能让监管部门和内部审计把风险降到最低。
2. 合规声明的结构要点
合规声明应围绕 三大维度：受众、适用范围、责任限制。
- 受众：明确系统面向的是内部法务、合作伙伴还是外部客户。
- 适用范围：列出系统覆盖的法律领域（如合同法、知识产权、劳动法）以及不覆盖的情形（比如税法、刑事案件）。
- 责任限制：使用“本系统输出不构成法律意见，最终解释权归贵公司法务部门所有”。
在一次 debrief 会议里，负责风险的同事把这三点写在白板上，并用 BAD vs GOOD 对比演示：
- BAD：“本系统使用最新 AI 技术，能够自动生成合同”。
- GOOD：“本系统为内部法务提供基于已归档合同的检索与参考摘要，生成内容仅作参考，非正式法律意见”。
这两个版本的差别在于，后者把 业务定位 与 责任边界 明确写出，前者则把技术炫耀置于首位，容易被监管视为误导。
3. RAG 系统的业务边界如何写进第一句话
业务边界的描述要具体到 “文档类型、使用场景、审阅流程”。例如：
> “本系统提供针对已归档《商业合作协议》及《保密协议》的检索与要点摘要，帮助内部法务在合同审阅前快速定位关键条款，输出仅作内部参考”。
这里用 不是‘所有法律文档’，而是‘已归档商业合同’ 来限定范围，用 不是‘直接生成’，而是‘提供要点摘要’ 来削弱生成的法律效力。
4. 法律文本的检索层级与生成层级的显式区分
在 RAG 架构里，检索层负责从向量库返回最相似的段落，生成层负责把这些段落拼接并用 LLM 进行语言润色。第一句话必须让读者知道这两层是 分离且可审计 的。
> “系统首先在经过合规审查的向量库中检索相关条款，随后在受控的 LLM 环境下生成摘要”。
这句话的价值在于：
- 不是把检索和生成混为一谈，而是明确两者的职责。
- 不是让模型自由发挥，而是让模型在受控的、已经合规审查的文本上作二次加工。
5. 让第一句话兼顾内部审计与外部监管
内部审计往往要求 版本可追溯，外部监管要求 透明告知。因此，第一句话里加入 “系统输出会记录在审计日志，且每次检索的原始文档链接都会在页面底部显示”，可以一次性满足两类需求。
> “每次检索结果均附带对应文档的唯一标识和审计日志链接，供法务团队追溯”。
这句话的核心判断是：不是仅提供结果，而是提供可追溯的证据链。
6. 薪资与团队配置的裸数据（为后文面试流程做支撑）
在组建 RAG 项目组时，常见的岗位与薪酬结构如下（均为硅谷标准）：
| 岗位 | Base | RSU（3 年） | Bonus |
|---|---|---|---|
| PM（Legal AI） | $150,000 | $120,000 | $30,000 |
| ML Engineer（检索） | $170,000 | $150,000 | $35,000 |
| ML Engineer（生成） | $180,000 | $180,000 | $40,000 |
| 法务顾问（内部） | $160,000 | $100,000 | $25,000 |
| 合规审计专员 | $140,000 | $80,000 | $20,000 |
这些数字在面试流程里会被引用，帮助候选人判断岗位价值，也让招聘委员会在 HC（Headcount） 讨论时有明确的预算依据。
7. 面试流程细化（每轮考察重点与时间）
- 简历筛选（30秒/份）：系统自动检测关键词 “RAG”、 “法律文档检索”、 “合规审计”。
- HR 初筛（15 分钟）：确认候选人对法务流程的了解，重点问：“你如何确保 AI 输出不被误用？”
- 技术面（60 分钟）：围绕检索向量库、倒排索引、Embedding 训练细节展开。要求现场写出 检索‑增强生成的伪代码。
- 业务与合规面（45 分钟）：由法务负责人与 PM 共同提问，案例：“如果系统生成的摘要误删了关键违约条款，你会怎么做？”重点评估 风险意识 与 沟通能力。
- 现场写作（30 分钟）：让候选人在白板上写出系统首页的第一句话，并解释每个词的合规意图。
- 最终评审（30 分钟）：Hiring Committee 进行打分，重点看 第一句话的判定是否符合业务合规，以及 候选人对责任边界的阐释。
每轮都有明确的评分维度，确保 不是只看技术深度，而是看技术与合规的协同。
> 📖 延伸阅读：PM竞争性Offer模板：谷歌Meta亚马逊TC计算器与谈判脚本
准备清单
- 收集过去 12 个月内的内部合同归档，确保每份文档都有唯一 ID 与审计标签。
- 搭建向量检索平台（如 Milvus），并完成法律文本的 Embedding 训练，记录训练超参数。
- 系统性拆解面试结构（PM 面试手册里有完整的[RAG 项目实战复盘]实战复盘可以参考），确保面试官知道如何评估“第一句话的合规判断”。
- 编写合规声明模板，列出受众、适用范围、责任限制三段式文本。
- 实现审计日志功能：每次检索记录用户 ID、时间戳、检索向量、返回文档 ID。
- 与法务团队共创“错误输出处理 SOP”，包括误删关键条款的快速回滚流程。
- 完成面试流程文档，明确每轮考察重点、时间分配以及评审矩阵。
常见错误
错误一：把技术细节写成第一句话
BAD：“本系统采用最新的跨模态 LLM，实时生成完整法律合同”。
GOOD：“本系统提供已归档商业合同的检索与要点摘要，输出仅作内部参考”。
根本原因：技术炫耀导致合规风险被掩盖，监管审计时会被认定为误导。
错误二：未限定文档范围，导致责任无限扩大
BAD：“系统可检索所有法律文档”。
GOOD：“系统仅检索已通过合规审查的《商业合作协议》与《保密协议》”。
根本原因：范围不明确让系统在未知法律领域产生输出，增加法律责任。
错误三：漏掉审计可追溯性声明
BAD：“用户点击后即得到答案”。
GOOD：“每次检索结果附带文档唯一标识与审计日志链接”。
根本原因：没有可追溯链条，内部审计和外部监管时无法证明输出来源。
> 📖 延伸阅读：WeWork产品经理薪资总包L3到L7对比分析2026
FAQ
Q1：如果系统在检索时意外返回了未审查的法律文档，该怎么办？
A：在一次真实的 debrief 中，检索层出现了误匹配，返回了内部未归档的“劳动合同”。法务立即启动 SOP，将该文档标记为“保密”，并在审计日志中记录异常。系统随后自动触发回滚，将该文档从向量库下线。结论是：第一句话必须提前声明“仅检索已审查文档”，否则系统一旦泄露未经审查的内容，合规风险直接升至最高等级。
Q2：为什么第一句话要提到“仅作内部参考”，不能直接说“仅供参考”？
A：在一次 hiring manager 与合规专员的对话里，合规专员指出，“内部参考”比“供参考”在法律语言上更具约束力，因为它明确了使用主体（公司内部法务），而不是对外的模糊受众。实际案例：某公司在对外发布的 AI 法律助手页面只写了“供参考”，在被外部律师追责时被认定为对外误导，导致赔偿。因此，正确的表述是“仅作内部参考”，而不是简单的“供参考”。
Q3：RAG 系统的第一句话是否需要随法规更新而改写？
A：是。一次内部审计发现，系统首页的合规声明仍沿用去年 GDPR 初稿的措辞，未覆盖最新的加州消费者隐私法（CCPA）要求。审计后，法务团队要求在声明中加入“符合加州消费者隐私法第 1798.115 条”。不是一次性写完即永久有效，而是需要定期审查并更新，以保持合规性。
以上判决式分析，旨在帮助你在设计法律文档 RAG 系统时，从合规第一句开始，确保技术实现永远站在合法、可审计的基石之上。
准备好系统化备战PM面试了吗？
也可在 Gumroad 获取完整手册。