一篇文章帶你認識 RAG，由淺入深

Patrick Tomasso on Unsplash

本文有使用 AI 協助編輯

RAG 系統的概念

RAG 是「Retrieval-Augmented Generation」的縮寫，是一種結合檢索（Retrieval）與生成（Generation）的 AI 技術方法，常用於提高語言模型回答問題的準確性和相關性。

RAG 的基本概念

RAG 方法將兩個主要的功能結合在一起：

• 檢索（Retrieval）：
• • 從外部知識庫（例如文件庫、網頁、數據庫）中檢索相關信息。
  • 常用的檢索工具包括向量搜索引擎（如 FAISS）或基於關鍵字的搜索技術。
  • 檢索的目的是為語言模型提供上下文，讓其在回答問題時能參考最新或相關的內容。
• 生成（Generation）：
• • 使用大型語言模型（如 GPT-3.5 或 GPT-4）來基於檢索到的內容生成回答。
  • 語言模型不僅是簡單的回答，還能將檢索到的片段組織成連貫的語句，甚至進行進一步推理。

RAG 的應用場景

• 問答系統（QA System）： 提供基於實際文檔或數據的準確回答。
• 知識管理： 幫助公司內部員工快速查找相關文件並生成答案。
• 教育與學習： 提供對教材或學術資料的精準解釋。
• 客戶支持： 利用內部知識庫自動生成客戶問題的答案。

RAG 的優勢

• 準確性高： 相比僅依賴生成模型，RAG 的檢索階段能有效減少模型生成「幻覺」（hallucination）的機率。
• 知識更新： 模型本身的知識可能是靜態的，但透過檢索能隨時引用最新的外部信息。
• 可控性高： 檢索過程可以控制數據來源，確保信息可信。

RAG 的技術流程

• 用戶輸入問題或查詢。
• 檢索模塊（Retriever）： 根據查詢從外部資料中找到最相關的內容。
• 生成模塊（Generator）： 使用語言模型，將檢索到的內容和原始查詢結合，生成回答。
• 輸出回答給用戶。

工具與框架

常用的 RAG 實現工具包括：

• FAISS：高效的向量搜索引擎。
• LangChain：結合檢索與生成的框架，適合快速構建 RAG 系統。
• OpenAI API：與 GPT-模型結合的生成部分。
• Pinecone、Weaviate、Qdrant：向量數據庫，用於存儲和檢索嵌入。
• • https://github.com/qdrant/qdrant （法國團隊使用）
• LangSmith: 性能監測
  

但這樣就只是 make sense

如果你今天要去實作 RAG、活用 RAG，歡迎閱讀以下部分

會從每一個元件下去拆解和剖析 RAG

RAG 深度研究

RAG（Retrieval-Augmented Generation） 系統的段落切分是指將長文檔拆分為較小的文本單位（如段落、句子或片段），以便構建檢索知識庫並提高檢索效率和生成準確性。

為什麼需要段落切分？

1. 提高檢索精度
2. • 小單位的文本更易於匹配查詢，提高檢索的相關性。
   • 避免返回過長的上下文，降低生成模型的噪聲干擾。
2. 降低檢索和存儲成本
3. • 分割後的片段可以更高效地儲存在向量資料庫中。
   • 提升檢索效率，特別是在大規模數據庫中。
3. 改善生成模型的上下文利用
4. • 小片段更便於生成模型理解和組織，提高答案的準確性。

段落切分的策略

• 基於固定長度
• • 將文檔按固定的字數、字符數或 token 數進行切分。
  • 適用場景：
  • • 文本結構不明確（如新聞摘要、大段描述）。
  • 範例：
  • • 每 200 個詞（或 500 個字符）切分為一個片段。
• 基於自然段落
• • 按文本的自然段（段落標記或空行）進行切分。
  • 適用場景：
  • • 文本有明確的段落結構（如論文、報告）。
• 基於語句（Sentence Splitting）
  切分為兩個句子：

    ```
    "Paris is the capital of France. It is famous for the Eiffel Tower."
    
    ```
    
    - "Paris is the capital of France."
    - "It is famous for the Eiffel Tower."
  

• • 按句號、問號或其他標點符號分句。
  • 適用場景：
  • • 查詢通常針對具體細節，需返回更精確的語句。
  • 範例：
