RAG技术为大型语言模型（LLMs）提供了从数据源检索到的信息，以支撑其生成的答案。简而言之，RAG就是搜索加上LLM提示，你让模型在提供的信息上下文中回答问题。查询和检索到的上下文都被注入到发送给LLM的提示中。
典型的RAG向量化应用程序有两个主要组件：
索引：从源中获取数据并对其进行向量化索引。
检索和生成：运行时接受用户查询转化成向量化数据，并从索引中检索相关数据，然后将其传递给LLM，生成内容。
实际使用过程中，上面简单的流程经常效果不能满足业务需求，核心问题在于如何检索并处理好传给LLM的内容，下面介绍几种优化思路以及LangChain的实现。
1.
分层索引
如果你有大量文档需要检索，你需要能够有效地在文档中搜索、找到相关信息，并将这些信息综合成一个答案，并引用来源。一种有效的方法是创建两个索引——一个由摘要组成，另一个由文档块组成，并分两步进行搜索，首先通过摘要过滤出相关文档，然后在该相关组中进行搜索。
2.
假设性问题和HyDE
让LLM为每个块生成一个问题，并将这些问题向量化。运行时，对这个问题向量索引进行查询搜索，然后路由到原始文本块，并将它们作为上下文发送给LLM以获取答案。这种方法提高了搜索质量，因为与原始文本块相比，查询和假设问题之间的语义相似性更高。
还有一种叫做HyDE的反向逻辑方法——你要求LLM在给定查询的情况下生成一个假设的响应，然后将其向量与查询向量一起使用，以提高搜索质量。
3. 上下文丰富化
检索较小的块以获得更好的搜索质量，但将周围的上下文一起拼接起来传给LLM推理。当然在索引的时候就要把数据处理好，搜索的时候才能找到周围的上下文。这么做的好处，就是小的文本块可以提升搜索的准确率，而扩展上下文则可以给LLM更丰富的内容。
一种处理的方案是，通过分割和存储小块数据来实现，在检索过程中，它首先获取小块，然后查找这些块的父ID，并返回那些较大的文档。
参考LangChain中的实现ParentDocumentRetriever
4. 融合检索或混合搜索
将检索到的结果与不同的相似性分数适当地结合起来——这个问题通常是在倒排融合算法的帮助下解决的，该算法将检索得到的结果重新排序以获得最终输出。在LangChain中，这是在EnsembleRetriever类中实现的，它结合了您定义的检索器列表，例如faiss矢量索引和基于BM25的检索器，并使用RRF进行重新排序。混合或融合搜索通常会提供更好的检索结果，因为两种互补的搜索算法结合在一起，同时考虑了查询和存储文档之间的语义相似性和关键字匹配。
5.过滤和压缩
检索容易遇到的一个问题，当把数据向量化索引到数据库时，不太可能预想到对应的用户问题会是什么。这意味着，与查询最相关的信息可能隐藏在一个包含大量不相关文本的文档中，如果都一股脑传给LLM，不仅费用高（肉疼）而且效果可能也会受影响。
LLMChainFilter是一个简单的压缩器，使用LLM链来决定最初检索到的文档中的哪些要过滤掉，哪些要返回，而无需操作文档内容。嗯。。。这个，我就是因为不想调用LLM费钱处理才采用这个方案的吗？EmbeddingsFilter通过嵌入文档和查询并只返回那些与查询具有足够相似嵌入的文档，提供了一个更便宜、更快的选项。
上下文压缩是另一种解决问题的思路。这个想法很简单：您可以使用给定查询的上下文对它们进行压缩，从而只返回相关信息，而不是立即按原样返回检索到的文档。ContextualCompressionRetriever循环处理返回的原始文档，并从每个文档中仅提取与查询相关的内容。
6.元数据过滤
我们已经习惯了SQL查询的时候增加Where的限制条件，这个可以精确查询所需的数据。RAG也不是所有的时候都要通过语义或关键词检索。比如检索“所有评分大于8分的电影”，或者我们公司实际的业务场景，检索的时候只需要明确某个品牌的数据。
通过元数据过滤实现精确过滤，和语义检索配合。在存储数据块到向量数据块时，需要先处理好元数据，在我们公司的场景中，就是把所属的品牌ID一起存储。检索的时候可以利用大模型的理解能力，把自然语言转成元数据过滤。看看LangChain的实现，metadata_field_info是pydantic的格式
7.时间加权
对于一些类似客服FAQ的场景，检索命中越频繁，数据的权重就越高，可以使用了语义相似性和时间衰减的组合。LangChain给出的计算公式是这样的
hours_passed是指自上次访问检索器中的对象以来（而不是自创建对象以来）经过的小时数。这意味着频繁访问的对象保持“新鲜”。
还有另一种时间权重，比如新闻资讯，创建时间越近权重越高，甚至可以为其设置过期时间。
RAG应用系统中，大家比较关心的因素：准确率、速度、成本。上面讨论的方案基本上都是提升准确率的，同时带来的问题就是速度下降，部分方案会成本上升。
另一方面，在实际的业务场景中，准确率可能是现阶段最重要的问题，业务人员对于应用的要求可能是90分，而LLM目前的能力只能达到60分，如果不能通过其它的方式提升效果，那么应用可能无法在实际场景中使用了。
