iT邦幫忙

2025 iThome 鐵人賽

DAY 28
0
生成式 AI

生成式AI的奇妙旅程:從ChatGPT到個人化應用系列 第 28

Day28|生成式 AI 的核心驅動:從 RAG 到 LLMOps 的生產級應用與挑戰

  • 分享至 

  • xImage
  •  

引言:AI 時代的巨變與挑戰

自從大型語言模型(LLM)橫空出世以來,我們的開發世界正在經歷一場前所未有的加速?生成式 AI (Generative AI) 指的是 AI 模型的一個子集,它可以從簡單的文字提示建立新的內容和成品,例如影像、影片、文字和音訊。由於單一模型就能執行多個任務,這些模型通常被我們稱為基礎模型 (FMs)

這些模型已經展現出驚人的多樣性和熟練度,即使是針對尚未明確訓練的任務也能應對自如。然而,當我們將這些強大的「巨獸」應用於企業的自訂文件(例如內部網站、專屬資訊、知識庫等) 以回答問題時,傳統方法(例如從頭訓練或微調)不僅成本高昂,且難以應對知識的即時更新。

這時,兩個關鍵的方法論和技術就成為了我們將生成式 AI 導入生產環境的核心驅動力

  1. RAG(Retrieval-Augmented Generation,擷取增強生成):解決知識專屬化與即時性的問題。
  2. LLMOps(Large Language Model Operations,大型語言模型維運):解決如何高效、安全、可擴展地駕馭這頭巨獸的問題。

今天,我們就來深入探討這兩大基石,以及如何在 AWS 等雲端環境或自訂架構中實現它們。


核心概念解析

我們將以條列方式,解釋生成式 AI 應用實作中的幾個主要概念:LLM、RAG 和 LLMOps。

一、 大型語言模型 (LLM) 與基礎

定義與原理

  • 定義: LLM 是針對大量資料預先訓練的深度學習 AI 模型。它們非常靈活,可以執行各種任務,例如回答問題、摘要文件、翻譯語言和完成句子。
  • 語言理解: LLM 解決的最根本問題在於對人類語言結構與字詞多義性的徹底理解,而且還是跨語言的理解。
  • 模型限制 (知識快照): 現階段的 LLM 就像是對「世界知識的快照」。例如,OpenAI 的 GPT-4 對世界的了解停留在 2023 年 4 月 30 日,對於該時間點之後發生的事情一無所知。

技術範例

LLM 的選擇很多元,我們可以選擇 IaaS 提供的服務,例如 Amazon Bedrock 上的 Anthropic Claude、Meta Llama 2、Amazon Titan,或是 Google 的 PaLM2、Azure 的 Azure OpenAI Service。

二、 擷取增強生成 (RAG)

詳細內容可以看前幾篇文章,這邊再簡單複習一下

定義與原理

  • RAG 定義: RAG 是一種技術,用於使用外部資料(例如公司的內部文件)增強大型語言模型 (LLM),從而為特定使用案例提供模型所需的內容,以產生準確且實用的輸出。
  • 核心優勢:
    • RAG 是一種經濟實惠的方法,可將模型的功能延伸到組織的內部知識庫,完全不需要重新訓練模型
    • 它可以讓您為自訂文件建立問答系統,而無需微調
    • 幻覺風險降低: 由於 RAG 使用向量搜尋的內容作為產生答案的基礎,因此可降低幻覺的風險
    • 即時性: RAG 可以在幾分鐘內納入最新的文件,這對於文件經常變更的場景非常重要。
    • 透明度: RAG 模型會提供資訊來源的參考,提高了透明度,使用者可以驗證引用的來源。

RAG 運作的四個高階步驟

