Introduction引言

Few domains demand as much precision and care as legal work, making it a hard test for putting an AI agent into daily practice. Beginning in early 2024 and continuing through 2025, before today’s agent harnesses were widely available, Uber built the first generation of our Legal Redlining Agent (LRA). It helps Uber Legal teams handle high-volume contract negotiations without compromising trust or compliance, and without replacing a lawyer’s judgment.很少有领域像法律工作那样要求极高的精准度和严谨性，这使其成为将AI智能体投入日常实践的严苛试验场。从2024年初到2025年，在当今的智能体框架广泛普及之前，Uber构建了第一代法律修订智能体（LRA）。它帮助Uber法律团队处理大量合同谈判，既不损害信任或合规性，也不取代律师的专业判断。

The most durable lesson wasn’t about the model or architecture; it was about bringing an agent successfully into lawyers’ day-to-day work. We started from the business problem: a steady stream of contract negotiations involving substantial repeatable redline work. We met lawyers where they already work, inside Microsoft Word®, so LRA could flag risky redlines and suggest edits within their existing workflow. We then iterated closely with lawyers on what the agent should do, piloting it with our Legal team in 2025 and folding their feedback back into the product.最持久的经验教训并非关于模型或架构，而是如何成功地将智能体引入律师的日常工作中。我们从业务痛点出发：处理源源不断的合同谈判，其中涉及大量可重复的修订工作。我们深入律师现有的工作环境——Microsoft Word®，使LRA能够在他们现有的工作流程中标记高风险修订并建议修改。随后，我们与律师密切合作，针对智能体的功能进行迭代，于2025年在我们的法律团队中进行试点，并将他们的反馈融入到产品中。

In this blog, we share what we learned bringing that first generation into practice: framing the problem, earning lawyers’ trust, and improving the agent through their feedback. We close with how the first-generation system worked and how we would approach the problem today as agent technology has evolved.在本篇博客中，我们将分享将第一代产品投入实践的经验：如何界定问题、赢得律师信任，以及通过反馈改进智能体。最后，我们将介绍第一代系统的工作原理，以及随着智能体技术的发展，我们今天将如何应对这一问题。

On March 9, 2026, LRA was part of Uber Legal’s winning submission for Most Innovative Legal Department of the Year at the ALM Legalweek Leaders in Tech Law Awards.2026年3月9日，LRA作为Uber法律团队提交的参赛作品之一，荣获ALM Legalweek科技法律领袖奖之“年度最具创新力法律部门奖”。

Figure 1: Legal Redlining Agent in action.图1：法律修订智能体运行界面。

The Problem: High Stakes, High Friction

At Uber, thousands of contracts are negotiated every year. Behind each one is a legal team reviewing and negotiating these contracts. This process can be time-consuming, repetitive, and often a bottleneck for deals, onboarding, and launches. It’s high-stakes, detail-oriented work where precision matters and delays ripple across sales, onboarding, and launches.在Uber，每年有数千份合同需要谈判。每一份合同背后都有一个法律团队在进行审查和协商。这个过程可能既耗时又重复，往往成为交易、入职和上线流程的瓶颈。这是一项高风险、注重细节的工作，精准度至关重要，任何延误都会对销售、入职和上线产生连锁反应。

Yet, buried inside this high-stakes process was something surprisingly structured: similar clauses, repeatable redlines across clients, and standing legal reasoning patterns. In other words, there was a clear system.然而，在这个高风险流程的深处，隐藏着一些出人意料的结构化内容：相似的条款、跨客户的可重复修订，以及固定的法律推理模式。换句话说，这背后存在一套清晰的系统。

Since the legal organization’s work is mission-critical to Uber, we saw an opportunity to automate repeatable parts and free up lawyers’ time for complex judgment calls, all without sacrificing quality or consistency.由于法律团队的工作对Uber至关重要，我们看到了自动化重复性工作的机会，从而让律师能够腾出时间专注于复杂的判断决策，同时又不牺牲质量或一致性。

Figure 2: Contract review lifecycle and average support times for enterprise deals.图2：合同审查生命周期及企业交易的平均支持时间。

The Solution: An AI-Powered Redlining Agent

