在人工智能（AI）領域，長上下文生成與檢索（RAG） 已成為提升自然語言處理（NLP）模型性能的關鍵技術之一。隨著數(shù)據(jù)規(guī)模與應用場景的不斷擴展，如何高效地處理海量上下文信息，成為研究與應用的熱點話題。本文將深入探討OpenAI最新發(fā)布的O1-preview和O1-mini模型在長上下文RAG任務中的表現(xiàn)，比較其與行業(yè)內其他SOTA（State-of-the-Art）模型如GPT-4o和Google Gemini 1.5的性能差異，并提供實用的優(yōu)化建議，助力開發(fā)者在構建LLM（大型語言模型）應用時實現(xiàn)更高效、更精準的性能表現(xiàn)。

引言：長上下文RAG的重要性

在現(xiàn)代AI應用中，大型語言模型（LLM） 已廣泛應用于文本生成、問答系統(tǒng)、內容總結等多個領域。然而，隨著應用場景的復雜性和數(shù)據(jù)量的急劇增加，傳統(tǒng)的短上下文處理能力已難以滿足需求。長上下文RAG（Retrieve and Generate） 技術通過在生成過程中引入檢索機制，使模型能夠處理更大規(guī)模的上下文信息，從而顯著提升了回答的準確性與相關性。

【CodeMoss】集成13個種AI模型（GPT4、o1等）、支持Open API調用、自定義助手、文件上傳等強大功能，助您提升工作效率！ >>> - CodeMoss & ChatGPT-AI中文版

>>> https://pc.aihao123.cn/index.html#/page/login?invite=1141439&fromChannel=CodeMoss_1212RAG

OpenAI O1模型概述

OpenAI的O1模型 是最新發(fā)布的SOTA模型之一，分為O1-preview 和O1-mini 兩個版本。O1模型在2023年10月發(fā)布后，憑借其卓越的長上下文處理能力，迅速在行業(yè)內嶄露頭角。與之前的GPT-4o模型相比，O1模型在多個長上下文RAG基準測試中表現(xiàn)更為出色，尤其是在處理超過百萬級詞元的超長文本時展現(xiàn)出了顯著優(yōu)勢。

O1-mini 版本在性能上幾乎與GPT-4o持平，而O1-preview 則在一些特定任務中超越了GPT-4o，顯示出其強大的泛化能力和適應性。這兩款模型不僅在標準數(shù)據(jù)集上的表現(xiàn)優(yōu)異，還在諸如Databricks DocsQA和FinanceBench等內部數(shù)據(jù)集上展現(xiàn)了卓越的性能。

O1模型在長上下文RAG基準測試中的表現(xiàn)

為了全面評估O1模型在長上下文RAG任務中的性能，我們將其在多個數(shù)據(jù)集上的表現(xiàn)進行詳盡分析，包括Databricks DocsQA、FinanceBench 和 **Natural Questions (NQ)**。

在Databricks DocsQA數(shù)據(jù)集上的表現(xiàn)

Databricks DocsQA 是一個內部數(shù)據(jù)集，專注于文檔問答任務，涵蓋了技術文檔的復雜結構與多樣化內容。在此數(shù)據(jù)集上，O1-preview和O1-mini模型在所有上下文長度下的表現(xiàn)顯著優(yōu)于GPT-4o和Google Gemini模型。具體而言：

• O1-preview模型在2k至200萬詞元的上下文長度范圍內，回答的正確性和相關性均穩(wěn)步提升，尤其在長上下文下表現(xiàn)尤為突出。
• O1-mini版本在處理超長上下文時，準確率接近GPT-4o，但在某些任務中超越了GPT-4o，顯示出其高效的上下文處理能力。

圖2.1展示了不同模型在Databricks DocsQA數(shù)據(jù)集上的RAG性能對比，可以明顯看出O1模型的優(yōu)勢。

在FinanceBench數(shù)據(jù)集上的表現(xiàn)

FinanceBench 數(shù)據(jù)集專注于金融領域的問答任務，涉及大量專業(yè)術語與復雜的金融邏輯。在此數(shù)據(jù)集上，O1模型同樣表現(xiàn)優(yōu)異：

• O1-preview和O1-mini在所有上下文長度下，尤其是在8k及以上，準確率均顯著高于GPT-4o和Gemini模型。
• 尤其是在16k甚至更長的上下文長度下，O1模型能夠保持較高的回答質量，展示出其在處理金融數(shù)據(jù)復雜性方面的優(yōu)勢。