RAG 程序大致包含四個步驟,其中第一個步驟只完成一次:

  1. 內嵌建立 (Indexing): 建立內嵌(文件中文字的數值表示法),將內部文件擷取至向量資料庫(Vector Database)。這一步需要資料清理、格式化和區塊化(Chunking)。
  2. 查詢提交 (Query): 人類以自然語言提交查詢。
  3. 擷取與增強 (Retrieval & Augmentation): 協調器 (Orchestrator) 在向量資料庫中執行相似性搜尋,並擷取相關資料(內容),然後將這些內容新增至包含查詢的提示中(即提示工程)。
  4. 生成回應 (Generation): 協調器將查詢和內容傳送至 LLM。LLM 會使用這些額外的內容產生查詢的回應。

三、 大型語言模型維運 (LLMOps)

定義與原理

  • LLMOps 定義: LLMOps 是一個涵蓋 LLMs 開發、部署、維護和優化的一整套實作的方法論和資料管理流程。
  • 與 MLOps 的關係: LLMOps 是既有 MLOps 的延伸跟擴展。傳統 MLOps 主要目標是簡化和優化將機器學習模型部署到生產環境的過程。LLMOps 則需應對許多傳統 ML 模型上不會遇到的問題,例如 Prompt Engineering、RAG 以及 Fine-tuning 等。
  • LLMOps 的目標: 嘗試去駕馭 LLM 這頭巨獸,指引它去完成人類想要的各種下游任務 (Downstream tasks),例如客服 Q&A、文本分類、Agents 等。

LLMOps 關鍵實作流程

LLMOps 實作涉及多個關鍵環節,確保應用程式的性能、安全性和可擴展性:

  1. 模型選型 (Model Selection): 評估並決定應用程式要奠基在哪一個 LLM 上,考量因素包括性能、資源需求、可擴展性、成本效益、易用性、安全性和合規性
  2. 資料整合 (Data Integration): 將企業內部零散的、多種格式的結構化與非結構化數據(例如 PDFs、Word 文件、掃描影像)轉換成生成 AI 可以使用的語料。此階段需要資料處理技術來擷取、處理和準備資料以供編製索引。
  3. 知識嵌入 (Embedding): 將企業知識讓大語言模型可吸收可理解的方法論。
  4. 提示工程 (Prompt Engineering): 指引 LLM 如何完成使用者問題的過程,目標是從 LLM 獲得準確、可靠的回應。標準結構包含:Instructions(總體任務說明)、Context(外部知識來源,例如從 RAG 擷取的內容)、Prompt Input(具體問題)、Output Indicator(標記生成文本的開始)。
  5. 上下文管理 (Context Management): 確保模型能夠在適當的時候引用正確的資訊,從而提供更相關、準確和有用的回應。

深入探討:策略、應用與防護

一、 RAG 與微調 (Fine-Tuning) 的策略性比較

在為自訂文件建置問答解決方案時,RAG 和微調是兩種主要選擇。微調涉及採用現有模型(如 Amazon Titan 或 Llama 模型),然後根據自訂資料調整模型,使其以更自訂的組織樣式來建立內容。

方法 優點 (Advantages) 缺點 (Disadvantages)
微調 (Fine-tuning) • 能夠建立更符合組織風格的內容(使用非監督式方法)。• 可協助組織遵循內部或產業特定的資料和合規標準。 時效性差: 如果自訂文件經常變更,這不是一個好解決方案(可能需要幾小時到幾天)。• 技術門檻高: 需要了解 LoRA 和 PEFT 等技術,可能需要資料科學家。• 缺乏來源: 微調後的模型不會在其回應中提供來源的參考。• 幻覺風險提高: 使用微調模型回答問題時,幻覺的風險可能會提高。
RAG 無需微調 即可為自訂文件建置問答系統。• 時效性好: 可以在幾分鐘內納入最新的文件。• 低門檻: AWS 提供全受管 RAG 解決方案,不需要資料科學家或機器學習的專業知識。• 提供來源: 會在其回應中提供資訊來源的參考。• 低幻覺風險: 由於使用向量搜尋的內容作為基礎,幻覺的風險會降低。 摘要能力差: 從整個文件摘要資訊時,RAG 無法正常運作。

建議: 如果您需要建置參考自訂文件的問答解決方案,建議從以 RAG 為基礎的方法開始。如果您需要模型執行其他任務,例如摘要,則可以使用微調。在一個模型中結合微調和 RAG 也是一種可行的最佳解決方案。