• 基於語義單元
• • 使用語義分析或模型分割文本，按主題或上下文切分。
  • 適用場景：
  • • 需要保留語義完整性，避免將相關內容分割到不同片段。
  • 實現方法：
  • • 使用 NLP 模型（如 Hugging Face 的 transformers）或分詞工具分析語義邊界。

段落切分的實踐步驟

• 選擇切分單位
• • 根據應用需求確定使用固定長度、自然段落或語義單元。
• 確定切分粒度
• • 過小：可能導致檢索不完整，生成模型缺乏上下文。
  • 過大：可能引入過多噪聲，影響檢索和生成的準確性。
• 維護邊界完整性
• • 切分時需保證片段是語義完整的，避免割裂核心信息。
  • 方法：
  • • 使用滑動窗口（Sliding Window），保留部分上下文重疊。
    • 範例：前後 50 個詞的重疊。

段落切分的場景建議

應用場景切分策略粒度建議

Embedding (嵌入)

embedding 是一個關鍵的概念，用來將非結構化的資料（例如文字）轉換成數學向量的形式，以便進行高效的檢索與推理

Embedding 的定義

Embedding 是一種向量化表示法，將文字（或其他類型的資料）壓縮到一個固定維度的向量空間中，保留其語義資訊。這些向量可以被視為語意的數值化表示，用於計算相似性或進行檢索。

Embedding 在 RAG 的角色

在 RAG 的流程中，embedding 主要用於兩個關鍵部分：

(1) 資料檢索階段

• RAG 需要從大型知識庫中檢索相關資料。
• 為了快速找到相關內容，首先需要將知識庫中的所有文字片段轉換成 embedding。
• 查詢（query）也會被轉換成 embedding，然後與知識庫的 embedding 進行相似度匹配（例如通過餘弦相似度或點積計算）。

(2) 生成階段的上下文構建

• 檢索到的相關資料會與原始查詢結合，作為生成模型（如 GPT）的上下文輸入。
• 高質量的 embedding 能確保檢索結果的相關性，提高生成答案的準確性。

Embedding 的生成方式

RAG 的 embedding 通常是通過深度學習模型生成的，以下是常用的方法：

(1) 預訓練模型

使用自然語言處理（NLP）模型，如 BERT、RoBERTa 或 Sentence Transformers，這些模型經過語言數據的大規模預訓練，能夠生成高質量的語義向量。

(2) 專用模型

若資料具有領域特定性，可以微調預訓練模型，使 embedding 更適合該領域。

Embedding 模型

生成 embedding 的常用模型，按用途分類：

1. 通用型預訓練模型

• BERT（Bidirectional Encoder Representations from Transformers）
• • 特點：擅長處理句子層級語義，適合生成句子或單詞的嵌入。
  • 用途：通用語義檢索、文本分類。
  • 工具：Hugging Face 的 bert-base-uncased。
• RoBERTa
• • 特點：BERT 的改進版，針對更大數據集和訓練調參，效果更佳。
  • 用途：更準確的語義匹配。
  • 工具：Hugging Face 的 roberta-base。
• DistilBERT
• • 特點：BERT 的輕量版本，適合需要速度與效率的場景。
  • 用途：邊緣設備或高效檢索。
• Sentence Transformers
• • 特點：專為生成句子嵌入設計，基於 BERT/RoBERTa，能直接用於語義相似度計算。
  • 用途：檢索與排序（如信息檢索、問答系統）。
  • 工具：sentence-transformers 庫。

2. 專用型語義模型

• OpenAI Embeddings（例如 text-embedding-ada-002）
• • 特點：針對語義向量生成的高效服務，適用於多種任務。
  • 用途：高質量的向量檢索、知識庫增強、RAG 系統。
• Universal Sentence Encoder (USE)
• • 特點：由 Google 提供，速度快，適用於短文本和長文本嵌入。
  • 用途：對話系統、信息檢索。

3. 多語言模型

• mBERT（多語言 BERT）
• • 特點：支持多語言文本嵌入，適合處理多語言資料。
  • 用途：跨語言檢索與生成。
• LaBSE (Language-agnostic BERT Sentence Embedding)
• • 特點：適合多語言場景，專為生成高質量句子嵌入設計。
  • 用途：多語言語義檢索。

4. 特定領域模型

• BioBERT
• • 特點：針對生物醫學語料微調的 BERT。
  • 用途：醫療數據檢索、問答。
• SciBERT
• • 特點：適用於科學文獻。
  • 用途：研究資料檢索、摘要。