The Legal Redlining Agent is an AI-powered smart assistant integrated directly into Microsoft Word as an add-in, where lawyers already work. It reviews client edits, understands intent, recommends policy-aligned responses, generates structured comments, flags risks, and continuously learns from feedback.法律修订智能体是一款AI驱动的智能助手，直接集成在律师日常使用的Microsoft Word中作为插件。它审查客户的修改，理解其意图，推荐符合政策的回复，生成结构化注释，标记风险，并持续从反馈中学习。

It combines:它结合了：

• Document review to identify redlines (edits made by clients versus by Uber lawyers)文档审查，以识别修订（客户与Uber律师所做的修改）
• Intent detection to interpret proposed changes意图检测，以解读提议的变更
• Policy-aligned recommendations to accept, reject, or modify clauses符合政策的建议，以接受、拒绝或修改条款
• Comment generation to explain Uber’s legal position注释生成，以解释Uber的法律立场
• Risk flagging to highlight clauses needing deeper review by the lawyers风险标记，以突出需要律师深入审查的条款
• Self-learning feedback loop to improve future recommendations自学习反馈循环，以改进未来的建议

Since launching with our Legal team, we’ve seen an over 20% reduction in average contract review time and 91% accuracy in AI-generated decisions. We’ve  also received feedback like, “It saved me real time; especially with comment suggestions.”自法律团队上线以来，我们观察到合同平均审查时间缩短了20%以上，AI生成的决策准确率达到91%。我们也收到了诸如“它确实节省了我的时间，特别是在注释建议方面”之类的反馈。

What is the Legal Redlining Agent?什么是法律修订智能体？

The add-in analyzes a Microsoft Word document and identifies any redlines from external parties. Using AI, it then processes these changes, attempting to understand the client’s intent and the legal implications. It compares the proposed changes against our team’s legal policies and guidelines.该插件分析Microsoft Word文档并识别外部方的任何修订。随后，它利用AI处理这些变更，试图理解客户的意图和法律影响，并将提议的变更与我们团队的法律政策和指南进行对比。

Based on this analysis, the add-in generates a series of suggestions, which includes recommended actions, proposed comments back to the client that justify these recommendations with legal reasoning, and an assessment of the risk level associated with each change. Uber lawyers then review each suggestion, deciding whether to accept, reject, or modify it before final incorporation into the client response.基于此分析，该插件会生成一系列建议，包括推荐的操作、向客户回复的建议注释（以法律推理证明这些建议的合理性），以及对每次变更相关风险级别的评估。Uber律师随后会审查每项建议，决定在最终合并到客户回复之前接受、拒绝或修改它。

Figure 3: High-level workflow of the Legal Redlining Add-in / Agent.图3：法律修订插件/智能体的高层工作流程。

Iteratively Improving the Legal Redlining Agent

The system we just described didn’t emerge fully formed. Getting here required four major iterations, each teaching us hard lessons about what Legal AI actually requires.我们刚才描述的系统并非一蹴而就。达到这一步需要经过四次重大迭代，每一次都让我们深刻认识到法律AI的真正需求。

Along the way, we used Uber’s GenAI Gateway, which allowed us to focus entirely on refining the product logic, working closely with subject matter experts. 在此过程中，我们使用了Uber的GenAI Gateway，这使我们能够完全专注于优化产品逻辑，并与主题专家密切合作。

Iteration 1: RAG迭代1：RAG

Our initial approach to the problem focused on developing a foundational RAG (Retrieval Augmented Generation) system. The Legal team provided existing playbooks and examples of negotiation turns. Our hypothesis was that by ingesting these playbooks to identify semantically relevant sections, and then feeding these sections along with proposed counterparty changes to an LLM (Large Language Model), the system would generate sound decisions.我们最初的方法侧重于开发一个基础的RAG（检索增强生成）系统。法律团队提供了现有的手册和谈判案例。我们的假设是，通过摄入这些手册以识别语义相关的部分，然后将这些部分连同交易对手的提议变更一起输入大语言模型（LLM），系统就能生成合理的决策。

Figure 4: RAG (Retrieval Augmented Generation) flow.图4：RAG（检索增强生成）流程。

