法律 AI 幻觉案例突破 2,000 起：该构建什么

涉及 AI 幻觉内容的法院裁决已突破 2,000 份。为什么单靠 RAG 没能解决问题，以及我在合同 AI 工作中总结的设计模式。

截至 2026 年 9 月 14 日，Damien Charlotin 的 AI Hallucination Cases 数据库收录了 2,041 份涉及 AI 幻觉内容的法院及裁判机构裁决。在其中多数裁决里，法院认定或暗示某一方当事人依赖了这类内容；作为例外，数据库也收录了一些使用 AI 仅被指称、未获证实的裁决。单靠检索解决不了问题：在 2024 年一项由斯坦福牵头的研究中，三款主流法律研究工具接受了测试，出现幻觉的比例各自在 17%–33% 之间。真正该构建的是：让输出可被核查的结构、一个做决定的人，以及先建好的评测集。

我曾在 Kartez Contract 项目中担任 AI 工程师；本文讲的是我会从那段工作中保留什么，以及会先做什么。

AI 幻觉案例数据库告诉了开发者什么，又没告诉什么

Charlotin 统计的数字已突破 2,000。在任何人把它写进提案或风险备忘录之前，有三点需要先弄清楚。

它统计的是裁决，不是错误。 该数据库“并不追踪法庭文书中所有虚假引用或 AI 使用的（必然更广的）整体范围”。它记录的是走到法官面前的失败，而不是幻觉率。

它不归咎于工具。 数据库自己的说明写道，提到某个工具“并不必然意味着该工具要为相关幻觉负责”，所以本文不会把数据库中的任何一份裁决与某个工具挂钩。下文点名的工具来自斯坦福的研究，而不是这个数据库。

类别比总数更重要。 在 Charlotin 的数据库中，1,690 份裁决被标为 Fabricated（捏造），854 份被标为 Misrepresented（曲解），548 份被标为 False Quotes（虚假引文），而且一份裁决可以同时带有多个标签。检查被引用的来源是否存在，能拦下第一类中的大部分，也就是凭空捏造的法律依据。但只要来源真实存在，而引文是编造的或对它的解读有误，后两类就会通过这道检查。合同工具也可能一边指向一个真实存在的条款，一边犯下这两种错误。

Charlotin 还列出了 1,174 份使用 AI 的一方是自行诉讼当事人（pro se，即不请律师、自己代表自己的人）的裁决，以及 811 份使用 AI 的一方是律师的裁决。因此，法律 AI 工具既不能假定流程中有律师参与，也不能假定会有律师发现它的错误。在他的数据库中，合同（Contract）以 449 份裁决成为最大的法律领域。这些是涉及 AI 幻觉内容问题的合同纠纷，而不是由 AI 起草的合同。

RAG 能防止法律 AI 幻觉吗？

不能。下文的斯坦福研究得出结论：法律领域的检索增强生成（RAG）“与通用 AI 系统（此处为 GPT-4）相比可以减少幻觉，但幻觉依然大量存在、范围广泛，而且可能具有隐蔽性”。“隐蔽”一词用得准确：依据错误的回答，是附带着一个真实来源送到你面前的。通用的护栏设计见 RAG 幻觉护栏。

斯坦福牵头的研究：17%–33%

在 2024 年 5 月 30 日发布到 arXiv 的一篇论文中，来自斯坦福大学和耶鲁大学的研究者报告了“首个针对 AI 驱动的法律研究工具的预注册实证评估”。预注册是指研究本身及其包含超过 200 个法律查询的数据集，在评估开始之前就已登记，以防研究者挑选迎合结果的查询。一些厂商曾宣传检索可以“消除”或“避免”幻觉。研究发现，Lexis+ AI、Westlaw AI-Assisted Research 和 Ask Practical Law AI 出现幻觉的比例各自在 17%–33% 之间，并指出“厂商的说法言过其实”。

比这个区间更重要的是定义。一个回答只要“不正确或依据错误（misgrounded）”，就算作幻觉；所谓依据错误，是指关键论断“给出了引用，却曲解了来源，或引用了并不适用的来源”。这些工具是在 2024 年测试的，测的是法律研究而不是合同，所以这个区间不能当作今天法律 AI 的数字。但这个类别同样适用于合同：在合同里，一个依据错误的回答听起来没错，指向的却是错误的条款。

Google 的“充分上下文”研究：上下文更多，拒答更少