二、 RAG 的廣泛應用與 AWS 實作選項

RAG 方法已被廣泛應用於多個領域,以增強 LLM 的實用性。

實際應用場景

  • 問答系統: RAG 可以改善問答系統中的回應品質。擷取型模型使用相似性搜尋來尋找包含答案的相關段落或文件,然後產生簡潔且相關的回應。
  • 零售或電子商務: RAG 可透過提供更相關且個人化的產品建議,來增強使用者體驗。
  • 工業或製造: RAG 可協助快速存取工廠營運等重要資訊,並從內部和外部來源快速擷取更新的法規和合規標準。
  • 醫療保健: 由於存取準確且及時的資訊至關重要,RAG 可以在應用程式中提供更準確且內容感知的回應,增強人類臨床醫生可存取的資訊。
  • 法律: RAG 可以在合併和收購等複雜法律案例中套用,協助法律專業人員快速解決複雜的法規問題。

AWS 上的 RAG 全受管選項

AWS 提供了多種全受管服務來簡化 RAG 工作流程,以協助我們管理未區分的繁重工作。

選項 描述 主要 RAG 元件/功能
Amazon Bedrock 的知識庫 全受管服務,提供統一 API 使用來自領導 AI 新創公司和 Amazon 的高效能 FMs。 知識庫會管理從擷取到提示擴增的整個 RAG 工作流程。它會在內部擷取文件、區塊化、轉換為內嵌,並存放在您選擇的向量資料庫中 (例如 Amazon OpenSearch Serverless, Amazon Aurora PostgreSQL 等)。
Amazon Q Business 全受管、生成式 AI 輔助,可根據企業資料回答問題、提供摘要、產生內容。 提供超過 40 種類型的內建連接器(如 Salesforce, Microsoft SharePoint),並提供內建索引管道、護欄和身分管理功能。允許最終使用者從企業資料來源接收立即的許可感知回應
Amazon SageMaker AI Canvas 提供無程式碼視覺化界面,透過無程式碼的文件查詢功能提供 RAG,可以將 Amazon Kendra 索引作為基礎企業搜尋來豐富聊天體驗。 SageMaker AI Canvas 會管理 Amazon Kendra 與所選基礎模型之間的通訊。

如果這些全受管服務不符合您的需求(例如需要選擇特定的向量資料庫或 LLM),您可以選擇自訂 RAG 架構,使用 Amazon Kendra、Amazon OpenSearch Service、Amazon Aurora PostgreSQL + pgvector 或 Pinecone/MongoDB Atlas 等第三方服務來自訂擷取器 (Retriever),並使用 Amazon Bedrock 或 SageMaker AI JumpStart 來作為產生器 (Generator)。

三、 LLM 部署與維運的進階挑戰

將 LLM 投入生產需要考慮到高效能推論、資源管理和安全性。

1. 高效能 LLM 部署:vLLM 與 K8S/Ray

為了提供極致的性能和高輸送量,我們必須使用專為 LLM 推理設計的優化框架和架構。

  • vLLM 框架: vLLM 是專為 LLM 推理和部署設計的高性能開源框架。它採用 PagedAttention 技術優化注意力鍵值的記憶體分配,支持長上下文窗口,並結合連續批處理 (Continuous Batching) 顯著提升輸送量。
    • 性能指標: 在相同延遲下,vLLM 的輸送量較 HuggingFace Transformers 高 8.5–15 倍。
  • K8S + GPU 部署: 在生產環境中,為了管理和調度 GPU 資源,Kubernetes (K8S) 是主流選擇。部署需要確保配置 NVIDIA GPU 驅動、nvidia-docker 運行時,以及 NVIDIA Device Plugin 插件來支持 K8S 識別和調度 GPU 資源。
  • 多機多卡策略: 對於超大型模型(例如 Qwen-72B),需要使用多張 GPU(如 H20 96GB 顯存卡)來實現高 QPS (每秒查詢數,目標 QPS 可達 600 以上)。
    • 張量並行 (Tensor Parallel): 將模型單層內的參數分割到多個 GPU 上,每個 GPU 處理參數的一部分,主要目標是降低單卡顯存佔用
    • 管道並行 (Pipeline Parallel): 將模型分層分配到不同 GPU 上,形成流水線階段,主要目標是通過重疊計算和通信的方式提升吞吐量
  • 模型優化: 為了降低算力需求,可以使用模型壓縮(如權重剪枝、量子化)和知識蒸餾 (Knowledge Distillation),將大型複雜的教師模型的知識轉移到更小、更高效的學生模型中。