• Inaccurate semantic similarity. The nature of the “key” we aimed to embed differed significantly from the content we sought to retrieve, resulting in imprecise semantic similarity searches. This inconsistency led to unreliable application decisions.语义相似度不准确。我们旨在嵌入的“键”的性质与我们试图检索的内容存在显著差异，导致语义相似度搜索不精确。这种不一致导致了不可靠的应用程序决策。
• Inappropriate tone. During negotiations, the tone of a response is critical. The application frequently generated replies that were either overly defensive or excessively positive, leading to unnatural and unacceptable communication.语气不当。在谈判中，回复的语气至关重要。该应用程序经常生成过于防御或过度积极的回复，导致沟通不自然且不可接受。
• Lack of generalization. The application produced effectively random responses when encountering negotiation scenarios not explicitly covered in the playbooks, limiting its utility in novel situations.缺乏泛化能力。在遇到手册中未明确涵盖的谈判场景时，应用程序会产生随机回复，限制了其在创新情况下的实用性。

Iteration 2: Feedback迭代2：反馈

Recognizing the limitations of a playbook-only approach, we understood the need for the agent to be more adaptable and to learn continuously from real-world interactions. This led to the development of a self-learning loop powered by direct lawyer feedback.意识到仅靠手册方法的局限性，我们明白智能体需要具备更强的适应性，并能从现实世界的交互中持续学习。这促使我们开发了一个由律师直接反馈驱动的自学习循环。

Initially, our feedback mechanism was simple: we saved the lawyer’s decision (accept/reject/modify), the original text, the redline, and a thumbs-down signal. This provided a basic error signal but lacked important nuances.起初，我们的反馈机制很简单：我们保存了律师的决定（接受/拒绝/修改）、原始文本、修订内容以及“踩”的信号。这提供了一个基本的错误信号，但缺乏重要的细微差别。

To deepen the system’s understanding, we evolved the feedback loop to capture the lawyer’s expected action and specific comments. When we introduced the ability for the AI to draft modifications, we further expanded this to collect the final modified text used by the lawyer. This granular data proved to be a turning point. It enabled us to map the counterparty’s intent directly to the lawyer’s precise, improved language. The agent started getting much more accurate, adapting to the team’s preferred style and negotiation postures.为了加深系统的理解，我们改进了反馈循环，以捕获律师的预期操作和具体评论。当我们引入AI起草修改意见的功能时，我们进一步扩展了该机制，以收集律师使用的最终修改文本。这些细粒度的数据成为了转折点。它使我们能够将交易对手的意图直接映射到律师精确且改进后的语言上。智能体开始变得更加准确，能够适应团队偏好的风格和谈判姿态。

We also started surfacing relevant past feedback and rules directly within the suggestion interface. This gave lawyers transparency into why a suggestion was generated, building trust and allowing them to see exactly what influenced the AI’s output.我们还开始在建议界面中直接呈现相关的过往反馈和规则。这让律师能够透明地了解建议生成的原因，从而建立信任，并让他们清楚地看到是什么影响了AI的输出。

At runtime, the agent queries this feedback store, which now contains thousands of previous interactions. The system first conducts a similarity search with metadata filtering, narrowing the pool to about 20 pertinent documents. These candidates are then passed through a second filtering layer using state-of-the-art LLMs to verify alignment with the user’s and counterparty’s intent. The agent then analyzes the most relevant examples to decide whether to accept or reject the proposed change and generates a comment for the counterparty.在运行时，智能体会查询这个反馈存储库，其中现在包含数千次先前的交互。系统首先进行带有元数据过滤的相似度搜索，将候选范围缩小到约20个相关文档。随后，这些候选内容通过第二层过滤，使用最先进的LLM来验证与用户和交易对手意图的一致性。智能体接着分析最相关的示例，以决定是接受还是拒绝提议的变更，并为交易对手生成注释。