论文《Sufficient Context》把两类错误区分开来：一类是模型误用了本身足够好的上下文，另一类是上下文从一开始就不足以回答问题。它测试的较大模型来自 Google、OpenAI 和 Anthropic，这些模型“在上下文不充分时，往往输出错误答案而不是拒绝作答”。

Google Research 对这项工作的介绍文章（2025 年 5 月 14 日）指出，RAG 虽然“总体上提升了整体性能，却反常地削弱了模型在该拒答时拒绝作答的能力”。在 Google 给出的例子中，Gemma 在没有任何上下文时答错了 10.2% 的问题，在上下文不充分时答错了 66.1% 的问题。

检索改变的是模型看到什么，而不是模型是否知道自己看到的已经够用。一个关于合同终止的问题，答案可能取决于一条从未被检索出来的定义条款或通知条款。设计上必须让“我需要另一部分内容”成为一种正常输出，评测也必须检验这一点。

AI 合同审查：真正要紧的错误

被编造出来的条款会成为签署方的法律责任，所以会编造条款的模型比没有模型更糟。下面这几类错误，是我在设计时会最先防范的。下列模式没有一个能证明回答正确；大多数能让错误的回答被发现。

错误类型

在合同中的表现

让它可被核查的模式

编造内容

文件中并不存在的条款或期限

依据选定条款作答；每处修改都由用户接受

引文有误

修改建议要改的文本并不存在

每条修改建议都逐字引用现有措辞

依据错误的回答

回答出自错误的条款，或出自从未提供给模型的部分

条款选择；指示模型索要缺失的部分

输出损坏

被截断的风险清单被当作完整内容展示

固定的输出结构，绝不原样展示；对修复后的回复做完整性检查（建议）

修改不完整

某一方的名称只在一个部分被改掉

整份合同范围的修改先规划，再全部应用并高亮

数值被改动

金额、日期或名称在改写中被改变

逐字核对数值（建议，见下文）

Kartez Contract 中的合同 AI 设计模式

2025 年 11 月至 2026 年 7 月，我在 Kartez Contract 项目中担任 AI 工程师。这是一个支持三种语言、从右向左排版的合同工作区，包含起草向导、审查流程和合同工作室。我以客户最初的几条基础 AI 调用链为起点，重建并扩展了支撑这些工作流的 AI 引擎，并构建了 copilot：它对每个请求进行分类，找出相关条款，并规划覆盖整份合同的修改。

最难的问题是检索和锚定，而锚定靠的是结构，不是信任。下面六个模式都不是经过测量的保证；前四个本身就是锚定约束。

只依据 copilot 选定的条款作答

用户的合同按其自身结构切分，包括波斯语合同按自己的方式编号的条、款和附注（ماده، بند، تبصره）。只有与问题相关的部分才会被用来回答该问题；copilot 还被指示，在需要未提供给它的部分时明确说出来。

条款本来就是律师工作时使用的单位，所以由条款组成的检索集，评测人员可以标注，也可以核查。这条指示为模型提供了猜测之外的另一种选择，但它不是强制执行的闸门，因此评测集里需要有选定条款无法回答的问题。波斯语检索有它自己的陷阱，波斯语 RAG 的混合检索一文针对另一套系统讨论过这些陷阱。

逐字引用合同原文的修改建议

每条修改建议都必须逐字引用现有措辞，以便定位和替换，并附带可直接使用的替换文本。正是这项要求让精确引文校验（exact-quote validation）成为可能：程序可以在应用修改之前，先确认被引用的文本确实存在。

一处改写是否明智，是法律判断；它要替换的那句话是否存在，是字符串匹配。OWASP 关于 LLM 错误信息（misinformation）的指南从一般层面说明了这一点：“自动校验关键输出，尤其是高风险环境中的输出”。如果重新构建，我会丢弃任何找不到引文的修改建议，绝不近似地应用它，并统计被丢弃的次数，作为早期预警。

这些修改建议位于审查流程中，而工作停止时该流程尚未经过完整测试，所以这个模式的依据是它的逻辑，而不是测量结果。

固定输出结构，绝不原样展示

每项分析都返回固定结构，因此时间线、风险登记表和修改建议每次都以同样的方式呈现。格式有误的响应会经过多阶段的解析与修复步骤，包括修复被截断的回复，必要时还会留出更大的输出空间重试。这样的响应从不原样展示给用户。

这针对的是一种不易察觉的失败：被截断的风险清单，在读者看来是完整的。单靠修复解决不了这个问题，因为一个被截断后又被补全闭合的清单照样能通过解析；所以我会对修复过的截断结果重试或加以标注，而不是把它当作完整内容展示。固定结构还让其他检查知道该去哪里查找。

