从 RAG 失败到 91% 准确率：Uber 法务红线 Agent 的四次架构演进

Uber 每年要谈判数千份合同。每一份合同背后都有一支法务团队在审阅、谈判，这件事重复、耗时，并且经常卡住交易、供应商入驻和产品上线——一旦拖延，销售、入驻和上线都会受影响。

但这份看上去门槛很高的工作里，藏着大量结构性的东西：相似的条款反复出现，红线修改在不同客户之间可以复用，法律立场长期稳定。也就是说，它其实是有体系的——这跟代码审查、客服回复那些已经被 AI 渗透进去的领域同构，只是领域知识的壁垒更高。

Uber 把这件事做成了一个产品：Legal Redlining Agent（法务红线 Agent，下文简称 LRA）。它做出来的结果是，平均合同审核时间下降 20% 以上，AI 生成决策的准确率 91%。2026 年 3 月 9 日，LRA 作为 Uber 法务部获奖方案的一部分，拿到 ALM Legalweek Leaders in Tech Law Awards 的「年度最具创新力法务部」。

四次迭代总览：从 RAG 到 Agent 的演进路径

版本	核心变化	解决的问题	关键工程细节
第 1 版	朴素 RAG：把谈判 playbook 灌进检索管道	—（失败）	语义检索粒度错位、语气失控、无法泛化
第 2 版	从「从文档学」改为「从决策学」，捕获真实决策轨迹	静态 playbook 覆盖不了动态偏好	两段式检索（约 20 候选 → LLM 精筛）、指数衰减半衰期 365 天、正负样本均衡 few-shot
第 3 版	单独加一个 LLM 调用做语气调制	注释过度防御或过度让步	「proactive and pessimistic」单次反思；三段式 prompt 交给律师维护
第 4 版	对 MODIFY 决策引入 agentic 工作流	生成文本会编造条款、偏离已定义术语	参考历史反馈 + 规则库起草反提案
规则库	律师维护的确定性兜底	冷启动期没有历史数据	语义向量匹配 + 高置信度注入 + 最终 LLM 校验

一、三条产品哲学，决定了后面所有技术选型

原文把三条哲学放在最前面讲，因为它后面每一个技术决定都能回溯到这三条：

产品哲学	具体做法	技术后果
在律师干活的地方交付	做成 Microsoft Word 插件，而不是另开一个 Web 工具	放弃独立应用，接受 Office JS API 的各种限制
增强而不是替代律师判断	AI 只给建议：accept / reject / modify，并附上理由注释，决策权在律师	系统定位是「第一遍」，不是「最终稿」
用真实反馈持续迭代	把律师的每一次决策都收集回来	直接催生了第二版的核心架构

二、第一版：朴素 RAG，为什么失败

第一版的思路很标准：法务团队提供现有的谈判 playbook 和谈判回合示例，把 playbook 灌进 RAG 管道，用语义检索找出相关段落，连同对方的改动一起喂给大模型，让它生成决策。

然后撞上三个失败模式：

1. 语义检索失准。 用来做嵌入的「关键句」和实际需要检索的内容粒度对不上——query 和 document 说的不是一回事，于是检索结果飘，决策也就不可靠。

2. 语气失控。 生成的注释要么过度防御、要么过度让步。在法律谈判里，语气本身就是立场，这两头都不合格。

3. 无法泛化。 遇到 playbook 里没写过的谈判场景，输出基本等于随机。

原文对第一版的总结是：playbook 里的静态知识，和律师实际谈判中的动态偏好之间，隔着一道鸿沟。文档不等于决策数据。

三、第二版：从「从文档学」改成「从决策学」

第二版是转折点。放弃从文档里学，改成从决策里学。

系统开始捕获每一次真实谈判的完整轨迹，粒度细到：

捕获项	内容
对方原始措辞	counterparty 的原始改动
律师的红线	律师划出的边界
期望动作	accept / reject / modify
律师写的注释	律师给出的理由
最终修改文本	律师实际采用的措辞

这些对齐数据让系统能把「对方意图」直接映射到「本方律师偏好的应对语言」，而不是停留在词面相似。原文说得很直白：这一步之后，agent 才开始明显变准，风格和谈判姿态都开始贴近团队。

运行时的流程分两段：

1. 相似度检索 + 元数据过滤，先把范围收窄到约 20 个候选；

2. 再用一层 LLM 精筛，判断这些候选是否真的贴合双方意图，然后才生成决策和注释。

两个工程细节值得单独拎出来：

• 指数衰减加权，半衰期 365 天。 给每一条历史交互算权重时按指数衰减，优先采信近一年的决策。目的是对抗策略漂移——对方立场和公司内部政策都会变，老案例不能一直当权威；同时保证 agree / disagree 两类样本分布均衡。