圖2.2展示了O1模型在FinanceBench數(shù)據(jù)集上的長上下文RAG性能，進一步驗證了其卓越表現(xiàn)。

在Natural Questions (NQ)數(shù)據(jù)集上的表現(xiàn)

Natural Questions (NQ) 是一個標準的學術基準測試數(shù)據(jù)集，涵蓋了廣泛的常識性問題。在NQ數(shù)據(jù)集上，O1模型的表現(xiàn)總體優(yōu)異，但在短上下文長度（2k詞元）下存在一定的性能下降：

• 在短篇幅上下文中，如果檢索到的文檔中信息不足，O1模型傾向于回答“信息不可用”，而無法基于自身知識進行補充回答。
• 盡管如此，在更長的上下文環(huán)境下，O1模型依然保持了較高的回答正確性，接近甚至超越了GPT-4o。

這種在短上下文下的性能下降主要源于檢索文檔的相關性不足，導致模型無法充分發(fā)揮其生成能力。

與Google Gemini 1.5模型的對比

Google Gemini 1.5 模型是目前市場上另一款領先的長上下文RAG模型，擁有Pro 和Flash 兩個版本。在多個基準測試中，Gemini 1.5展示出了其獨特的優(yōu)勢，尤其是在處理超長上下文時的穩(wěn)定性。

Gemini 1.5在超長上下文下的穩(wěn)定性

盡管在128k詞元以下的整體答案正確性低于O1和GPT-4o模型，Gemini 1.5 在處理高達200萬詞元的超長上下文時，表現(xiàn)出了驚人的穩(wěn)定性。具體表現(xiàn)如下：

• 一致性：在超長上下文下，Gemini 1.5模型能維持一致的回答質量，而不會像其他模型那樣在上下文長度增加時出現(xiàn)性能波動。
• 資源優(yōu)化：盡管處理超長文本可能帶來較高的計算成本，Gemini 1.5通過優(yōu)化算法，有效控制了資源消耗，使其在長文檔處理上具有成本效益。

圖2.1展示了Gemini 1.5在NQ數(shù)據(jù)集上的長上下文RAG性能，顯示其在大規(guī)模文本處理中依然能夠保持高水平的回答正確性。

成本與開發(fā)便捷性的權衡

對于開發(fā)者而言，選擇合適的模型不僅要考慮性能，還需權衡成本與開發(fā)便捷性。Gemini 1.5在長上下文處理上的優(yōu)勢意味著在某些應用場景下，可以跳過傳統(tǒng)的檢索步驟，直接將整個數(shù)據(jù)集輸入模型進行處理。然而，這種做法可能帶來較高的計算成本與資源消耗，但為開發(fā)人員提供了更簡化的開發(fā)體驗，適合對開發(fā)效率有較高要求的項目。

通過對比分析，我們可以得出：

• O1模型在中短上下文下表現(xiàn)優(yōu)異，適合需要高準確性和相關性的應用場景。
• Gemini 1.5則更適合處理超長上下文且對成本有一定容忍度的項目，提供了一種簡化的RAG工作流方案。

LLM在長上下文RAG中的失敗模式分析

盡管大型語言模型在長上下文RAG任務中展現(xiàn)了強大的能力，但在實際應用中，仍然存在多種失敗模式。理解這些失敗模式有助于開發(fā)者在構建應用時采取相應的優(yōu)化措施，提升系統(tǒng)的整體性能與穩(wěn)定性。

OpenAI O1-preview與O1-mini的失敗模式

在對O1模型的失敗案例進行分析時，我們發(fā)現(xiàn)其主要失誤類別包括：

1. 重復內容（repeated_content）：模型生成回答時出現(xiàn)重復的無意義詞組或字符，影響回答的可讀性與信息量。
2. 隨機內容（random_content）：生成的回答與上下文內容無關，缺乏邏輯性和語法合理性。
3. 未遵循指令（fail_follow_inst）：未按照問題要求生成回答，如在要求基于上下文回答時，模型嘗試進行總結。
4. 空響應（empty_resp）：模型未生成任何回答，返回空字符串。
5. 錯誤答案（wrong_answer）：盡管遵循了指令，模型提供了錯誤的答案。
6. 拒絕回答（refusal）：模型因不確定性或其他原因拒絕回答問題。
7. 因API過濾導致的任務失敗：由于安全過濾規(guī)則，模型未生成回答。

