如何提升RAG系统整体效果:从索引构建-问句理解-混合搜索+语义排序着手,评估系统

向量数据库大模型机器学习
如何提升RAG系统整体效果:从索引构建-问句理解-混合搜索+语义排序着手,评估系统
1.Query understanding

1.1 构建数据索引

一个主要的问题是, query 的 embedding 与文档的 embedding 在向量空间并没有对齐。改善这种情况的常见方法是从文档中提取信息并用它来回答问题。可以对文档提取、总结和生成潜在问题以改进的 embedding 匹配的问题。

例如,给定一个文档时,可以尝试:

    1. 提取 keywords 和 topics
    1. 生成HyDE-假设性问句:针对每个chunk级别生成,关键句--提炼”抽象“点金句子
    1. 生成摘要

 
 
 
 
   
class Extraction(BaseModel):  
    topic: str  
    summary: str  
    hypothetical\_questions: List[str] = Field(  
        default\_factory=list,  
        description="Hypothetical questions that this document could answer",  
    )  
    keywords: List[str] = Field(  
        default\_factory=list, description="Keywords that this document is about"  
    )  
  
text\_chunk = """  
## Simple RAG  
  
**What is it?**  
  
The simplest implementation of RAG embeds a user query and do a single embedding search in a vector database, like a vector store of Wikipedia articles. However, this approach often falls short when dealing with complex queries and diverse data sources.  
  
**What are the limitations?**  
  
- **Query-Document Mismatch:** It assumes that the query and document embeddings will align in the vector space, which is often not the case.  
    - Query: "Tell me about climate change effects on marine life."  
    - Issue: The model might retrieve documents related to general climate change or marine life, missing the specific intersection of both topics.  
- **Monolithic Search Backend:** It relies on a single search method and backend, reducing flexibility and the ability to handle multiple data sources.  
    - Query: "Latest research in quantum computing."  
    - Issue: The model might only search in a general science database, missing out on specialized quantum computing resources.  
- **Text Search Limitations:** The model is restricted to simple text queries without the nuances of advanced search features.  
    - Query: "what problems did we fix last week"  
    - Issue: cannot be answered by a simple text search since documents that contain problem, last week are going to be present at every week.  
- **Limited Planning Ability:** It fails to consider additional contextual information that could refine the search results.  
    - Query: "Tips for first-time Europe travelers."  
    - Issue: The model might provide general travel advice, ignoring the specific context of first-time travelers or European destinations.  
"""  
  
extractions = client.chat.completions.create(  
    model="gpt-4-1106-preview",  
    stream=True,  
    response\_model=Iterable[Extraction],  
    messages=[  
        {  
            "role": "system",  
            "content": "Your role is to extract chunks from the following and create a set of topics.",  
        },  
        {"role": "user", "content": text\_chunk},  
    ],  
)  
  
for extraction in extractions:  
    pprint(extraction.model\_dump())  
  


 
 
 
 
   
{'hypothetical\_questions': ['What is the basic concept behind simple RAG?',  
                            'How does simple RAG work for information '  
                            'retrieval?'],  
 'keywords': ['Simple RAG',  
              'Retrieval-Augmented Generation',  
              'user query',  
              'embedding search',  
              'vector database',  
              'Wikipedia articles',  
              'information retrieval'],  
 'summary': 'The simplest implementation of Retrieval-Augmented Generation '  
            '(RAG) involves embedding a user query and conducting a single '  
            'embedding search in a vector database, like a vector store of '  
            'Wikipedia articles, to retrieve relevant information. This method '  
            'may not be ideal for complex queries or varied data sources.',  
 'topic': 'Simple RAG'}  
{'hypothetical\_questions': ['What are the drawbacks of using simple RAG '  
                            'systems?',  
                            'How does query-document mismatch affect the '  
                            'performance of RAG?',  
                            'Why is a monolithic search backend a limitation '  
                            'for RAG?'],  
 'keywords': ['limitations',  
              'query-document mismatch',  
              'simple RAG',  
              'monolithic search backend',  
              'text search',  
              'planning ability',  
              'contextual information'],  
 'summary': 'Key limitations of the simple RAG include query-document '  
            'mismatch, reliance on a single search backend, constraints of '  
            'text search capabilities, and limited planning ability to '  
            'leverage contextual information. These issues can result in '  
            'suboptimal search outcomes and retrieval of irrelevant or broad '  
            'information.',  
 'topic': 'Limitations of Simple RAG'}  
  

