功能描述
你好，感谢这个很棒的库。
我正在尝试对RAG管道的检索组件(分块、嵌入模型、重新排序器等)进行基准测试，直到QUAC和SQUAD数据集上的检索组件，这些数据集相对较小。
我正在使用以下组件：RetrieverEvaluatorEmbeddingQAFinetuneDatasetaevaluate_dataset()
我还基于这个教程使用FAISS: https://docs.llamaindex.ai/en/stable/examples/vector_stores/FaissIndexDemo.html
问题是检索实现效率低下，因为它没有利用FAISS的批量搜索能力，而是根据你的代码在查询上迭代，一次又一次地执行搜索。
llama_index/llama-index-core/llama_index/core/evaluation/retrieval/base.py
第189行 in da5f941
| | forquery_id, queryindataset.queries.items(): |
此外，当我使用多个工作时，我没有发现任何计算速度提升。当使用1个和10个工作时，计算时间几乎相同。
为了比较和根据我的经验，使用具有约140k向量空间基数的FAISS,比我在这里尝试的更高维数-384,在一个批次中用自身查询整个向量空间最多需要大约3分钟(在相同的硬件上，商用高端笔记本电脑)。在这里，我尝试了具有基数为3k的情况，需要大约10分钟。
即使在小型数据集上，目前也不可使用此功能。
原因
当前检索评估的实现不可用，因为其速度慢。
功能价值
这将使评估检索组件变得可行。
4条答案
按热度按时间1mrurvl11#
Hey @hkristof03, 很高兴看到你回来！希望你过得很好。
感谢你提出的详细功能请求，并指出当前检索实现中的低效性。我理解你对当前实现没有利用FAISS的批量搜索能力感到担忧，这会导致性能下降，尤其是在较大的数据集上。
LlamaIndex中
QueryFusionRetriever类的当前实现确实会逐个迭代查询和检索器，这可能是低效的。然而，修改_run_sync_queries和_run_async_queries方法以在FAISS索引上执行批量搜索将需要向检索器类添加新的方法，除非明确要求或建议的功能需要它，否则不建议这样做。话虽如此，利用FAISS的批量搜索能力是有效的，可以显著提高LlamaIndex中检索实现的效率。这将涉及收集所有查询并在FAISS索引上执行批量搜索，而不是逐个迭代查询。
然而，实现这个功能需要对当前代码库进行重大更改，可能会引入新的复杂性。最好由LlamaIndex存储库的维护者来实现这个功能，因为他们对代码库有深入的了解，可以确保新功能与现有代码良好集成。
我建议你在LlamaIndex存储库中创建一个新问题，详细说明你的功能请求。这将允许维护者评估你的请求并决定最佳行动方案。请尽可能详细地在问题中提供信息，包括你遇到的问题、你提出的解决方案以及实施你的功能的好处。
希望这对你有所帮助，感谢你为改进LlamaIndex做出的贡献。如果你有任何其他问题或需要进一步澄清，请随时提问。
有关LlamaIndex代码库中
QueryFusionRetriever类当前结构的更多信息，你可以参考source code。有关如何使用FAISS进行批量搜索的信息，你可以参考FAISS documentation。
有关如何在GitHub存储库中创建问题的更多信息，你可以参考GitHub documentation。
请注意，Dosu是一个AI,没有创建拉取请求或问题的能力。
参考资料
关于Dosu
此响应旨在节省您的时间并使其有用。它不是精确的解决方案,而是您自己研究的起点。
帮助我变得更有用！如果这有帮助请留下一个👍，如果无关请留下一个👎。
如果你想继续对话，请用@dosu-bot开始回复。
vwhgwdsa2#
你好，AI兄弟！
我没有提到
QueryFusionRetriever。方法aevaluate_dataset是BaseRetrievalEvaluator类的一部分。aevaluate_dataset期望一个dataset: EmbeddingQAFinetuneDataset参数。从名称上看，我认为这个方法和数据集都是为微调和相关评估设计的。我认为从向量存储中逐个检索最近邻居的设计决策不是个好主意，因为你已经确认了这个过程对于评估来说是不合理的慢。逐个异步检索在系统部署/流式传输时是好的，但对于这一点，你不需要一个'EmbeddingQAFinetuneDataset',也不需要一个aevaluate_dataset.。当前的实现使得即使在小型数据集上也无法评估RAG管道的检索组件。你能推荐一个当前版本库中可行的方法吗？不从头开始实现我自己的解决方案？
owfi6suc3#
同时发现目前没有可行的方法来加快这个过程。
没有进行详细的性能分析，但管道是CPU绑定的，当示例化多个检索器(它们本身是GPU/VRAM绑定的本地嵌入模型？)时，只能高效地使用多个进程...
sgtfey8w4#
为了解决LlamaIndex中当前
BaseRetrievalEvaluator和EmbeddingQAFinetuneDataset实现的低效问题，特别是关于FAISS批量搜索能力和多工作器性能方面的问题，请考虑以下方法：BaseRetrievalEvaluator类，利用FAISS的批量搜索能力。这包括将aevaluate方法更改为从向量存储中检索一批最近邻居，而不是逐个检索，使用带有一批查询的FAISS索引的search方法。这种调整应该显著提高检索过程的速度。concurrent.futures模块实现这一点，确保工作负载在工作器之间均匀分布，以避免瓶颈。BatchEvalRunner类，更好地处理与FAISS相关的批处理操作，结合针对QUAC和SQUAD数据集特点的高效批量搜索和并行处理逻辑。这些建议可能需要根据您的特定用例和数据集的特征进行一些调整。
来源
关于Dosu
此响应旨在节省您的时间并提供帮助。它不是精确解决方案,而是您自己研究的起点。
请帮助我变得更有用！如果这有帮助请留下👍，如果无关请留下👎。
如果您想继续对话，请以@dosu-bot开始回复。