为律师设计RAG：拒答才是核心功能

通用聊天产品追求「有问必答」，但在法律场景里，最值得信赖的输出往往是「我无法回答这个问题」。为律所构建检索增强生成（RAG）系统时，这个反直觉的设计原则几乎决定了项目成败。

法律RAG的基本流程并不复杂

系统从律所的知识库中摄取材料——简报、备忘录、合同、案件档案和业务手册，来源通常是 SharePoint、iManage 或文档管理系统。摄取完成后按案件工作区（matter workspace）进行分组，让检索范围天然收敛到一个案件的相关材料内。

查询时，系统先按语义检索相关段落，然后仅基于被检索到的内容生成回答，每条论断附带编号引用，可回溯到源段落。这套流程听起来并不新鲜，但真正区分一个可用系统和一个危险系统的，是以下三个设计选择。

RAG（Retrieval-Augmented Generation，检索增强生成）是一种将检索系统与大语言模型结合的技术架构。与传统聊天机器人的核心区别在于：模型不依赖训练阶段记住的知识来回答，而是先在外部知识库中检索相关文档片段，再将这些片段作为上下文交给模型生成回答。这种架构的优势是回答可以追溯到具体来源，且知识库更新后无需重新训练模型。在法律场景中，RAG 的检索来源通常是律所内部的案件文档，因此回答的依据天然限定在特定案件的材料范围内，大幅降低了模型引入外部错误信息的可能性。

三个比模型选型更重要的设计决策

语义检索：律师不会用布尔表达式提问

律师提问的方式和合伙人开会时一样——用自然语言。「如果平台泄露客户数据，谁来承担风险」这样的问题，应该能检索到赔偿条款和保密条款，即便这两类条款中都不含「泄露」这个词。

在一个 SEC 文件检索项目中，这种自然语言查询比分析师们此前编写的 256 字符布尔字符串快了 3.4 倍。语义检索不是锦上添花的功能，而是让系统真正被律师使用的关键前提。

布尔检索是传统法律数据库（如 Westlaw、LexisNexis）中长期使用的主流方式，要求用户用 AND、OR、NOT 等逻辑运算符连接关键词，精确控制检索范围。它的优点是可预测、可复现，但对使用者的检索技巧要求很高。语义检索则基于向量嵌入（embedding）技术，将查询和文档都映射到高维向量空间，通过计算向量相似度找到语义相近的内容，即使字面用词不同也能匹配。两者并非互斥——成熟的 RAG 系统常将语义检索与关键词检索结合使用（称为混合检索），再通过重排序模型优化结果，以兼顾召回率和精确率。

硬性拒答：不要在检索结果之外编造

如果检索结果不足以支撑一个回答，系统必须明确说「无法回答」并停止。用看似合理的猜测填补空白，恰恰是这套系统要消除的行为。

这一点与通用聊天产品的设计哲学截然相反。面向消费者的 AI 助手被训练成尽量给出有用的回复，即使信息不完整也会尝试推断。但在法律场景下，一个编造出来的条款引用可能导致严重的职业责任问题。拒答能力不是系统的局限，而是核心功能。

人在环路中的审批门

系统返回的草稿以修订模式（tracked changes）呈现，每个改动都可以单独接受或拒绝。在律师签字确认之前，任何内容都不会被提交或发送，而签字这个动作会被完整记录在日志中。

这不是简单的「人工审核」按钮，而是一条有审计追踪的合规链路。对律所而言，知道谁在什么时候批准了什么内容，与内容本身同等重要。

「修订模式」（tracked changes）是 Microsoft Word 等文字处理软件中的一项功能，它会记录文档的每一处修改——包括插入、删除、格式变更——并以不同颜色标注，供审阅者逐条接受或拒绝。在法律行业，这是合同谈判和文件审阅的标准工作方式。将其引入 RAG 系统的工作流意味着：AI 生成的草稿不是一份需要律师从头核对的普通文档，而是一份每一处改动都已被标记、可追溯的修订稿。律师的审阅动作因此从「逐句比对原文」变成「逐条判断是否接受」，显著降低了审阅成本，同时保留了完整的决策记录。

数据质量比数据量更关键

知识库的状态对项目周期的影响远超规模。干净的判例法文件摄取速度很快，但二十年的扫描版案件档案需要先做数据清洗——OCR 纠错、格式标准化、元数据补全——这些工作量必须体现在项目估算里。

一个常见误区是认为「数据越多，RAG 效果越好」。在法律场景中，一份干净、结构良好的判例集比一座充满噪声的文档仓库有价值得多。

OCR（光学字符识别）是将扫描图像中的文字转换为可编辑文本的技术。在法律行业，大量历史案件档案以纸质形式保存后扫描为 PDF 图像，这些文件中的文字对计算机而言只是像素，无法被检索或嵌入。OCR 工具将其转为文本后，常伴随识别错误——尤其是法律文件中常见的特殊符号、表格、手写批注和盖章区域。此外，扫描件的格式（如页码、页眉、段落边界）往往在转换中丢失，需要额外的格式标准化和元数据补全工作。这些清洗步骤不产生直接可见的「智能」效果，却是 RAG 系统能否准确检索的基础——检索到一段充满 OCR 错误的文本，生成质量必然受损。

工程启示：先写评测集，再调系统

给工程师的直接建议：在调优任何参数之前，先写好评测集。

利用律所团队已经手工完成的研究成果作为基准，测量精确率和召回率，并在实际工作中加入遗漏案例审计（missed-case audit）。决定系统是否上线的，应该是这些数字，而不是演示时给人的印象。

这个思路的价值在于，它把「系统好不好用」从主观感受变成了可量化的指标。法律行业对准确性有极高要求，评测集不仅是技术工具，更是与客户建立信任的依据。

拒答作为设计哲学

回到最初的观点：在法律 RAG 中，拒答不是一个需要被优化掉的缺陷。它体现的是系统对自己知识边界的诚实认知。一个总是能给出答案的系统，在法律场景中反而更危险——因为你无法分辨哪些回答有据可查，哪些是模型在「填空」。

这套设计原则对其他高风险领域同样适用：医疗、金融合规、安全审计。当错误的代价远高于「不知道」的代价时，拒答就应该被当作一等公民来设计。