We also implemented an exponential decay weighting algorithm to construct the context for future prompts. This mechanism prioritizes recent decisions, ensuring the agent adapts to shifting legal stances and mitigates concept drift, while maintaining a balanced distribution of agree and disagree examples. This dynamic, balanced few-shot prompting allows the redlining tool to learn user preferences and policy nuances in near-real-time without requiring manual model fine-tuning.我们还实现了一种指数衰减加权算法来构建未来提示词的上下文。该机制优先考虑最近的决策，确保智能体适应不断变化的法律立场并减轻概念漂移，同时保持同意和拒绝示例的平衡分布。这种动态、平衡的少样本提示（few-shot prompting）使修订工具无需手动微调模型，即可近乎实时地学习用户偏好和政策细微差别。

Figure 5: Feedback–the first iteration.图5：反馈——第一次迭代。

Figure 6: Feedback–further refinement.图6：反馈——进一步优化。

Iteration 3: Tone

Addressing the persistent challenge of tone, we integrated an additional LLM call at the end of the processing pipeline specifically to modulate the output’s linguistic style. But we quickly discovered that getting tone right in legal negotiations is harder than it sounds.为了解决持续存在的语气挑战，我们在处理流水线的末端集成了一个额外的LLM调用，专门用于调节输出的语言风格。但我们很快发现，在法律谈判中掌握语气比听起来要困难得多。

Early outputs oscillated between two failure modes: sometimes overly defensive and adversarial; other times inappropriately accommodating and eager to please. Neither matched the measured, professional tone our lawyers use in actual negotiations.早期的输出在两种失败模式之间摇摆：有时过于防御和对抗；有时又不恰当地迁就和急于取悦。两者都不符合我们律师在实际谈判中使用的审慎、专业的语气。

The breakthrough came from a close collaboration with the in-house Legal team. Recognizing that tone is a critical component of legal communications, we empowered the lawyers to take direct ownership of the specific language defining the desired tone and conversational style. Our engineering team managed the anatomy, but the in-house Legal team managed the content of the three-part prompt anatomy.突破来自于与内部法律团队的密切合作。认识到语气是法律沟通的关键组成部分，我们授权律师直接负责定义所需语气和对话风格的具体语言。我们的工程团队负责架构，但内部法律团队负责三部分提示词架构的内容。

Figure 7: A prompt anatomy that includes tone, style, and conversation starters.图7：包含语气、风格和对话开场白的提示词架构。

Other techniques for reflection involve complex loops to achieve convergence on the desired behavior. We found that the presumption of bad quality doesn’t affect positive examples, but sufficiently corrects negative examples at a high reliability even with just one shot. We attribute this to the reduction in complexity, due to one less decision that the LLM needs to make in the single prompt. The lack of loops also limits ‌token usage and latency.其他反思技术涉及复杂的循环以实现期望行为的收敛。我们发现，对质量不佳的预设不会影响正面示例，但即使只有一次尝试，也能以高可靠性充分纠正负面示例。我们将此归因于复杂性的降低，因为在单个提示词中，LLM需要做出的决策减少了一个。没有循环也限制了Token的使用和延迟。

Figure 8: Using reflection to improve tone.图8：利用反思来改善语气。

Finally, we provide a section for Uber’s in-house lawyers to give conversation starter sentences as few-shot examples. 最后，我们提供了一个部分供Uber内部律师提供对话开场白句子作为少样本示例。

Within days, they’d tuned it to match their voice precisely. This led to a crucial insight: prompts directly influencing output format should be crafted and managed by the application’s subject matter experts or end-users with AI teams guiding to ensure that prompting best practices are met.

几天之内，他们就将其调整为与自己的声音完全匹配。这引出了一个关键见解：直接影响输出格式的提示词应由应用程序的主题专家或最终用户编写和管理，并由AI团队指导，以确保符合提示词的最佳实践。

Figure 9: Feedback and tone improvements influenced by subject matter experts.图9：受主题专家影响的反馈和语气改进。

Iteration 4: Agentic Modifications

While determining whether to accept or reject a change is valuable, the real time-saver for a lawyer is drafting the counter-proposal. Simple generative text often hallucinates terms or drifts from the contract’s defined terms.虽然确定是否接受或拒绝变更很有价值，但对律师而言，真正的省时之处在于起草反建议。简单的生成式文本往往会产生幻觉条款或偏离合同的定义术语。