从单一的文档 chunk 生成了 keywords,topics,HyDE 和 summary,这些信息可以极大的提高检索的效果。

  • • 推荐:
  • • 一级索引:假设问句[chunk]、摘要+点金句+关键词[Note粒度]
  • • 二级索引:chunk+点金句+关键词,

1.2 问句改写

适用于 Query Rewriting 的模型可以是一个大型模型,或者也可以是一个专门训练来执行此任务的较小模型。

此外,Query Rewriting 可以根据应用程序的需求采取许多不同的形式。大多数时候,基本的查询重写就足够了。但是,根据需要回答的问题的复杂性,可能需要更高级的技术,如 HyDE、multi-query 或 step-back 等。

Query Rewriting 通常在任何知识密集型的 RAG 中都能提供更好的性能。这是因为 RAG 对 query 的措辞和特定关键字很敏感。在以下情况下,采用 Query Rewriting 是有帮助的。

    1. 问题重构:该系统能够重新构建表述不清晰或结构奇怪的问题,从而提升系统的理解能力,确保问题得到准确解析。
    1. 无关上下文剔除:通过智能分析,系统能够去除用户输入中与查询不直接相关的上下文信息,提高查询的精确度和效率。
    1. 关键字引入:系统能够自动添加与问题相关的关键字,这些关键字有助于系统更准确地匹配到相关的上下文信息,提高答案的准确率。
    1. 问题分解:对于复杂问题,系统能够将其分解为多个简单、独立的子问题,每个子问题都有明确的上下文,便于分别解答,最终整合得出完整答案。
    1. 回退问题生成:针对需要多层次思考的问题,系统能够生成更高层次的回退问题,通过结合原始问题和回退问题进行上下文检索,更全面地理解问题并给出答案。
    1. 高级查询重写技术:系统采用先进的查询重写技术(如HyDE),通过生成假设文档来捕捉问题的真实意图,并与向量数据库中的嵌入进行高效匹配,从而快速准确地找到答案。

查询重写的一般策略

以下是 RAG 系统中各种查询重写技术的一些关键示例和用例:

  • 假设文档嵌入(HyDE)

HyDE 根据查询生成假设文档以改进检索。其过程如下:

    1. LLM 生成回答查询的假设文档
    1. 将此文档编码为向量
    1. 使用该向量进行检索,而不是原始查询向量

例如,对于查询 “气候变化的影响是什么?”,HyDE 可能会生成一个假设文档,如:

“气候变化对环境有广泛的影响,包括海平面上升、更频繁的极端天气事件以及动植物范围的变化。它影响全球的农业、水资源、人类健康和生态系统。”

然后对这个假设文档进行编码并用于检索,与使用原始的短查询相比,可能会改善结果。

实际使用过程中效果一般,建议在索引构建环境直接使用

  • 回退提示

回退提示从特定查询生成更广泛、更通用的查询。例如:

原始查询:“我如何在 2015 款丰田凯美瑞上更换瘪胎?” 回退查询:“更换汽车瘪胎的一般步骤是什么?”

这个更广泛的查询可能会检索到更多关于轮胎更换的相关一般信息,然后可以应用于具体情况。

兜底策略

  • 查询到文档(Query2Doc)

Query2Doc 生成伪文档来扩展和澄清查询。与假设直接回答的 HyDE 不同,Query2Doc 创建一个围绕查询提供上下文的文档。例如:

查询:“姜黄的健康益处是什么?” 生成的伪文档:“姜黄是印度菜肴中常用的香料。它已被研究具有潜在的健康益处。一些感兴趣的领域包括其抗炎特性、抗氧化作用以及对大脑功能和心脏健康可能产生的影响。”

然后使用此伪文档进行检索,可能会捕获更广泛的相关信息。

不推荐

  • 多查询 / 子查询

此技术将复杂查询分解为多个更简单的子查询。例如:

