# LAB 開源 C&H 合成律所：9,288 份文件測試 Agent 知識檢索

> 📖 本站完整內容索引（documentation index）：[llms.txt](/llms.txt)

> 原作者：Julio Pereyra (@ItsJulioPereyra) · 策展與摘要：EasyVibeCoding · 平台：X (Twitter) · 熱度：🔥🔥 · 日期：2026-08-08

> 原始來源：https://x.com/itsjuliopereyra/status/2085772997944803682

## 證據與延伸閱讀

- [LAB 開源 C&H 合成律所：9,288 份文件測試 Agent 知識檢索](https://x.com/itsjuliopereyra/status/2085772997944803682)
- [規格數值（客戶 46、執業領域 15 等）](https://github.com/harveyai/harvey-labs/tree/main/tasks/firm-knowledge) — 官方 Repository
- [效能圖表數據（Pass rate 等數據）](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/b07f9cc39da8e2a2.jpg)

## 中文摘要

# LAB 開源 C&H 合成律所：9,288 份文件測試 Agent 知識檢索

我們即將開放原始碼的下一個 LAB 擴充內容：一間合成律師事務所 Calderwood & Harkness（簡稱「C&H」或「本所」）。本所與 @engramlab 合作打造，包含超過 250 件客戶專案的工作成果，總計近 10,000 份文件與超過 1 億個 token。

| 規格 | 數值 |
| --- | --- |
| 客戶 | 46 |
| 執業領域 | 15 |
| 專案 | 266 |
| 檔案 | 9,288 |
| Token | 108M |
| 任務 | 250 |
| 評分 | 依各任務評分規準，由 LLM judge 評估 |
| 資料集 | https://github.com/harveyai/harvey-labs/tree/main/tasks/firm-knowledge |

這個環境包含 250 個任務，涵蓋各種知識檢索與推理形式。每項任務都模擬律所可能要求文件管理系統執行的檢索與推理工作，並且是針對 Agent 能力所設計的壓力測試——回答任何一個問題所需的 context 都分散在不同地方，通常沒有可供 grep 的關鍵字；而在 1 億個 token 的規模下，整個語料庫大到無法窮舉搜尋。

在這篇文章中，我們會說明律所的組織方式、如何打造一個符合這種組織結構且具備扎實依據的合成律所環境，以及基準測試結果如何揭示目前的 Agent 存取大規模知識語料庫的能力。

## 律所的組織方式

律所通常透過一組共通的關係來組織工作：律所服務的客戶，以及律所為這些客戶處理的專案。我們以這些核心關係作為 C&H 的基礎。

![Calderwood & Harkness 事務所的組織架構圖，展示 Firm、Client 與 Matter 三層階層關係](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/17daa6e0a9c46242.jpg)
> Calderwood & Harkness 事務所的組織架構圖，展示 Firm、Client 與 Matter 三層階層關係

<details class="chart-data"><summary>展開畫面重點</summary><div class="me-note">FIRM
Calderwood &amp; Harkness

CLIENT
Ardent Capital Partners
1001

MATTER
Asset Purchase
1001-00003
38 docs

MATTER
HSR Merger Clearance
1001-00001
36 docs

CLIENT
Cascade Retail Holdings
1038

MATTER
Stock Purchase
1038-00009
83 docs

MATTER
ABL Credit Facility
1038-00002
36 docs

CLIENT
Dunmore Energy
1016

MATTER
High-Yield Notes
1016-00003
79 docs

MATTER
DOJ Inquiry
1016-00009
88 docs</div></details>

本所有 46 個虛構客戶，代表不同的企業與個人，律所為他們提供服務。我們刻意定義多元的客戶，以涵蓋廣泛的工作類型——私募股權（PE）公司所需要的法律服務，與工業製造商所需要的服務並不相同。

本所透過不同的執業領域為這些客戶提供服務。這些執業領域代表不同類型的法律專業，涵蓋中型與大型律所常見的各種業務團隊。

律所實際執行的工作，則由客戶專案來表示。一個客戶可以有多個專案，而一個專案可能涉及多個執業領域的律師。本所的檔案系統目前有 266 件進行中或已完成的專案。

這三個概念界定了 C&H 的範圍：它為誰提供服務、能運用哪些專業，以及目前正在處理哪些具體專案。

## 建立資料集

每個客戶專案都從一份規格開始，其中定義與律所結構相關的詳細資訊：服務的客戶，以及專案的大致形態。接著，再以一組具體的實質事實加以擴充，讓該專案具備特定任務所需的依據。

這些事實可能很狹隘，例如特定協議中的 10% 證券託管款，或為期兩年的競業禁止條款；也可能是結構性的，例如某起訴訟遭到駁回或以和解結案。這些特徵讓我們能從簡短規格中定義與檢視真值，而不必處理龐大且沒有結構的語料庫。整體而言，一個專案大約只需 1,000 個 token 描述規格，卻能包含許多對任務至關重要的特徵。

接著，我們的合成資料管線會將每份規格轉換成一個包含 10 至 200 份逼真文件的檔案系統（數量取決於專案狀態、規模與類型），用以呈現相關特徵。特徵會固定在特定文件上，因此可以一路追溯到專案層級與檔案層級。專案本身是由文件組成的結構鬆散集合，包含專案的主要面向：委任、各階段的執行、重大決策，以及最終結果。實際的檔案系統並未採用標準化結構，而是依據專案類型、合夥人的偏好，以及特定專案的發展方式，呈現符合邏輯的組織形式。

![顯示多層級資料夾與文件檔案列表的檔案管理介面](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/deae21bc4a863537.jpg)
> 顯示多層級資料夾與文件檔案列表的檔案管理介面

<details class="chart-data"><summary>展開畫面重點</summary><div class="me-note">畫面為暗色主題的檔案總管介面，呈現三個欄位的多層級資料夾與檔案結構：

左側欄位（第一層資料夾）：
- 1001-00004
- 1001-00005
- 1001-00006
- 1001-00007 （被選取反白）
- 1002-00001
- 1002-00002
- 1002-00003

中間欄位（第二層資料夾，對應 1001-00007 底下的內容）：
- Closing
- Correspondence
- Diligence （被選取反白）
- Financing
- Insurance
- Regulatory
- Transaction Documents

右側欄位（第三層檔案與資料夾，對應 Diligence 資料夾底下的內容）：
- comprehensiv...e-report.docx
- employee-be...ce-memo.docx
- environmental...ummary.docx
- healthcare-re...e-memo.docx
- ip-data-priva...summary.docx
- Tax</div></details>

## 環境與任務定義

本所的專案被視為一個持續存在的語料庫，每個任務都會針對整個檔案系統執行。任務本身則是根據專案的簡要規格列舉而成，真值會依據包含特定特徵組合的專案或文件計算得出。專案底層的特徵不會在執行階段直接提供給 Agent；Agent 必須透過搜尋與推理的組合，從沒有結構的檔案系統中找回這些特徵。

雖然特徵本身具備結構，但它們仍能支援各種搜尋與推理任務的彈性表達，包括搜尋先例、理解產業趨勢，以及辨識客戶層級的偏好或結果。

![法律與商業任務類型對照表，左側為具體任務描述，右側為對應的 Task type 分類。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/6df698043e3255bd.jpg)
> 法律與商業任務類型對照表，左側為具體任務描述，右側為對應的 Task type 分類。

<details class="chart-data"><summary>展開畫面重點</summary><div class="me-note">表頭：
- Task
- Task type

第一列：
- Task: "Find our M&amp;A deals that used a 10% escrow"
- Task type: Deal-term precedent lookup

第二列：
- Task: "How many of our credit facilities are covenant-lite?"
- Task type: Portfolio census

第三列：
- Task: "What's our largest litigation settlement?"
- Task type: Benchmarking / book-of-business review

第四列：
- Task: "M&amp;A deals that did not close"
- Task type: Exception spotting

第五列：
- Task: "Pull the full list of matters we've handled for Cascade Retail Holdings"
- Task type: Client history lookup

第六列：
- Task: "How did our indemnification caps trend across software deals, 2022–2024?"
- Task type: Portfolio trend analysis

第七列：
- Task: "I'm building a clause bank of commercial MFN provisions — pull all of them"
- Task type: Clause-bank building

第八列：
- Task: "For which clients have we handled both a sell-side M&amp;A matter and a financing?"
- Task type: Cross-practice client coverage

第九列：
- Task: "What's our record across litigation?"
- Task type: Outcome analysis

第十列：
- Task: "Who are our top five clients by number of matters, with counts?"
- Task type: Relationship review

第十一列：
- Task: "Have we ever done a SPAC merger in the biotech space?"
- Task type: Sector experience check</div></details>

在標準的 LAB 形式中，我們會使用 LLM judge，依據評分規準評估 Agent；評分規準會將真值拆解成完成任務所需的原子化條件。

## 目前的效能

我們使用標準 LAB harness，以及兩個強大的基礎模型 GPT-5.6-sol 和 Opus-4.8，來測量基準效能。我們發現，兩者在整體任務效能與延遲效率方面都表現吃力。兩者都能解決一組共通的簡單任務，也各自能解決另一組較困難的任務；但每項任務都需要花費五分鐘以上，而且只能滿足全部評分條件的大約一半。

從檢視執行軌跡的結果來看，我們預期成本與延遲都會隨語料庫規模增加而上升。對真正的企業級規模語料庫而言，這會造成實際問題，因為其規模可能比 C&H 大上數個數量級。

![gpt-5.6-sol-high 在 Criteria pass rate (79.1%) 與 All-pass rate (36.0%) 皆優於 opus-4.8-high 且中位數延遲更短，但每項任務的中位數成本更高。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/b07f9cc39da8e2a2.jpg)
> gpt-5.6-sol-high 在 Criteria pass rate (79.1%) 與 All-pass rate (36.0%) 皆優於 opus-4.8-high 且中位數延遲更短，但每項任務的中位數成本更高。

<details class="chart-data"><summary>展開數據表</summary><table><thead><tr><th></th><th>Criteria pass rate</th><th>All-pass rate</th><th>Median latency</th><th>Median cost / task</th></tr></thead><tbody><tr><td>opus-4.8-high</td><td class="rank-bar num bar-w-90"><span class="bar-val">71.7%</span></td><td class="rank-bar num bar-w-70"><span class="bar-val">24.4%</span></td><td class="rank-bar num bar-w-100"><span class="bar-val">475s</span></td><td class="rank-bar num bar-w-80"><span class="bar-val">$1.26</span></td></tr><tr><td>gpt-5.6-sol-high</td><td class="rank-bar num bar-w-100"><span class="bar-val">79.1%</span></td><td class="rank-bar num bar-w-100"><span class="bar-val">36.0%</span></td><td class="rank-bar num bar-w-90"><span class="bar-val">406s</span></td><td class="rank-bar num bar-w-100"><span class="bar-val">$1.66</span></td></tr></tbody></table></details>

失敗的主要原因，大致可以歸結為無法全面搜尋並理解語料庫。模型對於自己找到的內容，大多能正確推理；但經常無法找出所有相關資訊。

這種失敗模式在需要列舉大量相關專案、檔案或資訊的任務上尤其嚴重。隨著成功完成任務所需的原子化要點數量增加，兩個模型都會退化到 0% 的全數通過率。

![gpt-5.6-sol-high 在多數 Rubric size 區間的 Criteria pass rate 與 All-pass rate 較高；26+ 的 All-pass rate 兩者同為 0%。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/4d99c212deeb082e.jpg)
> gpt-5.6-sol-high 在多數 Rubric size 區間的 Criteria pass rate 與 All-pass rate 較高；26+ 的 All-pass rate 兩者同為 0%。

<details class="chart-data"><summary>展開數據表（1）Criteria pass rate</summary><table><thead><tr><th>模型</th><th>1-5</th><th>6-15</th><th>16-25</th><th>26+</th></tr></thead><tbody><tr><td>opus-4.8-high</td><td class="rank-bar num bar-w-100"><span class="bar-val">72%</span></td><td class="rank-bar num bar-w-90"><span class="bar-val">78%</span></td><td class="rank-bar num bar-w-80"><span class="bar-val">70%</span></td><td class="rank-bar num bar-w-90"><span class="bar-val">68%</span></td></tr><tr><td>gpt-5.6-sol-high</td><td class="rank-bar num bar-w-100"><span class="bar-val">75%</span></td><td class="rank-bar num bar-w-100"><span class="bar-val">83%</span></td><td class="rank-bar num bar-w-100"><span class="bar-val">84%</span></td><td class="rank-bar num bar-w-100"><span class="bar-val">74%</span></td></tr></tbody></table></details><details class="chart-data"><summary>展開數據表（2）All-pass rate</summary><table><thead><tr><th>模型</th><th>1-5</th><th>6-15</th><th>16-25</th><th>26+</th></tr></thead><tbody><tr><td>opus-4.8-high</td><td class="rank-bar num bar-w-80"><span class="bar-val">40%</span></td><td class="rank-bar num bar-w-60"><span class="bar-val">17%</span></td><td class="rank-bar num bar-w-0"><span class="bar-val">0%</span></td><td class="rank-bar num bar-w-0"><span class="bar-val">0%</span></td></tr><tr><td>gpt-5.6-sol-high</td><td class="rank-bar num bar-w-100"><span class="bar-val">52%</span></td><td class="rank-bar num bar-w-100"><span class="bar-val">28%</span></td><td class="rank-bar num bar-w-100"><span class="bar-val">21%</span></td><td class="rank-bar num bar-w-0"><span class="bar-val">0%</span></td></tr></tbody></table></details>

這並不是搜尋策略失敗。Agent 一致能找到核心資訊，並滿足大約一半的評分條件。真正的問題在於，Agent 不知道何時應該繼續尋找更多資訊。這表示 Agent 並未建立起有效的語料庫中間模型，因而無法判斷自己的搜尋是否已經足夠全面。

若要在企業知識環境中成功完成任務，就必須改善這項特定能力。

## 結論

法律工作需要理解一個問題與過去工作之間的關聯：哪些先例與某位客戶相關，或市場標準通常是什麼樣子。現今的 Agent 會在每項任務中，嘗試從頭推導這些知識。

C&H 顯示，到了企業知識的規模，這種策略成本高昂，而且效果不佳。我們認為，改善 Agent 這項能力的一個有希望方向，是讓它們預先建立更豐富的語料庫表示——索引、摘要、記憶——並將建立這些表示的成本攤銷到後續執行中。由於環境是持續存在的，這些一次性的理解成本可以在許多任務之間分攤。我們很快會分享更多相關工作。

我們為這篇文章建立的合成律所資料，已經放在開放原始碼的儲存庫中。目前版本的 C&H 只涵蓋律所所執行工作的一部分，其任務也只代表律師可能想從機構知識中提出的問題的一部分。我們計畫隨著時間逐步擴充這兩個部分。

特別感謝以下貢獻者針對資料集與文章初稿提供回饋：Dan Biderman（Engram）、Jessy Lin（Engram）、Mayee Chen（Engram）、Neel Guha（Columbia Law School／Engram）、Shizhe He（Engram）、Calvin Qi（Harvey）、Gabe Pereyra（Harvey）

## 標籤

開源專案, LLM, Benchmark, GitHub