企業AI導入可信RAG架構　查資料再答消弭幻覺(下)

為了克服「大型語言模型（LLM）」依賴參數化記憶所帶來的侷限，「檢索增強生成（RAG）」技術應運而生，在專門的領域，如醫療、法律等極度依賴專業利基知識的領域中，該機制能提升回應的精準度與專業性。然而，RAG系統的實際效能取決於檢索品質、資料時效性及提示詞設計等多項因素，建立系統化的評估指標與持續優化機制將是企業AI建置成功的關鍵。

上集文章已經詳細介紹了RAG的基本背景與核心框架，比較RAG與其他AI的不同之處，以下將透過情境模擬的方式進行實作，實際建構RAG基礎架構以及Ragas自動化評估工具。

情境模擬前情提要

「翼緣智旅」是一家專門提供AI智慧旅遊導覽規劃的新創公司，主打依據客戶的預算及需求並結合AI，為客戶提供客製化行程。然而，過去一年公司面臨嚴峻挑戰，雖然他們使用了大型語言模型來驅動客服機器人，能根據使用者輸入自動生成完整行程建議，但機器人經常出現「幻覺」，甚至未能掌握即時資訊。例如，在冬季旅遊旺季期間，有客戶詢問「藏王樹冰是否仍可搭乘纜車前往？」AI模型回答可以，並且仍然依照舊資料產出推薦的完整行程，但實際上官網在該期間已有「纜車因暴風雪停駛」的最新公告，模型未能即時掌握，導致實際到場的旅客撲空。類似案件一再發生，導致客戶投訴不斷，品牌信任度大幅下滑。

由於AI客服機器人的輸出無法追溯，公司在面對客訴時無法舉證，加上客戶們的個資在雲端API有外流風險，除了技術上面臨窘境，更涉及資安與法律責任。為了挽回商譽，公司重金聘請了資安專家小林前來指導，問題並非模型能力不足，而是典型的Knowledge Cutoff與靜態知識問題。純LLM架構無法即時查閱最新公告，也無法驗證資料來源，必須導入RAG架構，為模型提供「即時更新的百科全書」。同時，他參考最新的LLM-as-a-Judge評估模型，透過LLM驅動、建立一套自動化優化流程，以優化翼緣智旅的新RAG模型。

核心技術架構簡介：Local RAG + Ragas

為兼顧資料隱私、安全性與部署彈性，小林並未選擇直接使用雲端API，而是改採用LM Studio作為本地端大型語言模型的執行環境，並搭配本地端模型google/gemma-3-4b，建構完整的Local RAG架構。

小林的設計核心概念是，透過撰寫Python程式，使用LM Studio搭建的本機API服務，啟用「Local Server」模式，將模型的推論、向量檢索與資料儲存等流程全部部署於本地端設備環境，使操作在不依賴雲端API（如雲端OpenAI API）的情況下即可完成知識檢索與問答生成，無須連線至外部伺服器。可有效避免公司內部敏感資料外流風險、保護旅客個資，同時降低長期API呼叫的成本。

然而，RAG的建構須經歷多次的優化與迭代，單靠人工評估與檢測RAG，耗時耗人力，成本極高。因此小林進一步結合Ragas（Retrieval-Augmented Generation Assessment）的評估框架，實現以LLM作為評估者（LLM-as-a-Judge）的自動化品質評估流程。

另外補充說明，LM Studio可於LM Studio官網（https://lmstudio.ai/）中免費下載並啟動開源LLM，且其Local Server採用OpenAI相容API設計，使外部應用程式得以透過標準API呼叫本地模型，進行RAG的檢索與生成，以及建立Ragas自動化評估工具。

整體系統流程說明

整體的系統流程，如下所述：

1.建立索引（Indexing）：預先建立資料，將文字檔（本文的範例information.txt）轉為向量並存入FAISS資料庫。

2.自動檢索（Retrieval）：使用者提問後，系統自動去資料庫「翻資料」，找出最相關的資料參考。

3.自動生成（Generation）：Gemma-3根據翻到的資料回答問題。

4.自動評估（Evaluation）：由另一個本地端LLM串接Ragas進行評估，幫剛才的RAG回答表現打分。

了解Ragas的核心邏輯

如前文所述，相較於評估單純的LLM，RAG的系統架構與工作流程較為複雜，因此評估方法較具挑戰性。而Ragas（https://docs.ragas.io/en/stable/）是一個專為RAG設計的評估框架，提供多維度的關鍵指標以評估RAG系統分別在「檢索」與「生成」以及「整個RAG系統」的表現，可依據評估結果得出優化RAG的指南，進一步確保模型回答的真實性與可靠性。

