法律领域的AI扩展：构建Uber的红线审查智能体

引言

很少有领域像法律工作那样要求如此高的精确度和严谨性，因此它成为检验 AI 智能体能否投入日常实践的严苛试金石。从 2024 年初开始，一直持续到 2025 年，在当今的智能体框架广泛普及之前，Uber 构建了第一代法律红线审查智能体（Legal Redlining Agent，LRA）。它帮助 Uber 法务团队处理海量合同谈判，同时不损害信任与合规性，也不会取代律师的判断。

最持久的经验教训并非关于模型或架构，而是关于如何成功地将智能体融入律师的日常工作。我们从商业问题出发：持续不断的合同谈判中包含大量可重复的红线审查工作。我们在律师已有的工作场所——Microsoft Word®——与他们对接，使 LRA 能够在其现有工作流程中标记风险红线并建议修改。随后，我们与律师密切迭代智能体的功能，并于 2025 年与法务团队进行试点，将他们的反馈融入产品中。

在这篇博客中，我们将分享将第一代智能体投入实践的经验：界定问题、赢得律师的信任，以及通过他们的反馈改进智能体。最后，我们将介绍第一代系统的工作原理，以及在智能体技术不断发展的今天，我们会如何处理这个问题。

2026 年 3 月 9 日，LRA 是 Uber 法务团队获奖提交作品的一部分，该作品荣获 ALM Legalweek Leaders in Tech Law Awards 的 年度最具创新力法务部门 奖项。

Document editing interface showing tracked changes in a disclaimer text, with suggestions and options panel on the right.：图片未能保存，请查看原文。

图 1：法律红线审查智能体的实际运行情况。

问题：高风险、高摩擦

在 Uber，每年要谈判数千份合同。每一份合同背后都有一个法务团队在审查和谈判。这个过程可能耗时、重复，且常常成为交易、入职和发布的瓶颈。这是一项高风险、注重细节的工作，精确度至关重要，任何延误都会波及销售、入职和发布。

然而，在这个高风险流程的深处，隐藏着一些出人意料的结构化内容：相似的条款、跨客户的可重复红线，以及既定的法律推理模式。换句话说，存在一个清晰的体系。

由于法务部门的工作对 Uber 至关重要，我们看到了一个机会：自动化可重复的部分，让律师腾出时间处理复杂的判断，同时不牺牲质量或一致性。

图 2：合同审查生命周期及企业交易的平均支持时间。

解决方案：AI 驱动的红线审查智能体

法律红线审查智能体是一款 AI 驱动的智能助手，作为加载项直接集成到律师工作所在的 Microsoft Word 中。它审查客户修改、理解意图、推荐符合政策的回应、生成结构化评论、标记风险，并不断从反馈中学习。

它结合了：

• 文档审查，用于识别红线（客户所做的修改与 Uber 律师所做的修改）
• 意图检测，用于解读提出的修改
• 符合政策的建议，用于接受、拒绝或修改条款
• 评论生成，用于解释 Uber 的法律立场
• 风险标记，用于突出需要律师进一步审查的条款
• 自我学习反馈循环，以改进未来的推荐

自与我们的法务团队合作推出以来，我们看到平均合同审查时间减少了 20% 以上，AI 生成决策的准确率达到 91%。我们还收到了这样的反馈：“它为我节省了大量时间，尤其是评论建议功能。”

什么是法务红线代理？

该加载项会分析 Microsoft Word 文档，并识别来自外部方的任何红线修改。然后，它利用 AI 处理这些更改，试图理解客户的意图和法律影响。它会将建议的更改与我们团队的法律政策和准则进行比较。

基于此分析，该加载项会生成一系列建议，其中包括推荐操作、向客户提出的评论（用法律推理来证明这些推荐的合理性），以及对每项更改相关风险等级的评估。Uber 律师随后会审查每条建议，决定是接受、拒绝还是修改，然后再最终将其纳入客户回复中。

图 3：法务红线加载项/代理的高级工作流程。

迭代改进法务红线代理

我们刚刚描述的系统并非一蹴而就。走到这一步需要四次重大迭代，每一次都让我们深刻认识到法务 AI 实际上需要什么。

在此过程中，我们使用了 Uber 的 GenAI 网关，这使我们能够完全专注于完善产品逻辑，并与领域专家密切合作。

迭代 1：RAG

我们最初的方法侧重于开发一个基础的 RAG（检索增强生成）系统。法务团队提供了现有的操作手册和谈判回合示例。我们的假设是，通过摄取这些操作手册来识别语义相关的部分，然后将这些部分与对方提出的更改一起输入 LLM（大语言模型），系统就能生成合理的决策。

图 4：RAG（检索增强生成）流程。

我们很快遇到了这种方法的挑战：

