GraphRAG / RAG 架構設計

「語義相似的文字區塊」與「正確、完整的回答」之間的差距，正是大多數企業級 RAG 部署折戟之處。史丹佛大學人工智慧實驗室（Stanford AI Lab）的研究發現， 即使檢索到了正確的文件，40% 的 RAG 回應仍會產生幻覺。檢索環節奏效了，但事實依據（Grounding）卻失效了。

為什麼 RAG 檢索的是文件，而非答案

這是因為標準向量相似度無法區分「主題相關的段落」與「真正回答問題的段落」。當您的法規遵循團隊詢問「針對涉及 16 歲以下歐盟居民的資料外洩，有哪些通報要求？」時，若系統傳回了三段關於 GDPR 資料外洩通報的內容，卻缺少針對特定年齡的專門條款，那麼回答看似正確，實則潛藏嚴重的殘缺風險。

我們的方法是建構專門弭平這項差距的檢索系統。具體採用何種架構，取決於您的文件類型、查詢模式以及對錯誤答案的容忍度。有時是結合交叉編碼重新排序器的 BM25 + 稠密向量混合檢索；有時是包含實體擷取與社群摘要的完整 GraphRAG 管線；有時則是對複雜問題進行拆解、反覆運算檢索並在生成前自我修正的代理型檢索迴圈。我們不會預設採用最複雜的方案——而是選擇能在可持續成本下解決您檢索問題的方案。

依據您的查詢模式量身打造的三種檢索架構

我們根據您的查詢模式來適配架構，而非預設追求複雜度。以下三種模式涵蓋了絕大多數生產環境需求。

結合重新排序的混合檢索

這是多數生產級 RAG 系統應當起步的起點。BM25 處理精確關鍵字比對（錯誤代碼、產品 SKU、法規條文編號），而稠密嵌入向量則捕捉語義意圖。 倒數排名融合（RRF，k=60） 合併兩組結果集，且不會產生困擾機器學習融合方法的分數正規化問題。

頂層配置交叉編碼重新排序器（cross-encoder reranker）： BGE-reranker-v2-m3 部署於 GPU 可提供 50–100ms 延遲且無持續 API 成本，或採用 Cohere Rerank 滿足需要代管基礎架構團隊的需求。生產基準測試顯示，此兩階段管線表現超越所有單階段方法。 Anthropic 的上下文檢索 技術進一步疊加其上，在嵌入前為每個文字區塊附加文件層級上下文，進而將檢索失敗率降低 49%（結合重新排序後達 67%）。

圖增強檢索（GraphRAG）

當您的問題需要綜合多份文件的資訊或跨實體關係進行推理時，單靠向量相似度是遠遠不夠的。若法務團隊詢問「收購方公司（AcquiringCo）的哪些子公司在目標公司（TargetCo）開展業務的司法管轄區內有未結案的監管處分？」，這就需要實體消歧解析、關係遍歷以及多跳推理。

我們從您的文件中建構知識圖譜，採用基於依存關係的擷取技術，達到 LLM 擷取效能的 94% 且僅需極低比例的詞元成本（詳見 我們關於強制引用驗證 GraphRAG 的研究）。 微軟（Microsoft）的 GraphRAG 方法（萊頓分群 + 社群摘要）適用於語料庫層級的全局理解查詢，但其索引成本是標準 RAG 的 4–8 倍。我們選擇性地運用它：

• 全域查詢採用社群摘要。
• 實體關係問題採用屬性圖遍歷。
• 其餘查詢採用標準向量檢索。

對於圖譜後端儲存， FalkorDB 以 6,693 QPS 與次毫秒級冷啟動處理重讀取的 RAG 工作負載，而 Neo4j 在您需要成熟的 RBAC、叢集與複雜聚合時仍是正確選擇。

代理型檢索

2026 年能力最強的模式，亦是做好成本最高的模式。代理型檢索迴圈將複雜查詢拆解為子查詢，將各子查詢路由至相應的檢索策略（向量、圖譜或結構化資料庫），評估結果是否充分，並反覆迭代直至達到置信度門檻。

我們在 LangGraph上實作此架構，其狀態機抽象為您提供條件分支、人機協同（human-in-the-loop）中斷節點與確定性可稽核性。糾錯性 RAG（Corrective RAG）層每次查詢會增加 100–800ms 延遲，但在檢索錯誤到達 LLM 之前將其攔截。此模式已在 摩根士丹利（Morgan Stanley）、PwC 與 ServiceNow達到生產就緒水準。但對於缺乏專門 MLOps 能力來監控與微調檢索迴圈的團隊而言，它尚未就緒。

嵌入之前的工作：把文本分塊做對

文本分塊是 RAG 系統悄然失效之處。天真的固定大小分塊產生的真實忠實度（faithfulness）評分僅有 0.47–0.51。語義分塊可達 0.79–0.82，但代價是必須對語料庫中的每個句子進行嵌入。正確的策略取決於您的文件：

• 結構化法規申報文件 ——版面感知解析可保留章節階層。
• 包含表格與圖表的混合內容 PDF ——視覺引導分塊（將每頁視為圖像進行版面偵測，然後擷取文字區域）相較於純文字解析，可將檢索精確度提高 8–15%。
• 長篇敘述性文件 ——延遲分塊（late chunking）先將整份文件輸入 Transformer，讓每個詞元嵌入都反映雙向上下文，在前向傳遞後再劃分區塊邊界。