評估方法主軸為採用LLM as a Judge機制：以「更強的LLM」來擔任裁判（例如GPT-4或本地端部署的Gemma-3），透過模擬人工審閱流程，量化RAG系統的表現。當使用者提出問題，RAG系統完成索引及生成流程後，由另一個LLM擔任評估RAG表現的角色，導入Ragas的評分指標，進行自動化評估，能有效克服人工標註成本高昂且難以擴展的限制，同時全面評估模型的性能。以更生動的比喻可想像成：把Ragas比喻為「考卷與評分標準」，而LLM是「閱卷老師」。沒有Ragas，我們得自己寫程式去告訴LLM怎麼計算Faithfulness；有了Ragas，你只需要把資料餵進去，它就會自動指揮LLM產出分數。

Ragas評估參數包括Query（使用者提出的問題）、Contexts（RAG針對使用者問題索引到的上下文）、Answer（RAG對於使用者問題的回應）與ground_truth（回應問題的正確標準答案）。Ragas基於上述評估參數，建立評估和測試RAG的函式，以不同角度衡量RAG系統是否能夠聚焦於問題的上下文、是否能夠忠實於檢索內容以及回答問題的能力。圖1表示了Ragas的評估參數與各指標間的關係：

1.Context Precision（檢索品質∕精準度）：評估檢索到的上下文是否真正與Query相關，是否包含足夠支援回答的關鍵有用資訊，計算「檢索到並且真正與Query相關的上下文」與「Query」間的比例。

2.Context Recall（檢索召回率）：此指標需要結合「標準答案（Ground Truth）」來進行比對，判斷「檢索到的資料」是否涵蓋了「標準答案」中的所有事實，衡量檢索資料的完整度，確保系統沒有遺漏任何回答問題所必需的關鍵知識。

3.Faithfulness（忠實度∕幻覺檢查）：評估RAG生成的回答是否嚴格錨定檢索內容。該指標會將答案拆分成多個陳述句，逐一驗證其是否能由上下文推導而出，檢測是否出現模型臆測或幻覺，加入資料中沒有的內容。

4.Answer Relevancy（回答相關性）：評估回答是否正確回應並解決使用者問題的核心。逆向工程：由LLM依據生成的答案反推（猜）多個可能的原始問題，並將這些反推出的問題與真正的原始問題進行語義相似度的比對。如果猜出來的問題與原始問題越接近，分數就越高；相反地，低分則反映出回答可能存在資訊缺失、偏離主題或包含過多無關的冗餘雜訊，進而造成LLM回推出的可能的原始提問偏離。

LM Studio建立本地端RAG及準確度評估工具Ragas

接下來，將透過三個步驟以LM Studio建立本地端RAG及RAG準確度評估工具Ragas。

第一步：搭建地端LLM環境（LM Studio）

為了隱私與節省成本，小林使用LM Studio在本地端運行AI模型。然後，進行下載與安裝，先前往LM Studio官網（https://lmstudio.ai/），下載適合的作業系統（Windows/Mac/Linux）的安裝包並安裝。下載安裝完成後，啟動LM Studio，完成安裝設定。然後取得模型，開啟LM Studio，在搜尋框輸入google/gemma-3-4b或Llama-3.2-3B，選擇一個版本點擊Download。模型下載完成後，按下Start a New Chat，進入主畫面。

接著，啟動本地API伺服器。如圖2所示，確認左下角與左上角標誌，進入「Developer」，並點擊正上方的「Select a model to load」。接續如圖3所示，載入先前已下載好的本地端大型語言模型。

如圖4所示，點擊「Server Settings」設定端口（預設通常是1234）。確認伺服器路徑為「http://127.0.0.1:1234」。完成後，點擊左側Status: Running。最後，如圖5所示，確認畫面中欲使用的模型顯示處已顯示「READY」，即表示完成本地端伺服器啟用。

第二步：配置Python開發環境

首先，建立資料夾，並透過終端機開啟，建立虛擬環境。新增資料夾（如「ragas」）後按下滑鼠右鍵，以「終端機」開啟資料夾。然後，在終端機中輸入如圖6中所示的指令，畫面中若出現綠色的「（venv）」，就表示虛擬環境建立完成。

接下來，安裝必要套件。透過pip指令安裝建構RAG系統與Ragas評估框架所需的相關套件，於終端機依序輸入如圖7所示的指令進行安裝。

第三步：建立Python程式

