---
slug: tw-legal-rag-taiwan-law-search
title: TW Legal RAG：把台灣判決做成語義檢索，讓法律問題先找到案例
status: published
excerpt: TW Legal RAG 比較像一個把 2200 萬筆台灣判決做成語義檢索與 citation check 的法律工具鏈，而不是一個只會聊天的法學助理。
category: AI Tools
tags: [ai, rag, legal, semantic-search, cli, mcp]
author: Seer
author_role: Author
read_time: 6 min
cover: "/static/tw-legal-rag-taiwan-law-search-cover-v1.png"
closing_note: "法律是文字的圍牆，但公義的追求，在於穿透墨跡後的溫度。"
published_at: "2026-05-28T00:00:00Z"
updated_at: "2026-07-01T15:54:39Z"
---

在台灣做法律相關的 AI 應用，最痛苦的不是 Prompt 怎麼寫，而是如何從司法院幾千萬筆判決書裡，精準撈出有參考價值的案例，又不會讓 LLM 開始胡說八道（Hallucination）。TW Legal RAG 這個開源專案，就是為了解決這個痛點。

它做的不是直接用 AI 來代替律師回答問題，而是先把「法律檢索」這件事做成一個乾淨的 RAG (Retrieval-Augmented Generation) 資料層。你丟一句白話問題進去，它先幫你找出相關判決，再把結果打包成 Bundle，讓你的 LLM 應用去讀取並整理成答案。

## 它能解決什麼問題？

- 提供開源 CLI 工具：`twlegalrag`。
- 支援用自然語言直接搜尋台灣法院判決。
- 把檢索出的結果打包成 Context Bundle。
- 限制 ChatGPT / Claude / Gemini 等模型只能引用 Bundle 內部的案例來回答。
- 提供 `check` 指令做 Bundle-level Citation 檢查，防止 AI 瞎編不存在的判決案號。

如果你是律師或法務，這就像是幫你寫好一個「把判決撈準」的前置 CLI 腳本；如果你是一般使用者，它則像一個能用白話文翻譯成法律事實的入口。

## 技術架構與使用方式

從軟體開發的角度來看，這套工具主要是用 Python 寫成的 CLI 套件：

- 使用 `Typer` 來做 CLI 的命令列介面開發。
- 透過 `httpx` 來發送 HTTP Request 到後端。
- 使用 `Rich` 庫處理 Terminals 上的排版與視覺化輸出。
- 核心指令包括 `search`、`pack`、`check` 和 `health`。

我們可以用簡單的指令來體驗它的運作：

```bash
pip install twlegalrag
twlegalrag search --query "車禍 賠償" --limit 5
```
這行指令會安裝 `twlegalrag` 套件，並直接透過 CLI 對遠端法律資料庫發送 Semantic Search 請求，撈出 5 筆跟『車禍賠償』最相關的台灣法院判決。

特別要注意的是，這個 CLI 本身不呼叫 LLM，也不在本機存儲巨大的判決書 Database，而是透過 API 來對接遠端的語義檢索服務。換句話說，它扮演的是純粹的「檢索層」，而不是「回答生成層」。

## 這套 RAG 工作流的設計思路

這類專案很容易被外行誤解為「訓練一個法律大模型」，但實際上它做的是 *Retrieval Infrastructure*。我們把它的 Pipeline 拆開來看：

- **原始資料清理**：對判決書的文字格式進行整理、欄位標準化與去噪。
- **Chunking (切段)**：把動輒幾萬字的長判決書拆成適合 Vector Search 的片段。
- **Embedding (向量化)**：將文本段落轉換成向量特徵值。
- **Indexing (索引)**：把向量存入 Vector Database，建立語義搜尋引擎。
- **Retrieval (檢索)**：根據使用者的 Query 撈出最相關的 Top-K 判決。
- **Bundling (打包)**：將案例、引用 ID 和摘要打包輸出成 LLM 可讀的格式。
- **Citation Check (引用檢查)**：比對 LLM 生成的 Answer，確保它沒有胡亂編造 Bundle 以外的案例。

## 可以搬到哪些領域？

這種 RAG 架構真正有價值的地方不限於「法律」這個垂直領域，而是這套檢索與防幻覺的 Workflow 可以直接套用到其他需要高度嚴謹資料的場景。

只要你的專案符合「資料量極大、需要標註引用來源、容錯率極低」這三個特徵，這套骨架就非常合用：

- **金融研究**：撈取財報、法說會逐字稿，確保分析模型引用的是真實數據。
- **醫療生技**：檢索臨床指引與學術論文，防止 AI 亂開藥方。
- **企業 FAQ / 客服知識庫**：從產品手冊與過去的工單紀錄中撈答案，並精準附上官方文件連結。
- **SRE 與資安維運**：從歷年的 Runbook、Postmortem (事後檢討報告) 撈取故障排除對策。

如果要做成產品，這種「先把資料檢索做穩，再把模型當作翻譯與排版工具」的 Decoupled 架構，是目前實務上最不容易踩坑的選擇。

## 邊界比演算法更重要

在評估這類工具時，我最看重的不是它的 Embedding Model 有多先進，而是它有沒有把「系統邊界」畫清楚。

TW Legal RAG 的防守範圍很明確：它只保證檢索出來的案例相關度，而不打包票 LLM 的法律意見絕對正確；它用 Citation Check 去防堵幻覺，但不替判決書背後的司法實務做價值判斷。這種設計思維在開發 Legal-tech 產品時非常關鍵——在法律的世界裡，一個「看起來很專業的胡言亂語」，往往比「查無此案」帶來的風險還要高得多。

## 連結

- [GitHub](https://github.com/aa0101181514/tw-legal-rag)
- [法律廣場 / 法律偵探](https://dr-lawbot.com/ask)
- [Threads 原文](https://www.threads.com/@dr_lawbot/post/DY2DI5eFCEt?slof=1)