To solve this, we moved beyond simple text generation to an agentic workflow. When a MODIFY decision is reached, we reference historical feedback and rules to refine the clause.为了解决这个问题，我们超越了简单的文本生成，转向了智能体工作流。当做出“修改”决定时，我们会参考历史反馈和规则来优化条款。

This allows the tool to help lawyers draft high-quality proposed compromise language that reflects prior legal guidance and incorporates the company’s broader risk position for each particular issue.这使得该工具能够帮助律师起草高质量的拟议妥协语言，这些语言反映了先前的法律指导，并结合了公司针对每个具体问题的更广泛风险立场。

Rules Database规则数据库

Lastly, we realized that lawyers frequently work with their own templates, which are often shared across teams. This insight presented two advantages:最后，我们意识到律师经常使用他们自己的模板，这些模板通常在团队间共享。这一发现带来了两个优势：

• Repeatable questions. There’s significant commonality in the questions lawyers receive, and repeatedly articulating Uber’s position with a consistent tone is time-consuming.可重复的问题。律师收到的问题有很大的共性，反复以一致的语气阐述Uber的立场非常耗时。
• Consistent search keys. Since the original document consistently uses the same language, we can generate reliable keys for searching when a document undergoes changes.一致的搜索键。由于原始文档始终使用相同的语言，当文档发生变更时，我们可以生成可靠的搜索键。

To leverage these benefits, we developed a rules database for lawyers. This allows them to select important or frequently modified text within an original template document and associate a rule with it. A rule encapsulates Uber’s stance, any fallback positions, and an example of the desired application response. When the application detects a change, it performs a semantic vector search on the modified sentences against our rules index. If a rule matches with high confidence, it’s injected into the context window. To ensure strict adherence, a final LLM step is incorporated into the workflow to verify that the final output aligns precisely with the retrieved specifications.为了利用这些优势，我们为律师开发了一个规则数据库。这使他们能够在原始模板文档中选择重要或经常修改的文本，并为其关联一条规则。规则封装了Uber的立场、任何后备方案以及期望应用程序回复的示例。当应用程序检测到变更时，它会对修改后的句子与我们的规则索引进行语义向量搜索。如果规则以高置信度匹配，它就会被注入上下文窗口。为了确保严格遵守，工作流中加入了一个最终的LLM步骤，以验证最终输出是否与检索到的规范完全一致。

Figure 10: How rules processing fits into the overall picture.图10：规则处理如何融入整体图景。

Architecture架构

The architecture follows a thin-client pattern: the Word add-in handles document interaction and user input, while a Python back end orchestrates all AI operations. When a lawyer triggers an analysis, the back end runs a LangGraph™ workflow that parallelizes intent detection, risk assessment, and policy lookup. Vector stores (OpenSearch®) provide the memory layer, retrieving relevant rules and historical feedback to ground each decision.该架构遵循瘦客户端模式：Word插件处理文档交互和用户输入，而Python后端协调所有AI操作。当律师触发分析时，后端运行一个LangGraph™工作流，并行执行意图检测、风险评估和政策查询。向量存储（OpenSearch®）提供记忆层，检索相关规则和历史反馈，以支撑每个决策。

Figure 11: Overall system architecture.图11：整体系统架构。

Microsoft Word Add-In: Meeting Lawyers Where They Work

A critical design decision was building the assistant as a Microsoft Word Add-in rather than a standalone web application. Lawyers live in Word, so asking them to copy-paste between tools would kill adoption.一个关键的设计决策是将助手构建为Microsoft Word插件，而不是独立的Web应用程序。律师的工作离不开Word，因此要求他们在工具之间复制粘贴会扼杀采用率。

The add-in is built on React and TypeScript, running as a task pane alongside the document. It communicates with Word through Microsoft Office’s® JavaScript API to read tracked changes, apply modifications, and highlight clauses under review.该插件基于React和TypeScript构建，作为任务窗格在文档旁边运行。它通过Microsoft Office®的JavaScript API与Word通信，以读取修订记录、应用修改并高亮显示正在审查的条款。

This integration wasn’t without challenges. The Office JavaScript  API has significant limitations that required creative workarounds:这种集成并非没有挑战。Office JavaScript API存在重大限制，需要创造性的变通方法：