• 语义相似度不准确。我们试图嵌入的“键”的性质与我们想要检索的内容存在显著差异，导致语义相似度搜索不精确。这种不一致导致了不可靠的应用决策。
• 语气不当。在谈判中，回复的语气至关重要。该应用经常生成要么过于防御、要么过于积极的回复，导致沟通不自然且不可接受。
• 缺乏泛化能力。当遇到操作手册中未明确涵盖的谈判场景时，该应用会产生实际上随机的回复，这限制了它在新场景中的实用性。

迭代 2：反馈

认识到仅依赖操作手册方法的局限性，我们明白代理需要更具适应性，并能从真实世界的互动中持续学习。这促成了一个由律师直接反馈驱动的自我学习循环的开发。

最初，我们的反馈机制很简单：我们保存律师的决定（接受/拒绝/修改）、原文、红线标注以及一个点踩信号。这提供了一个基本的错误信号，但缺乏重要的细微差别。

为了加深系统的理解，我们将反馈循环升级为捕获律师的预期操作和具体评论。当我们引入 AI 起草修改内容的功能时，我们进一步扩展了这一点，以收集律师使用的最终修改文本。这些细粒度数据被证明是一个转折点。它使我们能够将对方的意图直接映射到律师精确、改进后的语言上。智能体开始变得更加准确，适应团队偏好的风格和谈判姿态。

我们还开始在建议界面中直接展示相关的历史反馈和规则。这让律师能够了解建议生成的原因，从而建立信任，并让他们确切地看到是什么影响了 AI 的输出。

在运行时，智能体会查询这个反馈存储库，其中现在包含数千次历史交互。系统首先进行带元数据过滤的相似性搜索，将候选范围缩小到约 20 份相关文档。然后，这些候选文档会通过使用最先进的 LLM 的第二层过滤，以验证其是否符合用户和对方的意图。接着，智能体会分析最相关的示例，以决定是否接受所提出的修改，并为对方生成评论。

我们还实施了一种指数衰减加权算法来构建未来提示的上下文。该机制优先考虑近期的决定，确保智能体适应不断变化的法律立场并缓解概念漂移，同时保持同意和不同意示例的均衡分布。这种动态、均衡的少样本提示使红线标注工具能够近乎实时地学习用户偏好和政策细微差别，而无需手动微调模型。

图 5：反馈——第一次迭代。

进一步的优化涉及战略性数据修剪，以确保搜索结果的准确性更高。这种迭代增强使应用性能得以持续改进，并产生了一个高质量的标注数据集，这对于跟踪质量回归和推动持续改进至关重要。

图 6：反馈——进一步优化。

迭代 3：语气

为了解决语气这一长期存在的挑战，我们在处理管道的末尾集成了一个额外的 LLM 调用，专门用于调节输出的语言风格。但我们很快发现，在法律谈判中把握好语气比听起来要难。

早期的输出在两种失败模式之间摇摆：有时过于防御性和对抗性；有时又不恰当地迁就和急于讨好。两者都不符合我们的律师在实际谈判中所使用的克制、专业的语气。

突破来自于与内部法务团队的密切合作。认识到语气是法律沟通的关键组成部分，我们授权律师直接负责定义所需语气和对话风格的具体语言。我们的工程团队负责架构，而内部法务团队负责三部分提示架构的内容。

图 7：包含语气、风格和对话开场白的提示词结构。

我们请律师更新的提示词的第一部分是目标。该部分定义了语气调节代理的角色。它通过假设代理生成的评论存在我们之前遇到过的问题，来实现一种主动式和悲观式的 AI 反思技术。

其他反思技术涉及复杂循环以实现对期望行为的收敛。我们发现，质量不佳的假设不会影响正面示例，但即使仅进行一次尝试，也能以高可靠性充分纠正负面示例。我们将此归因于复杂度的降低，因为在单个提示词中，大语言模型（LLM）需要做出的决策减少了一个。缺少循环也限制了 token 用量和延迟。

图 8：使用反思来改进语气。

接下来，我们向节点提示律师偏好的风格。由于该代理旨在代表律师提供首轮回复，我们必须确保代理直接、使用第一人称，并且不进行闲聊。

最后，我们提供了一个部分，供 Uber 的内部律师提供对话开场白句子作为少样本示例。

几天之内，他们就将其调整得与自己的语气完全一致。这带来了一个关键洞察：直接影响输出格式的提示词，应由应用领域的专家或最终用户来编写和管理，由 AI 团队提供指导，以确保符合提示词最佳实践。

图 9：由领域专家影响的反馈和语气改进。

迭代 4：智能体化修改

虽然判断是否接受或拒绝一项更改很有价值，但对律师来说真正节省时间的是起草反提案。简单的生成式文本经常会臆造条款或偏离合同中定义的术语。