O1-preview 和O1-mini 在處理不同上下文長度時，特別是在推理步驟的詞元長度不可預測時，可能會因上下文過長而返回空響應。此外，在NQ數(shù)據(jù)集中，短上下文下的性能下降表現(xiàn)為模型簡單地回答“信息不可用”，即便在一些情況下存在支持回答的oracle文檔，模型仍未能提供正確答案。

下面兩個圖分別展示了O1-preview在Databricks DocsQA和NQ數(shù)據(jù)集上的失敗分析，可以看出不同數(shù)據(jù)集和上下文長度對模型表現(xiàn)的影響。

Google Gemini 1.5 Pro與Flash的失敗模式

Gemini 1.5 模型的失敗模式分析顯示，其主要問題在于：

1. 主題敏感性：生成API對提示內容的主題高度敏感，尤其在NQ基準測試中，由于提示內容被過濾，導致了大量任務失敗。
2. 拒絕回答：在FinanceBench數(shù)據(jù)集中，模型經(jīng)常因為檢索不到相關信息而拒絕回答，尤其在短上下文（2k詞元）下，96.2%的“拒絕”情況發(fā)生在缺失oracle文檔時。
3. BlockedPromptException錯誤：由于提示內容被API過濾，導致生成任務失敗，這類錯誤在NQ基準測試中較為普遍。

圖3.3至圖3.5展示了Gemini 1.5 Pro在不同數(shù)據(jù)集上的失敗模式分布，可以明顯看出在不同上下文長度和數(shù)據(jù)集環(huán)境下，模型表現(xiàn)出的特有問題。

優(yōu)化長上下文RAG性能的策略

針對上述模型的表現(xiàn)與失敗模式，開發(fā)者可以采取以下策略優(yōu)化長上下文RAG的性能，提升應用的整體效果。

選擇合適的模型與上下文長度

根據(jù)具體應用需求選擇最合適的模型與上下文長度，是提升RAG性能的第一步。

• 中短上下文應用：對于需要高準確性和相關性的應用，如技術文檔問答、金融報告分析，推薦使用OpenAI O1-preview或O1-mini，在2k至16k詞元的上下文長度下表現(xiàn)優(yōu)異。
• 超長上下文應用：對于需要處理超過200萬詞元的超長文本，如大型文檔解析、綜合報告生成，Google Gemini 1.5是更合適的選擇，其在超長上下文下保持了相對穩(wěn)定的性能。

改進檢索步驟以提升性能

檢索步驟在RAG流程中扮演著至關重要的角色，改進檢索算法和策略，可以有效提升模型的回答質量。

• 增強檢索相關性：通過優(yōu)化檢索算法，確保檢索到的文檔與問題高度相關，減少模型生成隨機或錯誤回答的概率。
• 動態(tài)上下文調整：根據(jù)問題的復雜性和上下文的相關性，動態(tài)調整輸入的上下文長度，確保模型在不同任務中都能獲得足夠的信息支持。

處理模型的失敗模式

針對模型在不同場景下的失敗模式，采取相應的預防和修正措施，能夠顯著提高系統(tǒng)的穩(wěn)定性和用戶體驗。

• 內容過濾與指令優(yōu)化：在設計提示內容時，避免觸發(fā)模型的拒絕回答機制，采用更加明確和具體的指令，減少因安全過濾導致的任務失敗。
• 多模型協(xié)同：結合多種模型的優(yōu)勢，采用多模型協(xié)同策略，如在短上下文下優(yōu)先使用O1模型，在超長上下文下切換至Gemini模型，最大化每種模型的優(yōu)點。
• 錯誤監(jiān)控與反饋機制：建立完善的錯誤監(jiān)控系統(tǒng)，實時檢測并記錄模型的失敗情況，采用反饋機制不斷優(yōu)化提示內容和模型選擇策略。

結論：未來的發(fā)展與展望

隨著AI技術的不斷進步，長上下文RAG在各種應用場景中的重要性日益凸顯。OpenAI O1模型 的發(fā)布，展示了其在處理長上下文任務上的強大能力，超越了之前的GPT-4o模型，為行業(yè)樹立了新的標桿。同時，Google Gemini 1.5 在超長上下文處理上的獨特優(yōu)勢，也為開發(fā)者提供了更多選擇，特別是在需要處理海量文本數(shù)據(jù)的應用中，Gemini 1.5 的優(yōu)勢尤為明顯。

