RAG 架構：讓企業擁有專屬的「AI 大腦」

作者/陳冠豪


【內容摘要】企業導入生成式AI的關鍵技術——RAG（檢索增強生成），透過嵌入模型（Embedding Model）將文字轉為向量座標，實現語意搜尋，讓企業知識庫不再依賴關鍵字比對，真正打造專才AI。然而實務中，切塊（Chunking）策略不當、知識版本衝突、通用模型難以理解企業內部術語、缺乏詮釋資料（Metadata）與權限管理，以及模型注意力缺陷等問題，都可能導致RAG失效，甚至引發資安與管理危機。建造企業級AI知識庫絕非一鍵安裝，而是需要技術團隊針對業務情境反覆調校的資料清洗工程。 【TAG 關鍵字】#生成式AI # RAG #檢索增強生成 #Embedding Model #企業知識庫 #Chunking切塊(Chunking)策略 #RAG失效 #資安 #資料清洗

作者簡歷

作者目前擔任凌群電腦資通技術處經理，現專職AI解決方案規劃與領導AI專案開發，並規劃凌群AI開發團隊之研究方向。

讓通用型AI，轉化為專才AI，RAG (檢索增強生成)

在上一期中，我們學會了如何透過「提示工程」為AI建立嚴格的邊界與邏輯，不過無論提示詞寫得多好，如果AI腦袋裡空空如也，也只是具備網路上抓來的通用常識，它依然無法回答企業內部的專業問題。 為了解決這個問題，目前業界最主流、也是現行企業導入AI唯一不可或缺的技術架構RAG (檢索增強生成)誕生了。 透過RAG架構，我們能為企業打造專屬的知識庫，但這個知識庫，究竟是如何運作的？為什麼它比傳統的關鍵字搜尋聰明這麼多？筆者相信…現在講AI，每個人都會講RAG，但實際知道它的運作原理的人應屬少數。

向量化的魔法：把文字變成座標