2. LLM 的潛在風險與防護

隨著 LLM 在企業中的應用,資安風險也隨之而來。OWASP(Open Worldwide Application Security Project)在 2023 年將 LLM 資安風險納入了其 Top 10 關鍵風險列表。

OWASP LLM Top 10 關鍵風險 (部分列舉) 潛在威脅與影響
指令注入 (Prompt Injection) 攻擊者透過精巧的指令操控 LLM 產生非預期的回應或行為,誘使模型洩漏機敏資訊。
錯誤資訊 (Misinformation) / AI 幻覺 (Hallucination) LLM 可能產生看似可信但實際上不正確或具誤導性的資訊。RAG 雖然能降低幻覺,但如果誤解了來源的上下文混合了新舊資訊,仍可能導致錯誤結論。
敏感資訊揭露 (Sensitive Information Disclosure) LLM 在回應中不慎洩漏機密資料,或使用者在輸入時無意間輸入了機敏資訊。
向量與嵌入弱點 (Vector and Embedding Weaknesses) 針對使用 RAG 的系統,攻擊者可能透過向量與嵌入對模型注入有害內容、操控模型輸出,或存取機敏資訊。
過度代理授權 (Excessive Agency) LLM 被賦予過高的自主權或過多的權限,可能導致機密資訊的存取或洩露。
無限資源耗盡 (Unbounded Consumption) 攻擊者操控 LLM 產生大量輸出或傳送大量耗費資源的請求,導致阻斷服務(DoS)攻擊。

企業防護策略

企業應從多方面著手保護 LLM:

  • 網路安全: 部署 AI 防火牆 (Firewall for AI),專為保護 LLM 設計的資安防護層,能在 API 請求到達模型之前掃描指令,尋找潛在攻擊。AI 防火牆也能運用機敏資料偵測 (SDD) 識別模型回應中可能吐出的 PII 或機密資訊。
  • 存取控制: 實施最小權限原則、多因素驗證 (MFA) 和 PassKey,確保只有授權的用戶能執行特定操作。
  • 監控與日誌: 透過監控全面的系統日誌、行為模式及異常活動,即時偵測潛在威脅。

結語與展望

從我們深入探討 RAG 的原理,到理解 LLMOps 如何將這些複雜技術產品化,再到面對潛在的資安威脅,我們可以清楚地看到:生成式 AI 的價值,絕對不在於單純調用一個 API,而在於整個維運的「系統工程」

系統工程的核心目標是設計、開發和管理在其生命週期內的複雜系統。將 LLM 應用落地,我們需要的正是這種跨學科領域的整體觀點,將資料處理、模型選擇、RAG 管道、高性能部署 (如 vLLM + K8S) 和嚴格的資安護欄 (如 AI 防火牆) 整合為一個可靠的整體。

雖然技術充滿挑戰,但這也是我們這代工程師最熱血沸騰的時代!無論你是資料科學家、後端工程師,還是熱衷於全棧開發的夥伴,掌握這些 LLMOps 和 RAG 的實戰技能,都將助你在 AI 時代中保持絕對的競爭力。

生成式AI之路還很長,讓我們一起持續學習、持續實驗,將這些技術從概念變成可靠、具備成本效益的生產級產品吧!

下篇文章見!


上一篇
Day27|RAG 與知識圖譜的完美結合:GraphRAG 如何實現更精準、可解釋的生成式 AI
系列文
生成式AI的奇妙旅程:從ChatGPT到個人化應用28
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言