法律客戶AI代理商技術堆疊：n8n + 微調模型 + 本地部署

為法律事務所構建AI解決方案需要一個滿足法律合規要求的特定技術堆疊，同時對小型代理商團隊保持可管理性。本文記錄完整架構——每個組件、選擇它的原因，以及各部分如何連接。

完整架構

┌─────────────────────────────────────────────────────────┐
│                    客戶網絡                               │
│                                                          │
│  ┌──────────┐    ┌──────────┐    ┌───────────────────┐  │
│  │   DMS    │───→│   n8n    │───→│  LLM推論          │  │
│  │(iManage) │    │(自       │    │  (Ollama/vLLM)    │  │
│  └──────────┘    │ 託管)    │    │  + LoRA適配器      │  │
│                  └────┬─────┘    └───────────────────┘  │
│                       │                                  │
│                  ┌────▼─────┐    ┌───────────────────┐  │
│                  │ 向量     │    │  客戶門戶          │  │
│                  │   數據庫 │    │  (結果UI)          │  │
│                  │(Chroma/  │    └───────────────────┘  │
│                  │ Qdrant)  │                            │
│                  └──────────┘                            │
└─────────────────────────────────────────────────────────┘

每個組件都在法律事務所的網絡內運行。沒有數據離開邊界。

組件選擇

n8n：工作流程編排

為什麼選擇n8n：

• 可自託管（Docker、裸機）——沒有SaaS依賴
• 非技術人員在演示中可以理解的視覺工作流程構建器
• OpenAI相容節點直接連接到本地LLM端點
• 用於實時文件處理的Webhook觸發器
• 內置錯誤處理、重試邏輯和執行日誌
• 活躍的開源社群，有法律相關工作流程範本

為什麼不選Make.com或Zapier：

• 兩者都是僅雲端的SaaS——數據必須離開事務所的網絡
• 不能自託管用於隔離部署
• 供應商依賴為長期項目創造風險

n8n部署： 帶有PostgreSQL後端的Docker容器。資源輕量——2個CPU核心和4GB RAM可以處理大多數代理商工作負載。

LLM推論：Ollama或vLLM

Ollama用於更簡單的部署：

• 單一二進制安裝，最少配置
• 內置模型管理（下載、版本、切換模型）
• 開箱即用的OpenAI相容API端點
• 較低吞吐量但更簡單的操作

vLLM用於生產部署：

• 使用連續批處理的更高吞吐量
• 在並發負載下更好的GPU利用率
• OpenAI相容API
• 更多操作複雜性（Python環境、模型加載）

決策框架： 從Ollama開始用於試點部署和單客戶設置。當您需要服務多個並發用戶或同一GPU上的多個客戶適配器時，遷移到vLLM。

微調模型 + LoRA適配器

基礎模型+適配器架構是多客戶代理商操作的基礎：

• 一個基礎模型（Llama 3.1 8B）加載在GPU內存中
• 每個客戶的LoRA適配器（每個50-200 MB），為每個事務所的特定任務和風格自定義基礎模型
• 動態適配器加載——在推論時根據哪個客戶的請求正在處理來交換適配器

這種架構意味著單個GPU服務於您的所有法律客戶。每個客戶都得到一個行為就像專門在其數據上訓練的模型，但基礎設施成本是共享的。請參閱我們的多客戶LoRA指南了解技術細節。

微調通過Ertas Studio進行——上傳客戶數據、配置訓練、導出適配器。不需要ML專業知識。

向量數據庫：Chroma或Qdrant

對於法律AI，純微調通常由RAG（檢索增強生成）補充，用於需要引用特定文件的任務：

Chroma用於輕量部署：

• 嵌入模式在進程內運行（無需單獨服務器）
• 簡單的Python API
• 適合少於100萬個文件的集合

Qdrant用於生產部署：

• 帶有REST和gRPC API的專用服務器
• 更好的大規模性能（數百萬個文件）
• 內置過濾（對多客戶數據隔離有用）
• Docker部署

何時在微調旁邊使用RAG：