模型精度速度支持語言大小適用場景

如何選擇用什麼 Embedding 模型

• 明確應用場景，針對場景選擇
• 評估需求條件
• • 模型精度 vs 速度
  • • 高精度（例如長文章、關鍵性檢索）：使用大模型（如 RoBERTa 或 openai-text-embedding-ada-002）。
    • 高速度（例如大量用戶請求）：使用輕量模型（如 MiniLM）。
  • 預算
  • • 有預算：使用商業化 API，如 OpenAI 的 text-embedding-ada-002。
    • 無預算：選擇開源模型，如 Hugging Face 的 Sentence Transformers。

💡

“精度”的具體含義

• 語義匹配能力：
• • 當兩個文本語義接近時，模型生成的向量應該在嵌入空間中彼此接近（例如餘弦相似度高）。
  • 精度高的模型能更準確地表示文本語義，適合高相關性的檢索或排序任務。
• 區分能力：
• • 精度高的模型能有效地區分語義相似與不相似的文本。
  • 例如，"台北的天氣如何？" 與 "台北的交通如何？" 在嵌入空間中應有較大距離。

查詢檢索（Query Retrieval）

查詢檢索是 RAG 系統中將用戶的自然語言查詢與知識庫中的數據匹配的關鍵步驟。目的是從海量數據中快速找到與查詢語義最相關的內容，並作為生成模型的輔助上下文。

查詢檢索的工作原理

1. 查詢向量化
   💡
   查詢向量化 和 embedding 的文本向量化 基本上是相同的概念，它們都指的是將文本（無論是用戶查詢還是知識庫中的內容）轉換為數學向量，以便進行語義匹配或其他計算。
   
2. • 使用嵌入（embedding）模型將用戶查詢轉換成固定維度的向量，表示查詢的語義。
2. 相似度計算
3. • 將查詢向量與知識庫中每個數據向量進行相似度匹配（例如餘弦相似度）。
   • 找到與查詢向量最接近的數據塊（chunks）。
3. 檢索結果
4. • 返回最相關的數據塊作為檢索結果，通常包括排名（ranked results）。

優化查詢向量化的建議

1. 微調查詢向量模型：
2. • 使用查詢和相關文檔配對數據（如 MSMARCO）進行微調，以提升檢索準確性。
2. 結合查詢改寫：
3. • 將用戶查詢進行改寫（reformulation），使其語義更清晰，然後向量化。例如：
   • • 原查詢：「Weather today」
     • 改寫後：「What is the weather like today?」
3. 增強查詢上下文：
4. • 在查詢向量化之前，結合用戶背景信息（如位置或歷史行為）來增強語義表示。

RAG 檢索查詢的典型返回內容

• 數據塊內容（content）
• 元數據（metadata）
• 相似度分數（similarity_score）
• 檢索結果的排序

常見的返回數據塊策略：

1. Top-K 返回
2. • 最常見設定：返回 3 到 5 個數據塊（Top-3 或 Top-5）。
   • 原因：
   • • 保持上下文簡潔，避免生成模型處理過長的輸入。
     • 確保檢索結果有足夠的多樣性，覆蓋不同的潛在答案來源。
2. 單數據塊
3. • 如果查詢目標明確（如直接問答），可能只返回 1 個數據塊。
   • 優勢：
   • • 減少噪聲，專注於最相關的內容。
   • 適用場景：
   • • FAQ 系統或直接的查詢回答。
3. 多數據塊
4. • 如果查詢複雜，或者需要多方面信息，返回 5 到 10 個數據塊。
   • 適用場景：
   • • 需要全面資訊的生成場景（如摘要生成）。

場景建議數據塊數量原因

RAG 怎麼 Evaluate 效果

評估 RAG（Retrieval-Augmented Generation） 系統的效果是一個多層次的過程，涉及檢索部分（Retrieval）和生成部分（Generation）的各自性能，以及它們的整體協同效果。以下是常用的評估指標和方法：

檢索部分的評估

指標

1. 準確率（Precision@K）
2. • 測量返回的前 K 條檢索結果中，有多少是相關的。
   • 適用場景：需要檢索結果的高相關性（如 FAQ 問答）。
2. 召回率（Recall@K）
3. • 測量系統檢索出的相關結果占所有相關結果的比例。
   • 適用場景：需要更多全面的上下文支持生成。