RAG作為一種減少模型幻覺（Model Hallucination）并提升模型在私域知識分析與回答能力的高效方法，受到了廣泛關注。然而，RAG的成功實施依賴于知識召回的準確性，這直接影響到大語言模型（LLM）的表現(xiàn)。那么，RAG究竟是如何工作的？在實現(xiàn)過程中，哪些技術手段能夠確保知識召回的精準性？本文將帶你深入了解這些問題，尤其是混合檢索技術在其中扮演的關鍵角色。

單一檢索的局限性：為何僅靠關鍵詞檢索不夠？

在眾多檢索方法中，關鍵詞檢索無疑是最常用的一種。它通過匹配用戶輸入的關鍵詞與文檔中的關鍵詞來返回相關結果。然而，關鍵詞檢索存在明顯的局限性，這些問題在實際應用中往往難以忽視。

語義缺失：詞語之間的深層聯(lián)系被忽略

關鍵詞檢索的最大缺陷之一就是無法理解詞語之間的語義關系。舉個例子，當用戶搜索“狗”時，系統(tǒng)可能無法識別“犬”與“狗”是同義詞，導致相關文檔被遺漏。這種語義上的缺失，使得關鍵詞檢索在處理同義詞或近義詞時表現(xiàn)不佳。

多義詞問題：一詞多義帶來的困擾

另一個常見問題是多義詞的處理。例如，“蘋果”既可以指水果，也可以指科技公司。如果用戶搜索“蘋果”，系統(tǒng)無法確定用戶的具體意圖，從而可能返回不相關的結果。這種情況下，關鍵詞檢索的效果大打折扣。

實例分析：單一檢索的不足

讓我們通過一個具體的例子來更好地理解單一檢索的局限性。假設我們有以下代碼，通過關鍵詞匹配在兩個文本中尋找最相關的內容：

def main():
    """
    主函數(shù)，用于測試和演示
    """
    text1 = '把商品發(fā)到商鋪'
    text2 = '我想將商品掛到商鋪'
    text3 = '我想找商鋪問下商品'

    # calculate_tfidf_similarity: 通過兩個文本TF-IDF相似度計算相似度
    tfidf_similarities2 = calculate_tfidf_similarity(text1, text2)
    tfidf_similarities3 = calculate_tfidf_similarity(text1, text3)

    print(f"\n匹配句子1得分:{tfidf_similarities2[0]} \n\n匹配句子2得分: {tfidf_similarities3[0]} \n\n")

運行結果如下：

匹配句子1得分:0.8164965809277259 

匹配句子2得分:0.8164965809277259

可以看到，盡管text1與text2在語義上更為匹配，但由于關鍵詞“商品”和“閑魚”在三個句子中均有出現(xiàn)，導致兩個句子的得分相同。這說明，單純依賴關鍵詞匹配，無法有效區(qū)分哪些文檔更符合用戶需求。

混合檢索：打破單一檢索的束縛

為了克服單一檢索的局限性，混合檢索應運而生?；旌蠙z索（Hybrid Retrieval）結合了多種檢索方法的優(yōu)勢，旨在提升檢索結果的質量和多樣性。通過將關鍵詞檢索與語義檢索相結合，混合檢索能夠更精準地滿足用戶需求，提供更全面的檢索結果。

什么是混合檢索？

混合檢索是一種綜合運用多種檢索技術的策略。它不僅依賴于傳統(tǒng)的關鍵詞匹配，還結合了語義理解和上下文分析等先進技術。通過這種方式，混合檢索能夠在保持關鍵詞檢索高效性的同時，彌補其在語義理解上的不足，從而實現(xiàn)更高的召回準確性。

實現(xiàn)混合檢索的步驟

接下來，我們將通過代碼示例，詳細拆解混合檢索的實現(xiàn)過程。

