Uber 法務 Redlining Agent：RAG 失準後，如何讓資料成為決策依據

Uber 的 Legal Redlining Agent 從檢索 playbook 的 RAG 原型，逐步演進為會使用律師回饋、近期案例、談判規則與 Agent 修改流程的合約審查工具。Uber 在工程文章中表示，系統讓平均合約審核時間減少逾 20%，AI 生成決策準確率達 91%；Uber Legal 也以此案例參與獲獎提案。這些是 Uber 公開的成果數字，文章沒有提供準確率的分母、標註方法、基準線或獨立評估，因此應視為公司自述，而非可直接外推的通用基準。

這個案例最值得看的不是「RAG 換成 Agent」的名詞變化，而是資料從文件集合變成決策依據的過程：檢索鍵如何對準任務、歷史決策如何保留時間脈絡、正反例如何支持邊界判斷，以及哪些政策不應交由模型自由猜測。

從 playbook 檢索開始，卻沒有回答正確的問題

Uber 的第一版把法律 playbook 與談判範例放進 RAG，希望依語意找到相關段落，再讓大型語言模型（LLM）判斷如何回應合約紅線。團隊很快遇到三類問題：用來表示查詢意圖的「key」和要取回的內容不在相同粒度，語意相似度因而不可靠；模型產生的回覆語氣有時過度防禦、有時過度讓步；playbook 沒涵蓋的情境則難以泛化。

這說明「相關文件」不一定是「決策依據」。合約修訂通常以原始條款、對方修改內容、談判意圖與公司可接受的立場共同決定。若索引只記住一段通用政策，卻沒有把它連到具體條款和決策情境，檢索分數再高，也可能只把看似相近的文字交給模型。

Uber 後續把資料表示方式貼近工作本身：規則索引以原始合約句子作為穩定搜尋鍵；歷史回饋則依對手方修改所表達的意圖建立索引。團隊指出，談判常從同一份範本開始，因此可把後續互動錨定到原始條款，即使律師加註或對方略微改寫，仍以語意搜尋找相近案例。資料建模的關鍵，是保留「這筆案例在回答哪一種決策」的上下文，而非只保存一段文字向量。

律師的修正，才是可用的監督訊號

早期回饋只記下 accept、reject、modify 等選擇、原始文字、紅線和負面評價。這能指出結果不理想，卻不一定能告訴系統律師真正想採取什麼立場。Uber 後來補上律師預期的動作、具體留言，以及律師最後採用的修改文字。這讓回饋資料不只標示「哪裡錯」，也能表示「這個意圖在這項政策下如何被處理」。

對資料工程而言，這是從弱標籤走向任務標籤：每筆紀錄都應盡可能連上原文、對方意圖、適用規則、模型建議、律師決定、最終文字與理由。這些欄位有助於重建決策脈絡，也讓團隊能檢查同一情境下建議如何改變。Uber 提到其回饋庫累積了數千筆互動；這仍是公司描述，公開文章沒有給出資料分布、去重策略或標籤一致性結果。

系統先用相似度搜尋與 metadata filter 把候選縮到約 20 份，再用另一層 LLM 檢查候選是否符合使用者與對手方意圖。這個兩階段流程有一個實務含意：向量搜尋負責找候選，不能單獨決定哪些案例有資格進入上下文；候選的政策、意圖和條款條件仍需驗證。也因此，在評估 RAG 時，除了看 Recall@k，還要追蹤進入最終 prompt 的案例是否真能支持當前決策。

舊案例不應和新立場同權重

法律策略和公司政策會變。Uber 表示，他們以指數衰減為歷史互動加權，半衰期目前設為 365 天，讓近期決策更容易被選入上下文，降低系統過度依賴過時立場的風險。這不是把舊資料刪除，而是讓每筆案例的影響力隨時間變化。