起草时使用低随机性

起草时，模型以低随机性运行。这换来的是可重复性，而不是正确性：相同的输入往往得到相同的草稿，因此失败可以复现，不同轮次的评测结果也可以相互比较。

引导式工作流，而不是一个聊天框包揽所有工作

起草、审查和编辑是不同的工作，各自需要专门的引导式工作流，而不是共用一个聊天窗口。例如，审查是从用户一方的立场撰写的，所以它的第一步会询问用户在交易中的角色。

Anthropic 的《Building effective agents》是在编排的意义上使用“工作流”一词的：工作流是“通过预定义的代码路径来编排 LLM 和工具的系统”。文章称，工作流“为定义明确的任务提供可预测性和一致性”。每个固定步骤的输入和输出都有已知的结构，可以核查。空白聊天框接受任何输入，也返回任何输出。

高亮显示、由用户接受或拒绝的修改

在全部三条工作流中，规则都是：AI 提出建议，用户做出决定。copilot 所做的修改会在编辑器中高亮显示，由用户接受或拒绝。针对整份合同的指令，例如更改某一方的名称，会先经过规划，再应用到每个受影响的部分，并高亮显示。

用户评判的是标出来的改动，而不必重读整份文件；一次改名在它生效的每一处都会高亮，而不是事后才作为前后不一致被发现。

另一套系统：本站助手的闸门

本节描述的任何内容都不属于 Kartez Contract。本站的助手由我构建和维护，它只依据本站自己的内容作答，并受一系列确定性闸门约束。

有些问题在检索任何内容之前，就会被模式匹配直接拒绝：询问费用与时间安排的问题、打探私人信息的问题、猜测性问题、针对系统提示词的攻击尝试，以及让助手写代码、翻译或解题的任务请求。如果问题与我无关，而检索到的内容又都没有达到检索分数下限，助手就会拒答，模型根本不会被调用。关于我的问题同样通过模式匹配来识别，依据的是我的名字或第三人称代词之类的线索；这类问题不会仅仅因为没有段落达到下限就被拒答。此时模型拿到的是本站自己的记录，即来自简历、案例研究、文章和咨询服务的条目，并被要求在这些记录无法回答问题时只回复一个固定的标识词；读者看到的仍是同样的拒答。回答以流式输出时，句子闸门会在每个完整的句子显示之前对它进行检查：

  • 引用范围。 每个引用标记都指向提供给模型的某个来源。

  • 必须有引用。 每个实质性句子都带有标记。

  • 值有出处。 每个数字、URL 和电子邮件地址都出现在该句所引用的某个来源中。

  • 人称。 任何句子都不使用 I、me 或 we 这类第一人称代词。

只要有一个句子没通过，回答就会停止，而且那个句子永远不会显示。引用标记先经过检查，然后被移除，所以读者永远看不到它们。

具体机制见流式 LLM 护栏。“有检索 vs 没检索”演示会流式输出一个真实的、有出处的回答，旁边不做检索的那一栏按设计保持空白；如果问一个与我无关、本站也没有覆盖的问题，运行会在触及任何模型之前就停下来。如果我要做一个合同工具，我会为金额、日期和当事人名称加上同类检查，要求每个值都与来源逐字一致。

如何评测法律 AI：先建评测集

通常的顺序是先构建，再测量。对于法律 AI，我会把顺序反过来。

  1. 设计约束是一个假设。 “修改建议必须逐字引用合同原文”是一条规则。模型多久违反一次，是一个数字，而只有评测集能给出这个数字。

  2. 每次改动都需要回归检查。 没有固定的评测集，每一次模型、提示词或检索方面的改动都只能凭感觉判断。

  3. 评测集比项目活得更久。 一个标注好的评测集和它最近一次的运行结果，是别人也能使用的证据；一份设计原则清单则不是。

Kartez Contract 项目后来发生了什么

在距完工还有一个月时，战争引发的财务困难导致资金中断，客户叫停了这项合作。这是客户在资金上的失败，而不是交付上的失败。到那时，起草向导、配备 copilot 的合同工作室以及三语界面都已建成，并已端到端打通。审查流程的全部五个步骤都已构建，但工作停止时尚未经过完整测试，仍在完善中。

目前没有任何准确率数字，因为合作在正式评测集建立之前就已终止。设计约束是真实存在的；而能把它们变成一项有据结论的数字，从未产生过。

合同 AI 第一周就该建的评测集