def main():
    """
    主函數(shù)，用于測試和演示
    """
    text1 = '把商品發(fā)到商鋪'
    text2 = '我想將商品掛到商鋪'
    text3 = '我想找商鋪問下商品'

    # 通過兩個文本TF-IDF相似度計算相似度
    tfidf_similarities2 = calculate_tfidf_similarity(text1, text2)
    tfidf_similarities3 = calculate_tfidf_similarity(text1, text3)

    # 通過兩個文本的嵌入相似度計算相似度
    embedding_similarities2 = calculate_similarity(text1, text2)
    embedding_similarities3 = calculate_similarity(text1, text3) 

    print(f"\n\n語義搜索句子1 {embedding_similarities2[0]} \n\n語義搜索句子2: {embedding_similarities3[0]}")

運行結果：

語義搜索句子1 ('我想將商品掛到閑魚', 0.8553742925917707) 

語義搜索句子2: ('我想找閑魚問下商品', 0.6846143988983046)

從結果中可以看出，語義檢索在區(qū)分句子相關性方面表現(xiàn)出色，能夠更準確地識別出與用戶需求更為契合的句子。

加權計算

為了進一步提升檢索的準確性，我們可以將關鍵詞檢索和語義檢索的得分進行加權計算。這樣，用戶可以根據(jù)自身需求，調整關鍵詞檢索與語義檢索的權重，從而獲得最優(yōu)的檢索結果。

def main():
    """
    主函數(shù)，用于測試和演示
    """
    text1 = '把商品發(fā)到商鋪'
    text2 = '我想將商品掛到商鋪'
    text3 = '我想找商鋪問下商品'

    # 通過兩個文本TF-IDF相似度計算相似度
    tfidf_similarities2 = calculate_tfidf_similarity(text1, text2)
    tfidf_similarities3 = calculate_tfidf_similarity(text1, text3)

    embedding_similarities2 = calculate_similarity(text1, text2)
    embedding_similarities3 = calculate_similarity(text1, text3) 
    
    Semantic_Proportio = 0.8
    Word_Proportion = 0.2

    # 根據(jù)傳進來的權重計算最終得分
    final_score2 = calculate_final_score(embedding_similarities2[0][1], tfidf_similarities2[0], Semantic_Proportio, Word_Proportion)
    final_score3 = calculate_final_score(embedding_similarities3[0][1], tfidf_similarities3[0], Semantic_Proportio, Word_Proportion)

    print(f"最終語句1得分: {final_score2} \n\n最終語句2得分: {final_score3}")

運行結果：

最終語句1得分: 0.8475987502589617 

最終語句2得分: 0.7109908353041888

通過混合檢索，系統(tǒng)能夠更精準地識別出最符合用戶需求的句子，大幅提升了檢索結果的質量和準確性。

完整代碼展示

為了幫助大家更好地理解混合檢索的實現(xiàn)，以下是完整的代碼示例。請注意，運行代碼前需將??dashscope??的API key替換為你自己的有效key。

import dashscope
from http import HTTPStatus
import numpy as np
import jieba
from jieba.analyse import extract_tags
import math

# 初始化dashscope，替換qwen的api key
dashscope.api_key = 'sk-xxxx'

def embed_text(text):
    """
    使用dashscope API獲取文本的嵌入向量
    :param text: 輸入的文本
    :return: 文本的嵌入向量，如果失敗則返回None
    """
    resp = dashscope.TextEmbedding.call(
        model=dashscope.TextEmbedding.Models.text_embedding_v2,
        input=text)
    if resp.status_code == HTTPStatus.OK:
        return resp.output['embeddings'][0]['embedding']
    else:
        print(f"Failed to get embedding: {resp.status_code}")
        returnNone

def cosine_similarity(vec1, vec2):
    """
    計算兩個向量之間的余弦相似度
    :param vec1: 第一個向量
    :param vec2: 第二個向量
    :return: 余弦相似度
    """
    dot_product = np.dot(vec1, vec2)
    norm_vec1 = np.linalg.norm(vec1)
    norm_vec2 = np.linalg.norm(vec2)
    return dot_product / (norm_vec1 * norm_vec2)

def calculate_similarity(text1, text2):
    """
    計算兩個文本之間的相似度
    :param text1: 第一個文本
    :param text2: 第二個文本，可以包含多個句子，用逗號分隔
    :return: 每個句子的相似度列表，格式為 (句子, 相似度)
    """
    embedding1 = embed_text(text1)
    if embedding1 isNone:
        return []

    similarities = []
    sentences = [sentence.strip() for sentence in text2.split(',') if sentence.strip()]

    for sentence in sentences:
        embedding2 = embed_text(sentence)
        if embedding2 isNone:
            continue
        similarity = cosine_similarity(embedding1, embedding2)
        similarities.append((sentence, similarity))

    return similarities

