建立生成性AI应用程序，使用检索增强生成（RAG）可能会带来一系列挑战。让我们来看看依赖于向量数据库来检索相关上下文，并将其包含在提示中，供大型语言模型提供更相关结果的RAG实现的故障排除。
我们将把这个过程分为两个主要部分。第一个部分，我们将在本系列的第一篇文章中讨论的是嵌入管道，它用嵌入填充向量数据库：
在这里，我们将考虑三个主要领域可能会导致结果不佳：次优的嵌入模型、低效的分块策略和缺乏元数据过滤器（在即将发布的文章中，我们将研究与LLM的实际交互，并查看一些常见的问题，并导致结果不佳。）
选择适当的嵌入模型
您选择的嵌入模型将对您的RAG应用程序的整体相关性和可用性产生重大影响。因此，它需要对每个模型的能力有细致的了解，并分析这些能力与您的应用要求的吻合度。
如果您对RAG和嵌入一般相对较新，您应该了解的最佳资源之一是MTEB（大规模文本嵌入基准）嵌入排名表。我们在本文中关注的是检索用例，但嵌入当然可以用于许多其他应用，包括分类、聚类和摘要。排行榜可以帮助您确定最适合您特定用例的模型。
导致RAG性能不佳的最常见原因之一是初次接触此领域的开发人员在Google搜索中寻找嵌入生成的示例。他们经常找到使用诸如Word2Vec、sBERT和RoBERTa等嵌入模型的样本，这些模型对于检索用例来说是不合适的选择。如果您发现本文，因为您正在调试相关性差的结果，并且您使用类似sBERT这样的模型来生成嵌入，那么我们可能已经找到了您相关性问题的原因。
如果是这样，您接下来可能会问的问题是，有哪些嵌入模型可用于改善相似性搜索结果。在不知道您用例的细节的情况下，我们建议的三个模型是：
1. text-embedding-ada-002（Ada v2）
OpenAI的Ada v2可能是大多数RAG应用程序的常见起点，因为很多开发人员首先使用Open AI的API。Ada v2在检索用例中表现出色，并且专为处理不同类型的内容（包括文本和代码）而构建。它的最大输入序列长度可达8,192个标记，这也使您可以为比替代模型更长的文本创建嵌入。这既是福音又是诅咒。拥有较大的序列大小简化了为更多文本内容创建嵌入的过程，并允许嵌入模型在更大的文本体中识别单词和句子之间的关系。
然而，当您要比较两个长文档的相似性时，您可能会得到更模糊的相似性搜索结果，而您要找的是相关上下文的相关片段，以促进生成过程。
Ada v2有两个主要缺点。第一个是它无法在本地运行。您必须使用OpenAI的API来创建嵌入。这不仅可能在您想要为许多内容创建嵌入的情况下产生瓶颈，还会增加每1,000个记号0.0001美元的成本。第二个是从Open AI模型创建的嵌入每个维度为1,536。如果您使用的是云向量数据库，则这可能会大大增加向量存储成本。
选择时机：您希望选择一个只需要API调用的简单解决方案，您可能需要为大型文档创建向量，而成本不是问题。
2. jina-embeddings-v2（Jina v2）
Jina v2是一个新的开源嵌入模型，具有与Ada v2相同的8,000个输入序列支持，并且在检索用例中实际上得分稍好。
Jina v2为Ada v2的问题提供了解决办法。它是遵循Apache License 2.0的开源模型，并可以在本地运行，当然，如果您不打算运行自己的代码来执行此操作，这也是一个缺点。它还在向量数据库的角度提供了一半维度的嵌入向量。因此，您不仅可以在基准用例上获得稍微更好的检索性能，而且还可以以更低的存储和计算要求获得这些改进的结果。
何时选择：您希望使用开源解决方案并有可能需要对大型文档进行向量化，并且对于在本地运行嵌入流程感到舒适。您希望通过较低维度的嵌入来降低向量数据库的成本。
3. bge-large-en-v1.5
bge-large-en-v1.5在MIT许可下开源，目前是MTEB排行榜上重视检索用例的排名最高的嵌入模型。较小的输入序列将要求您考虑更多的块划分策略，但最终提供了最佳的整体性能，适用于检索用例。
何时选择：您希望使用开源解决方案并愿意花更多时间在块划分策略上，以符合输入大小的限制。您可以在本地运行嵌入流程。您想要用于检索用例的最佳性能嵌入模型。
虽然本文未涉及这方面，但您可能希望更深入地了解MTEB排行榜中的15个基准，以确定与您的特定情况最接近的基准。嵌入模型在不同基准上的表现往往存在一定的规律，但通常在每个基准中都有一些特定的模型突出。如果您需要进一步细化嵌入选择，这是一个可能需要进一步研究的领域。
优化您的块划分策略
文本输入的分割或“块划分”是一个重要因素，它显著地影响生成的输出的相关性和准确性。各种块划分策略都提供独特的优势，并适用于特定类型的任务。在这里，我们深入探讨这些方法，并提供其应用的指导原则，包括一些关键考虑因素：
固定长度块划分
- 何时使用：除非您的内容本身高度结构化且长度固定，否则通常应依赖于更有用的块划分策略，如后面介绍的策略。
- 技术考虑：虽然实现起来非常简单，但是这种块划分策略通常会导致在RAG应用中的结果较差。
- 其他见解：如果您在RAG应用中使用固定长度策略，并且很难检索相关的上下文信息，您应该考虑切换到不同的块划分方法。
句子级块划分
- 何时使用：当输入文本中的每个句子都富含含义和上下文时，这种策略非常有效。它允许模型专注于每个句子中的细微差别，从而生成更连贯和语境相关的回答。您很少会在RAG用例中依赖句子级块划分。
- 技术考虑：句子级块划分通常涉及基于句子边界进行的标记化，可以使用自然语言处理（NLP）库实现。
- 其他见解：句子级块划分在您需要搜索特定语句的情况下特别有用，例如在会议记录的转录中，您要找到与给定文本的语义相似的语句。
段落级块划分
- 何时使用：在输入文本被组织成具有不同部分或段落的明显分节的情况下，应采用这种策略，每个段落都包含一个单独的想法或主题。这使得模型可以专注于每个段落中的相关信息。
- 技术考虑：识别段落边界通常涉及检测换行符或其他表示段落结束的界定符。
- 其他见解：段落级块划分在您有多个不同方面的文档涵盖同一主题时非常有用。例如，一篇产品文档的一页可能会介绍一个产品功能，解释何时使用它，讨论如何配置它，并提供不同配置的示例。使用段落级块划分可以帮助您确定提供给LLM作为上下文的文档的最相关部分。
内容感知块划分
- 何时使用：在文本中特定部分的相关性至关重要时，选择这种策略。例如，在法律文件中，基于条款或章节对文本进行分割可以产生更具上下文特定性的回答。
- 技术考虑：这种方法可能需要使用先进的NLP技术来理解文本中的语义边界。
- 其他见解：内容感知块划分特别适用于处理结构化或半结构化数据时，因为特定块可以与元数据过滤结合使用，以进行更精确的检索。例如，在法律文件中，您可能希望提取所有的保证或赔偿条款，并且当您将块的嵌入存储在向量数据库中时，您可以使用元数据来更轻松地搜索给定类型的内容，以构建RAG用例。
递归分块
- 使用时机：递归分块使用层次化的方法将数据分成越来越小的块。例如，当对文本文档进行分块时，可以先将文本分成段落，然后再将段落分成句子，最后再分成单词。一旦数据被分成了第一组块，就可以对每个较小的块递归地应用分块过程，重复操作直到达到感兴趣的最小块大小。
- 技术考虑：实现递归分块可能涉及到多级解析策略，根据附加的标准将块进一步分成子块。如果您正在使用LangChain，它的递归实现比此处描述的要简单一些。
- 额外见解：这种方法使模型能够在不同级别的高级主题和详细细微之间理解上下文，因此对于复杂的文档（如学术论文、技术手册或法律合同）特别有用。这带来了灵活性的好处，因为相似性搜索可以识别出更广泛和较短查询的相似文本。但是，这也意味着相同来源文档的相似块在相似性搜索中可能会被过度呈现，尤其是如果您选择在文本分割器配置中使用更长的重叠。
作为一种一般方法，在对一大批语料库进行分块和向量化之前，应考虑对数据进行一些即兴实验。手动检查您想要为特定查询检索的文档，确定表示理想上下文的块，然后尝试使用分块策略，看看哪种策略给出的块最相关，最适合提供给LLM使用。
上下文窗口的考虑
LLM的可用上下文窗口是选择分块策略的重要因素。如果上下文窗口较小，您需要更加有选择地提供块给模型，以确保包含最相关的信息。相反，较大的上下文窗口能够提供更大的灵活性，可以包括可能增强模型输出的额外上下文，即使不是严格必要的。
通过尝试这些分块策略并考虑这些因素，您可以评估它们对生成结果相关性的影响。关键是将选择的策略与您的RAG应用程序的具体要求相一致，保持输入的语义完整性，并提供对上下文的全面理解。这将使您能够找到最佳性能的正确分块过程。
元数据过滤
随着搜索索引中嵌入的数量增长，当寻找与提示中的相关上下文时，近似最近邻（ANN）变得不太有用。假设您的知识库中已经索引了200篇文章的嵌入。如果您能够以1%的准确率找到最接近的邻居，那么您很可能会得到相当相关的结果，因为1%代表这200篇文章中的前两篇，而您将得到其中之一。
现在考虑一下包含维基百科中所有文章的搜索索引。那将约有670万篇文章。如果您的最近邻属在最相似的文章中排在前1%，那意味着您将获得最相似的67000篇文章中的一篇。对于像维基百科这样的语料库来说，这意味着您可能还是离正确结果相差甚远。
元数据过滤为您提供了一种方法来通过首先过滤文档，然后应用最近邻算法来缩小内容片段的范围。在处理大量可能匹配的情况下，这种初始预过滤可以帮助您在检索最近邻居之前缩小可能的选项。
接下来，我们将深入探讨与LLM的交互，并审视可能导致结果不佳的常见问题。