原始查询:“比较 FDR 和里根的经济政策” 子查询:

    1. “富兰克林 ·D· 罗斯福的主要经济政策是什么?”
    1. “罗纳德 · 里根的关键经济政策是什么?”
    1. “FDR 的经济方法与里根的有何不同?”

通过分解复杂查询,系统可以为问题的每个方面检索更具体和相关的信息。

这些技术可以显著提高 RAG 系统中的检索性能,从而获得更准确和全面的答案。技术的选择取决于具体的用例、查询的复杂性以及要检索的信息的性质。


 
 
 
 
   
from langchain.llms import OpenAI  
from langchain.prompts import PromptTemplate  
from langchain.chains import LLMChain  
from langchain.embeddings import OpenAIEmbeddings  
from langchain.text\_splitter import CharacterTextSplitter  
from langchain.vectorstores import FAISS  
from langchain.docstore.document import Document  
  
#初始化 LLM 和嵌入  
llm = OpenAI(temperature=0.7)  
embeddings = OpenAIEmbeddings()  
  
#1. 假设文档嵌入(HyDE)  
hyde\_prompt = PromptTemplate(  
    input\_variables=["query"],  
    template="Generate a detailed answer for the following question:\n{query}\n\nAnswer:"  
)  
  
hyde\_chain = LLMChain(llm=llm, prompt=hyde\_prompt)  
  
def hyde(query):  
    hypothetical\_doc = hyde\_chain.run(query)  
    doc\_embedding = embeddings.embed\_query(hypothetical\_doc)  
    return doc\_embedding  
  
#使用示例  
query = "What are the effects of climate change?"  
hyde\_embedding = hyde(query)  
  
#2. 回退提示  
step\_back\_prompt = PromptTemplate(  
    input\_variables=["query"],  
    template="Generate a more general version of this specific query:\n{query}\n\nGeneral query:"  
)  
  
step\_back\_chain = LLMChain(llm=llm, prompt=step\_back\_prompt)  
  
def step\_back(query):  
    general\_query = step\_back\_chain.run(query)  
    return general\_query  
  
#使用示例  
specific\_query = "How do I change a flat tire on a 2015 Toyota Camry?"  
general\_query = step\_back(specific\_query)  
  
#3. 查询到文档  
query2doc\_prompt = PromptTemplate(  
    input\_variables=["query"],  
    template="Generate a short document providing context for this query:\n{query}\n\nContext document:"  
)  
  
query2doc\_chain = LLMChain(llm=llm, prompt=query2doc\_prompt)  
  
def query2doc(query):  
    pseudo\_doc = query2doc\_chain.run(query)  
    return pseudo\_doc  
  
#使用示例  
query = "What are the health benefits of turmeric?"  
pseudo\_doc = query2doc(query)  
  
#4. 多查询/子查询  
multi\_query\_prompt = PromptTemplate(  
    input\_variables=["query"],  
    template="Break down this complex query into 3-5 simpler sub-queries:\n{query}\n\nSub-queries:"  
)  
  
multi\_query\_chain = LLMChain(llm=llm, prompt=multi\_query\_prompt)  
  
def multi\_query(query):  
    sub\_queries\_text = multi\_query\_chain.run(query)  
    sub\_queries = sub\_queries\_text.split('\n')  
    return [q.strip() for q in sub\_queries if q.strip()]  
  
#使用示例  
complex\_query = "Compare the economic policies of FDR and Reagan"  
sub\_queries = multi\_query(complex\_query)  
  
#RAG 管道中的示例用法  
def rag\_pipeline(query, documents):  
    # 创建向量存储  
    text\_splitter = CharacterTextSplitter(chunk\_size=1000, chunk\_overlap=0)  
    texts = text\_splitter.split\_documents(documents)  
    docsearch = FAISS.from\_documents(texts, embeddings)  
  
    # 查询重写  
    hyde\_emb = hyde(query)  
    general\_query = step\_back(query)  
    pseudo\_doc = query2doc(query)  
    sub\_queries = multi\_query(query)  
  
    # 使用各种方法检索文档  
    hyde\_docs = docsearch.similarity\_search\_by\_vector(hyde\_emb, k=2)  
    general\_docs = docsearch.similarity\_search(general\_query, k=2)  
    pseudo\_docs = docsearch.similarity\_search(pseudo\_doc, k=2)  
    sub\_query\_docs = [doc for sq in sub\_queries for doc in docsearch.similarity\_search(sq, k=1)]  
  
    # 合并并去重结果  
    all\_docs = hyde\_docs + general\_docs + pseudo\_docs + sub\_query\_docs  
    unique\_docs = list({doc.page\_content: doc for doc in all\_docs}.values())  
  
    # 通常,您会将这些文档传递给您的 LLM 以生成最终答案  
    return unique\_docs  
  
