企業 AI 不只是 LLM：打造高品質 RAG 知識庫的架構與最佳實務

Posted on by Rico

近兩年，大型語言模型（LLM）快速發展，許多企業開始導入 AI，希望能建立企業專屬的 AI 助理、知識問答系統或智慧客服。

然而，在實際導入過程中，我發現許多企業都有一個共同的迷思：

只要導入一個夠大的 LLM，就能解決所有問題。

事實並非如此。

真正影響企業 AI 成功的，往往不是模型大小，而是企業知識如何被整理、管理與提供給 AI 使用。

這也是近年 Retrieval-Augmented Generation（RAG）快速成為企業 AI 主流架構的原因。

企業 AI 面臨的最大挑戰

大型語言模型雖然擁有龐大的知識，但它並不了解你的企業。

它不知道：

  • 公司 SOP
  • ISO 文件
  • ERP 操作流程
  • EIP 公告
  • 合約規範
  • 內部技術文件
  • 維運手冊
  • 歷史專案經驗

如果直接詢問這些內容，模型通常只能依照公開知識進行推論，甚至產生看似合理卻完全錯誤的回答（Hallucination）。

因此，企業真正需要的並不是「讓 AI 更聰明」，而是「讓 AI 能找到正確的企業知識」。

RAG 到底是什麼？

RAG（Retrieval-Augmented Generation）可以理解成：

回答問題之前，先去查公司的知識庫，再根據查到的內容回答。

整個流程大致如下：

使用者提問
      │
      ▼
搜尋企業知識庫
      │
      ▼
找出最相關的文件內容
      │
      ▼
組成 Prompt
      │
      ▼
交給 LLM 推論
      │
      ▼
產生回答

換句話說，LLM 不再依賴自己的記憶，而是依據企業最新、最正確的知識回答問題。

這也是 RAG 最大的價值。

很多人以為「建立知識庫」只是上傳 PDF

這可能是企業導入 AI 最常見的誤解。

很多人認為：

把 Word、PDF 或 PowerPoint 丟進系統，就完成知識庫建置。

實際上，真正的流程遠比想像中複雜。

文件蒐集
      │
文件解析
      │
OCR（必要時）
      │
Chunk 切割
      │
Metadata 建立
      │
Embedding
      │
向量資料庫
      │
Retriever
      │
Prompt
      │
LLM

真正耗費時間的，往往不是 AI，而是前面的知識工程（Knowledge Engineering）。

Chunk，決定 AI 能不能找到正確答案

很多人在第一次建置 RAG 時，都會花大量時間研究：

  • 用哪一個 LLM？
  • GPU 要多快？
  • 向量資料庫要選哪一套？

但真正影響回答品質的，通常是另一件事：

Chunk（文件切割）。

如果 Chunk 太大：

AI 一次取得太多內容，容易混淆不同主題。

如果 Chunk 太小：

上下文不足，回答又容易失去完整性。

因此，一個好的 Chunk 應該遵循一個簡單原則：

一個 Chunk，只回答一個主題。

例如：

一份 SOP 有十個章節。

正確做法不是：

  • 一整份文件一個 Chunk

也不是：

  • 每一句話一個 Chunk

而是：

  • 每個章節或每個步驟形成一個完整 Chunk。

這也是許多企業在調整 RAG 品質時，最常反覆優化的部分。

Metadata，比 Embedding 更重要

很多技術文章都在討論 Embedding Model。

但在企業環境裡，我認為 Metadata 往往更重要。

例如，每份文件都應至少保存：

  • 文件名稱
  • 文件版本
  • 部門
  • Owner
  • 生效日期
  • 文件分類
  • 安全等級
  • 關鍵字

有了這些資訊，企業才能做到：

  • 只搜尋最新版本
  • 僅查詢特定部門文件
  • 不同權限看到不同內容
  • 自動排除已失效文件

這些能力，都是企業 AI 真正需要的功能。

AI 回答品質，其實取決於知識品質

很多人會花大量預算升級 GPU、購買更大的模型。

但實際專案經驗常常發現：

如果知識庫品質不好，再大的模型也無法回答正確答案。

企業 AI 的品質，大致受到以下因素影響：

Knowledge Quality
        │
        ▼
Document Structure
        │
        ▼
Chunk Design
        │
        ▼
Metadata
        │
        ▼
Retriever
        │
        ▼
Embedding
        │
        ▼
Prompt
        │
        ▼
LLM

令人意外的是，LLM 並不是第一順位。

真正排在最前面的，是知識本身。

RAG 是一個持續優化的工程

不少主管會問：

「知識庫建好後，是不是就完成了？」

答案通常是否定的。

企業文件每天都在更新。

新的 SOP 發布。

舊制度廢止。

流程改版。

ERP 更新。

ISO 文件修訂。

每一次更新，都可能需要：

  • 重新切割 Chunk
  • 重建 Embedding
  • 更新 Metadata
  • 重建向量索引

因此，RAG 更像是一個持續優化的工程，而不是一次性的專案。

常見的五個迷思

迷思一：文件越多越好

不是。

品質永遠比數量重要。

迷思二：Chunk 越大越準

不是。

Chunk 過大，通常會降低檢索精確度。

迷思三：LLM 越大越好

未必。

知識品質與檢索策略，往往比模型大小更重要。

迷思四：Embedding 模型越大越好

不一定。

Embedding 的一致性與穩定性，比模型規模更重要。

迷思五：RAG 建立一次就結束

錯。

企業知識每天都在改變。

RAG 必須隨著知識持續更新。

我的建議：把 AI 當成知識工程，而不是模型工程

近年大家都在討論 LLM、GPU 和參數規模。

但真正完成多個企業 AI 專案後，我越來越相信：

企業 AI 的核心，不是模型，而是知識。

模型會持續進步。

GPU 每年都會更新。

Embedding 也會一直演進。

唯有企業知識，是每家公司最獨特、最有價值的資產。

因此，真正值得投入的，不只是選擇哪一個模型，而是建立一套可治理、可維護、可持續演進的知識管理架構。

當企業能做好文件治理、Chunk 設計、Metadata 管理與檢索策略時，即使未來更換不同的 LLM，也能快速延續既有知識庫的價值。

這或許才是企業導入 AI 最重要的一步。