• Performance: The Office JavaScript  API is inherently slow, requiring us to optimize at the application layer with aggressive caching and minimal round-trips to Word.性能：Office JavaScript API本质上很慢，要求我们在应用层进行优化，采用激进的缓存策略，并尽量减少与Word的往返调用。
• API bugs: The tracked changes API has edge cases that cause crashes on certain document structures, requiring defensive loading strategies.API漏洞：修订记录API存在一些边缘情况，会导致在某些文档结构上崩溃，需要防御性的加载策略。
• Missing features: Deleted text in tracked changes returns empty strings, requiring us to maintain our own text state for accurate diff display.功能缺失：修订记录中删除的文本返回空字符串，要求我们维护自己的文本状态以实现准确的差异显示。

These constraints shaped our architecture: a thin client that orchestrates Word operations carefully, paired with a back end that handles all the heavy AI lifting.这些约束塑造了我们的架构：一个小心协调Word操作的瘦客户端，搭配一个处理所有繁重AI计算的后端。

High-Performance Orchestration高性能编排

We optimized for both latency and accuracy by parallelizing independent graph nodes. For instance, while the Intention Node analyzes the counterparty’s meaningful intent, the Risk Level Node concurrently assesses the clause’s danger profile.我们通过并行化独立的图节点来优化延迟和准确性。例如，当意图节点分析交易对手的实际意图时，风险级别节点会同时评估条款的危险概况。

Hybrid Decision Engine: Rules versus Learning混合决策引擎：规则与学习

To balance flexibility with compliance, we architected a hybrid system that treats hard and soft logic differently.为了在灵活性与合规性之间取得平衡，我们构建了一个混合系统，对硬逻辑和软逻辑采取不同的处理方式。

For non-negotiable policies, we use a deterministic Rules Engine. Unlike standard RAG, this triggers only on strict semantic matches against a target sentence. If a rule matches, it acts as a hard guardrail, overriding the model.对于不可协商的政策，我们使用确定性的规则引擎。与标准RAG不同，它仅在与目标句子严格语义匹配时触发。如果规则匹配，它将作为硬护栏，覆盖模型输出。

For negotiable nuances (tone, strategy), we rely on the probabilistic feedback loop.对于可协商的细微差别（语气、策略），我们依赖概率性的反馈循环。

This dual approach allowed us to bootstrap the system, delivering high-confidence results from day 1 based on rules, while the feedback loop accumulated the data needed to handle more complex, unstructured scenarios.这种双重方法使我们能够引导系统，从第一天起就基于规则提供高置信度的结果，同时反馈循环积累了处理更复杂、非结构化场景所需的数据。

Self Learning via Feedback通过反馈实现自学习

The core of our self-learning capability is a feedback loop that removes the need for manual model fine-tuning. We capture a comprehensive snapshot of every lawyer interaction. This structured dataset includes the original context (contract text, counterparty redline), the AI's analysis (intent, risk level), and most crucially, the lawyer’s full response: their final decision, any specific text modifications they applied, and their written reasoning. This granular data allows the system to model not just what was decided, but why, enabling it to replicate the nuance of senior counsel in future similar scenarios.我们自学习能力的核心是一个反馈循环，它消除了手动微调模型的需要。我们捕获了每次律师交互的完整快照。这个结构化数据集包括原始上下文（合同文本、交易对手修订）、AI的分析（意图、风险级别），以及最关键的——律师的完整回复：他们的最终决定、他们应用的任何具体文本修改，以及他们的书面推理。这些细粒度数据使系统不仅能够模拟决策结果，还能模拟决策原因，从而使其能够在未来类似的场景中复制资深律师的细微差别。

Time-Weighted Self-Learning时间加权自学习

To prevent concept drift where the model might over-index on outdated legal positions, we implemented a custom feedback sampling algorithm based on exponential decay. When retrieving few-shot examples for the context window, we calculate a weight for each historical interaction.为了防止模型可能过度索引过时法律立场而导致的概念漂移，我们实现了一种基于指数衰减的自定义反馈采样算法。在为上下文窗口检索少样本示例时，我们会计算每个历史交互的权重。