#使用示例  
documents = [Document(page\_content=f"Document {i}") for i in range(10)]  # 示例文档  
query = "What are the long-term economic impacts of climate change?"  
relevant\_docs = rag\_pipeline(query, documents)  
  

理解“最近的查询”以添加时间上下文

在检索过程中,对于数据的时效性有时候是至关重要的,因此如何基于 Query 添加对应的时间线索,有助于检索出在固定时间区间下更相关的数据。此外需要注意的是,一定要设置好默认的时间区间,否则,可能会空召回。基于 Instructor 结合 OpenAI 给出示例。


 
 
 
 
   
from datetime import date  
  
class DateRange(BaseModel):  
    start: date  
    end: date  
  
class Query(BaseModel):  
    rewritten\_query: str  
    published\_daterange: DateRange  
  

在此示例中,DateRangeQuery是 Pydantic 模型,它们通过日期范围和要在其中搜索的域列表来构建用户的 query。

这些模型重新构建 用户的 query,包括 rewritten_query、published_daterange。

使用新的 rewritten_query,可以将此模式应用于的函数调用,以获得针对后端优化的结果。


 
 
 
 
   
def expand\_query(q) -> Query:  
    return client.chat.completions.create(  
        model="gpt-3.5-turbo",  
        response\_model=Query,  
        messages=[  
            {  
                "role": "system",  
                "content": f"You're a query understanding system for the Metafor Systems search engine. Today is {date.today()}. Here are some tips:...",  
            },  
            {"role": "user", "content": f"query: {q}"},  
        ],  
    )  
  
query = expand\_query("What are some recent developments in AI?")  
query  
  


 
 
 
 
   
Query(rewritten\_query='Recent developments in artificial intelligence', published\_daterange=DateRange(start=datetime.date(2024, 1, 1), end=datetime.date(2024, 3, 31)))  
  

这不仅仅是添加一些日期范围。甚至可以使用一些思维链提示来生成与的后端深度集成的定制搜索。


 
 
 
 
   
class DateRange(BaseModel):  
    chain\_of\_thought: str = Field(  
        description="Think step by step to plan what is the best time range to search in"  
    )  
    start: date  
    end: date  
  
class Query(BaseModel):  
    rewritten\_query: str = Field(  
        description="Rewrite the query to make it more specific"  
    )  
    published\_daterange: DateRange = Field(  
        description="Effective date range to search in"  
    )  
  
def expand\_query(q) -> Query:  
    return client.chat.completions.create(  
        model="gpt-4-1106-preview",  
        response\_model=Query,  
        messages=[  
            {  
                "role": "system",  
                "content": f"You're a query understanding system for the Metafor Systems search engine. Today is {date.today()}. Here are some tips:...",  
            },  
            {"role": "user", "content": f"query: {q}"},  
        ],  
    )  
  