为了解决这个问题，我们从简单的文本生成转向了智能体化工作流。当做出 MODIFY 决定时，我们会参考历史反馈和规则来完善条款。

这使得该工具能够帮助律师起草高质量的折中方案语言，反映先前的法律指导，并针对每个特定问题纳入公司的整体风险立场。

规则数据库

最后，我们意识到律师经常使用自己的模板，而这些模板通常在团队间共享。这一洞察带来了两大优势：

• 可重复的问题。律师收到的问题具有很大的共性，而反复以一致的语气阐述 Uber 的立场非常耗时。
• 一致的搜索键。由于原始文档始终使用相同的语言，当文档发生更改时，我们可以生成可靠的搜索键。

为了利用这些优势，我们为律师开发了一个规则数据库。这使他们能够在原始模板文档中选择重要或经常修改的文本，并将其与规则关联起来。规则封装了 Uber 的立场、任何备选立场以及期望的应用响应示例。当应用程序检测到更改时，它会对修改后的句子与我们的规则索引执行语义向量搜索。如果规则以高置信度匹配，则将其注入上下文窗口。为了确保严格遵守，工作流程中还纳入了最终的 LLM 步骤，以验证最终输出是否与检索到的规范精确一致。

图 10：规则处理如何融入整体图景。

当将此工具扩展到更多业务线时，规则数据库将提供次要好处，帮助律师在整个公司范围内保持法律立场的一致性。

架构

该架构遵循瘦客户端模式：Word 加载项处理文档交互和用户输入，而 Python 后端则协调所有 AI 操作。当律师触发分析时，后端会运行 LangGraph™ 工作流，将意图检测、风险评估和策略查找并行化。向量存储（OpenSearch®）提供记忆层，检索相关规则和历史反馈，为每项决策提供依据。

图 11：整体系统架构。

Microsoft Word 加载项：在律师工作的地方满足他们

一个关键的设计决策是将助手构建为 Microsoft Word 加载项，而不是独立的 Web 应用程序。律师生活在 Word 中，因此要求他们在工具之间复制粘贴会扼杀采用率。

该加载项基于 React 和 TypeScript 构建，作为任务窗格与文档并行运行。它通过 Microsoft Office® JavaScript API 与 Word 通信，以读取修订、应用修改并突出显示正在审查的条款。

这种集成并非没有挑战。Office JavaScript  API 存在重大限制，需要创造性的解决方法：

• 性能：Office JavaScript  API 本身很慢，需要我们在应用层通过积极的缓存和最小化与 Word 的往返次数来进行优化。
• API 缺陷：修订 API 存在边缘情况，在某些文档结构上会导致崩溃，需要防御性加载策略。
• 缺失功能：修订中被删除的文本会返回空字符串，需要我们维护自己的文本状态以实现准确的差异显示。

这些限制塑造了我们的架构：一个精心协调 Word 操作的瘦客户端，配合一个处理所有繁重 AI 工作的后端。

高性能编排

我们通过并行化独立的图节点来同时优化延迟和准确性。例如，当 意图节点分析对手方的有意义意图时，风险等级节点会同时评估该条款的危险状况。

混合决策引擎：规则与学习

为了在灵活性和合规性之间取得平衡，我们设计了一个混合系统，对硬逻辑和软逻辑区别对待。

对于不可协商的政策，我们使用确定性规则引擎。与标准RAG不同，它仅在与目标句子严格语义匹配时才触发。如果规则匹配，它将作为硬性护栏，覆盖模型的输出。

对于可协商的细微差别（语气、策略），我们依赖概率性反馈循环。

这种方法使我们能够引导系统启动，从第1天起就基于规则交付高置信度的结果，同时反馈循环积累处理更复杂、非结构化场景所需的数据。

通过反馈实现自我学习

我们自我学习能力的核心是一个反馈循环，它消除了对模型进行手动微调的需求。我们捕获了每一次律师交互的完整快照。这个结构化数据集包括原始上下文（合同文本、对方的修订标记）、AI的分析（意图、风险等级），以及最关键的，律师的完整回应：他们的最终决定、他们应用的任何具体文本修改，以及他们的书面理由。这些细粒度数据使系统不仅能建模决定了什么，还能建模为什么这样决定，使其能够在未来的类似场景中复制资深法律顾问的细微判断。

时间加权的自我学习

为了防止模型可能过度依赖过时法律立场而导致的概念漂移，我们实现了一个基于指数衰减的自定义反馈采样算法。在为上下文窗口检索少样本示例时，我们会为每个历史交互计算一个权重。

图12：自定义反馈采样算法。 

