RAG5个常见错误

向量数据库并非硬性规定

几乎互联网上所有关于RAG的教程都使用向量存储。如果你一直在搜索RAG相关内容，你就会明白我们在说什么。

基于向量的检索无疑是RAG成功的重要因素。向量嵌入非常适合映射文本的语义含义。它们也能很好地处理不同大小的文本。你的查询可能只是一个句子，但你的文档存储包含整页的文章？—向量搜索能够处理这些情况。

然而，检索并不仅限于基于向量的检索。

RAG可以从互联网、关系型数据集、Neo4J中的知识图谱，或者这三者的组合中检索信息。

在许多情况下，我们注意到混合方法往往能带来更好的性能。

对于通用应用，你可以使用向量存储，但当向量存储中没有可用信息时，你可以搜索互联网。

对于客户聊天机器人，你可能需要授予RAG访问部分客户数据库的权限，这可能是一个关系型数据库。

公司的知识管理系统可能会创建知识图谱并从中检索信息，而不是使用向量存储。

从定义上讲，所有这些都是RAG。

然而，确定使用哪些数据源的过程并不是很直接。你需要尝试各种选项，了解每种方法的优缺点。接受或拒绝某个想法的原因可能受到技术和业务考虑的双重影响。

例如，你可以创建每个客户资料信息的文本版本，并将其向量化以供检索。这对于查询来说效率很高，因为你只需处理单个数据库。但它可能不如运行SQL查询准确。这是一个需要考虑的技术原因。

然而，让LLM运行SQL查询可能导致SQL注入攻击。这既是技术问题也是业务顾虑。

向量数据库对语义检索也很有效。但这并不意味着其他数据库无法处理语义检索；几乎所有其他数据库都可以处理向量搜索。

优先选择微调过的小型模型

嵌入模型可以将任何内容转换为向量形式。在更大的模型上你会看到比小模型更好的性能。

然而，这并不意味着更大就总是更好。

忘掉规模吧。所有模型都是在公开数据集上训练的。它们知道苹果(水果)和苹果(品牌)之间的区别。但是，如果你和你的朋友用"苹果"作为暗号，嵌入模型无法知道这一点。

而且，我们创建的几乎所有应用都专注于一个小众话题。

对于这些应用，使用更大模型带来的好处是微不足道的。

下面是一种不同的做法：

为你的领域数据创建一个数据集，并微调一个小型嵌入模型。

小型模型足以捕捉语言细微差别，但可能无法理解在不同情境中具有特殊含义的词语。

但仔细想想，为什么你的模型需要理解木星的卫星是什么呢？

小型模型更高效。它们速度快且成本低。

要让模型具备领域知识这一缺失能力，你可以对其进行微调。

这两个提示可以修复高效检索的索引部分。但是，检索过程本身也可以优化。

检索过程可以更先进

最直接的检索过程是直接查询。

如果你使用向量数据库，可以对用户输入进行语义搜索。否则，你可以使用LLM生成SQL或Cipher查询。

如果需要，你也可以调用HTTP端点。

但直接查询方法很少能产生可靠的上下文。

你可以通过更高级的方法查询数据源。例如，你可以尝试查询路由技术来决定从哪个数据源获取数据。具有良好推理能力的LLM可以用于此目的。你还可以对较小的模型进行指令微调，以节省成本并减少延迟。

另一种技术是链式请求。对于初始查询，我们可以从数据源获取信息。然后，基于获取的文档，我们可以获取后续文档。

分块是RAG中最具挑战性和最重要的部分

当上下文中包含不相关信息时，LLM往往会失控。

防止RAG中出现幻觉的最佳方法是分块。

现代LLM可能支持更长的上下文长度。例如，Gemini 2.5 Pro支持高达200万个token，足以容纳两到三本大学级别的物理教科书。

但对于关于基础力学的问题，你很少需要来自量子物理学的上下文信息。

如果你将教科书分解成更小的部分，可能每一部分只讨论一个主题，那么你只需获取与问题相关的信息。

这里的挑战在于有许多分块技术。每种技术都有自己的优缺点。对你的领域最有效的方法可能对其他领域不起作用。

递归字符分块可能是最简单的，也是我们的默认选择。然而，它假设文本中每个主题的讨论长度相等，这在现实中很少见。尽管如此，最好从这开始。

沿着这条路走下去，你甚至可以尝试主题聚类和代理式分块。

尝试重排序

最后但同样重要的是重排序。

已经证明，相关分块的位置对高质量LLM响应至关重要。

然而，常规的向量搜索，甚至数据库查询，都不能非常智能地排序结果。而LLM可以。

因此，我们使用专门的大型语言模型(LLM)作为重排器，对获取的上下文进行重新排序，并进一步过滤，只找出最相关的分块。

这种二级重排序在某些应用中有益，但在其他应用中则不然。但有一些技术可以用来改进重排序结果。

其中一种是获取大量初始结果。宽松定义初始标准会拉取一些不相关的上下文，但它增加了找到正确内容的概率。

现在，重排器可以处理这个大集合并过滤出更相关的内容。