Figure 12: Custom feedback sampling algorithm. 图12：自定义反馈采样算法。

Data Storage and Vector Search数据存储与向量搜索

Our knowledge base relies on OpenSearch, utilizing nomic-embed-text-v15 embeddings for high-dimensional semantic retrieval. We maintain two primary indices:我们的知识库依赖于OpenSearch，利用nomic-embed-text-v15嵌入进行高维语义检索。我们维护两个主要索引：

• Rules index: Stores legal policies, vectorized by the target sentence.规则索引：存储法律政策，按目标句子向量化。
• Feedback index: Stores historical negotiation data, vectorized by the counterparty’s intention rather than raw text, allowing us to catch semantically identical changes phrased differently.反馈索引：存储历史谈判数据，按交易对手的意图而非原始文本进行向量化，使我们能够捕捉措辞不同但语义相同的变更。

When a new redline is detected, the system performs semantic vector searches against these indices to retrieve the most relevant rules and past decisions, ensuring the AI has the exact context needed to suggest the change.当检测到新的修订时，系统会对这些索引进行语义向量搜索，以检索最相关的规则和过往决策，确保AI拥有建议变更所需的精确上下文。

Improving Rule and Feedback Retrieval Accuracy in OpenSearch提高OpenSearch中的规则和反馈检索准确性

One advantage that we have in the problem space is that negotiation always starts from the same source contract. This means that we can anchor learnings and feedback to the same sections across multiple interactions over the same document. 我们在该问题领域的一个优势是，谈判总是从相同的源合同开始。这意味着我们可以将学习成果和反馈锚定到同一文档在多次交互中的相同部分。

First, we break down a legal contract into small chunks delimited by ';' or '.' or '\n' characters. Then, whenever the system encounters a redline, we perform a lookup on the original source sentence to retrieve guaranteed relevant historical occurrences, or explicit rules. Whenever a user interacts with the system and provides feedback, it’s the same verbatim source sentence that is used for ingestion into the database.首先，我们将法律合同分解为由“;”或“.”或“\n”字符分隔的小块。然后，每当系统遇到修订时，我们都会对原始源句子进行查找，以检索保证相关的历史记录或明确规则。每当用户与系统交互并提供反馈时，用于摄入数据库的都是相同的逐字源句子。

Figure 13: Leveraging OpenSearch to improve rule and feedback retrieval accuracy.图13：利用OpenSearch提高规则和反馈检索准确性。

Session Memory会话记忆

For the conversational interface, we use Redis®  to maintain session state, allowing lawyers to ask follow-up questions about the document. Behind the scenes, we run continuous LLM-as-a-judge evaluations to monitor the quality of retrieved context (document_quality_metric) and the adherence of the model to company rules (rule_adherence_metric).对于对话式界面，我们使用Redis®来维护会话状态，允许律师询问有关文档的后续问题。在后台，我们运行持续的“LLM即裁判”评估，以监控检索到的上下文质量（document_quality_metric）以及模型对公司规则的遵守情况（rule_adherence_metric）。

Today’s Approach: Harness Engineering当今的方法：智能体工程

As part of our Agentic AI efforts across Uber, which includes Legal AI, we are exploring agentic harnesses such as Claude Code® and OpenCode® in conjunction with skills to structure and automate workflows. In parallel, we’ll explore incorporating legal ontologies and knowledge graphs to provide a semantic foundation for representing legal concepts and relationships, enabling more consistent interpretation and reliable reasoning.作为我们在Uber范围内（包括法律AI）开展的智能体AI工作的一部分，我们正在探索Claude Code®和OpenCode®等智能体框架，并结合技能来构建和自动化工作流。同时，我们将探索整合法律本体和知识图谱，为表示法律概念和关系提供语义基础，从而实现更一致的解读和可靠的推理。

Conclusion结论

