AI 時代來臨，企業的 SOP、產品手冊與內部規章往往散落在不同系統，根據我們協助企業導入 AI 的經驗，問題通常不在資料不足，而在資料沒辦法「直接問出來」，本文將說明背後的 RAG 原理，以及如何用 Amazon Bedrock Knowledge Bases 實際建置，讓讓員工用自然語言提問，由 企業 AI 知識庫中找出依據並附上來源回答。
RAG 是什麼？和模型微調差在哪？
RAG（Retrieval Augmented Generation，檢索增強生成）是讓 AI 先查資料、再回答的做法，使用者提問時，系統會先從企業文件中找出最相關的段落，再把這些段落交給大型語言模型，由模型整理成自然的回答並標註出處。
要讓 AI 理解企業知識，另一種常見做法是模型微調（fine-tuning），也就是用企業資料重新訓練模型。
兩種做法的差異如下：
|
比較項目 |
RAG |
模型微調 |
|---|---|---|
|
資料更新 |
替換文件、重新同步即可 |
需要重新訓練模型 |
|
建置成本 |
較低，不需 GPU 訓練 |
較高，需準備訓練資料與運算資源 |
|
答案可追溯 |
可標示引用來源 |
難以說明答案出自哪份文件 |
|
適合情境 |
規章、手冊、FAQ 等會變動的知識 |
調整模型語氣、特定任務格式 |
由上表我們可以知道，對大多數「找資料、問規定」的需求來說，RAG 是更快上線、也更容易維護的選擇。
Amazon Bedrock Knowledge Bases 能做什麼？
Amazon Bedrock Knowledge Bases 是 AWS 提供的全託管 RAG 服務，把原本需要工程團隊自行串接的環節整合成一套流程，企業只要把文件放進 Amazon S3，完成同步後就能開始提問。
整個流程分成兩個階段：
- 建立索引（文件更新時才執行）：系統讀取文件、切分成適當大小的段落（chunking）、轉換成向量（embedding），再存入向量資料庫。
- 檢索與回答（每次提問時執行）：系統依問題找出最相關的段落，交給基礎模型生成答案，並附上引用來源。
換句話說，企業不需要自己撰寫切塊程式、維運向量資料庫，也不必處理檢索與生成之間的串接，可以把心力放在「要放哪些文件」與「答案品質好不好」上。
.png)
文件只在更新時重新建立索引；員工每次提問，系統都會從向量儲存中找出相關段落，交給基礎模型生成附來源的答案，Guardrails 則同時把關提問與回答。
知識庫類型與向量儲存怎麼選？
導入前有兩個關鍵決定：要用哪一種知識庫，以及向量資料要存在哪裡。
知識庫類型
|
類型 |
適合的資料 |
取捨 |
|---|---|---|
|
自行管理・非結構化 |
PDF 手冊、SOP、規章、產品型錄 |
可自訂切塊方式、向量儲存與成本，彈性最高 |
|
Bedrock 託管 |
想透過 SaaS 連接器快速串接 |
設定最快，但可調整的空間較少 |
|
自行管理・結構化 |
Amazon Redshift 中的訂單、庫存、財務資料 |
不必另建 Text-to-SQL，就能用自然語言查表 |
向量儲存
- Amazon S3 Vectors：沒有閒置費用，適合以語意搜尋為主、使用量不固定的情境，例如內部 FAQ、規章查詢，也很適合當作試行專案的起點。
- Amazon OpenSearch Serverless：支援關鍵字加語意的混合搜尋與進階篩選，適合查詢量大或需要精準比對料號、型號的情境；新版已可縮減至零，降低閒置成本。
建議先以 S3 Vectors 做小範圍驗證，確認有混合搜尋需求後再升級。
建置企業 AI 知識庫的 5 個步驟
盤點並整理文件
挑出最常被問到的知識來源，例如 SOP、產品手冊、人資規章、客服 FAQ。支援格式包含 PDF、Word、Excel、CSV、HTML、Markdown 與純文字。過期或重複的版本務必先清掉，因為 AI 的回答品質取決於文件品質。
上傳至 Amazon S3 並規劃權限
依部門或資料類型建立資料夾分類，方便日後控管存取範圍。也可為每份文件加上 metadata（例如部門、產品線），讓查詢時能依條件篩選。
建立知識庫並選擇切塊策略
在 Amazon Bedrock 主控台設定資料來源、嵌入模型與向量儲存。切塊方式對檢索品質影響最大：
- 固定長度切塊：適合格式一致的 FAQ
- 語意切塊：適合說明性、敘述性的文件
- 階層式切塊：適合章節層次多的規章與手冊
- 含表格、圖片或掃描檔的 PDF：可搭配 Amazon Bedrock Data Automation 或基礎模型解析
同步與測試
執行同步後，用實際員工會問的問題測試，並檢查每個答案引用了哪些段落。答案不準時，回頭調整切塊方式、補 metadata 或整理原始文件。上線前建議準備一份「問題與標準答案」評估集，用 Bedrock 的 RAG 評估功能量化準確度。
串接到員工或客戶使用的介面
可嵌入企業入口網站、內部系統，或串接 Microsoft Teams、Slack、LINE 等通訊工具，前端主要呼叫兩支 API：RetrieveAndGenerate 直接回傳附引用的答案；Retrieve 只回傳相關段落，方便您搭配自訂提示詞使用。
文件內容更新時記得重新同步，也可以透過 S3 事件通知自動觸發。
用 Guardrails 守住回答品質與資料安全
企業導入 AI 最擔心的往往不是技術，而是「AI 會不會亂講」和「資料會不會外洩」，Amazon Bedrock Guardrails 可以同時檢查使用者的提問與 AI 的回答，常見設定包括：
-
禁止話題：例如不回答法律、醫療或投資建議，並引導至對應的負責單位。
-
內容過濾：依需求調整仇恨、不當言論、提示詞注入攻擊等類別的過濾強度。
-
敏感資訊遮罩：自動偵測並遮蔽身分證字號、電話、員工編號等個人資料。
-
情境依據檢查：要求回答必須有檢索到的文件作為依據，降低 AI 幻覺。
-
友善的拒答訊息：查無資料時，回覆「目前文件中找不到相關資訊，請洽 OO 部門」，而不是硬湊答案。
-
文件保留在企業自己的 S3 儲存桶，並對向量儲存啟用靜態加密。
-
以 IAM 落實最小權限原則，不同部門只存取各自的資料。
-
涉及個資或機敏資料的文件，先評估是否適合放入知識庫，並符合《個人資料保護法》等相關規範。
企業 AI 知識庫的 3 大應用場景
製造業：設備維修與作業 SOP 查詢
工廠累積大量設備手冊、維修紀錄、品質規範與作業標準書，但現場人員遇到異常時，往往只能等資深技師支援。將這些文件建成 AI 知識庫後，產線人員可以直接問「CNC 主軸過熱的排除步驟是什麼？」，系統會引用對應的手冊章節回答，縮短停機時間，也降低對特定人員經驗的依賴，有助於技術傳承。
客服中心：產品規格與售後問題
客服人員每天回答大量重複問題，例如保固範圍、退換貨流程、產品相容性。AI 知識庫可以先提供附來源的建議答案，客服確認後再回覆，新進人員也能更快上手。
人資與行政：內部規章查詢
請假規定、出差報帳、福利申請等問題，員工隨時可以自助查詢，人資團隊不必再反覆回答相同問題，能把時間放在更有價值的工作上。
-
先選一個部門、一類文件：例如先做客服 FAQ 或單一產線的 SOP，範圍明確才容易評估成效。
-
先定義「答對」的標準：準備 30～50 組真實問題與標準答案，作為上線前後的比較基準。
-
文件品質比模型更重要：多數答不準的情況來自文件過時、版本混雜或掃描檔無法辨識，整理文件的投資回報往往最高。
-
每次調整都要重新評估：更換切塊方式、新增文件或更換模型後，都應重跑評估集。
-
控制成本：試行階段使用 S3 Vectors 等無閒置費用的方案，確認效益後再依使用量擴大。
常見問題 FAQ
Q1：企業 AI 知識庫和一般的內部搜尋有什麼不同？
傳統搜尋需要輸入正確的關鍵字，結果是一串文件清單，還得自己點開閱讀。AI 知識庫能理解問題的語意，直接整理出答案並標示出處，即使用詞和文件不同也找得到。
Q2：公司資料放進知識庫，會被拿去訓練模型嗎？
不會。Amazon Bedrock 不會使用客戶的資料訓練基礎模型，文件也保留在企業自己的 AWS 帳號中。
Q3：導入需要很大的工程團隊嗎？
不一定。Amazon Bedrock Knowledge Bases 已處理切塊、向量化與檢索等環節，試行階段透過主控台就能完成設定；正式串接企業系統時，再由內部或合作夥伴協助開發前端與權限整合。
Q4：中文文件的效果好嗎？
可以支援繁體中文文件與提問，但建議選擇支援多語言的嵌入模型，並用實際的中文問題做評估測試。
Q5：費用大概怎麼計算？
主要包含嵌入與生成的模型用量、向量儲存費用，以及 S3 儲存費用，實際金額取決於文件量與提問次數。建議先以小範圍試行估算單位成本。