其中λ对应一个可配置的半衰期（当前设置为365天）。这确保了模型能够适应不断变化的法律立场和概念漂移，而不会过度依赖过时的先例。实际上，系统能够近乎实时地学习团队当前的偏好，就像人类同事会领会新的规范一样。

数据存储与向量搜索

我们的知识库依赖于OpenSearch，利用nomic-embed-text-v15嵌入进行高维语义检索。我们维护两个主要索引：

• 规则索引： 存储法律政策，按目标句子进行向量化。
• 反馈索引： 存储历史谈判数据，按对方的意图而非原始文本进行向量化，使我们能够捕捉表述不同但语义相同的修改。

当检测到新的修订标记时，系统会对这些索引执行语义向量搜索，以检索最相关的规则和过往决定，确保AI拥有提出修改建议所需的准确上下文。

提高OpenSearch中规则和反馈的检索准确率

我们在该问题领域的一个优势是，谈判总是从同一份源合同开始。这意味着我们可以将学习成果和反馈锚定到同一文档多次交互中的相同章节。 

首先，我们将法律合同拆分为以 ';'、'.' 或 '\n' 字符分隔的小片段。然后，每当系统遇到红线修改时，我们就在原始源句子上进行查找，以检索保证相关的历史出现情况或明确规则。每当用户与系统交互并提供反馈时，用于摄入数据库的正是逐字相同的源句子。

图 13：利用 OpenSearch 提高规则和反馈检索的准确性。

实现查询嵌入和输入嵌入的对称性以获得最佳搜索性能非常重要。在我们的案例中，存储的嵌入和嵌入的查询保证是相似的，因为它们都源自合同。由于文档可能会随着律师每一轮的批注而发生细微变化，因此仍然需要相似性搜索。

会话记忆

对于对话界面，我们使用 Redis®  来维护会话状态，使律师能够就文档提出后续问题。在幕后，我们运行持续的 LLM-as-a-judge 评估，以监控检索上下文的质量（document_quality_metric）以及模型对公司规则的遵守情况（rule_adherence_metric）。

当前方法：Harness 工程

作为我们在 Uber 开展的 Agentic AI 工作的一部分（包括 Legal AI），我们正在探索 Claude Code® 和 OpenCode® 等 agentic harness，并结合技能来构建和自动化工作流程。与此同时，我们将探索引入法律本体和知识图谱，为表示法律概念和关系提供语义基础，从而实现更一致的解释和可靠的推理。

结论

我们经历的这些迭代历程，从最初的 RAG 系统到整合用户反馈、优化语气以及实施强大的规则数据库，都表明构建一个真正有效的 AI 驱动法律助手是一个由持续学习和与领域专家紧密协作驱动的迭代过程。我们遇到的每一个挑战都成为了加深理解并完善系统的机会，最终打造出一个更准确、更适应需求且以用户为中心的工具，真正增强人类在复杂法律谈判中的专业能力。

致谢

我们要感谢 Alissa McDowell 的密切合作和领域专业知识，以及 Uber Legal、AI Platform 团队及其领导层 Michelle Parker 和 Viv Keswani 对将 AI 引入 Uber Legal 这一努力的支持。

封面图片来源：由 OpenAI ChatGPT Images 生成。

Claude 及其标志是 Anthropic, PBC 在美国和其他国家/地区的注册商标。使用这些标志并不意味着 Anthropic, PBC 的认可。

Codex 及其标志是 OpenAI OpCo, LLC 在美国和其他国家/地区的注册商标。使用这些标志并不意味着 OpenAI OpCo, LLC 的认可。

FastAPI 及其标志是 Sebastián Ramírez 在美国和其他国家/地区的注册商标。使用这些标志并不意味着 Sebastián Ramírez 的认可。

LangChain 和 LangGraph 及其标志是 LangChain Inc. 在美国及其他国家/地区的注册商标。使用这些标志并不意味着 LangChain Inc. 的认可。

Microsoft Word、Microsoft Office、Office JavaScript API、TypeScript 及其标志是 Microsoft Corporation 在美国及其他国家/地区的注册商标。使用这些标志并不意味着 Microsoft Corporation 的认可。

OpenSearch 及其标志是 LF Projects, LLC 在美国及其他国家/地区的注册商标。使用这些标志并不意味着 LF Projects, LLC、OpenSearch Project 或 OpenSearch Community 的认可。

Python 及其标志是 Python Software Foundation 在美国及其他国家/地区的注册商标。使用这些标志并不意味着 Python Software Foundation 的认可。

React 及其标志是 Meta Platforms, Inc. 在美国及其他国家/地区的注册商标。使用这些标志并不意味着 Meta Platforms, Inc. 的认可。

Redis 及其标志是 Redis Ltd. 在美国及其他国家/地区的注册商标。使用这些标志并不意味着 Redis Ltd. 的认可。