Our journey through these iterations, from the initial RAG system to integrating user feedback, refining tone, and implementing a robust rules database, underscores that building a truly effective AI-powered legal assistant is an iterative process driven by continuous learning and tight collaboration with subject matter experts. Each challenge we encountered became an opportunity to deepen our understanding and refine the system, leading to a more accurate, adaptable, and user-centric tool that genuinely augments human expertise in complex legal negotiations.我们经历的这些迭代历程，从最初的RAG系统到整合用户反馈、优化语气以及实现稳健的规则数据库，强调了构建一个真正有效的AI驱动法律助手是一个迭代过程，需要持续学习并与主题专家紧密合作。我们遇到的每一个挑战都成为了加深理解和优化系统的机会，最终打造出一个更准确、更具适应性且以用户为中心的工具，真正增强了人类在复杂法律谈判中的专业能力。

Acknowledgments致谢

We’d like to thank Alissa McDowell for her close collaboration and subject matter expertise, as well as Uber Legal, the AI Platform teams, and their leadership, Michelle Parker and Viv Keswani, for supporting this effort to bring AI to Uber Legal.我们要感谢Alissa McDowell的密切合作和主题专业知识，以及Uber法律团队、AI平台团队及其领导Michelle Parker和Viv Keswani对将AI引入Uber法律部门这一工作的支持。

Cover Photo Attribution: Generated with OpenAI ChatGPT Images.封面图片来源：由OpenAI ChatGPT Images生成。

Claude and its logo are registered trademarks of Anthropic, PBC in the United States and other countries. No endorsement by Anthropic, PBC is implied by the use of these marks.Claude及其徽标是Anthropic, PBC在美国和其他国家的注册商标。使用这些标志并不暗示Anthropic, PBC的背书。

Codex and its logo are registered trademarks of OpenAI OpCo, LLC in the United States and other countries. No endorsement by OpenAI OpCo, LLC is implied by the use of these marks.Codex及其徽标是OpenAI OpCo, LLC在美国和其他国家的注册商标。使用这些标志并不暗示OpenAI OpCo, LLC的背书。

FastAPI and its logo are registered trademarks of Sebastián Ramírez in the United States and other countries. No endorsement by Sebastián Ramírez is implied by the use of these marks.FastAPI及其徽标是Sebastián Ramírez在美国和其他国家的注册商标。使用这些标志并不暗示Sebastián Ramírez的背书。

LangChain and LangGraph and their logos are registered trademarks of LangChain Inc. in the United States and other countries. No endorsement by LangChain Inc. is implied by the use of these marks.LangChain和LangGraph及其徽标是LangChain Inc.在美国和其他国家的注册商标。使用这些标志并不暗示LangChain Inc.的背书。

Microsoft Word, Microsoft Office, Office JavaScript API, TypeScript, and their logos are registered trademarks of Microsoft Corporation in the United States and other countries. No endorsement by Microsoft Corporation is implied by the use of these marks.Microsoft Word、Microsoft Office、Office JavaScript API、TypeScript及其徽标是Microsoft Corporation在美国和其他国家的注册商标。使用这些标志并不暗示Microsoft Corporation的背书。

OpenSearch and its logo are registered trademarks of LF Projects, LLC in the United States and other countries. No endorsement by LF Projects, LLC, the OpenSearch Project, or the OpenSearch Community is implied by the use of these marks.OpenSearch及其徽标是LF Projects, LLC在美国和其他国家的注册商标。使用这些标志并不暗示LF Projects, LLC、OpenSearch项目或OpenSearch社区的背书。

Python and its logo are registered trademarks of the Python Software Foundation in the United States and other countries. No endorsement by the Python Software Foundation is implied by the use of these marks.Python及其徽标是Python Software Foundation在美国和其他国家的注册商标。使用这些标志并不暗示Python Software Foundation的背书。

React and its logo are registered trademarks of Meta Platforms, Inc. in the United States and other countries. No endorsement by Meta Platforms, Inc. is implied by the use of these marks.React及其徽标是Meta Platforms, Inc.在美国和其他国家的注册商标。使用这些标志并不暗示Meta Platforms, Inc.的背书。

Redis and its logo are registered trademarks of Redis Ltd. in the United States and other countries. No endorsement by Redis Ltd. is implied by the use of these marks.Redis及其徽标是Redis Ltd.在美国和其他国家的注册商标。使用这些标志并不暗示Redis Ltd.的背书。