3. Mean Reciprocal Rank（MRR）
4. • 衡量檢索結果中第一個相關結果的位置。
   • 適用場景：用於排序敏感的場景（如直接問答）。
4. NDCG（Normalized Discounted Cumulative Gain）
5. • 用於評估檢索結果的排序質量，考慮相關性的遞減影響。
   • 公式：
   • 適用場景：需要對檢索結果進行精細排序評估。
5. 檢索時間
6. • 測量從向量資料庫檢索結果所需的時間。
   • 適用場景：對實時性要求高的應用。

生成部分的評估

1. BLEU（Bilingual Evaluation Understudy）
2. • 衡量生成結果與參考答案的重疊程度。
   • 適用場景：生成文本短小精煉的場景（如翻譯或短回答）。
2. ROUGE（Recall-Oriented Understudy for Gisting Evaluation）
3. • 衡量生成文本與參考答案的重疊，包括詞語和句子的召回率。
   • 適用場景：摘要生成或回答生成。
3. METEOR
4. • 結合語義和詞形變化的評估指標。
   • 適用場景：語言靈活性高的文本生成。
4. GPT-Score 或 LLMSelfScore
5. • 使用大語言模型（如 GPT-4）對生成文本的相關性、流暢性和一致性進行打分。
   • 適用場景：需要自動化定性評估的生成任務。
5. 用戶評分
6. • 直接請用戶對生成的答案進行主觀評分，衡量滿意度。
   • 適用場景：用戶交互類應用。

整體協同效果的評估

指標

1. Answer Precision
2. • 測量最終回答是否正確，對整個檢索與生成流程進行整體評估。
2. End-to-End Accuracy
3. • 衡量生成答案與目標答案的完全匹配度。
   • 適用場景：需要準確答案的應用（如法規問答）。
3. Contextual Appropriateness
4. • 檢測生成答案是否利用了檢索上下文中的正確信息。
   • 適用場景：需要上下文一致性的應用。
4. Human Evaluation
5. • 人工檢查生成結果的相關性、準確性和易讀性。
   • 適用場景：無法完全依賴自動評估的高價值場景。

LLM as a Judge

是一種利用大語言模型（LLM，例如 GPT-4）作為自動化評估工具的方法，用於對生成結果的質量進行判斷。這種方法通常被用於文本生成系統（如 RAG 系統、對話系統或摘要生成）中，對輸出進行客觀評估，避免完全依賴人工或傳統的自動指標（如 BLEU、ROUGE）。

LLM as a Judge 最常應用於：

1. 生成部分的評估（生成文本的質量評估，是 LLM 的最佳應用場景）。
2. 整體協同效果的評估（特別是 Answer Precision 和 Contextual Appropriateness）。

評估流程與工具

流程

1. 定義基準數據集
2. • 包括查詢、期望答案、以及相關的數據塊。
   • 範例：MS MARCO（問答檢索數據集）。
2. 測試檢索
3. • 使用向量資料庫（如 Pinecone 或 FAISS）檢索 Top-K 數據塊，計算檢索相關性。
3. 生成測試
4. • 基於檢索結果生成答案，並與期望答案對比。
4. 整體評估
5. • 同時考慮檢索與生成的協同效果，特別是答案的完整性與準確性。

評估工具

1. IR 評估工具
2. • Pytrec_eval：用於檢索相關性評估。
   • faiss.eval：內建的 FAISS 檢索評估工具。
2. 生成文本評估工具
3. • NLTK：計算 BLEU 和 METEOR。
   • ROUGE：專用於摘要和回答生成。
3. 自動化框架
4. • LangChain Evaluation：支持 RAG 系統中檢索與生成的整合評估。
   • Hugging Face：用於檢索與生成模型的性能測試。

如何設計 RAG 的評估框架

評估階段指標評估方法工具

RAG A/B testing

A/B Testing 在 RAG 中可以做到

• 用戶體驗導向的系統
• • RAG 系統的最終目標通常是滿足用戶需求，A/B Testing 是直接測量用戶反應的有效方式。
• 比較多個版本的效果
• • RAG 系統的檢索和生成部分都可以有多種實現方式，A/B Testing 可以用來比較不同版本（如不同檢索策略或生成模型）的性能。
• 實際應用中的評估
• • 相較於實驗室中的人工或自動化評估，A/B Testing 在真實使用場景中收集數據，更能反映系統的實際表現。