12 分鐘、$0.30、一個 Prompt：Weaviate 如何用 Agentic Search 重新定義法律合約搜尋

法律文件搜尋是 RAG 最難的場景之一。不是因為資料量大，而是因為精確度要求極高：使用者問的是 2024 年的合約，你不能回傳 2022 年語意相似的條款。日期、當事人、管轄法律、特定條款類型——任何一個維度出錯都是法律風險。

Victoria Slocum（Weaviate）在 2026-04-16 發佈的這支影片，展示了一件讓 RAG 開發者停下來想一想的事：用 Weaviate Query Agent + Agent Skills，一個 prompt 在 12 分鐘內 build 出完整的法律合約搜尋系統，花費約 $0.30（20k tokens on Claude Sonnet 4.6）。

架構是什麼

先說清楚這個系統實際上在做什麼。

資料層：CUAD dataset（Contract Understanding Atticus Dataset）。510 份商業法律合約、超過 13,000 個人工標注、涵蓋 41 類重要條款類型（來源：The Atticus Project / HuggingFace）。合約被分進三個 Weaviate collection：

CommercialContracts：授權、轉銷、行銷、贊助、特許等市場面合約
CorporateIPContracts：策略聯盟、合資、智慧財產等
OperationalContracts：維護、服務等營運合約

嵌入層：ColQwen 多向量模型。這不是普通的文字嵌入。ColQwen 把 PDF 頁面當作圖像輸入，直接編碼成視覺 token——不需要跑 OCR、不需要 PDF 文字抽取前處理。每一頁依頁面尺寸動態決定 patch 數量，保留表格、版面、標題等視覺結構（來源：Qdrant PDF Retrieval 教學）。再搭配 Muvera 壓縮——這是 Google Research 在 NeurIPS 2024 提出的 Fixed Dimensional Encodings 演算法，把多向量表示壓縮成固定維度，可用 product quantization 達到 32× 記憶體壓縮同時維持高召回率（來源：Google Research blog）。

推論層：Weaviate Query Agent（2025-09 正式 GA，來源：Weaviate Blog）。Query Agent 做的事不是 keyword match，是推理：

檢查你的 schema，決定最佳搜尋策略
建立複雜的 filter 和 aggregation，鎖定相關資料
呼叫 Rerank sub-agent 根據真實相關性重新排序
生成含引用來源段落的綜合答案

應用層：FastAPI backend（async client + dependency injection）+ Next.js frontend（串流輸出 + 來源展示）。

一個 prompt 能做到這些的前提

這裡需要說清楚：「一個 prompt」的背後是 Weaviate Agent Skills。

Agent Skills 是 Weaviate 在 2026-02-21 發布的（來源：GlobeNewswire），讓 Claude Code 或 Cursor 這類 coding agent 能直接呼叫預先封裝好的 Weaviate 操作——schema 建立、資料 import、Query Agent 設定、hybrid search 等。你用 npx skills add weaviate/agent-skills 安裝後，coding agent 就有了 Weaviate 的完整操作手冊。

換句話說：那個 prompt 之所以能在 12 分鐘內生效，是因為 Weaviate 工程師已經把幾個月的 iteration 壓進了 skill 的 prompt 和文件裡。你執行的那個 prompt 受益於 Weaviate blog post 裡描述的所有除錯過程——你是在免費使用別人做完的功課。

這是重要的 context，不是批評，而是讓你準確評估「12 分鐘」這個數字的含義。

Query Agent 解決了 RAG 的哪個核心問題

傳統 RAG 的痛點是什麼？

它是靜態的。你寫一個 retriever，它做的事是固定的——語意搜尋、或關鍵字搜尋、或 hybrid。如果使用者的問題需要「找出所有 2024 年後生效且管轄法律是加州的保密條款」，傳統 RAG 要嘛給你一堆「語意相關但時間不對」的結果，要嘛你要手工寫 filter 邏輯。

Query Agent 的方法是：讓 LLM 在執行期根據 query 的意圖，動態決定 filter 組合、collection routing、aggregation 策略。它讀 schema，理解資料結構，然後即時規劃查詢計畫——類似 Text-to-SQL，但用在向量資料庫和多集合的場景，且輸出的不是 SQL 而是 Weaviate 的查詢 API 呼叫。

法律合約搜尋是這個能力特別有價值的場景，因為：

合約有明確的結構性屬性（日期、當事人、合約類型）
問題往往涉及多個條件的交集
「語意相近但不符合特定條件」的結果在法律場景是危險的，不是「差不多」

但是：這是生產系統嗎？

這個問題很值得停下來想。

Victoria 說「production-ready application in 36 hours」——這個「production-ready」是 Weaviate 內部 finance team 的內部工具，不是一個外部客戶可以依賴的法律 SaaS。

真正部署面向客戶的法律 AI 系統，還有幾個這個 demo 完全沒有碰到的問題：

資料主權與 privilege：法律合約往往涉及律師-委託人特權（attorney-client privilege）。資料要放哪裡、誰能存取、是否可以通過 API 送到外部 LLM——這些是合規問題，不是工程問題。

幻覺的法律後果：Query Agent 生成含引用來源的答案，大幅降低幻覺風險，但「降低」不等於「消除」。在法律場景，一個錯誤的引用可能直接影響商業決策。需要有 human-in-the-loop 的驗證機制。

模型版本與可重現性：法律分析需要一致性。LLM 版本更新時，同一個問題的答案可能改變——這在一般搜尋可以接受，在法律場景需要版本控制。

這些問題不會讓 Weaviate 的技術示範失去價值。它展示的是「架構有多快可以建起來」，而不是「部署到生產需要多快」。

對開發者的實際意義

如果你在做需要精確、結構化文件搜尋的應用——法律、醫療、合規、技術文件——這個架構組合值得認真評估：

ColQwen + Muvera：PDF 視覺嵌入不需 OCR，對表格密集型文件（合約、財報）特別有優勢
Query Agent ask mode：適合需要綜合答案的 chatbot 場景；search mode 適合需要高精確度原始 result 的搜尋場景
Agent Skills：大幅降低 Weaviate 的上手門檻，適合 AI coding agent 流程

完整 prompt 和實作細節在 Weaviate blog，CUAD dataset 的 15 份範例合約是夠用的起點。

RAG 的「最難場景」正在被系統性地工具化。12 分鐘不是終點，是新的起點線。