由Python搭建完整的RAG系統，並導入Ragas的評估框架。直接使用OpenAI官方Python SDK進行串接LM Studio本地伺服器，實現從「建立索引」到「自動打分」的完整流程。本文中小林的實作程式碼可至「https://gitfront.io/r/janice/TUegmTiXAF2v/ragas/」下載。整體流程與程式碼詳細說明如以下文字，並對應圖8進行說明：

第一步，準備提供給RAG的資料來源。小林預先將包含最新旅遊公告、景點介紹及交通運行狀態等資料建立成一個文檔，如圖9所示，供後續RAG系統依據使用者提出的問題，進行相關資料的索引。

第二步是建構RAG流程，過程如下：

1.embeddings.py（建立旅遊知識庫）：負責將原始文件（如information.txt）的文字切成片斷，並透過Embedding模型轉換為向量存入FAISS資料庫。

2.retriever.py（搜尋相關公告）：當使用者提問時，負責從向量資料庫中找出最相關的文字片段。

3.generator.py（生成回應）：將「問題」與「找出的相關文字片段」組成Prompt，並沿用OpenAI官方Python套件「from openai import OpenAI」，完成本地模型API呼叫，交給本地端LLM生成繁體中文回答。

第三步為Ragas評估框架（main_eval.py）。這是將RAG系統與Ragas框架串接的關鍵步驟，建構真正的自動評估RAG流程。導入Ragas框架進行品質量化評估，由本地端LLM（Gemma-3）建立Ragas評估器，自己幫自己的RAG系統表現打分。

完成以上檔案的建立後，確認同一個資料夾路徑下（如本文為C:\Users\dora9\ragas）包含information.txt、embeddings.py、retriever.py、generator.py、main_eval.py，並於終端機輸入「python main_eval.py」。

等待幾分鐘後，即可得到RAG系統產生的回答、Ragas的評分結果以及評估報告表格。圖10所示是終端機顯示的評估結果摘要，將所有指標評分分別進行加權平均，圖11則是彙整出的各項的詳細結果報告。

表1、表2擷取「Ragas詳細評估報告」中的部分RAG問答與Ragas評分結果。

在表2中，Faithfulness、Answer Relevancy與Context Precision皆為0，主因可能是此題為虛構陷阱題其問題內容（如「山嵐暖心足湯」）並不存在於檢索資料中。在此情境下，雖然模型正確回應「無資料可回答」，但由於Ragas評估機制仍會比對生成內容與參考答案及檢索內容之間的語意關聯性，因此在缺乏可對應知識依據時，相關指標可能被評為0。

最終，在針對「蔵王の樹氷專案」進行初步測試後，小林觀察執行結果如下：

‧Faithfulness（忠實度）達到了0.7：顯示系統生成內容在一定程度上依據檢索資料，但仍存在部分未完全對齊原始內容的情形，代表模型在引用資料時仍可能出現輕微偏差。

‧Context Recall（檢索召回率）達到1.0：代表檢索系統能有效涵蓋與問題相關的關鍵資訊，未出現明顯遺漏。無論是處理時間敏感的「點燈日期」或是特定的「交通套票變更」，檢索器都能將正確的知識片段提供給LLM。

‧Context Precision（精準度）達到0.7667：顯示檢索結果中，多數內容與問題具有相關性，但仍包含部分非關鍵或次要資訊，顯示檢索結果仍有優化空間。

‧Answer Relevancy（相關性）異常出現0：小林判斷這可能是因為本次測試的模型（Gemma-3-4b）小，而Ragas的某些測試指標（如Relevancy）需要LLM進行「反向生成問題」的複雜推理；本地小模型作為評估裁判時邏輯能力不足，而非RAG失敗。

小林隨即根據Ragas指標進行RAG優化，嘗試採用更大的模型進行評估。透過「開發 - 評估 - 修正優化」流程逐步改善系統表現。小林成功在短時間內提升了系統表現。

結語

本文以LM Studio本地化實作，在兼顧隱私與成本的情況下，快速搭建基本的RAG系統流程，並以LLM as a Judge的方式導入Ragas自動化評估框架，建立評估RAG效能的多維度指標，藉由量化指標，開發者能精準找出RAG系統的弱點並加以修補。

＜本文作者：社團法人台灣E化資安分析管理協會（ESAM, https://www.esam.io/）中央警察大學資訊密碼暨建構實驗室 & 情資安全與鑑識科學實驗室（ICCL and SECFORENSICS）1998年成立，目前由王旭正教授領軍，並致力於資訊安全、情資安全與鑑識科學、資料隱藏與資料快速搜尋之研究，以為人們於網際網路（Internet）世界探索的安全保障（https://hera.secforensics.org/）＞