巅峰对决 LlamaIndex 与 OpenAI API大比拼

 我们进行了一项详尽的分析，比较了 OpenAI 助手 API 和 LlamaIndex 在 RAG 性能方面的差异。目的是使用Tonic Validate评估各种RAG系统，该系统是一个RAG评估和基准平台，同时使用开源工具tvalmetrics。本文中使用的所有代码和数据都可以在这里找到。简单来说，Llamaindex目前在速度上大幅领先（尤其是在处理多个文档方面）。几个关键的发现包括：

多文档处理：在处理多个文档时，助手 API 的表现不尽人意。而 LlamaIndex 在这方面表现出色。

单文档处理：当文档被合并成一个*单一*文档时，助手 API 的性能有显著提升，在这方面略胜一筹于 LlamaIndex。

速度对比：“处理五份文档只用了七分钟，而 OpenAI 的系统在相同条件下几乎要花上一个小时。

”稳定性：“相比于 OpenAI 的系统，LlamaIndex 显著降低了崩溃的风险”

介绍

上周，我们测试了OpenAI的Assistants API，并发现其在处理多个文档时存在一些主要问题。然而，为了更好地评估其性能，我将比较OpenAI的Assistants RAG与另一个流行的开源RAG库LlamaIndex。让我们开始吧！测试OpenAI的Assistants RAG 在先前的文章中，我们已经设置了OpenAI的Assistants RAG。您可以在此处查看原始设置。这是一个提醒：我们的测试集使用了212篇Paul Graham的文章。最初，我们尝试将所有212篇文章上传到RAG系统，但发现OpenAI的RAG将上传限制在最多20个文档。为了解决这个问题，我们将这212篇文章分成五组，并为每组创建了一个单独的文件，总共得到了五个文件。我们使用了五个文件而不是20个，因为在更高的文档数量上遇到了可靠性问题，这阻止了我们在20个文件集上运行任何测试。通过这个五文件的设置，我们使用我们的开源RAG基准库tvalmetrics得到了以下结果：

在我们的软件包中，得分为0表示没有相似性，而5表示完全相似。上面的结果并不理想，平均相似性得分为2.41，中位数为2。这低分是由于OpenAI的RAG系统无法在文档中找到相关文本，导致系统返回无答案。

在我们的软件包中，得分为0表示没有相似性，而5表示完全相似。上面的结果并不理想，平均相似性得分为2.41，中位数为2。这低分是由于OpenAI的RAG系统无法在文档中找到相关文本，导致系统返回无答案。

为了导入这些文档，我运行了以下代码：

要查看我如何创建单一和多文档的训练集，以及用作测试集的问题-答案对，您可以在上一篇博客文章中查看我的撰写，点击这里。

检查设置

最后，我们可以进行抽样检查以查看LlamaIndex的表现如何。

对于五文档设置和单一文档设置，LLM返回了相同的正确答案：

评估RAG系统

现在，让我们使用tvalmetrics进行评分，这是Tonic.ai在测量LLM响应质量方面创建的一个开源库。我使用以下代码对LlamaIndex的响应进行基准测试：

使用五文档设置，我得到了以下结果：

使用多个文档，LlamaIndex的表现远远好于OpenAI。其平均相似性得分约为3.8，略高于平均水平，中位数为5.0，非常出色。相较于使用相同设置的OpenAI系统，五个文档的运行时间仅为七分钟，而OpenAI系统几乎需要一个小时。我还注意到，与OpenAI的系统相比，LlamaIndex系统明显不太容易崩溃，这表明OpenAI的可靠性问题更多地与RAG系统本身有关，而不是Assistants API。

我应该指出，通过调整一些LlamaIndex参数，包括将块大小更改为80个令牌，块重叠为60个令牌，提供的块数为12，并使用LlamaIndex中的混合搜索选项，我获得了稍微更好的结果。这样做产生的结果更接近于OpenAI，但并不完全一样：

 

虽然两个系统之间的性能现在更接近了，但在仅单一文档上，OpenAI仍然稍微领先。请记住，我使用的设置是针对我提出的问题类型进行调整的（即，短问题，其答案在文本中非常明显）。这些设置在所有情景下都不适用，而OpenAI设法在理论上适用于任何情况的设置下实现了良好的性能。尽管由于OpenAI不允许对其设置进行大量定制，您可能正在放弃一些性能。最终，取决于您是否希望通过在某些情景下获得更多定制来获得更好的结果，还是选择一个通用的开箱即用工具，可以在特定情况下取得不错的性能（...仅限于单一文档）。

结论

OpenAI的RAG系统似乎很有前途，但在处理多个文档时的性能问题显著降低了其实用性。他们的系统在单一文档上运行良好。然而，大多数人可能希望在一系列不同文档上运行他们的RAG系统。虽然他们可以把所有文档塞进一个单一的、庞大的文档中，但那只是一种技巧，不应该是一个性能良好、易于使用的RAG系统所需要的。再加上20个文件的限制，这让我不太愿意建议任何人立即用OpenAI的RAG替换其现有的RAG流水线。然而，正如我之前所说，OpenAI仍有改进的潜力。在对其GPT的RAG系统进行一些抽样检查时，我注意到在处理多个文档时性能要好得多。糟糕的性能仅限于Assistants API本身。如果OpenAI努力提高Assistants API的质量，使其达到GPT的水平并消除文件限制，那么我可以想象公司可能会考虑迁移到OpenAI的RAG，前提是他们愿意放弃LlamaIndex提供的一些可定制性。然而，在那一天到来之前，我建议继续使用LlamaIndex。本文中使用的所有代码和数据都可以在这里找到。我很想听听您对OpenAI Assistants、GPT和tvalmetrics的看法！