在選定方案之前，我們會針對您的實際查詢集測試三到四種分塊策略。評估框架（RAGAS 忠實度 + 上下文精確度指標、領域特定相關性評判）作為管線的一部分交付，而非事後補充。 60% 的新 RAG 部署現在從第一天起就納入系統化評估，高於 2025 年初的不到 30%。我們將評估整合至您的 CI/CD 中，讓每次部署都能衡量檢索品質，而不是等到使用者抱怨時才發現問題。

企業級 RAG 系統的運作成本是多少？

一家製造業公司花費了 400,000 美元 部署一套 RAG 系統，隨後發現持續營運成本高達 每月 18,000 美元 ——是其預估值的兩倍以上。他們忽略的成本模型是：重新排序。嵌入 API 的費用為 每十億詞元 20–120 美元。在千萬級（10M）向量規模下，代管服務（Pinecone、Weaviate Cloud）的向量資料庫託管成本是自行託管（Qdrant、pgvector）的 1.5–3 倍。然而，在生產級查詢量下，重新排序才是導致預算爆表的原因：Cohere Rerank 的費用為 每 1,000 次查詢 2 美元，而在單一 GPU 上自行託管的 BGE-reranker-v2-m3 能以零單次查詢成本達到相近延遲——儘管您需要支付 GPU 執行個體的費用。

GraphRAG 增加了另一層成本。知識圖譜建構需要消耗 比原始文字多 4–8 倍的詞元 用於實體擷取與社群摘要。維護工作則消耗 第一年工程預算的 40–60% ，因為實體解析、重複資料刪除與本體論更新是持續性的工作，而非一次性設置。基於依存關係的擷取（使用傳統 NLP 代替 LLM 呼叫）可將建構成本降低約 90% ，同時保持 94% 的擷取品質。我們在每個專案中都會提供明確的每月營運支出預測，涵蓋嵌入、儲存、檢索、重新排序與圖譜維護。

何時值得採用 GraphRAG（以及何時不值得）

當您的查詢需要跨實體與關係進行多跳推理時，您就需要圖增強檢索：

• 涵蓋數百份子公司申報文件的併購盡職調查。
• 跨藥物交互作用資料庫的臨床證據整合。
• 將供應商網路與監管行動關聯起來的供應鏈風險分析。

GraphRAG 在基準測試中針對複雜的多層級企業查詢展現出最高的搜尋精確度（參見 引用驗證型法律檢索的實際示範）。當您的查詢屬於單一文件查找、FAQ 式問答或關鍵字驅動搜尋時，您並不需要它——結合重新排序器的 BM25 + 稠密向量混合檢索能以極低的成本與複雜度處理這些需求。如果您的語料庫規模低於 500 萬個向量 且問題不跨越文件邊界，具備 HNSW 索引的 pgvector 就確實足夠了。我們會在推薦架構前對此進行評估，並在更簡單的方案為正確選擇時坦誠相告。

「我們真的還需要 RAG 嗎？」這個問題同樣值得探討。隨著上下文視窗突破 100 萬詞元（Gemini 3 Pro 達 1,000 萬），部分團隊考慮將整個語料庫塞入提示詞中。問題在於：單次 100 萬詞元的查詢成本高達 2–10 美元，這在企業級查詢量下是無法承受的。即使在宣稱的限制之內，一旦超過特定門檻，上下文品質也會發生衰退。對於任何需要針對龐大且持續變化的文件集進行重複查詢的系統而言，RAG 依然是正確的架構。

RAG 管線的攻擊面是什麼？

PoisonedRAG 的研究（USENIX Security 2025） 證實，在包含百萬份文件的語料庫中注入 5 份精心設計的惡意文件，即可操縱 AI 回應，成功率超過 90%。您的檢索管線正是對抗性內容的攝入途徑。OWASP 現已正式將向量與嵌入漏洞（LLM08:2025）以及透過檢索文件注入提示詞（LLM01:2025）列為 LLM 頂級安全風險。

我們在檢索管線中構建文件出處追蹤、嵌入層級異常偵測與輸入淨化層。每個檢索到的段落均附帶來源中繼資料與信任評分。生成層受到約束，必須引用具體段落；無法在檢索內容中獲得事實佐證的主張會被標記而非直接放行。對於部署在受監管環境中的任何 RAG 系統而言，這絕非可有可無，詳見 我們關於保護私有企業級 LLM 安全的研究。

我們的交付成果

每個專案均交付：

• 專為您的特定查詢模式與文件類型量身挑選的檢索架構。
• 針對您的實際查詢進行基準測試的分塊與嵌入策略。
• 具備 RAGAS 指標與領域特定測試案例的生產級評估框架。
• 明確的成本預測，涵蓋嵌入、儲存、檢索、重新排序以及各項圖譜維護。
• 針對基於檢索之攻擊的安全強化。
• 在使用者察覺之前即可攔截檢索品質衰退的監控技術堆疊。

若您目前的設置已足夠完善且投入更複雜檢索難以回收成本，我們亦會如實相告。