這可以視為一種概念漂移處理，但「365 天」不是普遍正解。真正的半衰期應依政策更新頻率、條款生命週期與錯用舊案例的風險校準。若政策有正式生效日，版本與有效期間應優先於單純的時間衰減；過期政策也要能撤回或排除，不能只靠排序權重慢慢淡出。時間權重是檢索策略，來源版本、有效期和撤銷流程才是治理基礎。

Uber 也描述了平衡 agree 與 disagree 案例的 dynamic few-shot prompting。少數正例會讓模型誤以為相似文字總是接受；只放拒絕案例，也可能把可談判的修改一律拒掉。正反案例一起呈現，才讓模型看到決策邊界。不過 few-shot 的平衡不能取代代表性抽樣：仍要避免只挑容易、近期或常見案例，並依條款類型、對手方修改與政策版本檢查覆蓋率。

把自由判斷留給模糊處，把硬規則交給確定性控制

Uber 將流程進一步拆成四次演進：RAG、律師回饋、語氣調整，以及 Agentic 修改。當系統判斷為 MODIFY 時，Agent 會參考歷史回饋和規則來草擬折衷條文，避免一般文字生成偏離合約定義或自行增加條款。律師仍會審閱並決定是否接受、拒絕或修改建議。

另一條支線是規則資料庫。律師可在範本中選取重要或常被修改的句子，為它設定公司立場、備援立場和期望回覆範例。若系統以高信心匹配到規則，便把規則帶入上下文，再由 LLM 檢查輸出是否符合規格。Uber 的架構說明還指出，不可妥協政策由 deterministic Rules Engine 處理；可協商的語氣與策略則交由機率式回饋流程。

這個邊界很重要：LLM 可以協助理解意圖、整理理由或草擬文字，但硬性政策應由程式控制條件、允許值和輸出驗證。若最終合規性只依賴另一個模型「再看一次」，它仍然是機率判斷，不等於確定性保證。對高風險操作，可用 deterministic rule 阻止不允許的結果，再由人員處理例外。

把案例轉成可操作的資料工程檢查

這個案例可以整理成一組資料管線檢查，而不只是 Prompt 調整：

1. 為決策定義資料單位。 保存原始條款、修訂差異、對手方意圖、政策與最終決策之間的關係，避免用不對稱的查詢鍵與文件片段做相似度比較。
2. 把回饋做成可追溯紀錄。 記錄模型輸入與輸出、律師採取的動作、最後採用的文字、理由、時間、政策版本與來源 ID；敏感資料則依保留期限與存取權限治理。
3. 讓時效進入檢索。 同時使用有效期間、版本與時間衰減；設定舊規則失效、撤回和重建索引的流程，避免過期案例只是「分數較低」但仍可能被取回。
4. 評估邊界，不只評估平均分數。 依條款類型、政策版本、接受／拒絕／修改、罕見情境和無適用規則案例切分測試集，檢查模型何時該轉交人工。
5. 把確定性政策與生成式工作分層。 規則命中、輸出 schema、禁用條款和核准條件由程式驗證；模型處理意圖理解、說明與候選文字，人工保留最終判斷權。

Uber 公開的案例提供了有用的架構方向，但不等於其效益已由外部研究重現。除了缺少準確率的計算細節，文章也未公開逐階段消融、錯誤分布、不同合約類型的樣本數或長期漂移監測結果。因此，團隊可以借用其資料建模原則，卻應在自己的合約、政策和律師工作流上重新建立基線與評測集。

如果你正在設計類似系統，可以先讀 企業 RAG 完整指南了解資料、版本與評估如何連成治理管線，再用 AI Agent 完整指南檢查模型與工具的責任邊界；更完整的平台控制面可參考 Agentic AI 平台契約。

來源

• Uber Engineering：Scaling AI in Legal: Building Uber’s Redlining Agent（2026-10-08）：四次演進、架構、回饋資料、時間權重、規則引擎與公司自述成效。

本文將 Uber 的實作描述與工程推論分開；20%+ 時間減少與 91% 準確率均為 Uber 公開文章中的公司自述，來源沒有提供足以獨立重算的評估資料。