今時今日的 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 流程圖
了解更多：按此連結
分享到 :
最新影片