expand\_query("What are some recent developments in AI?")  
  


 
 
 
 
   
Query(rewritten\_query='latest advancements in artificial intelligence', published\_daterange=DateRange(chain\_of\_thought='Since the user is asking for recent developments, it would be relevant to look for articles and papers published within the last year. Therefore, setting the start date to a year before today and the end date to today will cover the most recent advancements.', start=datetime.date(2023, 3, 31), end=datetime.date(202  
  

  1. 混合检索 + 语义排名 ==============

生成式 AI 应用需要通过从包含必要知识的索引中检索内容来奠定基础。如果将不相关的内容传递给 LLM,这将违背这一目标,并需要模型过滤多余的信息。这可能会降低生成的响应质量,并增加延迟和运营成本。

对代表性客户索引以及流行的学术基准进行了测试,以评估内容检索结果的质量。总体而言,对于大多数场景,最有效的检索引擎通过以下方式实现:

• 将长篇内容分块,

• 使用混合检索(结合关键词和向量搜索),以及

• 启用语义排名。

| 搜索配置 | 客户数据集 [NDCG@3] | BEIR 数据集 [NDCG@10] | Multilingual Academic (MIRACL) [NDCG@10] | | 关键字 | 40.6 | 40.6 | 49.6 | | 向量 (Ada-002) | 43.8 | 45.0 | 58.3 | | 混合 (Keyword + Vector) | 48.4 | 48.4 | 58.8 | | 混合检索 + 语义重排 | 60.1 | 50.0 | 72.0 |

2.1 混合检索结合了关键词和向量搜索的优势

关键词和向量检索从不同的角度处理搜索,提供互补的功能。向量检索将查询语义匹配到具有相似含义的段落。这非常强大,因为嵌入对拼写错误、同义词和措辞差异的敏感性较低,甚至可以在跨语言场景中工作。关键词搜索则优先匹配那些可能在嵌入中被淡化的特定重要词汇。

用户搜索可以有多种形式。混合检索在不同查询类型中始终能够将两种检索方法的最佳效果展现出来。拥有最有效的 L1 后,L2 排序步骤可以显著提高顶级结果的质量。

| 查询类型 | 关键词 [NDCG@3] | 向量 [NDCG@3] | 混合 [NDCG@3] | 混合 + 语义排序器 [NDCG@3] | | 概念查找查询 | 39.0 | 45.8 | 46.3 | 59.6 | | 事实查找查询 | 37.8 | 49.0 | 49.1 | 63.4 | | 精确片段搜索 | 51.1 | 41.5 | 51.0 | 60.8 | | 类似网页搜索的查询 | 41.8 | 46.3 | 50.0 | 58.9 | | 关键词查询 | 79.2 | 11.7 | 61.0 | 66.9 | | 查询与文档术语重叠较低 | 23.0 | 36.1 | 35.9 | 49.1 | | 有拼写错误的查询 | 28.8 | 39.1 | 40.6 | 54.6 | | 长查询 | 42.7 | 41.6 | 48.1 | 59.4 | | 中等长度查询 | 38.1 | 44.7 | 46.7 | 59.9 | | 短查询 | 53.1 | 38.8 | 53.0 | 63.9 |

2.2 文档分块策略很重要

分块为生成式 AI 应用程序解决了三个问题:

• 将长文档拆分为有限长度的段落,允许将多个检索到的文档传递给 LLM,并保持在其上下文窗口限制内。

• 分块提供了一种机制,以便给定文档中最相关的段落优先被排序。

• 向量搜索对每个向量可以嵌入的内容有模型限制。

将每个文档分块并为每个分块生成独立向量,可以使输入保持在嵌入模型的 token 限制内,并且在 ANN(近似最近邻)搜索索引中无需截断即可搜索整个文档。大多数深度嵌入模型的限制为 512 个 token,而 Ada-002 的限制为 8,192 个 token。中等长度的文档可能包含数万个 token。当文档非常长或者查询的答案位于文档的后面时,分块的优势尤为明显。

| 检索配置 | 单向量表示每个文档 [Recall@50] | 分块文档 [Recall@50] | | 答案在长文档中的查询 | 28.2 | 45.7 | | 答案在文档深处的查询 | 28.7 | 51.4 |

另一个关键因素是,嵌入模型必须将一段文本的所有语义内容压缩到有限数量的浮点数中(例如,Ada-002 使用 1,536 维)。如果开发人员将包含多个主题的长段落编码为一个单一的向量,重要的细微差别可能会丢失。的分析显示,使用较大的分块会降低检索性能。

| 检索配置 | Recall@50 | | 每个向量 512 个输入标记 | 42.4 | | 每个向量 1024 个输入标记 | 37.5 | | 每个向量 4096 个输入标记 | 36.4 | | 每个向量 8191 个输入标记 | 34.9 |

开发人员可以通过多种方式构建每个向量的输入。例如,他们可以使每个块之间有重叠,从而在它们之间共享上下文,或者他们可以在每个向量中添加文档标题或关键主题,以提供更多的上下文。将向量在自然句子和段落的断点处终止的策略既简单又有效。

| 分块边界策略 | Recall@50 | | 512 个标记,按标记边界分割 | 40.9 | | 512 个标记,保留句子边界 | 42.4 | | 512 个标记,10% 重叠分块 | 43.1 | | 512 个标记,25% 重叠分块 | 43.9 |

2.3 测试方法说明

  • • 是如何生成这些数据的 为了评估哪些检索系统和配置表现最佳,遵循最佳实践生成可比较的指标。总体过程是对每个配置的多个文档索引进行一系列查询,并产生检索和排序的评分。 • 文档:使用了来自 Azure 客户(经过他们许可)或公开可用基准的统一文档集。 • 查询:使用了最终用户查询和 / 或通过多种 GPT 提示生成的查询,使用文档索引中的随机片段作为基础。 • 评分:使用了基准提供的标签(和官方评分库)用于 BEIR 和其他数据集。对于客户数据集,使用了经过内部审查的高质量人工标签的 GPT 提示。 使用了 3 个指标来确定的推荐:
  • • NDCG@10:NDCG 是一种常用的信息检索指标,它根据检索系统(1)找到最佳结果的能力和(2)将这些结果按照理想顺序(即从最好的文档到最差的文档的排序)进行评分。@10 表示在评分计算中考虑了前 10 个文档。使用这个指标和公共基准的可用标签池,以保持与以前运行的一致性。归一化折扣累积增益(NDCG)。
  • • NDCG@3:相同的 NDCG 指标,但计算在前 3 个文档上。使用 @3 是因为希望在生成 AI 场景中获取最准确的前 3 个结果。评分前 50 个文档,因为 Azure AI Search 的语义排序器工作在前 50 个结果上。
  • • Recall@50:计算在前 50 个检索结果中,评分提示标记为高质量的文档数量,并将其除以已知的良好文档数量。
  • • 搜索和数据集配置 搜索配置 对于此结果表,所有文档被拆分成 512 个标记的块,重叠部分为 25%。 数据集详情
  • • 客户数据集:从 4 个不同的客户数据集中构建的检索基准,涵盖了各种行业和文档结构。所有文档都通过 Azure AI Search 的文档摄取管道从原始输入(如 pptx、pdf、html)中导入。每个数据集的查询既包括提供的查询,也包括 GPT 生成的查询。对于 ANN 向量检索测试,所有文档都被拆分为 512 个标记的块,重叠部分为 25%,并使用 Ada-002 进行嵌入。
  • • BEIR:从官方来源(beir-cellar/beir: A Heterogeneous Benchmark for Information Retrieval. Easy to use, evaluate your mo…)导入以下数据集,并使用官方标签和官方评分库生成指标。对于 ANN 向量检索,每个文档都使用 Ada-002 索引(在 99.9% 的情况下,1 个向量足以表示完整文档)。使用的 Beir 数据集:nq、scidocs、touche2020、arguana、climate-fever、dbpedia、fever、hotpotqa、covid。
  • • Miracl:直接从官方来源(project-miracl/miracl: A large-scale multilingual dataset for Information Retrieval. Thorough human-…)导入,并使用官方标签进行评分。由于数据集的规模,使用了以下简化方法:为每种语言抽样了 250 个查询,只有带有标签的文档进行了向量化,并构建了一个多语言组合索引。报告的指标是 ar、bn、de、en、es、fa、fi、fr、hi、id、ja、ko、ru、sw、te、th、yo、zh 语言的平均值。
  • • 关键词:将所有块作为完整文档进行索引。使用基于关键词的索引(BM25 相似度)进行检索,并标记前 50 个结果。
  • • 向量:所有块使用 Ada-002 进行嵌入,并构建了 ANN 索引。每个查询也使用 Ada-002 进行嵌入,并使用余弦相似度进行检索。标记了前 50 个结果。
  • • 混合:对块的关键词索引和向量索引进行检索(取每个索引的前 50 个结果),然后使用 RRF 融合结果。标记了 RRF 的前 50 个文档(块)。
  • • 混合 + 语义排序:对启用了语义排序的混合搜索配置进行查询。
  • • 查询类型定义

| 查询类型 | 解释 | 示例 | | 概念寻求查询 | 抽象问题,需用多句话才能回答 | “为什么我应该使用语义搜索来排序结果?” | | 精确片段搜索 | 精确子字符串的较长查询 | “使您能够最有效地最大化对 LLM 投资的质量和价值,方法是只提供相关信息” | | 类似网页搜索的查询 | 类似于常见搜索引擎中输入的简短查询 | “最佳检索概念查询” | | 低查询 / 文档词汇重叠 | 查询和答案使用不同词汇和短语,检索较困难 | “最好的排序技术” 搜索一个说:“Azure AI Search 具有排名您内容的最佳模型” | | 事实寻求查询 | 有一个单一明确答案的查询 | “有多少文档是语义排序的” | | 关键词查询 | 仅包含重要标识词的简短查询 | “语义排序器” | | 拼写错误的查询 | 包含拼写错误、字母顺序错误的查询 | “Ho w mny documents are samantically r4nked” | | 长查询 | 超过 20 个标记的查询 | “这是一个非常长的查询,因为它在其组成和结构中使用了大量标记,非常冗长” | | 中等长度查询 | 长度介于 5 和 20 个标记之间的查询 | “这是一个中等长度的查询” | | 短查询 | 少于 5 个标记的查询 | “短查询” |

2.4 RRF倒数排序融合

RRF(Reciprocal Rank Fusion)就是用于信息检索和排序系统中,将多个排序列表融合为一个综合排序列表的算法,本质上 RRF 就是一个很简单的公式。

picture.image

在这里插入图片描述

  • • d 是指某一个文档,也是某一条数据(通常以数据的唯一 id 来区分)
  • • S(d) 是综合得分
  • • k 是一个常数(通常为60)

是文档 d 在第 i 个排序列表中的排名

从公式上看,排名越靠前,综合得分越高,并且,由于是对所有排序列表的得分进行求和,所以一个文档在多个排序列表中排名靠前的话,它的综合得分就会比较高,从而在最终的融合排名中也会更靠前。

RRF 可视化 UI:https://deval-shah.github.io/visualizations/rrf/

picture.image

在这里插入图片描述

参考链接:https://blog.csdn.net/UbuntuTouch/article/details/131200354

3.RAG评估--RAGas

大家常说 RAG 应用是:一周出 demo,半年用不好。那么怎么评估 RAG 应用是否能够上生产了呢?

RAGas(RAG Assessment)RAG 评估的缩写,是一个专门的解决方案用于评估、监控和提升生产环境中大语言模型(LLM)和检索增强生成(RAG)应用的性能,包括用于生产质量监控的定制模型。它除了评估,还能从数据集中生成测试集,这将极大地降低人力投入,毕竟一个良好的数据集构建是非常消耗时间和人力的。

  • • 生成角度可以从忠实性 faithfulness 和回答相关性 answer relevancy 评估,
  • • 检索则从上下文精度(context precision)和上下文召回(context recall)上来测评。

当然 ragas 不止这四种评测,还有答案准确性(answer correctness),上下文利用率(context utilization),上下文实体召回率(context entity recall)和噪声敏感度(noise sensitivity)等。

参考资料

[1] Alec Berntson: https://techcommunity.microsoft.com/t5/user/viewprofilepage/user-id/2031971

[2] 关键词 : https://learn.microsoft.com/en-us/azure/search/search-lucene-query-architecture

[3] 向量 : https://learn.microsoft.com/en-us/azure/search/vector-search-overview

[4] 混合 : https://learn.microsoft.com/en-us/azure/search/vector-search-ranking#hybrid-search

[5] 语义排名: https://learn.microsoft.com/en-us/azure/search/semantic-search-overview

[6] Azure AI Search 文档: https://learn.microsoft.com/en-us/azure/search/

0
0
0
0
关于作者
关于作者

文章

0

获赞

0

收藏

0

相关资源
高性能存储虚拟化方案 NVMe over Fabric 在火山引擎的演进
在云计算中,虚拟化存储扮演着重要角色,其中 iSCSI 协议在业界开放、流行多年。近年来,拥有更优性能的 NVMe over Fabrics 协议也得到了发展。本次分享介绍了 NVMe over Fabrics 在云原生和虚拟化方向的演进工作和成果。
相关产品
评论
未登录
看完啦,登录分享一下感受吧~
暂无评论