• 正负样本均衡的 few-shot。 把「同意」和「不同意」的案例成对呈现，让模型学的是判别边界，而不是单边模仿。

原文的关键结论：不需要任何手动微调，靠检索 + 上下文学习就能持续进化。 另外他们还在建议界面里把命中的历史反馈和规则显示出来，让律师知道这条建议是怎么来的——这是信任问题，不是技术问题。

四、第三版：把语气单独拆出来，然后把 prompt 交给律师

语气的问题在第一版就存在，第二版没解决，第三版单独加了一个 LLM 调用做语气调制。

有意思的是那个技巧，原文叫「proactive and pessimistic」的一次性反思：让模型预先假设自己生成的注释就是有质量问题的，在一次调用里完成自检和修正。效果跟反思循环接近，但只花一次调用的 token 和延迟。原文的解释是，这么做等于让 LLM 少做一个决定，复杂度降下来了；而且「假设质量差」这个前提不会伤害本来就正确的样例，却能以较高可靠性修正错误样例。

更大的突破不在模型，在组织：三段式 prompt 的所有权直接交给了律师。

三段分别是：

1. 目标：定义语气调制 agent 的角色，也就是上面那个「先假设有问题」的反思机制；

2. 偏好风格：要求直接、第一人称、不寒暄——因为这个 agent 是替律师出第一遍稿；

3. 开场白示例：由 Uber 内部律师提供对话起始句作为 few-shot 样例。

工程团队管结构，法务团队管内容。几天之内，律师就把它调成了自己的语气。原文由此得出结论：直接影响输出格式的 prompt，应该由领域专家来维护，AI 团队负责确保 prompt 的最佳实践，而不是由工程师替律师定义「什么叫专业语气」。

五、第四版：从「建议」到「起草」

判断一个改动该不该接受，价值有限。律师真正省时间的地方是写反提案，而简单让模型生成文本，很容易编出合同里根本不存在的条款，或者偏离已定义的术语。

所以第四版对 MODIFY 这个决策引入了 agentic 工作流：参考历史反馈和规则库来起草修改文本。到这一步，系统从「建议者」升级成了「起草者」。

六、规则库：确定性兜底，也是跨业务线一致性的抓手

规则库（Rules Database）解决的是另一个问题：律师经常用自己的模板，而这些模板往往跨团队共用。这带来两个好处——问题高度重复、检索键天然一致（原文档总是用同样的措辞）。

用法是律师自己维护：在原始模板里选中重要或常被修改的条款，附上一条规则。一条规则包含三样东西：Uber 的立场、可退让的底线、期望的回复示例。

运行时，应用对修改后的句子在规则索引里做语义向量检索，高置信度命中就直接注入上下文；最后还有一个 LLM 校验步骤，确认输出严格贴合检索到的规则。

它的价值有两层：

• 第一天就能用：规则库不像反馈库需要冷启动积累，上线就能给出高置信度结果；

• 跨业务线立场一致：把工具扩展到其他业务线时，规则库能帮公司维持法律立场的一致性。

七、架构：薄客户端 + Python 后端

整体是薄客户端模式：Word 插件只负责文档交互和用户输入，所有 AI 操作交给一个 Python 后端编排。

律师触发分析后，后端跑一个 LangGraph 工作流，把意图识别、风险评估、策略检索并行化。记忆层用 OpenSearch 做向量存储，检索相关规则和历史反馈来给每个决策提供依据。

组件	作用
Word 插件（React + TypeScript）	以任务窗格形式嵌在文档旁边，通过 Office JavaScript API 读取修订、应用修改、高亮待审条款
Python 后端（LangGraph 工作流）	编排所有 AI 操作，并行跑意图、风险、策略三个分支
OpenSearch 向量存储	两条索引：规则索引、反馈索引
Redis	会话记忆，支撑追问式交互
Uber 内部 GenAI Gateway	团队不用自己管模型接入，精力全部放在产品逻辑上

八、Word 插件的三个坑

把助手做成 Word 插件而不是独立 Web 应用，是一个关键决定——律师就生活在 Word 里，让他们在两个工具之间复制粘贴，采纳率会大打折扣。

代价是 Office JavaScript API 的限制，原文列了三个：

• 性能。 这个 API 本身就慢，只能在应用层优化：激进缓存 + 尽量减少与 Word 的往返次数。

• API bug。 修订（tracked changes）API 在特定文档结构上有边界情况会直接崩，需要防御式的加载策略。

• 功能缺失。 修订里被删除的文本返回的是空字符串，所以得自己维护一份文本状态，才能把 diff 正确显示出来。

这三个限制反过来塑造了架构：客户端要薄、对 Word 的调用要精打细算，重活全部扔给后端。

