今時今日的 LLM 基礎模型非常強大,可以處理繁複任務,例如撰寫故事、推薦個人資料等。但為什麼企業仍需要自訂基礎模型?主要原因是需要處理特定任務,尤其是使用自己的數據集。
基礎模型通常沒有我們數據集的知識。因此,我們需要用不同的方法來解決這個問題。而檢索增強生成 (RAG) 是表現較理想的方案。以下將介紹 RAG 的好處以及在 AWS 上實踐 RAG 的工具。
自訂基礎模型方法多 技術表現以 RAG 佔優
其中一個自訂方法是提示工程 (prompt engineering),將問題和資料內容作為提示,直接傳遞給 LLM,讓它回答和分析。但大如整個企業的數據集,需要輸入很多 token,按 token 計費就會十分昂貴,遑論許多 LLM 有 token 限制。另一種技術是微調 (fine-tuning)。用戶提供較小的數據集給微調模型以理解特定知識。但按 AWS 技術人員的經驗,當提供全微調的數據集以使模型理解知識時,實際效果並不理想。這帶出了為何需要 RAG 技術。
檢索增強生成(Retrieval-Augmented Generation,RAG),第一步就是檢索。使用 RAG 技術從舊數據源中檢索更相關的資訊,然後再傳遞給生成模型。透過用戶查詢從外部知識庫中獲取相關內容,然後將用戶的查詢增強為提示,中間亦可加入一些指令,將其輸入給基礎模型。最後,利用生成模型幫助我們基於增強的提示來總結資訊。
比較各種自訂基礎模型方法的成本與效果
以往檢索資料較常以關鍵字匹配,即是搜尋足球就會找到包含「足球」關鍵字的資訊。但現在有更先進的技術在 RAG 中應用到,稱為語義搜尋。例如有幾個關鍵字:紐約、巴黎、動物和馬。透過嵌入模型 (embedding model),我們會將文字轉換為數字,這串數字稱為向量 (vectors)。紐約和巴黎之間的數字相對較近,而動物和馬之間的數字則相對較遠。這意味著轉換為數字格式實際上可以提供我們的關係。例如輸入足球,我們也可以找到像「世界杯」或「阿根廷」等資訊,獲得更準確的上下文,然後將其傳遞給 RAG 系統。
Amazon Bedrock 知識庫打包大模型與 RAG 架構 省卻企業自行開發時間
AWS 正正提供完全管理解決方案 – Amazon Bedrock 知識庫,為客戶提供端到端的 RAG 直接流程。這意味著這包括一個嵌入模型、向量儲存以及一個生成模型,全部打包在一起。不需要使用不同的組件來逐步構建。
Bedrock KB 兼容性強大。首先,數據來源能與我們的儲存 S3 整合,適合儲存各種文件,如 PDF、DOC 等等。然後,支持不同的 Amazon Titan 嵌入體系,以及其合作夥伴 Cohere。Cohere 同時支持英語和多語言版本。是相當受歡迎的嵌入模型,在 Hugging Face 嵌入模型中名列前茅。它還支持更多儲存方式,比如開源的無伺服器儲存,Postgres SQL 以及Pinecone、Redis 和 MongoDB。重點是這一切都是自動化,全由 Bedrock KB 管理,無需逐步構建。
使用 Bedrock KB 十分方便。基本上,用戶就只需要進行一次檢索和生成的 API 調用並提供問題。你不需要考慮調用哪個嵌入模型、查詢哪個向量儲存,以及使用哪個 LLM。甚至不需要提示工程,只需一次 API 調用,就能獲得答案。
Bedrock KB 調用 API 流程圖
了解更多:按此連結
相關文章:
AWS re:Invent 2024 懶人包重點速覽 AWS AI 戰略大揭密 AWS 企業轉型實錄 客戶體驗管理平台 Sprinklr 挑戰 99.99% 系統可靠性 專家預測 2025 年生成式 AI 趨勢 AI 將從構想走向行動新紀元