LLM之RAG实战（十三）| 利用MongoDB矢量搜索实现RAG高级检索

       想象一下，你是一名侦探，身处庞大的信息世界，试图在堆积如山的数据中找到隐藏的一条重要线索，这就是检索增强生成（RAG）发挥作用的地方，它就像你在人工智能和语言模型世界中的可靠助手。但即使是最好的助理也有其局限性，因此，让我们开始探索RAG的高级方法，重点关注大规模文档检索中的精度和上下文。

一、基本RAG

       想象一下，有一本和地平线一样宽百科全书。基本的RAG试图将这些丰富的知识提炼成一个单一的“嵌入”——本质上是一个数字。但是，当你在一个特定的主题上寻求智慧时，比如神秘的百慕大三角，基本的RAG的粗笔画会覆盖更多细节，给你留下一幅不完整的画面。这种限制就像试图用一张只显示大陆的地图来寻找隐藏的宝藏，而不是通往标有“X”的地点的复杂路径。

       另一方面，如果我们只拥有带有嵌入的单个页面，我们可能会找出具体的事实，但当它们交织在一起时，我们就会失去它们所讲述的故事。如果没有叙事，大型语言模型（LLM）很难找到一个能抓住我们探究的真正本质的答案。

       基本RAG，虽然是一个值得称赞的里程碑，但没有做的更好。基本RAG只是一个基础，需要跨越通用知识和精确见解之间的距离，我们需要做更细致的优化工作。

二、路径的细化：父子文档关系

       我们不是对整个百科全书进行单一的总结，而是为每一页（子文档）进行简洁的概述，注意包含的章节（父文档）。该方法在我之前的LLM之RAG实战（五）| 高级RAG 01：使用小块检索，小块所属的大块喂给LLM，可以提高RAG性能博客中有所介绍，这里略过。

2.1 步骤1：父子文档关系

       想象一下，你有一本又大又笨重的书——一本关于所有电器的用户手册。现在，有人问了一个特定的问题：“为什么我的洗衣机显示错误代码2？”，对于基本的RAG，我们要么得到缺乏上下文的小块，要么得到搜索不够准确的大块。然而，高级RAG采用了更聪明的方法。

       首先，手册被分解成大块——这些是我们的“父”文档。每一节都涉及更大的信息。在这些部分中，我们拆分了涵盖特定问题的“子”文档，如洗衣机的错误代码。

       现在，来看看矢量化的魔力。每个子文档都通过嵌入模型进行处理，该模型分析文本并将其转换为向量——一系列表示文本本质的数字。这就像为每一小段信息创建一个DNA图谱。

       每个子文档的文本都被提取到一个向量中，然后将其存储在向量存储中，其父文档也存储在这个向量存储中——这也是一个通用数据库。这使我们不仅可以快速检索最相关的小信息，还可以保留父文档提供的上下文。

2.2 步骤二：问答