def extract_keywords(text):
    """
    提取文本中的關鍵詞
    :param text: 輸入的文本
    :return: 關鍵詞列表
    """
    return extract_tags(text)

def cosine_similarity_tfidf(vec1, vec2):
    """
    計算兩個TF-IDF向量之間的余弦相似度
    :param vec1: 第一個TF-IDF向量
    :param vec2: 第二個TF-IDF向量
    :return: 余弦相似度
    """
    intersection = set(vec1.keys()) & set(vec2.keys())
    numerator = sum(vec1[x] * vec2[x] for x in intersection)
    sum1 = sum(vec1[x] ** 2for x in vec1)
    sum2 = sum(vec2[x] ** 2for x in vec2)
    denominator = math.sqrt(sum1) * math.sqrt(sum2)
    return numerator / denominator if denominator else0.0

def calculate_tfidf_similarity(text, text2):
    """
    計算兩個文本之間的TF-IDF相似度
    :param text: 第一個文本
    :param text2: 第二個文本，可以包含多個文檔，用豎線分隔
    :return: 每個文檔的TF-IDF相似度列表
    """
    documents = [doc for doc in text2.split('|') if doc.strip()]
    query_keywords = extract_keywords(text)
    documents_keywords = [extract_keywords(doc) for doc in documents]

    query_keyword_counts = {kw: query_keywords.count(kw) for kw in set(query_keywords)}
    total_documents = len(documents)
    all_keywords = set(kw for doc in documents_keywords for kw in doc)
    keyword_idf = {kw: math.log((1 + total_documents) / (1 + sum(1for doc in documents_keywords if kw in doc))) + 1for kw in all_keywords}

    query_tfidf = {kw: count * keyword_idf.get(kw, 0) for kw, count in query_keyword_counts.items()}
    documents_tfidf = [{kw: doc.count(kw) * keyword_idf.get(kw, 0) for kw in set(doc)} for doc in documents_keywords]

    return [cosine_similarity_tfidf(query_tfidf, doc_tfidf) for doc_tfidf in documents_tfidf]

def calculate_final_score(embedding_similarity, tfidf_similarity, w1=0.5, w2=0.5):
    """
    計算最終得分，結合語義相似度和TF-IDF相似度
    :param embedding_similarity: 語義相似度
    :param tfidf_similarity: TF-IDF相似度
    :param w1: 語義相似度的權重
    :param w2: TF-IDF相似度的權重
    :return: 最終得分
    """
    return w1 * embedding_similarity + w2 * tfidf_similarity

def main():
    """
    主函數(shù)，用于測試和演示
    """
    text1 = '把商品發(fā)到商鋪'
    text2 = '我想將商品掛到商鋪'
    text3 = '我想找商鋪問下商品'

    tfidf_similarities2 = calculate_tfidf_similarity(text1, text2)
    tfidf_similarities3 = calculate_tfidf_similarity(text1, text3)

    embedding_similarities2 = calculate_similarity(text1, text2)
    embedding_similarities3 = calculate_similarity(text1, text3)

    Semantic_Proportio = 0.8
    Word_Proportion = 0.2

    final_score2 = calculate_final_score(embedding_similarities2[0][1], tfidf_similarities2[0], Semantic_Proportio, Word_Proportion)
    final_score3 = calculate_final_score(embedding_similarities3[0][1], tfidf_similarities3[0], Semantic_Proportio, Word_Proportion)

    print(f"最終語句1得分: {final_score2} \n\n最終語句2得分: {final_score3}")

if __name__ == '__main__':
    main()

通過上述代碼，開發(fā)者可以輕松實現(xiàn)混合檢索功能，結合關鍵詞與語義檢索的優(yōu)勢，提升知識庫匹配的精準度。

總結

混合檢索技術通過整合關鍵詞檢索與語義檢索的優(yōu)勢，實現(xiàn)了多維度的知識召回，顯著提高了檢索結果的準確性和全面性。

希望本文的分享能夠為你在RAG知識庫的構建與優(yōu)化過程中提供有價值的參考與啟示。

本文轉載自??愛學習的蝌蚪??，作者：hpstream