九、混合决策引擎：硬规则覆盖模型，软判断交给反馈

这一层的做法是把「硬逻辑」和「软逻辑」分开处理。

• 不可谈判的政策 → 走确定性的规则引擎。它和常规 RAG 不同，只在严格语义匹配到目标句子时触发，一旦命中就是硬护栏，直接覆盖模型输出。

• 可以谈判的细节（语气、策略） → 交给概率性的反馈闭环。

这样做的收益是：第一天就能靠规则给出高置信度结果，而反馈闭环同时在后台积累数据，慢慢接手更复杂、更非结构化的场景。

十、检索为什么能准：三个细节

RAG 失败的那一版问题出在检索，所以后面对检索做了不少针对性处理。

1. 按源句分块，锚定同一个位置。 谈判总是从同一份源合同开始，这是他们的结构性优势——可以把学习和反馈锚定在同一份文档的同一段落上。做法是把合同按 ;、.、\n 切成小块；每次遇到修订，都用原始源句去查历史命中或显式规则；律师给反馈时，入库用的也是同一句原文。

2. 保证查询与入库的嵌入对称。 存储的嵌入和查询的嵌入都来自合同本身，天然相似，检索性能最好。之所以还需要相似度检索，是因为文档会随每一轮律师批注发生细微变化。

3. 两条索引的向量化口径不一样。

索引	存什么	按什么向量化
规则索引	法律政策	目标句子
反馈索引	历史谈判数据	对方的意图，而不是原始文本

反馈索引按意图向量化，是为了抓住「说法不同但意思一样」的改动。嵌入模型用的是 nomic-embed-text-v15 做高维语义检索。

十一、会话记忆与质量监控

对话界面用 Redis 维持会话状态，律师可以就文档继续追问。

后台则持续跑 LLM-as-a-judge 评测，监控两件事：检索到的上下文质量（document_quality_metric），以及模型对公司规则的遵循度（rule_adherence_metric）。评测是持续跑的。

十二、今天会怎么做：harness engineering

原文最后给了「如果今天重做」的方向。

Uber 在推进整套 Agentic AI 的时候，正在探索 Claude Code 这类 agentic harness（原文写作 harness engineering），配合 skills 来结构化和自动化工作流。同时他们打算引入法律本体和知识图谱，给法律概念与关系建立语义基础，让解释更一致、推理更可靠。

这一代系统是 2024 年初到 2025 年做出来的，那时候这类 agent harness 还不普及。原文也把「最持久的教训」归给了非技术部分：真正难的不是模型或架构，而是把 agent 顺利带进律师的日常工作。

十三、这套路径能迁移到哪

把法律换成别的领域，这条路径里可复用的部分大致是这些：

可迁移做法	适用前提
交付在工作现场（插件/IDE/工单系统），而不是新开一个工具	用户已经在某个高频工具里完成主要工作
决策数据优先于文档数据	有稳定的重复性决策，并且能捕获决策轨迹
指数衰减加权 + 正负样本均衡	领域策略会随时间漂移，老案例不能一直当权威
硬规则护栏 + 软反馈学习并行	存在「不可谈判」的硬约束，同时又有大量可协商的细节
把输出格式类 prompt 交给领域专家维护	输出的语气、格式本身就是业务的一部分
用严格语义匹配触发硬规则，而不是常规 RAG	需要确定性、可审计的行为
锚定同一源句做检索与入库	每轮交互都从同一份原始文档出发

反过来，这套东西的前提也需要说清楚：它建立在有大量历史决策可学、且专家愿意持续反馈的基础上。原文里两个数字——审核时间下降 20% 以上、决策准确率 91%——是 Uber 法务团队自己的口径，来自内部分享，原文没有给出评测集规模、统计窗口和口径定义。另外，LRA 的定位始终是「给建议」，最终判断仍然由律师做出。

数字来源与口径

数字/事实	出处
每年谈判数千份合同	Uber 官方博客（The Problem 一节）
平均合同审核时间下降 20% 以上	Uber 官方博客（自述；未给统计窗口与口径）
AI 生成决策准确率 91%	Uber 官方博客（自述；未给评测集规模）
2026 年 3 月 9 日获 ALM Legalweek「年度最具创新力法务部」	Uber 官方博客：LRA 是其获奖方案的一部分
检索候选约 20 个、半衰期 365 天	Uber 官方博客（Iteration 2 / Time-Weighted Self-Learning）
五次迭代描述（RAG → 反馈 → 语气 → agentic → 规则库）	推文摘要与 Uber 官方博客一致
项目时间：2024 年初起至 2025 年，2025 年与法务团队试点	Uber 官方博客（Introduction）