本文有使用 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） 系統的段落切分是指將長文檔拆分為較小的文本單位（如段落、句子或片段），以便構建檢索知識庫並提高檢索效率和生成準確性。
為什麼需要段落切分？
- 提高檢索精度
- 小單位的文本更易於匹配查詢，提高檢索的相關性。
- 避免返回過長的上下文，降低生成模型的噪聲干擾。
- 降低檢索和存儲成本
- 分割後的片段可以更高效地儲存在向量資料庫中。
- 提升檢索效率，特別是在大規模數據庫中。
- 改善生成模型的上下文利用
- 小片段更便於生成模型理解和組織，提高答案的準確性。
段落切分的策略
- 基於固定長度
- 將文檔按固定的字數、字符數或 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 系統中將用戶的自然語言查詢與知識庫中的數據匹配的關鍵步驟。目的是從海量數據中快速找到與查詢語義最相關的內容，並作為生成模型的輔助上下文。
查詢檢索的工作原理
- 查詢向量化
💡
查詢向量化 和 embedding 的文本向量化 基本上是相同的概念，它們都指的是將文本（無論是用戶查詢還是知識庫中的內容）轉換為數學向量，以便進行語義匹配或其他計算。 - 使用嵌入（embedding）模型將用戶查詢轉換成固定維度的向量，表示查詢的語義。
- 相似度計算
- 將查詢向量與知識庫中每個數據向量進行相似度匹配（例如餘弦相似度）。
- 找到與查詢向量最接近的數據塊（chunks）。
- 檢索結果
- 返回最相關的數據塊作為檢索結果，通常包括排名（ranked results）。
優化查詢向量化的建議
- 微調查詢向量模型：
- 使用查詢和相關文檔配對數據（如 MSMARCO）進行微調，以提升檢索準確性。
- 結合查詢改寫：
- 將用戶查詢進行改寫（reformulation），使其語義更清晰，然後向量化。例如：
- 原查詢：「Weather today」
- 改寫後：「What is the weather like today?」
- 增強查詢上下文：
- 在查詢向量化之前，結合用戶背景信息（如位置或歷史行為）來增強語義表示。
RAG 檢索查詢的典型返回內容
- 數據塊內容（content）
- 元數據（metadata）
- 相似度分數（similarity_score）
- 檢索結果的排序
常見的返回數據塊策略：
- Top-K 返回
- 最常見設定：返回 3 到 5 個數據塊（
Top-3或Top-5）。 - 原因：
- 保持上下文簡潔，避免生成模型處理過長的輸入。
- 確保檢索結果有足夠的多樣性，覆蓋不同的潛在答案來源。
- 最常見設定：返回 3 到 5 個數據塊（
- 單數據塊
- 如果查詢目標明確（如直接問答），可能只返回 1 個數據塊。
- 優勢：
- 減少噪聲，專注於最相關的內容。
- 適用場景：
- FAQ 系統或直接的查詢回答。
- 多數據塊
- 如果查詢複雜，或者需要多方面信息，返回 5 到 10 個數據塊。
- 適用場景：
- 需要全面資訊的生成場景（如摘要生成）。
場景建議數據塊數量原因
RAG 怎麼 Evaluate 效果
評估 RAG（Retrieval-Augmented Generation） 系統的效果是一個多層次的過程，涉及檢索部分（Retrieval）和生成部分（Generation）的各自性能，以及它們的整體協同效果。以下是常用的評估指標和方法：
檢索部分的評估
指標
- 準確率（Precision@K）
- 測量返回的前 K 條檢索結果中，有多少是相關的。
- 適用場景：需要檢索結果的高相關性（如 FAQ 問答）。
- 召回率（Recall@K）
- 測量系統檢索出的相關結果占所有相關結果的比例。
- 適用場景：需要更多全面的上下文支持生成。
- Mean Reciprocal Rank（MRR）
- 衡量檢索結果中第一個相關結果的位置。
- 適用場景：用於排序敏感的場景（如直接問答）。
- NDCG（Normalized Discounted Cumulative Gain）
- 用於評估檢索結果的排序質量，考慮相關性的遞減影響。
- 公式：
- 適用場景：需要對檢索結果進行精細排序評估。
- 檢索時間
- 測量從向量資料庫檢索結果所需的時間。
- 適用場景：對實時性要求高的應用。
生成部分的評估
- BLEU（Bilingual Evaluation Understudy）
- 衡量生成結果與參考答案的重疊程度。
- 適用場景：生成文本短小精煉的場景（如翻譯或短回答）。
- ROUGE（Recall-Oriented Understudy for Gisting Evaluation）
- 衡量生成文本與參考答案的重疊，包括詞語和句子的召回率。
- 適用場景：摘要生成或回答生成。
- METEOR
- 結合語義和詞形變化的評估指標。
- 適用場景：語言靈活性高的文本生成。
- GPT-Score 或 LLMSelfScore
- 使用大語言模型（如 GPT-4）對生成文本的相關性、流暢性和一致性進行打分。
- 適用場景：需要自動化定性評估的生成任務。
- 用戶評分
- 直接請用戶對生成的答案進行主觀評分，衡量滿意度。
- 適用場景：用戶交互類應用。
整體協同效果的評估
指標
- Answer Precision
- 測量最終回答是否正確，對整個檢索與生成流程進行整體評估。
- End-to-End Accuracy
- 衡量生成答案與目標答案的完全匹配度。
- 適用場景：需要準確答案的應用（如法規問答）。
- Contextual Appropriateness
- 檢測生成答案是否利用了檢索上下文中的正確信息。
- 適用場景：需要上下文一致性的應用。
- Human Evaluation
- 人工檢查生成結果的相關性、準確性和易讀性。
- 適用場景：無法完全依賴自動評估的高價值場景。
LLM as a Judge
是一種利用大語言模型（LLM，例如 GPT-4）作為自動化評估工具的方法，用於對生成結果的質量進行判斷。這種方法通常被用於文本生成系統（如 RAG 系統、對話系統或摘要生成）中，對輸出進行客觀評估，避免完全依賴人工或傳統的自動指標（如 BLEU、ROUGE）。
LLM as a Judge 最常應用於：
- 生成部分的評估（生成文本的質量評估，是 LLM 的最佳應用場景）。
- 整體協同效果的評估（特別是 Answer Precision 和 Contextual Appropriateness）。
評估流程與工具
流程
- 定義基準數據集
- 包括查詢、期望答案、以及相關的數據塊。
- 範例：MS MARCO（問答檢索數據集）。
- 測試檢索
- 使用向量資料庫（如 Pinecone 或 FAISS）檢索 Top-K 數據塊，計算檢索相關性。
- 生成測試
- 基於檢索結果生成答案，並與期望答案對比。
- 整體評估
- 同時考慮檢索與生成的協同效果，特別是答案的完整性與準確性。
評估工具
- IR 評估工具
- Pytrec_eval：用於檢索相關性評估。
- faiss.eval：內建的 FAISS 檢索評估工具。
- 生成文本評估工具
- NLTK：計算 BLEU 和 METEOR。
- ROUGE：專用於摘要和回答生成。
- 自動化框架
- 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 在真實使用場景中收集數據，更能反映系統的實際表現。