以下是建议，而不是在描述 Kartez Contract 当时已有的东西。每一项只判通过或不通过。

  • 可回答的问题，并标注对应条款。 回答必须正确，并且依据该条款。

  • 合同无法回答的问题。 期望的输出是“我需要第 X 节”或“合同中没有规定”，而不是一个答案。

  • 修改请求。 修改建议中每一段被引用的文本，都必须与源文件字符串匹配。

  • 整份合同范围的修改。 更改某一方名称时，必须改掉每一处出现，且不改动其他任何内容。

  • 不得变动的数值。 金额、日期、通知期限和当事人名称，在每次改写前后逐字比对。

  • 损坏的输出。 被截断或格式有误的回复绝不能原样显示到屏幕上，修复过的截断结果也绝不能被当作完整内容展示。

  • 波斯语结构。 按 ماده（条）、بند（款）和 تبصره（附注）编号，混合书写方向的行，以及波斯语数字。

  • 交易双方。 同一份合同，分别从每一方的立场审查。

Digital Omnibus 之后的欧盟《人工智能法案》截止日期：工程视角

  • 欧洲议会于 2026 年 6 月 16 日、欧盟理事会于 2026 年 6 月 29 日通过了最终文本。

  • 对于 2026 年 8 月 2 日之前投放市场的系统，AI 生成内容的标识须在 2026 年 12 月 2 日前完成。

  • 第 50 条规定的其他透明度义务，例如告知用户其正在与 AI 系统打交道，自 2026 年 8 月 2 日起适用。

  • 附件 III 中独立高风险 AI 系统的义务推迟至 2027 年 12 月 2 日。对于嵌入附件 I 所列安全立法所涵盖产品中的 AI，这一日期为 2028 年 8 月 2 日。

是否属于适用范围，应由法律顾问判断。上述任何模式都不是合规措施。

自建或采购法律 AI 的检查清单

  • 每个回答依据的是什么？ 某一条款或某一部分，而不是笼统的“这份文件”。

  • 每处修改都能定位吗？ 每处改动都引用它所替换的文本，并与文件核对。

  • 它能说出答案不在文件里吗？ 请对方演示。

  • 输出在显示前经过校验吗？ 损坏的回复要么被修复，要么不予显示。

  • 有没有未经接受就生效的改动？ 不应该有。

  • 是否一项工作对应一条工作流？ 起草、审查和编辑不应共用同一个聊天框。

  • 数值是否逐字核对？ 金额、日期和当事人名称，都要与来源比对。

  • 我能看看评测集吗？ 里面有什么，哪些条目测试拒答，最近一次是什么时候运行的。

如果你正在为合同或法律 AI 系统梳理范围，项目诊断会用五个问题给出一份初步架构。

常见问题

有多少 AI 幻觉案例已经进入法院？

截至 2026 年 9 月 14 日，Damien Charlotin 的 AI Hallucination Cases 数据库收录了 2,041 份涉及 AI 幻觉内容的法院及裁判机构裁决。在其中多数裁决里，法院认定或暗示某一方当事人依赖了这类内容；作为例外，也收录了一些使用 AI 仅被指称、未获证实的裁决。它记录的是裁决，而不是法庭文书中的每一处虚假引用或每一次 AI 使用。

RAG 能减少法律 AI 的幻觉吗？

能减少，但不能杜绝。在一项由斯坦福牵头的预注册研究中，三款基于检索的法律研究工具出现的幻觉少于 GPT-4，但在 2024 年测试时，它们出现幻觉的比例仍各自在 17%–33% 之间。Google 的“充分上下文”研究发现，当检索到的上下文不够时，较大的模型往往会给出错误答案，而不是拒绝作答。

AI 能可靠地审查合同吗？

不能靠信任。能构建出来的，是一种让错误可被核查的审查：依据选定条款作答、逐字引用合同原文的修改建议、固定的输出结构，以及由人来接受或拒绝每一处改动。一个工具能否真正抓住错误，要靠测量来回答，所以请向对方索要它的评测集。

什么是精确引文校验？

它是在应用修改建议之前进行的一项检查：确认该建议所引用的文本逐字存在于当前文件中。它的前提是一条规则，即每条修改建议都必须引用它所替换的措辞；有了这项检查，法律修改的一部分就变成了字符串匹配。

为什么 Kartez Contract 没有准确率数字？

客户因战争相关的资金原因，在距完工一个月时叫停了合作，当时正式评测集尚未建立。本站不估算未经测量的数字。正是这个空缺，让本文主张先建评测集。

参考来源