繁體中文 | English
這是一個針對台灣《建築技術規則建築設計施工編》所建立的 AI 知識檢索架構比較專案。 專案核心目標是客觀實作並對比目前主流的三種知識庫架構，點出從「底層建置」到「實際查詢」的真實優缺點，提供開發者與企業作為技術選型的參考。
基於最新的 V3 基準測試（15 題複雜法規考題，由 Gemini 3.1 Pro 進行評估），三大系統的表現與特性統整如下：
| 系統架構 | 建置成本 (Setup) | 查詢速度 (Speed) | Gemini 3.1 Pro 評分 | 核心優點 (Pros) | 主要限制 (Limitations) |
|---|---|---|---|---|---|
| Hybrid RAG (Vector + BM25) |
🟢 最低 僅需 Embedding 模型計算向量 |
🟡 中等 ~13 秒 |
🔴 33% | 建置最快、技術門檻低、非常適合單一事實或明確關鍵字的檢索。 | 容易發生段落截斷而丟失上下文；若一次放入過多無關文本，易導致模型注意力分散；較難處理跨章節的複雜推論。 |
| Graph RAG (知識圖譜擴展) |
🔴 極高 需使用強大 LLM 全文掃描萃取實體 |
🟢 極快 ~2.5 秒 |
🟡 67% | 回答速度極快（雜訊最少）；能準確捕捉實體關聯、明確的數字規定與條件限制。 | 建置極度耗時且昂貴；若前置作業未成功萃取出該實體，會導致後續檢索時遺漏該資訊。 |
| OKF-Wiki (Agent 本地目錄導航) |
🟡 中等 需使用 LLM 生成摘要與 MOC |
🟡 中等 ~13 秒 |
🟢 70% | 準確率最高、邏輯推演最完整；具備類似人類查書的容錯率，能循線追蹤跨章節法規。 | 查詢速度受限於 Agent 多次呼叫工具的過程；對於極簡單的單一問題，會造成運算資源與時間的相對浪費。 |
👉 詳細的逐題測試紀錄與法官點評，請參閱：15 題全量 V3 Benchmark 完整測試報告
本專案刻意挑選「輕量、開源、適合本地端運行」的框架，確保任何人都能容易上手執行 Benchmark。
- 傳統 RAG (Hybrid Search + Structural Chunking)
- 實作：使用 Chroma (向量) + Rank-BM25 (關鍵字) 進行混合檢索，並採用 RRF 重新排序。
- 特色：不再死板地按字數切分，而是依據法規原生的「條/項/款」進行語意分塊，並在檢索時自動帶入整段條文的上下文以還原脈絡。
- Graph RAG (Two-tiered Indexing)
- 實作：交由 Qwen2.5-7B 萃取法規中的三元組 (Entity-Relationship) 建立圖譜。
- 特色：先用向量庫找出起點，再從該點向外展開關聯網（1-Hop），並將每個節點與原始法規綁定，避免模型推論時產生偏誤。
- OKF LLM Wiki (Hierarchical MOC + Agent Tools)
- 實作：純文字 Markdown 目錄樹。利用 LLM 生成標準化的
_index.md(Map of Content) 與相對路徑雙向連結。 - 特色：完全不依賴向量庫，將法規轉為具備雙向連結的 Markdown 目錄樹。透過提供讀取檔案的工具，讓 AI 像人類查閱百科全書一樣，先看目錄再閱讀內文。
- 實作：純文字 Markdown 目錄樹。利用 LLM 生成標準化的
法規資料庫體積小（MB 等級），本專案已將三大架構的完整資料庫內建於 Repo data/databases/ 中，您可以直接 clone 並執行測試，無需重新建置：
# 1. 取得專案並安裝套件
git clone https://github.com/YuJunWang/taiwan-building-code-rag-benchmark.git
cd taiwan-building-code-rag-benchmark
pip install -r requirements.txt
# 2. 直接執行評估腳本
python benchmark/local_evaluator.py若需重新建置資料庫，建置腳本存放於 scripts/build/ 目錄下，可透過 Colab 執行。
前面的表格雖然點出了優缺點，但若要對應到真實的商業場景，身為您的 AI 評估法官，我給出以下最務實的導入建議：
- 如果你是「新創團隊」或「內部 PoC 驗證」👉 絕對首選 Hybrid RAG
- 原因：不需要花錢跑大模型萃取知識圖譜，只要套個現成的 LangChain 模板和便宜的 Embedding 模型，半天就能讓系統上線。缺點是遇到太難、需要跨章節推論的問題會答錯，但作為初期驗證 MVP 已經非常夠用。
- 如果你要處理「醫療合規」、「法律契約」、「金融條款」👉 強烈建議投資 Graph RAG
- 原因：這種場景下「絕對不容許幻覺」且「數值/條件極度重要」（例如：超過 50 公尺要退縮多少）。Graph RAG 能確保實體間的條件關聯不被遺漏，雖然前期建置極度耗時又昂貴，但對於需要 100% 精準度的高風險領域，這筆前置建置費是必須花的。
- 如果你要打造「自動化分析助理」、「跨部門知識庫導航」👉 請走 OKF LLM Wiki
- 原因：當你的業務需求不只是單純的「一問一答」，而是需要 AI 像新進員工一樣「幫我去翻看完這三大本手冊，然後整理一份綜合報告」時，賦予 Agent 原生目錄導航能力的 OKF 架構，是目前唯一能勝任這種高階邏輯推演的解法。
針對上述系統的優缺點，未來落地的最佳實踐將朝向整合架構發展：
- 雙引擎啟動 (Vector + Agent) 🚀
- 結合 Vector Search 的「快」與 OKF Agent 的「準」。先以毫秒級向量檢索給出精準的檔案位置「空投座標」，省去 Agent 前期看目錄的時間，直接切入高階邏輯驗證。
- 經驗沉澱與自我生長 (Agentic Memory) 🧠
- 當系統經歷複雜的跨章節推論並解答成功後，自動將該推論結果寫成一份 FAQ.md 存回系統。讓知識庫越用越聰明，未來遇到類似問題即可實現 O(1) 的極速回覆。