• 合同審查對比條款庫→RAG檢索類似條款，微調模型分析
• 法律研究→RAG檢索相關判例法，微調模型摘要和綜合
• 盡職調查→RAG搜索數據室，微調模型提取和分類

客戶門戶

法律事務所期待精美的介面，而非原始API輸出。選項：

自定義Web應用： 一個簡單的React或Next.js應用程序，可以：

• 接受文件上傳
• 顯示處理狀態
• 以格式化報告顯示分析結果
• 提供導出功能（PDF、DOCX）
• 對事務所的身份提供商進行身份驗證（SAML/OIDC）

n8n + 表單介面： 對於更簡單的部署，n8n的webhook + 表單觸發器可以作為基本的入口介面。不那麼精美但部署更快。

與現有工具的整合： 許多事務所更喜歡將結果交付到其現有的文件管理系統（iManage、NetDocuments）或事務管理平台，而不是單獨的門戶。

部署拓撲

單客戶部署

對於小型事務所（10-50名律師）：

客戶額外硬體成本：2,500至4,000美元（僅GPU工作站，如果他們還沒有）。

多客戶代理商部署

對於管理5至15個法律事務所客戶的代理商：

選項A：集中式（代理商託管）

• 代理商運營服務器機房或托管機架
• 每個客戶的數據是邏輯隔離的（單獨的數據庫、單獨的LoRA適配器）
• 需要強大的訪問控制和審計日誌記錄
• 每個客戶的硬體成本更低
• 注意：一些事務所不接受這種模式——其數據必須在其自己的硬體上

選項B：分佈式（客戶託管）

• 每個客戶都有自己的硬體堆疊
• 代理商通過VPN或安全遠程訪問遠程管理
• 較高的硬體成本（跨客戶重複），但最大的數據隔離
• 由於數據主權要求，大多數法律事務所偏好此模式

選項C：混合式

• 客戶託管推論（客戶硬體上的GPU + 模型）
• 代理商託管n8n（僅編排，沒有持久化的客戶數據）
• 微調在代理商基礎設施上進行，適配器文件交付給客戶

大多數代理商從選項B開始，隨著信任建立，將願意集中化的客戶遷移到選項A。

數據流：完整示例

以下是合同審查工作流程的逐步數據流：

1. 律師上傳合同到客戶門戶（或放入監控的DMS文件夾）
2. n8n webhook觸發，啟動合同審查工作流程
3. n8n從文件提取文本（PDF解析節點）
4. n8n將文件分塊為部分（Function節點）
5. 對於每個部分，n8n查詢向量數據庫，從事務所的先例庫中獲取類似條款
6. n8n將每個部分+檢索到的上下文發送到本地LLM，加載特定事務所的LoRA適配器
7. LLM返回每個部分的風險分析
8. n8n將結果聚合為結構化審查報告
9. 報告被交付到客戶門戶、通過電子郵件發送或寫回DMS
10. 所有執行數據都記錄在n8n的執行歷史和審計日誌中

處理30頁合同的總處理時間：2-5分鐘。

擴展考量

添加更多客戶

每個新客戶需要：

• 新的LoRA適配器（通過Ertas Studio訓練）
• 新的向量數據庫集合（如果使用RAG）
• 新的n8n工作流程（從範本克隆，每個客戶自定義）
• 門戶中的客戶特定配置

基礎模型和推論基礎設施是共享的。每個新客戶的邊際成本：微調時間+適配器存儲（微不足道）。

處理增加的量

當單個GPU飽和時：

• 在同一服務器上添加第二個GPU（大多數工作站支持2個GPU）
• 使用vLLM的張量並行在GPU之間拆分模型
• 或部署第二個推論服務器並用Nginx負載均衡

添加新能力

新使用案例（例如，為從合同審查開始的事務所添加法律研究）需要：

• 新任務的新微調適配器
• 新的n8n工作流程
• 新的向量數據庫集合（如果任務使用RAG）

基礎設施水平擴展——相同的堆疊，新的適配器。

---

延伸閱讀

• n8n + 本地LLM：構建HIPAA合規自動化 — n8n + 本地LLM整合深入探討
• 代理商的多租戶AI部署 — 在共享基礎設施上管理多個客戶