想像一下，如果我們用傳統系統的搜尋，輸入「蘋果」，系統是透過「關鍵字比對」來找文章，但如果文章裡寫的是「Apple」，系統可能就找不到囉！這是因為傳統搜尋依賴的是字面上的絕對準確。 但RAG的底層運作是完全不同，它依賴的是「向量化」與「語意搜尋」。 當我們將企業的請款辦法、人事規章或技術文件放入知識庫時，系統會透過一個嵌入模型也就是Embedding Model，將每一段文字轉換成一串極長的數字，也就是幾百或幾千維度的向量座標，我們可以把這想像成一個無比巨大的立體星空圖：
  • 意義相近的詞彙，在這個星空圖上的座標會非常靠近（例如「狗」和「幼犬」會相近、而「蘋果」和「iPhone」也會相近）。
  • 若是意義無關的詞彙，則座標就會離得很遠。
    • 因此，當使用者提問「我要怎麼報帳？」時，即使文件上寫的是「費用請款流程」，AI也能瞬間理解這兩句話在「數學座標」上是極度靠近的，它不是在比對文字，而是在計算空間中的「距離」；至此也就呼應了筆者在本刊五月號(第343期)稿文「演算法到模型的解密：機器是如何「懂」人話的？」，同樣都是將數學的運算計算到一個極致，為什麼RAG和模型會看起來就像真的聽懂了我們的言外之意。
    《圖一》圖片來源：AI生成

    實務面的殘酷真相：為什麼有了RAG，還是找不到答案？

    懂了向量化的原理後，很多企業主又會陷入另一種浪漫幻想：「太好了！那我們就把公司過去十年的檔案全部倒進知識庫裡，AI就會無所不知囉？」筆者：真是天真又浪漫的幻想呀！ 這是真的有在第一線參與過AI應用開發，才會知道在實務上常常發生這種窘境，那就是文件裡明明有答案，但AI卻說「找不到」，或者給出錯誤的結論？Why？ 除了前置作業的「切塊（Chunking）」策略可能因為粗暴切割而毀滅了表格與語意邏輯之外，還有幾個會讓RAG失效的致命傷：

    一、知識過時與版本衝突：

    企業的文件是會更新與改版的，伺服器裡往往同時存在2024年舊版和2026年新版的「差勤管理辦法」，由於基礎的向量搜尋只看「語意相似度」，不看「時間戳記」，AI很容易覺得舊版規定在語意上更匹配，就直接拿舊辦法來回答，導致員工照著錯誤的規範流程執行。

    二、通用模型的「行話」障礙：

    每家企業都有自己的專業術語或專案代號，通用型的嵌入模型因為是用網際網路的通用資料訓練的，它可能無法理解我們內部的「行話」，明明是高度相關的業務內容，在AI眼裡卻因為缺乏關聯性，而在向量空間中被判定為毫不相干，導致完全檢索不到。

    三、缺乏詮釋資料與權限混亂：

    真實的知識庫不能只有單純的文字，還必須上標籤（Metadata，例如：部門、日期、機密等級）；如果沒有設計好這層過濾機制，當一般員工發問時，AI可能會因為語意相近，直接把只有主管階層才能看的「機密薪資結構」或「高階經理人考核標準」給撈出來當作答案，這將引發企業內部極度嚴重的資安與管理災難。

    四、迷失在中間：

    就算系統很聰明地撈出了所有正確的文件片段，但如果我們把過多的參考資料一次全部塞給大型語言模型，模型往往會出現「只記得開頭和結尾，卻忘記中間內容」的注意力缺陷，這也是為什麼 RAG並不是「資料給得越多越好」，而是要給得「少又精」。 由於語言模型有「上下文」的限制，就像我們人類的短期記憶容量，我們不可能每次提問都把整本500頁的操作手冊塞給模型讀一遍，所以我們必須把長篇文件「切碎」成一小塊一小塊的Chunk，再轉成向量存起來；看到這裡若很難想像的話可參閱本刊四月號(第342期)文章「資料工程：AI模型背後的技術供應鏈」一文。 而技術就藏在切塊的細節裡：

    一、粗暴的字數切割：

    如果工程師設定「每300個字切一刀」，很可能會把一句話、或是條款的「前提條件」與「結果」硬生生切成兩半，當模型只檢索到後半段時，就會給出斷章取義的災難性回答。

    二、表格與排版的毀滅：

    企業文件充滿了表格，如果切塊時沒有做好結構化解析，表格的「標題欄」和「數據列」會被拆散，所以當使用者問「某 產品第二季的營收是多少？」，系統找出的向量碎片根本拼湊不出完整的邏輯。

    三、Top-K檢索限制：

    為了運算效率，系統通常只會抓取「最相關的前5個」片段給模型參考，如果真正的答案因為某些雜訊，被排到了第6 名，那麼模型就永遠看不到真相，只能乖乖地回答使用者：「文件未記載」。
    《圖二》圖片來源：AI生成

    建置AI知識庫是一門資料清洗之工藝，而非一鍵安裝

    RAG在現行的AI應用中之所以能如此快速的普及，是因為它完美結合了「資料檢索的可靠性」與「生成式AI的推理能力」；但也正如我們所見，要讓這套技術在實務中穩定運作，仰賴的是極度細緻的資料前處理與切塊策略。 這也是為什麼，不要輕易相信現在市面上宣稱「上傳文件就能立刻得到完美AI助理」的無腦方案！真正的企業級知識庫，需要技術團隊針對業務情境進行反覆的調校與實驗，這也是為什麼筆者在面對諮詢AI的客戶時，總是一再的強調「能適用於企業的專才AI就是需要客製化」。 許多企業在經歷了RAG實作的陣痛期後，往往會產生一個疑問：「既然RAG這麼麻煩，我們為什麼不乾脆自己『訓練（Fine-tuning）』一個模型就好？」 下一期，我們將直球對決這個企業最常問的技術路線之爭：「RAG vs. Fine-tuning：技術路線的抉擇」。